Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 10:36:14 -0400

On Wed, Sep 29, 2010 at 04:41:09PM -0700, Dean Hildebrand wrote:
>  Hello,
> 
> I uploaded a new version of our internet draft "Simple and Efficient
> Read Support for Sparse Files".
> 
> http://www.ietf.org/id/draft-hildebrand-nfsv4-read-sparse-01.txt

A couple other points:

	- By returning an error in a situation that isn't really an
	  error, we abort processing the compound when we don't really
	  need to.  I suppose we could make a special exceptions for
	  NFS4ERR_HOLE, but, yuch.
	- The server can't return NFS4ERR_HOLE unless it knows the
	  client is prepared to handle it.  One solution would be to
	  make client support for NFS4ERR_HOLE mandatory in whichever
	  minor version we add sparse-read support.  Whether that works
	  well may depend on the eventual size of the minor version.
	  It's easier if people can increment new features
	  incrementally.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 11:39:34 -0400

On Fri, Oct 01, 2010 at 05:23:18PM +0200, Benny Halevy wrote:
> On 2010-10-01 16:36, J. Bruce Fields wrote:
> As I said in the meeting I'd be happier with a revised READ operation
> that officially support holes rather than hacking the existing op.

I'd be for that.

As long as the name of the new operation includes the letter "Z".

> While at that, I'd add an optional prefetch value to the args to
> help client-directed readahead.

I think it would be amusing to have a version of READ that implements
the rsync protocol.  (Here's my checksum of the data in the range; tell
me I'm right, or give the real data if not.)

(Maybe that one would need a "Y" in the name.)

--b.

---

From: Marc Eshel <[email-masked]>
Date: Fri, 01 Oct 2010 08:49:02 -0700

We don't need a new operation but it is mandatory that the client will 
recognize this new NFS4ERR_HOLE return code, just for that we don't need 
another operation. Clearly the server don't have to support it and the 
client doesn't need to use the server advice.
Marc.

On 10/1/2010 8:39 AM, J. Bruce Fields wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: <[email-masked]>
Date: Fri, 1 Oct 2010 12:07:15 -0400

> I think it would be amusing to have a version of READ that 
> implements the rsync protocol.  (Here's my checksum of the 
> data in the range; tell me I'm right, or give the real data 
> if not.) 

I agree it is amusing.

However, the people for whom it is amusing are a strange sort of people.
That is, they are like us.  It definitely will not work as stand-up,
even at an IETF meeting, even with a drummer behind you for sound
effects

I note that amusement is not on Mike's requirement list for v4.2 but
Spencer has told us that that is not a bar.  At this point, I kind of
feel that amusing ops might be good.  

With copy as well, we are definitely moving in the direction of avoiding
reads with special ops that process the data on the remote side.  The
general case is that you send some sort of program to process the data
on the remote side but that prospect is more depressing than amusing.

BTW, I agree that trying to hack READ is losing battle.  If you think
there is any prospect of other sorts of such function, rather than new
ops for each, I would have one new op and an enum to facilitate that
expansion.  Then you could use the new op to do plain READ, READZ, and
anything else that the group later finds amusing/useful

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of J. Bruce Fields
Sent: Friday, October 01, 2010 11:40 AM
To: Benny Halevy
Cc: [email-masked]
Subject: Re: [nfsv4] New version of sparse draft
(draft-hildebrand-nfsv4-read-sparse-01.txt)

I'd be for that.

--b.

---

From: Benny Halevy <[email-masked]>
Date: Fri, 01 Oct 2010 18:18:49 +0200

> anything else that the group later finds amusing/useful

I'm not sure if this is any better than a flat operations namespace.
At least with the latter ERR_UNSUPPORTED is more definitive.

Benny

---

From: <[email-masked]>
Date: Fri, 1 Oct 2010 12:24:18 -0400

I went through a similar issue in which I tried to get by (in an
unrelated personal draft) in which I tried to get by with an error code
to note a non-fatal condition and return some error-like info as an
error even though a COMPOUND could have gone on.  All the people I
talked to, said something on the order of "no way".

As the concept of "consensus" has become so fraught, let me say it this
way.  If you try to do this, people are going to start holding their
noses.  This has a powerful effect.  You say to yourself, "I just took a
shower.  I don't smell."  Still people are holding their noses.  You
will give up on something like this.  People just don't like COMPOUNDs
terminating if there are not errors.  Deal with it. 

Thanks for reminding me of the fact I have to update my draft. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of J. Bruce Fields
Sent: Friday, October 01, 2010 10:36 AM
To: Dean Hildebrand
Cc: [email-masked]
Subject: Re: [nfsv4] New version of sparse draft
(draft-hildebrand-nfsv4-read-sparse-01.txt)

A couple other points:

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 12:26:50 -0400

> even at an IETF meeting, even with a drummer behind you for sound

Pfft.

> anything else that the group later finds amusing/useful

Well, we probably also want to do one thing at a time to the extent
possible.

E.g., for now try defining a READZ that just handles the case of
returning zero-extents as well as data, and don't start hanging lots of
unrelated features off of it until we've tried to define those features
separately first and concluded they really have to be part of the same
op....

Uh, maybe that's actually what you just said, and I didn't understand.

(And wouldn't benny's prefetch work best as a separate PREFETCH op that
took a range and returned no data?)

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 1 Oct 2010 16:38:06 +0000

Thanks for the update, Dean.

I tend to agree with others that it is likely best to introduce a new READ operation that
incorporates the ideas presented in this draft.  This new operation could allow for a
scatter/gather-like mechanism.  Allowing the client to do a 1MB read and obtain all
of the data within that range while reducing the amount of data transferred is
attractive.

More generally, your draft does combine the idea of space allocated at the server
for the file with the method of effective transfer of data when zeros or unallocated
or uninitialized ranges exist.  It is fine to combine the two ideas in the draft but
a little more explicit language would be helpful (I will make some suggestions offline).

It may be helpful to combine the these READ hole ideas with space allocation
controls provided to the client (allocate, release/trim, etc.).  Anyone else
in the WG have an opinion here?

Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Hildebrand
Sent: Wednesday, September 29, 2010 4:41 PM
To: [email-masked]
Subject: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)

Hello,

I uploaded a new version of our internet draft "Simple and Efficient Read Support for Sparse Files".

Please have a look and give us any feedback.

The main changes are:
1) Added section regarding pNFS (which basically states that there are no real changes to how pNFS works)
2) Added example sparse read message flow
3) Added statement to the effect that if a client sends a read request for a chunk that ends in zeroes, the server can return a short read (thanks to Benny)
4) I didn't change the return value.  There was a suggestion to use a flag instead of overloaded the length parameter, but I'm not sure what this gives us (although it might be more clear in the doc)

Dean

---

From: Marc Eshel <[email-masked]>
Date: Fri, 01 Oct 2010 10:28:55 -0700

I can claim that trying to read unallocated part of the file is and 
error :) but I see the point of complicating the error handling.  We can 
instead just add more information to the reply without giving the error 
return code.
I think this a simple solution that should be agreed on as alternative 
if we don't have a more general solution that will cover the requirement 
for this one.
This is a good example how we this group start with simple ideas and 
ending up with a conflicted and convoluted protocol that drags for years.
We proposed it, I believe we got consensus. We can fine tune it to make 
every one happy. If someone has a better idea let them write a draft and 
if the group agrees that it is a solution we can switch to the new 
proposed draft.
Marc.

On 10/1/2010 9:38 AM, Spencer Shepler wrote:
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Dean Hildebrand
> *Sent:* Wednesday, September 29, 2010 4:41 PM
> *To:* [email-masked]
> *Subject:* [nfsv4] New version of sparse draft 
> 3) Added statement to the effect that if a client sends a read request 
> for a chunk that ends in zeroes, the server can return a short read 
> (thanks to Benny)
> 4) I didn't change the return value.  There was a suggestion to use a 
> flag instead of overloaded the length parameter, but I'm not sure what 
> this gives us (although it might be more clear in the doc)
>
> Dean
>
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 13:40:50 -0400

On Fri, Oct 01, 2010 at 10:28:55AM -0700, Marc Eshel wrote:
> error :) but I see the point of complicating the error handling.  We
> can instead just add more information to the reply without giving
> the error return code.

The status is the only switch you can really take advantage of in the
read reply, so I don't think that's an option.  (The minorversion rules
prohibit completely replacing the xdr for an existing operation, which
is a good rule.)

> I think this a simple solution that should be agreed on as
> alternative if we don't have a more general solution that will cover
> the requirement for this one.

I think you'll find a separate READZ will be simpler if anything.

That doesn't force you to accept any extra bells and whistles if you
don't want to.

--b.

> We proposed it, I believe we got consensus. We can fine tune it to
> make every one happy. If someone has a better idea let them write a
> draft and if the group agrees that it is a solution we can switch to
> the new proposed draft.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 1 Oct 2010 17:46:40 +0000

From: Marc Eshel [mailto:[email-masked]]
Sent: Friday, October 01, 2010 10:29 AM
To: Spencer Shepler
Cc: Dean Hildebrand; [email-masked]
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)

I can claim that trying to read unallocated part of the file is and error :) but I see the point of complicating the error handling.  We can instead just add more information to the reply without giving the error return code.
I think this a simple solution that should be agreed on as alternative if we don't have a more general solution that will cover the requirement for this one.
This is a good example how we this group start with simple ideas and ending up with a conflicted and convoluted protocol that drags for years.
We proposed it, I believe we got consensus. We can fine tune it to make every one happy. If someone has a better idea let them write a draft and if the group agrees that it is a solution we can switch to the new proposed draft.

You are correct, Marc.  As owner of a personal draft, there is no requirement
that input to the draft be accepted.  The owner can appropriately decline
the input and continue forward.  Competing I-Ds can be helpful in that
ideas are presented in fuller form beyond just the short feedback that
an email thread allows.

Spencer

---

From: Marc Eshel <[email-masked]>
Date: Fri, 01 Oct 2010 10:54:38 -0700

> That doesn't force you to accept any extra bells and whistles if you

That sounds fair, but it should be called DONT_READ_Z  :)
Marc.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 14:12:14 -0400

> That sounds fair, but it should be called DONT_READ_Z  :)

We can say the Z is for "zoom", or "zippy", rather than zero.

--b.

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 01 Oct 2010 13:02:16 -0700

On 10/1/2010 9:38 AM, Spencer Shepler wrote:
> incorporates the ideas presented in this draft.
>
While a new operation is simple, it puts all the onus on clients to call 
the correct function.  Therefore, the only way for us to benefit from a 
new operation is if every client in existence stops using READ and 
switches to use the new operation.  If they do that, then what's the 
point of having the READ operation at all?

So with a new operation, I'm just not sure what the guidance to 
implementors would be?  Stop using READ? We wanted a simple addition to 
the protocol, not to deprecate READ :)

>This new operation could allow for ascatter/gather-like mechanism. 
Allowing the client to do a 1MB read and obtain all

> in the WG have an opinion here?
Yes, Bruce pointed out that my text switches between zero and 
unallocated.  I need to clean up this language.  But in fact, they are 
one and the same idea.  The READ operation doesn't control space 
allocation, that would be create or write.  The READ operation just 
wants to know if it should return data or a flag.

We want to propose the FADVISE like operation mentioned in Mike's draft 
at some point, this might be a good place for space allocation  information.
Dean

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 1 Oct 2010 20:07:47 +0000

Dean,

To the question of adding a new operation.  I am not sure I see the burden or cost
in the same way as you state.  The semantics of READ would change (old or new
operation) and the clients would need to be updated to deal with the new semantics
to take advantage of the functionality; therefore, there is implementation burden
in either path.  One advantage of a new operation is the clarity to the server in which
semantics the client is interested.

Spencer

From: Dean Hildebrand [mailto:[email-masked]]
Sent: Friday, October 01, 2010 1:02 PM
To: Spencer Shepler
Cc: [email-masked]
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)

While a new operation is simple, it puts all the onus on clients to call the correct function.  Therefore, the only way for us to benefit from a new operation is if every client in existence stops using READ and switches to use the new operation.  If they do that, then what's the point of having the READ operation at all?

So with a new operation, I'm just not sure what the guidance to implementors would be?  Stop using READ? We wanted a simple addition to the protocol, not to deprecate READ :)

>This new operation could allow for ascatter/gather-like mechanism.  Allowing the client to do a 1MB read and obtain all

It may be helpful to combine the these READ hole ideas with space allocation
controls provided to the client (allocate, release/trim, etc.).  Anyone else
in the WG have an opinion here?
Yes, Bruce pointed out that my text switches between zero and unallocated.  I need to clean up this language.  But in fact, they are one and the same idea.  The READ operation doesn't control space allocation, that would be create or write.  The READ operation just wants to know if it should return data or a flag.

We want to propose the FADVISE like operation mentioned in Mike's draft at some point, this might be a good place for space allocation  information.
Dean

Spencer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dean Hildebrand
Sent: Wednesday, September 29, 2010 4:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)

Hello,

The main changes are:

Dean

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 01 Oct 2010 13:44:31 -0700

> semantics the client is interested.
Yes, I agree, implementation work is needed either way, and having a 
more general READ function would probably benefit everyone.  I just 
wanted to make it clear that a proposal is being made to deprecate the 
current READ function and replace it with a more general READ operation. 
I would like everyone on board with that and not have it used as an 
excuse for rejection.
Dean

> Spencer
>
> *From:* Dean Hildebrand [mailto:[email-masked]]
> *Sent:* Friday, October 01, 2010 1:02 PM
> *To:* Spencer Shepler
> *Cc:* [email-masked]
> *Subject:* Re: [nfsv4] New version of sparse draft 
> While a new operation is simple, it puts all the onus on clients to 
> call the correct function.  Therefore, the only way for us to benefit 
> from a new operation is if every client in existence stops using READ 
> and switches to use the new operation.  If they do that, then what's 
> the point of having the READ operation at all?
>
> implementors would be?  Stop using READ? We wanted a simple addition 
> to the protocol, not to deprecate READ :)
>
> We want to propose the FADVISE like operation mentioned in Mike's 
> draft at some point, this might be a good place for space allocation  
> information.
> Dean
>
>
> Spencer
>
> *From:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Dean Hildebrand
> *To:* [email-masked] <mailto:[email-masked]>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Oct 2010 17:33:13 -0400

> draft at some point, this might be a good place for space allocation

It would be trivial to specify a WRITEZ that could also take zero
extents (so your write data could describe a range of zeroes instead of
explicitly listing all the zeroes).

And then it would be up to the server whether to translate that into
zero-writes or hole-punching, and in either case you could save some
bandwidth.

That's a bit different from fadvise as I understand it.

I'm not suggesting you need to include a WRITEZ, just saying that on the
write side also, transferring zeroes efficiently and allocating files
are two different things.

--b.

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 01 Oct 2010 15:15:13 -0700

> I'm not sure deprecating the legacy READ operation is required or even
> desired.  Why not specify the new READ operation as optional to the
> server and recommended for the client?
Sure, but remember that one operation would completely subsume the 
other.    Not sure why in the long run this would be desirable to 
maintain....

Dean
>>> *From:* [email-masked]<mailto:[email-masked]>
>>> *To:* [email-masked]<mailto:[email-masked]>

---

From: Benny Halevy <[email-masked]>
Date: Sat, 02 Oct 2010 00:49:20 +0200

> other.    Not sure why in the long run this would be desirable to 

This simplifies client implementations that do not make use of the new
functionality and makes them easier to port forward to support the new
minor version.  My inclination would be to add the new op as optional
in minor version X, and if it gains traction and we see interest
and demonstrate interoperability, then the old op can be obsoleted
in X+1.

Benny

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 01 Oct 2010 15:58:19 -0700

> and demonstrate interoperability, then the old op can be obsoleted

Exactly, I want everyone to realize the fact that we are on the road to 
obsoleting READ.
Dean

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sat, 2 Oct 2010 12:38:24 -0700

Dean, thanks for putting the draft together.

I have few comments on the draft proposal though.

First,

             For example, one possible way to implement sparse file
   read support would be to have the client, on the first hole
   encountered or at OPEN time, request a block layout map from the
   server.  While this option seems simple, it can become inefficient
   and cumbersome.  First, large block layout maps can be returned from
   the server, which can reduce overall READ performance.  For example,
   VMware's .vmdk files use 64KB blocks and can have a file size of over
   100 GBs.  This means that the possible number of allocated (or
   unallocated) blocks in the file can grow very large in the worse case
   scenario.

I don't seem to understand the comment that it reduces the overall READ
performance.
In what sense does it reduce the performance? My view is that the map
isn't any
different from the layout device map.

Are you hinting that the block map (or for that matter hole offset map)
has to be 
sent via READ output. That isn't necessarily the only way to do it. If
we are planning
to invent a new READ operation, then we might as well invent another
operation like
GET_SPARSE_BLOCK_MAP or GET_SPARSE_HOLE_OFFSET_MAP that gives the
information back
to the client.

Further, servers don't have to send the whole block map at the same
time. Clients
can just request the block map for the range it is interested in.

Second,

The fundamental premise of the proposal is that clients issue READ
requests serially on
a file (for a minute suppose vmdk as an example). You are hoping that
the each
preceeding READ request response shapes the subsequent READ requests. I
know that pNFS 
is an example that you addressed. But, even in non-pNFS case (consider
trunking), there 
is no guarantee that the client will rely on serialization of read
requests. So, 
the efficiency of the proposal does not fly. Thanks to your new error
code, 
servers don't have to send the data for the hole. But, clients in fact
will 
spend valuable resources in sending requests. Some of the efficiency is
lost due 
to aggressiveness of the client. This is purely becase, client does not
have the
bigger picture of the file.

Third,

In pNFS, the MDS owns the metadata. If I may, I consider the hole
information metadata.
Having a DS send the metadata information does not seem like a right
semantic to me.
I'm not even sure, if MDS would like to share this data with DS.

MDS owns the layout of the file. It must own the layout of the holes as
well. So, the
simpler and efficient way is to just get it directly from the MDS,
rather than have
the DS's communicate with MDS.

As a summary,

This proposal may be efficient for certain cases, but does not address
all cases.
Sending a block map still seems like a simpler proposal to me, that
would address
the cases not helped by this proposal:

1). Does not involve changing existing operations
2). Does not put onerous requirements on DSs'
3). Servers already have the maps available, clients 
    don't need to construct the maps based on the responses to READ.
4). The maps could be sent by the server for the interested range,
    Rather than the whole range.

- Pranoop

> Sent: Friday, October 01, 2010 3:58 PM
> To: Benny Halevy
> Cc: [email-masked]
> Subject: Re: [nfsv4] New version of sparse draft(draft-hildebrand-
> nfsv4-read-sparse-01.txt)
> 
> 
> 
> >>>> Yes, I agree, implementation work is needed either way, and
having
> a
> >>>> wanted to make it clear that a proposal is being made to
deprecate
> the
> >>>>> I tend to agree with others that it is likely best to introduce
a
> new
> >>>>> READ operation that
> >>>>> More generally, your draft does combine the idea of space
> allocated at
> >>>>> the server
> >>>>>
> >>>>> for the file with the method of effective transfer of data when
> zeros
> >>>>> or unallocated
> >>>>>
> >>>>> or uninitialized ranges exist.  It is fine to combine the two
> ideas in
> >>>>> the draft but
> >>>>>
> >>>>> a little more explicit language would be helpful (I will make
> some
> >>>>> suggestions offline).
> >>>>>
> >>>>>
> >>>>>
> >>>>> It may be helpful to combine the these READ hole ideas with
space
> >>>>> allocation
> >>>>> 1) Added section regarding pNFS (which basically states that
> there are
> >>>>> no real changes to how pNFS works)
> >>>>> flag instead of overloaded the length parameter, but I'm not
sure
> what

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Sat, 2 Oct 2010 16:11:22 -0400 (EDT)

> I'm not even sure, if MDS would like to share this data with DS.

If the system at hand happens to be organized in this way, sure.  The system I work with is not, and this approach seems much less natural, to me.

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sat, 2 Oct 2010 13:16:06 -0700

> From: Matt W. Benjamin [mailto:[email-masked]]
> Sent: Saturday, October 02, 2010 1:11 PM
> To: Erasani, Pranoop
> Cc: [email-masked]; Dean Hildebrand; Benny Halevy
> Subject: Re: [nfsv4] New version of sparsedraft(draft-hildebrand-nfsv4-
> read-sparse-01.txt)
> 
> 
> If the system at hand happens to be organized in this way, sure.  

However, pNFS specification does not preclude it to be organized that way
And I think that makes it to be a strong consideration for any proposal.

- Pranoop

> The system I work with is not, and this approach seems much less natural,
> to me.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 2 Oct 2010 16:35:51 -0400

Their current proposal is mainly just an optimization to allow returning
long strings of zeroes to clients in read requests.  (Servers may be
using file allocation information to identify long strings of zeroes
efficiently, but that's an implementation detail.)

This isn't about allocation, or metadata--it's just a minor incremental
improvement to READ.

The proposal decreases the size of read responses, and may decrease the
number of read requests as well in the case of a sequential reader.

As such, agreed: it doesn't allow a lot of optimizations that an
allocation map would.

It's also simpler than an allocation-map operation:

	- It's just a read, so we already know the semantics.
	- It never performs worse than ordinary read.

You may well be right that it simply isn't worth the trouble, whereas a
GET_HOLE_MAP operation would be.

But I think your proposal is sufficiently different that it should be a
separate proposal.  Beats me whether it would be a competitor to this
one, or complementary to it.

A few questions about a map:

	- What is its lifetime?  Will it be a recallable object like a
	  layout, or does the client invalidate it normally whenever it
	  would invalidate its data cache?
	- Does requesting the block map break write delegations, or (on
	  servers that support atime) update the atime?
	- How does a request for a map they interact with mandatory
	  locks?

--b.

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 3 Oct 2010 00:05:13 -0700

Bruce,

Thanks for getting back.

> This isn't about allocation, or metadata--it's just a minor
incremental

That's one interpretation. But, having to deprecate READ to provide this
feature
doesn't seem like a minor feature to me.

I don't read it as just an optimization. The stated goal seems to be
applicable all kinds of access patterns (i.e., it doesn't mention that
the algorithm is efficient for sequential pattern only).

The document says:

   This document extends the NFSv4.1 protocol to support efficient
   reading of sparse files.  The number of sparse files is growing in
   the data center, most notably due to the increasing number of virtual
   disk images.  This simple extension provides an easy and efficient
   way for administrators to copy and manage these files without wasting
   disk space or transferring data unnecessarily.

> As such, agreed: it doesn't allow a lot of optimizations that an

Great. We agree on the first point.

> one, or complementary to it.

I started with an intent to complement it, as I didn't see that the
current
proposal addresses many cases that I list below.

Basically, What are the requirements that we are trying to address with
this
proposal and what can we do to complete it to be beneficial to wider
range of
clients and servers.

> A few questions about a map:

Thanks for asking the questions.

I didn't myself think through the semantics of the hole map. So,
let's put the below questions in abeyance for a minute and address
my questions about requirements for the proposal by Dean. I promise
to come back with answers once I see that there is some direction on
whether the requirements need to be extended or whether another proposal
is warranted.

> 	  would invalidate its data cache?

For now, I feel that it has to be the latter. Similar to ctime
invalidation 
that this proposal warrants.

- Pranoop

---

From: James Lentini <[email-masked]>
Date: Sun, 3 Oct 2010 11:53:27 -0400 (EDT)

> are two different things.

WRITEZ sounds just like the HOLE_PUNCH operation described here:

http://tools.ietf.org/html/draft-iyer-nfsv4-space-reservation-ops-01

---

From: <[email-masked]>
Date: Sun, 3 Oct 2010 12:08:03 -0400

> Therefore, the only way for us to benefit from a new operation 
> is if every client in existence stops using READ and switches to 
> use the new operation.  
 
If one client stops using READ, and takes advantage of the new
operation, there is a benefit.  The more clients that do that, the more
benefit, so the benefits are incremental.  Also, switching to the new
operation is not a benefit if you don't use the new data.
 
> implementors would be?  
 
Use the operation when it helps you.  
 
Also if it simplifies your implementation to only have a single
read-style operation, use it everywhere if you use it in some places.
 
Stop using READ? 
 
No.  It is not at as if we have a big need to get to a future v4.x in
which READ is mandatory-to-not-implement.  Keeping READ around is not a
big deal for servers.
 
We wanted a simple addition to the protocol, not to deprecate READ :)
 
So don't deprecate READ.  Saying READ++ has come nice new shiny features
that can help you is not exactly deprecating READ.  Saying "You
old-fashioned stick in the mud still using READ, get out of that v4.1
rut" would be deprecating READ.  I don't think we don't want to do that.
The only sense in which I would favor deprecating READ would be in
saying that future new functionality should not be added to it, even if
you somehow could fit it.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Hildebrand
Sent: Friday, October 01, 2010 4:02 PM
To: Spencer Shepler
Cc: [email-masked]
Subject: Re: [nfsv4] New version of sparse
draft(draft-hildebrand-nfsv4-read-sparse-01.txt)

	I tend to agree with others that it is likely best to introduce
a new READ operation that

	

allocated at the server

zeros or unallocated

ideas in the draft but

	a little more explicit language would be helpful (I will make
some suggestions offline).

space allocation

	controls provided to the client (allocate, release/trim, etc.).
Anyone else

We want to propose the FADVISE like operation mentioned in Mike's draft
at some point, this might be a good place for space allocation
information.
Dean

	Spencer

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Hildebrand
	Sent: Wednesday, September 29, 2010 4:41 PM
	To: [email-masked]
	Subject: [nfsv4] New version of sparse draft
(draft-hildebrand-nfsv4-read-sparse-01.txt)

	Hello,
	
	I uploaded a new version of our internet draft "Simple and
Efficient Read Support for Sparse Files".

	
	The main changes are:
	1) Added section regarding pNFS (which basically states that
there are no real changes to how pNFS works)
	2) Added example sparse read message flow
	3) Added statement to the effect that if a client sends a read
request for a chunk that ends in zeroes, the server can return a short
read (thanks to Benny)
	4) I didn't change the return value.  There was a suggestion to
use a flag instead of overloaded the length parameter, but I'm not sure
what this gives us (although it might be more clear in the doc)
	
	Dean

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sun, 3 Oct 2010 14:36:18 -0400

> doesn't seem like a minor feature to me.

I don't understand.

For one thing, we're unlikely to "deprecate read" any time soon,
regardless of what Dean says.  (See Dave Noveck's comment, for example.)

--b.