Re: Issue in recovering and using the mirror superblock

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

[-- Attachment #1.1: Type: text/plain, Size: 4209 bytes --]



On 2017年11月24日 00:31, koller@caramail.com wrote:
> Hi,
> 
> I am trying to recover from a mistake I made by overwriting the first GBs of my Btrfs /home partition with a non-Btrfs filesystem.

Well, in most case, the chance of recovery is already very low.

The possibility mostly relies on your device extents layout.
If all new data write is overwriting device extents belong to data, then
you will have a high chance to recover.

However this always depends on the fs you're using.

AFAIK, normal traditional fs, like ext*/xfs will build all their block
groups/AGs at mkfs time, and they are not just writing data in the first
several GB, but a lot of small write across the whole disk, which makes
recovery even harder.

> 
> I have already made a .dd image of the partition, and I am using it to try and find the mirror superblock, in particular the one at 256 GB.
> 
> When I run the "btrfs restore" command I get an error message, maybe because the mirror superblock -- I am not sure about the reason.
> 
> Using the dummy run option, from the command line I do
> 
> btrfs restore -D -u 2 /run/media/user01/SamsungHD/sda2.dd /run/media/user01/ToshibaHD/RecoveredData
> 
> The message is get is:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 0000016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> bytenr mismatch, want=20971520, have=709

Unfortunately, your chunk tree get corrupted, which is the most
important tree for btrfs.
It manages the mapping between btrfs logical address space to device offset.

Without this tree, nothing can really be recovered.

If you're really sure about the overwrite range, you could use
btrfs-dump-super to verify your system chunk mapping (where chunk tree is).

I'd say it's in the overwrite range.

> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> With the -u 1 option (instead of -u 2) I get:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 0000016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 0000016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 0000000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> I have reason to believe that the mirror superblock at 256 GB is intact (I am assuming that only the initial sectors of the partition were overwritten), so I do not understand why it is not being recovered. BTW, the size of the partition is above 300 GBs, so there is supposed to be a mirror superblock at 256 GB.

Btrfs is complex, so complex that the bootstrap depends on several
trees, not only superblock.

To be more specific, btrfs bootstraps involves:

superblock (system chunk array) -> system chunk mapping -> chunk tree ->
metadata chunk mapping -> root tree -> fs tree.

Any corruption (without valid copy) in the chain will cause the mount
failure.
And in your case, system chunk mapping is good (since it's in
superblock) but your chunk tree is corrupted.

So no chance here.

Thanks,
Qu

> 
> Can anyone help me?
> 
> --------
> 
> Here is the btrfs info:
> 
> uname -a
> Linux adfa-workstation 4.9.63-1-MANJARO #1 SMP PREEMPT Sat Nov 18 14:12:41 UTC 2017 x86_64 GNU/Linux
> 
> btrfs --version
> btrfs-progs v4.13
> 
> Thanks
> 
> Terry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]