[systemd-devel] Reacting to non-systemd mounts

[Lennart Poettering]

On Fri, 05.08.16 10:26, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> > Everything happens asynchronously and systemd notices that the
> > filesystem has been mounted only through mountinfo.
> 
> Yes, this is second real life case after ZFS which does not fit in
> rather simplistic model. We probably need something like passive
> dependencies similar to how devices are handled, where systemd
> simply waits for a unit to appear without attempting to start it
> itself.

Well, I'd really turn this around, and propose that those systems
provide some /bin/mount.<fstype> tool that makes sure they can be used
using the usual mount/umount logic. In today's world mounting and
unmounting is highly dynamic, and often requires more than trivial
dependencies. Hence I am pretty sure systemd should be able to
schedule mounts correctly, so that it can pull in what is
necessary. There's a nice plug-in interface available to cover this,
it's nicely supported even beyond systemd, and those systems really
should just use that.

ZFS in particular is really broked right now since it assumes that
there was a point in time during boot where all block devices have
shown up. With today's hardware that point in time does not exist
(think hotpluggable disks, such as USB, iSCSI, NBD, …).

So, instead of adjusting systemd to be able to deal with these file
systems, I am pretty sure it should be those file systems that get
fixed to work like hardware (and Linux) work these days, and just
follow the normal plug-in schemes for file systems that need extra
userspace code that is implemented in util-linux.

Lennart

-- 
Lennart Poettering, Red Hat