On Tue, Feb 18, 2020 at 4:54 AM Henk Slager <eye1tm@xxxxxxxxx> wrote: > > On Sun, Feb 16, 2020 at 10:29 AM Simeon Felis <simeon_btrfs@xxxxxxxxx> wrote: > > [1] https://lists.archlinux.org/pipermail/arch-general/2020-February/047463.html > The partition size calculations done in the reference are not correct, > they are 1 512-byte-sized sector too smal (compare: if start_sector=0, > end_sector=9, size is 10). The btrfs device size is smaller than the partition size in both cases. Using an identically sized sparse file (same number of 512 byte sectors), both fdisk and gdisk produce a single partition that fails to end on a 4KiB boundary. But in any case Btrfs doesn't seem to care, it sets the total number of bytes for the partition to the nearest 4KiB. > Then still, there are some other errors somewhere, that might be > triggered by having unequeal sized partitions sdb1 and sdc1\ I'm not sure how it'll matter, since Btrfs allocates a chunk, with same stripe sizes, and any difference between partition sizes is overcome by chunk allocation. Within the allocated chunks, they're the same. Unallocated space isn't used for anything. Quite a lot of people are using Btrfs raid1 with dissimilar sized devices. > You could look at backports w.r.t. 32-bit vs. 64-bit, maybe related to > changes 512 sector sizes and 4k page sizes. I wasn't aware Btrfs ever had an internal sector size less than 4KiB. > And better use gdisk > instead of fdisk I think. And maybe check first 1MiB and last 2MiB of > both disks. Yeah we did that, they're fine. The backup GPT is in the correct location and intact according to both fdisk and gdisk. > There are also Ubuntu 32-bit and 64-bit images available for > RaspberryPi's with kernel 5.3.x, maybe that gives hints where the > root-cause is. Maybe. There is a bug here, even accounting for 32-bit. If either the device or volume become too large to reliably support on 32-bit OS, there needs to be a clear INFO or WARNING, and perhaps even only mount ro. -- Chris Murphy
