From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 03:45:09 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4C58106566C for ; Mon, 18 Apr 2011 03:45:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 88CED8FC14 for ; Mon, 18 Apr 2011 03:45:09 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Yr3x1g0051eYJf8A9rl9i6; Mon, 18 Apr 2011 03:45:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id Yrl81g00B1t3BNj01rl87b; Mon, 18 Apr 2011 03:45:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F2AA69B42B; Sun, 17 Apr 2011 20:45:07 -0700 (PDT) Date: Sun, 17 Apr 2011 20:45:07 -0700 From: Jeremy Chadwick To: Rick Macklem Message-ID: <20110418034507.GA63656@icarus.home.lan> References: <20110415140435.GA4278@icarus.home.lan> <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1924310048.124584.1302915420741.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: RFC: make the experimental NFS subsystem the default one X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 03:45:09 -0000 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 |