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.kof...@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'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. >
These kinds of problems are not really that rare across different Filesystems. 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: https://elixir.bootlin.com/linux/v5.8/source/fs/xfs/xfs_mount.c#L165 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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
