[systemd-devel] Using a new mount table notification type in systemd

[Luca Boccassi]

On Tue, 2020-07-07 at 10:44 +0800, Ian Kent wrote:
> Hi all,
> 
> Some of you may be aware of the David Howells recent efforts to have
> a new notifications sub-system merged into the upstream kernel.
> 
> Part of that includes a way to get information about specific mounts
> without loading and scanning the mount table (the new fsinfo() system
> call).
> 
> Paired with new mount notifications that carry information about mount
> changes this can be used to also avoid scanning the mount table when a
> mount change notifications are received.
> 
> But in order to get these features merged upstream Linus wants to see
> that they will be useful and used by user space and the systemd use
> cases are representative of how this will be used which is why I'm
> focusing on using these in systemd. Alternately, if there are problems
> with the implementation, we need to identify them and work out what
> needs to be changed to get the sort of improvements we need.
> 
> So far I have some fairly straight forward changes that allow the use
> of the fsinfo() system call via libmount and, as expected, continuing
> to load the entire mount table using fsinfo() doesn't give much
> improvement.
> 
> And this is all experimental, proof of concept, so there's nothing
> about working out if libmount has the new features yet and I expect
> there will be other changes needed before any of this is in a state
> that can be released as part of libmount or utilised by systemd in
> its releases.
> 
> Anyway, now I'd like to do this for the new notification type that
> Karel Zak has added to his util-linux experimental repo. in systemd.
> 
> Now, polling mountinfo for changes is the way systemd gets notified of
> mount changes but this is not an actual file, it's generated from the
> kernel mount data structures on access so there's no sensible way to
> send a "diff" of what's changed.
> 
> What happens with the new notification mechanism is that notifications
> are sent at the time of mount changes along with information about
> which mount has changed and what has changed (that's a simplified view
> of this but the detail probably isn't needed for the sake of this
> discussion for now).
> 
> It looks like the the current event handling in systemd assumes that
> there is no auxiliary data for mount table changes which is sensible
> since there is none. But now there will be additional information so
> this event handling will need to change to read the information and the
> mount table handling will need to change to use it as well.
> 
> What I'm hoping for with this post is discussion (a bit of help really)
> of how this should be done to best fit in with systemd.
> 
> Any help and suggestions for this will be most welcome,
> Ian

Hello Ian,

Thanks for looking into this, it looks very promising - I just wanted
to add that it looks like this feature could help in getting the
following issue finally solved for good:

https://github.com/systemd/systemd/issues/10872

I thought of mentioning this also because there were useful scripts
attached on this thread that can be used to stress tests this part of
systemd, so I thought they might turn out to be useful to validate work
in this area.

-- 
Kind regards,
Luca Boccassi