Date: Wed, 6 Feb 2008 18:27:14 -0500 (EST) From: Mike Andrews <mandrews@bit0.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-stable@freebsd.org Subject: Re: mount -p and NFS options Message-ID: <20080206181744.J36631@mindcrime.int.bit0.com> In-Reply-To: <20080205192830.GB17472@dan.emsphone.com> References: <20080204230945.J49853@mindcrime.int.bit0.com> <20080205192830.GB17472@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Feb 2008, Dan Nelson wrote: > In the last episode (Feb 04), Mike Andrews said: >> Is there anything like "mount -p" that will print the current NFS >> options in use? TCP vs UDP, v2 vs v3, read/write sizes etc. It >> doesn't have to be in fstab format; I just need to be able to see >> what the flags are for an active mount. >> >> This would be useful in tracking down an irritating NFS problem I've >> been experiencing with diskless systems in every 6.x release and >> 7.0-RC1, namely libc.so.6 appears to be truncated or corrupt to the >> client at somewhat random times... I think it may be related to >> mount options, hence the question. > > Theoretically, any filesystem that uses nmount(2) should have its > options recored in an easy-to-extract format, since one of the > arguments to nmount is an array of options. I patched my kernel and > /sbin/mount binary to do this (borrowing the f_charspare field in > struct statfs), and it mostly works. The stuff below in <> brackets > are from the options array. You can see that cd9660 was mounted with > the option "ssector=0": > [snip] > Unfortunately, mount_nfs simply calls nmount with a single "nfs_args" > option whose value is the same binary "struct nfs_args" it used to call > mount(2) with :( The fix would be to make nfs_vfsops.c and mount_nfs.c > use the options array instead of a custom struct, but > nfs_vfsops.c:nfs_decode_args scares me off every time I look at it. Hm. Well, that's a bummer. But it at least told me where to hack in some temporary printf() calls, and that helped me narrow my immediate problem down to the rsize/wsize parameters. My problem was, on a diskless 7.0-RC1 system, trying to compile anything resulted in ld SIGSEGV'ing. With diskless 6.3 ld said that libc.so.6 was truncated. ktrace hinted that 7.0's ld crash was right after reading libc.so.7 so it's probably the same issue -- problems reading libc. The problem goes away if I change rsize/wsize from 32K down to 16K or the default 8K, at least with TCP mounts. So for now in /boot/loader.conf I'm using boot.nfsroot.options="nfsv3 tcp rsize=8192 wsize=8192". (NFS options for the root filesystem in fstab seem to be ignored.) I don't know why it was libc consistently getting misread and why other files seem to always work, or why mounting other NFS filesystems with a 32K blocksize work fine... unless I'm hitting some edge case that's specific to NFS root vs NFS anything-else. Anyway, I've got a workaround for now. (FWIW, this happened with two different machines, one with an msk NIC and one with an em NIC, neither of which have jumbo frames enabled.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080206181744.J36631>