Messages in this thread | | | Subject | Re: request for patches: showing mount options | From | Miklos Szeredi <> | Date | Wed, 01 Aug 2007 08:52:36 +0200 |
| |
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |