From: Chuck Lever <chuck.lever@oracle.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kzak@redhat.com, sfrench@samba.org, trond.myklebust@fys.uio.no,
mark.fasheh@oracle.com, kurt.hackel@oracle.com
Subject: Re: request for patches: showing mount options
Date: Tue, 31 Jul 2007 10:19:57 -0400 [thread overview]
Message-ID: <46AF450D.5020106@oracle.com> (raw)
In-Reply-To: <E1IFnSa-0002BL-00@dorka.pomaz.szeredi.hu>
[-- Attachment #1: Type: text/plain, Size: 2663 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.
We have a first implementation of in-kernel mount option parsing in
2.6.23-rc now. I'm currently working on the user-space piece of this.
(And actually, now is a great time to review the new kernel part, while
it is still quite young.)
However, the NFS mount user-space pieces have undergone radical change
recently. The mount.nfs helper was split from the mount command just
last year, and is only now starting to go into distributions. This is
very old code that has been hacked on for over a decade, so it is taking
a little while to rediscover its history and modernize it before we move
forward.
I expect that both the kernel part and the user-space part will evolve
together over the next few months as we clarify the full set of
requirements. The requirements for this effort now include:
+ making new mount options simple to implement;
+ removing ABI dependencies between mount.nfs and the kernel NFS client;
+ an eventual merge of the nfs and nfs4 file system types;
+ improved error handling and reporting during the mount process;
+ support for NFS over IPv6.
I think there is also some talk about fully supporting SELinux as well,
but I haven't been following that closely.
The removal of /etc/mtab in favor of /proc/mounts is a new requirement,
and is not as trivial as you might hope. Internally the NFS client
represents the mount options as a binary data structure, and it contains
only the information that has traditionally been passed into the kernel
by the current mount command. The user-space-only options are not
passed to the kernel nor stored in the data structure.
Adding facilities to store information about every possible mount
option, including the user-space-only ones, will take a bit of time, but
is possible, if not straightforward. We just have to understand all the
dependencies.
[-- 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
next prev parent reply other threads:[~2007-07-31 14:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 13:45 request for patches: showing mount options Miklos Szeredi
2007-07-27 14:10 ` Steve French
2007-07-27 14:20 ` Miklos Szeredi
2007-07-27 15:30 ` Ian Kent
2007-07-27 15:40 ` Miklos Szeredi
2007-07-27 16:04 ` Steve French
2007-07-27 16:09 ` Miklos Szeredi
2007-07-28 6:45 ` Ian Kent
2007-07-29 15:07 ` Jan Engelhardt
2007-07-27 19:43 ` Chuck Lever
2007-07-27 20:03 ` Miklos Szeredi
2007-07-27 20:12 ` Chuck Lever
2007-07-28 5:37 ` Miklos Szeredi
2007-07-30 15:20 ` Chuck Lever
2007-07-31 8:52 ` Miklos Szeredi
2007-07-31 14:19 ` Chuck Lever [this message]
2007-07-31 20:22 ` Miklos Szeredi
2007-07-31 21:16 ` Chuck Lever
2007-07-31 21:27 ` Trond Myklebust
2007-08-01 6:20 ` Miklos Szeredi
2007-07-31 22:21 ` Karel Zak
2007-08-01 6:52 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46AF450D.5020106@oracle.com \
--to=chuck.lever@oracle.com \
--cc=kurt.hackel@oracle.com \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.fasheh@oracle.com \
--cc=miklos@szeredi.hu \
--cc=sfrench@samba.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox