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@xxxxxxxxxxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
