Re: [PATCH] initrd: support erofs as initrd

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

On 2025/8/26 23:32, Gao Xiang wrote:
> 
> 
> 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.

refine a bit: for data/metadata direct access, dax_direct_access()
and page cache apis are simple and efficient enough, but if on-disk
(meta)data needs to be transformed ((de)compressed or {en,de}crypted),
a unified bio interface is simplier than working on these individual
storage.

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