Subject: Re: [nfsv4] sparse files support for NFS

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 1 Oct 2009 15:27:19 -0400

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.  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:[email-masked]] 
Sent: Wednesday, September 30, 2009 11:45 AM
To: Nikita Danilov
Cc: [email-masked]; Dean Hildebrand
Subject: Re: [nfsv4] sparse files support for NFS

Nikita Danilov <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 02 Oct 2009 14:55:04 -0400

Noveck, Dave wrote:
> 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

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 5 Oct 2009 10:47:39 -0400

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:[email-masked]] 
Sent: Friday, October 02, 2009 2:55 PM
To: Noveck, Dave
Cc: Marc Eshel; Nikita Danilov; [email-masked]; Dean Hildebrand
Subject: Re: [nfsv4] sparse files support for NFS

Noveck, Dave wrote:
> 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
> 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.
> 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.
>>     
>

---

From: Marc Eshel <[email-masked]>
Date: Mon, 5 Oct 2009 09:07:56 -0700

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" <[email-masked]>
To:
"Dean Hildebrand" <[email-masked]>
Cc:
"Marc Eshel" <[email-masked]>, "Nikita Danilov" 
<[email-masked]>, <[email-masked]>, Dean Hildebrand/Almaden/IBM@IBMUS
Date:
10/05/2009 07:48 AM
Subject:
RE: [nfsv4] sparse files support for NFS

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

Dean

be shown.