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

[Dean Hildebrand <[e-mail]>]

On 10/1/2010 1:07 PM, Spencer Shepler wrote:
>
> Dean,
>
> To the question of adding a new operation.  I am not sure I see the 
> burden or cost
>
> in the same way as you state.  The semantics of READ would change (old 
> or new
>
> operation) and the clients would need to be updated to deal with the 
> new semantics
>
> to take advantage of the functionality; therefore, there is 
> implementation burden
>
> in either path.  One advantage of a new operation is the clarity to 
> the server in which
>
> semantics the client is interested.
>
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 would like everyone on board with that and not have it used as an 
excuse for rejection.
Dean

> Spencer
>
> *From:* Dean Hildebrand [mailto:[e-mail]]
> *Sent:* Friday, October 01, 2010 1:02 PM
> *To:* Spencer Shepler
> *Cc:* [e-mail]
> *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:* [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] *On Behalf Of *Dean Hildebrand
> *Sent:* Wednesday, September 29, 2010 4:41 PM
> *To:* [e-mail] <mailto:[e-mail]>
> *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
>
>