public inbox for initramfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <lennart@poettering.net>
To: Nils Kattenbeck <nilskemail@gmail.com>
Cc: Eric Curtin <ecurtin@redhat.com>,
	initramfs@vger.kernel.org, systemd-devel@lists.freedesktop.org,
	Stephen Smoogen <ssmoogen@redhat.com>,
	Qubes OS Development Mailing List <qubes-devel@googlegroups.com>,
	Yariv Rachmani <yrachman@redhat.com>,
	Douglas Landgraf <dlandgra@redhat.com>
Subject: Re: [RFC] initoverlayfs - a scalable initial filesystem
Date: Tue, 12 Dec 2023 22:02:34 +0100	[thread overview]
Message-ID: <ZXjKagDbAWpkKgOz@gardel-login> (raw)
In-Reply-To: <CAKkJDRd8=r+BDacQXO0SaYVKogwBTq6fz_U169GZT25+b0SmJA@mail.gmail.com>

On Di, 12.12.23 21:34, Nils Kattenbeck (nilskemail@gmail.com) wrote:

> Hi, while I have been following this thread passively for now I also
> wanted to chime in.
>
> > (The main reason why sd-stub doesn't actually support erofs-initrds,
> > is that sd-stub also generates initrd cpios on the fly, to pass
> > credentials and system extension images to the kernel, and you can't
> > really mix erofs and cpio initrds into one)
>
> What prevents one from mixing the two (especially given that the
> hypothetical erofs initrd support does not yet exist)?
> Or are you talking about mixing this with your memmap+root=/dev/pmem
> suggestion?

If you have 7 cpio initrds then the kernel will allocate a tmpfs and
unpack them all into it, one after the other, on top of each other,
and then jumps into the result.

if you have an erofs and 7 cpio initds, what are you going to do? You
cannot extract into an erofs, it's immutable. You'd need something
like overlayfs, but that would require (at least for now) an
additional step in userspace, which is something to avoid.

Alternatively (and preferred by me) would support a mode where it
would unpack any cpios it gets into a tmpfs, and then pass an fsopen()
fd to that to the executable it then invokes from the erofs. the
executable could then mount that somewhere if it wants. But this would
require a kenrel patch.

> Even if everything is the same there are codes paths which might not
> be taken during usual operation. An example would be services similar
> to the new systemd-bsod which are only triggered in emergencies.
> Having these in the cpio means that they will always be read and
> decompressed.

systemd-bsod is tiny though, less than 8K compressed here. Not sure it
is a good example.

> Using sysexts also has the drawback that each and every one of them
> has to be decompressed. I might be mistaken but I expect that this
> will be the case even if the extension-release in the sysext results
> in it being discarded which is obviously another big drawback.

sysexts are erofs or squashfs file systems with verity backing. Only
the sectors you access are decompressed.

Lennart

--
Lennart Poettering, Berlin

  parent reply	other threads:[~2023-12-12 21:02 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 17:59 [RFC] initoverlayfs - a scalable initial filesystem Eric Curtin
2023-12-09 12:46 ` Luca Boccassi
2023-12-09 14:42   ` Eric Curtin
2023-12-09 14:56     ` Andrei Borzenkov
2023-12-09 15:07       ` Eric Curtin
2023-12-09 15:22         ` Daan De Meyer
2023-12-09 15:46           ` Eric Curtin
2023-12-09 17:19         ` Luca Boccassi
2023-12-09 17:24           ` Eric Curtin
2023-12-09 17:46             ` Luca Boccassi
2023-12-09 17:57               ` Eric Curtin
2023-12-09 18:11                 ` Luca Boccassi
2023-12-09 18:26                   ` Eric Curtin
2023-12-11  9:57 ` Lennart Poettering
2023-12-11 10:07   ` Lennart Poettering
2023-12-11 11:20   ` Eric Curtin
2023-12-11 11:28     ` Eric Curtin
2023-12-11 11:42       ` Eric Curtin
2023-12-11 11:58         ` Lennart Poettering
2023-12-11 11:51       ` Lennart Poettering
2023-12-11 12:48         ` Eric Curtin
2023-12-11 12:52           ` Eric Curtin
2023-12-12 17:37           ` Lennart Poettering
2023-12-12 17:40           ` Lennart Poettering
2023-12-12 19:05             ` Demi Marie Obenour
2023-12-11 16:28   ` Demi Marie Obenour
2023-12-11 17:03     ` Eric Curtin
2023-12-11 17:46       ` Demi Marie Obenour
2023-12-12 18:00       ` Lennart Poettering
2023-12-12 20:34         ` Nils Kattenbeck
2023-12-12 20:48           ` Eric Curtin
2023-12-12 21:02           ` Lennart Poettering [this message]
2023-12-12 22:01             ` Nils Kattenbeck
2023-12-13  9:03               ` Lennart Poettering
2023-12-14  1:17                 ` Nils Kattenbeck
2023-12-16 14:34                   ` Lennart Poettering
2023-12-11 17:33     ` Neal Gompa
2023-12-11 20:15     ` Luca Boccassi
2023-12-11 20:43       ` Demi Marie Obenour
2023-12-11 20:58         ` Luca Boccassi
2023-12-11 21:20           ` Demi Marie Obenour
2023-12-11 21:45             ` Luca Boccassi
2023-12-12  3:47               ` Paul Menzel
2023-12-12  3:56               ` Paul Menzel
2023-12-12 15:26               ` Paul Menzel
2023-12-11 21:24           ` Eric Curtin
2023-12-12 17:50     ` Lennart Poettering
  -- strict thread matches above, loose matches on Subject: below --
2023-12-18 21:59 Askar Safin
     [not found] ` <CAOgh=FyA94-7YqGpsAqVQjadegRusoAvRhD=t-ipzVWN0CiJRQ@mail.gmail.com>
2023-12-18 23:31   ` Askar Safin

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=ZXjKagDbAWpkKgOz@gardel-login \
    --to=lennart@poettering.net \
    --cc=dlandgra@redhat.com \
    --cc=ecurtin@redhat.com \
    --cc=initramfs@vger.kernel.org \
    --cc=nilskemail@gmail.com \
    --cc=qubes-devel@googlegroups.com \
    --cc=ssmoogen@redhat.com \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=yrachman@redhat.com \
    /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