request for patches: showing mount options

request for patches: showing mount options

[Miklos Szeredi]

[please consider pruning the CC list if discussing some aspect, which
doesn't concern all]

I've done an audit of all filesystems with regards to showing mount
options in /proc/<pid>/mounts.  Unfortunately most of them show none
or only a part of all accepted options (for details see list of
filesystems at the end of the mail).

This is currently not a big problem, because mount(8) stores the given
options in /etc/mtab.  However we want to get rid of mtab, and this
requires, that the option showing be fixed up.

It would be easiest if this was done by the VFS instead of having to
deal with it in filesystems.  However there are differences in how
filesytems handle options during mount and remount, and it would be
impossible to take this into account in all cases.

If you are CC-ed, and responsible for one of these filesystems, please
take a moment to fully implement the ->show_options() method.  In most
cases it should be an easy task.

If for some reason you are unable to do this, please let me know and
I'll fix it up.

Here are some guidelines for showing options.  I'll also add these to
Documentation/filesystems/vfs.txt

+   If a filesystem accepts mount options, it must define show_options()
+   to show all the currently active options.  The rules are:
+
+     - options MUST be shown which are not default or their values differ
+       from the default
+
+     - options MAY be shown which are enabled by default or have their
+       default value
+
+   Options used only internally between a mount helper and the kernel
+   (such as file descriptors), or which only have an effect during the
+   mounting (such as ones controlling the creation of a journal) are exempt
+   from the above rules.

Thanks,
Miklos

-------
legend:

  all - fs has options, but doesn't define ->show_options()
  some - fs defines ->show_options(), but some options are not shown
  noopt - fs does not have options
  good - fs shows all options
  patch - I have a patch


9p          some
adfs        all (maintainer?)
affs        all
afs         all
autofs      all
autofs4     some
befs        all
bfs         noopt
cifs        some (odd parser)
coda        noopt
configfs    noopt
cramfs      noopt
debugfs     noopt
devpts      patch
ecryptfs    some
efs         noopt
ext2        patch
ext3        patch
ext4        patch
fat         some
freevxfs    noopt
fuse        patch
gfs2        good
hfs         good
hfsplus     good
hostfs      patch
hpfs        all
hppfs       noopt
hugetlbfs   all
isofs       all (maintainer?)
jffs2       noopt
jfs         some
minix       noopt
msdos       ->fat
ncpfs       all (FS_BINARY_MOUNTDATA?)
nfs         some
nfsd        noopt
ntfs        good (odd parser)
ocfs2       all
openpromfs  noopt
proc        noopt
qnx4        noopt
ramfs       noopt
reiserfs    all
romfs       noopt
smbfs       good (odd parser) (maintainer?)
sysfs       noopt
sysv        noopt
udf         all
ufs         all
vfat        ->fat
xfs         some (odd parser)

mm/shmem.c                                    patch
drivers/oprofile/oprofilefs.c                 noopt
drivers/infiniband/hw/ipath/ipath_fs.c        noopt
drivers/misc/ibmasm/ibmasmfs.c                noopt
drivers/usb/core (usbfs)                      noopt
drivers/usb/gadget (gadgetfs)                 noopt
drivers/isdn/capi/capifs.c                    noopt
kernel/cpuset.c                               noopt
fs/binfmt_misc.c                              noopt
net/sunrpc/rpc_pipe.c                         noopt
arch/powerpc/platforms/cell/spufs             all
arch/s390/hypfs                               all
ipc/mqueue.c                                  noopt
security (securityfs)                         noopt
security/selinux/selinuxfs.c                  noopt

in -mm:

reiser4                some (odd parser)
kernel/container.c     good (odd parser)

Re: request for patches: showing mount options

[Steve French]

What do you consider the best example so far of a kernel module's
equivalent of "parse_mount_options" (handling a mix of options of
different types) and show_options.

On 7/27/07, Miklos Szeredi <miklos@szeredi.hu> wrote:
> [please consider pruning the CC list if discussing some aspect, which
> doesn't concern all]
>
> I've done an audit of all filesystems with regards to showing mount
> options in /proc/<pid>/mounts.  Unfortunately most of them show none
> or only a part of all accepted options (for details see list of
> filesystems at the end of the mail).
>
> This is currently not a big problem, because mount(8) stores the given
> options in /etc/mtab.  However we want to get rid of mtab, and this
> requires, that the option showing be fixed up.
>
> It would be easiest if this was done by the VFS instead of having to
> deal with it in filesystems.  However there are differences in how
> filesytems handle options during mount and remount, and it would be
> impossible to take this into account in all cases.
>
> If you are CC-ed, and responsible for one of these filesystems, please
> take a moment to fully implement the ->show_options() method.  In most
> cases it should be an easy task.
>
> If for some reason you are unable to do this, please let me know and
> I'll fix it up.
>
> Here are some guidelines for showing options.  I'll also add these to
> Documentation/filesystems/vfs.txt
>
> +   If a filesystem accepts mount options, it must define show_options()
> +   to show all the currently active options.  The rules are:
> +
> +     - options MUST be shown which are not default or their values differ
> +       from the default
> +
> +     - options MAY be shown which are enabled by default or have their
> +       default value
> +
> +   Options used only internally between a mount helper and the kernel
> +   (such as file descriptors), or which only have an effect during the
> +   mounting (such as ones controlling the creation of a journal) are exempt
> +   from the above rules.
>
> Thanks,
> Miklos
>
> -------
> legend:
>
>   all - fs has options, but doesn't define ->show_options()
>   some - fs defines ->show_options(), but some options are not shown
>   noopt - fs does not have options
>   good - fs shows all options
>   patch - I have a patch
>
>
> 9p          some
> adfs        all (maintainer?)
> affs        all
> afs         all
> autofs      all
> autofs4     some
> befs        all
> bfs         noopt
> cifs        some (odd parser)
> coda        noopt
> configfs    noopt
> cramfs      noopt
> debugfs     noopt
> devpts      patch
> ecryptfs    some
> efs         noopt
> ext2        patch
> ext3        patch
> ext4        patch
> fat         some
> freevxfs    noopt
> fuse        patch
> gfs2        good
> hfs         good
> hfsplus     good
> hostfs      patch
> hpfs        all
> hppfs       noopt
> hugetlbfs   all
> isofs       all (maintainer?)
> jffs2       noopt
> jfs         some
> minix       noopt
> msdos       ->fat
> ncpfs       all (FS_BINARY_MOUNTDATA?)
> nfs         some
> nfsd        noopt
> ntfs        good (odd parser)
> ocfs2       all
> openpromfs  noopt
> proc        noopt
> qnx4        noopt
> ramfs       noopt
> reiserfs    all
> romfs       noopt
> smbfs       good (odd parser) (maintainer?)
> sysfs       noopt
> sysv        noopt
> udf         all
> ufs         all
> vfat        ->fat
> xfs         some (odd parser)
>
> mm/shmem.c                                    patch
> drivers/oprofile/oprofilefs.c                 noopt
> drivers/infiniband/hw/ipath/ipath_fs.c        noopt
> drivers/misc/ibmasm/ibmasmfs.c                noopt
> drivers/usb/core (usbfs)                      noopt
> drivers/usb/gadget (gadgetfs)                 noopt
> drivers/isdn/capi/capifs.c                    noopt
> kernel/cpuset.c                               noopt
> fs/binfmt_misc.c                              noopt
> net/sunrpc/rpc_pipe.c                         noopt
> arch/powerpc/platforms/cell/spufs             all
> arch/s390/hypfs                               all
> ipc/mqueue.c                                  noopt
> security (securityfs)                         noopt
> security/selinux/selinuxfs.c                  noopt
>
> in -mm:
>
> reiser4                some (odd parser)
> kernel/container.c     good (odd parser)
>


-- 
Thanks,

Steve

Re: request for patches: showing mount options

[Miklos Szeredi]

> What do you consider the best example so far of a kernel module's
> equivalent of "parse_mount_options" (handling a mix of options of
> different types) and show_options.

For example gfs2 is pretty good.  It has lots of different type of
options, and it handles them in remount as well as mount.

Miklos

Re: request for patches: showing mount options

[Ian Kent]

On Fri, 2007-07-27 at 15:45 +0200, Miklos Szeredi wrote:
> [please consider pruning the CC list if discussing some aspect, which
> doesn't concern all]
> 
> I've done an audit of all filesystems with regards to showing mount
> options in /proc/<pid>/mounts.  Unfortunately most of them show none
> or only a part of all accepted options (for details see list of
> filesystems at the end of the mail).
> 
> This is currently not a big problem, because mount(8) stores the given
> options in /etc/mtab.  However we want to get rid of mtab, and this
> requires, that the option showing be fixed up.
> 
> It would be easiest if this was done by the VFS instead of having to
> deal with it in filesystems.  However there are differences in how
> filesytems handle options during mount and remount, and it would be
> impossible to take this into account in all cases.
> 
> If you are CC-ed, and responsible for one of these filesystems, please
> take a moment to fully implement the ->show_options() method.  In most
> cases it should be an easy task.
> 
> If for some reason you are unable to do this, please let me know and
> I'll fix it up.
> 
> Here are some guidelines for showing options.  I'll also add these to
> Documentation/filesystems/vfs.txt
> 
> +   If a filesystem accepts mount options, it must define show_options()
> +   to show all the currently active options.  The rules are:
> +
> +     - options MUST be shown which are not default or their values differ
> +       from the default
> +
> +     - options MAY be shown which are enabled by default or have their
> +       default value
> +
> +   Options used only internally between a mount helper and the kernel
> +   (such as file descriptors), or which only have an effect during the
> +   mounting (such as ones controlling the creation of a journal) are exempt
> +   from the above rules.
> 
> Thanks,
> Miklos
> 
> -------
> legend:
> 
>   all - fs has options, but doesn't define ->show_options()
>   some - fs defines ->show_options(), but some options are not shown
>   noopt - fs does not have options
>   good - fs shows all options
>   patch - I have a patch
> 
> 
> 9p          some
> adfs        all (maintainer?)
> affs        all
> afs         all
> autofs      all

I'm not sure I understand this.
How does autofs show it's options without a ->show_options method?

> autofs4     some

OK, uid and gid aren't shown.
That should be straight forward to fix.
What's your time frame for this?

Ian

Re: request for patches: showing mount options

[Miklos Szeredi]

>   all - fs has options, but doesn't define ->show_options()
>   some - fs defines ->show_options(), but some options are not shown
>   noopt - fs does not have options
>   good - fs shows all options
>   patch - I have a patch

[...]

> > autofs      all
> 
> I'm not sure I understand this.
> How does autofs show it's options without a ->show_options method?

It doesn't.  The "all" means, all of them need to be added to
->show_options(), not that all are shown.

I can see now that this is slightly confusing, sorry.

So the ones that need attention are "all" and "some".  The others are
fine in theory.  Of course I may have missed something.

> > autofs4     some
> 
> OK, uid and gid aren't shown.
> That should be straight forward to fix.
> What's your time frame for this?

ASAP ;)

2.6.24 would be a nice, but it won't be easy...

Miklos

Re: request for patches: showing mount options

[Steve French]

cifs and nfs (probably others) have some mount options which are mount
order dependent ie may be invalid or ignored when you have more than
one mount to the same server, or mount the same resource in two places
with different options.  In the long run, at least for cifs, we may be
able to better handle a user mounting to the same server twice with
e.g. different security options (authentication, packet signing ...),
but in the meantime are there any thoughts on whether those type of
mount options should be displayed differently

On 7/27/07, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >   all - fs has options, but doesn't define ->show_options()
> >   some - fs defines ->show_options(), but some options are not shown
> >   noopt - fs does not have options
> >   good - fs shows all options
> >   patch - I have a patch
>
> [...]
>
> > > autofs      all
> >
> > I'm not sure I understand this.
> > How does autofs show it's options without a ->show_options method?
>
> It doesn't.  The "all" means, all of them need to be added to
> ->show_options(), not that all are shown.
>
> I can see now that this is slightly confusing, sorry.
>
> So the ones that need attention are "all" and "some".  The others are
> fine in theory.  Of course I may have missed something.
>
> > > autofs4     some
> >
> > OK, uid and gid aren't shown.
> > That should be straight forward to fix.
> > What's your time frame for this?
>
> ASAP ;)
>
> 2.6.24 would be a nice, but it won't be easy...
>
> Miklos
>


-- 
Thanks,

Steve

Re: request for patches: showing mount options

[Miklos Szeredi]

> cifs and nfs (probably others) have some mount options which are mount
> order dependent ie may be invalid or ignored when you have more than
> one mount to the same server, or mount the same resource in two places
> with different options.  In the long run, at least for cifs, we may be
> able to better handle a user mounting to the same server twice with
> e.g. different security options (authentication, packet signing ...),
> but in the meantime are there any thoughts on whether those type of
> mount options should be displayed differently

I think they should be displayed normally, just as all the other
options.  If an option is shared by multiple mounts, that option
should be displayed for all of them.

This is similar to the case of per-mount vs. per-superblock options,
which aren't separated either.

Miklos

Re: request for patches: showing mount options

[Chuck Lever]

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

Miklos:

Some mount options are never passed to the kernel, and thus can't appear 
in /proc/mounts.  Examples include user, users, and _netdev for NFS.

Miklos Szeredi wrote:
> [please consider pruning the CC list if discussing some aspect, which
> doesn't concern all]
> 
> I've done an audit of all filesystems with regards to showing mount
> options in /proc/<pid>/mounts.  Unfortunately most of them show none
> or only a part of all accepted options (for details see list of
> filesystems at the end of the mail).
> 
> This is currently not a big problem, because mount(8) stores the given
> options in /etc/mtab.  However we want to get rid of mtab, and this
> requires, that the option showing be fixed up.
> 
> It would be easiest if this was done by the VFS instead of having to
> deal with it in filesystems.  However there are differences in how
> filesytems handle options during mount and remount, and it would be
> impossible to take this into account in all cases.
> 
> If you are CC-ed, and responsible for one of these filesystems, please
> take a moment to fully implement the ->show_options() method.  In most
> cases it should be an easy task.
> 
> If for some reason you are unable to do this, please let me know and
> I'll fix it up.
> 
> Here are some guidelines for showing options.  I'll also add these to
> Documentation/filesystems/vfs.txt
> 
> +   If a filesystem accepts mount options, it must define show_options()
> +   to show all the currently active options.  The rules are:
> +
> +     - options MUST be shown which are not default or their values differ
> +       from the default
> +
> +     - options MAY be shown which are enabled by default or have their
> +       default value
> +
> +   Options used only internally between a mount helper and the kernel
> +   (such as file descriptors), or which only have an effect during the
> +   mounting (such as ones controlling the creation of a journal) are exempt
> +   from the above rules.
> 
> Thanks,
> Miklos
> 
> -------
> legend:
> 
>   all - fs has options, but doesn't define ->show_options()
>   some - fs defines ->show_options(), but some options are not shown
>   noopt - fs does not have options
>   good - fs shows all options
>   patch - I have a patch
> 
> 
> 9p          some
> adfs        all (maintainer?)
> affs        all
> afs         all
> autofs      all
> autofs4     some
> befs        all
> bfs         noopt
> cifs        some (odd parser)
> coda        noopt
> configfs    noopt
> cramfs      noopt
> debugfs     noopt
> devpts      patch
> ecryptfs    some
> efs         noopt
> ext2        patch
> ext3        patch
> ext4        patch
> fat         some
> freevxfs    noopt
> fuse        patch
> gfs2        good
> hfs         good
> hfsplus     good
> hostfs      patch
> hpfs        all
> hppfs       noopt
> hugetlbfs   all
> isofs       all (maintainer?)
> jffs2       noopt
> jfs         some
> minix       noopt
> msdos       ->fat
> ncpfs       all (FS_BINARY_MOUNTDATA?)
> nfs         some
> nfsd        noopt
> ntfs        good (odd parser)
> ocfs2       all
> openpromfs  noopt
> proc        noopt
> qnx4        noopt
> ramfs       noopt
> reiserfs    all
> romfs       noopt
> smbfs       good (odd parser) (maintainer?)
> sysfs       noopt
> sysv        noopt
> udf         all
> ufs         all
> vfat        ->fat
> xfs         some (odd parser)
> 
> mm/shmem.c                                    patch
> drivers/oprofile/oprofilefs.c                 noopt
> drivers/infiniband/hw/ipath/ipath_fs.c        noopt
> drivers/misc/ibmasm/ibmasmfs.c                noopt
> drivers/usb/core (usbfs)                      noopt
> drivers/usb/gadget (gadgetfs)                 noopt
> drivers/isdn/capi/capifs.c                    noopt
> kernel/cpuset.c                               noopt
> fs/binfmt_misc.c                              noopt
> net/sunrpc/rpc_pipe.c                         noopt
> arch/powerpc/platforms/cell/spufs             all
> arch/s390/hypfs                               all
> ipc/mqueue.c                                  noopt
> security (securityfs)                         noopt
> security/selinux/selinuxfs.c                  noopt
> 
> in -mm:
> 
> reiser4                some (odd parser)
> kernel/container.c     good (odd parser)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 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
version:2.1
end:vcard

Re: request for patches: showing mount options

[Miklos Szeredi]

> Some mount options are never passed to the kernel, and thus can't appear 
> in /proc/mounts.  Examples include user, users, and _netdev for NFS.

These options control *who* may mount and *when* to mount.  They are
not a property of the mount itself and are not added to /etc/mtab.

There's a "user=ID" option that is added to /etc/mtab in case of user
mounts.  This identifies the owner of the mount, so that it can be
unmounted by that user.  There are patches in -mm that enable the
kernel to store this info.

Do you have other examples in mind?

Miklos

Re: request for patches: showing mount options

[Chuck Lever]

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

Miklos Szeredi wrote:
>> Some mount options are never passed to the kernel, and thus can't appear 
>> in /proc/mounts.  Examples include user, users, and _netdev for NFS.
> 
> These options control *who* may mount and *when* to mount.  They are
> not a property of the mount itself and are not added to /etc/mtab.
> 
> There's a "user=ID" option that is added to /etc/mtab in case of user
> mounts.  This identifies the owner of the mount, so that it can be
> unmounted by that user.  There are patches in -mm that enable the
> kernel to store this info.
> 
> Do you have other examples in mind?

[no]quota comes to mind; also auto, [no]owner, [no]group, and 
quiet/loud, but these may fall into the same category you mention above.

Aside: It's a confusing artifact of the mount CLI that these options 
control who/when but are passed to the mount command in the same way the 
other options are.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 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
version:2.1
end:vcard

Re: request for patches: showing mount options

[Miklos Szeredi]

> >> Some mount options are never passed to the kernel, and thus can't appear 
> >> in /proc/mounts.  Examples include user, users, and _netdev for NFS.
> > 
> > These options control *who* may mount and *when* to mount.  They are
> > not a property of the mount itself and are not added to /etc/mtab.
> > 
> > There's a "user=ID" option that is added to /etc/mtab in case of user
> > mounts.  This identifies the owner of the mount, so that it can be
> > unmounted by that user.  There are patches in -mm that enable the
> > kernel to store this info.
> > 
> > Do you have other examples in mind?
> 
> [no]quota comes to mind;

These are passed to the kernel.

> also auto,

This controls when a filesystem is mounted, same category as '_netdev'

> [no]owner, [no]group,

These control who can mount the filesystem, same category as 'user' and 'users'

> quiet/loud,

I can't find these in the manual as universal options.  Quiet is
defined for a couple of filesystems but with different meaning for
each of them.

> Aside: It's a confusing artifact of the mount CLI that these options 
> control who/when but are passed to the mount command in the same way the 
> other options are.

Yes, slightly.  Actually most of these options are just ignored on the
command line.  They only have an affect in /etc/fstab.

The right behavior of mount(8) would probably be to error out on these
options, since they make no sense on the command line.  But this is
not a kernel issue.

Miklos

Re: request for patches: showing mount options

[Ian Kent]

On Fri, 2007-07-27 at 17:40 +0200, Miklos Szeredi wrote:
> >   all - fs has options, but doesn't define ->show_options()
> >   some - fs defines ->show_options(), but some options are not shown
> >   noopt - fs does not have options
> >   good - fs shows all options
> >   patch - I have a patch
> 
> [...]
> 
> > > autofs      all
> > 
> > I'm not sure I understand this.
> > How does autofs show it's options without a ->show_options method?
> 
> It doesn't.  The "all" means, all of them need to be added to
> ->show_options(), not that all are shown.

Oh .. sorry, I wasn't paying enough attention.

But now might be a good time to propose the removal of autofs and rename
autofs4 to autofs. I would need to provide some way to map autofs4
module load requests to autofs for backward compatibility but haven't
thought about that yet.

> 
> I can see now that this is slightly confusing, sorry.
> 
> So the ones that need attention are "all" and "some".  The others are
> fine in theory.  Of course I may have missed something.
> 
> > > autofs4     some
> > 
> > OK, uid and gid aren't shown.
> > That should be straight forward to fix.
> > What's your time frame for this?
> 
> ASAP ;)
> 
> 2.6.24 would be a nice, but it won't be easy...

The autofs4 (and, if needed autofs) should be straight forward.
I'll do these.

Ian

Re: request for patches: showing mount options

[Jan Engelhardt]

[cc trim on purpose, just autofs interest here]

On Jul 28 2007 14:45, Ian Kent wrote:
>
>Oh .. sorry, I wasn't paying enough attention.
>
>But now might be a good time to propose the removal of autofs and rename
>autofs4 to autofs. I would need to provide some way to map autofs4
>module load requests to autofs for backward compatibility but haven't
>thought about that yet.

You could use EXPORT_SYMBOL in autofs.ko that autofs4.ko uses.
Or write an autofs4.c that does try_module_get(autofs) on _init.


	Jan
-- 

Re: request for patches: showing mount options

[Chuck Lever]

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



Miklos Szeredi wrote:
>>>> Some mount options are never passed to the kernel, and thus can't appear 
>>>> in /proc/mounts.  Examples include user, users, and _netdev for NFS.
>>> These options control *who* may mount and *when* to mount.  They are
>>> not a property of the mount itself and are not added to /etc/mtab.
>>>
>>> There's a "user=ID" option that is added to /etc/mtab in case of user
>>> mounts.  This identifies the owner of the mount, so that it can be
>>> unmounted by that user.  There are patches in -mm that enable the
>>> kernel to store this info.
>>>
>>> Do you have other examples in mind?

There are a few more cases for NFS mount.

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.

I'm wondering if there are other such cases in other file systems.

[-- 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

Re: request for patches: showing mount options

[Miklos Szeredi]

> 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?

> I'm wondering if there are other such cases in other file systems.

Anything that has /sbin/mount.XXX could be doing this.  According to
Karel, those are nfs, cifs and ocfs2.

Miklos

Re: request for patches: showing mount options

[Chuck Lever]

[-- 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

Re: request for patches: showing mount options

[Miklos Szeredi]

> >> 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?

It would be nice to have all this stuff in 2.6.24, which doesn't leave
a lot of time.

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.

Miklos

Re: request for patches: showing mount options

[Chuck Lever]

[-- 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

Re: request for patches: showing mount options

[Trond Myklebust]

On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote:
> Miklos Szeredi wrote:
> > 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.

I never like to tell people what their priorities should be. If someone
is interested enough to do the work, then it will get done, however this
cannot make the top of my already-overloaded list of priorities for
2.6.24, and it would appear that Chuck is busy too.

Any other volunteers out there?

Cheers
  Trond

Re: request for patches: showing mount options

[Karel Zak]

On Tue, Jul 31, 2007 at 10:19:57AM -0400, Chuck Lever wrote:
> 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.

 I still have doubts. The removal of /etc/mtab is nice, but a little
 unreal wish. Do we really want to store non-kernel data (options) in
 kernel? What about options that are not closely related to any
 filesystem -- for example "loop="?

 Maybe we can replace /etc/mtab with something more useful
 (e.g. /var/run/mount/<mntid>.tab) for really user-space-only information.

 It doesn't mean that Miklos's audit of all filesystems and request
 for patches is bad thing. The /proc/mounts has to provide complete
 information at least about kernel mount options.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: request for patches: showing mount options

[Miklos Szeredi]

> On Tue, 2007-07-31 at 17:16 -0400, Chuck Lever wrote:
> > Miklos Szeredi wrote:
> > > 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.
> 
> I never like to tell people what their priorities should be. If someone
> is interested enough to do the work, then it will get done, however this
> cannot make the top of my already-overloaded list of priorities for
> 2.6.24, and it would appear that Chuck is busy too.
> 
> Any other volunteers out there?

I'm willing to help out.

I could have basically fixed up all filesystems, but I think it's
better if the maintainers do it and are aware that this needs to be
looked at each time a new option is added.

But there's no problem with making exceptions if the maintainers are
busy.

Miklos

Re: request for patches: showing mount options

[Miklos Szeredi]

> > 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.
> 
>  I still have doubts. The removal of /etc/mtab is nice, but a little
>  unreal wish. Do we really want to store non-kernel data (options) in
>  kernel? What about options that are not closely related to any
>  filesystem -- for example "loop="?

"loop=DEV" is special, we've already talked about that.

For example if we have an mtab entry like this:

  /dir/foo.iso /mnt/image ext3 rw,loop=/dev/loop/0 0 0

It says: /dev/loop/0 has been automatically set up by mount(8) from
/dir/foo.iso and so needs to be torn down by umount(8).  It is not a
property of the mount, rather the property of the device.

So what we really want is a file to store this, and only this info:

/var/lib/mount/loop:

/dev/loop/0 /dir/foo.iso
/dev/loop/2 /dir/bar.img
...

Notice, there's nothing about the _mountpoint_ in this file.

>  Maybe we can replace /etc/mtab with something more useful
>  (e.g. /var/run/mount/<mntid>.tab) for really user-space-only information.

The problem with storing mount options in userspace is that
unprivileged mounts/umounts won't work in the presense of those, we
cannot _force_ an unprivileged user to update a file.

So we want to avoid storing options in userspace as long as possible.

Miklos