All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Svist <fry.kun@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Trying to recover data from SSD
Date: Sun, 29 Aug 2021 20:48:05 -0700	[thread overview]
Message-ID: <74809aba-047e-ca7a-e5b4-d64287ddd81d@gmail.com> (raw)
In-Reply-To: <5858520a-ca82-0552-140d-9702fc7dad94@gmx.com>

On 8/29/21 17:22, Qu Wenruo wrote:
>
>
> On 2021/8/30 上午4:02, Konstantin Svist wrote:
>> On 8/29/21 00:19, Qu Wenruo wrote:
>>>
>>>
>>> On 2021/8/29 下午2:34, Konstantin Svist wrote:
>>>>
>>>> # 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?
>>
>>
>> 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...
>>
>>
>> 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




  reply	other threads:[~2021-08-30  3:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10  4:41 Trying to recover data from SSD Konstantin Svist
2021-08-10  5:24 ` Qu Wenruo
     [not found]   ` <CADQtc0=GDa-v_byewDmUHqr-TrX_S734ezwhLYL9OSkX-jcNOw@mail.gmail.com>
2021-08-10  6:56     ` Qu Wenruo
2021-08-10 16:12       ` Konstantin Svist
2021-08-10 22:24         ` Qu Wenruo
2021-08-10 23:21           ` Konstantin Svist
2021-08-10 23:54             ` Qu Wenruo
2021-08-11  5:22               ` Konstantin Svist
2021-08-11  5:24                 ` Qu Wenruo
2021-08-11  5:34                   ` Konstantin Svist
2021-08-11  5:49                     ` Qu Wenruo
2021-08-11 19:33                       ` Konstantin Svist
2021-08-11 21:51                         ` Qu Wenruo
2021-08-11 22:34                           ` Konstantin Svist
2021-08-12  1:18                             ` Qu Wenruo
2021-08-21  2:56                               ` Konstantin Svist
2021-08-28  5:57                                 ` Konstantin Svist
2021-08-28  6:16                                   ` Qu Wenruo
2021-08-28 23:16                                     ` Konstantin Svist
2021-08-28 23:30                                       ` Qu Wenruo
2021-08-29  6:34                                         ` Konstantin Svist
2021-08-29  7:19                                           ` Qu Wenruo
2021-08-29 20:02                                             ` Konstantin Svist
2021-08-30  0:22                                               ` Qu Wenruo
2021-08-30  3:48                                                 ` Konstantin Svist [this message]
2021-08-30  7:20                                                   ` Qu Wenruo
     [not found]                                                     ` <aa33b83f-b822-b1d8-9fe4-5cf4ab45c3e1@gmail.com>
2021-08-31 11:05                                                       ` Qu Wenruo
2021-09-01  1:38                                                         ` Konstantin Svist
2021-09-01  1:47                                                           ` Qu Wenruo
2021-08-11  0:30       ` Zygo Blaxell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74809aba-047e-ca7a-e5b4-d64287ddd81d@gmail.com \
    --to=fry.kun@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.