Re: btrfs multiple mounts stacked on the same mount point

[Anand Jain <Anand.Jain@oracle.com>]

  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. =:^)
>