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: Sat, 28 Aug 2021 16:16:00 -0700	[thread overview]
Message-ID: <36652872-850c-fe92-9fcd-c9c95dc25d65@gmail.com> (raw)
In-Reply-To: <14a9a98c-50fc-eb7b-804b-2fe36775b5fa@gmx.com>

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

# btrfs ins dump-tree -b 778108928 /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 778108928 level 1 items 7 free space 486 generation 166929 owner
ROOT_TREE
node 778108928 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 778125312 gen 166929
    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 780730368 gen 166929
    key (FREE_SPACE UNTYPED 99888398336) block 780812288 gen 166929

..and 2 more from other backup_tree_roots



  reply	other threads:[~2021-08-28 23:16 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 [this message]
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
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=36652872-850c-fe92-9fcd-c9c95dc25d65@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.