Selon Stuart Kemp <stuart_k...@hotmail.com>: > > It is mount(8) and umount(8) that maintain /etc/mtab. I don't think this is > intended to be a definitive list (on Linux) of all mounted areas. As it > states in the mount(8) man-page 'It is possible that /etc/mtab and > /proc/mounts don't match. The first file is based only on the mount command > options..." > /proc/mounts is to my understanding a linux only feature and /etc/mtab usage is more general than linux.
> Yes, the app I was playing with does not call addmntent() or anything else to > explicitly manipulate /etc/mtab. But it should not have to, since all of this > mount-data is already available from the kernel (via /proc/mounts); as such > it seems redundant to even have /etc/mtab. The problem could also arise using > the "-n" option of mount(8). It would seem logical to use a definitive set of > information, given that it is readily available i.e. get the mounted > filesystems from /proc/mounts, rather than the arbitrary data that may (or > may not) be in /etc/mtab. And this addresses a limitation in the current > implementation. > There is sometime less informations in /proc/mounts than in /etc/mtab so linking /etc/mtab to /proc/mounts may drive to issues. This could be demonstrated by mkdir /tmp/test1 /tmp/test2 mount -bind /tmp/test1 /tmp/test2 With /etc/mtab as symlink, you can't do umount /tmp/test1 and could only umount /tmp/test2 With /etc/mtab as a real file, umount /tmp/test1 work too. As booting from initramfs is now very frequent, /proc /sys /dev are mounted inside initramfs script. So the boot script on the root file system has to mount -f /proc /sys /dev again to update the rootfs /etc/mtab (mount -f only update /etc/mtab and mount nothing) > And of course, using mount(8) with no arguments also has a "problem" in that > it lists the contents of /etc/mtab, rather than what is actually mounted! > > -Stuart Kemp > that could be considered as a feature when you are inside a chroot and don't want to be distracted by what was done outside. Gilles
