Date: Mon, 18 Apr 2011 16:47:27 -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: <1065856259.239578.1303159647210.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20110418040940.GA64222@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1065856259.239578.1303159647210.JavaMail.root>