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

[Ian Kent]

On Tue, 2020-07-07 at 08:47 +0000, Luca Boccassi wrote:
> 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

Potentially, yes.

It doesn't quite look like it but I wouldn't discount this being due
to the known kernel mount list locking problem when reading mountinfo
(well actually reading of any of the proc mount info. files).

But that would require some other activity during reads of mountinfo
to cause entries to no be seen and I don't see that happening in the
problem description.

If this is due to the mountinfo read problem it has probably been
fixed by a recent kernel change from Miklos Szeredi, could be worth
checking again with that change.

See upstream commit 9f6c61f96f2d for details.

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

Ha, I need to implement the changes first, but yes these could be
useful for testing, particularly to check for missed notifications.

Thanks for this.
Ian