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. 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.
