All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: page->index limitation on 32bit system?
Date: Thu, 18 Feb 2021 12:15:03 +0000	[thread overview]
Message-ID: <20210218121503.GQ2858050@casper.infradead.org> (raw)
In-Reply-To: <1783f16d-7a28-80e6-4c32-fdf19b705ed0@gmx.com>

On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
> 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.

4TB?  I think you mean 16TB (4kB * 4GB)

Yes, this is a known limitation.  Some vendors have gone to the trouble
of introducing a new page_index_t.  I'm not convinced this is a problem
worth solving.  There are very few 32-bit systems with this much storage
on a single partition (everything should work fine if you take a 20TB
drive and partition it into two 10TB partitions).

As usual, the best solution is for people to stop buying 32-bit systems.

  reply	other threads:[~2021-02-18 15:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  8:54 page->index limitation on 32bit system? Qu Wenruo
2021-02-18 12:15 ` Matthew Wilcox [this message]
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=20210218121503.GQ2858050@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /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.