On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock <daniel@xxxxxxxxxx> wrote: > > > > On 16/09/2020 21:29, Josef Bacik wrote: > > On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote: > >> On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote: > >>> At the time we tied the fs blocksize to the > >>> page size, because it was unlikely that a user would mkfs a fs on one > >>> arch > >>> and move it over to another arch. > >> > >> But one doesn't need "another arch" for page size to change; many > >> architectures (arm, mips, powerpc, sparc, to name a few) support multiple > >> page sizes. > > > > Sure, but again you are not likely to change page size for an existing > > system. The decision early on was to forgo this particular ability for > > simplicity, and then we would revisit the decision later on. It's been > > a while and there's still not been enough demand to justify the work > > until recently. Thanks, > > > This is messy but important > > Is it possible for Fedora to offer two flavours of the kernel package, > like Debian? There, I created a -4k flavour so it builds two kernel > packages, one with 4k and the other with 64k. They can both be > installed on the same machine and one or the other selected in the grub > menu on each boot. Either can mount an ext4 root but obviously they > can't share the same btrfs root, only the one that created it can mount > that root. > > Once an alternative kernel is available, people need an installer/rescue > ISO including that kernel. This may mean making both permutations > available as different installer ISOs, or including two kernels in the > same ppc64el > > Installer logic: If somebody is using ANY non-4k page size, on any > architecture, it would be useful to display a pop-up window with a > warning about btrfs before they create their root filesystem. This will > save a lot of trouble for people. They might not realize there is a > problem until they've been using the system for a few days and then they > have to reinstall it again. > > Finally, if both page sizes are available, it is desirable to do a build > of every package for every page size. Some packages appear to sense the > page size at compile time and assume it will always be the same at > runtime. This is unfortunate. Maybe reproducible builds techniques can > be used to build each package on two different page sizes, detect if the > binary differs and if so, suggest checking for hard-coded page size. > I think all of this effort required is why we probably *won't* do that. I would be interested in seeing what kind of performance differences there are between 4K page sizes and 64K page sizes, but I don't particularly want to make ppc64le change back to 4K page sizes, simply because there's not much point to it. POWER systems are still largely unavailable to people and that's not going to change anytime soon. As for a warning, I do not have the cycles to do that. As it stands, if I'm going to put my limited contributing energy into something, it'd probably be to help upstream fix the problem with non-4K page sizes in the first place. Since you're interested in this problem, perhaps you could help upstream with testing the patches and writing code to fix this? Especially since it sounds like you have hardware and use-cases to test this with. -- 真実はいつも一つ！/ 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
