From owner-freebsd-fs@FreeBSD.ORG Mon Apr 18 20:47:29 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 369361065670 for ; Mon, 18 Apr 2011 20:47:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 400D98FC0C for ; Mon, 18 Apr 2011 20:47:27 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKWirE2DaFvO/2dsb2JhbACET6FliG+rY4MKjWuBKYNOegSOAA X-IronPort-AV: E=Sophos;i="4.64,235,1301889600"; d="scan'208";a="117862747" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 18 Apr 2011 16:47:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 41A19B3F3E; Mon, 18 Apr 2011 16:47:27 -0400 (EDT) Date: Mon, 18 Apr 2011 16:47:27 -0400 (EDT) From: Rick Macklem To: Jeremy Chadwick Message-ID: <1065856259.239578.1303159647210.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110418040940.GA64222@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) 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 20:47:29 -0000 > On Sun, Apr 17, 2011 at 08:45:07PM -0700, Jeremy Chadwick wrote: > > 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. > > Well that didn't go well. Server is RELENG_8 dated Thu Feb 24 22:06:45 > PST 2011. rc.conf had the following: > > nfs_server_enable="yes" > nfs_server_flags="-e -u -t -n 4" > mountd_enable="yes" > You need the "-e" option on mountd as well. Running nfsuserd should be harmless, but you are correct that it is not necessary if the server will not be handling NFSv4 clients. > Note that I *did not* set nfsv4_server_enable="yes" because that > appears > to do > > mountd and nfsd were full stopped then started (in correct order). > nfsd > did not start, and this error was thrown on console: > > Apr 17 20:47:36 ra nfsd[23423]: Can't open /var/db/nfs-stablerestart > > Quickly digging through source introduced me to stablerestart(5), > which > states this: > > BUGS > If the file is empty, the NFS V4 server has no choice but to return > NFSERR_NOGRACE for all Reclaim requests. Although correct, this is a > highly undesirable occurrence, so the file should not be lost if at > all > possible. Nfsd will not create the file if it does not exist and will > simply log a failure to start, in the hopes that the file can be > recov- > ered from a backup. To move the file, you must edit the nfsd sources > and > recompile it. This was done to discourage accidental relocation of the > file. > > The first line of this BUGS section implies touch'ing the file is > insufficient. I was forced to review the source code to see what this > file contains/how it's maintained; it appears to store two raw > unsigned > 32-bit ints to the file, otherwise it throws error "Can't read stable > storage file" and exits. > > So how does one go about properly creating/initialising this file? And > what should the proper file perm/ownership be? > > My opinion is that the rc.d scripts need to somehow do this, but only > once. The nuances/complexities of this situation seem very high, as > blindly creating the (presumably 8-byte) file on startup (if it > doesn't > exist) doesn't sound like it's the correct solution. > The code in head no longer needs this. The nfsd now manages a backup copy of the file and creates them, as required. With the older code the file must be created as an empty file owned by root/wheel. This is explained in "man nfsv4", since I had assumed only folks who wanted nfsv4 would be using the server while it was "experimental". For example: # install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart - should do it (done as su, of course) > Also, the nfsd(8) man page needs to list stablerestart(5) in its SEE > ALSO section. > Agreed. I'll patch it.