What Linux bind mounts are really doing
Lots of Unixes have some form of 'loopback' mounts, where you can mount
a bit of an existing filesystem somewhere else; they're called loopback
mounts by analogy with the loopback interface. The general idea behind
them is that they are a more efficient (and easier to use) version of
doing an NFS mount from localhost
.
(I suspect that Sun originated the idea, but I'm not sure.)
Linux's bind mounts (so called because they are done with mount
--bind
, or by specifying bind
as the filesystem type in /etc/fstab
)
look like any other sort of loopback mounting. However, they actually
operate in a way quite different from the usual idea of loopback
mounting, and the difference has some important consequences.
What bind mounts are really doing is more or less mounting the filesystem again with a different inode as the root inode. Thus, if you do:
mount /dev/md1 /foo mount --bind /foo/bar /bar
what you really have is /dev/md1 mounted twice, once with the root inode of the filesystem on md1 as the root of the mount point, and once with the inode for 'bar' in the root of the filesystem on md1 as the root of the mount point.
The mount
command makes this hard to see by being misleading in
its output, reporting things like '/data/home on /home type none
(rw,bind)
'. Because they use /etc/mtab
, which mount
maintains,
things like df
also report like this. More of the real state of
affairs is visible in /proc/mounts
, where the kernel itself reports:
/dev/md5 /data ext3 rw,data=ordered 0 0 /dev/md5 /home ext3 rw,data=ordered 0 0
Unfortunately the kernel doesn't report that what root inode /home
is
mounted with, which generally makes mount
's output more useful once you
know what is really going on.
One consequence of this is that once you've set up your bind mounts, you can unmount the original mount point, something which I believe is not true of things like Solaris's loopback mounts (and which definitely wouldn't be true of NFS mounts from localhost). There might be a use for this in obscure situations.
Sidebar: Deeper under the hood
Disclaimer: I am not sure I understand this correctly.
Under the hood, there are two things: actual mounts of filesystems from devices (or the network), and namespace-based views of such filesystems. Rather than create new copies of both, bind mounts create new views ('mounts' or 'vfsmounts') of the same underlying mounted filesystem.
This explains one limitation of bind mounts, which is that you can't change mount flags when you do a bind mount (so you can't have a bind mount that is a read-only version of part of a read-write filesystem). Currently, all mount flags are associated with the filesystem, not with the view, so all views have to have the same mount flags.
|
|