Hi Chris, Thanks for your suggestions
On 02/10/16, Chris Murphy wrote: > Well short of a bug, the problem aren't the checksums. The problem is > the metadata is wrong, so if you recalculate checksums you're likely > end up with an even more corrupted file system because it'll start out > trusting bad metadata. > > If you're prepared to lose this filesystem, use --repair and see if it > can fix the metadata problems despite csum failures. If it were me, > I'd take a btrfs-image before --repair. In theory, if it makes things > worse you can restore the image, or donate the image to making the > btrfsck better. > > If --repair doesn't work, try -b --repair. > > If that doesn't work then I'd probably use --init-extent-tree which, > while it's a heavy hammer, at least still isn't going to pretend bad > metadata is good which is what --init-csum-tree will end up doing. > > But before all of that I'm curious what you get for: > > btrfs-debug-tree -b 11185160192 /dev/sda3 > btrfs-find-root /dev/sda3 The output from btrfs-debug-tree command is: https://ptpb.pw/0weU The btrfs-find-root: https://ptpb.pw/PIZe The btrfs-show-super -f : https://ptpb.pw/O4C9 I tried the btrfs-image but failed # btrfs-image /dev/sda3 /root/sda3-btrfs-image.bin with output https://ptpb.pw/jtDJ Unless there's some other idea I will continue with the following: # btrfs check --repair # btrfs check -b --repair # btrfs check --init-extent-tree --repair and see if I can get something Thanks, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- 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
