ZFS auf Linux/ Komprimierung
Komprimierung Bearbeiten
Allgemeines Bearbeiten
Im ZFS kann eine transparente Komprimierung für ein Dataset aktiviert werden, so dass die Daten beim Schreiben komprimiert und beim Lesen automatisch entpackt werden.
- Es stehen 4 Komprimierungsalgorithmen zur Auswahl: LZ4, LZJB, GZIP, ZLE [1]
- Der Standardalgorithmus ist momentan LZ4.
- Wenn ZFS den 1. Block eines Datensatzes nicht um min. 12,5% komprimieren kann, versucht es nicht, die restlichen Blöcke zu komprimieren. Es ist also kein Problem mit bereits komprimierten Daten zu arbeiten.
- LZ4 ist für die meisten Fälle am besten geeignet.
- Die ZFS-Komprimierung kann für jedes Dataset gesondert definiert/eingeschaltet werden.
- Man kann für jedes Dataset einen anderen Komprimierungsalgorithmus wählen.
- Man kann die Komprimierung für jedes Dataset ein- oder ausschalten.
- Auf einer modernen CPU kann man pro CPU-Kern mit LZ4 ca. 500 MB/s komprimieren und 1500 MB/s dekomprimieren [2].
- GZIP sollte eingesetzt werden, wenn ein effiziente Nutzung des vorhanden Speicherplatzes sehr wichtig ist.
- Auch bei der Komprimierung sollten logische Blockgrößen von 512 KiB bzw. 1 MiB eingesetzt werden.
Komprimierungsgeschwindigkeit Bearbeiten
Für den Vergleich der Komprimierungsalgorithmen wurde ein Pool aus 44 Festplatten ohne Redundanzen verwendet. Folgende Geschwindigkeiten konnten ermittelt werden:
Bei der mit "komp." markierten Messung wurden im Gegensatz zu allen anderen Benchmarks komprimierbare Daten verwendet, um das Verhalten von LZ4 sichtbar zu machen. Durch die Verwendung von Komprimierung kann die Lesegeschwindigkeit im Vergleich zu einem Pool ohne Komprimierung sogar leicht gesteigert werden. Aufgrund der vollständigen Auslastung der CPU erreichen LZJB und GZIP deutlich niedrigere Komprimierungsgeschwindigkeiten als ZLE und LZ4. Die höhere Lesegeschwindigkeit von LZ4 (komp.) kann durch die Verwendung der komprimierbaren Daten erklärt werden. Dadurch müssen weniger Daten gelesen werden und die Geschwindigkeit steigt.
Komprimierungsverhältnis Bearbeiten
Um die Algorithmen wirklich vergleichen zu können, wurden zusätzlich die Komprimierungsverhältnisse untersucht. Dabei kamen einerseits die unkomprimierten Kernelquellen [3] und andererseits eine Reihe von MRT-Aufnahmen (Dicom-Daten) als Testdaten zum Einsatz.
Die MRT-Aufnahmen konnten nur mit GZIP komprimiert werden. Bei den Kernelquellen schnitt ZLE am schlechtesten ab, da es lediglich Folgen von Nullen sucht und ersetzt. LZ4 konnte etwas bessere Ergebnisse als LZJB erzielen und GZIP lieferte auch bei diesem Datensatz die besten Ergebnisse.
Unter Berücksichtigung beider Benchmarks ergeben sich im Hinblick auf die Algorithmen die bereits am Anfang diese Kapitels genannten Empfehlungen.
Abhängigkeit von der logischen Blockgröße (recordsize) Bearbeiten
Da jeder logische Block einzeln komprimiert wird, wurde zusätzlich der Zusammenhang zwischen Komprimierungsgeschwindigkeit bzw.-verhältnis und der recordsize ermittelt.
Die Lesegeschwindigkeiten zeigen das gleiche Verhalten, wie bereits bei der Untersuchung des Einflusses der recordsize ohne Komprimierung festgestellt wurde. Auch bei diesem Benchmark sind sie, wie schon beim Vergleich der Algorithmen, wieder etwas höher als die eines Pools mit deaktivierter Komprimierung. Ab einer Größe von 64 KiB steigt die Komprimierungsgeschwindigkeit nicht mehr.
Optimale Komprimierungsverhältnisse können mit einer logischen Blockgröße ab 32 KiB erreicht werden. Unter Berücksichtigung beider Benchmarks sollte eine recordsize von 512 KiB oder 1 MiB zum Einsatz kommen.
1. Bild: Wie gut können die komprimierbaren Daten komprimiert werden? "Die MRT-Aufnahmen konnten nur mit GZIP komprimiert werden." Warum?