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 13:02:03 -0700 [thread overview]
Message-ID: <4a5d64fd-637c-bd8a-fe6f-db1bb20942c2@gmail.com> (raw)
In-Reply-To: <597bd681-c7ba-075c-4376-142695b91f93@gmx.com>
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.
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)
[...]
# btrfs restore -Divf 781467648 /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
# btrfs ins dump-tree -b 781172736 --follow /dev/sdb3 | grep "(257
ROOT_ITEM" -A 5
[...]
item 13 key (257 ROOT_ITEM 0) itemoff 13147 itemsize 439
generation 166930 root_dirid 256 bytenr 780828672 level 2 refs 1
lastsnap 56690 byte_limit 0 bytes_used 1013104640 flags 0x0(none)
[...]
# btrfs restore -Divf 780828672 /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
# btrfs ins dump-tree -b 778108928 --follow /dev/sdb3 | grep "(257
ROOT_ITEM" -A 5
[...]
item 13 key (257 ROOT_ITEM 0) itemoff 13147 itemsize 439
generation 166929 root_dirid 256 bytenr 102760448 level 2 refs 1
lastsnap 56690 byte_limit 0 bytes_used 1013104640 flags 0x0(none)
[...]
# btrfs restore -Divf 102760448 /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
next prev parent reply other threads:[~2021-08-29 20:02 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 [this message]
2021-08-30 0:22 ` Qu Wenruo
2021-08-30 3:48 ` Konstantin Svist
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=4a5d64fd-637c-bd8a-fe6f-db1bb20942c2@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.