On Thu, 2005-07-28 at 08:58, Miklos Szeredi wrote:
> > step 1: mount --bind /mnt /mnt
> >             a new mount 'A' is created at /mnt
> > 
> > step 2: mount --make-shared /mnt
> >            mounts under 'A' are made shared. But in this case
> >        there are no other mounts. So only 'A' will be made shared.
> >           
> >          
> > step 3: mkdir -p /mnt/1 /mnt/2
> >             nothing special here
> >             
> > step 4: mount --bind /usr  /mnt/1
> >                 a new mount 'B' is created  at /mnt/1 which is
> >              'shared;.
> >                             
> > 
> > step 5: mount --bind /mnt  /mnt/2
> > 
> >             a new mount 'C' is created at /mnt/2
> >             and propogation is set between 'A' and 'C'.
> >             note: 'C' is made shared.
> > 
> > 
> > 
> > lets say, at this point I try 
> >             mount --bind /var /mnt/1
> > 
> >     this is going to mount 'D' on top of mount 'B'.  However
> >     there is no other mount to which 'B' propogates to. So that is 
> >     it. the contents of /var is only visible at /mnt/1 and it
> >      propogates no where else.
> > 
> > but lets say, we tried mount --bind /var /mnt/2/1
> >     /mnt/2/1 belongs to mount 'C'. And mounts under 'C' propogates to 'A'
> > too. So in this case a new mount 'E' is created at mnt/1/2
> 
> You mean /mnt/2/1
> 
> > i.e on top of 'C' at dentry '2'
> 
> On dentry '1'
> 
> > and due to propogation a new mount 'F' is created at /mnt/1 i.e on
> > top of mount 'A' at dentry '1' But note: /mnt/1 already has a mount
> > 'B' on top of it.  The new mount 'F' as per the 'most-current mount
> > rule' obscures 'B' even though the mount is on top of 'A'. As a
> > result the contents of /var are now visible both at /mnt/2/1 and
> > /mnt/1
> 
> True.  
> 
> > Ok the net effect is, mount at /mnt/1 is visible only under /mnt/1
> > but mount at /mnt/2/1 is visible at mount /mnt/2/1 and /mnt/1
> > This makes it confusing.
> 
> But this asymmetry is caused by the fact that mounts from /mnt/1 (B)
> don't propagate, while mounts from /mnt/2/1 (C) do.  And not because
> of the mount lookup semantics you want to change.  That change in fact
> would only _hide_ the asymmetry and not fix it: there would be
> propagation in one case and no propagation in the other.

no. there is no asymmetry as such. the propogations are working the way
they are meant to. But the confusion arises because of the mount lookup
symantics.  The reason Avantika(who is doing shared subtree testing),
had this exact confusion is because of the 'most-recent-mount visible'
rule. I dont think this rule is documented anywhere. And the natural
response to such a behavior is confusion.

> 
> If you did before step 4 in another shell 'cd /mnt/1', then after step
> 5 you did 'mount --bind /var .', that would have had the same
> symmetric effect as the 'mount --bind /var /mnt/2/1'.
> 
> > So the point I am driving at is, is there any special reason 
> > for having 'most-recent mount visible rule' instead of 'top-most mount
> > visible rule'?
> 
> I don't think, that 'topmost mount is visible' is any more logical
> than 'latest mount is visible'.  The fact that the later has been in
> the kernel for a long time means, that there may be systems relying on
> this behavior, and changing it would break them.

No I wont change this behavior. But this is something that will be a
source of confusion (probably misinterpreation to be a bug) as shared
subtrees use become more prominently used.

RP
> 
> Miklos
> -
> 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

-
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

Reply via email to