On Mon, Apr 26, 2021 at 3:04 PM mike tancsa <m...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
