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.ev...@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). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/