On Sun, Jul 10, 2016 at 1:01 AM, Tomáš Hrdina <thomas....@gmail.com> wrote:
> sudo btrfs check --repair /dev/sdc > enabling repair mode > parent transid verify failed on 7008807157760 wanted 70175 found 70133 > parent transid verify failed on 7008807157760 wanted 70175 found 70133 > checksum verify failed on 7008807157760 found F192848C wanted 1571393A > checksum verify failed on 7008807157760 found F192848C wanted 1571393A > bytenr mismatch, want=7008807157760, have=65536 > Checking filesystem on /dev/sdc > UUID: 2dab74bb-fc73-4c47-a413-a55840f6f71e > checking extents > parent transid verify failed on 7009468874752 wanted 70180 found 70133 > parent transid verify failed on 7009468874752 wanted 70180 found 70133 > checksum verify failed on 7009468874752 found 2B10421A wanted CFF3FFAC > checksum verify failed on 7009468874752 found 2B10421A wanted CFF3FFAC > bytenr mismatch, want=7009468874752, have=65536 > parent transid verify failed on 7008859045888 wanted 70175 found 70133 > parent transid verify failed on 7008859045888 wanted 70175 found 70133 > checksum verify failed on 7008859045888 found 7313A127 wanted 97F01C91 > checksum verify failed on 7008859045888 found 7313A127 wanted 97F01C91 > bytenr mismatch, want=7008859045888, have=65536 > parent transid verify failed on 7008899547136 wanted 70175 found 70133 > parent transid verify failed on 7008899547136 wanted 70175 found 70133 > checksum verify failed on 7008899547136 found 2B6F9045 wanted CF8C2DF3 > parent transid verify failed on 7008899547136 wanted 70175 found 70133 > Ignoring transid failure > leaf parent key incorrect 7008899547136 > bad block 7008899547136 > Errors found in extent allocation tree or chunk allocation > parent transid verify failed on 7009074167808 wanted 70175 found 70133 > parent transid verify failed on 7009074167808 wanted 70175 found 70133 > checksum verify failed on 7009074167808 found FDA6D1F0 wanted 19456C46 > checksum verify failed on 7009074167808 found FDA6D1F0 wanted 19456C46 > bytenr mismatch, want=7009074167808, have=65536 OK well it was all a goose chase then. These are all the same messages from 4 days ago also. The central problem appears to be checksum verifications on multiple blocks, which really doesn't make sense to me because it should be able to reconstruct from parity. How is it possible to have four root trees, all of which point to different leaf/nodes, all of which have some kind of checksum failure? None of them are good? And none of them can be reconstructed? Sounds fishy. You try to plug each of those bytenr's into btrfs-debug-tree -b <bytenr> and see if it'll show you what leaf information is there that it doesn't like. But if there's a csum mismatch, it may refuse to show anything, rather than show it and say it's unreliable due to csum mismatch. If it refuses to show it you could plug each of those failed bytenrs into btrfs-map-logical -l <bytenr> and get a device and physical sector, then you can get the entire leaf, compute a new csum and overwrite the current one. That way it now passes csum and see if that's the only problem, or if there's another brick wall later. Of course, if the csum was correct, and it's the metadata that's bad, honoring bad metadata as valid might cause a bad fix and then the whole thing implodes. But you're pretty much there already I'd say. If I were to pick an address to start with, it'd be this one. > leaf parent key incorrect 7008899547136 > bad block 7008899547136 But other than that, I'm out of ideas. It's completely reasonable to just give up at this point. -- 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
