Re: request for patches: showing mount options

Chuck Lever
2007-07-31T21:17:23Z

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

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.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

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