All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Linux FS Devel <linux-fsdevel@vger.kernel.org>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: page->index limitation on 32bit system?
Date: Thu, 18 Feb 2021 16:54:46 +0800	[thread overview]
Message-ID: <1783f16d-7a28-80e6-4c32-fdf19b705ed0@gmx.com> (raw)

Hi,

Recently we got a strange bug report that, one 32bit systems like armv6
or non-64bit x86, certain large btrfs can't be mounted.

It turns out that, since page->index is just unsigned long, and on 32bit
systemts, that can just be 32bit.

And when filesystems is utilizing any page offset over 4T, page->index
get truncated, causing various problems.

This is especially a big problem for btrfs, as btrfs uses its internal
address space, which is from 0 to U64_MAX, but still sometimes relies on
page->index, just like most filesystems.

If a metadata is at or beyond 4T boundary (which is not rare, even with
small btrfs, as btrfs can related its chunks to much higher bytenr than
device boundary), then page->index will be truncated and may even
conflicts with existing pages.

I'm wonder if this is a known problem, and if so is there any plan to fix?
If not a known one, does it mean we have to make page->index u64 to fix
it? (this is definitely not going to be easy)

Thanks,
Qu

             reply	other threads:[~2021-02-18  9:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  8:54 Qu Wenruo [this message]
2021-02-18 12:15 ` page->index limitation on 32bit system? Matthew Wilcox
2021-02-18 12:42   ` Qu Wenruo
2021-02-18 13:39     ` Matthew Wilcox
2021-02-19  0:37       ` Qu Wenruo
2021-02-19 16:12         ` Theodore Ts'o
2021-02-19 23:10           ` Qu Wenruo
2021-02-20  0:23             ` Matthew Wilcox
2021-02-22  0:19             ` Dave Chinner
2021-02-20  2:20           ` Erik Jensen
2021-02-20  3:40             ` Matthew Wilcox
2021-02-20 23:02       ` Erik Jensen
2021-02-20 23:22         ` Matthew Wilcox
2021-02-21  0:01           ` Erik Jensen
2021-02-21 17:15             ` Matthew Wilcox
2021-02-18 21:27   ` Erik Jensen
2021-02-19 14:22     ` Matthew Wilcox
2021-02-19 17:51       ` Matthew Wilcox
2021-02-19 23:13         ` Qu Wenruo
2021-02-22  1:48       ` Dave Chinner
2021-03-01  1:49         ` GWB

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=1783f16d-7a28-80e6-4c32-fdf19b705ed0@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.