Messages in this thread | | | From | Dawid Ciezarkiewicz <> | Date | Fri, 29 Sep 2017 16:02:42 -0700 | Subject | Re: Read-only `slaves` with shared subtrees? |
| |
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
| |