Add templated [email protected]

[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 [email protected] which runs zfs mount -R <dataset>, to be used in conjunction with canmount=noauto mountpoint=/path/...

Description

[email protected] 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 [email protected] 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 [email protected] 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.