openzfs/zfs

RFC: better import integration with systemd, hotplug et al.

Open

#4178 opened on Jan 8, 2016

View on GitHub
 (9 comments) (2 reactions) (0 assignees)C (9,908 stars) (1,703 forks)batch import
Status: InactiveType: Featuregood first issue

Description

First, this is not an issue report per se, but rather an "RFC issue".

Currently, zfs pool importing and mounting completely bypasses the udev and hotplug machinery. That is, even the systemd pool import unit file begins with:

Requires=systemd-udev-settle.service
After=systemd-udev-settle.service

It does not hook up itself to local-fs.target, nothing. Moreover, zfs has its own dataset mounting machinery which, again, bypasses the systemd state machine. This may sound beneficial to most due to their familiarity, but (from top of my head — the list is not too impressive, but it isn't exhaustive):

  • this does not allow to import pools/mount datasets after relevant devices are hot-plugged;
  • this does not allow to write unit files depending on zfs datasets (well, it does, but systemd won't wait for the devices to become available and will fail right away if datasets have not been mounted beforehand);
  • this means all of the usual problems with udevadm settle (races with disk controller init).

One of the ways to solve this, for ZFS on Linux specifically, would be to integrate nicely into the existing event/dependency infrastructure (the other way would be to devise a separate hotplug handling subsystem which does not use udevadm settle, which is likely not going to happen). In particular:

  1. import pools as they become plugged-in (probably subject to some filtering), by triggering import from udev rules;
  2. From the kernel driver, create "fake" block devices for each imported dataset, which then can be "mounted" from fstab (and waited for by systemd).

Or, other way around:

  1. from udev rules, set ENV{SYSTEMD_READY}=0 on all block devices which appear to participate in zfs pools;
  2. import pools as they become plugged-in (probably subject to some filtering), by triggering import from udev rules;
  3. once a pool has been imported in any way, mark participating block devices as ENV{SYSTEMD_READY}=1 on all block devices of this pool;
  4. allow mounting a zfs dataset by any of its devices and dataset name in mount options (btrfs-like).

Is anybody interested in this? Maybe there are better ways? Maybe this is already done, just not reflected in mans and anywhere?

Contributor guide

Tech stack
cshell
Domain
devopsinfrastructure
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
systemdudevZFS internalsLinux kernel device management
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
5
Research direction
This is an RFC proposing better integration of ZFS pool importing and mounting with systemd and udev, avoiding reliance on 'udevadm settle'. The discussion should explore two main approaches: (1) creating fake block devices from the kernel driver for each dataset, or (2) using udev rules to set SYSTEMD READY and trigger imports. Existing examples from other filesystems (e.g., btrfs) and systemd documentation should be referenced. No code changes are proposed yet; the goal is to gather feedback and design a solution.