[Ded7xSEoPKYNsDd]

Btrfs supports it. The parity stays exactly where it is, but new files will use the new device. You can (and far too often have to, when btrfs decides there is no free space left) also perform a 'balance' operation, which recreates all the b-trees on the disks, optionally with different parity options.

[StavrosK]

Hmm, I don't understand how that's possible on RAID-Z? You can only have as much space per disk as the parity, no? I.e. you can't have three 500 GB disks for a total of 1 GB space, and replace one with a 1 GB disk and get more space, can you?

[rocqua]

The idea is to add disks rather than replace. So to go from 3x500GB to 4x500GB.

[StavrosK]

Oh, I see. In that case, it's odd to me that ZFS doesn't support that, hmm.

[nske]

Well, it was designed for by a company targeting enterprise customers. I guess this feature would be secondary for that market.

[takeda]

That doesn't make much sense, how can you change parity on the fly? I suspect it does the same thing as ZFS; it just adds another vdev

[Ded7xSEoPKYNsDd]

For each chunk of on-disk data, the fs stores which devices it is stored on and the used parity configuration. You can take one such chunk of data, and clone it into a new chunk with identical contents but a different parity configuration in the free space of the devices that are part of the file system. (Just like you'd allocate new chunks for storing new files in the same parity configuration). Once that copy is created, all references to the old chunk are changed to point to the new chunk and so the old chunk is now free space. Repeat this process for all chunks in the file system, and the whole file system is converted to use a different parity configuration.