Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Apr 2011 20:45:07 -0700
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: RFC: make the experimental NFS subsystem the default one
Message-ID:  <20110418034507.GA63656@icarus.home.lan>
In-Reply-To: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca>
References:  <20110415140435.GA4278@icarus.home.lan> <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 15, 2011 at 08:57:00PM -0400, Rick Macklem wrote:
> > 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.
> 
> Well, if you mean source code changes, I can't think of how I could
> come up with this. The experimental
> NFS implementation is based on work I started in 2003 and is a separate
> implementation from the other one in FreeBSD, so I can't produce any
> kind of "log" of changes for it. (I started from the code in OpenBSD2.6,
> but there would be very little of that code left at this point.)
> 
> I can tell you that, as far as I know, it supports NFSv2 and NFSv3 in
> the same way the other/regular server does. (There might be an obscure
> case where it returns a different errno for some failure or similar,
> but nothing that I am aware of.) I ran it in production mode for a few
> years, where the clients were mostly Linux 2.4 and 2.6 systems, plus a
> FreeBSD4.6 system and didn't see issues when they used NFSv3 mounts.
> 
> I would like to think that folks won't notice anything when they switch
> over, but I am not nieve(sp?) enough to believe no one will find problems with it.
> 
> The one area that is different is what nfsstat reports, since the "-e" version
> includes extra information. If that causes difficulties for folks, it
> should be possible to implement a "old nfsstat -s" compatible output that
> just reports the same information as "nfsstat -s" does now.

Here's a better way to phrase what I'm requesting:

You're announcing to people "Hey! What do you think about me making the
experimental server the default?" yet nobody knows what the experimental
server does differently (for better or worse) than the non-experimental
server.  Documenting the differences -- not on a source code level -- is
what I'm asking for.  Without those differences (improvements, etc.)
then I have absolutely no inclination to try something that's labelled
"experimental" when the author cannot explain (or advocate) *why*
someone should change to it.  :-)

I think you might answer the question of what's changed further down in
your Email however.

> > 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).
> > 
> I can't think of a good answer for this, either, because it depends
> upon what "wonky" means. I don't think it's much different than any
> other issue that shows up in freebsd-current (or freebsd-stable or
> freebsd-fs) or a PR? (Then add the "-o" option to flip back to the
> old server until the problem gets resolved.)

I'm willing to slide on this one, but I'm mainly referring focused on
situations where nfsd can't be killed, or the kernel "deadlocks" (is
alive/NumLock works/etc. but is wedged).

I'm a little surprised that you didn't say "procstat -kk would be a good
start".  :-)

> Well, about the only improvement is NFSv4, so for you there is no incentive
> at this time. Hopefully you may find the better file locking, ACLs etc that
> NFSv4 offsers useful improvements someday.
> 
> It does have a rather novel DRC (duplicate request cache), which I believe
> works better, particularily when clients use TCP, but I can't say that
> you'll see a noticible change because of this. (Maybe less mbuf hungry
> compared to the generic one in the FreeBSD8 krpc.)

Okay, so there's two items for the list: NFSv4 support (which offers
improved locking and a better ACL model), and use of a duplicate request
cache which can (ideally) help improve performance for TCP clients.

This is the kind of stuff I'm looking for, and I imagine a lot of others
are too.

It sounds like NFSv2 and NFSv3 are basically untouched (no direct
changes to them, but probably some indirect changes), I'm willing to
switch over to using -e on our production cluster, while keeping the
clients using mount_nfs *without* -o nfsv4.

> ...
>
> One of the reasons that I was encouraged to suggest this is to get it
> more widely tested. I can only do so much in this regard and that has
> already happened. If others aren't willing to try and run it, it can't
> progress beyond where it is now.
>
> Maybe someone from Isilon could chime in with some information on what
> testing they've put it through, recognizing that their system is
> significantly different and without giving out any information that
> they would consider proprietary?
> 
> Again, I can't guarantee there won't be a regression, but until others
> try to run it, I/we won't know.

I truly understand this situation, as it's been happening with all sorts
of features in FreeBSD for years now.  Change (or feature) X gets
introduced, it's a Good Thing(tm), but how do you get users to actually
test it?  When is it truly "safe" to commit it as the default?

I think the number of testers of the experimental server would increase
if, like I said, there was a concise list of what the actual differences
are between the non-experimental and experimental server.

Once that is written (the FreeBSD Wiki would be a perfect place for it)
and the URL disseminated, sending a mail to the lists (-fs, -stable,
-current, and maybe -net -- not sure of the last one) asking people to
test it would make most sense.  That's my view, anyway.

-- 
| Jeremy Chadwick                                   jdc@parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110418034507.GA63656>