[arch-general] btrfs kernel incompatibility?

[Chris Murphy]

There's not enough information to know what's going on yet. My strong
advice is to make no further changes (no writes) to either block
device until you understand exactly what's going on. Every write
increases the chance of permanently losing the file system.


On Thu, Feb 6, 2020 at 2:01 PM Simeon Felis <arch-general at sfelis.de> wrote:
>
> 4.19.75 dmesg:
>
> [   17.707873] GPT:Primary header thinks Alt. header is not at the end of the di
> sk.
> [   17.707889] GPT:7814037167 != 253879390758629
> [   17.707895] GPT:Alternate GPT header not at the end of the disk.
> [   17.707902] GPT:7814037167 != 253879390758629
> [   17.707907] GPT: Use GNU Parted to correct GPT errors.
> [   17.707977]  sdb: sdb1
> [   17.709682] GPT:Primary header thinks Alt. header is not at the end of the disk.
> [   17.709697] GPT:7814037167 != 253879390758629
> [   17.709703] GPT:Alternate GPT header not at the end of the disk.
> [   17.709710] GPT:7814037167 != 253879390758629

This is terrible error reporting (by the kernel) in that it's not
clearly stating whether the primary GPT is reporting 7814037167 or
253879390758629. No shit, they aren't the same. Usually this error
means the backup GPT at the end of the drive has been stepped on by
something; but LBA 253879390758629 is plainly bogus, that's ~115PiB.

What do you get for either 'fdisk -l' or 'gdisk -l' or 'parted
/dev/sda u s p' for each device?

> btrfs inspect-internal dump-super /dev/disk/by-label/URAID
> superblock: bytenr=65536, device=/dev/disk/by-label/URAID
> total_bytes        8001571065856
...
> dev_item.total_bytes    4000785104896

4000785104896 bytes is 7814033408 sectors, which approximates LBA
7814037167. And fortunately the latter number is bigger.

There is a gotcha moving Btrfs between different archs. "Btrfs sector
size", which is an internal Btrfs thing, not a reference to either
logical or physical sector size of the device, must be the same as
page size. Page size is 4KiB on x86 and I'm pretty sure it's 16KiB on
ARM.

So I wonder if you've run into an arch mixing problem (or bug).


-- 
Chris Murphy