From: Nakajima Akira <nakajima.akira@nttcom.co.jp>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3)
Date: Mon, 16 Jan 2017 10:33:40 +0900 [thread overview]
Message-ID: <90248ac2-0253-36d4-ddd0-b283373634f8@nttcom.co.jp> (raw)
In-Reply-To: <20170113032651.GF1555@ZenIV.linux.org.uk>
> 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...
prev parent reply other threads:[~2017-01-16 1:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 9:16 Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3) Nakajima Akira
2017-01-12 10:24 ` Al Viro
2017-01-13 1:40 ` Nakajima Akira
2017-01-13 3:26 ` Al Viro
2017-01-16 1:33 ` Nakajima Akira [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90248ac2-0253-36d4-ddd0-b283373634f8@nttcom.co.jp \
--to=nakajima.akira@nttcom.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).