From: Lennart Poettering <lennart@poettering.net>
To: Eric Curtin <ecurtin@redhat.com>
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>,
Yariv Rachmani <yrachman@redhat.com>,
initramfs@vger.kernel.org, systemd-devel@lists.freedesktop.org,
Stephen Smoogen <ssmoogen@redhat.com>,
Douglas Landgraf <dlandgra@redhat.com>,
Qubes OS Development Mailing List <qubes-devel@googlegroups.com>
Subject: Re: [RFC] initoverlayfs - a scalable initial filesystem
Date: Tue, 12 Dec 2023 19:00:32 +0100 [thread overview]
Message-ID: <ZXifwMan02j9M3n2@gardel-login> (raw)
In-Reply-To: <CAOgh=Fzd-BcBCKzL419iOxbE=+uZWp6oYSV8+VDJ9w8vWG_L-g@mail.gmail.com>
On Mo, 11.12.23 17:03, Eric Curtin (ecurtin@redhat.com) wrote:
> A generic approach is hard, I think it's worth discussing which type of boots
> you should actually care about milliseconds of performance for. It would be nice
> if we had an init system that contained the binary data to do the minimum for
> standard Fedora, Debian installs and everything else was an extension whether
> that's sysexts, dlopen, a new binary to execute etc.
>
> If the network is ingrained in your boot stack like this, I'm
> guessing you probably don't care about boot performance.
Uh, I am not sure that's really true. People boot up VMs on demand,
based on network traffic. They sure care about latency and boot
times. I mean people care about firecracker and these things precisely
because it brings the of off-to-IP to a minimum.
> Automotive has an expectation for really fast boots, like 2 seconds, in standard
> desktops installs there's some expectation as you interface directly
> with a human,
> but for other installs how much expectation is there?
AFAIR in particular in cars there's quite som functionality you
probaly want to move very early in boot. Which yells to me that you
want a service manager super early. Which again suggests to me that
the first initrd that runs should probably already cover that.
If I were you I'd probably focus on a design like this: ship a basic
systemd in an initrd. Complete enough to find the harddisk, and to run
the other services that are absolutely necessary this early. Then,
once you found the disk, look for sysext images on it, and apply them
all on top of the initrd's root fs you are already running with. Never
transition anywhere else.
The try to optimize the initrd a bit by making it an erofs/memmap
thing and so on. And make sure the initrd only contains stuff you
always need, so that reading it all into memory is necessary anyway,
and hence any approach that tries to run even the initrd off a disk
image won't be necessary becuase you need to read everything anyway.
Lennart
--
Lennart Poettering, Berlin
next prev parent reply other threads:[~2023-12-12 18:00 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 [this message]
2023-12-12 20:34 ` Nils Kattenbeck
2023-12-12 20:48 ` Eric Curtin
2023-12-12 21:02 ` Lennart Poettering
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=ZXifwMan02j9M3n2@gardel-login \
--to=lennart@poettering.net \
--cc=demi@invisiblethingslab.com \
--cc=dlandgra@redhat.com \
--cc=ecurtin@redhat.com \
--cc=initramfs@vger.kernel.org \
--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