Auswirkung der mkinitcpio Kompression

Schon länger war es etwas still in diesem Blog, diese stille möchte ich nun vertreiben und regelmäßig neue Beiträge für die digitale Nachwelt erstellen. Den Anfang soll hierbei ein kleines Experiment aus Dezember 2015 machen.

Konkret geht es um die Auswirkung der unterschiedlichen Kompressionsmöglichkeiten von mkinitcpio unter Arch Linux, die Ergebnisse sind aber auch auf andere Distributionen wie Debian, Ubuntu oder Fedora anwendbar. Die Idee ist es die Initial Ramdisk vom Linux Kernel so klein wie möglich zu bekommen, gleichzeitig aber auch die dafür erforderliche Zeit zu berücksichtigen.

Bei den angegebenen Zeiten wurde jeweils gemessen wie lange mkinitcpio -P benötigt um sowohl die Standard als auch die Fallback Ramdisk zu generieren, wir reden hier also immer von der Kompressionszeit. Die Zeit, welche für die Dekompression beim Systemstart erforderlich ist, wurde nicht explizit gemessen, erfahrungsgemäß liegen diese unabhängig vom verwendeten Algorithmus bei unter einer Sekunde.

Kompression	Fallback (MiB)	Standard (MiB)	Zeit (s)	Prozent (%)
none	80	40	18.021	100
gzip	27	14	19.787	34
bzip2	25	13	38.675	32
lzma	18	8.4	67.259	22
xz	18	8.4	65.069	22
lzop	38	20	13.152	48
lz4	39	20	8.670	49

Addiert man die Größe, der unkomprimierten Fallback und Standard Ramdisk, kommt man auf 120 MiB, was so auch die 100% Marke in der Tabelle definiert. Wie unschwer zu erkennen ist steht none für keine Kompression.

Nachfolgend möchte ich die Ergebnisse meines Tests basierend auf meiner Erfahrung erläutern:

none

Man würde erwarten, dass keine Kompression am schnellsten ist, dies ist jedoch ein Trugschluss. Zwar wird keine Zeit für eine Kompression benötigt, im Gegenzug aber die Zeit für Plattenzugriffe drastisch erhöht. Ich würde aus diesem Grund davon abraten unkomprimierte Ramdisks zu verwenden.

gzip

Der alte Freund gzip erreicht brauchbare 14 MiB für die typischerweise genutzte Ramdisk, was ca. 20 Sekunden dauert. Wie erwartet gibt es hier keine großen Überraschungen. Insgesamt benötigen wir somit 41 MiB. Vorteil von gzip ist das bis auf wenige Ausnahmen wohl jede Linux Distribution damit umgehen kann.

bzip2

Auch bzip2 ist ein guter alter Freund, der jedoch in diesem Beispiel keine gute Wahl gewesen ist. Insgesamt benötigen wir damit ca. 38 MiB, also lediglich 3 MiB weniger bezogen auf gzip. Gleichzeitig benötigen wir für dieses geringe Ersparnis an Plattenplatz fast doppelt so viel Zeit, und das bei jedem Kernel Upgrade.

lzma / xz

Sowohl xz als auch lzma gelten als gute Kompressionsmöglichkeiten, benötigen dafür aber auch überdurchschnittliche Lange. Da die Kompression unverhältnismäßig lange dauert, würde ich vom Einsatz dieser für derartige Zwecke abraten.

lzop

Durch btrfs hat LZO, und damit auch lzop an Beliebtheit gewonnen. Der Ansatz ist es Daten möglichst CPU schonenden zu komprimieren und dadurch das Nadelöhr Disk-IO / Festplatte zu entlasten. Die Rechnung geht bei modernen Prozessoren voll auf, in der Regel ist die zusätzliche Belastung durch lzo kaum der Rede wert. Immerhin werden noch über 50% des Platzes eingespart, was für diese Anwendung ein brauchbares Ergebnis ist.

lz4

Das in letzter Zeit zunehmend beliebtere lz4 ist eine Art lzop mit Heckspoiler und Ralleystreifen, die Kompressionsraten sind in der Regel marginal schlechter, die Geschwindigkeit jedoch deutlich höher.

Für mich ist lz4 die Kompression der Wahl für die Initial Ramdisks, eine Ausnahme bilden Systeme auf denen /boot zu klein ist, dort dann je nach Verfügbarkeit xz oder lzma. Bei den heute verfügbaren Systemen mit schnellen HDDs oder SSDs spielt es keine wesentliche Rolle mehr, ob eine Datei 10 oder 20 MiB groß ist, die Zeit welche eine Kompression oder Dekompression benötigt jedoch schon. Insbesondere bei Arch Linux gibt es öfters neue Kernel Versionen, dort stets über eine Minute auf die Kompression zu warten ist in meinen Augen nicht Verhältnismäßig. Hohe Kompressionsraten sollte man wählen, wenn Platz und Bandbreite knapp ist, in anderen Fällen kann man pauschal lz4 oder lzop auf das Problem werfen ohne sich groß sorgen über die Konsequenzen machen zu müssen.

Der Artikel erläutert bewusst nicht genau, wie man die verwendete Kompression umstellt, die unterstützten Kompressionsmöglichkeiten unterscheiden sich je nach Kernel Version und Distribution erheblich, eine falsche Auswahl führt sofort zu einem nicht mehr startenden System. Die oben genannten Ergebnisse wurden Ende 2015 ermittelt, die ermittelten Zeiten und Dateigrößen sind also nur als Richtwert zu verstehen.