RAIDZ expansion on PVE 9.2 / kernel 7.0.14-24: affected code and supported stable fixes

C

ctrlshift

New Member
Oct 31, 2026
4
0
1
Hello,

I'm preparing to expand an existing two-disk RAIDZ1 vdev to three disks on a home Proxmox VE server. The expansion has not been started. I would like to identify a supported stable fix, or establish whether the following upstream reports apply to our kernel build, before proceeding.

Current environment:

- Proxmox VE 9.2.21, running kernel `7.0.14-24-pve`.
- ZFS userland and loaded kernel module both report `2.4.4-pve1`.
- Installed signed kernel package: `proxmox-kernel-7.0.14-24-pve-signed`, version `7.0.14-24`; its package metadata lists the signing-wrapper source as `proxmox-kernel-signed-7.0`, version `7.0.14+24`.

My source review traced the public kernel version-bump commit `316d1680efe8277d3ce6d8b2cf2e19c838e9173a` (KREL 24) to its ZFS submodule `dcd0e4345f4253bb9e44cc1ab54c6f73196421aa`, then to upstream `71a9f9578616a90c3c14bb59629fb4d31bfd68d1` (ZFS 2.4.4) plus ten Proxmox patches. I did not find the fixes below in that patch queue. This is a static source review, not a reproduction on our system or a reproducible-build attestation.

The reports I'm concerned about are:

1. [OpenZFS #19404](https://github.com/openzfs/zfs/issues/19404), proposed fix [#19405](https://github.com/openzfs/zfs/pull/19405): opening from a stale cachefile after expansion completion may fail because the cached RAIDZ layout is older than the labels.
2. [OpenZFS #19420](https://github.com/openzfs/zfs/issues/19420), proposed fix [#19603](https://github.com/openzfs/zfs/pull/19603): a crash between reflow completion and the subsequent capacity-growth step may leave the added capacity unavailable.
3. [OpenZFS #19423](https://github.com/openzfs/zfs/issues/19423), fix [#19550](https://github.com/openzfs/zfs/pull/19550): expansion can remain paused if a short resilver finishes before the expansion thread starts waiting for its wakeup. My review found #19550 merged into upstream master, but did not establish a stable Proxmox backport.

The original reports used development/userspace builds. I found corresponding code sequences in stable 2.4.4, but have not established how each failure would manifest in my kernel build, including the real import fallback behavior. I'm not claiming existing data corruption or guaranteed pool loss.

Could you please clarify:

- Which of these mechanisms affect the official build above and the planned RAIDZ1 2-to-3 expansion? If any do not apply, what implementation detail or existing fix rules them out?
- Is there a supported stable Proxmox kernel/ZFS package that fixes the applicable mechanisms, including accepted equivalent fixes? Please provide exact binary/source package versions, repository channel, and source commits or backport references for each mechanism. A newer version number alone would not establish this.
- If no such stable package is available, is there a public tracking reference or a tentative target release? I understand that any estimate may change.
- What minimum supported update and verification procedure would you recommend before attempting expansion, and what remaining risks or recovery limitations should we account for?

I'm not requesting crash experiments on the production pool or an unsupported self-built ZFS installation. Any kernel update/reboot and the subsequent expansion will be separately reviewed and authorized. We can provide additional non-sensitive package metadata if needed.

Thank you.
 
ctrlshift said:
Thanks for checking. In this case, the existing vdev is actually a two-disk RAIDZ1: zpool status explicitly reports raidz1-0, not mirror-0.

OpenZFS supports RAIDZ1 with a minimum of two disks, although three or more are recommended:
https://openzfs.github.io/openzfs-docs/Basic Concepts/Pool Structure/VDEVs.html

Therefore, the planned operation is RAIDZ expansion from two to three disks, not adding a third member to a mirror.
Click to expand...
Ok, thanks for clarity:

"RAIDZ1: Single parity, similar to RAID 5. Requires at least 2 disks (3+ recommended), can tolerate one drive failure."

Then please go on and tell us, if you was success!
 
news said:
a two-disk ist not RAIDZ1 it is a zfs vdev mirror
Click to expand...
news said:
Ok, thanks for clarity:

"RAIDZ1: Single parity, similar to RAID 5. Requires at least 2 disks (3+ recommended), can tolerate one drive failure."

Then please go on and tell us, if you was success!
Click to expand...
Thanks. I have not started the expansion yet. Before proceeding, I would like to clirify on the three linked OpenZFS issues and whether they affect this Proxmox build.

Could a Proxmox maintainer confirm which stable kernel/ZFS package contains the applicable fixes, or explain why these issues do not apply?
I would prefer not to use my production pool as a test case).
 
check your openzfs version: zpool version
and make a test run with local zfs, create 3 new zfs volume on your current zfs pool.
Code: 
# start with a test dataset
$ zfs create rpool/test

# create new zfs volume for tests
$ zfs create -V 10G rpool/test/tvol1
$ zfs create -V 10G rpool/test/tvol2
$ zfs create -V 10G rpool/test/tvol3

# result in
/dev/zvol/rpool/test/tvol1
/dev/zvol/rpool/test/tvol2
/dev/zvol/rpool/test/tvol3

# create a zfs test pool test-pool
$ zpool create test-pool raidz1 /dev/zvol/rpool/test/tvol1 /dev/zvol/rpool/test/tvol2

# result in
$ zpool status test-pool
  pool: test-pool
 state: ONLINE
config:

    NAME                       STATE     READ WRITE CKSUM
    test-pool                  ONLINE       0     0     0
      raidz1-0                 ONLINE       0     0     0
        zvol/rpool/test/tvol1  ONLINE       0     0     0
        zvol/rpool/test/tvol2  ONLINE       0     0     0

errors: No known data errors

# attach a new disk to the zfs pool test-pool and vdev raidz1-0
$ zpool attach test-pool raidz1-0 /dev/zvol/rpool/test/tvol3

# result in
$ zpool status test-pool
  pool: test-pool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:00 with 0 errors on Sat Oct 31 17:10:25 2026
expand: expanded raidz1-0 copied 5.58M in 00:00:01, on Sat Oct 31 17:10:25 2026
config:

    NAME                       STATE     READ WRITE CKSUM
    test-pool                  ONLINE       0     0     0
      raidz1-0                 ONLINE       0     0     0
        zvol/rpool/test/tvol1  ONLINE       0     0     0
        zvol/rpool/test/tvol2  ONLINE       0     0     0
        zvol/rpool/test/tvol3  ONLINE       0     0     0
 
Last edited:
  • Like
Reactions: Onslow and UdoB
Thanks for the example. I've already checked: both ZFS userland and the loaded kernel module report 2.4.4-pve1, with kernel 7.0.14-24-pve.

Your test demonstrates successful expansion under normal conditions. My concern is specifically the failure/recovery paths described in #19404, #19420 and #19423. A successful expansion without a crash or device interruption would not exercise those paths.

Do you know whether this Proxmox build includes fixes or equivalent changes for these issues, or which stable package does?
 
ctrlshift said:
Do you know whether this Proxmox build includes fixes or equivalent changes for these issues, or which stable package does?
Click to expand...
no sorry.

At all i would get 3 new disk and zfs send the total snapshot of the old zfs pool to the new one.
before that you shut halt all lxc and vm, backup jobs and so on.

if the old zfs pool drives hold a bios and/ or efu partition you must create them bevor.
 
You must log in or register to reply here.
Top Bottom
Back