On Sun, Feb 9, 2020 at 8:15 AM Simeon Felis <arch-general@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