On 2018-06-29 07: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.
btrfs check --repair also didn't help.
```
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
bytenr mismatch, want=1082114048, have=9385453728028469028
owner ref check failed [1082114048 16384]
repair deleting extent record: key [1082114048,168,16384]
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
```
Any clues?
It's not thinking it's a raid6 array. All the messages before this one:
Btrfs loaded, crc32c=crc32c-intel
Are completely unrelated to BTRFS (because anything before that message
happened before any BTRFS code ran). The raid6 messages are actually
from the startup code for the kernel's generic parity RAID implementation.
These:
BTRFS error (device dm-1): bad tree block start 9385453728028469028
1082114048
BTRFS error (device dm-1): bad tree block start 2365503423870651471
1082114048
Are the relevant error messages. Unfortunately, I don't really know
what's wrong in this case though. Hopefully one of the developers will
have some further insight.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
