On Thu, Aug 08, 2024 at 04:20:43PM GMT, Morten Hein Tiljeset wrote: > > It's likely held alive by some random file descriptor someone has open. > > IOW, try and walk all /proc/<pid>/fd/<nr> in that case and see whether > > anything keeps it alive. > > Thanks for the suggestion, but I've already tried the equivalent of that by > using a debugger to find the superblock in question and then walking all open > fds and comparing the superblock pointer. I've validated that this approach > works in a synthetic example where I create a new namespace, mount the > filesystem under /mnt, run a program to open /mnt/foo and lazy unmount /mnt. > > Walking procfs seems less precise. I've tried iterating through /proc/*/fd/* > and comparing the Device entry of stat -L, also without luck. The file descriptor could already be closed but the task could be stuck exiting and so queued task work including destroying files wouldn't be done yet. You could also try and see if you can figure out what tasks require your workload to do a lazy umount in the first place. That might bring you closer to the root cause. What kernel version are you running anyway?
