Re: btrfs and default page sizes (4k vs 64k)
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.
Regards,
Daniel