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?
Ian
