Which compression algorithm to choose in mkinitcpio.conf?

I wonder if I should use lzop or lz4 instead of the default gzip?

# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.

Which one would you recommend? My system is installed on BTRFS if that would make any difference.

I think @2000 has zstd on Btrfs

I was also advised by @2000 to add compress=zstd to the options in fstab:

ID=1a1b20eb-6fb5-46fc-9666-3b0e6f4c4300 / btrfs subvol=@,defaults,noatime,space_cache,autodefrag,compress=zstd 0 0

But those in mkinitcpio.conf, aren’t those for compressing the kernels put in /boot?

I don’t know about it really. I just used his copy & paste method. Maybe it can or can’t be used? :thinking:

1 Like

Don’t know. zstd is not among those options in mkinitcpio.conf. Maybe it can be added to it. I really don’t know. I read a little bit about lzof and lz4. They seem to be a bit faster in compressing but the images produced are slightly larger in size…

Ya maybe it’s not an Arch option for that or some other reason. I don’t really know. :upside_down_face:

1 Like

zstd compressed initramfs is only supported by Linux 5.9 and newer.

Your /etc/mkinitcpo.conf should include the option #COMPRESSION="zstd". You probably didn’t check those .pacnew files if not :wink: .


You are right! Shame on me!

How about the other two, lzop and lz4 when it comes to speed and cpu usage? Or you think zstd is the best option overall?

1 Like

yeah, i chose zstd when merging my mkinitcpio.conf and the .pacnew. But i’m not sure what is “the best” option. The speed depends on the CPU and number of cores as far as i remember… there is a another thread where this got discussed.

1 Like

Thanks for the reply!
I will change the compression to zstd.
I will look around the forum and see if I find that thread.

Just an off-topic question:

Will arch-chroot from a live medium works as usual even though / is on a subvolume?

As long as you mount the subvolume @, yes.

  1. Boot into the live environment
  2. In case your device is encrypted, decrypt and mount your luks partition (e. g. /dev/sda2); otherwise leave out the decryption part and use /dev/sda2 instead of /dev/mapper/crypt:
sudo cryptsetup luksOpen /dev/sda2 crypt &&
sudo mount -o compress=zstd,subvol=@ /dev/mapper/crypt /mnt
  1. Only on UEFI systems: Mount your EFI boot folder (e. g. /dev/sda1)
sudo mount /dev/sda1 /mnt/boot/efi
  1. chroot into your system
sudo arch-chroot /mnt
  1. Do some root stuff …

Thank you so much for your answer! I appreciate it!

Have a great day!

1 Like

It doesnt matter. And I honestly do not know why there are so many choices. This is just over complicating things. I stick with “xz”.


Because it’s Linux, which is all about choice.

But you’re not wrong, bzip2 and lzma are superseded by faster algos with better compression ratio. Gzip, xz, lz4 and zstd are valid and useful alternatives.

That said, XZ in my opinion only makes sense if you want to squeeze out a few KB/MB of free space. It’s rather slow both in compression and in decompression.


In terms of speed and/or CPU usage how would you rate the algorithm that you have mentioned above if space is not a concern.

lz4 or zstd. Depends on the exact options and of course your hardware.
I use zstd -15 as a good compromise.
Somewhere I have a little script that logs total and cpu time, and file size for zstd and xz, might post it some day (I don’t have it on this computer).

(and there’s always “uncompressed” but I’m not sure if it’s really faster than e.g. lz4)

1 Like

Thanks for the reply and explanation!
This machine got a AMD Ryzen 7 4800U. So if I were to use zstd -15, where do I need to make the change?

I know that I need to read up on these stuff and perhaps at the end of the day the difference is in order of some hundreds of a second but it is just nice to know that you can speed up things a bit when possible.

That would be nice!

To use a specific compression algorithm simply uncomment it in mkinitcpio.conf (and comment all the others).

For options, see COMPRESSION_OPTIONS array.
Important: Do not use the above as I think it applies to all compression algos.
From manpage:

This option is generally not used. It can be potentially dangerous and may cause invalid images to be generated without any sign of an error.

If you’re adventurous, you can modify /usr/bin/mkinitcpio like I already described here. I don’t support or endorse this :slight_smile:

1 Like


This sounds very tempting now! I’ll have a look!

No problem! See my username? :sweat_smile:

1 Like