Add templated zfs-mount@.service

[LunarLambda]

Runs zfs mount -R <dataset> at boot, after zfs mount -a. Intended to replace mountpoint=legacy in certain mount setups.

Motivation and Context

If a pool has multiple ZFS root filesystems (canmount=noauto mountpoint=/) (or some other dual-booting setup that utilizes ZFS across multiple systems), and those in turn each have child datasets (e.g., canmount=on mountpoint=/var/lib/mysql), then problems arise as zfs-mount.service will execute zfs mount -a, attempting to mount multiple datasets to the same location.

The typical solution is to set mountpoint=legacy and set a mount entry in /etc/fstab. This is cumbersome and easy to mess up.

Instead, introduce a zfs-mount@.service which runs zfs mount -R <dataset>, to be used in conjunction with canmount=noauto mountpoint=/path/...

Description

zfs-mount@.service is essentially identical to zfs-mount.service, with the following two changes:

1. It is ordered After=zfs-mount.service, yielding an intuitive precedence order.
2. It executes zfs mount -R <dataset> instead of zfs mount -a.

The build/install files have been adjusted to install zfs-mount@.service where appropriate.

As far as I can tell, the documentation does not directly mention zfs-mount.service, so I have not added or modified any documentation.

How Has This Been Tested?

I have tested it on a personal machine. Being essentially identical to zfs-mount.service, I would not expect there to be any issues with the implementation. Being a template unit, it will never be enabled by default, so 50-zfs.preset was left unmodified (I did verify that template units without a DefaultInstance= setting do not need to be disabled explicitly)

The dracut and initramfs-tools modules both do not use zfs-mount.service, so they are left unmodified. zfs-mount-generator adds a Before=zfs-mount.service ordering, and with zfs-mount@.service being After=zfs-mount.service, a consistent ordering is preserved here too.

Beyond this, I did not see any test files that directly deal with systemd services, so nothing was modified there. No core ZFS code was modified.

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.

[LunarLambda]

zloop check failure seems unrelated to my changes.

[behlendorf]

Thanks. This makes sense, I can see the use case for something like this. Although, it makes me wonder if we should support a systemd template for the zfs-import-* services as well. Rather than always importing all detected pools.

As for the lacking documentation for the service files that's definitely a gap. At some point we need to add a man page describing the systemd support better. But that's for another PR.

[LunarLambda]

I could add templated units for those if desired. I can see that making sense for multi-homed pools?

[behlendorf]

Yes, exactly. For pools visible from multiple nodes it might be handy. In such setups usually the import is managed by some HA software though instead of systemd. So let's not bother adding it until we have a real use case. I'll go ahead and get this merged.