Re: [RFC] shared subtrees

[J. Bruce Fields]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/