make zfs type more flexible to allow arbitrary vdev options

[yangm97]

https://github.com/nix-community/disko/blob/fa4ec0bd26a103b3aa0d5a60f60399724face977/lib/types/zpool.nix#LL16C8-L16C8

We probably need an option for specifying VDEVs arbitrarily since zfs is more like a JBODs i.e. I have a pool that has two pairs of mirrors in addition to one pair of special vdevs (used for metadata and small blocks).

[phaer]

I think the title for this issue could be a bit clearer, can't really parse it.

But you are right IMO regarding the necessity of changing our ZFS support, as recently commented here https://github.com/nix-community/disko/issues/261#issuecomment-1587049324

[yangm97]

I think the title for this issue could be a bit clearer, can't really parse it.

I'm really fun at parties.

But yeah, I've been thinking about this, skimming over the codebase, I think one possible implementation would be to introduce a top-level zfs_vdevs property to act as a indirection point to the pool, where the topology could be specified. That would also mean to replace the pool disk property with a zfs_vdev pointing to the vdev name i.e. tank-mirror-0. However that has the downside of making vdev naming global, something that is not the case with zfs pools.

Another possibility would be to keep the pool disk property but add the vdev property i.e. mirror-0 then specify the vdev layout inside the given zpool. This is probably more backwards compatible than the other approach.

Either way, I'm don't know if we can influence the vdev naming that zfs generates when creating/manipulating a pool despite needing that to do disk -> vdev -> pool relationships so maybe we would need to add some docs around it (or come up with a better design).

[nicoonoclaste]

Not sure whether this is the most relevant place, but another ZFS feature that disko doesn't support are delegations (see zfs-allow(8))

They allow (eh) things like letting otherwise-unprivileged users manage the dataset for their homedir, take snapshots, create children datasets, etc.

Note that some permissions (such as receive) have non-trivial security implications.

[Lassulus]

Maybe it would be good to have a better titled issue for zfs features :)