> On Thu, May 31, 2007 at 06:29:12PM +0200, Miklos Szeredi wrote:
> > It's not just mount(8) that reads /etc/mtab, but various other
> > utilities, for example df(1). So the best solution would be if
>
> mount.nfs, mount.cifs, mount.ocfs, HAL, am-utils (amd)...
OK, I'll try to round up the people involved and ask how this change
would affect their programs.
> > (1) user mounts ("user" or "users" option in /etc/fstab) currently
> > need /etc/mtab to keep track of the owner
>
> There is more things:
>
> loop=</dev/loopN>
>
> ... umount(8) uses this option for loop device deinitialization,
> when the device was initialized by mount(8),
Hmm, this is basically just a bool flag for each loop device, and
could be stored in a file under /var/lib.
> encryption=, offset=, speed=
>
> ... but nothing uses these options
>
> uhelper=
>
> ... this one is my baby :-(
>
> (Not released by upstream yet. ...according to Google this
> Fedora patch is already in Mandrake, PCLinuxOS, Pardus, and
> ??? )
>
> From man page:
>
> The uhelper (unprivileged umount request helper) is possible
> used when non-root user wants to umount a mountpoint
> which is not defined in the /etc/fstab file (e.g devices
> mounted by HAL).
So the helper gets to run _before_ the umount takes place?
>
> GNOME people love it, because that's a way how use command line
> utils (umount(8)) for devices that was mounted by desktop
> daemons.
>
>
> The umount.nfs also reads many options from mtab, but it seems all
> these options are also in /proc/mounts.
>
> I know almost nothing about the others [u]mount dialects (cifs, ...).
>
> > (2) lots of filesystems only present a few mount options (or none) in
> > /proc/mounts
> >
> > (1) can be solved with the new mount owner support in the unprivileged
> > mounts patchset. Mount(8) would still have to detect at boot time if
> > this is available, and either create the symlink to /proc/mounts or if
> > MS_SETOWNER is not available, fall back to using /etc/mtab.
>
> Sounds good, but there should be a way (an option) to disable this
> functionality (in case when mtab is required for an exotic reason).
Sure, that's a good idea. How do we configure mount(8)? Maybe an
option (--no-mtab-symlink), and leave the configuration to userspace.
When mount is invoked first on boot (mount -a) this could tell us if
the creation of the symlink is not desired.
> > (2) needs work in the filesystems implicated. I already have patches
> > for ext2, ext3, tmpfs, devpts and hostfs, and it would be nice if the
> > maintainers for others could help out.
> >
> > It wouldn't even be fatal if some mount options were missing from
> > /proc/mounts. Mount options in /etc/mtab have never been perfectly
> > accurate, especially after a remount, when they could get totally out
> > of sync with the options effective for the filesystem.
>
> The /etc/mtab is almost always useless with NFS (kernel is changing
> mount options according to NFS server settings, so there is possible
> that you have "rw" in mtab and "ro" in /proc/mounts :-)
>
> > Can someone think of any other problem with getting rid of /etc/mtab?
>
> Crazy idea: make kernel more promiscuous with mount options -- it
> means you can use an arbitrary "foo=" option for mount(2) when max
> length of all options is less than or equal to
> /proc/sys/fs/mntopt_max. (well... NACK :-)
>
> I agree that the /etc/mtab file is badly designed thing where we
> duplicate almost all from /proc/mounts, but loop= and uhelper= are
> nice examples that userspace utils are able to capitalize on this
> concept. Maybe we need something better than the mtab for userspace
> specific options.
>
> Somewhere at people.redhat.com/kzak/ I have a patch that add LUKS
> support to the mount(8) and this patch also add new options to the
> mtab file. I can imagine more scenarios when userspace specific
> options are good thing.
So there's a need to attach some metadata to mounts. And preferably
that should also be stored in the kernel, otherwise there will just be
confusion, when the mount tree is manipulated without the metadata
also being updated. And with unprivileged mounts this can only be
guaranteed if the metadata is also in the kernel.
So, how about a special mount option: "uopts=...", which would contain
userspace options separated by ";" or whatever. Then the kernel could
be taught to store this option verbatim and show it in /proc/mounts
along with the kernel options.
> > [1] http://lkml.org/lkml/2007/4/27/180
>
> The patches have been postponed by Andrew, right? Or is it already in
> -mm?
Yes, they have now survived for a month in -mm, which might be a good
sign ;)
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
