June 2021 FreeBSD Developer Summit: Raid-Z Expansion

That is not how this will work. The reason the parity ratio stays the same, is that all of the references to the data are by DVA (Data Virtual Address, effectively the LBA within the RAID-Z vdev). So the data will occupy the same amount of space and parity as it did before. All stripes in RAID-Z are dynamic, so if your stripe is 5 wide and your array is 6 wide, the 2nd stripe will start on the last disk and wrap around. So if your 5x10 TB disks are 90% full, after the expansion they will contain the same 5.4 TB of data and 3.6 TB of parity, and the pool will now be 10 TB bigger. New writes, will be 4+2 instead, but the old data won't change (they is how this feature is able to work without needing block-pointer rewrite). See this presentation: ▶ this video

in “OpenZFS – Incremental add of disks to existing RAIDZ” · View on HN

For those that like videos more than text, there is a youtube video from last year [1] that explain the feature (unless it's changed since ,but it seems not to be the case). One downside that I see of this approach, if I understand it correctly, is that the data already present on disk will not take advantage of the extra disk per slice. For example, if I have a raidz of 4 disks (so 25% of space "wasted"), and add another disk, new data will be distributed on 5 disks (so 20% of space "wasted") but the old data will keep using stripes of 4 blocks, they will just be reshuffled between the disks. Do I understand it correctly ? [1] ▶ this video

in “Raid-Z Expansion Feature for ZFS Goes Live” · View on HN

> AFAIK ZFS pools can't easily be resized > you generally have to recreate them Not anymore. There is RAIDZ Expansion available. Happens on the fly. - ▶ this video - [link]

in “Ask HN: What are the best-designed things you've ever used?” · View on HN