Re: [PATCH v4 0/3] fs: allow statmount to fetch the fs_subtype and sb_source

[Ian Kent]

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