FS#25697 - [util-linux-ng] Change package so /proc/mounts are used instead of /etc/mtab
Attached to Project:
Arch Linux
Opened by Robert Petranovic (jazzfan) - Sunday, 21 August 2011, 11:16 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 20 September 2011, 13:04 GMT
Opened by Robert Petranovic (jazzfan) - Sunday, 21 August 2011, 11:16 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 20 September 2011, 13:04 GMT
|
Details
Description:
.install file should be created so /etc/mtab gets deleted and made as symlink to /proc/mounts. Having dynamically maintained file on /etc is really bad idea, especially because it gets rewritten on each boot. This change would make mount use less hard disk access (almost none), with no drawbacks. Additional stuff: From util-linux-ng changelog (v2.19 - current): mount(8), umount(8): - could be linked with libmount (--enable-libmount-mount) to manage userspace mount options outside /etc/mtab on systems where the file is a symlink to /proc/mounts. (EXPERIMENTAL) So if I got it right, --enable-libmout-mount option is nice thing to add. (To testing repo?) This both should help http://bugs.archlinux.org/task/9384. Additional info: * util-linux 2.19 |
This task depends upon
Closed by Tom Gundersen (tomegun)
Tuesday, 20 September 2011, 13:04 GMT
Reason for closing: Implemented
Tuesday, 20 September 2011, 13:04 GMT
Reason for closing: Implemented
Traditionally /etc/mtab contains more information than the kernel knows (/proc/self/mounts), which is why we don't have a symlink yet.
With the move to libmount this should be taken care of by moving this information to /run. However, we must make sure that all the utilities that access /etc/mtab have been ported to libmount before we can add the symlink, as otherwise we get regressions. In particular we need to make sure the mount-helpers are ported. That is, mount.cifs, mount.nfs, mount.fuse and possibly others. I believe mount.nfs is ported, but I don't know the status of the others.
I believe we could use --enable-libmount-mount at the moment without creating the symlink, and everything should work as before. The individual admin could then add the symlink if he/she knows that his/her system does not rely on unported utilities. --enable-libmount-mount is still marked as experimental, but the API is now stable, and it is enabled in fedora 15, so hopefully any problems should have been found.
I'd be open to use --enable-libmonut-mount in util-linux-2.20 (which should be out next week), but the symlink by default would have to wait.
I personalty don't see particular reason why this shouldn't work with the rest also. I don't really see big difference between two formats, except /proc/mounts have more options specified, which can't do any harm.
Semi-related: http://bugs.archlinux.org/task/23014
The problem is that /etc/mtab has some options that /proc/self/mounts does not. In particular, mounting with the "user" option is not supported by /proc/self/mounts, but it is supported by mtab.
libmonut gets around this by storing some info in /run/mount/. However, it relies on all users of /etc/mtab knowing about this (i.e. they should not access /etc/mtab directly, but use libmount).
I was under the impression that libmount could deal with /etc/mtab not being a symlink, but according to the bugreport falconindy just linked to, that is not the case (unless it has been changed for 2.20).