== ZFS Encryption is still under development (as of March 2019) One of the big upcoming features that a bunch of people are looking forward to in ZFS is natively encrypted filesystems. This is already in the main development tree of [[ZFS On Linux https://zfsonlinux.org/]], will likely propagate to FreeBSD ([[since FreeBSD ZFS will be based on ZoL ../solaris/ZFSFreeBSDChangesBase]]), and will make it to Illumos if the Illumos people want to pull it in. People are looking forward to native encryption so much, in fact, that some of them have started using it in ZFS On Linux already, using either the development tip or one of the 0.8.0 release candidate pre-releases (ZoL is up to 0.8.0-rc3 as of now). People either doing this or planning to do this show up on the ZoL mailing list every so often. Unfortunately this is not a good idea (despite ZoL being in the 0.8.0 release candidate stage). Instead, ~~you should avoid using ZFS encryption until it's part of an official release~~, and maybe even past that. Unlike garden variety features and changes in ZoL, where the development tree has historically been almost completely solid and problem free, ZFS encryption is such a significant change that people are still routinely finding bugs and needing to make serious changes, including changes to the on disk data format that require you to back up and restore any encrypted filesystems you may have ([[yes, really http://list.zfsonlinux.org/pipermail/zfs-discuss/2019-March/034110.html]], and [[see also https://github.com/zfsonlinux/zfs/commit/f00ab3f22cc2c7f62cfd56be842945667b1d558f]]). (This particular change is far from the only encryption related problem that has come up. I follow the development tree and read every commit's description, and I've seen quite a lot of commits that fix various encryption related issues. It really seems that people are still frequently finding corner cases that hadn't been considered or previously encountered, despite ZFS On Linux's relatively extensive test suite. ZFS sends and receives seem to be an especial problem area, but my memory is that even ordinary use hasn't been trouble free.) If you have a strong need for combining encryption and ZFS today, I think that you're going to need to stick to the old approaches of things like ZFS on top of a LUKS encrypted volume. Otherwise, you should wait. The most that people should be doing with ZFS encryption today is taking it for a test drive to gain experience with it; you should definitely not use it for anything you care about. I know, this seems odd given that ZFS On Linux is up to 0.8.0-rc3, but it is what it is. I am a little bit surprised that ZoL has been doing a -rcN series with encryption so apparently unstable, but I'm sure they have their reasons. It's even possible that ZFS On Linux 0.8.0 will not include encryption as a production-ready feature; at this point the developers probably won't disable the code outright, but they might fence it off behind warnings. (It's possible that encryption has turned out to be more tangled and troublesome than anyone initially expected when the feature first landed, and that it's only through the early enthusiastic people jumping on it that all of these problems have been found.) PS: I expect that FreeBSD people won't have to worry about this unless you're tracking FreeBSD-CURRENT or FreeBSD-STABLE, since I doubt that FreeBSD will enable ZFS encryption in a FreeBSD release until it's established a solid track record for stability in ZoL.