Messages in this thread |  | | | Date | Tue, 31 Jul 2007 17:16:27 -0400 | | From | Chuck Lever <> | | Subject | Re: request for patches: showing mount options |
| |
Miklos Szeredi wrote: >>>> After a successful mount, the NFS mount command tucks some options into >>>> /etc/mtab that reflect which mountd was used for the mount, and what >>>> protocol version and port was used for the mount request. Those options >>>> are not passed to the kernel, and do not appear in /proc/mounts today. >>>> See nfs(5)'s discussion of the mountport, mounthost, mountprog, and >>>> mountvers options. >>>> >>>> However, the trend for NFS is to push mount option parsing into the >>>> kernel. Thus all options will be passed to the kernel, and at that >>>> point it should be able to reflect the mount* options in /proc/mounts. >>>> But it doesn't do that quite yet. >>> Trond, do you have a roadmap for this? >> Well I'm actually doing the coding, and Trond is playing more of an >> architectural role. > > OK, what your estimage for this then?
I don't have an estimate. This is all very slippery because once I get into a part of the code, we discover a lot of issues that we didn't expect. The NFS mount stuff is largely historical; we've all forgotten (or never really knew) how it works.
> It would be nice to have all this stuff in 2.6.24, which doesn't leave > a lot of time.
Yes, that would be nice, but there's a lot of stuff that needs to get done before this. NFS IPv6, for example, is a higher priority than refactoring to remove /etc/mtab -- the US government has a new requirement in 2008 for IPv6 support in any software that it purchases, and NFS may be a stumbling block for distributors if it doesn't have it.
So I'd say "no way" for 2.6.24, but it's really Trond's call to make.
> But if it's just those four options you mentioned, it should be > managable. I do not think there needs to be some generic code to > hande userspace-only options, it would be perfectly fine just to > parse, store and show them like all the other options.
Like you, I don't expect it will be difficult to implement, but I have too many balls in the air to make any promises at the moment. Plus, we can't really predict when distributors will feel the in-kernel mount parsing stuff will be ready for their users. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE url:http://oss.oracle.com/~cel version:2.1 end:vcard
|  |