Re: Seeking guidance on detecting mount point inactivity

From: Ali Nasrolahi <a.nasrolahi01@gmail.com>
To: Raka Gunarto <rakagunarto@gmail.com>
Cc: Richard <richard_siegfried@systemli.org>,
	kernelnewbies@kernelnewbies.org
Subject: Re: Seeking guidance on detecting mount point inactivity
Date: Sun, 5 Jul 2026 08:34:06 +0330	[thread overview]
Message-ID: <aknbW9m52mfTLSXY@zephyr> (raw)
In-Reply-To: <CACUOwmKRgj8Z+JoNRsFRPR5gOAGsLqcDSMtKepBaGOE-q-fWiw@mail.gmail.com>

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
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies