zfs native encryption best practices on RELENG13

[Alan Somers]

On Mon, Apr 26, 2021 at 3:04 PM mike tancsa <mike at sentex.net> wrote:

> On 4/23/2021 11:47 PM, Peter Libassi wrote:
> > Yes, I’ve come to the same conclusion. This should be used on a
> > data-zpool and not on the system-pool (zroot). Encryption is per
> > dataset. Also if found that if the encrypted dataset is not mounted of
> > some reason you will be writing to the parent unencrypted dataset.. At
> > least it works for encrypted thumb_drive, i just posted this quick
> > guide
> https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
> > <
> https://forums.freebsd.org/threads/freebsd-13-openzfs-encrypted-thumb-drive.80008/
> >
> >
> >
> >
>
> Thanks, good points to consider!  I wonder too if there are any
> performance differences
>
>     ---Mike
>

Yes there are.  Firstly, if you're using raid, then geli must encrypt both
data and parity.  ZFS crypto, however, only encrypts data because it
operates at a higher level.  That's a pretty substantial performance win
for ZFS during writes.  It's a nonissue for reads from a healthy array,
since ZFS doesn't need to read parity in that case.  Secondly, ZFS crypto
doesn't yet support hardware acceleration.  That's a huge win for geli if
you happen to have a hardware crypto engine (for this purpose AESNI does
not count as hardware, and it works fine with either geli or ZFS).
Thirdly, in my benchmarks I found about a 5% speed advantage for GELI
during reads, though I don't know why.  But of course none of this matters
if you're using a small number of HDDs.  It's only an issue if you have
fast SSDs or a large number of HDDs.
-Alan