...It took me writing out my original question to recognize why X:=(an in-place upgrade from RAIDZ1 to RAIDZ2) is non-trivial to implement. (Original question:

...It took me writing out my original question to recognize why X:=(an in-place upgrade from RAIDZ1 to RAIDZ2) is non-trivial to implement. (Original question: Why X hasn't been implemented yet?) https://www.raidz-calculator.com/raidz-types-reference.aspx https://www.raidz-calculator.com/raidz-types-reference.aspx The general difference between the two is RAIDZ2's additional blocks from its 2nd parity function, which seems independent from the 1st. The (ideal) set of operations that would happen would be: 1) Treat existing parity disk as blank without overwriting it 2) Write to chosen parity disks 1 & 2 from new disks (assertion: new disks >= 2) 3) Blank out old parity disk Step (1) would be near-instant, since it involves no writes. (3) either involves removing the block entries on the old parity disk and treating it as blank (near-instant), or writing zeroes to the disk (lengthy). The bulk of the time would be spent on (2). The process of doing this migration would require siloing off writes to another place whilst the new parity disks are being built. Considering that this migration (A) very rarely occurs, and (B) would require a write silo in the interim, devoting time into creating this error-prone task would not be wise.