On Wed, Sep 16, 2020 at 09:31:50AM -0500, Eric Sandeen wrote:
On 9/15/20 7:29 PM, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
>> Daniel Pocock wrote:
>>> One issue I've come across is that a btrfs filesystem can only be used
>>> on hosts with the same page size as the host that created the filesystem
>> Ewww! That alone should disqualify btrfs as a default file system!
>> Why does a file system depend on the kernel page size? The kernel page size
>> is an internal implementation detail of the kernel, whereas a file system
>> ought to be a stable interchange format that is compatible across all
>> It is unfortunate that this showstopper was not mentioned when the switch to
>> btrfs by default was proposed.
I'm not sure that it would have been deemed any more important than other
concerns which were raised at the time, TBH.
> I hate to break it to you, but this problem is not just in
> filesystems, it's in basically everything in the kernel. And we've had
> variations of problems like this for years (endianness, page size,
> pointer size, single bit vs multi-bit booleans, etc.). I've personally
> been bitten by all of these issues in some way. This comes from the
> fact that there's no such thing as "internal implementation detail of
> the kernel" by design. This is the "joy" of the monorepo
> where everything leaks into everything else.
That's simply not accurate. Handling 32/64 bit interfaces, endianness, etc
are long-solved problems. Longstanding lack of design or support for
sub-page block support in a filesystem is not /at all/ the same thing.
Are there occasional endianness bugs, pointer size bugs, etc? Sure.
But that's different from "We did not design this."
> This didn't become a serious problem until Red Hat made the
> unfortunate (though not realized at the time) mistake of switching to
> 64k pages for ARM and POWER. We got that change in Fedora for POWER
> but not ARM. It has led to all kinds of unfortunate problems that are
> gradually being worked on and fixed upstream.
Sub-page block support in filesystems is not a wild, esoteric, unexpected
These kinds of problems are not really that rare across different
Try creating a XFS fs on a system with 64k PAGE_SIZE and a blocksize of
64k, then try mounting that fs on a x86_64 machine. It won't work:
And IIRC xfs is the default for RHEL, no?
Best Regards, Benjamin Block / Linux on IBM Z Kernel Development / IBM Systems
IBM Deutschland Research & Development GmbH / https://www.ibm.com/privacy
Vorsitz. AufsR.: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294