Comment 10 for bug 1571761

Hello Richard,

Richard Laager [2016-04-20 17:59 -0000]:
> Yes, each filesystem has a "mountpoint" property.

I see, thanks. (Sorry, I'm just familiar with btrfs and subvolumes,
and they work differently). So I see how putting this into
local-fs.target in parallel with the fstab mounts makes sense.

> I want the daemon to import that pool as soon as all 6 disks are
> present. I also want it to import the pool if 4 (or 5) disks are
> present, but only after a short timeout where no new disks have been
> detected.

Aah, that makes much more sense than "wait for all devices", so that
was just a misunderstanding.

> That is, I do not want the pool to import in a degraded state when
> the first 4 disks are present, only to have the 5th and 6th show up
> milliseconds later.
>
> The daemon would handle each disk one-by-one. It would track the
> information about discovered pools in memory. After each new disk is
> discovered and we've identified the pool it belongs to (C/glib
> pseudo-code follows):

Doing this with a daemon would certainly work, it can do arbitrary
state keeping and timeouts. OTOH this is a bit of a central point of
failure/you need to write a new daemon/etc.

I haven't thought this through very thorouhgly, but I have a gut
feeling this could even work in a decentral and asynchronous way:
Whenever we get an uevent for a block device we call a helper (through
udev's RUN) which checks which zpool this belongs to and if there's at
least the minimal number of members available (but not all yet); if
so, it can start a systemd timer unit [1]
zpool-assemble@<devicename>.timer which will trigger some
zpool-assemble@<devicename>.service after, say, 500ms. But when that
helper sees (on the next uevent) that this was the last missing member
of the zpool, i. e. we now have all devices, it could immediately
start zpool-assemble@<devicename>.service. The timer then goes off
into nothing as the corresponding .service is already running (i. e.
it's harmless), or the udev helper could also explicitly stop it.

This is just a sketch, but if you are interested in exploring this I
recommend that we have a more synchronous chat (IRC, I'm pitti on
Freenode) or a hangout or so.

[1] Triggering a systemd unit from a udev rule is trivial,
    e. g. ENV{SYSTEMD_WANTS}+="zpool-assemble@%k.service" (with the
    appropriate checks for "is this a zfs block device)