Comment 4 for bug 1624540

It is important that zed run in all cases where a pool (with real disks) exists. This will only get more important over time, as the fault management code is improved. (Intel is actively working on this.)

It seems reasonable to not start zed in a container, though.

For the second piece, only running zed if a pool exists... Did you have a specific implementation in mind?

Long-term, there are some questions about whether zed should be in charge of importing pools. If zed were to be the thing that imports pools, that creates a problem if you don't want zed to run all the time. I don't think I came up with the idea of zed orchestrating pool imports, but I discussed it here:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1571761

There's also this work-in-progress pull request upstream that may be a better approach:
https://github.com/zfsonlinux/zfs/pull/4943

Long-term, if upstream was to accept something like that pull request, and make its zpool import unit template Wants=zed.service, would that accomplish all the goals?

I'm not saying we have to implement the whole thing now. I just want to make sure the fixes now are compatible with a long-term plan. I also want to make sure that upstream's long-term plans are compatible with Ubuntu's needs.