On Mon, Jul 4, 2016 at 1:11 PM, Tomáš Hrdina <thomas.rkh@xxxxxxxxx> wrote: > Result from dmesg: > http://sebsauvage.net/paste/?4e8e95b5eafbf675#ybToBzZ/WAoRjjugeH6N2YXZKEBlswaNI/J41GBmFYU= [10849.041749] BTRFS info (device sda): allowing degraded mounts [10849.041754] BTRFS info (device sda): disk space caching is enabled [10849.041756] BTRFS: has skinny extents [10849.090553] BTRFS error (device sda): bad tree block start 10160120763642806272 12678831570944 [10849.090676] BTRFS error (device sda): bad tree block start 10160120763642806272 12678831570944 [10849.090700] BTRFS: failed to read chunk tree on sda [10849.100153] BTRFS: open_ctree failed Try 'mount -o ro,degraded,recovery > > sudo btrfs check /dev/sda > warning, device 3 is missing > checksum verify failed on 12678831570944 found 3DC57E3E wanted 771D2379 > checksum verify failed on 12678831570944 found 3DC57E3E wanted 771D2379 > bytenr mismatch, want=12678831570944, have=10160133442474442752 > Couldn't read chunk tree > Couldn't open file system Want and have are way far apart. If the mount command above still fails then I'd like to see: # btrfs-show-super -fa /dev/sda # btrfs-show-super -fa /dev/sdb Pretty much look for any discrepancies in generation, root and chunk_root addresses, both in the main part of the super as well as in the backups. # btrfs-find-root /dev/sda Maybe it's possible to use a different tree to get it mounted. I don't know what happened but merely a failing device should not either break checksums or lose the ability to mount the proper tree; but for sure one of the backups should work. Have you done a scrub on this file system and do you know if anything was fixed or if it always found no problem? -- 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
