linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Avantika Mathur <mathurav@us.ibm.com>,
	janak@us.ibm.com, linux-fsdevel@vger.kernel.org,
	mike@waychison.com, Miklos Szeredi <miklos@szeredi.hu>,
	viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: mount behavior question.
Date: Thu, 28 Jul 2005 15:59:07 -0700	[thread overview]
Message-ID: <1122591547.4715.193.camel@localhost> (raw)
In-Reply-To: <OF1C9E25BA.C98EFE76-ON8825704C.0078C214-8825704C.007B5A06@us.ibm.com>

On Thu, 2005-07-28 at 15:27, Bryan Henderson wrote:
> >Bryan, what would you expect the behavior to be when somebody mounts on
> >a directory what is already mounted over? 
> 
> Well, I've tried to beg the question.  I said I don't think it's 
> meaningful to mount over a directory; that one actually mounts at a name. 
> And that Linux's peculiar "mount over '.'" (which is in fact mounting over 
> a directory and not at a name) is weird enough that there is no natural 
> expectation of it except that it should fail.
> 
> But if I had to try to merge "mount over '.'" into as consistent a model 
> as possible with one of the two behaviors we've been discussing, I'd say 
> that "." stands for the name by which you looked up that directory in the 
> first place (so in this case, it's equivalent to mount ... /mnt).  And 
> that means I would expect the new mount to obscure the already existing 
> mount.

ok. maybe I am having some odd expectations here.
To me it still feels natural to tuck the mount under the earlier mount,
since you are not mounting on something which on the top, but you
are mounting  on top of something which is under(obscured).

RP


> 
> --
> Bryan Henderson                     IBM Almaden Research Center
> San Jose CA                         Filesystems


  reply	other threads:[~2005-07-28 22:59 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
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 [this message]
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=1122591547.4715.193.camel@localhost \
    --to=linuxram@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=hbryan@us.ibm.com \
    --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).