runtime nfs mount options for existing mounts

Bruce Evans brde at optusnet.com.au
Sat Jan 29 04:46:37 UTC 2011


On Fri, 28 Jan 2011, Rick Macklem wrote:

>> How would I find out about the current mount options for an existing
>> NFS
>> mount on an NFS client?

> I don't think you can get this stuff out of the FreeBSD kernel right now.
> (I was hoping someone else was going to answer, but no one did:-)
>
> As to whether or not it should, I think it would be a nice feature, but
> I've got a lot of other stuff on my plate right now.
>
> I think it would take some sort of extension to the nmount(2) syscall or
> maybe a new syscall + noew VFS_xxx() op.

nmount() doesn't do this.  It only mounts, and only copies out error
messages.  (Despite having a horrible uio interface, it never uses uiomove()
and uses copyin() to fetch its args).

> I can say that, if someone else came up with the syscall/VFS changes, I
> could easily implement a function in the NFS client that generates the
> name/value pairs like nmount() uses. (There is currently a function that
> basically does that for the old mount() and I think a slightly modified
> version of that would do it. However, I haven't actually tried it.:-)

Old mount(2) doesn't do this.  All mount(8) just use statfs(2).  statfs()
just returns the old mount flags and a couple of other broken things
(async and sync i/o counts) that are used mainly by mount -v.

> Anyone feel like an nmount() related project to do this?

Hopefully statfs(2) would not become as horrible as nmount(2).  statfs()
wants to return a fix-ed size structure.  Fix-size structs and a limited
set of flags options are much easier to work with than strings.

Despite, or because of its horribleness, nmount(2) still can't handle
basic parsing like "-u -o current,..." or "-o fstab,...", or support
userland parsing of "-o current", and and has horrible messes for
parsing negative options.  Such parsing belongs in userland where it
was (although "-u -o current" has never really worked, for the same
reason that "mount -v" has never really worked -- there is no way to
determine mount options from userland except for ones in statfs()'s
flags.  However, the kernel knows all the current mount options and
could support "-u -o current,..." if it had any clue about parsing.
That alone wouldn't be very useful though, since parsing of fstabs
clearly belongs in userland only, and the userland parser needs to
handle "-o current" too, to properly merge it with "-o fstab" and other
options (in any order, with cancellations...).

This shows that no parsing in the kernel for nmount() is useful.  Once
all the current options are exported to userland, for printing in mount
-v and merging with "-o current", the userland parser needs to understand
the format of _all_ of them well enough merge them with other command-line
options.  The format cannot be completely-free-format strings, like
nmount() can handle now if it has parsing code for a "free" format
somewhere.  The merge also requires userland knowing a complete list
of options for the current file system (since for example, the absense
of a positive option should be equivalent to the presence of the
corresponding negative option.  nmount() has had mounds of bugs from
getting this wrong for the absent "rw" option being equivalent to a
present "noro" and not having a flag to distinguish between an absent
"rw" and a present "noro").  Once userland understands the format, it
can do all the parsing and present the results to the kernel in a
canonical form so that the kernel doesn't need to do much parsing
(e.g., it doesn't need to convert "nonofoo" to the absense of "foo",
or worry about N-tuple negatives, or discard duplicates, or cancel
"foo" with "nofoo"...

Instead of the uio interface for nmount(), I would have used a single
string, with contents like a mount(8) command line with 1 single space
as the only field separator.  The general case would be hard to parse,
but pre-parsing by mount utilities would give a canonical form and
could use special field separators if the space field separator turns
out to be a problem.  The string passed by the mount utilities must
contain all the options that don't have their default settings, since
it is all that will come back for mount -v to prettyprint and mount
-o -current to reparse.  Hopefully, sysctls are enough for retrieving
the current options and the supported options and their default
settings.

All of this could be done more easily and hackishly by a utility like
nfsstat doing lots of sysctls to retrieve the options.  It's a bit
surprising that nfsstat doesn't already do this, since nfs has more
nonstandard options than most file systems, and many of them can already
be determined without the kernel having any way to report them directly,
by watching network statistics.  (I often get confused by messing up
the tcp/udp option and r/wsize options and looking at network statistics
is the only way that I know of of determining what I mis-set them to.)

Bruce


More information about the freebsd-fs mailing list