On Wed, Aug 24, 2016 at 11:59 AM, Chris Murphy <li...@colorremedies.com> wrote: > 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
Looks like the above is simply invalid usage on my part. The backref value doesn't apply to btrfs-debug-tree -b and must be some other thing. Those values don't show up as either nodes or leaves, only as a reference to extent data. But a complete btrfs-debug-tree has no complaints about the file system, so I'm still not sure the btrfs check complaints are valid. -- 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
