[systemd-devel] advice for zfs-mount-generator

[Lennart Poettering]

On Tue, 28.06.16 05:49, Jörg Thalheim (joerg.systemd at higgsboson.tk) wrote:

> Hi,
> 
> when using zfs in combination with systemd, users run into the following problem:
> 
> - zfs manages mountpoints on its own and systemd is not aware of those.

what do you mean by that? systemd tracks /proc/self/mountinfo. Are you
saying those "mounts" don't appear there? If so, that appears to be
seriously borked in the zfs kernel code...

> - this leads to problems, when mountpoints for other filesystems are mounted
>   on directories in a zfs dataset or files are created in a directory before zfs could
>   mount its dataset there. 

Not sure I grok this. Or are you saying that zfs uses a different
source of configuration than /etc/fstab for its mounts?

If so, it should either write a generator for that and let systemd do
the work, or make sure it establishes its mounts atomically. (by
prepping them somewhere and then using MS_MOVE to move them into
place, for example). This is however not going to work as soon as a
non-zfs file system shall be moutnable into some dir provided by zfs.

> It should be also noted that those filesystems will be not mounted using mount(2),
> but the command interface `zfs mount` except mountpoint is set the
> `legacy`

This sounds pretty broken. Why don't they provide a mount.zfs binary,
similar to how all other file systems do it that need to do something
special on mount?

> However currently some zfs services exists which import zfs pools after the generator run:
> 
> ```/usr/lib/systemd/system/zfs-import-scan.service
> [Unit]
> Description=Import ZFS pools by device scanning
> DefaultDependencies=no
> Requires=systemd-udev-settle.service
> After=systemd-udev-settle.service

if zfs requires "udev-setlle", then that's broken and very very
sad. No new technology should need that. 

> As generators will run before unit I run into a Chicken or the egg problem.
> I would appreciate, if you have suggestions how to make this scheme compatible 
> with the way systemd handle mounts.

If zfs requires an explicit "scan" phase, that needs to be called
after all storage has shown up then it is simply incompatible with how
today's device management works. There's simply no point in time where
all hardware has to have shown up. Such a concept is incompatible with
today's hardware which can pop up any time, and can take all the time
it wants to show up. zfs has to be able to deal with devices coming
any time and it should not expect to be run when "all has shown" up.

my recommendation would be to work with the zfs guys to adapt it to
how modern storage works, stop using udev-settle and make sure they
implement a generator, and a mount.zfs plugin for
/bin/mount. Otherwise it's always going to be more or less
incompatible with systemd and how things generally work on Linux these
days.

Lennart

-- 
Lennart Poettering, Red Hat