umount -f Device or resource busy; already tried: mount, lsof, fuser, exportfs, ps axf, dmsetup table, losetup -a

umount -f Device or resource busy; already tried: mount, lsof, fuser, exportfs, ps axf, dmsetup table, losetup -a

[Michael Evans]

I am posting with hope to improve the reliability and usability of
unmounting 'busy' filesystems (for which umount -f doesn't work and no
remedy is known).

There are no apparent resource holders but the device is still 'busy'. (
http://serverfault.com/questions/591406/umount-device-or-resource-busy-alrea
dy-tried-mount-lsof-fuser-exportfs-ps ), including:

* mount | grep /tmp/
* lsof | grep /tmp/
* fuser -m /tmp/...
* exportfs -rv | grep /tmp/
* Restarting the daemon which runs the creation scripts anyway...
* ps axf | grep /tmp/
* dmsetup table
* losetup -a
* fuser -vm /tmp/tmp.random-chars/ (yields two lines)
##                        USER PID    ACCESS COMMAND
## /tmp/tmp.random-chars: root kernel mount  /tmp/tmp.random-chars

Is there /any other/ test which might reveal what is keeping the device busy
(so I can end their existence)?
Is there anything more forceful than 'umount -f' to really just sync what's
possible to a specific device and invalidate all remaining file handles,
buffers, etc?

Failure is always be an option.  However in this case failing to allow
failure would require an entire VM host reboot during the next maintenance
window.


Thank you in advance for your time and ideas.  Please either reply to my
work email address <michael.evans@nor-consult.com> or at the above
serverfault link; optionally CC the list for the archives.  I'll also update
the main post on the serverfault page with any additional tests and
highlight any that yield useful information for future search engine users.

PS: Even if your reply is after our next maintenance window, I'll continue
updating the serverfault post with test for future users (more quickly if
directly emailed as well).