Re: btrfs suddenly think's it's raid6

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

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



On 2018年06月29日 19:04, marble wrote:
> Hello,
> I have an external HDD. The HDD contains no partition.
> I use the whole HDD as a LUKS container. Inside that LUKS is a btrfs.
> It's used to store some media files.
> The HDD was hooked up to a Raspberry Pi running up-to-date Arch Linux
> to play music from the drive.
> 
> After disconnecting the drive from the Pi and connecting it to my laptop
> again, I couldn't mount it anymore. If I read the dmesg right, it now
> thinks that it's part of a raid6.

Don't panic, the raid6 module is always loaded by btrfs, no matter if
btrfs uses or not.

> 
> btrfs check --repair also didn't help.

Normally you shouldn't try it anyway.

> 
> ```
> marble@archlinux ~ % uname -a
> Linux archlinux 4.17.2-1-ARCH #1 SMP PREEMPT Sat Jun 16 11:08:59 UTC
> 2018 x86_64 GNU/Linux
> 
> marble@archlinux ~ % btrfs --version
> btrfs-progs v4.16.1
> 
> marble@archlinux ~ % sudo cryptsetup open /dev/sda black
> [sudo] password for marble:
> Enter passphrase for /dev/sda:
> 
> marble@archlinux ~ % mkdir /tmp/black
> marble@archlinux ~ % sudo mount /dev/mapper/black /tmp/black
> mount: /tmp/black: can't read superblock on /dev/mapper/black.
> 
> marble@archlinux ~ % sudo btrfs fi show
> Label: 'black'  uuid: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5
>         Total devices 1 FS bytes used 143.38GiB
>         devid    1 size 465.76GiB used 172.02GiB path /dev/mapper/black
> 
> marble@archlinux ~ % sudo btrfs check --repair /dev/mapper/black
> enabling repair mode
> Checking filesystem on /dev/mapper/black
> UUID: 9fea91c7-7b0b-4ef9-a83b-e24ccf2586b5
> Fixed 0 roots.
> checking extents
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3

This means, both copies for logical bytenr 1082114048 are corrupted.

> bytenr mismatch, want=1082114048, have=9385453728028469028
> owner ref check failed [1082114048 16384]
> repair deleting extent record: key [1082114048,168,16384]

You shouldn't really use --repair here.
Your extent tree is corrupted, --repair could make things worse here.

> adding new tree backref on start 1082114048 len 16384 parent 0 root 5
> Repaired extent references for 1082114048
> ref mismatch on [59038556160 4096] extent item 1, found 0
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> bytenr mismatch, want=1082114048, have=9385453728028469028
> incorrect local backref count on 59038556160 root 5 owner 334393 offset
> 0 found 0 wanted 1 back 0x56348aee5de0
> backref disk bytenr does not match extent record, bytenr=59038556160,
> ref bytenr=0
> backpointer mismatch on [59038556160 4096]
> owner ref check failed [59038556160 4096]
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> checksum verify failed on 1082114048 found 1A9EFC07 wanted 204A6979
> checksum verify failed on 1082114048 found D7CA51C8 wanted E6334CB3
> bytenr mismatch, want=1082114048, have=9385453728028469028
> failed to repair damaged filesystem, aborting
> 
> marble@archlinux ~ % dmesg > /tmp/dmesg.log

This is the root cause:
[  124.544439] BTRFS error (device dm-1): bad tree block start
9385453728028469028 1082114048
[  124.555229] BTRFS error (device dm-1): bad tree block start
2365503423870651471 1082114048
[  124.555275] BTRFS warning (device dm-1): failed to read fs tree: -5

Your fs tree is corrupted.
I'm not sure how it's corrupted, but corruption to fs tree is a little rare.

Is there anything like unexpected power loss happens?
And would you provide the following data for debugging?

# btrfs ins dump-super -fFa /dev/mapper/black

And further more, what's the device mapper setup for /dev/mapper/black?
Is there anything like RAID here?

Thanks,
Qu


> ```
> 
> Any clues?
> 
> Best regards,
> marble
> 


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