Comment 7 for bug 1857398

Thanks Richard for digging in, the performance comparison and the valuable upstream feedback and pointers.
Good catch about retrieving the master key written in old blocks with the previous (fix) passphrase even if changed later on. It seems that trimming could help. Do you think that we should base on work going that direction (overwriting old keys) and keep the current approach?

On a more general side, the approach seems to be forward-compatible with per user dataset encryption (zfs change-key <dataset>), which creates a new encryption root.

Steve:
* the only comment I have on the ubiquity part of the equation is based on Richard's feedback. Otherwise, looks good to me. I think we should wait on the above feedback before taking a finale decision on the approach though.
* the zfs-linux initramfs POC looks good (not tested though, currently travelling, but I didn't spot any issues). It should be easily pluggable later on once the user set it to "prompt" with their own passphrase and use the plymouth prompt codepath. (Not tested yet either).
Just a nitpick: Colin asked for our patches in zfs-linux to be numbered (hence the 4XXX- namespace), as the debian ones. It seems that it's not reliably the case since the 0.8.2 merge with debian, so need double checking (order seems as well messy after this merge right now).

Anyway, we need to wait on the kernel patches first.