Thank you for the suggestions. On 26/07/03 10:54AM, Raka Gunarto wrote: > 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.
Lazy unmounting, moving the mount to another location, or even techniques such as `chmod 000` (for non-root users) would all eventually drain the mount of references. My concern is slightly different. I don't want to start draining the mount immediately after observing that it has no references at a particular instant, because that alone is not strong evidence that the workload is actually inactive or ,more accurately, likely to be inactive. For example, a workload may repeatedly open a file, perform a small amount of work, close it, sleep for a short time, and then repeat. If I immediately started draining the mount every time the reference count reached zero, the system would constantly interrupt some workload. That is the whole reason behind the grace period. Rather than treating "reference count reached zero" as sufficient, I only consider the mount a possible maintenance candidate if it has remained without active references for some time. The goal is not to prove inactivity, but to make it much more likely that the workload has genuinely gone idle. > 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? Well, this is actually my direction. I even wrote a small PoC eBPF program that attaches to LSM hooks to account for opens and reject new ones during maintenance. However, it has its own challenges, specifically, some nasty races. For example, if monitoring begins after some file objects are already open, the accounting is immediately off. As a result, the design becomes closer to a best-effort mechanism than one that can guarantee a successful `umount()`. These kind of challenges are exactly the points I hope to discuss. Regards, Ali _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
