Re: [PATCH RFC 0/2] RFC: erofs: memory-backed mount for non-page-aligned ranges

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]>
>