Warum Betriebssysteme nicht einfach alles mit Zstandard komprimieren

Die Frage klingt erst mal logisch: Wenn Zstandard Daten schnell und effizient komprimiert, warum nutzen Betriebssysteme das nicht einfach überall und sparen Speicherplatz auf SSDs?

Die kurze Antwort: Weil Speicherplatz nur ein Teil des Problems ist. Ein Betriebssystem muss Daten nicht nur klein halten. Es muss sie jederzeit schnell, zuverlässig und mit wenig Zusatzaufwand lesen und schreiben können.

Kompression ist nie gratis

Auch ein schneller Codec wie Zstandard kostet Rechenzeit. Bei großen Archiven oder Backups ist das oft ein guter Tausch. Im laufenden Betrieb eines Dateisystems sieht die Sache anders aus. Dort geht es um viele kleine Zugriffe, unvorhersehbare Last und harte Anforderungen bei Latenz.

Ein Betriebssystem kann nicht davon ausgehen, dass jede Datei schön sequentiell gelesen wird. Viele Workloads bestehen aus kleinen Blöcken, Metadaten, zufälligen Zugriffen und dauernden Änderungen. Genau da wird Kompression kompliziert. Man spart Platz, handelt sich aber zusätzliche CPU-Arbeit, mehr Verwaltungslogik und im schlechtesten Fall Ruckler bei I/O ein.

64-Kilobyte-Blöcke sind keine Zauberformel

Die naheliegende Idee lautet oft: Dann komprimiert man eben in festen Blöcken, etwa 64 Kilobyte. Das begrenzt den Aufwand und hält den Zufallszugriff brauchbar. Genau solche Ansätze gibt es seit Jahren in verschiedenen Dateisystemen und Betriebssystem-Funktionen.

Aber auch Blockkompression hat Nebenwirkungen. Wenn sich wenige Bytes in einem komprimierten Block ändern, muss oft der ganze Block neu geschrieben werden. Das kann Schreibvorgänge aufblasen. Es erhöht die Fragmentierung. Und es macht Caching, Deduplizierung, Prüfsummen und Fehlerbehandlung nicht einfacher.

Vor allem bei Daten, die schon komprimiert sind, bringt der Aufwand oft fast nichts. Videos, Fotos, viele Spiele-Assets, Container-Images oder heruntergeladene Pakete lassen sich oft kaum weiter schrumpfen. Das Betriebssystem müsste also erst erkennen, wo sich Kompression lohnt, statt blind alles durch einen Codec zu jagen.

Dateisysteme sind konservativ, aus gutem Grund

Dateisysteme gehören zu den empfindlichsten Teilen eines Betriebssystems. Fehler dort sind teuer. Nicht im Sinne von Benchmarks, sondern im Sinne von Datenverlust, kaputten Snapshots oder schwer reproduzierbaren Randfällen.

Darum werden neue Funktionen im Storage-Bereich langsamer eingeführt als vieles andere. Ein moderner Codec allein reicht nicht. Es geht um Recovery nach Abstürzen, Interaktion mit Journaling, Speicherverbrauch im Kernel, Verhalten unter Last und Wartbarkeit über viele Jahre.

Genau deshalb setzen Systeme, die Kompression anbieten, meist auf gezielte Aktivierung statt auf einen pauschalen Standard. Administratoren oder Distributionen können dann selbst entscheiden, welche Daten davon profitieren.

Zstandard ist nicht das Problem

Die Diskussion verfehlt oft den Punkt, wenn sie nur auf den Codec schaut. Zstandard gilt als schnell und flexibel. Daran scheitert es nicht. Die eigentliche Hürde liegt in der Schicht darunter: im Design des Dateisystems und in den Prioritäten des Betriebssystems.

Ein OS braucht Vorhersagbarkeit. Kompression bringt dagegen Variabilität hinein. Dateien wachsen und schrumpfen anders als unkomprimierte Blöcke. Schreibpfade werden komplizierter. Speicherallokation wird schwieriger. Auch Debugging und Performance-Analyse werden mühsamer, weil I/O nicht mehr direkt mit physischem Platzbedarf zusammenfällt.

Auf SSDs zählt mehr als nur Kapazität

Der Verweis auf SSD-Speicherplatz ist verständlich, greift aber zu kurz. SSDs haben die Debatte verändert. Früher war jede Einsparung auf langsamen Festplatten ein starkes Argument. Heute sind Kapazität, Preis, Controller-Verhalten, Wear-Leveling und reale Anwendungsprofile wichtiger als die simple Frage, ob man noch ein paar Prozent spart.

Kompression kann SSD-Schreibvolumen senken. Sie kann es in manchen Szenarien aber auch erhöhen, wenn ständig neu gepackt werden muss. Dazu kommt: Viele Engpässe liegen heute nicht beim nackten Platzverbrauch, sondern bei Build-Zeiten, Ladeverhalten, Netzwerktransfer oder RAM-Druck.

Wo Zstandard trotzdem gut passt

Ganz außen vor ist Zstandard im Betriebssystem-Umfeld nicht. Für Paketformate, Archive, Backups, Container-Layer oder komprimierte Systemabbilder ist der Codec sehr attraktiv. Dort sind die Datenströme planbarer, und der Kompromiss zwischen CPU und Platzgewinn lässt sich besser steuern.

Auch bei einzelnen Dateisystemen oder Speicherfunktionen kann Zstandard sinnvoll sein, wenn Workload und Implementierung zusammenpassen. Nur der Gedanke, ein Betriebssystem sollte einfach standardmäßig alles in kleinen Blöcken komprimieren, unterschätzt die Folgen im Alltag.

Die nüchterne Antwort

Betriebssysteme verzichten nicht auf flächendeckende Zstandard-Kompression, weil die Idee unbekannt wäre. Sie verzichten oft darauf, weil Dateisysteme Stabilität und berechenbares Verhalten höher gewichten als maximale Platzeffizienz.

Wer vor allem Speicher sparen will, findet für bestimmte Datenklassen gute Einsatzorte für Zstandard. Wer ein allgemeines Betriebssystem baut, muss strenger auswählen. Genau deshalb ist Kompression im Storage-Bereich meist ein Werkzeug für konkrete Fälle und kein universeller Default.