Example 1:
# mount /dev/sdb1 /mnt/AThis is not a bug. It's possible to mount the same filesystem on two places.
# mount /dev/sdb1 /mnt/B
Example 2:
# mount /dev/sdb1 /mnt/AThe result from both examples is the same, see /proc/self/mountinfo:
# mount --bind /mnt/A /mnt/B
# grep mnt /proc/self/mountinfoThis is very important, from kernel point of view is it the same thing. The same filesystem is mounted on two places.
48 20 8:17 / /mnt/A rw,relatime - ext4 /dev/sdb1 rw,barrier=1,stripe=64,data=ordered
49 20 8:17 / /mnt/B rw,relatime - ext4 /dev/sdb1 rw,barrier=1,stripe=64,data=ordered
The kernel does not maintain anywhere information that /mnt/B was created by bind mount (MS_BIND mount(2) syscall flags). There is not dependence between /mnt/A and /mnt/B (for example you can umount /mnt/A).
Unfortunately, the situation in the /etc/mtab file is completely different:
# grep mnt /etc/mtabThis is confusing for many users. Try:
/dev/sdb1 /mnt/A ext4 rw 0 0
/mnt/A /mnt/B none rw,bind 0 0
# umount /mnt/ADoes the information in mtab make any sense? I don't think so... Keep this kind of information in userspace is mistake. Yeah, mtab is evil.
# rm -rf /mnt/A
# grep mnt /etc/mtab
/mnt/A /mnt/B none rw,bind 0 0
Everyone who uses bind mounts on system without mtab (where mtab is symlink to /proc/mounts) has to undestand that "bind" flag is no more stored anywhere. For example you have to explicitly add the flag to the mount options if you want to use read-only bind mount.
# rm -f /etc/mtab(or install Fedora 15:-)
# ln -s /proc/mounts /etc/mtab
Let's use findmnt(8) rather than grep /proc/self/mountinfo:
# findmnt -o TARGET,VFS-OPTIONS,FS-OPTIONS /dev/sda1What will happen if we try to remount with bind flag? See:
TARGET VFS-OPTIONS FS-OPTIONS
/mnt/A rw,relatime rw,errors=continue,user_xattr,acl,barrier=0,data=ordered
/mnt/B rw,relatime rw,errors=continue,user_xattr,acl,barrier=0,data=ordered
# mount -o remount,ro,bind /mnt/BThe filesystem (superblock) is still read-write, but the /mnt/B mountpoint is in VFS marked as read-only.
# findmnt -o TARGET,VFS-OPTIONS,FS-OPTIONS /dev/sda1
TARGET VFS-OPTIONS FS-OPTIONS
/mnt/A rw,relatime rw,errors=continue,user_xattr,acl,barrier=0,data=ordered
/mnt/B ro,relatime rw,errors=continue,user_xattr,acl,barrier=0,data=ordered
And now the same thing without the bind flag:
# mount -o remount,ro /mnt/Bthe superblock has been remounted read-only, so the filesystem is read-only everywhere in the system.
# findmnt -o TARGET,VFS-OPTIONS,FS-OPTIONS /dev/sda1
TARGET VFS-OPTIONS FS-OPTIONS
/mnt/A rw,relatime ro,errors=continue,user_xattr,acl,barrier=0,data=ordered
/mnt/B ro,relatime ro,errors=continue,user_xattr,acl,barrier=0,data=ordered
Again, all this is possible independently on the way how /mnt/B has been mounted to the system (examples 1 and 2).
BTW, you can also set the block device as read-only by blockdev --setro. So we have three layers (device -> FS -> VFS) where is possible to set read-only attribute :-)
Oh. I see.
ReplyDeleteThanks for an informative post!
Is it possible to get inotified (or similar) when a filesystem is remounted as read-only due to a file system error?
ReplyDelete