Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1742390

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

Show all headers | View raw

On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz
<dawid.ciezarkiewicz@rubrik.com> wrote:
> On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai <linuxram@us.ibm.com> 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

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: Read-only `slaves` with shared subtrees? Dawid Ciezarkiewicz <dawid.ciezarkiewicz@rubrik.com> - 2017-09-30 01:10 +0200

csiph-web