From: Henk Slager <eye1tm@gmail.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Simeon Felis <simeon_btrfs@sfelis.de>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: kernel incompatibility?
Date: Tue, 18 Feb 2020 18:20:31 +0100 [thread overview]
Message-ID: <CAPmG0jYW+OFUSzYiRAQDLD_GsnBYpriABA7cT6U-=O96N15=_w@mail.gmail.com> (raw)
In-Reply-To: <CAJCQCtQjRMctPYtPM-v2=ZGBMJ5T88eyVcvdgR9SfpTVWBgSOQ@mail.gmail.com>
On Tue, Feb 18, 2020 at 3:15 PM Chris Murphy <lists@colorremedies.com> 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
next prev parent reply other threads:[~2020-02-18 17:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-16 9:02 kernel incompatibility? Simeon Felis
2020-02-17 22:55 ` Chris Murphy
2020-02-18 2:14 ` Adam Borowski
2020-02-18 11:54 ` Henk Slager
2020-02-18 14:15 ` Chris Murphy
2020-02-18 17:20 ` Henk Slager [this message]
2020-02-18 17:22 ` Henk Slager
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPmG0jYW+OFUSzYiRAQDLD_GsnBYpriABA7cT6U-=O96N15=_w@mail.gmail.com' \
--to=eye1tm@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=simeon_btrfs@sfelis.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).