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. ** Changed in: zfs-linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1624540 Title: please have lxd recommend zfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1624540/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
