Date: Fri, 15 Apr 2011 20:57:00 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one Message-ID: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110415140435.GA4278@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > 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.) > 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). > 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.) > 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. > Well, I've PXE booted from it using the old pxeboot code that used NFSv2 and the recent code that I modified to use NFSv3. I don't see why there would be a problem, but obviously I can't guarantee that. > - 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. > As noted above, I have used it with a FreeBSD4.6 client, but I don't have any old FreeBSD systems to test against any more. > - 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. > I believe it will, but can't say it will. > - 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. > Well, all I have access to these days are two laptops and one old desktop system. Someone was going to look at trying it in FreeBSD's network perf cluster, but I don't know if that has happened. I have heard some positive reports from others, but... As noted above, I did run an earlier version of the server in production mode when I first ported it to FreeBSD and it handled the loads we had well, but that's a long time ago. 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. > 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. :-) > Well, I can't think of more that I can do than answer, as above.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1924310048.124584.1302915420741.JavaMail.root>