Re: [PATCH] initrd: support erofs as initrd

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2025/8/26 22:21, Byron Stanoszek wrote:
> On Tue, 26 Aug 2025, Christoph Hellwig wrote:
> 
>> On Mon, Aug 25, 2025 at 09:27:13PM +0300, Askar Safin wrote:
>>>> We've been trying to kill off initrd in favor of initramfs for about
>>>> two decades.  I don't think adding new file system support to it is
>>>> helpful.
>>>
>>> I totally agree.
>>>
>>> What prevents us from removing initrd right now?
>>>
>>> The only reason is lack of volunteers?
>>>
>>> If yes, then may I remove initrd?
>>
>> Give it a spin and see if anyone shouts.
> 
> Well, this makes me a little sad. I run several hundred embedded systems out in
> the world, and I use a combination of initrd and initramfs for booting. These
> systems operate entirely in ramdisk form.
> 
> I concatenate a very large .sqfs file onto the end of "vmlinuz", which gets
> loaded into initrd automatically by the bootloader. Then in my initramfs (cpio
> archive that's compiled in with the kernel), my /sbin/init executable copies
> /initrd.image to /dev/ram0, mounts a tmpfs overlay on top of it, then does a
> pivot root to it.
> 
> This gives it the appearance of a read-write initramfs filesystem, but the
> lower layer data remains compressed in RAM. This saves quite a bit of RAM
> during runtime, which is still yet important on older PCs.
> 
> If there's a better (more official) way of having a real compressed initramfs
> that remains compressed during runtime, I'm all for it. But until then, I would
> like to ask you to please not remove the initrd functionality.
> 
> (In fact, I was actually thinking about trying this method with erofs as the
> lower layer filesystem someday soon instead of squashfs. But I would still be
> using an overlay to mount it, instead of the auto-detect method addressed by
> this patch.)

Something a bit out of the topic, to quota the previous reply from
Christiph:

> There is no reason to fake up a block device, just have a version
> of erofs that directly points to pre-loaded kernel memory instead. 

I completely agree with that point. However, since EROFS is a
block-based filesystem (Thanks to strictly block alignment, meta(data)
can work efficiently on both block-addressed storage
devices and byte-addressed memory devices. Also if the fsblock size
is set as the page size, the page cache itself can also be avoided
for plain inodes), I think even pre-loaded kernel memory is used,
a unified set of block-based kAPIs to access different backends
(e.g., block devices, kernel memory, etc.) is useful for block-based
filesystems instead of developing another dax_direct_access() path
just as pmem-specialized filesystems.

In short, in my opinion, the current bio interfaces fit the
requirements well for various storage for block-based filesystems.

As for EROFS initrd support, I've seen several requests on this,
although I think the interesting point is data integrity and
security since the golden image can be easier protected compared to
tmpfs-based initramfs. It is just my own opinion though, if initrd
survives in the foresee future, I do hope initrd could be an
intermediate solution to initdax support since it just needs a few
line of changes, but if initrd removes soon, just forget what I said.

Thanks,
Gao Xiang

> 
> Thank you,
>   -Byron