Date:	Tue, 30 Sep 2014 03:21:33 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Removing shared subtrees?

On Mon, Sep 29, 2014 at 06:24:05PM -0700, Andy Lutomirski wrote:
> On Mon, Sep 29, 2014 at 6:14 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> > On Mon, Sep 29, 2014 at 05:36:27PM -0700, Andy Lutomirski wrote:
> >
> >> Ideally it would leave them around until the whole subtree had no
> >> references, at which point /mnt and everything under it would
> >> disappear with no side effects, because it has no references.
> >
> > So, assuming you've got a stuck NFS mount with a bunch of local stuff
> > bound on top of it, in your ideal we'd have the latter all remaining
> > mounted until the server comes back.  Lovely, that...
> 
> No, not at all.

Er...  How so?  /mnt is stuck NFS.  /mnt/foo/bar and /mnt/foo/barf have
/dev/sda1 and /dev/sda2 mounted on them.  Both are currently not busy.
/mnt is - there's that shell trying to expand *.c in /mnt/splat, sitting
around blocked with opened directory in its descriptor table.

Just how would your ideal prevent sda1 and sda2 staying mounted?  You can't
say umount /mnt/foo/bar; it'll get blocked trying to revalidate foo and
waiting for server to reply.  In real world you can say umount -l /mnt and
be done with that - everything in there becomes detached, what used to be
/mnt stays alive (but not mounted on /mnt anymore) until it ceases to be
busy.  What used to be /mnt/foo/bar and /mnt/foo/barf end up shut down
immediately (what with not being busy).  In your ideal they would stay around
until the "whole subtree" (of what?) loses all references, i.e. until that
shell closes opened directory.

> Let me try this one more time:
> 
> I don't *care* whether MNT_DETACH unmounts submounts immediately or
> when all the references are finally gone.  I didn't read the docs or
> the code to see which is the case *because I don't care*.
> 
> I think it's somewhere between ridiculous and flat-out broken that
> MNT_DETACH of the *root* of a shared subtree *propagates* the unmount
> of submounts to the parent of the shared subtree.  This is IMO
> completely bogus.

Parent in which sense?  Try to experiment with this: mount something on
/tmp/foo, then mount --rbind /tmp/foo /mnt/foo, mount something on /mnt/bar
and /tmp/bar and umount -l /mnt/foo.  Then think what does and does not
happen.

> IOW, if I do:
> 
> mount --make-rshared /
> mount --rbind / /mnt
> umount -l /mnt/dev
> 
> then I fully expect /dev to be unmounted (although I think that this
> is a misfeature).
> 
> But I did:
> 
> mount --make-rshared /
> mount --rbind / /mnt
> umount -l /mnt  <- the ROOT of the fscking shared subtree
> 
> And /dev got unmounted.  How does this make any sense at all?

Sigh... umount -l /mnt *includes* unmounting /mnt/dev.  Which you
do expect to take /dev out.  "I expect Y to cause Z; I don't care if X
causes Y; why does it end up causing W?!!!?"  Where W is vague as hell
and depending on what is meant either refers to Z or to something more
than that; in the letter case the answer would be "W isn't happening".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists