Using a new mount table notification type in systemd

[Ian Kent <raven@xxxxxxxxxx>]

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

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel