Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree [chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1 btrfs-progs v4.7 checksum verify failed on 16913485824 found FEAA7A13 wanted 20000000 checksum verify failed on 16913485824 found FEAA7A13 wanted 20000000 bytenr mismatch, want=16913485824, have=14276644976086482944 ERROR: failed to read 16913485824
[chris@f24s ~]$ sudo btrfs-debug-tree -b 246050455552 /dev/mapper/brick1 btrfs-progs v4.7 checksum verify failed on 246050455552 found E4E3BDB6 wanted 00000000 checksum verify failed on 246050455552 found E4E3BDB6 wanted 00000000 bytenr mismatch, want=246050455552, have=0 ERROR: failed to read 246050455552 [chris@f24s ~]$ sudo btrfs-debug-tree -b 285446881280 /dev/mapper/brick1 btrfs-progs v4.7 checksum verify failed on 285446881280 found 6BB60B47 wanted C9310000 checksum verify failed on 285446881280 found 6BB60B47 wanted C9310000 bytenr mismatch, want=285446881280, have=5188146780436697072 ERROR: failed to read 285446881280 So, all I can say is these must be stale, and that's why their checksums are wrong; or there's a pretty big big in Btrfs scrub right now because it came up clean. So at the moment I'm going with the idea that there's a bug in btrfs check 4.7 that's reporting non-real problems. 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
