btrfs multiple mounts stacked on the same mount point

btrfs multiple mounts stacked on the same mount point

[Anand Jain]

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 ?

  Any idea. ?

Thanks Anand

Re: btrfs multiple mounts stacked on the same mount point

[Duncan]

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 ?

The most common case of multiple over-mounts is almost certainly the 
kernel's built-in rootfs in RAM, usually as an initramfs or initrd, with 
real-root often directly over-mounted the same mountpoint, tho it can 
also be mounted elsewhere on the initramfs.

The various union-filesystem solutions also directly use over-mounting, 
with the read-only mount often directly over-mounted with the writable 
but semi-transparent overlay, such that if a file hasn't changed from the 
read-only version on the under-mount, that's the version that gets used.

Otherwise, over-mounts generally obscure what's underneath them, making 
direct access to it impossible, unless that underneath filesystem is bind-
mounted elsewhere.

(Which is actually how I backup my root filesystem, using a bind-mount to 
mount it elsewhere for the backup, so for instance the /dev/console and 
/dev/null device nodes located directly on root get copied over to my 
backup root as well, instead of the devtmpfs content otherwise over-
mounted on /dev.)

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.  To communicate with anything underneath, the over-mounting 
layers will either need umounted, or (if it's not the exact same 
mountpoint, which might have been your point) a bind-mount of the under-
mount can be used.

But an over-mount obscuring under-mounts is how Linux (and I believe POSIX 
in general) normally works.  (The semi-transparent union-filesystem 
solutions mentioned above thus being exceptions with those exceptions 
being the hairy bits, that explaining the several implementations with 
their various limitations and bugs.)  So not being able to access under-
mounts is the normal state of affairs. =:^)

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

Re: btrfs multiple mounts stacked on the same mount point

[Anand Jain]

  Thanks.

  In the context of btrfs,
   what is the critical need of this feature ?
    OR
   what is that it can't do without this feature ?

Thanks, Anand


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 ?
>
> The most common case of multiple over-mounts is almost certainly the
> kernel's built-in rootfs in RAM, usually as an initramfs or initrd, with
> real-root often directly over-mounted the same mountpoint, tho it can
> also be mounted elsewhere on the initramfs.
>
> The various union-filesystem solutions also directly use over-mounting,
> with the read-only mount often directly over-mounted with the writable
> but semi-transparent overlay, such that if a file hasn't changed from the
> read-only version on the under-mount, that's the version that gets used.
>
> Otherwise, over-mounts generally obscure what's underneath them, making
> direct access to it impossible, unless that underneath filesystem is bind-
> mounted elsewhere.
>
> (Which is actually how I backup my root filesystem, using a bind-mount to
> mount it elsewhere for the backup, so for instance the /dev/console and
> /dev/null device nodes located directly on root get copied over to my
> backup root as well, instead of the devtmpfs content otherwise over-
> mounted on /dev.)
>
> 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.  To communicate with anything underneath, the over-mounting
> layers will either need umounted, or (if it's not the exact same
> mountpoint, which might have been your point) a bind-mount of the under-
> mount can be used.
>
> But an over-mount obscuring under-mounts is how Linux (and I believe POSIX
> in general) normally works.  (The semi-transparent union-filesystem
> solutions mentioned above thus being exceptions with those exceptions
> being the hairy bits, that explaining the several implementations with
> their various limitations and bugs.)  So not being able to access under-
> mounts is the normal state of affairs. =:^)
>

Re: btrfs multiple mounts stacked on the same mount point

[Duncan]

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

Re: btrfs multiple mounts stacked on the same mount point

[Anand Jain]

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


  Thanks. Makes sense theoretically. Any eg of real practical 
application ? Any product in the market using it that way ?


  looks btrfs-progs shouldn't depend on the mnt-point driven ioctls
  to manage the FS. Now that's a set of challenges.


Thanks, Anand

Re: btrfs multiple mounts stacked on the same mount point

[Duncan]

Anand Jain posted on Wed, 12 Feb 2014 15:36:48 +0800 as excerpted:

>> 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.
> 
>   Thanks. Makes sense theoretically. Any eg of real practical
> application ? Any product in the market using it that way ?

At least from here over-mount-to-prevent-access seems more like an admin 
technique than something someone would ship in a product.  And yes, while 
I don't know of any specific product using the technique, I've certainly 
read of admins using the trick -- that's actually how I knew about it 
myself.

>   looks btrfs-progs shouldn't depend on the mnt-point driven ioctls to
>   manage the FS. Now that's a set of challenges.

I don't really see why not.  Why would one /need/ to issue ioctls to an 
under-mounted filesystem that's not otherwise accessible (except to apps 
with files on it opened before a different filesystem was over-mounted on 
top), and why wouldn't the ordinary rules of umounting the over-mount in 
ordered to access it if necessary, not apply?  In general, I think most 
admins are used to the general limitation, and I doubt it would even 
occur to most of them to try to (for example) run a balance or check the 
free space on a filesystem they can't otherwise access, because that sort 
of thing is in most cases simply not possible.

And if for some reason one were to need such an arrangement, that's what 
bind/move/shared-mounts are for.  (See the mount (8) manpage and $KERNDIR/
Documentation/filesystems/sharedsubtree.txt.)

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