On 9/15/20 7:29 PM, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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'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 "design"
> 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
feature.
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:
commit 737c9c7da818f1da0bdf3f6a0dda5c38a3cba769
Author: Josh Boyer <jwboyer@xxxxxxxxxx>
Date: Fri Sep 9 11:21:22 2011 -0400
Change to 64K page size for ppc64 kernels (rhbz 736751)
-Eric
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
