Re: losetup -d --force for zombie loop devices?

[Phillip Susi <psusi@ubuntu.com>]

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.