4 ms·

Subsets of BPR have gone in...that's more or less what vdev evacuation does, for example. I would be curious to see how practical someone writing something lik

Subsets of BPR have gone in...that's more or less what vdev evacuation does, for example. I would be curious to see how practical someone writing something like this would be without requiring one make an entirely new pool or do offline conversion...

cryptonector 4y ago
vdev evac is NOT BP rewrite. vdev evac simply plays a trick of a) copying a vdev to another, then b) making the new vdev's ID the same as the old so that all the physical block pointers that referred to the old vdev remain valid after the move. But this cannot support defragmentation because the block addresses within the vdev (old vdev and new vdev) cannot change. The fundamental problem I described above is just too hard to overcome in ZFS. Therefore the only thing that can be done about problems like this is to find alternative solutions. vdev evac is one such solution to one of the problems BP rewrite was meant to solve. In a reply to a sibling to yours I outline a way in which ZFS could solve the defragmentation problem without a proper BP rewrite. Enough such solutions might make BP rewrite not necessary at all.
- 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 ago
    I'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.)

cryptonector 4y ago

vdev evac is NOT BP rewrite. vdev evac simply plays a trick of a) copying a vdev to another, then b) making the new vdev's ID the same as the old so that all the physical block pointers that referred to the old vdev remain valid after the move. But this cannot support defragmentation because the block addresses within the vdev (old vdev and new vdev) cannot change. The fundamental problem I described above is just too hard to overcome in ZFS. Therefore the only thing that can be done about problems like this is to find alternative solutions. vdev evac is one such solution to one of the problems BP rewrite was meant to solve. In a reply to a sibling to yours I outline a way in which ZFS could solve the defragmentation problem without a proper BP rewrite. Enough such solutions might make BP rewrite not necessary at all.

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 ago
  I'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.)