Wie wirkt sich die Dateisystemkompression auf die Schreibleistung eines Heim-NAS aus?

Dateisystemkomprimierung kann ein Heim-NAS schneller schreiben lassen, wenn sie mehr Speicherarbeit entfernt, als sie CPU-Arbeit hinzufügt, aber sie kann auch die Latenz erhöhen.

Das Ergebnis hängt davon ab, was das NAS speichert, welchen Komprimierungsalgorithmus und welches Level es verwendet und ob der aktive Engpass die CPU, der Laufwerkspool oder der synchrone Schreibpfad ist. Dieser Artikel konzentriert sich auf transparente Dateisystemkomprimierung – nicht auf ZIP-Archive oder SMB-Komprimierung – da jede an einer anderen Stelle des Datenpfads arbeitet.

Der Kernkompromiss: Weniger geschriebene Bytes, mehr CPU-Arbeit

Transparente Komprimierung sitzt im Schreibpfad des Dateisystems. Anwendungen übergeben logische Daten, das Dateisystem teilt diese Daten in Datensätze oder Extents auf, und die Komprimierungs-Engine versucht, jede Einheit vor der Zuweisung mit weniger Bytes zu codieren. Wenn dies gelingt, erreichen weniger Blöcke den Speicherpool. Eine detaillierte Erklärung der transparenten Dateisystemkomprimierung zeigt, warum Datensatzgröße, Komprimierungsrate und physische Blockgröße alle beeinflussen, wie viel I/O tatsächlich eingespart wird.

Dies erzeugt einen Austausch statt einer universellen Geschwindigkeitssteigerung. Die CPU verbringt Zeit damit, wiederholte Muster zu finden, aber die Festplatten, SSDs, Paritätsschicht und der Speicherbus verarbeiten eine kleinere physische Nutzlast. Wenn die eingesparte Gerätezeit größer ist als die Komprimierungszeit, steigt der für Anwendungen sichtbare Schreibdurchsatz. Wenn die CPU bereits ausgelastet war oder die Daten kaum schrumpfen, kann die zusätzliche Stufe die Schreiblatenz erhöhen, ohne genug I/O zu reduzieren, um dies auszugleichen.

Die angegebene Geschwindigkeit kann ebenfalls missverstanden werden. Ein Kopierwerkzeug misst logische Bytes, die vom Client akzeptiert werden, während Laufwerksstatistiken physische Bytes nach der Komprimierung anzeigen. Ein NAS kann daher 500 MB/s logischen Fortschritt melden, während seine Festplatten deutlich weniger als 500 MB/s erhalten. Die Dateisystemkomprimierung reduziert nicht automatisch den eingehenden SMB-Verkehr; eine Netzwerkkomprimierung müsste früher im Pfad eingreifen.

Die Komprimierbarkeit entscheidet, wie viel Speicherarbeit entfällt

Kompression reduziert Arbeit nur, wenn die Eingabe wiederverwendbare Muster enthält. Text, Logs, Quellcode, wiederholte Datenbankfelder und mit Nullen gefüllte Bereiche weisen oft genug Redundanz auf, um deutlich zu schrumpfen. JPEG, HEVC-Videos, ZIP-Archive und verschlüsselte Dateien haben diese Muster bereits entfernt oder verschleiert. Die Beziehung zwischen Datenredundanz und Kompression erklärt, warum zwei gleich große NAS-Ordner gegensätzliche Schreibleistungsergebnisse liefern können.

Ein Heim-NAS hat selten eine einheitliche Arbeitslast, daher ist die nützliche Frage nicht, ob Kompression isoliert schnell ist. Sondern ob der aktive Datensatz klein genug wird, um den langsamsten Teil seines eigenen Schreibpfads zu verkürzen.

Auch die Reihenfolge ist wichtig. Daten, die vor der Verschlüsselung komprimiert werden, sparen möglicherweise noch Platz, aber der Chiffretext erscheint einer späteren Dateisystemebene normalerweise als hochentropisch. Ebenso kann ein spärliches oder teilweise leeres VM-Image gut komprimieren, obwohl das darin laufende Betriebssystem gemischte Inhalte speichert. Dateiendungen sind nützliche Hinweise, aber keine verlässlichen Messgrößen für die Blöcke, die das Dateisystem sieht.

Algorithmus und Kompressionsstufe bestimmen die CPU–I/O-Wechselrate

Schnelle Algorithmen bevorzugen kurze Verarbeitungszeiten und moderate Größenreduzierung, während aufwändigere Algorithmen mehr CPU-Zeit aufwenden, um ein besseres Verhältnis zu finden. Dies ist dieselbe Geschwindigkeits-gegen-Größe-Grenze, die auch in unabhängigen Vergleichen von Kompressionsmethoden sichtbar ist. Für ein ständig laufendes NAS ist das beste Verhältnis nicht automatisch die beste Schreibleistung, da jeder Vordergrund- und Hintergrundschreiber denselben Prozessor nutzt.

Das Kompressionslevel macht diese Grenze feiner. Veröffentlichten Zstandard-Level-Messungen zeigen, dass die Kompressionsgeschwindigkeit mit steigendem angeforderten Verhältnis sinkt, während die Dekompression vergleichsweise schnell bleibt. Das macht ein hohes Level attraktiv für Archivschreibvorgänge auf ruhender Hardware, aber potenziell störend für Live-Datenbanken, Container-Logs oder mehrere gleichzeitig schreibende Clients.

Kein Algorithmus liefert ein universelles Ergebnis. Prozessor-Generation, verfügbare Kerne, Speicherbandbreite, Implementierung, Chunk-Größe und Datensatz sind alle wichtig. Ein schneller Algorithmus auf einer stromsparenden CPU kann dennoch der Engpass hinter einem schnellen NVMe-Pool sein, während ein stärkerer Algorithmus effektiv kostenlos bleibt, wenn langsame Laufwerke dasselbe NAS dominieren.

Laufwerksmedium und Schreibmuster verschieben den Engpass

Rotationslaufwerke bieten in der Regel mehr Möglichkeiten, dass Kompression hilft, da jeder entfernte Block relativ teure Gerätearbeit vermeidet. Ein NVMe-Pool kann viel mehr Daten aufnehmen, bevor der Speicher zum Limit wird, sodass die CPU-Zeit für Kompression leichter sichtbar wird. Das übergeordnete Prinzip ist, dass CPU-Arbeit Speicher-I/O ersetzen kann, aber die bessere Ressource zum Einsatz hängt vom tatsächlichen Hardware-Verhältnis ab.

Die Art des Schreibens ändert ebenfalls die Antwort. Große asynchrone Streams geben dem Dateisystem Raum, Arbeit zu bündeln und zu parallelisieren. Kleine synchrone Updates warten weiterhin auf Bestätigungen der Dauerhaftigkeit, sodass eine reduzierte Payload-Größe die feste Latenz eines Flushs oder Journal-Commits möglicherweise nicht beseitigt. Dateisystem-Implementierungen komprimieren auch in bestimmten Einheiten: Das aktuelle Btrfs-Kompressionsverhalten verwendet beispielsweise begrenzte Chunks, parallele Verarbeitung und implementierungsspezifische Regeln, die die Nutzung von Metadaten und die Schreiblatenz verändern können.

Nebenläufigkeit fügt eine weitere Grenze hinzu. Mehrere Backups, Anwendungsdatenbanken, Medienimporte und Container-Schreiber können gemeinsam die CPU auslasten, selbst wenn jeder einzelne Stream für sich genommen davon profitiert. Kompression sollte daher im Zusammenhang mit Netzwerk-, Speicher-, Laufwerks- und Hintergrundaufgaben-Engpässen betrachtet werden, insbesondere wenn der Durchsatz nur während geplanter Jobs oder bei Mehrbenutzeraktivität sinkt.

Kompressionsbenchmarks müssen logische und physische Arbeit vergleichen

Ein Benchmark, der mit Nullen oder wiederholten Bytes gefüllt ist, kann ein komprimiertes Dateisystem schneller erscheinen lassen, als seine Laufwerke je schreiben könnten. Dieses Ergebnis mag für die logische Arbeitslast mathematisch korrekt sein, ist aber für ein Fotoarchiv oder verschlüsseltes Backup nutzlos. Häufige Fehler bei Speicherbenchmarks sind hoch komprimierbare Testdaten, gecachte Lesevorgänge, nicht abgeflusste Schreibvorgänge und das Versäumnis, den Anwendungsdurchsatz mit der Geräteaktivität zu vergleichen.

Ein aussagekräftiger Heim-NAS-Test verwendet dieselbe Hardware, denselben Datensatz, denselben Client-Pfad und dieselbe Hintergrundlast mit aktivierter und deaktivierter Kompression. Er erfasst logischen Durchsatz, physische Gerätebytes, CPU-Auslastung, Kompressionsrate und Schreiblatenz. Bei synchronen oder Multi-Client-Arbeitslasten ist die Perzentil-Latenz informativer als eine einzelne Spitzen-MB/s-Zahl, da kurze Verzögerungen in einem hohen Durchschnitt verborgen sein können.

Die endgültige Interpretation ist bedingt. Wenn die physischen Schreibvorgänge stark zurückgehen, während die CPU unterhalb der Sättigung bleibt, wirkt die Kompression als Durchsatzverstärker. Bleibt das Verhältnis nahe 1:1 und steigen CPU oder Latenz, ist es meist nur zusätzliche Arbeit. Wenn das Netzwerk bereits die Grenze ist, kann der Speicher effizienter werden, ohne dass die Client-Kopie schneller fertig wird.

Häufig gestellte Fragen

Verlangsamt Dateisystemkompression immer NAS-Schreibvorgänge?

Nein. Sie kann den logischen Schreibdurchsatz erhöhen, wenn komprimierbare Daten und ein Speicherengpass den eingesparten I/O gegenüber den CPU-Kosten überwiegen. Sie kann neutral oder langsamer sein bei hochentropischen Daten, begrenzter CPU-Kapazität, aggressiven Kompressionsstufen oder latenzsensitiven Schreibvorgängen.

Welche Dateien auf dem Heim-NAS profitieren am meisten von Kompression?

Protokolle, Text, Quellcode, wiederholte strukturierte Daten und teilweise leere virtuelle Festplatten sind häufige Kandidaten. Bereits komprimierte Medien, Archive und verschlüsselte Daten bieten normalerweise weniger Vorteile, obwohl das tatsächliche Ergebnis eher vom Blockinhalt als vom Dateinamen abhängt.

Kann Dateisystemkompression den SSD-Verschleiß reduzieren?

Es kann die vom Host auf die SSD geschriebenen Daten reduzieren, wenn Blöcke gut komprimierbar sind, was einen Teil der Gerätebelastung verringern kann. Es beseitigt jedoch nicht die Controller-Ebene Garbage Collection oder Schreibverstärkung, sodass die Haltbarkeitsgewinne vom Dateisystem, der Arbeitslast, dem freien Speicherplatz und der SSD-Firmware abhängen.