From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs multiple mounts stacked on the same mount point
Date: Wed, 12 Feb 2014 05:15:24 +0000 (UTC) [thread overview]
Message-ID: <pan$783b9$6da610c9$6ead6d9b$966fb3d6@cox.net> (raw)
In-Reply-To: 52FAEC7F.4050707@oracle.com
Anand Jain posted on Wed, 12 Feb 2014 11:37:35 +0800 as excerpted:
> On 02/12/14 04:57 AM, Duncan wrote:
>> Anand Jain posted on Tue, 11 Feb 2014 16:18:02 +0800 as excerpted:
>>
>>> per mount(2)
>>>
>>> ---
>>> multiple mounts can be stacked on the same mount point.
>>> ---
>>>
>>> In this situation how could ioctl communicate (using mount point)
>>> with each FS stacked on the same mount point ?
>>>
>>> BTW I don't understand the need for multiple mounts on the same
>>> mount point ?
>>
>> That principle of over-mount obscuring what's beneath it should apply
>> to the ioctls as well. They will always communicate with the top
>> mounted layers. [Since] an over-mount obscuring under-mounts is how
>> Linux normally works[,] not being able to access under-mounts is the
>> normal state of affairs. =:^)
> In the context of btrfs,
> what is the critical need of this feature ?
> OR
> what is that it can't do without this feature ?
IMO btrfs shouldn't behave any different than any other filesystem in
this regard, and in fact, I'd /guess/ that btrfs has little to do with it
since that's surely handled at the general VFS layer, except perhaps
btrfs might need to ensure that if multiple filesystems are mounted at
the same mountpoint, the expected (that being top) one always gets the
ioctls. Anything underneath the top layer should be ignored, regardless
of whether the given mountpoint is /home and it's / underneath, or
whether it's two filesystems mounted on /home, such that the last one
mounted always gets the ioctls.
BTW, another (general) reason over-mounts are sometimes used is to
deliberately obscure what's underneath. It's worth noting that anything
with a file already open on the underlying filesystem still has access to
that file after something else is mounted over top, and that fact is
sometimes used to control access to certain files/filesystems, by
starting whatever it is that needs to access them and letting them open
the files they need, then over-mounting a different filesystem, often
empty, so no other applications can access the under-mounted files.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-02-12 5:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 8:18 btrfs multiple mounts stacked on the same mount point Anand Jain
2014-02-11 20:57 ` Duncan
2014-02-12 3:37 ` Anand Jain
2014-02-12 5:15 ` Duncan [this message]
2014-02-12 7:36 ` Anand Jain
2014-02-12 13:17 ` Duncan
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='pan$783b9$6da610c9$6ead6d9b$966fb3d6@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/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).