On 03/17/2017 10:27 AM, Lionel Bouton wrote: > Hi, > > Le 17/03/2017 à 09:43, Hans van Kranenburg a écrit : >> btrfs-debug-tree -b 3415463870464 > > Here is what it gives me back : > > btrfs-debug-tree -b 3415463870464 /dev/sdb > btrfs-progs v4.6.1 > checksum verify failed on 3415463870464 found A85405B7 wanted 01010101 > checksum verify failed on 3415463870464 found A85405B7 wanted 01010101 > bytenr mismatch, want=3415463870464, have=72340172838076673 > ERROR: failed to read 3415463870464
So in the place where checksum is supposed to be stored, it has 01010101 and recomputing the checksum of the garbage results in A85405B7. Found / wanted is also confusing here, since 01010101 is what it found, but A85405B7 is what it 'found out'. > Is there a way to remove part of the tree and keep the rest ? It could > help minimize the time needed to restore data. No, that's not how it works. Those trees are not file/directory structure trees. You can try btrfs-debug-tree <blockdevice> and see how far it gets dumping everything it can find, and then search for 3415463870464 in the output. Somewhere, there has to be another object (one level higher) which points to this address. If you find it, you can find out in which tree the block lives. -- Hans van Kranenburg -- 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
