[systemd-devel] [PATCH 0/6] RFC: Initial implementation of mount table handling using libmount kernelwatch

Ian Kent ikent at redhat.com
Mon Jul 27 04:57:45 UTC 2020

Further to my post about using the new mount table notifications in
systemd I'd like to start by posting a few patches for discussion to
hopefully get a better understanding of some aspects of how systemd
mount unit state handling works, and also to get guidance on systemd
coding style, and generally how I should be doing things in systemd
as well as how best to debug problems.

To test what's been done I use a simple autofs direct mount map with
20000 mounts (ie. 20000 autofs mounts are done when autofs is started)
to trigger notifications. While, in this case, systemd bails out early
in the individual mount unit update processing, it still does the mount
unit traversal of all the units in the unpatched case so it should be a
reasonable test for the notification handling.

The patch series depends on changes to use the new fsinfo() system call
and also changes to provide the new kernelwatch notifications that will
be included in libmount.

Karel Zak has done a lot of work on this and his repo. containing this
work can be found at:
https://github.com/karelzak/util-linux.git, branch topic/fsinfo

The only additional libmount change I'm using here is some #define
entries of constants MNT_NOTIFY_MOUNT_* that are the same as the
kernelwatch NOTIFY_MOUNT_* constants. The reasons for that are, first
including linux/watch_queue.h conflicts with existing systemd includes
and also because the kernelwatch implementation should be usable from
libmount without the need to include the kernel definitions.

The patch series is against a fairly recent clone of the upstream
systemd git repo but for the actual testing the patches were back ported
to a source rpm of systemd-245.4 included in Fedora. There's also a need
for work to detect if libmount has the new features and ensure systemd
falls back to the old style mount table handing but I'll get to that.

There are six patches so far, one to use fsinfo() where possible for
mount table loading, another to use fsinfo() for systemd SIGCHLD
handling of mount unit mounting, a refactor patch, two patches to
enable use of the kernel mount id with the Mount units and finally an
initial implementation that uses kernelwatch notifications.

With only the patches to use fsinfo() I see a bit more than a 10%
reduction in overhead which is to be expected because the entire mount
table is still being read and the whole list of mount units traversed
on every mountinfo notification.

With the last patch added I haven't been able to work out why this isn't
working properly. The boot looks OK but I see cores from crashes when I
try and log in via gdm that look like a problem with unit garbage
collection related to unit state. Also I'm pretty sure I'm falling back
to the old mount table reading more often that I should so it's still a

However, even though the kernelwatch implementation isn't completely
working, running my test shows a reduction of about half in CPU usage.

Comments on what I have so far are welcome. And also any discussion
about how the mount unit state update works would be much appreciated,
as well as approaches to debugging sysyemd problems in general.

Ian Kent (6):
      systemd: try to use libmount fsinfo if available
      systemd: refactor mount_process_proc_self_mountinfo()
      systemd: try to use fsinfo for sigchld handling
      systemd: add mount id to MountParameters
      systemd: add Hashmap mount_unit_by_mnt_id
      systemd: use libmount kernelwatch if available

 src/core/mount.c           |  463 ++++++++++++++++++++++++++++++++++++--------
 src/core/mount.h           |    1 
 src/mount/mount-tool.c     |    4 
 src/shared/libmount-util.h |   28 +++
 src/shared/mount-util.c    |    4 
 src/shutdown/umount.c      |   18 +-
 6 files changed, 425 insertions(+), 93 deletions(-)


More information about the systemd-devel mailing list