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
next prev parent 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.