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
machines.
It is unfortunate that this showstopper was not mentioned when the switch to
btrfs by default was proposed.
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
"design"
where everything leaks into everything else.
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.
Coming back to Btrfs specifically, there is work underway upstream to
resolve this issue. My (semi-blind) estimate is that we'll see a fix
in Linux 5.11, but Josef (cc'd to this email) may know more about it.
--
真実はいつも一つ!/ Always, there's only one truth!