- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you
umount -l /media/hdd you will no longer be able to access
/media/hdd/dir/file (absolute pathname) but if you have a process with working directory
/media/hdd it will still be able to create new processes which can read/write
./dir/file (relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though
lsof +f -- /dev/device shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
If you do
umount -l a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a
umount -l is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdc. The kernel log messages may still refer to
/dev/sdb even though that device no longer exists as a file under
/dev. (The only way I know to resolve this is to reboot.)
btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).