Date: Sat, 29 Jan 2011 15:46:32 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD FS <freebsd-fs@FreeBSD.org> Subject: Re: runtime nfs mount options for existing mounts Message-ID: <20110129144348.T967@besplex.bde.org> In-Reply-To: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca> References: <496514462.1056535.1296256105160.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110129144348.T967>