Hi! On Mon, 2025-04-07 at 10:57 +0200, hch@xxxxxx wrote: > On Fri, Mar 21, 2025 at 01:17:54PM +0000, Julian Stecklina wrote: > > 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. :) > > Booting from erofs seems perfectly fine to me. Booting from erofs on > an initrd is not. 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. This is a bit more work, but a lot more efficient > in that it removes the block path from the I/O stack, removes the boot > time copy and allows for much more flexible memory management. Can you be more specific in how that would look like in practice? The infrastructure for initrds is universally available and what you are proposing sounds like adding a new mechanism entirely? Julian PS. Sorry for the re-send. I accidentally sent a HTML mail. :(
