Hi On Tue, Jun 30, 2026 at 2:21 PM Richard <[email protected]> wrote: > > Hi, > > On 25/06/2026 16:37, Ali Nasrolahi wrote: > > Hello everyone, > > > > I am working on a problem involving managing some number of filesystem > > mounts (~1000+) and determining when a mount becomes inactive to do some > Honestly this does not sound like a good/sane setup to start with. Maybe > zooming out and solving the overall requirement with a different setup > might be smarter. > > > To be specific, the goal is to detect when a mounted filesystem has no > > remaining active file usage, and after it remains inactive for some > > period (e.g. 10 seconds), > > transition it into a state where new file opens are blocked so that > > maintenance operations can safely proceed. > > It must handle concurrent access from arbitrary applications, so > > correctness under races is quite challenging. > > Why do you care about the filesystem level? If this is about device > maintendance device activity might be more relevant than fs activity. > (Remember there is caching and lots of other abstraction). It might also > be easier to track bio requests for a specific device on the device level. > > I don't know tools from the top of my head but I'm sure there are files > for this in /sys/. There is also iotop and you can see its source code > where it gets its info from. I'd also recommend reading brendan greggs > System Performance book. It has 2 chapters on disks and block I/O, I'm > sure you'll find good diagnostic tools there. > > Best, > -- Richard
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. Also, the maintenance itself is also not necessarily related to the underlying block device. In my use case, I often don't need to take the device offline at all. For example, I want to unmount a logical volume on one node and activate it on another node in a cluster, or temporarily unmount a loopback-backed filesystem so that the backing file can be moved or backed up. Also, I do appreciate your suggestion on System Performance, I would surely check it out. Regards, Ali _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
