[lkml]   [2017]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Read-only `slaves` with shared subtrees?
On Fri, Sep 22, 2017 at 11:43 AM, Dawid Ciezarkiewicz
<> wrote:
> On Thu, Sep 21, 2017 at 12:14 PM, Ram Pai <> 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.

Dawid Ciezarkiewicz

 \ /
  Last update: 2017-09-30 01:03    [W:0.130 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site