[arch-general] btrfs kernel incompatibility?

[Chris Murphy]

On Sun, Feb 9, 2020 at 8:15 AM Simeon Felis <arch-general at sfelis.de> wrote:

> btrfs raid1 disks UUIDs:
> 63E9CA8E-F1B4-8A41-9C21-F058C1AC0783
> 9904ABA2-B9F8-4544-9699-9935CE8A7B1F
> Oh, by the way it's a Seagate and Western Digital. Damn I thought I bought identical ones.

This is better. Chance of simultaneous failures is much reduced with
mixed make/model.

What do you get for?
# btrfs insp dump-t b 3746684731392 /dev/

That's a read-only command, volume doesn't need to be mounted, and
/dev/ is either device. I actually don't need to see the output, but I
want to know if the command complains or provides whatever is at that
location. It could be a node or leaf, it may contain filenames so if
you do post it, you'll want to sanitize them.


> 63E9CA8E-F1B4-8A41-9C21-F058C1AC0783
> ====================================
>
> # LANG=C fdisk -l /dev/sdb
> Disk /dev/sdb: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
> Disk model: USB3.0 DISK03
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> Disk identifier: 63E9CA8E-F1B4-8A41-9C21-F058C1AC0783
>
> Device     Start        End    Sectors  Size Type
> /dev/sdb1   2048 7814037134 7814035087  3,7T Linux filesystem
>
> --> (7814037134-2048)*512 = 4000785964032 of available bytes
>
> # btrfs inspect-internal dump-super /dev/sdb1 | grep total_bytes
> total_bytes             8001571065856
> dev_item.total_bytes    4000785960960
>
> --> 4000785960960-4000785964032 = -3072 --> broken?

Other way around. The partition is larger than the file system, by
exactly 3072 bytes which is spot on correct, because Btrfs sector size
is 4KiB and 7814035087 sectors is exactly 512 bytes short of whole
4KiB. So the last 3072 bytes on this partition aren't used by Btrfs.

This device is Btrfs devid 7. And it is OK.

> 9904ABA2-B9F8-4544-9699-9935CE8A7B1F
> ====================================
>
> LANG=C fdisk -l /dev/sdc
> Disk /dev/sdc: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
> Disk model: USB3.0 DISK04
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> 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.

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


That's it. Unmount and go try it on the Pi.


-- 
Chris Murphy