[arch-general] btrfs kernel incompatibility?

[Chris Murphy]

On Sun, Feb 9, 2020 at 5:12 PM Chris Murphy <lists at colorremedies.com> wrote:
>
> > Disk identifier: 9904ABA2-B9F8-4544-9699-9935CE8A7B1F
> >
> > Device     Start        End    Sectors  Size Type
> > /dev/sdc1   2048 7814035455 7814033408  3,7T Linux filesystem
> >
> > --> (7814035455-2048)*512 = 4000785104384 of available bytes
> >
> > # btrfs inspect-internal dump-super /dev/sdc1 | grep total_bytes
> > total_bytes             8001571065856
> > dev_item.total_bytes    4000785104896
> >
> > --> 4000785104896-4000785104384 = 512 --> safe? So here one could create the backup GPT...
>
> Again, other way around. The partition is smaller than the file
> system, by 512 bytes, 1 sector.

Actually I've made a very common mistake. LBA 2048 should be
*included* in the total byte count. So it's really

(7814035455-2048+1)*512=4000785104896

which is identical to dev_item.total_bytes. Therefore *both* of these
devices are completely safe and fine, and should not give either ARM
or x86_64 grief. And you don't have to make the two mirrors
identically sized. Btrfs doesn't care if they're identical.

You might just go straight to ARM, and try to mount -o ro and see if
it mounts it OK. I think the error messages you got from Btrfs
previously had to do with the bogus GPT error messages - which we
don't know why that happened.


Anyway, the below is still valid and safe, but entirely optional. For
what it's worth, fdisk will ask if it should wipe the Btrfs signature,
don't do that. Writing out a new GPT writes to the first 34 and last
34 sectors of the drive, and this Btrfs file system is nowhere near
those areas.

>
> Simplest and safest fix?
> 0. Boilerplate disclosure, mount -o ro, and freshen backups. Just in case.
> 1. Unmount
> 2. fdisk or gdisk /dev/sdc1, 9904ABA2...
> delete partition 1 and recreate it with default values, this will change it from
>
>  /dev/sdc1   2048 7814035455 7814033408  3,7T Linux filesystem
>
> to
>
>  /dev/sdc1   2048 7814037134 7814035087  3,7T Linux filesystem
>
> Which matches /dev/sdb1 and will be bigger than it is now. Double
> check the values and write it out. Since the device isn't used the
> kernel should be updated automatically, you can check dmesg before and
> after, or just use partprobe if available.
>
> 3. mount the volume normally (this time rw)
> 4. resize sdc1 to account for the slightly larger partition and match its mirror
>
> # btrfs fi resize 8:max /mnt
>
> You can use 'btrfs insp dump-s' on both drives to confirm they both have
>
> dev_item.total_bytes    4000785960960
>




-- 
Chris Murphy