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

On 10/1/2010 3:49 PM, Benny Halevy wrote:
> 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.

Exactly, I want everyone to realize the fact that we are on the road to 
obsoleting READ.
Dean

> 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