So, this bit me again, years later. This time I have a better
understanding of what is going on.
When a snapshot is mounted, /proc/mounts gets weird. Here's an example
having created two LVs, bind mounting the first onto a new directory,
and then mounting a snapshot of the second lv into the subdir of that
new directory.
+ grep /mnt/snaptest /proc/mounts
/dev/mapper/ssd1-test1 /mnt/snaptest/a ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2 /mnt/snaptest/a/2 ext4 rw,relatime 0 0
/dev/mapper/ssd1-test1 /mnt/snaptest/b ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2--snap /mnt/snaptest/b/2 ext4 rw,relatime 0 0
/dev/mapper/ssd1-test2--snap /mnt/snaptest/a/2 ext4 rw,relatime 0 0
Note that /proc/mounts is LYING. I have no idea why. But the last line
there claiming that the snapshot is mounted on the "a" directory (the
"original" one) is utterly untrue. My guess is that this has something
to do with how bind mounts work?
It's acting as if I used "mount --rbind" or such, but I did not, I used
"mount --bind".
In the example above, I'm using an LV for the "root" FS ("test1"), but
in the real world that is not an LV so I can't create a snapshot from it
and avoid the bind mounting. For context, the real world thing I'm
doing here is setting up a separate set of mounts, using snapshot LVs
wherever I can, that is a copy of the system layout, to then run a
backup tool against that "snapshot" setup.
This weirdness with /proc/mounts is also, I think, causing heinous
confusion to systemd even without the snapshot LV getting full, causing
systemd to try to unmount the original directory when the snapshot
device is removed. This is super-fun on a production server when the
snapshot is of /var or /usr and thus stopping local-fs.target and
bringing down almost everything for no good reason.
--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
