Messages in this thread | | | Date | Thu, 27 Apr 2006 18:49:29 +0400 | From | Michael Tokarev <> | Subject | Re: CLONE_NEWNS and mount command? |
| |
Tom Horsley wrote: [] > If there is a bug, maybe it is that a /etc/mtab file exists > at all :-).
This topic has been discussed before (without any real conclusion if memory serves me right). The thing is: /etc/mtab IS useful, as it contains different information compared with /proc/mounts (irrelevant to CLONE_NEWNS/namespaces). For example, if I'll
mount -o loop file /mount/point
mtab will contain -oloop=X /path/to/file /mount/point
while /proc/mounts will only have file /mount/point
Note the two differences: omission of loop device number (used by umount to automatically deconfigure loop device) and relative (to what??) path to `file'.
On the other hand, /proc/mounts often contains more options than mtab: mtab only lists those options which has been specified on the command line, omitting defaults, but /proc/mounts lists them all (like data=ordered for ext3fs).
And on another note, there are cases when you do NOT want to expose some "internal" mounts to users. "Classical" example which bothered me for quite some time is the way udev is set up on Debian (dunno for other distros): they move-mount /dev to /dev/.static/dev, but /dev/.static is drwx------, ie ordinary users can't access it. Hence, when you run any command which tries to access mounted filesystems (like df for example), it complains that it can't stat /dev/.static/dev, which is plain ugly. Omitting that entry from /etc/mtab fixes the problem.
That all to say: /proc/mounts and /etc/mtab both has their good and usages... And *this*, IMHO, is where the bug is: neither of the two gives complete information.
/mjt - 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/
| |