Ubuntu Rethinking Its Initramfs Compression Strategy

[phoronix]

Phoronix: Ubuntu Rethinking Its Initramfs Compression Strategy

While Ubuntu switched from LZ4 to Zstd for compressing its initramfs, they now are finding they were too aggressive in defaulting to Zstd with the highest compression level of 19. Due to speed and memory consumption concerns, they are looking at lowering their Zstd compression level...

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Initramfs-Zstd-Too-High

[perpetually high]

That's interesting. I've been using the ZSTD + ultra compression mode myself.

# ZSTD compression options
CONFIG_KERNEL_ZSTD_LEVEL=19
CONFIG_KERNEL_ZSTD_LEVEL_ULTRA=y

And seems fine, but in Ubuntu's case, if there's going to be any issues whatsoever with zstd, why not just fallback to LZ4 as the safe, fast default? Not sure why the need to immediately default to ZSTD? Why is it even up for discussion? Just rollback. It's just something behind the covers that the average user is not concerned with, but will be if at any point if it jeopardizes their bootup.

[intelfx]

Phoronix: Ubuntu Rethinking Its Initramfs Compression Strategy

<...> But with that highest compression level they have found the initramfs decompression to be too slow and consumes too much memory. In particular, for low-end devices and embedded hardware like the Raspberry Pi Zero with just 512MB of RAM, it just crashes. <...>

I don't see decompression mentioned anywhere on the mailing list. Instead, what they are talking about is creating initramfs images. Which makes sense, because zstd decompression is always fast and consumes a constant amount of memory regardless of (most) compression settings.

phoronix — this might be a gross factual error in the article.

[perpetually high]

gross factual error in the article.

Hyperbole much? Get a grip.

[alpha_one_x86]

because zstd decompression is always fast and consumes a constant amount of memory regardless of (most) compression settings.

It's exactly what I remember.
And load 100MB+ of firmware on low end config is abused, when low memory detected then repackage initrd with only used firmware.

[skeevy420]

Switch to BTRFS
mount with something like compress-force=zstd:2
and then set everything else to not compress and let the file system handle it for you.

And have it setup so the installer will switch to LZ4 if the user picks a file system that doesn't offer compression.

There ya go.

[bug77]

In other news, one of the Canonical developers found an unformatted C header file and took care of it. Who cares?

[arun54321]

Switch to BTRFS
mount with something like compress-force=zstd:2
and then set everything else to not compress and let the file system handle it for you.

And have it setup so the installer will switch to LZ4 if the user picks a file system that doesn't offer compression.

There ya go.

Some uefi bootloader like systemd / gummiboot needs kernel and initramfs on uefi partition. You can't use btrfs there.

[caligula]

Some uefi bootloader like systemd / gummiboot needs kernel and initramfs on uefi partition. You can't use btrfs there.

He's talking about the rootfs != boot partition. You can link the btrfs code in the kernel, and not use it as a module. It's also more efficient that way.

[ms178]

I have just tried out the Kubuntu 22.04 image today, and it fails right at the point where you make your first software choice and updates itself in the background. And it simply won't complete the task. I've tried it some months before with the same result... either Kubuntu doesn't like my system anymore or there is a major bug in the installer which hasn't been fixed yet.