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

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

On Fri, Oct 01, 2010 at 05:23:18PM +0200, Benny Halevy wrote:
> On 2010-10-01 16:36, 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
> > 
> > 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.
> 
> 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.