Block Pointer V2

[NicholasRush]

Hello there,

i have seen the discussion about the clara systems "Block Pointer V2" Project and i found that this is a great thing for the development of openzfs at all. @allanjude said much about the usage and the changes they want to make to the current block pointer. But i dont´t understand why openzfs dont get a fundamental change how data is stored on disk, like they want do with anyraid and implement a block pointer where physiscal blocks and virtual blocks could be addressed. With this fundamental change in the block pointer you could add way much features than today. And this could affect how zfs does compression and deduplication in the future. Because you could store multiple small virtual blocks in one physiscal block, that is not possible today. And deduplication could run on these virtual blocks that equal to the on disk recordsize (4K) that is also not possible today. The only thing that should work as today is compression, because it works great like it is. That means, that this fundamental change would make openzfs much much more space efficent than today. Maybe there would be much more things that would be better with a block pointer that works like this.

Maybe it would be possible to later add a vdev type that act like a jbod with separate parity drives. Where you could add disks to the vdev without rewrite the data on the disks and add or remove parity drives without data movement on the data disks. Then you could have this flexibility, that you want add today with anyraid backed by raid-z. But without raid-z and its limitations. And you could get the same speed out of a vdev type like this, by distributing blocks like raid 0 across all of the data type (jbod) disks. The parity disks in the jbod only have the parity data and thanks to the copy-on-write nature of ZFS, they can be updated in such a way that they don't become hotspots. This VDEV type would then be similar to RAID 4, but with up to three parity disks, similar to RAID-Z.

Sincerly
NicholasRush