On Wed, Oct 25, 2000 at 10:59:13AM +0200, Christian Czezatke wrote:
> I've recently run across some problems with /proc/mounts on Linux 2.2.17
> when trying to get rid of /etc/mtab in favor of /proc/mounts.
>
> Patches that are basically a backport of the 2.4.x implementation of
> fs/super.c:get_filesystem_info (handles /proc/mounts) can be found at:
>
> http://www.xss.co.at/sysinfo/mounts_diff-2.2.17-patch
> (against Linux 2.2.17)
Good.
> In the future we should IMHO remove the current limitations of
> /proc/mounts so that the mount-command can finally get rid of having to do
> all the bookkeeping in /etc/mtab itself.
>
> For more information (especially why this would be a good thing...) please
> have a look at:
>
> http://www.xss.co.at/sysinfo/mounts.html
>
> Please let me know what you think about this issue.
First of all, let me quote mount(8):
---------------------------------------------------------------------
The programs mount and umount maintain a list of currently
mounted file systems in the file /etc/mtab. If no argu
ments are given to mount, this list is printed. When the
proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. The
former has somewhat more information, such as the mount
options used, but is not necessarily up-to-date (cf. the
-n option below). It is possible to replace /etc/mtab by a
symbolic link to /proc/mounts, but some information is
lost that way, and in particular working with the loop
device will be less convenient. Also, pathnames containing
spaces are handled correctly by /etc/mtab but not (yet) by
/proc/mounts.
---------------------------------------------------------------------
Your web page misses the loop device info.
Another point of difference is the name of the root device.
/proc/mounts has /dev/root, while /etc/mtab usually has
whatever was listed for / in /etc/fstab.
For some applications it is important to get the name of the
root device right. (I wrote a mount_guess_rootdev.c found in
the latest util-linux (2.10p), but not yet used because the
information in /etc/fstab is normally better.)
2.4 allows us multiple mounts of the same filesystem.
This means that umount currently is broken since it will
remove all entries for a (device,mountpoint) pair, while
it should remove only the last one.
Here /proc/mounts show the actual state of affairs.
2.4 allows us to remount (bind) subtrees at different points.
Here /proc/mounts is broken.
(The command "mount --bind /home/aeb /mnt" yields a line
/home/aeb /mnt ext2 rw,bind 0 0
in /etc/mtab, and a line
/dev/hdb7 /mnt ext2 rw 0 0
in /proc/mounts.)
So far about the current status.
Backporting my 2.4 mount patch to 2.2 is a good idea.
Also removing the 1-page limit is just a triviality.
But before doing more extensive things, we might wait a bit and see
what happens with 2.4. The new mount stuff allows people to build
immensely complicated mount structures. No doubt this has security
implications, and probably security conscious stuff will have to be
partially rewritten. I could imagine that we'll discover the need
for new system calls, maybe mtable(), or mstat() to find out about
the mount status of a file or directory. No design exists as yet.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:16 EST