Comment 9 for bug 1857398

I've given this a lot of thought. For what it's worth, if it were my decision, I would first put your time into making a small change to the installer to get the "encryption on" case perfect, rather than the proposal in this bug.

The installer currently has:

 O Erase disk an install Ubuntu
   Warning: ...
   [] Encrypt the new Ubuntu installation for security
      You will choose a security key in the next step.
   [] Use LVM with the new Ubuntu installation
      This will set up Logical Volume Management. It allows taking
      snapshots and easier partition resizing.
 O EXPERIMENTAL: Erase disk and use ZFS
   Warning: This will delete all your files on all operating systems.
   This is experimental and may cause data loss. Do not use on
   production systems.
 O Something else
   ...

I would move the ZFS option to be a peer of / alternative to LVM instead:

 O Erase disk and install Ubuntu
   Warning: ...
   [] Encrypt the new Ubuntu installation for security
      You will choose a security key in the next step.
   Volume Managment:
     O None (Fixed Partitions)
     O Logical Volume Manager (LVM)
        LVM allows taking snapshots and easier partition resizing.
     O EXPERIMENTAL: ZFS
        ZFS allows taking snapshots and dynamically shares space between
        filesystems.
        Warning: This is experimental and may cause data loss. Do not use
        on production systems.
 O Something else
   ...

This is a very straightforward UI change. The only new combination introduced with this UI is encryption on + ZFS, which is what we want. In that scenario, run the same passphrase prompting screen that is used now for LUKS. Then pass the passphrase to `zpool create` (and use encryption=aes-256-gcm for the reasons already discussed).

If the "always enable encryption" feature is to future-proof for people who would otherwise choose "no encryption", that's worth considering, but if it's an alternative to prompting them in the installer, I'm personally opposed.

However, we do need to consider why they're turning off encryption. Are they saying, "I don't want encryption ever (e.g. because of the performance penalty)." or "I don't care about encryption right now." If you always enable encryption, you are forcing encryption on them, which has real performance impacts on older hardware. For example, I just yesterday upgraded my personal server to use ZFS encryption, but made a media dataset that is unencrypted. Sustained writes to the media dataset are _at least_ twice as fast. With encryption, I was CPU bound. With it off, I was not, so I suspect I could have written even faster. This system is older and does not have AES-NI.

You mentioned spinning disks. Perhaps I misunderstood, but I don't know why you'd be asking about spinning disks in particular. They are slower than SSDs, so encryption is less likely to be a concern there, not more. My server scenario involved spinning disks.

If the old wrapped master key were overwritten when changed _and_ the system has AES-NI instructions, then I think it would be reasonable to make "no encryption" turn on encryption anyway with a fixed passphrase. This would achieve the goal of allowing encryption to be enabled later. But I think that is second in priority to handling the "encryption on" case.