Hi, The admittedly quirky mount setup mentioned in the subject line produces a questionable result on 3.18, and a different but also questionable result on 3.19. I'd like to understand if this is a kernel bug, or simply something that userspace should be responsible for managing better. The context is an initramfs, which has mounts root partition at /sysroot. The actual regular filesystem that we want to boot from is in the /fs subdirectory of that mount. This setup is achieved from the initramfs as follows: 1. /sysroot is mounted as normal. /proc/mounts has: /dev/sda1 /sysroot ext4,relatime,data=ordered rw 0 0 2. /sysroot/fs is bind-mounted at /sysroot/fs. Now it can be treated as its own mount point. /proc/mounts now has: /dev/sda1 /sysroot ext4,relatime,data=ordered rw 0 0 /dev/sda1 /sysroot/fs ext4,relatime,data=ordered rw 0 0 3. /sysroot/fs is MS_MOVE'd to /sysroot /dev/sda1 /sysroot ext4,relatime,data=ordered rw 0 0 /dev/sda1 /sysroot ext4,relatime,data=ordered rw 0 0 Code: https://gist.github.com/dsd/0a7efb0f5a101346335b (This is a simplified version of what ostree does) At this point, I can unmount /sysroot twice, and we're back to where we've started. But now, to continue the life of the initramfs and switch to the root filesystem, considering 3.18 behaviour: # switch_root /sysroot /bin/bash # cat /proc/mounts [...] /dev/sda1 /sysroot ext4,relatime,data=ordered rw 0 0 /dev/sda1 / ext4,relatime,data=ordered rw 0 0 >From this point it is now impossible (as far as I can see) to totally clean up those mounts. For example, # umount /sysroot umount: /sysroot: not mounted And if I switch_root again into another ramdisk, one of the /sysroot mounts is still listed, and I still can't find a way to unmount it. e2fsck then refuses to run on this device because /proc/mounts says the device is mounted. This behaviour changed for 3.19 with this commit: commit 9d4d65748a5ca26ea8650e50ba521295549bf4e3 Author: Dmitry V. Levin <ldv@xxxxxxxxxxxx> Date: Tue Dec 16 06:59:37 2014 +0300 vfs: make mounts and mountstats honor root dir like mountinfo does Now the "ghost" mount is no longer shown in /proc/mounts, but I'm not sure if that is really a solution to this issue, as I imagine the mount is still there, just the above commit hides it from my view. Is this an issue that should be addressed in the kernel, or is this a case where userspace has lots of power but is simply expected to tread carefully? I can't find an appropriate place in the above sequence where userspace could unmount one of the /sysroot mounts, but if I change it to avoid creating the bind mount inside the parent mount, I have found a point at which we can unmount /sysroot and avoid the ghost mount going forward while still achieving the desired end result: 1. /sysroot is mounted as normal. 2. /sysroot/fs is bind-mounted at /sysroot2. 3. /sysroot is unmounted 4. /sysroot2 is MS_MOVE'd to /sysroot Thanks for any insight! Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
