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@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