linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).