On Tuesday 01 May 2012 11:23:42 Phillip Susi wrote: > On 4/30/2012 4:07 PM, Mike Frysinger wrote: > > `umount -l` has its place -- there are cases where you want those > > semantics. granted, most people actually want a `umount -f`, but the two > > aren't mutually exclusive. > > If you want to prevent processes from opening new files on the mount > point, it would be much more sane to mount --move it somewhere hidden. there's really no difference at all here. the active process will still have the same capabilities to modify their open handles, and attempting to open new paths in the fs will fail because they'll be expecting the mount at one place but you relocated it elsewhere (ignoring the accesses down via the *at funcs which will work the same). > When you detach it entirely from the namespace, you can't even be aware > that the mount still exists, let alone change your mind and reattach it. you can re-attach it by mounting it again > Having a device that is still mounted, but appears not to be to all > tools that normally check for such things ( partitioning tools, auto > mounters, etc ) is broken. conversely, having a mount point removed from the perspective of userspace can be useful. like with tools that stubbornly enumerate all mounts, or attempting to shutdown your system with known unreachable network mounts. you, as the admin, know these things are gone and beyond accessible, so having the ability to remove them all manually and reboot cleanly (w/out ridiculous long retries/timeouts) is a good thing. > It is very confusing when you later try to change the cd in the drive > and can't mount it because the old one is still mounted, yet lsof, > mount, etc offer no evidence that this is the case, and you can't track > down the process that is still holding an open fd and kill it. are you sure that's true ? `lsof -n` seems to report open handles to unmounted filesystems to me. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
