linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Henk Slager <eye1tm@gmail.com>
Cc: Simeon Felis <simeon_btrfs@sfelis.de>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: kernel incompatibility?
Date: Tue, 18 Feb 2020 07:15:30 -0700	[thread overview]
Message-ID: <CAJCQCtQjRMctPYtPM-v2=ZGBMJ5T88eyVcvdgR9SfpTVWBgSOQ@mail.gmail.com> (raw)
In-Reply-To: <CAPmG0ja40xPPcXxM+uv_v339v+8Jc5TLP_kONbkw1vWHFUer-Q@mail.gmail.com>

On Tue, Feb 18, 2020 at 4:54 AM Henk Slager <eye1tm@gmail.com> wrote:
>
> On Sun, Feb 16, 2020 at 10:29 AM Simeon Felis <simeon_btrfs@sfelis.de> 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

  reply	other threads:[~2020-02-18 14:15 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 [this message]
2020-02-18 17:20     ` Henk Slager
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='CAJCQCtQjRMctPYtPM-v2=ZGBMJ5T88eyVcvdgR9SfpTVWBgSOQ@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=eye1tm@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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).