On Fri, Sep 18, 2020 at 8:19 AM Daniel Pocock <daniel(a)pocock.pro> 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
>>> 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
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
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!