On Thu, Feb 6, 2020 at 2:01 PM Simeon Felis <arch-general@sfelis.de> wrote:
[ 21.417002] Btrfs loaded, crc32c=crc32c-generic [ 21.418650] BTRFS: device label URAID devid 8 transid 1254272 /dev/sdb1 [ 21.423593] BTRFS: device label URAID devid 7 transid 1254272 /dev/sda1 [ 313.823521] BTRFS info (device sda1): disk space caching is enabled [ 313.823537] BTRFS info (device sda1): has skinny extents [ 313.826597] BTRFS critical (device sda1): unable to find logical 3746684731392 length 4096
For what it's worth, Btrfs uses logical addresses internally. These are in bytes. They do not correlate to a physical location. So while 3746684731392 translates to ~3.4TiB and might suggest that this is a location near the end of the drive, it's not necessarily true - but would be consistent with something stepping on the end of the drive, wiping out both the alternate GPT and the chunk tree.
From the super you provided: compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x161 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA )
These are supported since forever, going back to 3.x kernels. Can you confirm the architecture of the workstation you did the scrub and balance on? I'm guessing it's x86_64. The problem isn't with the superblock. It's with boot strapping the chunk tree. It's not clear why. The chunk tree is what's responsible for translating a logical address into a device + sector lookup; for raid1 that's two devices and two different physical sectors. If the chunk tree cannot be read, it's not possible to find anything, including other metadata. It should be true that the partition this Btrfs is on, is exactly the same number of bytes as dev_item.total_bytes. I think there's a bug somewhere, you've got two devices experiencing the exact same complaint and problem. The GPT thing might be a distraction, I'm not really sure yet. What do you get for: btrfs insp dump-s -fa /dev/ btrfs insp dump-t -t chunk /dev These are all read only commands. -- Chris Murphy