On 8/29/21 17:22, Qu Wenruo wrote:

On 2021/8/30 上午4:02, Konstantin Svist wrote:

quoted

On 8/29/21 00:19, Qu Wenruo wrote:

quoted

On 2021/8/29 下午2:34, Konstantin Svist wrote:

quoted

# btrfs ins dump-tree -b 787070976 --follow /dev/sdb3 | grep "(257
ROOT_ITEM" -A 5
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
Csum didn't match
WARNING: could not setup extent tree, skipping it
      item 13 key (257 ROOT_ITEM 0) itemoff 13147 itemsize 439
          generation 166932 root_dirid 256 bytenr 786726912 level 2
refs 1
          lastsnap 56690 byte_limit 0 bytes_used 1013104640 flags
0x0(none)
          uuid 1ac60d28-6f11-2842-aca2-b1574b108336
          ctransid 166932 otransid 8 stransid 0 rtransid 0
          ctime 1627959592.718936423 (2021-08-02 19:59:52)


# btrfs restore -Divf 786726912 /dev/sdb3 .
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
Csum didn't match
WARNING: could not setup extent tree, skipping it
This is a dry-run, no files are going to be restored
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
bad tree block 920748032, bytenr mismatch, want=920748032, have=0
ERROR: search for next directory entry failed: -5

This all zero means the data on-disk are wiped.

Either not reaching disk or discarded.

Neither is a good thing.

quoted

1st set of "checksum verify failed" has different addresses, but the
last set always has 920748032

Have you tried other bytenrs from find-root?

Is it normal that they all fail on the same exact block? Sounds
suspicious to me.

This means some higher tree block is corrupted.

Only manual inspection can determine.

But this is definite not a good thing for your data salvage...

quoted

The other 3 attempts:


# btrfs ins dump-super -f /dev/sdb3 | grep backup_tree_root
         backup_tree_root:    787070976    gen: 166932    level: 1
         backup_tree_root:    778108928    gen: 166929    level: 1
         backup_tree_root:    781172736    gen: 166930    level: 1
         backup_tree_root:    786399232    gen: 166931    level: 1

# btrfs ins dump-tree -b 786399232 --follow /dev/sdb3 | grep "(257
ROOT_ITEM" -A 5
[...]
     item 13 key (257 ROOT_ITEM 0) itemoff 13147 itemsize 439
         generation 166931 root_dirid 256 bytenr 781467648 level 2
refs 1
         lastsnap 56690 byte_limit 0 bytes_used 1013104640 flags
0x0(none)

[...]

To manually inspect the tree, you can use btrfs-inspect to see what's
wrong with the tree blocks.

# btrfs ins dump-tree -b 781467648 --follow --bfs /dev/sdb3

This also means, even the remaining part is fine, a big chunk of data
can no longer be recovered. 

I'm hoping to find several important files at this point, definitely
don't need the whole FS..

So when I run this, I get about 190 lines like

    key (256 INODE_ITEM 0) block 920748032 gen 166878
    key (52607 DIR_ITEM 988524606) block 1078902784 gen 163454
    key (52607 DIR_INDEX 18179) block 189497344 gen 30
    key (174523 INODE_REF 52607) block 185942016 gen 30
    key (361729 EXTENT_DATA 0) block 785907712 gen 166931
    key (381042 XATTR_ITEM 3817753667) block 1027391488 gen 120910


I tried to pass these into restore, but it's not liking it:

# btrfs restore -Divf 196816535552 /dev/sdb3 .
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
Csum didn't match
WARNING: could not setup extent tree, skipping it
This is a dry-run, no files are going to be restored
Done searching