On 5/3/2012 12:43 AM, Mike Frysinger wrote:
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
The last time I tried this, you couldn't and that made sense because
most filesystems require exclusive access to the block device, which
they can't get with the other ghost mount still hanging around.
Mounting the same block device twice would cause massive corruption.
Now that I try it again, it appears to let you. Based on the kernel
prints, it looks like it is somehow magically reattaching the existing
mount instead of creating a new one. Oddly though, the reattached mount
can be unmounted without -l, even though it is still in use.
I'll have to test with removable media again. Presumably this new
reattach behavior would cause the contents of the old cd to show up
again while dmesg spews IO errors, which may be slightly better than the
old behavior of simply being unable to mount the drive with no
explanation as to why, but is still very much not good.
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.
If you want to hide mounts from certain processes, that is what unshare
is for. Hiding a mount from all processes does not make sense. If you
know a mount is gone and beyond recovery ( like in this loop over nfs
case, or removed media ), then it should be forcibly unmounted, not
simply made invisible and doomed to remain a zombie mount until the
system is rebooted.
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
It does, but they have been reparrented as if the filesystem was mounted
in the root, so you can't search for the files using their previous
mount point.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
