4 ms·
I don't expect this to land any time soon, if ever. It's a very large change, and very complicated. It's been in progress ever since I started using zfs, and th
by minimaul 6y ago
I don't expect this to land any time soon, if ever. It's a very large change, and very complicated. It's been in progress ever since I started using zfs, and that was years ago :)
It's worth noting you can expand a RAIDZ through replacing disks - if you start off with a pool of 4x2TB for instance say giving 6TB usable, you can expand it by replacing those disks one by one with 4TB disks - in which case you eventually end up with 12TB usable, once all disks are replaced.
Alternatively, you can add another RAIDZ to the same pool with extra disks (but you will lose more capacity this way).
Otherwise, recreate the pool, and restore from your backup (which you definitely have, right?). Assuming both your live and backup are zfs, this is easy with zfs send | zfs receive.
- secabeen 6y agoYeah. The backing reason is that ZFS has an axiom that data, once written to disk, never changes. That includes moving data to a different location. Changing that either means a massive relocation table, or some other yet-to-be-coded tool.