Messages in this thread | | | Date | Sat, 16 Sep 2023 10:19:02 +0800 | Subject | Re: [RFC PATCH 0/3] quering mount attributes | From | Ian Kent <> |
| |
On 15/9/23 11:06, Amir Goldstein wrote: > On Fri, Sep 15, 2023 at 4:20 AM Ian Kent <raven@themaw.net> wrote: >> On 14/9/23 14:47, Amir Goldstein wrote: >>> On Wed, Sep 13, 2023 at 6:22 PM Miklos Szeredi <mszeredi@redhat.com> 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.
| |