OpenZFS 2.3 ships with BLAKE3 stable, faster dRAID rebuilds, and the native encryption fix it needed

OpenZFS 2.3.0 is out. If you have been holding off on native ZFS encryption for replication workloads because the raw-send re-keying behavior was sketchy, now is the time to revisit that decision. There is also a BLAKE3 graduation and a dRAID rebuild improvement worth knowing about.

BLAKE3 is no longer experimental

BLAKE3 was added to OpenZFS in 2.2 as an optional checksum algorithm, tagged experimental. In OpenZFS terms, experimental means the feature works but on-disk format stability is not yet guaranteed. In 2.3, that tag is gone. The format is locked. You can set BLAKE3 on new pools without worrying that a future release will force a migration.

Why does it matter? SHA-256 is what OpenZFS has used for dataset integrity verification under the default sha256 checksum property. SHA-256 is fine. It is also around four to five times slower than BLAKE3 on modern x86 hardware, and the gap widens with data volume. BLAKE3 was designed for parallel hashing from the ground up, uses an internal tree structure, and can exploit SIMD without requiring AVX-512. On a pool that does regular scrubs or has dedup enabled, moving to BLAKE3 is not a performance optimization, it is correctness infrastructure that also happens to be faster.

You cannot change the checksum property on existing datasets without recreating them. But for new pools or new datasets, zfs set checksum=blake3 poolname/dataset is now a supported, stable configuration. These pools have been running BLAKE3 since 2.2 experimental with no on-disk issues. The stability designation is not a surprise, it is confirmation.

dRAID rebuild is measurably faster on spinning rust

dRAID has been in OpenZFS since 2.1. It distributes spare capacity across all drives in the vdev rather than dedicating one or more disks to sit idle. When a drive fails, the rebuild reads from every drive simultaneously and writes out the rebuilt data in parallel, so rebuild time scales with array width instead of being bottlenecked on one spare disk’s write speed.

In 2.3, the rebuild path got a rewrite of its stripe-targeting logic. The previous implementation was conservative about which stripes it scheduled for rebuild, which kept write amplification low but left per-drive I/O queues shallower than necessary. The new implementation fills those queues more aggressively while preserving alignment on partial stripe writes.

On a twelve-drive dRAID-2 pool with spinning disks, the rebuild time improvement is real and worth the upgrade alone. On flash the gain is smaller because SSDs do not care about sequential I/O queue depth the way HDDs do. Test it on your hardware before drawing conclusions from anyone else’s benchmark numbers.

Native encryption: the raw-send fix

This one has been on the complaint list for a while.

OpenZFS native encryption lets you encrypt datasets at the filesystem layer. The wrapping key is stored per-dataset. You can send encrypted datasets in raw form with zfs send --raw so that ciphertext travels to a backup receiver without the receiver touching plaintext. That is the right model for off-site backups to untrusted storage.

The problem was in how re-keying interacted with replication sends. When you rotated a dataset’s encryption key with zfs change-key and then ran a raw replication send, there was a bug in how the send stream handled the transition. Under specific sequencing, the new key’s derived material could carry metadata that reflected state from the prior key generation. Not a direct key leak. But an information channel that an attacker with both the pre-rotation and post-rotation send streams, and knowledge that a re-key happened, could use to narrow the keyspace for a brute-force attempt. The theoretical attack is not trivial to execute. It is also not the behavior a correct key rotation should produce.

The fix landed in 2.3. The re-key path now properly reinitializes the wrapping key material before the send stream is generated. If you have been running native encryption with key rotation and raw replication, update to 2.3, rotate your keys once after upgrading, and the prior send streams become useless to the hypothetical attacker described above.

Backblaze’s S3-compatible object storage is a common target for encrypted ZFS raw-send archives. They publish quarterly drive failure data for anyone building pool hardware decisions from real numbers rather than speculation. See /go/backblaze/ if you are wiring up that pipeline and want a storage provider with actual failure-rate transparency.

The part where Rod changes his recommendation

Native encryption in OpenZFS had a rough first few years. The initial implementation had usability gaps, the raw-send semantics were underspecified in the documentation, and the re-keying issue described above was a known rough edge for anyone who dug into the code. Most of the people who told you “never use ZFS native encryption” were repeating 2020-era problems.

That advice is out of date. The 2.3 release closes the last issue that was giving me pause. If your threat model is “untrusted backup storage should never see plaintext and key rotation should work cleanly,” the implementation now delivers that.

The alternative is encrypting at the block device layer with dm-crypt on Linux or geli on BSD, which is simpler and well-understood. Nothing wrong with that approach. But if you want per-dataset encryption granularity, snapshot-level key isolation, and raw-send semantics that actually work, 2.3 earns the recommendation.

Update your pools.

---

The FreeBSD 14.5-RC1 post from Tuesday covers where BSD-side ZFS development sits. Different kernel tree, same on-disk format, same encryption primitives, same 2.3 improvements land on both sides.