On 2021/2/18 下午8:15, Matthew Wilcox wrote:
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)
Oh, offset by 2...
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).
What would happen if a user just tries to write 4K at file offset 16T
fir a sparse file?
Would it be blocked by other checks before reaching the underlying fs?
As usual, the best solution is for people to stop buying 32-bit systems.
They don't need a large single partition to even trigger it.
This is especially true for btrfs, which has its internal address space
(and it can be any aligned U64 value).
Even 1T btrfs can have its metadata at its internal bytenr way larger
than 1T. (although those ranges still needs to be mapped inside the device).
And considering the reporter is already using 32bit with 10T+ storage, I
doubt if it's really not worthy.
BTW, what would be the extra cost by converting page::index to u64?
I know tons of printk() would cause warning, but most 64bit systems
should not be affected anyway.
Thanks,
Qu
