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 >
signature.asc
Description: OpenPGP digital signature
