On Fri, Jul 3, 2026 at 10:05 AM Ali Nasrolahi <[email protected]> wrote: > > > Thank you for taking the time to reply. > > My maintenance is actually tied to the VFS rather than the block layer. > Ultimately I have to determine when an `umount()` is likely to succeed, > which isn't necessarily the same as "no block I/O." > > For example, a process may still hold an open file or other kernel reference > on the mount while generating no bio activity at all, in which case > `umount()` would still fail. > On the other hand, even with determining the no block activity, I > still need some mechanism > to prevent new accesses from racing with the maintenance process. >
Is moving the mount to another path or lazy unmount not an option? After moving the mount, you can wait until there are no more open handles (since all subsequent open calls would be blocked). Then you can do your operations and then restore the mount at the original location. Lazy unmounting would work the same way, wait until it properly unmounts, and then you remount at your maintenance location. If you don't want to disrupt currently running operations, you could use the fanotify API and keep track of events and determine an activity threshold to move the mount / lazy unmount. Or perhaps an eBPF program that hooks into the FS tracepoints? If your workloads can afford to wait indefinitely during an open() call, you can also just use the fanotify API to delay any calls to open() until your maintenance program finishes too, this wouldn't require moving the mount or unmounting. Raka _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
