Hi Miklos,
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)...
and these utils also write to mtab, although I think many of them already
check for a symlink.
> /etc/mtab were a symlink to /proc/mounts, and the kernel would be the
> authoritative source of information regarding mounts.
Yes.
> (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),
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).
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).
> (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.
> [1] http://lkml.org/lkml/2007/4/27/180
The patches have been postponed by Andrew, right? Or is it already in
-mm?
Karel
--
Karel Zak <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
