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 <kzak@xxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html