F43 Change Proposal: Compress the initrd with zstd by default (self-contained)

Project Discussion Change Proposals
,
1

Compress the initrd with zstd by default

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Use zstd to compress the initrd for all Fedora variants by default when built with dracut.

:link: Owner

:link: Detailed Description

Since feat(dracut): search for zstd compressor first by bdrung · Pull Request #385 · dracut-ng/dracut-ng · GitHub, dracut is now using zstd to compress the initrd by default. It does so only when the zstd binary is available (and not the library as this is a shell script), so right now on Fedora, most variants are still using xz compressed initrds by default (Tree - rpms/dracut - src.fedoraproject.org). This changes however as soon as users install zstd on their systems.

The current zstd users are:

Other related issues:

For this change, we will replace the dependency in dracut from xz to zstd and we might configure a different compression ratio, potentially pushing that upstream, depending on feedback.

:link: Feedback

None so far.

We welcome testing for various compression ratios and comparing size of the initrd and speed of decompression (which matters on boot) on different hardware. See Boot partition can easily run out of space on upgrade · Issue #1247 · coreos/fedora-coreos-tracker · GitHub for an example.

:link: Benefit to Fedora

Smaller initrd and faster boots. See Boot partition can easily run out of space on upgrade · Issue #1247 · coreos/fedora-coreos-tracker · GitHub for some measurements. We did the change in Fedora CoreOS to reduce the size of the initrd to save disk space in the /boot partition.

:link: Scope

  • Proposal owners: Replace dependency on xz by zstd in dracut to enable zstd by default
  • Other developers: Make sure that their tools still work with the new compression algorithm
  • Release engineering: #Releng issue number TBD but nothing should be needed here
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: N/A, it’s a general improvement

:link: Upgrade/compatibility impact

There should be no impact for most users as the decompression of the initrd is handled by the kernel and it has had support for zstd for a while now. Users of custom kernels should make sure this is supported in their configs.

Existing installations will be updated to use zstd by default. No manual action should be required.

Users that want to keep using xz for compressing the initrd can configure it in their dracut config.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

On package mode systems:

  1. Install zstd: dnf install -y zstd
  2. Rebuild the initrd: dracut <path to initrd> or dracut --regenerate-all to do it for all kernel versions (make a backup to compare sizes, etc.)
  3. Validate that it is zstd compressed: LANG=C grep -aUPq "\x28\xb5\x2f\xfd" <path to initrd> && echo "using zstd" || echo "not using zstd"
  4. Reboot

For ostree image systems, you should wait until the change lands in Rawhide or build your own, including the configuration from Fedora CoreOS as an example.

For bootable container image mode systems, you can install zstd and rebuild the initrd in a Containerfile and switch/rebase your system to it.

:link: User Experience

There should be no change in user experience beyond slightly faster boots.

:link: Dependencies

No other dependencies as far as the authors know right now.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Revert the change
  • Contingency deadline: Final freeze
  • Blocks release? No

:link: Documentation

To be written if accepted.

:link: Release Notes

To be written if accepted.

Last edited by @amoloney 2025-07-04T13:03:54Z

Last edited by @amoloney 2025-07-04T13:03:54Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This sounds like a good idea to me, but just for the sake of transparency



that doesn’t match my own intuitions about compression algorithms, nor does it match the statistics provided in the linked table at Boot partition can easily run out of space on upgrade · Issue #1247 · coreos/fedora-coreos-tracker · GitHub.

What that link shows matches my own experience, and it’s that xz has insane compression ratios (almost impossible-seeming, in fact, compared to gzip and bzip2), but it takes time to achieve them.

Switching to zstd might at most achieve equivalent compression ratios (so, not smaller initrd, but same size — or possibly slightly larger), but it could decompress as much as an order of magnitude faster than with xz.

(xz’s decompression also should benefit from parallelism much more than other algorithms. The stats in that table make me wonder if only a single core is being used to decompress the initrd. Because I know xz is slow, but it doesn’t seem like it should be that slow.)

Like I said, the tradeoffs there sound desirable to me, but it doesn’t seem like a good idea to set up expectations of smaller initrd files, because it’s still just about impossible to beat xz’s compression on the basis of size.

1 Like
4

Things may have changed, but last I recall xz decompression was single core. So zstd should be somewhat faster.

1 Like
5

Oh, yeah, you may be right about that. I know xz compression (which is so slow it makes xz decompression look speedy) benefits massively from multiple cores, which is the only thing that makes it usable. But decompression may be non-parallelizable.

Ah, actually, no! Since xz 5.4.0 (December 2022), xz can parallel-decompress as long as the compression was done with multiple threads. (Multi-threaded compression creates an .xz file with multiple blocks containing size headers, a necessary requirement for decompressing in parallel.)

But zstd is still way faster, even when achieving similar compression ratios.

6

Dracut has supported the usage of pixz for multi-threaded XZ (de-)compression. But, I don’t think we use this in Fedora.

The important thing is that Zstd is faster and uses slightly less resources to decompress, which is a huge win for improving boot times and general system responsiveness.

1 Like
7

Good points. @hricky is working on updated numbers to make the tradeoff clearer. Apparently some of our images are not even using xz yet.

8

I did some benchmark tests on Zstandard decompression times using userspace tools. Apparently the initramfs images in some Fedora editions are currently Gzip compressed, so I used those variants for comparison. For reference, I’ve also included the commands I use for testing.

See Compress the initramfs with zstd by default on Fedora package mode systems - HackMD.

1 Like
9

Just wanted to pop in and say that Universal Blue has been doing this for years, it’s an excellent change and I believe there are no downsides.

3 Likes
10

This change proposal has now been submitted to FESCo with ticket #3441 for voting.

To find out more, please visit our Changes Policy documentation.