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

[Dean Hildebrand <[e-mail]>]

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]] *On 
> Behalf Of *Dean Hildebrand
> *Sent:* Wednesday, September 29, 2010 4:41 PM
> *To:* [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
>