Compression
Siehe auch: ZFS Pool und Datasets erstellen: Die Grundlagen, ZFS RAID: Mirror, RAID-Z und Root-Pool spiegeln, ZFS: Warum dieses Dateisystem anders ist
ZFS kann Daten transparent beim Schreiben komprimieren und beim Lesen dekomprimieren. Bei heutigen CPUs merkt man davon nichts — im Gegenteil: Weil weniger Daten auf die Platte geschrieben werden müssen, sinkt die I/O-Last und es wird oft sogar schneller. Man bekommt also mehr Platz und mehr Performance gleichzeitig.
Wichtig: Beim Aktivieren werden nicht rückwirkend alle Daten komprimiert. Nur neue Schreibvorgänge werden komprimiert abgelegt. Schaltet man Compression wieder ab, bleiben die komprimierten Daten lesbar — neue Daten werden unkomprimiert geschrieben.
Aktivieren:
zfs set compression=lz4 pool/dataset
LZ4 ist heute der empfohlene Algorithmus — schnell, niedriger CPU-Verbrauch, gutes Kompressionsverhältnis. Es ist seit OpenZFS 0.7 und FreeBSD 12 der Default bei compression=on. Alternativ gibt es gzip (Level 1–9, stärkere Kompression aber mehr CPU) und zstd (seit OpenZFS 2.0, guter Kompromiss zwischen gzip und lz4).
Für Daten, die bereits komprimiert sind (Videos, Bilder, Archive), bringt Compression nichts — ZFS erkennt das und legt solche Blöcke unkomprimiert ab. Für Logfiles, Konfigurationen, VMs und Datenbanken lohnt es sich fast immer.
Compression in der Praxis
Test mit einer frischen Betriebssystem-Installation auf zwei baugleichen Rechnern — einmal mit, einmal ohne Compression:
# Kompressionsverhältnis prüfen zfs get compressratio rpool NAME PROPERTY VALUE SOURCE rpool compressratio 1.52x - # Plattenverbrauch mit Compression zpool list NAME SIZE ALLOC FREE CAP HEALTH rpool 74G 2,59G 71,4G 3% ONLINE # Plattenverbrauch ohne Compression zpool list NAME SIZE ALLOC FREE CAP HEALTH rpool 74G 3,93G 70,1G 5% ONLINE
2,59 GB statt 3,93 GB — ein Drittel weniger Plattenverbrauch bei einer Standard-Installation. Die Installation dauerte mit Compression etwa 30 Sekunden länger.
Algorithmus-Wahl
Pro Dataset lässt sich der Algorithmus und Level anpassen:
# LZ4 — schnell, empfohlen für fast alles zfs set compression=lz4 pool/data # gzip-9 — maximale Kompression, mehr CPU zfs set compression=gzip-9 pool/archiv # zstd — seit OpenZFS 2.0, guter Kompromiss zfs set compression=zstd pool/logs # Prüfen zfs get compression pool/data
Deduplication
Bei aktivierter Deduplication werden identische Blöcke nur einmal gespeichert. ZFS bildet für jeden Block eine SHA-256-Checksumme — existiert ein Block mit derselben Checksumme bereits, wird nur ein Verweis angelegt statt die Daten erneut zu schreiben.
Das spart Platz bei VMs (viele identische OS-Blöcke), Fileservern (dasselbe Dokument an verschiedenen Stellen) oder Versionierungs-Kopien. Aktivieren:
zfs set dedup=on pool/vms
Für zusätzliche Sicherheit gegen Hash-Kollisionen kann man einen Byte-für-Byte-Vergleich erzwingen:
zfs set dedup=sha256,verify pool/vms
Dedup-Warnung: RAM-Verbrauch
Deduplication frisst RAM. Die Dedup-Tabelle (DDT) muss im Arbeitsspeicher gehalten werden — pro Block ein Eintrag. Faustformel: ~320 Bytes pro Block, bei 128K-Blockgröße also ~2,5 GB RAM pro TB gespeicherter Daten. Passt die DDT nicht mehr in den RAM, wird sie auf die Platte ausgelagert und die Performance bricht dramatisch ein.
Ob sich Dedup lohnt, kann man vorher mit einem Trockenlauf prüfen — zdb -S pool zeigt das erwartete Dedup-Ratio ohne tatsächlich zu deduplizieren. In den meisten Fällen ist Compression allein die bessere Wahl: weniger Komplexität, kein RAM-Overhead, und der Platzvorteil ist oft vergleichbar.
Mehr zu ZFS: TRIM im ZFS-Pool aktivieren und Linux Mint mit verschlüsseltem ZFS Root Pool. Fragen? Einfach melden.
So ging es mir mit allem was man so mal eben in die Kiste stopfen kann. Ob es nun ein USB-Stick, eine CD/DVD oder eine Wechselplatte ist. Sie wird sauber erkannt und automatisch eingebunden. Es gibt ein schönes Symbol auf dem Gnome Desktop und in dessen Dateiverwaltung. Selbst der Zugriff auf alles klappt tadellos. Aber wehe man möchte das Teil wieder los werden.
Sobald man auf „Aushängen“ klickt, springt einem das System mit der GUI-Meldung an: cannot unmount volume
Sehr nervig…. Konsole aufmachen, su, unmount…..
Dass dieses ein Problem mit irgendeiner Berechtigung sein muss ist schnell klar, aber welcher? Google konnte mir schnell helfen. Das Problem besteht seit 147 bzw. Solaris Express, soll aber inzwischen gefixt sein. Ist es auch, nur taucht es inzwischen durch eine andere Änderung wieder auf. Das ganze ist bekannt und soll gelöst werden. Bisher gibt es einen Workaround.
Einfach nachstehende Zeile in die folgende Datei packen:
Der OpenSolaris fork Openindiana und gPodder
Pahhh da boote ich ganz cool meine Linux-Schüssel, hänge die USB-Platte ein und passe meine exports für einen ganz einfachen und schnellen Share an:
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.