Re: Trying to recover data from SSD

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

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.

Thanks,
Qu

>
> dmesg has the same errors, though..
>
> Anything else I can do?
>