[arch-general] btrfs kernel incompatibility?
lists at colorremedies.com
Thu Feb 6 22:28:18 UTC 2020
On Thu, Feb 6, 2020 at 2:01 PM Simeon Felis <arch-general at 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:
( MIXED_BACKREF |
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.
More information about the arch-general