All of lore.kernel.org
 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 08:02:19 -0700	[thread overview]
Message-ID: <1122562938.4715.71.camel@localhost> (raw)
In-Reply-To: <E1Dy6zl-00030c-00@dorka.pomaz.szeredi.hu>

On Thu, 2005-07-28 at 04:56, Miklos Szeredi wrote:
> > Here is a scenario with shared subtree. Sorry it is complex.
> > 
> > 
> > mount --bind /mnt /mnt
> > mount --make-shared /mnt
> > mkdir -p /mnt/p
> > mount --bind /usr  /mnt/1
> > mount --bind /mnt  /mnt/2
> > 
> > At this stage the mount at /mnt/2 and /mnt belong to the same pnode
> > which means mounts under them propogate to each other.
> > 
> > mount --bind /var /mnt/1
> > 
> > the contents of /var will be visible under /mnt/1 and not under /mnt/2
> > But if mount --bind /var /mnt/2 is executed, the contents of /var is
> > visible under /mnt/1 as well as /mnt/2 . Isn't this freaky?
> 
> I don't understand.
> 
> 'mount --bind /var /mnt/1' should propagate to /mnt/2/1, not /mnt/2. 

yes it should propogate to /mnt/2/1 , thats what I meant when I said
under /mnt/2, but yes I was not clear. Hope I have a clearer
explanation below.

>  No?
> 
> 'mount --bind /var/ /mnt/2' should propagate to /mnt.  What am I
> missing?


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
i.e on top of 'C' at dentry '2'  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


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. If the 'top-most mount rule' is applied
'F' though mounted on 'A', will not be visible because it will get 
obscured by 'B' and the confusion is avoided.

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'?
RP


> Miklos


  reply	other threads:[~2005-07-28 15:02 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-25 22:44 Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-27 19:54   ` [PATCH 1/7] shared subtree 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 [this message]
2005-07-28 15:58             ` Miklos Szeredi
2005-07-28 18:22               ` Ram Pai
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
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44   ` (unknown) Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
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
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44   ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44   ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44 ` (unknown) Ram Pai
2005-07-25 22:44 ` Ram Pai
2005-07-25 22:44   ` (unknown) Ram Pai
2005-07-26  2:53 ` supposed to be shared subtree patches Ram Pai

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=1122562938.4715.71.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.