Date: Fri, 15 Apr 2011 07:04:35 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one Message-ID: <20110415140435.GA4278@icarus.home.lan> In-Reply-To: <1369404502.72409.1302871750151.JavaMail.root@erie.cs.uoguelph.ca> References: <1369404502.72409.1302871750151.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: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).
NFS, as I'm sure you know, is one of those things where if you break it
people get *very* (rightfully) upset. NFS breakage is one of the
reasons I moved away from Linux back in the mid-to-late-90s (true). The
last thing I need is to upgrade our FreeBSD-based filer to find that
while I'm sleeping NFS suddenly behaves oddly or breaking (either on our
clients or the server).
The reason I haven't tried the experimental NFS server is simply because
I have absolutely no idea what the improvements are; no documentation +
no incentive = no try. :-) The man page for nfsd(8)'s -e flag tells me
nothing more than it's "experimental code" and adds NFSv4 support (the
latter does not interest me).
Stuff that concerns me the most (for our environment):
- Works properly when used with PXE booting and an NFS-based install
(e.g. a new 8.2-RELEASE box is being built/installed via serial
console and PXE that mounts an NFS filesystem for installation data;
will this work if the NFS server is running this experimental
code?). I remember you mentioning something to me a long time ago,
and I'm almost certainly remembering it wrong, about how the PXE boot
client (/boot/pxeboot) on FreeBSD uses a very old version of the NFS
protocol.
- Works properly when used with *very* old FreeBSD clients. How old?
I'm talking 6.4-STABLE old. Yes, we do in fact have boxes that old
that are in production.
- Works exactly the same, configuration and performance-wise, as the
existing (non-experimental) code. Focusing on NFSv2 and NFSv3 here,
specifically UDP (the default). NFSv4 does not matter to us in any
way shape or form.
- Has the experimental code been stress-tested? If so, how? I've heard
of people doing silly things like testing with filesystem benchmark
utilities -- which pass/work fine, but the instant someone tries
using something like rsnapshot (like we do), the thing falls apart.
I'm concerned greatly about things like the kernel "deadlocking" (alive
but isn't actually responsive to a lot of things), unkillable processes,
processes stuck in bad states due to NFS oddities, or abysmal
performance.
My intent here is not to sound overly critical, but critical enough to
make sure you triple-check all your ducks are in a row. :-)
--
| 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?20110415140435.GA4278>