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
