15

A lot of people keep saying that Linux does not keep information about bind mounts, so there is no way to get a list of them and their sources. Here are some examples:

  • from one of the the comments here:

    IIRC this information is not kept anywhere: after mount --bind, the two copies are equivalent, there isn't one that's more “original” than the other. After all there could be no original if you'd already unmounted /mnt.

  • from an answer on this site:

    So the only way to remember what mounts were bind mounts is the log of mount commands left in /etc/mtab. A bind mount operation is indicated by the bind mount option (which causes the filesystem type to be ignored). But mount has no option to list only filesystems mounted with a particular set of sets of options.

  • from a Debian bug report:

    This is intentional. Both mount points are fully equal in all ways so the kernel does not keep any flags to differentiate them.

The above is nonsense though. The tool findmnt is able to list the source paths of bind mounts (in the form of device[source-path]; I'm also trying to get it to list just the source path and not the device). If the Linux kernel is to maintain a bind mount, then that information has to be stored somewhere, otherwise it couldn't know that /home is bound to /users. So where is this data? Is it stored in some obscure region in RAM? Does findmnt look in /proc somewhere?

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
Melab
  • 3,808
  • 8
  • 29
  • 49
  • What version of `findmnt` are you running and what options are you giving it? Mine doesn't print it out like that and looking at the source code it looks to be using `_PATH_PROC_MOUNTINFO` which looks to be `/proc/self/mountinfo` which doesn't have this information in it either. – Bratchley Jul 13 '16 at 02:16
  • OK I guess `/proc/self/mountinfo` relatively recently was restructured. I was on my RHEL6 machine before which didn't have the path info but my RHEL7 machine does and as mentioned in your link Wheezy does as well. – Bratchley Jul 13 '16 at 02:31
  • It isn't nonsense: it was true with older kernels, but newer kernels do track the information. – Gilles 'SO- stop being evil' Oct 26 '16 at 00:07
  • @Gilles Then how could a bind mount persist if the information that one directory is mounted at another is not tracked? – Melab Oct 27 '16 at 19:20
  • @Melab Actually, it's easier for a bind mount to persist if you don't track that it's a bind mount. When `/dev/A` is mounted at `/B` and you do `mount --bind /B /C`, older kernels remember only `/B → /dev/A` and `/C → /dev/A`, they don't remember any relationship between `/B` and `/C`. So unmounting `/B` naturally has no effect on `/C`. Newer kernels remember that `/C` was a bind mount of `/B`, but in a way that doesn't prevent `/C` from continuing to work if `/B` is unmounted, I don't know exactly how. – Gilles 'SO- stop being evil' Oct 27 '16 at 20:27
  • @Gilles But they'd *have* to keep track of it so only the files and folders in the bind mount's source directory are shown in the mount point. – Melab Nov 04 '16 at 02:14
  • @Melab No, for that you don't need to track the original mount location. The VFS layer supports mounting a subtree of the filesystem, even though for most filesystems the mount code doesn't support it so you need to use a bind mount to mount a subtree. I think btrfs does that to mount a subvolume. – Gilles 'SO- stop being evil' Nov 04 '16 at 13:24

2 Answers2

14

You've misunderstood a little; the two mount points are equal in terms of permissions, flags, etc because the bind effectively redirects access from one path to another. But they are still distinct.

If you look at /proc/self/mountinfo you'll see the kernel view of the mount world for this process (namespaces make things more complicated; there's not just one view of the mount table).

man 5 proc will explain the format of this file, but you can see the tree hierarchy and where bind mounts have their "parent". This is the file that findmnt parses.

Stephen Harris
  • 42,369
  • 5
  • 94
  • 123
12

Linux does not keep the information about which mount was a bind mount. It does keep information about all mounts including bind mounts.

It's quite similar to hard links. Mounts link to filesystems like filenames link to inodes. The only differences are that mounts also have per-mountpoint flags and may refer to a subdirectory of the target filesystem instead of the filesystem root.

When you create a hard link the file system doesn't save which filename was the original one and which was the hard link. Both simply refer to the same inode. If you unlink the original file the situation is indistinguishable from if you directly created the file with the second filename.

Back to bind mounts: The kernel keeps a table that contains the filesystem (identified by a major:minor number pair), the mountpoint, the path relative to the filesystem root and some flags. You can access this list by looking at /proc/self/mountinfo. (It gets more complicated when namespaces are involved, as @stephen-harris mentioned). findmnt parses this list.

If your root is /dev/sda1 with the major:minor 8:1 and you run mount --bind /a /b /proc/self/mountinfo will contain lines similar to this:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro

If your /home is /dev/sda2 with the major:minor 8:2 and you run mount --bind /home /users it will look like this:

1 0 8:1 / / rw - ext4 /dev/sda1 rw,errors=remount-ro
2 1 8:2 / /home rw - ext4 /dev/sda2 rw
3 1 8:2 / /users rw - ext4 /dev/sda2 rw

The relevant columns for your question are the third, the fourth and the fifth ones. These are the filesystem id (for real filesystems it's the same as the device major:minor; for virtual filesystems like tmpfs it's [0:counter]), the path relative to the filesystem root that is bound to the mountpoint (usually / for normal mounts, may be anything for bind mounts) and the mountpoint.
For the meaning of remaining columns see the Linux kernel documentation.

findmnt calls the source path relative to the filesystem root "FSROOT". You can use findmnt -o TARGET,FSROOT to get it. If you want the absolute source path you probably need to parse /proc/self/mountinfo by yourself and combine the information about the mounts for the same filesystem.

For more information see my answer to "List only bind mounts".

Community
  • 1
cg909
  • 6,908
  • 1
  • 27
  • 30
  • If `/proc/self/mountinfo` can contain lines like `2 1 8:1 /a /b rw - ext4 /dev/sda1 rw,errors=remount-ro`, then Linux most certainly *does* keep some information about bind mounts. – Melab Feb 28 '17 at 20:59
  • No. Look at my second example. It keeps the information which filesystem was mounted and which path *relative to the filesystem root was mounted*. So for `mount --bind /home/melab /mnt` the resulting line might look like any of the following depending on which of `/home` and `/home/melab` is a mountpoint: `3 1 8:1 /home/melab /mnt rw - ext4 /dev/sda1 rw`, `3 1 8:2 /melab /mnt rw - ext4 /dev/sda2 rw`, `3 1 8:3 / /mnt rw - ext4 /dev/sda3 rw` – cg909 Feb 28 '17 at 21:11
  • It's true that something different to `/` in the fourth column often indicates a bind mount. But it also might be a Btrfs subvolume. – cg909 Feb 28 '17 at 21:36
  • Is `/dev/sda3` supposed to be mounted at `/home/melab`? – Melab Mar 03 '17 at 02:00
  • Yes. In my example I used `/dev/sda1` as `/`, `/dev/sda2` as `/home` and `/dev/sda3` as `/home/melab` – cg909 Mar 03 '17 at 13:09
  • If kernel doesn't keep any information about --bind, then mount the same device twice should be exactly the same as bind its mount point to another directory. filesystem will not be corrupted when two threads are concurrently writing to these two mount points. But I remember I've seen such case, writing to one mount point but can't see the file on the other. So maybe there IS some difference, like building new cache for device mount but using original cache for bind. – 炸鱼薯条德里克 Sep 05 '18 at 10:47