Re: Read-only `slaves` with shared subtrees?

[Dawid Ciezarkiewicz]

On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz
<dawid.ciezarkiewicz@xxxxxxxxxx> wrote:
> On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai <linuxram@xxxxxxxxxx> wrote:
>> Here is a patch that accomplishes the job. tested to work with
>> some simple use cases.  check if this works for you. If it does
>> than we will have to think through all the edge cases and make it
>> acceptable.
>
> From your experiments, it looks exactly right.
>
> I'll give it a try in the upcoming week. Thank you!


I've reproduced your setup and results.

I've played with it for a while, mostly checking some recursive mount scenarios.
My biggest concern is transitivity of the RO attribute. Once a root of
slave directory
is set to be RO + STICKY, it is very important that host directories
propagated there,
even recursively (rslave), or any other, are not RW. From what I was
able to test, everything
seemed OK, but I don't grok all the semantics around it, so I'm just
pointing it out, as I might
have missed something.

One thing that I don't plan to use, but might be worth thinking about is
 `slave + RW + STICKY` combination.  If `master` mounts something RO,
and `slave`
is `RW + STICKY`, should the mount appear RW inside the slave? I don't
find it particularly useful,
but still...

Another thing that popped into my head: Is it worth considering any
dynamic changes to `slave`'s
RO status? It complicates everything a lot (it seems to me), since it
adds a retroactive
dynamic propagation. I don't currently have any plans to use it, but I
could imagine scenarios
in which a slave mount with all it's sub-mounts is remounted from RO
to RW, in response to
some external authorization trigger.

Regards,
Dawid Ciezarkiewicz