2 ms·
Okay, you're correct, it's not rewriting BPs on disk, it's adding an indirection table for them, but that's usually what's meant when discussing the topic, give
by rincebrain 4y ago
Okay, you're correct, it's not rewriting BPs on disk, it's adding an indirection table for them, but that's usually what's meant when discussing the topic, given the immutability constraint, e.g. that is my understanding of how it worked when it was implemented and not integrated at Sun, and if you check the vdev evac talk, they talk about "implementing bits of BPR as needed".
- cryptonector 4y agoI'm aware, but it's not BP rewrite. It's a workaround for not having BP rewrite. It's a fine workaround for not having BP rewrite. Enough such workarounds can make BP rewrite unnecessary -- that is what was expressed in that talk, but it's not that vdev evac == BP rewrite or that vdev evac == a bit of BP rewrite. BP rewrite is still needed for defragmentation, and for other reasons too (like if you wanted to change the configuration of a zpool to have more mirrors or stripes, or if you wanted to change compression algorithms, etc). (A proper CAS would not be able to handle things like compression algorithms, unfortunately, not unless the filesystem hashed the decompressed block rather than the compressed block, but that has security issues if you don't trust the storage, so it's not ideal. Of course, if you don't trust the storage then you need to be signing/MACing Merkle hash tree roots, but that's another story.)