On Mon, Sep 29, 2014 at 7:21 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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. I don't want /mnt/foo/far to stay mounted. I do, however, want their peers, if any, to stay mounted *if /mnt is the root of a shared recursive bind mount*. > >> 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: mount --rbind / /mnt umount -l /mnt/dev to detach /dev. I expect: mount --rbind / /mnt umount -l /mnt to have no net effect. Another way of thinking about this would be that I would expect the umount -l to propogate as a unit rather than propagating as a bunch of individual unmounts. For example: mount --rbind / /mnt umount -l /mnt/dev means "detach /mnt/dev from /mnt and, due to sharing, detach /dev from /" whereas mount --rbind / /mnt umount -l /mnt means "detach /mnt from /" but does not unmount / or other things in /. IOW MNT_DETACH should only propagate detach of submounts if a umount without MNT_DETACH would propagate. In this case, mount --rbind / /mnt; umount /mnt would either fail with -EBUSY or *not* propagate because it's the root of the shared subtree. Anyway, improving the MNT_DETACH docs to recommend doing MS_PRIVATE first if you're just trying to remove an rbind would solve most of the problem. In any event, I still don't understand why we have shared recursive bind mounts in the first place. What are they used for that wouldn't be better served by slave mounts? --Andy -- 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
