Hi Alberto, On 2026/6/19 00:13, Alberto Ruiz via B4 Relay wrote:
This series adds a memory-backed ("memback") mode to EROFS that allows mounting an EROFS image directly from a kernel memory region without going through the block layer.I am sending this as an RFC to get EROFS maintainer feedback on this approach before building the full initramfs series on top of it. The memback mode may also be useful for other use cases beyond
First, thanks for your interest and efforts. On my side I'm glad if EROFS can be used for the initramfs use case (for many years!).
initramfs where EROFS images need to be served directly from memory, though it may need further hardening for more general use cases. Previous review feedback on the initramfs patches raised concerns about the block layer dependency — this series addresses that by
Could you have a pointer where "concerns about the block layer dependency" comes from? I don't notice that on the mailing list.
providing a direct memory-backed path. It also adds support for
But I think EROFS subsystem can not decide itself if we could land this functionality or not, in any case we should have a discussion with VFS/MM folks first to know if the rough direction is acceptable or not. And we also need to know what's the concerns before we draft a version. There may have some barriers on my side to land this feature: - erofs_memback_set_pending() can be used to set an arbitary kernel virt address. I don't think it's a good direction to be honest, for example, previously cramfs gets some arbitary address using mtd_point() and implement XIP feature but I think it's quite outdated. Yes, I've seen erofs_memback_set_pending() can only be used for specific cases since it has __init annotation, but it also limits _the other potential use cases_. - currently modern memory backends (memory devices like PMEM and CXL) all use Linux DAX infrastructure, which means we shouldn't bypass the DAX infrastructure to operate arbitary memory address directly. That is my own opinion at least, but if MM/FS folks think EROFS can work on arbitary kernel virt address instead, I'm fine, but I think it's highly impossible. So at least on this part, I wonder if we should enhance ramdax (drivers/nvdimm/ramdax.c) to support initramfs use cases and make EROFS to use ramdax + DAX infrastrure to mount initramfs instead.
non-page-aligned memory ranges, which is the common case for initramfs images packed at arbitrary cpio boundaries. Supporting
That is another issue I would like to discuss: If EROFS filesystem data is page aligned, we can just use the initramfs memory directly and so that no page cache is needed. And in that cases, no double cache anymore (see "ramfs and ramdisk" section in https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt).
non-page-aligned ranges is essential for true zero-copy access —
I guess that is not true: I've looked the code, basically the code uses the page cache (double caching), and the unaligned data will be copied into page cache (aligned data) first. Since mmap use cases need page aligned buffers, and in practice of the linux kernel, it will be page cache or DAX. So in order to do that, unaligned initramfs needs do double caching and an extra copy at least to fulfill the requirement.
requiring page alignment would force a copy into an aligned buffer before the data can be used, defeating the purpose.
same as above. Anyway, I wonder if we could avoid non-page-aligned initramfs so that ramdax can be enhanced to be used directly.
The full initramfs integration (init/ changes) that wires up the EROFS initrd detection and layered mount is available for reference here[0]. It implements support for interleaved cpio and EROFS layers, it supports cpio CPU microcode update prefix, and uses overlayfs+tmpfs for write support.
If that's why EROFS is unaligned, and we just add some padding between cpio and erofs image (I think the padding is small than 4k)? or can cpio CPU microcode update prefix placed after the erofs image?
This series was developed with the assistance of Claude Opus 4.6. All patches carry an Assisted-by tag. I am providing the kunit testing and I have tested this change against the initramfs series to boot an EROFS initramfs. I welcome feedback on the approach and implementation.
Yes, the generated code can work but IMHO it doesn't mean it's well suitable for upstream... It's just my own humble opinion, but I expect VFS/MM folks could have similar thoughts. However, I'm also interested if EROFS can be used for initramfs, as long as we have a proper way to implement that. Thanks, Gao Xiang
Patch 1 adds the core memback implementation. Patch 2 adds a KUnit test that mounts a compressed EROFS image at a non-page-aligned offset and verifies decompressed file contents. [0] https://github.com/aruiz/linux/tree/wip/erofs-initramfs-memback Signed-off-by: Alberto Ruiz <[email protected]> --- Alberto Ruiz (2): erofs: add memory-backed mode for non-page-aligned mount erofs: add KUnit test for memory-backed compressed mount fs/erofs/Kconfig | 11 ++++ fs/erofs/Makefile | 2 + fs/erofs/data.c | 33 +++++++++- fs/erofs/internal.h | 53 +++++++++++---- fs/erofs/memback.c | 169 ++++++++++++++++++++++++++++++++++++++++++++++++ fs/erofs/memback_test.c | 151 ++++++++++++++++++++++++++++++++++++++++++ fs/erofs/super.c | 38 +++++++++-- fs/erofs/zdata.c | 16 +++-- 8 files changed, 447 insertions(+), 26 deletions(-) --- base-commit: 6b5a2b7d9bc156e505f09e698d85d6a1547c1206 change-id: 20260617-erofs-memback-0ae2448ba2cc Best regards, -- Alberto Ruiz <[email protected]>
