On 15/9/23 11:06, Amir Goldstein wrote:
On Fri, Sep 15, 2023 at 4:20 AM Ian Kent <raven@xxxxxxxxxx> wrote:
On 14/9/23 14:47, Amir Goldstein wrote:
On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
Implement the mount querying syscalls agreed on at LSF/MM 2023. This is an
RFC with just x86_64 syscalls.
Excepting notification this should allow full replacement for
parsing /proc/self/mountinfo.
Since you mentioned notifications, I will add that the plan discussed
in LFSMM was, once we have an API to query mount stats and children,
implement fanotify events for:
mount [mntuid] was un/mounted at [parent mntuid],[dirfid+name]
As with other fanotify events, the self mntuid and dirfid+name
information can be omitted and without it, multiple un/mount events
from the same parent mntuid will be merged, allowing userspace
to listmnt() periodically only mntuid whose child mounts have changed,
with little risk of event queue overflow.
The possible monitoring scopes would be the entire mount namespace
of the monitoring program or watching a single mount for change in
its children mounts. The latter is similar to inotify directory children watch,
where the watches needs to be set recursively, with all the weight on
userspace to avoid races.
It's been my belief that the existing notification mechanisms don't
quite fully satisfy the needs of users of these calls (aka. the need
I found when implementing David's original calls into systemd).
Specifically the ability to process a batch of notifications at once.
Admittedly the notifications mechanism that David originally implemented
didn't fully implement what I found I needed but it did provide for a
settable queue length and getting a batch of notifications at a time.
Am I mistaken in my belief?
I am not sure I understand the question.
fanotify has an event queue (16K events by default), but it can
also use unlimited size.
With a limited size queue, event queue overflow generates an
overflow event.
event listeners can read a batch of events, depending on
the size of the buffer that they provide.
So it sounds like I can get a bunch of events at once with fanotify.
I'll have to look at the code again ...
Ian
when multiple events with same information are queued,
for example "something was un/mounted over parent mntuid 100"
fanotify will merged those all those events in the queue and the
event listeners will get only one such event in the batch.
Don't misunderstand me, it would be great for the existing notification
mechanisms to support these system calls, I just have a specific use case
in mind that I think is important, at least to me.
Please explain the use case and your belief about existing fanotify
limitations. I did not understand it.
Thanks,
Amir.
