NFSv4.1 (DEVELOPER ONLY)

[Steve Dickson]

I just noticed NFSv4.1 is set to "DEVELOPER ONLY" in the
mainline kernel and I wonder if there an guess as to when 
this will be moved "EXPERIMENTAL"? 

I was hoping to enable this in upcoming Fedora Development 
builds so we can get a broader base of testing but I'm a bit 
hesitant with it being a "DEVELOPER ONLY"...

Although, I have done (and will continue to do) regression testing 
with this enable and have seen any problems, plus this new code 
does not even come into play unless the mount command explicitly as
for it (ala -o minorversion=1) on v4 mounts... which seems to be
fairly stable... 

steved.

[pnfs] NFSv4.1 (DEVELOPER ONLY)

[William A. (Andy) Adamson]

I think NFSv4.0 should be moved from EXPERIMENTAL before NFSv4.1 gets
moved from DEVELOPER -> EXPERIMENTAL!

What is left to do in NFSv4.0 to allow this to happen?

-->Andy

On Mon, Aug 17, 2009 at 9:49 AM, Steve Dickson<SteveD(a)redhat.com> wrote:
>  I just noticed NFSv4.1 is set to "DEVELOPER ONLY" in the
>  mainline kernel and I wonder if there an guess as to when
>  this will be moved "EXPERIMENTAL"?
>
>  I was hoping to enable this in upcoming Fedora Development
>  builds so we can get a broader base of testing but I'm a bit
>  hesitant with it being a "DEVELOPER ONLY"...
>
>  Although, I have done (and will continue to do) regression testing
>  with this enable and have seen any problems, plus this new code
>  does not even come into play unless the mount command explicitly as
>  for it (ala -o minorversion=1) on v4 mounts... which seems to be
>  fairly stable...
>
>  steved.
>
>  _______________________________________________
>  pNFS mailing list
>  pNFS(a)linux-nfs.org
>  http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
>

[pnfs] NFSv4.1 (DEVELOPER ONLY)

[J. Bruce Fields]

On Mon, Aug 17, 2009 at 12:19:27PM -0400, William A. (Andy) Adamson wrote:
>  I think NFSv4.0 should be moved from EXPERIMENTAL before NFSv4.1
> gets
>  moved from DEVELOPER -> EXPERIMENTAL!
>  
>  What is left to do in NFSv4.0 to allow this to happen? 
Todo's I know of that should probably be fixed first:

	- on the client side (we probably want to move client and server
	  out of experimental at roughly the same time, if possible?)
	  there's the mount negotiation to finish.  Steve intends his
	  mount configuration stuff to be a first step.
	- server-side exports coordinated with v2/v3: I need to take a
	  day or two to think about Steve's patches.  Will do that soon!
	- server-side reboot recovery code: the other kernel people
	  really hate the current v4 recovery code, and it has indeed
	  been a generator of weird bugs.  I tried to pick this up early
	  this week and write down a basic design, then got distracted.
	  Would like to get this fixed sooner rather than later just
	  because it will likely be a backwards-incompatible change,
	  hence easier to do while there are fewer users.
	- proper delegation enforcement: currently e.g. if you edit a
	  delegated file with a text editor, delegation-holding clients
	  don't get an update (because the server is not correctly
	  breaking leases on rename/unlink).  I have a patch series that
	  needs a few more bug fixes and some review.

Some other todo's I can think of that I'm not might also block
EXPERIMENTAL removal (but I'm not as sure):

	- Turn on 4.0 reply cache.  Theoretical problem, not sure if
	  we've seen it in practice.
	- Make sure deferrals don't replay non-idempotent operations.
	  (Neil is close to fixing this.)  Theoretical problem, not sure
	  if we've seen it in practice.

This is a little off the top of my head; anything I've forgotten?

--b.

[pnfs] NFSv4.1 (DEVELOPER ONLY)

[Steve Dickson]

On 08/17/2009 12:37 PM, J. Bruce Fields wrote:
>  On Mon, Aug 17, 2009 at 12:19:27PM -0400, William A. (Andy) Adamson
> wrote:
> > I think NFSv4.0 should be moved from EXPERIMENTAL before NFSv4.1 gets
> > moved from DEVELOPER -> EXPERIMENTAL!
> >
> > What is left to do in NFSv4.0 to allow this to happen?
>  
>  Todo's I know of that should probably be fixed first:
>  
>  	- on the client side (we probably want to move client and server
>  	  out of experimental at roughly the same time, if possible?)
>  	  there's the mount negotiation to finish.  Steve intends his
>  	  mount configuration stuff to be a first step. 
Which was committed...

>  	- server-side exports coordinated with v2/v3: I need to take a
>  	  day or two to think about Steve's patches.  Will do that soon! 
This has been
in Fedora's rawhide kernel since early July... with
now issues.. yet! ;-)

>  	- server-side reboot recovery code: the other kernel people
>  	  really hate the current v4 recovery code, and it has indeed
>  	  been a generator of weird bugs.  I tried to pick this up early
>  	  this week and write down a basic design, then got distracted.
>  	  Would like to get this fixed sooner rather than later just
>  	  because it will likely be a backwards-incompatible change,
>  	  hence easier to do while there are fewer users.
>  	- proper delegation enforcement: currently e.g. if you edit a
>  	  delegated file with a text editor, delegation-holding clients
>  	  don't get an update (because the server is not correctly
>  	  breaking leases on rename/unlink).  I have a patch series that
>  	  needs a few more bug fixes and some review. 
Are these in a bug report somewhere?
And it sound like that latter is
a bit more important than the former..

>  
>  Some other todo's I can think of that I'm not might also block
>  EXPERIMENTAL removal (but I'm not as sure):
>  
>  	- Turn on 4.0 reply cache.  Theoretical problem, not sure if
>  	  we've seen it in practice. 
Won't enabling nfs41 help with this?

>  	- Make sure deferrals don't replay non-idempotent operations.
>  	  (Neil is close to fixing this.)  Theoretical problem, not sure
>  	  if we've seen it in practice. 
So probably not a show stopper... 

steved.