Re: Trying to recover data from SSD

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/8/29 下午2:34, Konstantin Svist wrote:
> On 8/28/21 16:30, Qu Wenruo wrote:
>>
>>
>> On 2021/8/29 上午7:16, Konstantin Svist wrote:
>>> On 8/27/21 23:16, Qu Wenruo wrote:
>>>>
>>>>
>>>> On 2021/8/28 下午1:57, Konstantin Svist wrote:
>>>>> On 8/20/21 19:56, Konstantin Svist wrote:
>>>>>> On 8/11/21 18:18, Qu Wenruo wrote:
>>>>>>>
>>>>>>> On 2021/8/12 上午6:34, Konstantin Svist wrote:
>>>>>>>> Shouldn't there be an earlier generation of this subvolume's tree
>>>>>>>> block
>>>>>>>> somewhere on the disk? Would all of them have gotten overwritten
>>>>>>>> already?
>>>>>>> Then it will be more complex and I can't ensure any good result.
>>>>>>
>>>>>> It was already pretty complex and results were never guaranteed :)
>>>>>>
>>>>>>
>>>>>>> Firstly you need to find an older root tree:
>>>>>>>
>>>>>>> # btrfs ins dump-super -f /dev/sdb3 | grep backup_tree_root
>>>>>>>                    backup_tree_root:       30687232        gen: 2317
>>>>>>>     level: 0
>>>>>>>                    backup_tree_root:       30834688        gen: 2318
>>>>>>>     level: 0
>>>>>>>                    backup_tree_root:       30408704        gen: 2319
>>>>>>>     level: 0
>>>>>>>                    backup_tree_root:       31031296        gen: 2316
>>>>>>>     level: 0
>>>>>>>
>>>>>>> Then try the bytenr in their reverse generation order in btrfs ins
>>>>>>> dump-tree:
>>>>>>> (The latest one should be the current root, thus you can skip it)
>>>>>>>
>>>>>>> # btrfs ins dump-tree -b 30834688 /dev/sdb3 | grep "(257 ROOT_ITEM"
>>>>>>> -A 5
>>>>>>>
>>>>>>> Then grab the bytenr of the subvolume 257, then pass the bytenr to
>>>>>>> btrfs-restore:
>>>>>>>
>>>>>>> # btrfs-restore -f <bytenr> /dev/sdb3 <restore_path>
>>>>>>>
>>>>>>> The chance is already pretty low, good luck.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Qu
>>>>>>
>>>>>>
>>>>>> When I run dump-tree, I get this:
>>>>>>
>>>>>> # btrfs ins dump-tree -b 787070976 /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
>>>>>>
>>>>>> The same exact offset fails checksum for all 4 backup roots, any way
>>>>>> around this?
>>>>
>>>> When without the grep, is there any output?
>>>
>>>
>>> # btrfs ins dump-tree -b 787070976 /dev/sdb3
>>> btrfs-progs v5.13.1
>>> 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
>>> node 787070976 level 1 items 7 free space 486 generation 166932 owner
>>> ROOT_TREE
>>> node 787070976 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid 44a768e0-28ba-4c6a-8eef-18ffa8c27d1b
>>> chunk uuid a8a06213-eebf-40d8-ab1a-914f621fbe1c
>>>       key (EXTENT_TREE ROOT_ITEM 0) block 787087360 gen 166932
>>>       key (277 INODE_ITEM 0) block 197491195904 gen 56511
>>>       key (305 INODE_ITEM 0) block 778174464 gen 166929
>>>       key (366 EXTENT_DATA 0) block 197491949568 gen 56511
>>>       key (428 INODE_ITEM 0) block 36175872 gen 166829
>>>       key (476 INODE_ITEM 0) block 787234816 gen 166932
>>>       key (FREE_SPACE UNTYPED 99888398336) block 780812288 gen 166929
>>
>> My bad, I forgot to add "--follow" option for "btrfs ins dump-tree"
>>
>> So the full command is:
>>
>> $ btrfs ins dump-tree -b 787070976 --follow /dev/sdb3
>>
>> Then you should be able to find "(257 ROOT_ITEM".
>>
>
> # 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.

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

Have you tried other bytenrs from find-root?

Thanks,
Qu
>
>