linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Andrew Morton <akpm@osdl.org>,
	viro@parcelfarce.linux.theplanet.co.uk,
	Avantika Mathur <mathurav@us.ibm.com>,
	mike@waychison.com, janak@us.ibm.com,
	linux-fsdevel@vger.kernel.org
Subject: Re: mount behavior question.
Date: Thu, 28 Jul 2005 11:22:38 -0700	[thread overview]
Message-ID: <1122574958.4715.108.camel@localhost> (raw)
In-Reply-To: <E1DyAmQ-0003MC-00@dorka.pomaz.szeredi.hu>

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2005-07-28 18:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-25 22:44 (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-26  2:53 ` supposed to be shared subtree patches Ram Pai
     [not found] ` <20050725225908.031752000@localhost>
2005-07-27 19:13   ` [PATCH 3/7] shared subtree Miklos Szeredi
2005-07-27 20:30     ` Ram Pai
2005-07-28  8:34       ` Miklos Szeredi
     [not found] ` <20050725225907.007405000@localhost>
2005-07-27 19:54   ` [PATCH 1/7] " Miklos Szeredi
2005-07-27 21:39     ` Ram Pai
2005-07-28  7:35       ` mount behavior question Ram Pai
2005-07-28 11:56         ` Miklos Szeredi
2005-07-28 15:02           ` Ram Pai
2005-07-28 15:58             ` Miklos Szeredi
2005-07-28 18:22               ` Ram Pai [this message]
2005-07-28 19:30                 ` Miklos Szeredi
2005-07-28 20:09                   ` Ram Pai
2005-07-28 20:44                     ` Miklos Szeredi
2005-07-28 20:59                       ` Ram Pai
2005-07-28 18:27         ` Bryan Henderson
2005-07-28 19:01           ` Miklos Szeredi
2005-07-28 20:35             ` Bryan Henderson
2005-07-28 20:42               ` Ram Pai
2005-07-28 22:27                 ` Bryan Henderson
2005-07-28 22:59                   ` Ram Pai
2005-07-28 20:53               ` Miklos Szeredi
2005-07-28 22:51                 ` Bryan Henderson
2005-07-28  9:57       ` [PATCH 1/7] shared subtree Miklos Szeredi
2005-07-29 19:54         ` Ram Pai
2005-07-30  5:39           ` Miklos Szeredi
2005-07-31  0:45             ` Ram Pai
2005-07-31  7:52               ` Miklos Szeredi
2005-07-31  8:25                 ` Miklos Szeredi

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=1122574958.4715.108.camel@localhost \
    --to=linuxram@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=janak@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mathurav@us.ibm.com \
    --cc=mike@waychison.com \
    --cc=miklos@szeredi.hu \
    --cc=viro@parcelfarce.linux.theplanet.co.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).