On Wed, Sep 16, 2020 at 10:32 AM Eric Sandeen <esandeen(a)redhat.com> 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."
Almost every filesystem was not originally designed for mixing page
sizes, endianness, etc. These issues *have* been fixed over time, for
sure. But it is not worth it for me or anyone else to go into a blame
game. Is it unfortunate that Btrfs didn't have that? Sure. Did I know
this was a problem? No, because I have no access to POWER systems,
like almost everyone else here. And ARM, the other architecture we
have, does not use 64K page sizes in Fedora (though it does in RHEL,
and that is pretty much considered a mistake there, as it didn't take
off, caused interop and performance issues, and added complexity where
it was unneeded).
> 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
It's something that is generally available in nearly every other widely used
Linux filesystem. It's not accurate to suggest that this is some unexpected
side effect of page size choice, or that 64k pages were somehow a "mistake"
now that this btrfs compatibility issue has been made more obvious.
btw, Fedora has shipped kernels with 64k pages for almost a decade:
Author: Josh Boyer <jwboyer(a)redhat.com>
Date: Fri Sep 9 11:21:22 2011 -0400
Change to 64K page size for ppc64 kernels (rhbz 736751)
I am aware that we shipped them for a long time. They are a mistake
for many other reasons unrelated to Btrfs. Regardless, the choice was
made and things have been fixed over time for it. There is already a
patch set being reviewed for the first stage of mixed page support.
真実はいつも一つ！/ Always, there's only one truth!