mount -p and NFS options

[Mike Andrews]

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.)