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 13:09:18 -0700 [thread overview]
Message-ID: <1122581358.4715.152.camel@localhost> (raw)
In-Reply-To: <E1DyE53-0003j2-00@dorka.pomaz.szeredi.hu>
On Thu, 2005-07-28 at 12:30, Miklos Szeredi wrote:
> > 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.
>
> I really fail to see what you are getting at.
>
> You agree that:
>
> 1) mount doesn't propagate from /mnt/1 to /mnt/2/1.
>
> 2) mount propagates from /mnt/2/1 to /mnt/1.
Yes I agree.
>
> Then you are surprised that you don't see the same thing if you mount
> on /mnt/1 as if on /mnt/2/1.
I am not surprised when mounts on /mnt/1 do not propogate to /mnt/2/1
This is expected, and I am perfectly happy. Because the mount is
attempted on 'B' and 'B' has nobody to propogate to.
when mount on /mnt/2/1 (i.e on C at dentry 1) is attempted, I expect
to see a new mount 'E' at that dentry. That is happening and
I am happy with it.
I also expect that the mount propogates to /mnt/1 too (i.e on 'A' at
dentry '1'). Because 'C' and 'A' have propogation setup.
But what I also expect to see is: the new mount 'F' at /mnt/1 ( mount A
at dentry 1) be obscured by the already existing mount on /mnt/1 i.e
mount 'B'.
And the reason I want the new mount at /mnt/1 (i.e 'F') obscured is that
the new mount is not done on 'B' but is done on 'A'.
The "most recent mount rule" makes 'B' obscured instead of 'F'
and I am expecting "the topmount visible rule" to be applicable
here which makes 'B' still visible and 'F' obscured.
Ah...its so hard without a whiteboard :( I wish there was some way to
explain it drawing some objects on the whiteboard.
I guess, I have got all the letters and the words right. Any small
mistake can distort everything. If somebody is wondering why there is
no 'D' that is because it was used for something else in the earlier
example and hence not used here.
RP
>
> I think your proposed solution would be _more_ confusing not less,
> since then I'd not see the expected propagation from /mnt/2/1 to
> /mnt/1. I'd call that a bug.
>
> Miklos
next prev parent reply other threads:[~2005-07-28 20:09 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
2005-07-28 19:30 ` Miklos Szeredi
2005-07-28 20:09 ` Ram Pai [this message]
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=1122581358.4715.152.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