Recovery options for damaged beginning of the filesystem

Recovery options for damaged beginning of the filesystem

[Shapranov Vladimir]

Hi,

I've got a filesystem with first ~50Mb accidentally dd'ed.

"btrfs check" fails with a following error (regardless of "-s"):
checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
bytenr mismatch, want=21037056, have=13515002166904211737
ERROR: cannot read chunk root
ERROR: cannot open file system

"mount -o ro /dev/sdf1 /mnt/tmp" fails, while "mount -o ro,subvol=X /mnt/tmp" succeeds for "/" and couple subvolumes.

I can even ls the root directory, but at some point something can't be read anymore and following errors appear in dmesg:
[385647.999981] btrfs_dev_stat_print_on_error: 158686 callbacks suppressed
[385648.079187] BTRFS error (device sdd1): bdev /dev/sdf1 errs: wr 0, rd 22094847, flush 0, corrupt 0, gen 0
[385648.193733] BTRFS error (device sdd1): bdev /dev/sdf1 errs: wr 0, rd 22094848, flush 0, corrupt 0, gen 0

Also it is worth mentioning that after corruption one of the subvolumes was mounted read-write and possibly some files were written.

Is there any chance to recover the FS?



-- 
Best regards,
Vladimir

Re: Recovery options for damaged beginning of the filesystem

[Qu Wenruo]

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



On 2018/10/10 下午12:47, Shapranov Vladimir wrote:
> Hi,
> 
> I've got a filesystem with first ~50Mb accidentally dd'ed.

So about 49M meta/data loss.

It depends on the chunk layout. If it got one metadata chunk wiped out,
it's pretty hard to repair.
If it only wiped several data chunks, it should be mostly OK.


> 
> "btrfs check" fails with a following error (regardless of "-s"):
> checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
> checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
> checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
> checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
> bytenr mismatch, want=21037056, have=13515002166904211737
> ERROR: cannot read chunk root
> ERROR: cannot open file system
> 
> "mount -o ro /dev/sdf1 /mnt/tmp" fails, while "mount -o ro,subvol=X /mnt/tmp" succeeds for "/" and couple subvolumes.

That's very strange.

If chunk root is corrupted, it should fail for all subvolumes.

> 
> I can even ls the root directory, but at some point something can't be read anymore and following errors appear in dmesg:
> [385647.999981] btrfs_dev_stat_print_on_error: 158686 callbacks suppressed
> [385648.079187] BTRFS error (device sdd1): bdev /dev/sdf1 errs: wr 0, rd 22094847, flush 0, corrupt 0, gen 0
> [385648.193733] BTRFS error (device sdd1): bdev /dev/sdf1 errs: wr 0, rd 22094848, flush 0, corrupt 0, gen 0
> 
> Also it is worth mentioning that after corruption one of the subvolumes was mounted read-write and possibly some files were written.
> 
> Is there any chance to recover the FS?

You could try btrfs rescue chunk-recovery to recover the chunk root, and
then all depends on your luck to see if it works.

Thanks,
Qu

> 
> 
> 


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

Re: Recovery options for damaged beginning of the filesystem

[Chris Murphy]

On Tue, Oct 9, 2018 at 10:47 PM, Shapranov Vladimir
<equidamoid@gmail.com> wrote:
> Hi,
>
> I've got a filesystem with first ~50Mb accidentally dd'ed.
>
> "btrfs check" fails with a following error (regardless of "-s"):
> checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
> checksum verify failed on 21037056 found FC8A6557 wanted 2F51D090
> checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
> checksum verify failed on 21037056 found 1EDD5E47 wanted 222F7E7F
> bytenr mismatch, want=21037056, have=13515002166904211737
> ERROR: cannot read chunk root
> ERROR: cannot open file system
>
> "mount -o ro /dev/sdf1 /mnt/tmp" fails, while "mount -o ro,subvol=X /mnt/tmp" succeeds for "/" and couple subvolumes.

What do you get for 'btrfs rescue super -v /dev/sdf1' ?

I thought the kernel code will not mount a Btrfs if the first super is
not present or valid (checksum match)?




-- 
Chris Murphy