OpenZFS 2.3: RAIDZ expansion finally GA, plus the other features worth caring about

OpenZFS 2.3 released in mid-2025 with one headline feature homelabbers have been waiting nearly a decade for: RAIDZ expansion finally hits general availability. The release also includes a few quieter improvements that don’t get as much attention but matter for daily operators.

Here’s the working review from running 2.3 on a homelab pool.

RAIDZ expansion: the headline

Before 2.3, RAIDZ vdevs were immutable. If you built a 4-wide RAIDZ1, you were stuck at 4 drives forever; adding capacity meant adding entire new vdevs.

OpenZFS 2.3 changes this. You can now add a single drive to an existing RAIDZ vdev. The pool restripes (slowly) in the background, and you end up with a 5-wide RAIDZ1 where you had a 4-wide.

Important caveats:

• Existing data uses the OLD parity ratio. A 4-wide RAIDZ1 with 25% parity overhead, expanded to 5-wide, keeps the old 25% overhead on existing data. Only new writes get the new 20% ratio.
• The expansion is slow. Plan for hours-to-days on large pools.
• You can’t shrink. Once expanded, you can only go larger.

For homelab use, this is still meaningfully useful. The “I need to add one more drive” problem that has defined ZFS-on-homelab for years now has a non-rebuild answer.

The other features worth knowing

Direct IO improvements: NVMe SSD performance ceiling raised meaningfully. If you run ZFS on fast SSDs, the throughput gains in 2.3 are real.

Improved zstd compression: better ratio at slightly higher CPU cost. For media archives this is a net win.

Fast Dedup (foundation): a meaningful re-think of ZFS dedup that may eventually make dedup usable. As of 2.3 the feature ships as foundational work; full Fast Dedup is in 2.4+.

Long names support: ZFS dataset names can now be longer. Niche but appreciated.

Various stability fixes: especially around send/receive on large datasets. If you do regular cross-pool replication, 2.3 is a meaningful reliability bump.

What didn’t make it

A few things the community had hoped for but didn’t land in 2.3:

• Block pointer rewrite / re-stripe — would let you rebalance a pool. Still not coming.
• Online dedup table cleanup — partial in 2.3, fuller in 2.4 trajectory.
• TRIM during scrubs — not yet.

These are multi-year projects. The OpenZFS roadmap moves slowly by design.

How to actually use RAIDZ expansion

If you have an existing RAIDZ1 or RAIDZ2 vdev and want to add a drive:

# Make sure you're on OpenZFS 2.3+
zpool version

# Add a single new drive to an existing vdev
zpool attach poolname raidz1-0 /dev/disk/by-id/your-new-drive

# Watch the restripe (this takes a while)
zpool status -v poolname

The expansion runs in the background. The pool stays online during the operation. You can write to the pool, but performance will be degraded until the restripe completes.

The honest take

RAIDZ expansion is a one-line ZFS docs update that closes a decade-old gap. For homelab use it’s significant. For enterprise use the recommendation remains “design your topology correctly from the start” — but for the inevitable “I bought one more drive” homelab moment, 2.3 turns a multi-day rebuild into a multi-hour expand.

Combined with the broader stability and performance work, OpenZFS 2.3 is the most operationally meaningful ZFS release in years.

If you’re on TrueNAS, Proxmox, Unraid, or vanilla Linux, you’ll get 2.3 via your platform’s update cycle through the rest of 2025. For the architectural decisions that determine whether you’ll even need expansion, see our ZFS pool design guide. For the OS context, TrueNAS Scale vs Core and Proxmox VE review.