On Tue, Feb 18, 2020 at 3:15 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > 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. Yes indeed, I see it now. If I create a Btrfs raid1 with same (simulated) disksizes as in this error case, it mounts without problems in raspbian kernel7 4.17.97 on a RPi3B+ > > 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. Indeed shouldn't be a problem, but I was thinking some other tool or something in the blocklayer did something wrong in the past. The fact that sdb1 is using a proposed max/largest sector for end_sector while sdc1 does not, I find remarkable. > > 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. Also this remark refers to outside btrfs scope in principle, Btrfs itself is 4KiB, but there have been changes in implementation in the relation between logical setctors and 4k pages as far as I remember. Although it is long time ago, so I think older than 4.19
