On Wed, Sep 16, 2020 at 10:32 AM Eric Sandeen <esandeen@xxxxxxxxxx> wrote: > > 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." > 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 > 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) > 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[1] for the first stage of mixed page support. [1]: https://lore.kernel.org/linux-btrfs/12ecf2f9-c262-8b00-2165-486684ba2fef@xxxxxxxx/T/ -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
