Re: [nfsv4] sparse files support for NFS

[Marc Eshel <eshel at almaden.ibm.com>]

Let me make my proposal less ambiguous. What I really want is step two, 
which is a new return code and information to the location of the next 
chunk of data. Step one was only to illustrate how simple it is with just 
one new return code we can get a big improvement, and step three requires 
pNFS and I prefer not to have it as a requirement to support sparse files.
Marc.




From:
"Noveck, Dave" <Dave.Noveck at netapp.com>
To:
"Dean Hildebrand" <seattleplus at gmail.com>
Cc:
"Marc Eshel" <eshel at almaden.ibm.com>, "Nikita Danilov" 
<danilov at gmail.com>, <nfsv4 at ietf.org>, Dean Hildebrand/Almaden/IBM at IBMUS
Date:
10/05/2009 07:48 AM
Subject:
RE: [nfsv4] sparse files support for NFS




I think barriers to entry are an important consideration.  However, I
don't think we will wind up with more than two levels.  That is, we'll
have to make choice whether we have Marc's first step for the base
protocol and his third for pNFS or Marc's second step for the base
protocol and his third for pNFS. 

-----Original Message-----
From: Dean Hildebrand [mailto:seattleplus at gmail.com] 
Sent: Friday, October 02, 2009 2:55 PM
To: Noveck, Dave
Cc: Marc Eshel; Nikita Danilov; nfsv4 at ietf.org; Dean Hildebrand
Subject: Re: [nfsv4] sparse files support for NFS



Noveck, Dave wrote:
> Understood, but the working group has to decide:
>
> 1) Whether it will address sparse files in v4.2.
> 2) In what ways, it will address sparse files in v4.2.
>
> I understand Nikita's message in that context.  While you have 
> proposed three steps, the working group needs to decide whether the 
> first two are worth doing if the third addresses the problem.
Along these lines, it is worth considering the effort (barrier of entry)
for supporting a feature.
Marc's first step, a adding a simple error return code, will drastically
improve the performance of reading sparse files with a very small
protocol change.

Improving this efficiency through pNFS or some other manner would then
improve this efficiency somewhat, but with a drastically higher barrier
of entry for implementations (supporting all of pNFS plus a dedup layout
on both the client and server).

In summary, I don't see it as an either/or situation.  I believe the
simple step (for non pnfs clients) plus a more complete and complex
solution are both worth supporting.

Dean
>   I'm not taking a
> position here on this issue (If I did, I'd have a different one 
> tomorrow, and the day after that :-), but one direction the group 
> might take is to push content that can be done in a storage protocol 
> into that framework and only put things that need a base protocol 
> change into v4.2 per se.
>
> I think the argument can be made is that this would allow a faster 
> rate of innovation (assuming that's a good thing :-), via 
> implementation of experimental storage protocols.  This would take 
> advantage of the work that has been done to accommodate the very 
> different requirements of files, objects, and blocks.  This work has 
> created a more modular protocol framework and it may well be that the 
> benefits will be similar to that for code modularity, assuming we have

> created the right module boundaries and interfaces, which does need to
be shown.
>
> -----Original Message-----
> From: Marc Eshel [mailto:eshel at almaden.ibm.com]
> Sent: Wednesday, September 30, 2009 11:45 AM
> To: Nikita Danilov
> Cc: nfsv4 at ietf.org; Dean Hildebrand
> Subject: Re: [nfsv4] sparse files support for NFS
>
>
> Nikita Danilov <danilov at gmail.com> wrote on 09/30/2009 04:43:58 AM:
> 
>> Hello,
>>
>> Marc Eshel wrote:
>>  > I would like to propose an extension to NFSv4.2 to support sparse
>> 
> files.
> 
>> [...]
>>
>>  > zeros over the network. Step two can also provide additional
>> 
> information
> 
>>  > along with the E_HOLE return code to specify the offset of next
>> 
> data
> chunk
> 
>>  > and the length of it. Step three would be to use pNFS layouts to
>> 
> describe
> 
>>  > the holes in the file and avoid reading them by the client all
>> 
> together.
> 
>> won't de-duplication, as proposed in
>> http://tools.ietf.org/html/draft-eisler-nfsv4-pnfs-dedupe-00, cover 
>> client-side sparse files support?
>> 
>
> No, the first two steps are simple and are independent of pNFS, maybe 
> the third step can be combined with the pNFS proposal for dedupe but I

> will need to think about some more.
> Marc.
>
> 
>>  >
>>  > Marc.
>>
>> Thank you,
>> Nikita.
>> 
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>