zfs-mount-generator improvements (remove udev-settle dependency) RFC

[aerusso]

Motivation and Context

Previously, the zfs-mount-generator produced .mount units that depended on the zfs-import.target. This meant that every filesystem required all pool imports be completed before beginning mounting. Additionally, the zfs-import*.service units that actually performed the zpool import depended on the deprecated systemd-udev-settle.service. This leads to warnings, and more fragile mount behavior.

See also #10891

Description

Instead, make the zfs-mount-generator .mount units depend on a per-pool zfs-import@.service template. Additionally, have zfs-mount-generator grant zfs-import@.service dependencies on the associated .devices required for the pool to actually import.

Additionally, remove udev settle dependencies in systemd units that depend on zfs-import targets. Also, remove the zfs-import.target wait for zfs-mount@.service, since not all pools need to be imported to begin mounting filesystems.

How Has This Been Tested?

I am running this, rebased onto 2.4.1. I am looking for more widespread testing here.

I suspect that this may break some configurations. We need to talk about this.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[aerusso]

Yikes, the OOM logic is nasty (and there are memory leaks). I need to work through that before this is worth a close review. The other logic is still worth looking at, though.

[behlendorf]

Thanks @aerusso for tackling this work. I think this makes a lot of sense and is the way we need to go, just a couple questions.

dependencies on the associated .devices required for the pool to actually import.

Could you elaborate a bit on how systemd handles this when there are multiple devices listed. When is the zfs-import@.service started? From the documentation it sounds like this occurs once after all of the listed *.device dependencies are started for the first time. And since you've used Wants instead of Requires they don't all need to succeed, which is good.

But what happens if one of the expected *.device files never gets dynamically created. For example, because the device has failed or was removed from the system? In this case, will the zfs-import@.service ever be started? If that's the case, it seems like we still want some kind of timeout which triggers the import so pools with sufficient redundancy are imported.