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

["J. Bruce Fields" <[e-mail]>]

On Thu, Sep 30, 2010 at 12:23:56PM -0700, Dean Hildebrand wrote:
> 
> 
> On 9/30/2010 12:16 PM, J. Bruce Fields wrote:
> >On Thu, Sep 30, 2010 at 02:37:52PM -0400, J. Bruce Fields wrote:
> >>On Thu, Sep 30, 2010 at 11:22:34AM -0700, Dean Hildebrand wrote:
> >>>
> >>>On 9/30/2010 10:59 AM, J. Bruce Fields wrote:
> >>>>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
> >>>>>
> >>>>>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)
> >>>>How will the client take advantage of the data_length field?
> >>>I'm not 100% sure what you are asking, but all read requests into
> >>>the region specified by data_offset and data_length cannot be
> >>>assumed to be zero.  The data must come from either the client cache
> >>>or server.  The example was designed to answer this type of
> >>>question, does it help?
> >>I think I understand what data_offset *means*.  What I don't understand
> >>is how the client can use data_offset to improve performance.
> >Knowing that there may be nonzero values in the range
> >[data_offset,data_offset+data_length] isn't very useful--you're still
> >going to have to perform reads to get the data in that range.
> >
> >The information that really *is* useful is the information that all data
> >in the range [read offset,data_offset] is zero.
> >
> >So data_length doesn't give the client any new information it can use.
> >
> >Simpler, I think, would be to either drop data_length entirely, or to
> >return a range describing the extent of the current *hole*, instead of
> >the extent of the next *non-hole*.
> >
> >And just write the spec to say that the server return means that a read
> >of the returned range would have returned all zeroes.
> 
> I think the original motivation was for the client to adapt its
> requests using this field, so it wouldn't try to read into a hole.
> So instead of reading 64K, which might go past
> data_offset+data_length, it simply reads the appropriate amount of
> data up until data_offset+data_length.  Now, the server can always
> return a short read, but that does put the onus on the server to do
> fine-grained checking of zero and non-zero data for every read
> request, which may be quite onerous.

I don't understand.  Either the server finds out where the holes are, or
it doesn't--up to it.  If it knows where they are, then returning a
short read isn't any more or less hard than returning the correct
data_length would have been on the earlier read.

Or it could also just return the zeroes at the end of the read that
crosses the beginning of the next hole.  That doesn't strike me as a big
problem.  The client will still find out about a hole on its next read.

But, sure, I can believe that the client aligning its reads to with
respect to the possible boundary at data_offset+data_length could have
some benefit, and I didn't understand that before--thanks for pointing
it out.

There's still some question to me how beneficial that really would
be....

> So I still think it has a
> purpose and should be kept in the draft.
> 
> btw, I like your comment regarding allocated and unallocated data.
> I'll use that as motivation and refer to zero and non-zero data in
> the protocol description.

OK, thanks.

--b.