> - - And, moving said extent requires giving it a new checksum [...]
> - Extents need a poison bit: "reads return errors, even though it now has a good checksum" - this was added in a separate patch queued up for 6.15.
To me, it sounds like saving the old hash could be useful. That way a human can look at the now-corrupt extent, test flipping that one odd-looking bit, and confirm that the extent now matches the old hash.
> - - And, moving said extent requires giving it a new checksum [...]
> - Extents need a poison bit: "reads return errors, even though it now has a good checksum" - this was added in a separate patch queued up for 6.15.
To me, it sounds like saving the old hash could be useful. That way a human can look at the now-corrupt extent, test flipping that one odd-looking bit, and confirm that the extent now matches the old hash.
So poison bit => failing_hash: Option<Hash>
Or we could automate that at some point by storing small reed-solomon codes instead of checksums...
If ever get a fast implementation of rslib.c. Which is probably possible since pclmulqdq.
i am barely catching up to btrfs