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

  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:
> 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.
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>