OpenZFS 2.3 review — RAIDZ expansion lands, plus the quieter 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.

The community response captured the moment. The r/homelab “RaidZ Expansion is officially released” thread (354 upvotes) hit the homepage on launch day. The r/zfs “Taking a look at RAIDZ expansion” thread (56 upvotes) became the canonical “here”s how it actually works” reference within days. The feature mattered more for homelab users than for enterprise — the long-standing “I want to add one more drive” problem finally has a non-rebuild answer.

This piece is the working review from running 2.3 on a homelab pool through June-July 2025.

RAIDZ expansion: the headline feature

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 (well-articulated in the r/homelab launch thread top comments (57 upvotes)):

“Note the limitations though: After the expansion completes, old blocks remain with their old data-to-parity ratio (e.g. 5-wide RAIDZ2, has 3 data to…”

The constraints in plain language:

• Existing data uses the OLD parity ratio. A 4-wide RAIDZ1 with 25% parity overhead, expanded to 5-wide, keeps the 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.

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 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.

The community discourse: write amplification + 2.4 horizon

The r/zfs “Does ZFS Kill SSDs? Testing Write amplification in Proxmox” thread (69 upvotes) — same day as the RAIDZ expansion thread — captured the simultaneous conversation about whether ZFS on SSDs is killing drives faster than expected. The thread doesn”t conclude definitively, but the testing matters for homelab users running Proxmox + ZFS-on-SSD setups, which have been getting more common as SSD prices drop.

The mature read: ZFS write amplification on SSDs is real but workload-dependent. Heavy small-write workloads (databases, VMs with frequent state changes) wear SSDs faster on ZFS than on simpler filesystems. Media archive workloads and read-heavy use cases are fine.

The r/zfs “zfs-2.4.0-rc1 released” thread (89 upvotes) in August signaled the next horizon. 2.4 is moving faster than 2.3”s long gestation — the OpenZFS project momentum visibly accelerated through 2025. Fast Dedup, additional performance work, possibly online dedup table cleanup. The 2.4 ship target is end-of-year 2025 / early 2026.

What didn”t make 2.3

A few things the community had hoped for but didn”t land:

• 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 — which is why 2.3 took as long as it did, and why 2.4”s apparent acceleration matters.

Creator POV vs Reddit dissent: the homelab storage landscape

The broader homelab storage discourse in mid-2025 doesn”t orbit only around ZFS. Lawrence Systems” “Is It Time to Drop Synology?” (May 13) framed the alternative landscape: TrueNAS Scale (ZFS-based) vs Unraid (BTRFS/XFS) vs DIY Proxmox + ZFS vs commodity NAS. ZFS is the right answer for a meaningful slice of homelab users — not all.

Craft Computing”s “Proxmox CEPH Cluster Tutorial” (Jul 26) shows the high-end homelab alternative: distributed storage via Ceph instead of single-node ZFS. CEPH wins for multi-node, large-scale homelab; ZFS wins for single-node simplicity and operational maturity. The 2.3 release strengthens ZFS”s position in the single-node tier.

Christian Lempa”s “Proxmox LXC” video (Jul 28) — same week — covers the container substrate question. Most homelab users running ZFS in 2025 do it underneath Proxmox, and the LXC vs VM decision shapes how ZFS”s features (snapshots, send/receive, dataset hierarchy) actually get used in practice.

The Reddit dissent through 2025 splits productively:

• The “ZFS is overkill for homelab” camp — accurate for users who don”t need snapshots, send/receive, or RAIDZ-style redundancy beyond mirroring. For them, mdadm + ext4 or BTRFS is simpler.
• The “ZFS is the only adult filesystem” camp — also accurate for users who DO need those features. Data integrity, checksum scrubs, send/receive replication — the operational primitives are real.
• The “stop debating filesystems, ship something” camp — meta-critique. The discourse can get religious; for most users, picking a working filesystem and getting on with infrastructure work matters more than optimizing the choice.

What this means for working homelabbers in mid-July 2025

Three practical positions:

1. If you have an existing ZFS pool, upgrade to 2.3 when your platform offers it. Stability improvements and RAIDZ expansion both matter; the upgrade is low-risk.

2. If you”ve been waiting to add a drive to RAIDZ, now you can. The feature works, has real caveats (old parity ratio on existing data), and is worth using for capacity needs.

3. If you”re evaluating ZFS vs alternatives for a new homelab, 2.3 strengthens the case but doesn”t change the fundamentals. ZFS is right for users who need its features (snapshots, integrity, replication). It”s overkill for users who just want a NAS.

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, see TrueNAS Scale vs Core and Proxmox VE review.