On Fri, 05.04.13 17:27, Tvrtko Ursulin ([email protected]) wrote:
> > On Friday 05 April 2013 18:23:35 Lennart Poettering wrote: > > On Fri, 05.04.13 17:19, Tvrtko Ursulin ([email protected]) wrote: > > > > Hmm, does this always happen this way, or is the MS_REC flag "sticky" > > > > and causes the MNT_DETACH to be recursive? > > > > > > > > That looks a bit like a kernel misfeature, no? > > > > > > To me it looks like the kernel is working as designed, but perhaps I am > > > not > > > getting what exactly are you asking. You can read all the details in about > > > shared mounts and event propagation in > > > Documentation/filesystems/sharedsubtree.txt. > > > > > > Use case described there is that if you clone (bind) a shared tree you > > > need to make it a slave to shut down the propagation in the backward > > > direction (it's bi-directional for shared trees by default). > > > > Well, but in your example you unmounted a bind mount with a child, and > > that resulted in the unmounting of the child in the source mount, too -- > > even though you never asked for that child mount to be unmounted. That's > > what your example showed, right? > > Yes, but as I said, after a quick glance at kernel docs I got the impression > that is what should happen. I could be wrong though. Perhaps we should try > and > drag into discussion someone who designed this. I would have assumed that it would at least fail with EBUSY as long as that submount is still there... Which wouldn't solve the issue at hand, but at least make it more obvious, since you then have to manually unmount the submounts, and then would have to think about what you are doing there... Maybe the lesson to learn here is that MS_REC is more powerful than people would expect, right? Because it duplicates mount points you don't have to explicitly know about... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
