Messages in this thread | | | Subject | Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3) | From | Nakajima Akira <> | Date | Mon, 16 Jan 2017 10:33:40 +0900 |
| |
> 120 116 252:1 /home/b /mnt rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > 121 61 252:1 /home/b /home/a rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered
Thanks for your polite explanation. I can understand this is correct kernel specification and above Fedora18 and RHEL7.0 is using shared mount as default.
I should have done it as follows.
# mount --make-private --bind a /mnt # mount --make-private --bind b /mnt # ls -i 100 a 999 b
# tali /proc/self/mountinfo 200 59 8:3 /home/a /mnt rw,relatime - ext4 /dev/sda3 rw,stripe=64,data=ordered 205 200 8:3 /home/b /mnt rw,relatime - ext4 /dev/sda3 rw,stripe=64,data=ordered
On 2017/01/13 12:26, Al Viro wrote: > On Fri, Jan 13, 2017 at 10:40:08AM +0900, Nakajima Akira wrote: >> On 2017/01/12 19:24, Al Viro wrote: >>> On Thu, Jan 12, 2017 at 06:16:35PM +0900, Nakajima Akira wrote: >>>> Bug: >>>> Duplicate inode number when mount --bind some directories to same >>>> mountpoint. (from Fedora18 to 4.10-rc3) >>>> Fedora17 and earlier works correctly. >>> >>> Explain, please. "Duplicate inode number" between what and what? >> >> Duplicate inode number between mounted directories. >> >> Example) >> # cd /home >> # mkdir a b >> # ls -i >> 100 a 999 b >> # mount --bind a /mnt >> # mount --bind b /mnt >> # ls -i >> 999 a 999 b >> >> Inode number of directory "a" is changed to "b". >> Then we see directory "b" when ls "a". > > 61 0 252:1 / / rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > > Root, marked shared (peer group 1). /home is not a mountpoint, /mnt > wasn't one until your mounts (i.e. both are within the same mount as /). > > Since /home/a is a subtree of a shared mount, any clone of it will, by > default, join the same peer group. Which means that binding it on /mnt > results in > > 116 61 252:1 /home/a /mnt rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > > i.e. ext4[vda1]home/a being mounted on /mnt and marked peer of root mount. > Accordingly, any mount/umount event in either will be duplicated to all > peers (provided that they contain a counterpart of affected mountpoint). > In particular, binding /home/b on /mnt (i.e. on top of ext4[vda1]home/mnt) > propagates to the corresponding points in all peers - including the root > mount, where it corresponds to /home/a. Result: > > 120 116 252:1 /home/b /mnt rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > 121 61 252:1 /home/b /home/a rw,relatime shared:1 - ext4 /dev/vda1 rw,data=ordered > > The same tree (ext4[vda1]home/b) is mounted on root in mount 116 > (i.e. the thing found on /mnt) and on /home/a in mount 61 (i.e. /home/a). > > Since /home/b is on a shared mount, both clones are put in the same peer > group (i.e. the same group 1). > > You asked for it, you've got it... Well, fedora folks did, actually. > I'm none too fond of their default setup (root made shared), but that has > nothing to do with the kernel. Userland (systemd, as far as I can tell) > is setting the things up that way, and it's even documented in fedora > release notes... Kernel mechanisms involved in that had been there for > a long time and they are also documented (man 2 mount, look for MS_SHARED > and related flags in there). > > Take it up with fedora folks...
| |