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
