Comment 3 for bug 1571761

There is some angles of attack here:

└─zfs-import-cache.service @1min 786ms +272ms
  └─systemd-udev-settle.service @494ms +1min 275ms

This is a case of "you asked for it, you got it", really. udev-settle is a workaround for old software that wasn't written with hotplugging in mind. It's 2016, and we really should avoid introducing new dependencies to udev-settle, as it's conceptually broken and can't work. This totally does not work for any hotplugged device, or a device which just gets detected by the kernel late, or which needs to be unwrapped from building an LVM or cryptsetup device, etc.

I think it would be much more elegant to instead create udev rules (or systemd units) which load the ZFS cache as soon as a ZFS block device is detected. Would that be possible/reasonable? I don't know anything about what import-cache does, but I hope/suppose it has some way of doing this on a per-device basis?

    └─systemd-udev-trigger.service @415ms +55ms

This is cloud-init's rules for blocking udev rules until network devices get detected and cloud-init's naming rules get applied. This is a hairy topic and Scott and I already discussed this at length. I think there's a better solution here, but I doubt we'll completely turn this around by the release. This just illustrates one of the problems of the "waiting for all hardware just to single out a particular device" approach from above -- this waits on stuff which is completely unrelated to zfs.