RFC: make the experimental NFS subsystem the default one

[John Baldwin]

On Friday, April 15, 2011 10:04:35 am Jeremy Chadwick wrote:
> On Fri, Apr 15, 2011 at 08:49:10AM -0400, Rick Macklem wrote:
> > I think that the experimental NFS server is now ready for generic use
> > and that the experimental NFS client will be soon, after some commits
> > over the next week or so.
> > 
> > How do folks feel w.r.t. making these the default?
> >
> > My plan is to make the server the default first (the "-e" option on
> > mountd and nfsd would become a no-op) and a new option on mountd and
> > nfsd ("-o" sound ok?) would be needed to run what is currently the
> > regular server. (I am not proposing taking out the regular client/server
> > at this time, simply making them the non-default ones.)
> > 
> > For the client, "newnfs" would become "nfs" and what is now "nfs"
> > would become "oldnfs" for file system type. (This wouldn't happen
> > until a series of commits bring "newnfs" in line with "nfs" for
> > various things, including default mount options, plus diskless
> > booting for NFSv3 gets fixed.)
> > 
> > So, comments w.r.t. this would be appreciated, rick
> 
> I can't speak for others, but I would feel much more comfortable if a
> well-written and verbose document/web page was put up somewhere with a
> full, concise list of what the changes are.  Additionally, documentation
> stating *exactly* what to do / provide you in the case something starts
> acting wonky would be highly beneficial (commands, kernel stuff,
> whatever would help you in troubleshooting).

Short version:

1) It needs testing before 9.0 is released and the only real way to get that 
is to change the default.  Users will generally not go try something new until 
the default changes.  It can always be reverted before 9.0 is released if it 
blows up for some reason.

2) The old NFS code is a PITA.  I can sum it up with "goto's from one macro 
that jump to a label defined in another macro".  If you understand C at all, 
that should make you cry.  (Thankfully, the second macro was retired a few 
years ago and all the 'nfsmout' labels are now explicit, but things like 
nfsm_request() still jump to a random label not defined in the macro on error, 
meaning all NFS functions have to have a single exit point, etc.)

3) NFSv4 does really matter for several folks, and it will continue to matter 
in the future.  You will certainly care about it once it is performant as it 
offers far better cache consistency and the chance at far better use of 
locally cached data than NFSv2/3.

-- 
John Baldwin