Some questions regarding ZFS

[oddlama]

I've recently tried using disko to manage some VMs. This worked great so now I want to use it to manage my more complex ZFS based setups, too. But before I start I was hoping you can shed some light onto some questions that have popped up as I'm currently not sure whether disko is ready for ZFS "in production". I'm also reluctant to test these things before knowing more.

• Why is there a mountpoint attribute on the zpool? This doesn't make any intuitive sense to me, as pools don't have mountpoints. It seems like the default is null so I figure disko expects me to always set this?
• It seems to me like "disko create" and "disko mount" are supposed to only be used once when setting up a new system. Is this correct?
• Is disko guaranteeing creation order as listed such that I can reliably specify datasets with children? As the datasets are not specified as a list, I am unsure whether there is a ordering guarantee at all. (I'd for example need rpool/home (empty parent) and rpool/home/myuser1, rpool/home/myuser2, so creation order is important)
• Is there a specific reason why _mount is not using altroots (zpool create/import -R /mnt) and zfs mount as recommended by ZFS? It looks like all mounting is done manually for some reason.
• It also occurred to me that encryption keys are not imported or regarded in many commands, so I am wondering whether encryption is supported at all (will prompts be shown?).

I'd of course be willing to contribute any changes I have to make to get it to work, but at this point I cannot judge what is intentional and what isn't. I don't fully understand what "guarantees" disko assumes for its create and mount actions, and I couldn't find any documentation apart from the README. Any help would be appreciated.

[Mic92]

I've recently tried using disko to manage some VMs. This worked great so now I want to use it to manage my more complex ZFS based setups, too. But before I start I was hoping you can shed some light onto some questions that have popped up as I'm currently not sure whether disko is ready for ZFS "in production". I'm also reluctant to test these things before knowing more.

* Why is there a `mountpoint` attribute on the zpool? This doesn't make any intuitive sense to me, as pools don't have mountpoints. It seems like the default is `null` so I figure disko expects me to always set this?

One can set a mountpoint on the toplevel dataset, if you don't supply a mountpoint here, this dataset is ignored.

* It seems to me like "disko create" and "disko mount" are supposed to only be used once when setting up a new system. Is this correct?

disko create yes, disko mount you could also use if you want to access your system from a recovery system.

* Is disko guaranteeing creation order as listed such that I can reliably specify datasets with children? As the datasets are not specified as a list, I am unsure whether there is a ordering guarantee at all. (I'd for example need `rpool/home` (empty parent) and `rpool/home/myuser1`, `rpool/home/myuser2`, so creation order is important)

I think so, but I am unsure here.

* Is there a specific reason why `_mount` is not using altroots (`zpool create/import -R /mnt`) and `zfs mount` as recommended by ZFS? It looks like all mounting is done manually for some reason.

zfs mount does not work with legacy mounts afaik. This way both types of dataset can handled by one mount call. Actually the zfs kernel ends up calling the mount binary eventually anyway because vfs_mount is a GPL symbol. In Nixos since we don't use zfs systemd mount generator, all zfs filesystem have be mountable through mount() anyway.

* It also occurred to me that encryption keys are not imported or regarded in many commands, so I am wondering whether encryption is supported at all (will prompts be shown?).

I think you can pass keyformat=passphrase as a dataset option but you would need to provide the password than manually. Otherwise keylocation=file:///root/zfs_key should also work.

I'd of course be willing to contribute any changes I have to make to get it to work, but at this point I cannot judge what is intentional and what isn't. I don't fully understand what "guarantees" disko assumes for its create and mount actions, and I couldn't find any documentation apart from the README. Any help would be appreciated.

[oddlama]

Thanks for the quick response!

I think so, but I am unsure here.

Do you have any idea on how we could proceed to verify this?

zfs mount does not work with legacy mounts afaik. This way both types of dataset can handled by one mount call. Actually the zfs kernel ends up calling the mount binary eventually anyway because vfs_mount is a GPL symbol.

I see, I didn't expect anyone to still use legacy mounts with ZFS when creating new disk layouts today.

In Nixos since we don't use zfs systemd mount generator, all zfs filesystem have be mountable through mount() anyway.

From the NixOS wiki entry about ZFS: "zfs-mount service is enabled by default on NixOS 22.05."
This would lead me to believe that nixos is not requiring legacy mounts, or am I mistaken?

But what's more important to me is that using mount in the way it is currently used in disko prevents automatically loading the key for encrypted datasets. zpool import -l and zfs mount -l would prompt for the passphrase if necessary, which would be required to support mounting encrypted datasets in a recovery situation. Currently the mount just fails.

* It also occurred to me that encryption keys are not imported or regarded in many commands, so I am wondering whether encryption is supported at all (will prompts be shown?).

I think you can pass keyformat=passphrase as a dataset option but you would need to provide the password than manually. Otherwise keylocation=file:///root/zfs_key should also work.

(Related to previous point)
That's what I'm doing right now. For my personal machine I require keyformat=passphrase, which works when creating the datasets initially, but fails afterwards when using disko mount in case the rpool is exported.

EDIT: Technically a zfs load-key -a call would also suffice, but one would need to make sure that only the relevant keys are loaded instead of all keys (in case other disks are present)

[Lassulus]

I think so, but I am unsure here.

Do you have any idea on how we could proceed to verify this?

the datasets are ordered in alphabetical order. which should good for all usecases (since "/" comes before "/data"). lib.attrValues gets values from attrsets in alphabetical order. Hopefully this answers your question :)

[oddlama]

Yes, thanks!

[Mic92]

zfs load-key -a or something that is more granular and just tries to import the pool would indeed make sense.

[SuperSandro2000]

FYI #211

[oddlama]

Thanks everyone, sandro's PR plus my recent PR have solved the remaining issues with altroots and encryption keys respectively, so I think everything has been answered :D