All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Konstantin Svist <fry.kun@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Subject: Re: Trying to recover data from SSD
Date: Thu, 12 Aug 2021 05:51:21 +0800	[thread overview]
Message-ID: <4bd90f4a-7ced-3477-f113-eee72bc05cbb@gmx.com> (raw)
In-Reply-To: <238d1f6c-20a9-f002-e03a-722175c63bd6@gmail.com>



On 2021/8/12 上午3:33, Konstantin Svist wrote:
> On 8/10/21 22:49, Qu Wenruo wrote:
>>
>>
>> On 2021/8/11 下午1:34, Konstantin Svist wrote:
>>> On 8/10/21 22:24, Qu Wenruo wrote:
>>>>
>>>>
>>>> On 2021/8/11 下午1:22, Konstantin Svist wrote:
>>>>> On 8/10/21 16:54, Qu Wenruo wrote:
>>>>>>
>>>>>> Oh, that btrfs-map-logical is requiring unnecessary trees to
>>>>>> continue.
>>>>>>
>>>>>> Can you re-compile btrfs-progs with the attached patch?
>>>>>> Then the re-compiled btrfs-map-logical should work without problem.
>>>>>
>>>>>
>>>>>
>>>>> Awesome, that worked to map the sector & mount the partition.. but I
>>>>> still can't access subvol_root, where the recent data is:
>>>>
>>>> Is subvol_root a subvolume?
>>>>
>>>> If so, you can try to mount the subvolume using subvolume id.
>>>>
>>>> But in that case, it would be not much different than using
>>>> btrfs-restore with "-r" option.
>>>
>>>
>>> Yes it is.
>>>
>>> # mount -oro,rescue=all,subvol=subvol_root /dev/sdb3 /mnt/
>>> mount: /mnt: can't read superblock on /dev/sdb3.
>>
>> I mean using subvolid=<number>
>>
>> Using subvol= will still trigger the same path lookup code and get
>> aborted by the IO error.
>>
>> To get the number, I guess the regular tools are not helpful.
>>
>> You may want to manually exam the root tree:
>>
>> # btrfs ins dump-tree -t root <device>
>>
>> Then look for the keys like (<number> ROOT_ITEM <0 or number>), and try
>> passing the first number to "subvolid=" option.
>
> This works (and numbers seem to be the same as from dump-tree):
> # mount -oro,rescue=all /dev/sdb3 /mnt/
> # btrfs su li /mnt/
> ID 257 gen 166932 top level 5 path subvol_root
> ID 258 gen 56693 top level 5 path subvol_snapshots
> ID 498 gen 56479 top level 258 path subvol_snapshots/29/snapshot
> ID 499 gen 56642 top level 258 path subvol_snapshots/30/snapshot
> ID 500 gen 56691 top level 258 path subvol_snapshots/31/snapshot
>
> This also works (not what I want):
> # mount -oro,rescue=all,subvol=subvol_snapshots /dev/sdb3 /mnt/
>
>
> But this doesn't:
>
> # mount -oro,rescue=all,subvolid=257 /dev/sdb3 /mnt/
> mount: /mnt: can't read superblock on /dev/sdb3.
>
> dmesg:
> BTRFS error (device sdb3): bad tree block start, want 920748032 have 0
>
>
Then it means, the tree blocks of that subvolume is corrupted, thus no
way to read that subvolume, unfortunately.

Thanks,
Qu

  reply	other threads:[~2021-08-11 21:51 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 [this message]
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
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=4bd90f4a-7ced-3477-f113-eee72bc05cbb@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=fry.kun@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.