From owner-freebsd-fs@FreeBSD.ORG Sat Apr 30 12:18:33 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 29804106566B for ; Sat, 30 Apr 2011 12:18:33 +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 DC7008FC12 for ; Sat, 30 Apr 2011 12:18:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAG/9u02DaFvO/2dsb2JhbACEUaI9iHGpPpAkgSqDVYEBBI55jj4 X-IronPort-AV: E=Sophos;i="4.64,292,1301889600"; d="scan'208";a="120007074" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Apr 2011 08:18:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CAEC6B3F22; Sat, 30 Apr 2011 08:18:31 -0400 (EDT) Date: Sat, 30 Apr 2011 08:18:31 -0400 (EDT) From: Rick Macklem To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Message-ID: <410050117.807767.1304165911685.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <86r58kfndu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] 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: Sat, 30 Apr 2011 12:18:33 -0000 > Rick Macklem writes: > > 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. > > I've seen some pxeboot-related weirdness with the new code... > > Server: ds4.des.no, amd64, FreeBSD 9.0 r221100 > Client: via.des.no, i386, FreeBSD 9.0 r221205 > > (both with mods, but none that would affect NFS) > > Note that they conveniently bracket the switch - the server runs the > old > NFS code while the client runs the new. > > Booting a customized kernel with the new NFS stack results in a weird > error message from mountroot: > > Trying to mount root from nfs:ds4:/jail/via [rw]... > mountroot: waiting for device ds4:/jail/via ... > Mounting from nfs:ds4:/jail/via failed with error 19. > Trying to mount root from nfs: []... > NFS ROOT: 10.0.0.4:/jail/via > > (error 19 is ENODEV) > I always get this error and got it even before I did the switch, I think? It's caused by vfs_mountroot_parse() finding an entry in the fstab, which then calls parse_mount(). Basically anything that specifies a non-NULL "dev" argument is going to fail for NFS. (See the "waiting for device ds4:/jail/via" which indicates "dev" is set to that. The failure and error message is because parse_mount_dev_present() can't find a device file called "ds4:/jail/via", which it shouldn't be able to. I can't see anything that would have skipped doing this before the switchover? I don't think my changes made this any different. So, you didn't get this before you switched over? > Booting a customized kernel with the old NFS stack (and with > /etc/fstab > altered to list / as oldnfs instead of nfs) produces a slightly > different result: > > Trying to mount root from oldnfs:ds4:/jail/via [rw]... > mountroot: waiting for device ds4:/jail/via ... > Mounting from oldnfs:ds4:/jail/via failed with error 19. > Trying to mount root from nfs: []... > Mounting from nfs failed with error 2: unknown file system. > > Note that after the first attempt fails, it tries again with "nfs" > instead of "oldnfs". If I type "oldnfs:" at the mountroot prompt, I > get: > > Trying to mount root from oldnfs: []... > NFS ROOT: 10.0.0.4:/jail/via > You can get around this by putting a line like: vfs.root.mountfrom="oldnfs:" - in the boot/loader.conf on the root fs in the server. It will then use "oldnfs:" instead of the default "nfs:" (which is hardwired by setting rootdevnames[0] to it). > The rc scripts also get confused because they think the NFS client > code > is not loaded, and try to load it again, leading to the following > kernel > error message: > > interface oldnfs.1 already present in the KLD 'kernel'! > > accompanied by a message from the script itself: > > /etc/rc: WARNING: Unable to load kernel module nfsclient > Ok, I'll need to look at this. At a glance, I see a load_kld, but that won't get upset if it's already loaded. (It does need to be fixed, though, since it refers to nfsclient as the module for "nfs" instead of nfscl.) > So there are (at least) two kernel issues: > > 1) the "error 19" that occurs with both the old and the new stack > I don't know if this is considered a bug or a feature, but I think it has been there for a while and happened before the switchover. If you could test a pre-switchover (but recent) client and see if the message shows up, that would be appreciated. > 2) the fallback that always uses "nfs" instead of using the correct > fstype for whichever NFS stack is loaded. > The default is changed via the vfs.root.mountfrom="oldnfs:" line added to boot/loader.conf on the root fs on the server. That is mentioned in UPDATING. Thanks for pointing these out, rick