Well it looks like metadata corruption, if it were just a case of data corruption there'd be a file name path associated with the checksum mismatch error; and in that case you'd be able to just delete the file (or first extract a copy of it it with btrfs restore) and then it wouldn't trigger csum errors anymore, and replace it with a confirmed good copy later.
Also, btrfs check by itself doesn't check data extent csums, only metadata csums. So again it sounds like there's a corrupt leaf and for whatever reason it's not being fixed up by parity. And Btrfs really obsinate about continuing on, especially read-write mounted, once there's a csum error in metadata that it can't fix from parity or another copy. And even XFS now will also go read only in similar circumstances. It's just that its repair is a lot older and has some ways to infer metadata when it's missing or bad, and Btrfs check hasn't gotten that far yet. I think one of the future tests for btrfs check when it hits csum errors is the ability to test if the outcome is plausible if it assumes the metadata is actually good and it's the csum itself that's bad. Or to iterate plausible variations of metadata that cause the csum to match. And if it all works out then to CoW the rebuilt metadata. Anyway, fixing this would be really tedious with the existing tools. You'd need to iterate some portions of this leaf to get it to match its csum; or just change the csum to match the metadata as it is right now, and then see if things work again. It's a reasonably good idea though to just delete any associated file, because that will cause its metadata to go away also, and the source of this problem. But often a leaf or node will contain references to more than just one file. -- 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
