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

[<[e-mail]>]

> 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 one client stops using READ, and takes advantage of the new
operation, there is a benefit.  The more clients that do that, the more
benefit, so the benefits are incremental.  Also, switching to the new
operation is not a benefit if you don't use the new data.
 
> So with a new operation, I'm just not sure what the guidance to 
> implementors would be?  
 
Use the operation when it helps you.  
 
Also if it simplifies your implementation to only have a single
read-style operation, use it everywhere if you use it in some places.
 
Stop using READ? 
 
No.  It is not at as if we have a big need to get to a future v4.x in
which READ is mandatory-to-not-implement.  Keeping READ around is not a
big deal for servers.
 
We wanted a simple addition to the protocol, not to deprecate READ :)
 
So don't deprecate READ.  Saying READ++ has come nice new shiny features
that can help you is not exactly deprecating READ.  Saying "You
old-fashioned stick in the mud still using READ, get out of that v4.1
rut" would be deprecating READ.  I don't think we don't want to do that.
The only sense in which I would favor deprecating READ would be in
saying that future new functionality should not be added to it, even if
you somehow could fit it.
 
 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Dean Hildebrand
Sent: Friday, October 01, 2010 4: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]] 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