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

sorry, nfsv4@ietf.org list fu again :-/

-------- Original Message --------
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)
Date: Fri, 01 Oct 2010 18:01:43 +0200
From: Benny Halevy <bhalevy@panasas.com>
To: Marc Eshel <eshel@almaden.ibm.com>
CC: J. Bruce Fields <bfields@fieldses.org>,  nfsv4@ietf.org <nfsv4@ietf.org>

On 2010-10-01 17:49, Marc Eshel wrote:
>   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.

The main problem is that you return an error for a non-error case.
No only this short-circuits COMPOUND handling, it complicates
the client's error handling code.

Returning this information as part of READ[XYZ]4resok will be a
much cleaner solution.

Benny

> 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.)READ4resok
>>
>> (Maybe that one would need a "Y" in the name.)
>>
>> --b.
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
> 
> 