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:

There's also this work-in-progress pull request upstream that may be a better 

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 Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.

  please have lxd recommend zfs

Status in lxd package in Ubuntu:
Status in zfs-linux package in Ubuntu:

Bug description:
  Since ZFS is now in Main (Bug #1532198), LXD should recommend the ZFS
  userspace package, such that 'sudo lxd init' just works.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to