mkfs.erofs: should MAX_BLOCK_SIZE be tied to build host page size?

[Matthew Lear]

Hi,
I'm writing to ask if there is scope to change how mkfs.erofs handles
its max block size ceiling.

MAX_BLOCK_SIZE currently defaults to the page size of the system where
erofs-utils is built, not where it executes. This means a that compiled
mkfs.erofs built on a 4K page host permanently inherits the build
host's 4K block size limit, even when running on a system with a 16K
page kernel (e.g. like our 2712 Raspberry Pi5 kernel):

$ getconf PAGE_SIZE
16384
$ mkfs.erofs -b 16384 test.img /lib
<E> erofs: invalid block size 16384

Passing MAX_BLOCK_SIZE=16384 at erofs-utils configure time results in a
binary that successfully creates 16K block images, regardless of the
page size of the host it's executing on. The restriction seems to be a
build-time constant rather than something which has runtime
justification.

Also, since modern kernels now support large block sizes (LBS) where
block size > page size, this seems to add weight to removal of the
inherited host page size cap.

Without this, users on 16K page kernels are forced into the experimental
sub-page compressed block path:

erofs: (device mmcblk0p4): EXPERIMENTAL EROFS subpage compressed block
support in use. Use at your own risk!

If I build erofs-utils on a 4K host and use its mkfs for a 16K target,
the binary rejects -b 16384. I need to configure with
MAX_BLOCK_SIZE=16384 in order to use -b 16384 otherwise I'm forced to
produce 4K-block images that trigger the experimental sub-page warning
on the target device. This isn't a problem, but it does feel like the
utility should decouple its validation logic from the host's
page size.

The baked-in behaviour also affects official distribution packages,
which may typically be built on 4K page size build farms. So this is
possibly a wider issue for the 16K page size ecosystem.

Is there scope to increase the default block size ceiling of mkfs.erofs
to 16K (or perhaps increase it to 16K for aarch64 compilations)?

Cheers,
-- Matt