On May 5, 2014, at 9:11 AM, George Pochiscan <george.pochiscan@xxxxxxx> wrote: > Hello Hugo, > > Running btrfs-zero-log /dev/md127 i have the following error: > > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9 > Csum didn't match > btrfs-zero-log: extent-tree.c:2717: alloc_reserved_tree_block: Assertion `!(ret)' failed. > Aborted (core dumped) > > Full output : http://pastebin.com/3h5zVuWg > Full dmesg : http://pastebin.com/r9Fk8J8F OK. Well I'm out of ideas at this point. I'm not a developer, and don't know what the problem is or how to fix it. So my advice at this point will be like throwing spaghetti at a wall. (There is a lot of spaghetti available to throw at the wall when it comes to fixing btrfs if the normal mount code doesn't fix it automatically.) Baring better advice from pretty much anyone else: - First, btrfs-image -c9 -t4 /dev/md127 /path/for/large/file The resulting file will be somewhere between 50% to 100% of the size reported for metadata by btrfs filesystem df. put this somewhere in case a developer wants to look at it in the current state. - Then, btrfs check --init-csum-tree /dev/md127 will remove all checksums from the file system and should remove the csum errors preventing mount. The problem with this is it removes all checksums, so every read is reported as a mismatch but still permits the reads to proceed. As a result it's just a way to mount the file system, make a backup, and then created a new file system to restore to. So it's a recovery operation rather than a repair operation. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
