On Tue, Jan 25, 2005 at 02:02:43PM -0800, Ram wrote: > oops. I had the following in mind. > > mount <device1> /tmp/mnt1 > ** mount --make-shared /tmp/mnt1 ** > mkdir -p /tmp/mnt1/a/b > mount --rbind /tmp/mnt1 /tmp/mnt2 > mount --make-slave /tmp/mnt2 > > In this case it cannot be EINVAL, because /tmp/mnt1 and /tmp/mnt2 will > both be part of a pnode and hence /tmp/mnt2 can be demoted to be a > slave. > > > > > mount <device2> /tmp/mnt2/a > > > rm -f /tmp/mnt2/a/* > > > > > > what happens when a mount is attempted on /tmp/mnt1/a/b? > > > will that be reflected in /tmp/mnt2/a ? > > > > > > I believe the answer is 'no', because that part of the subtree > > > in /tmp/mnt2 no more mirrors its parent subtree.
shared subtrees aside, it is the nature of --bind mounts that they share all the same dentries; so the "rm -f" above will immediately be reflected in all copies (with or without subtree sharing) and no mounts will be possible on the (now absent) path a/b. I think the question you meant to ask was what would happen if you mounted something on /tmp/mnt2/a/b (the slave copy) and then mounted something else on /tmp/mnt1/a/b. In that case there's two places where the propagated mount might go: 1. On top of the dentry a/b in /tmp/mnt2, underneath the preexisting mount. 2. On top of the root dentry of the thing mounted in /tmp/mnt2/a/b, thus covering the preexisting mount. Wouldn't option 1 require changing the mnt_parent of the preexisting mount on /tmp/mnt2/a/b? That seems like an odd thing to do, so I assume option 2 is the only possible solution, but perhaps I'm missing something. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html