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
