Revisiting default initramfs compression

Paul Sladen ubuntu at paul.sladen.org
Wed Mar 9 10:02:25 UTC 2022


On Wed, 9 Mar 2022, Julian Andres Klode wrote:
> On Wed, Mar 09, 2022 at 02:10:57PM +1300, Michael Hudson-Doyle wrote:
> > On Thu, 9 Dec 2021 at 06:13, Julian Andres Klode <julian.klode at canonical.com>
> > wrote:
> > > changed from lz4 -9 to zstd -19. This caused significant problems:
> > change to initramfs-tools to allow the compression level to be configured
> xypron had a patch to change the default level to 9 ...
> think the summary from the Frankfurt discussion was: ...

I live in Frankfurt, but wasn't there...; otherwise some observations
could have been made:

Choosing the best (size) of hammer, to nail in a screw, is un-useful.

Using four screwdrivers with four small screws seems quick; but only
if four screws are an acceptable engineering solution. [Pigz chops the
stream into independent (128 kB) blocks and round-robins these per
CPU/thread + concats() afterwards].

When the output is made of independent concatentated chunks; each
chunk *may* have its own compression level; ...chosen from reasonable
heuristics [file size + content type (+ available local resources)].

With the same input stream, && the same heuristics, this will always
generate the same (identical) outputs.

Which means the (previous) outputs can be cached and (re-)used, or
...precalculated in the background.

Which means initramfs generation *could* be turned into a ~1 second
"cat *.cpio.gz > initramfs.cpio.gz" operation.


	-Paul









More information about the ubuntu-devel mailing list