Anand Jain posted on Wed, 12 Feb 2014 15:36:48 +0800 as excerpted: >> BTW, another (general) reason over-mounts are sometimes used is to >> deliberately obscure what's underneath. It's worth noting that >> anything with a file already open on the underlying filesystem still >> has access to that file after something else is mounted over top, and >> that fact is sometimes used to control access to certain >> files/filesystems, by starting whatever it is that needs to access them >> and letting them open the files they need, then over-mounting a >> different filesystem, often empty, so no other applications can access >> the under-mounted files. > > Thanks. Makes sense theoretically. Any eg of real practical > application ? Any product in the market using it that way ? At least from here over-mount-to-prevent-access seems more like an admin technique than something someone would ship in a product. And yes, while I don't know of any specific product using the technique, I've certainly read of admins using the trick -- that's actually how I knew about it myself. > looks btrfs-progs shouldn't depend on the mnt-point driven ioctls to > manage the FS. Now that's a set of challenges. I don't really see why not. Why would one /need/ to issue ioctls to an under-mounted filesystem that's not otherwise accessible (except to apps with files on it opened before a different filesystem was over-mounted on top), and why wouldn't the ordinary rules of umounting the over-mount in ordered to access it if necessary, not apply? In general, I think most admins are used to the general limitation, and I doubt it would even occur to most of them to try to (for example) run a balance or check the free space on a filesystem they can't otherwise access, because that sort of thing is in most cases simply not possible. And if for some reason one were to need such an arrangement, that's what bind/move/shared-mounts are for. (See the mount (8) manpage and $KERNDIR/ Documentation/filesystems/sharedsubtree.txt.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
