4 ms·

> Does anyone know why this is the case? > Considering the process is already reading and rewriting basically the entire array, why not recalculate the parity

> Does anyone know why this is the case? > Considering the process is already reading and rewriting basically the entire array, why not recalculate the parity as well? IANA expert but my guess is -- because, here, you don't have to modify block pointers, etc. ZFS RAIDZ is not like traditional RAID, as it's not just a sequence of arbitrary bits, data plus parity. RAIDZ stripe width is variable/dynamic, written in blocks (imagine a 128K block, compressed to ~88K), and there is no way to quickly tell where the parity data is within a written block, where the end of any written block is, etc. If you had to instead, modify the block pointers, I'd assume you have to also change each block in the live tree and all dependent (including snapshot) blocks at the same time? That sounds extraordinarily complicated (and this is the data integrity FS!), and much slower, than just blasting through the data, in order. To do what you want, you can do what one could always do -- zfs send/recv between a filesystem between and old and new filesystem.

toast0 3y ago
> To do what you want, you can do what one could always do -- zfs send/recv between a filesystem between and old and new filesystem. Sure, but that involves having enough spare disks, enough places to put them, and enough places to connect them. This way, while the initial expansion is not ideal, it works. If you really need the space gains from a wider distribution, you can do this expansion and then do the make a new copy, then replace old copy with a new copy dance... although that's counter productive if you have snapshots.
- mustache_kimono 3y ago
  > Sure, but that involves having enough spare disks So long as we are pointing out things: this presumes that the user doesn't have enough space to make the copies on their own disks? If one has a 3GB dataset and 9GB of free space, one can easily zfs send/recv that dataset and destroy the old copy. > This way, while the initial expansion is not ideal, it works. Yep. > If you really need the space gains from a wider distribution, you can do this expansion and then do the make a new copy, then replace old copy with a new copy dance... although that's counter productive if you have snapshots. That's why you do a zfs send/recv, instead of a copy. ZFS will copy your snapshots for you!
crote 3y ago
But you are moving the blocks to other disks anyway, surely that would require a change of the block pointers too?
- mustache_kimono 3y ago
  Again not an expert -- but if you look at the presentations re: this feature, I presume you wouldn't. Why? Because another feature, adopted concurrently, provides for time independent geometry? So, if you look at the pool after time X, you have the same block #, etc., but with a different geo.

toast0 3y ago

> To do what you want, you can do what one could always do -- zfs send/recv between a filesystem between and old and new filesystem. Sure, but that involves having enough spare disks, enough places to put them, and enough places to connect them. This way, while the initial expansion is not ideal, it works. If you really need the space gains from a wider distribution, you can do this expansion and then do the make a new copy, then replace old copy with a new copy dance... although that's counter productive if you have snapshots.

mustache_kimono 3y ago
> Sure, but that involves having enough spare disks So long as we are pointing out things: this presumes that the user doesn't have enough space to make the copies on their own disks? If one has a 3GB dataset and 9GB of free space, one can easily zfs send/recv that dataset and destroy the old copy. > This way, while the initial expansion is not ideal, it works. Yep. > If you really need the space gains from a wider distribution, you can do this expansion and then do the make a new copy, then replace old copy with a new copy dance... although that's counter productive if you have snapshots. That's why you do a zfs send/recv, instead of a copy. ZFS will copy your snapshots for you!

crote 3y ago

But you are moving the blocks to other disks anyway, surely that would require a change of the block pointers too?

mustache_kimono 3y ago
Again not an expert -- but if you look at the presentations re: this feature, I presume you wouldn't. Why? Because another feature, adopted concurrently, provides for time independent geometry? So, if you look at the pool after time X, you have the same block #, etc., but with a different geo.