ZFS-MOUNT-GENERATOR(8) | System Manager's Manual | ZFS-MOUNT-GENERATOR(8) |
zfs-mount-generator - generates systemd mount units for ZFS
/lib/systemd/system-generators/zfs-mount-generator
zfs-mount-generator implements the Generators Specification of systemd(1), and is called during early boot to generate systemd.mount(5) units for automatically mounted datasets. Mount ordering and dependencies are created for all tracked pools (see below).
If the dataset is an encryption root, a service that loads the associated key (either from file or through a systemd-ask-password(1) prompt) will be created. This service RequiresMountsFor the path of the key (if file-based) and also copies the mount unit's After, Before and Requires. All mount units of encrypted datasets add the key-load service for their encryption root to their Wants and After. The service will not be Wanted or Required by local-fs.target directly, and so will only be started manually or as a dependency of a started mount unit.
mount unit's Before -> key-load service (if any) -> mount unit -> mount unit's After
It is worth nothing that when a mount unit is activated, it activates all available mount units for parent paths to its mountpoint, i.e. activating the mount unit for /tmp/foo/1/2/3 automatically activates all available mount units for /tmp, /tmp/foo, /tmp/foo/1, and /tmp/foo/1/2. This is true for any combination of mount units from any sources, not just ZFS.
Because ZFS pools may not be available very early in the boot process, information on ZFS mountpoints must be stored separately. The output of the command
for datasets that should be mounted by systemd, should be kept separate from the pool, at
The cache file, if writeable, will be kept synchronized with the pool state by the ZEDLET
The behavior of the generator script can be influenced by the following dataset properties:
This behavior is equal to the auto and noauto legacy mount options, see systemd.mount(5).
Encryption roots always generate a key-load service, even for canmount=off.
on: Mount will be WantedBy local-fs.target
off: Mount will be Before and RequiredBy local-fs.target
unset: Mount will be Before and WantedBy local-fs.target
To begin, enable tracking for the pool:
Then, enable the tracking ZEDLET:
systemctl enable zfs-zed.service
systemctl restart zfs-zed.service
Force the running of the ZEDLET by setting a monitored property, e.g. canmount, for at least one dataset in the pool:
This forces an update to the stale cache file.
To test the generator output, run
This will generate units and dependencies in /tmp/zfs-mount-generator for you to inspect them. The second and third argument are ignored.
If you're satisfied with the generated units, instruct systemd to re-run all generators:
zfs(5) zfs-events(5) zed(8) zpool(5) systemd(1) systemd.target(5) systemd.special(7) systemd.mount(7)
August 24, 2020 | OpenZFS |