please enable EROFS
Describe the bug
https://docs.kernel.org/filesystems/erofs.html
the EROFS file system does not seem to be enabled here
Steps to reproduce the behaviour
n/a
Device (s)
Raspberry Pi 5
System
n/a
Logs
No response
Additional context
No response
I sent PR a long time ago: https://github.com/raspberrypi/linux/pull/6163
I can rebase to 6.12 if the maintainer here agree with enabling this.
@pelwell, would you consider allowing the EROFS module into your kernel?
I can't think of a good reason not to - the modules aren't enormous. See https://github.com/raspberrypi/linux/pull/6806.
@popcornmix Testing on kernel version 6.12.43, I can confirm this works! Thank you.
Would it be too much to ask for this to be built with EROFS_FS_ZIP_ZSTD and EROFS_FS_ZIP_ACCEL too please if you think it's appropriate for the rpi hardware.
Also CONFIG_FS_DAX would be very beneficial for this filesystem too.
https://docs.kernel.org/filesystems/dax.html
EROFS_FS_ZIP_ZSTD makes sense, since we have ZSTD support already in the kernel - I'll add it. See #7028.
EROFS_FS_ZIP_ACCEL enables hardware accelerated decompression - is that supported by our processors?
For CONFIG_FS_DAX, the description page you linked to says:
The DAX code does not work correctly on architectures which have virtually mapped caches such as ARM, MIPS and SPARC.
The caches on the Cortex A53, A73 and A76 are Virtually Indexed Physically Tagged (VIPT). That probably qualifies as "virtually mapped", so I'm not going to be enabling that feature.
Thank you for EROFS_FS_ZIP_ZSTD.
I kinda hoped you folks would know if EROFS_FS_ZIP_ACCEL makes sense on any of the Pi hardware or not. It would be really neat if we managed to get some hardware accelerated decompression going!
That's a real shame about CONFIG_FS_DAX. I might do some experimentation myself to verify that this indeed is impossible.
actually, EROFS_FS_ZIP_ACCEL might only be for Intel CPUs: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b4a29efc51461edf1a02e9da656d4480cabd24b0
I'm closing the issue because the main request has been addressed.