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
