On Mon, May 16, 2016 at 5:33 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> > I would think this would be perfectly possible if some other file that had a > checksum in that node changed, thus forcing the node's checksum to be > updated. Theoretical sequence of events: > 1. Some file which has a checksum in node A gets written to. > 2. Node A is loaded into memory to update the checksum. > 3. The new checksum for the changed extent in the file gets updated in the > in-memory copy of node A. > 4. Node A has it's own checksum recomputed based on the new data, and then > gets saved to disk. > If something happened after 2 but before 4 that caused one of the other > checksums to go bad, then the checksum computed in 4 will have been with the > corrupted data. > I'm pretty sure Qu had a suggestion that would mitigate this sort of problem, where there'd be a CRC32C checksum for each data extent (?) something like that anyway. There's enough room to stuff in more than just a checksum per 4096 byte block. That way there's three checks, and thus there's a way to break a tie. But this has now happened to Richard twice. What are the chances of this manifesting exactly the same way a second time? If the chance of corruption is equal, I'd think the much much larger footprint for in-memory corruption is data itself. Problem is, if the corruption happens before the checksum is computed, the checksum would say the data is valid. So the only way to test this would be passing all file from this volume and a reference volume through a hash function and comparing hashes, e.g. rsync -c option. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
