On 2021/8/30 上午11:48, Konstantin Svist wrote:

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

quoted

...

quoted

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

Can you provide the full output? (both stdout and stderr)

If you're concerning about the filenames, "btrfs ins dump-tree" has
--hide-names to mask all the file/dir names.

190 lines look too few than expected, thus means some tree blocks are
not read out properly.

You may want to try other bytenr to see which gives the most amount of
output (thus most possible to restore some data).

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

# btrfs restore -Divf 196816535552 /dev/sdb3 .

Where the bytenr 196816535552 is from?

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 part is expected, it just tries to read extent tree which is
manually corrupted.

This is a dry-run, no files are going to be restored
Done searching

While this is not expected, as it doesn't even show any research
attempts, is the bytenr from the subtree of the subvolume 257?

Thanks,
Qu