From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: Removing shared subtrees?
Date: Tue, 30 Sep 2014 01:29:48 +0100 [thread overview]
Message-ID: <20140930002948.GP7996@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CALCETrW8xvOr0WfyzqBUxZkw_PXckUh8AdGPxU3sd7=cLayPyQ@mail.gmail.com>
On Mon, Sep 29, 2014 at 05:14:55PM -0700, Andy Lutomirski wrote:
> I understand that:
>
> # mount --make-rshared /
> # mount --rbind / /mnt
> # umount - /mnt/dev
>
> should unmount /dev. That's the whole point. But why does unmounting
> */mnt* propagate like that? It doesn't unmount /. To me, this makes
> about as much sense as having 'umount -l /mnt/dev' unmount /dev/pts
> but *not* /dev would make.
Aha. And what, pray tell, does umount -l /mnt do to mounts deeper in
the tree? Forget about shared, etc. - what, in your opinion, does umount -l
mean wrt the stuff mounted on /mnt? /mnt/dev, for example...
> > What for?
>
> Simplicity and comprehensibility.
Such an elegant way to say "I can't be arsed to read"... For what it's
worth: MNT_DETACH is *not* "detach the subtree as whole, busy or not".
It's "unmount all mounts within the subtree, busy or not". At which point
the self-LART you keep describing becomes quite easy to comprehend, doesn't
it?
next prev parent reply other threads:[~2014-09-30 0:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 23:45 Removing shared subtrees? Andy Lutomirski
2014-09-30 0:09 ` Al Viro
2014-09-30 0:14 ` Andy Lutomirski
2014-09-30 0:29 ` Al Viro [this message]
2014-09-30 0:36 ` Andy Lutomirski
2014-09-30 1:14 ` Al Viro
2014-09-30 1:24 ` Andy Lutomirski
2014-09-30 2:21 ` Al Viro
2014-09-30 2:40 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140930002948.GP7996@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).