On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler
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.
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!
Frankly I'm disappointed that the response is to deflect criticism of btrfs by
claiming that this is an expected issue with the kernel, and then placing the blame on Red
Hat for using a larger page size. To my knowledge page size differences aren't an
issue on ext4 or xfs as they default to using a 4kb block size, so saying that
"it's in basically everything in the kernel" is at best inaccurate and at
worst intentionally misleading.