From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:32:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336A21065673 for ; Sun, 12 Sep 2010 15:32:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E4BB58FC0A for ; Sun, 12 Sep 2010 15:32:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFmPjEyDaFvO/2dsb2JhbACDGZ8frC6QYoEigyp0BIon X-IronPort-AV: E=Sophos;i="4.56,355,1280721600"; d="scan'208";a="93596759" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Sep 2010 11:32:17 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 252E0B3F39; Sun, 12 Sep 2010 11:32:17 -0400 (EDT) Date: Sun, 12 Sep 2010 11:32:17 -0400 (EDT) From: Rick Macklem To: Tim Kientzle Message-ID: <1596813331.782431.1284305537136.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 15:32:18 -0000 > On Sep 11, 2010, at 5:26 PM, Rick Macklem wrote: > >> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: > >> > >>> You can also look in /var/log/messages to see if any of the > >>> daemons > >>> are complaining about something. > >> > >> Only warning I see on a system reboot is: > >> nfsd: can't open /var/db/nfs-stablerestart > >> > >> Creating this file and then rebooting the system seems to get > >> things > >> working. > >> > >> This file certainly wasn't required by the old nfsd. > >> Should this file be created by /etc/rc.d/nfsserver at boot time (if > >> it > >> doesn't exist)? > >> Or should it be created by installworld? > >> > > Technically, it should only be created for a fresh install on a disk > > that has never been set up before. (ie. Not on an update/upgrade > > unless it has never existed before.) > > .... > > As such, I just documented it in "man nfsv4" for now, > > This is going to bite people on upgrades since > the old server didn't require this file, so people > upgrading from the old nfsd are going to hit > this problem pretty consistently. > > I'd like to at least consider alternatives to the > current behavior; maybe one of the following? > * If the file doesn't exist on startup, create it > and warn loudly. > * Similar to isc-dhcp, periodically make a > a backup copy of the file and only create a > fresh blank one if the file and backup are > both missing. I think this might be a reasonable compromise. The kernel can signal the master nfsd (which remains in userland) to copy the file to a backup after it has been updated, then the backup can be used if the regular one is lost/corrupted. If neither exists, creating new ones seems reasonable. Other opinions? rick > * "make installworld" is certainly capable > of creating this file only if it doesn't already > exist. (That doesn't cover the binary > update case, of course.)