On Mon 18-11-24 07:29:42, Ian Kent wrote: > On 14/11/24 19:56, Jan Kara wrote: > > On Thu 14-11-24 09:45:23, Ian Kent wrote: > > > On 13/11/24 23:18, Jan Kara wrote: > > > > On Wed 13-11-24 08:45:06, Jeff Layton wrote: > > > > > On Wed, 2024-11-13 at 12:27 +0100, Karel Zak wrote: > > > > > > On Tue, Nov 12, 2024 at 02:39:21PM GMT, Christian Brauner wrote: > > > > > > Next on the wish list is a notification (a file descriptor that can be > > > > > > used in epoll) that returns a 64-bit ID when there is a change in the > > > > > > mount node. This will enable us to enhance systemd so that it does not > > > > > > have to read the entire mount table after every change. > > > > > > > > > > > New fanotify events for mount table changes, perhaps? > > > > Now that I'm looking at it I'm not sure fanotify is a great fit for this > > > > usecase. A lot of fanotify functionality does not really work for virtual > > > > filesystems such as proc and hence we generally try to discourage use of > > > > fanotify for them. So just supporting one type of event (like FAN_MODIFY) > > > > on one file inside proc looks as rather inconsistent interface. But I > > > > vaguely remember we were discussing some kind of mount event, weren't we? > > > > Or was that for something else? > > > I still need to have a look at the existing notifications sub-systems but, > > > tbh, I also don't think they offer the needed functionality. > > > > > > The thing that was most useful with David's notifications when I was trying > > > to improve the mounts handling was the queuing interface. It allowed me to > > > batch notifications up to around a couple of hundred and grab them in one go > > > for processing. This significantly lowered the overhead of rapid fire event > > > processing. The ability to go directly to an individual mount and get it's > > > information only got about half the improvement I saw, the rest come from > > > the notifications improvement. > > Well, if we implemented the mount notification events in fanotify, then the > > mount events get queued in the notification group queue and you can process > > the whole batch of events in one go if you want. So I don't see batching as > > an issue. What I'm more worried about is that watching the whole system > > for new mounts is going to be somewhat cumbersome when all you can do is to > > watch new mounts attached under an existing mount / filesystem. > > But, for mounts/unounts for example, isn't it the act of performing the > mount/unmount that triggers the notification if the path in within a file > system that's marked to report such events? Obviously it is the act of mounting / unmounting that will trigger the generation of the event. But I guess I don't understand what are you getting at... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
