From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Julian Stecklina <julian.stecklina@cyberus-technology.de>,
"hch@lst.de" <hch@lst.de>
Cc: "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] initrd: support erofs as initrd
Date: Fri, 21 Mar 2025 21:57:59 +0800 [thread overview]
Message-ID: <934af3e3-3153-40c1-9a25-7a8d08fdb007@linux.alibaba.com> (raw)
In-Reply-To: <933797c385f2e222ade076b3e8fc5810fa47f5bd.camel@cyberus-technology.de>
Hi Julian,
On 2025/3/21 21:17, Julian Stecklina wrote:
> On Fri, 2025-03-21 at 13:27 +0800, Gao Xiang wrote:
>> Hi Christoph,
>>
>> On 2025/3/21 13:01, Christoph Hellwig 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.
>>>
>>
>> Disclaimer: I don't know the background of this effort so
>> more background might be helpful.
>
> So erofs came up in an effort to improve the experience for users of NixOS on
> smaller systems. We use erofs a lot and some people in the community just
> consider it a "better" cpio at this point. A great property is that the contents
> stays compressed in memory and there is no need to unpack anything at boot.
> Others like that the rootfs is read-only by default. In short: erofs is a great
> fit.
>
> Of course there are some solutions to using erofs images at boot now:
> https://github.com/containers/initoverlayfs
>
> But this adds yet another step in the already complex boot process and feels
> like a hack. It would be nice to just use erofs images as initrd. The other
> building block to this is automatically sizing /dev/ram0:
>
> https://lkml.org/lkml/2025/3/20/1296
>
> I didn't pack both patches into one series, because I thought enabling erofs
> itself would be less controversial and is already useful on its own. The
> autosizing of /dev/ram is probably more involved than my RFC patch. I'm hoping
> for some input on how to do it right. :)
Ok, my own thought is that cpio format is somewhat inflexible. It
seems that the main original reason for introducing initramfs and
cpio was to avoid double caching, but it can be resolved with FSDAX
now and initdax totally avoids unnecessary cpio parsing and unpacking.
cpio format is much like tar which lacks of basic features like
random access and xattrs which are useful for some use cases as
I mentioned before.
The initrd image can even compressed as a whole and decompress in
the current initramfs way. If you really need on-demand
decompression, you could leave some file compresssed since EROFS
supports per-inode compression, but those files are still double
caching since FSDAX mode should be uncompressed to support mmap.
You could leave rare-used files compressed.
Thanks,
Gao Xiang
next prev parent reply other threads:[~2025-03-21 13:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 19:28 Julian Stecklina via B4 Relay
2025-03-21 2:08 ` Al Viro
2025-03-21 8:46 ` Christian Brauner
2025-03-21 12:49 ` Julian Stecklina
2025-03-21 5:01 ` Christoph Hellwig
2025-03-21 5:27 ` Gao Xiang
2025-03-21 13:17 ` Julian Stecklina
2025-03-21 13:57 ` Gao Xiang [this message]
2025-04-07 8:57 ` hch
2025-04-07 11:19 ` Julian Stecklina
2025-04-07 16:05 ` Gao Xiang
2025-08-25 18:27 ` Askar Safin
2025-08-26 7:59 ` Christoph Hellwig
2025-08-26 14:21 ` Byron Stanoszek
2025-08-26 15:32 ` Gao Xiang
2025-08-26 16:00 ` Gao Xiang
2025-08-27 9:22 ` Askar Safin
2025-08-27 9:48 ` Gao Xiang
2025-08-27 9:58 ` Gao Xiang
2025-08-28 16:44 ` Askar Safin
2025-08-28 17:00 ` Gao Xiang
2025-08-28 17:14 ` Gao Xiang
2025-08-30 11:49 ` Askar Safin
2025-08-30 12:23 ` Gao Xiang
2025-08-26 17:00 ` Askar Safin
2025-03-21 8:48 ` Christian Brauner
2025-03-21 9:16 ` Thomas Weißschuh
2025-03-21 13:26 ` Julian Stecklina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=934af3e3-3153-40c1-9a25-7a8d08fdb007@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=julian.stecklina@cyberus-technology.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®