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

On 2010-10-02 00:15, Dean Hildebrand wrote:
> 
>>> 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'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....
> 

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

> Dean
>> Benny
>>
>>> I would like everyone on board with that and not have it used as an
>>> excuse for rejection.
>>> Dean
>>>
>>>> Spencer
>>>>
>>>> *From:* Dean Hildebrand [mailto:seattleplus@gmail.com]
>>>> *Sent:* Friday, October 01, 2010 1:02 PM
>>>> *To:* Spencer Shepler
>>>> *Cc:* nfsv4@ietf.org
>>>> *Subject:* Re: [nfsv4] New version of sparse draft
>>>> (draft-hildebrand-nfsv4-read-sparse-01.txt)
>>>>
>>>>
>>>> On 10/1/2010 9:38 AM, Spencer Shepler wrote:
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>>> 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?
>>>>
>>>> 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:* nfsv4-bounces@ietf.org<mailto:nfsv4-bounces@ietf.org>
>>>> [mailto:nfsv4-bounces@ietf.org] *On Behalf Of *Dean Hildebrand
>>>> *Sent:* Wednesday, September 29, 2010 4:41 PM
>>>> *To:* nfsv4@ietf.org<mailto:nfsv4@ietf.org>
>>>> *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".
>>>>
>>>> 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)
>>>>
>>>> Dean
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>