Followup to: <20001025201607.A3376@veritas.com>
By author: Andries Brouwer <aeb@veritas.com>
In newsgroup: linux.dev.kernel
>
> 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.
>
Another option is to have the readout done by calling mount(8) without
any parameters be smarter; for example, even if it reads /proc/mounts
it can replace /dev/root with the appropriate entry for the root
directory from fstab. I have suggested, strongly, a /proc/vfsbind or
other way to detect the location of VFS bindings.
There is another good reason to ditch /etc/mtab: as a static file, it
cannot track changes due to VFS bind/unbind. I am considering for
autofs 5 to build a mount tree in a temporary directory, then binding
it to the target site and unbinding it from the temporary directory.
Since vfsbinds are similar to hard links in that respect, this would
have the effect of moving the entire mount hierarchy atomically into
place, which may avoid some of the rather serious problems the current
autofs has with the dcache (the dcache doesn't like a directory both
"existing" and "not existing" depending on the user, and subtle
changes in the dcache continually breaks autofs for that reason.)
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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