[systemd-devel] Shared root fs by default

[Lennart Poettering]

On Fri, 05.04.13 17:27, Tvrtko Ursulin (tvrtko.ursulin at onelan.co.uk) wrote:

> 
> On Friday 05 April 2013 18:23:35 Lennart Poettering wrote:
> > On Fri, 05.04.13 17:19, Tvrtko Ursulin (tvrtko.ursulin at onelan.co.uk) 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.