zfs set compression macht genau was?

pit234a

pit234a

Well-Known Member
Der Titel sagt wenig aus, was daher rührt, dass ich zu wenig weiß.

Vorab: ich habe die meisten pools mit lz4-compression angelegt.
Nun bin ich eher begeistert von zstd und die letzten pools habe ich nur noch damit angelegt.
So weit, so gut.

Nun kann ich aber doch einem Dataset und nicht nur einem Pool eine compression= zuweisen.

Wenn ich nun einem bestehenden Dataset zstd zuweise, was macht das dann?
Zuvor war es lz4.
Wird von nun an alles zu zstd?
Oder werden die alten Daten dann auch umgewandelt also neu gepackt?

Anders gefragt: wenn ich nur noch zstd will, muss ich dann neue pools/datasets anlegen und die alten darauf überspielen?
Oder genügt es einfach, die Eigenschaft zu ändern und zstd an Stelle von lz4 zu setzen?
 
Hallo,

die alten Daten bleiben wie sie sind. Aber alles was neu geschrieben wird, wird mit den aktuellen Einstellungen komprimiert.

Gruß
PhysChemist
 
pit234a schrieb:
Anders gefragt: wenn ich nur noch zstd will, muss ich dann neue pools/datasets anlegen und die alten darauf überspielen?
Zum Vergrößern anklicken....
Du kannst, aber musst nicht. Wie PhysChemist richtig sagt, wird alles neu geschriebene ab dann mit zstd komprimiert.

Die Überlegung ist auch, wieviel du an Stromkosten für die Aktion reinsteckst. Nehmen wir an, du hast auf einem dataset gemischte files von insgesamt 4TB auf lz4 bei einer ratio von 1,68. Das alles einmal auf ein frisches dataset mit zstd (zstd-3 ist standard) genudelt bringt dir vllt. eine ratio von 1,8. Da könnte es interessanter sein, das Geld für größere Platten statt Strom auszugeben.

Effizienter wirst du, wenn du die recordsize von 128K auf 1M anhebst, da die Kompression auf Blockebene passiert. Das ist vor allem dann sinnvoll, wenn deine Dateien im Schnitt größer als 1MB sind. In der Theorie wird der Durchsatz dann auch erhöht, da weniger Blöcke verwurstet werden müssen. Nur 1x Checksumme statts 10 (bei 128K) berechnen quasi.

Und noch effizienter im Sinne der ratio wird das auf zstd-19, aber wie im anderen Thread erwähnt fühlt sich das Schreiben zwischen Anker geworfen und abgestürzt an.
 
pit234a schrieb:
Zuvor war es lz4.
Zum Vergrößern anklicken....
Ich schließe mich insofern mein Vorredner an, das man sich überlegen sollte, warum man die Kompression umstellt.
Also ja. Das man zstd verwenden will, leuchtet mir noch irgendwo ein. Aber warum man bereits vorhandene Daten von lz4 nach zstd umwandeln will, das erschließt sich mir nicht so. Was erwartest Du Dir davon?
 
Andy_m4 schrieb:
Was erwartest Du Dir davon?
Zum Vergrößern anklicken....
einfach nur Einheitlichkeit.
Keine sonstigen Erwartungen.

Ich erkenne auch mal wieder, wie gut es sein kann, hier Fragen zu stellen.
Zum ersten Mal hatte ich zstd auf meinem neuen nvme-SSD eingesetzt (von dem ich nicht boote) und da ist mir (natürlich) kein Performance-Nachteil gegenüber lz4 auf meinen SATA-SSDs aufgefallen.

In der Folge hatte ich dann mit zstd experimentiert und verschiedene Archive erstellt.
Leider finde ich den Zettel mit meinen Notizen nicht mehr, aber ich glaube, dass ich dabei bis -22 gegangen bin (macht FreeBSD das überhaupt mit? da gab es eine Begrenzung bis -19?) Ich weiß auch nicht mehr genau den Rest der Daten, aber aus dem Kopf heraus brauchte ein ca 30G Archiv dann insgesamt etwa 4h (zstd + Verschlüsselung über GPG) und belegte nur noch 12G auf dem Datenträger. Das hatte mich beeindruckt!
Die nächsten Pools legte ich auf Medien an, die über USB3 angeschlossen waren. Da merkt man dann die möglicherweise mangelnde Performance ja auch nicht direkt.

Mein Denken ist beeinflusst von Systemen, die möglichst kompakt daher kommen und mich immer wieder überraschten.
So hatte ich auf alten PCs (wirklich alt) Knoppix (ein Live-GNU/Linux) auf eine BTRFS Partition mit Kompression gelegt. Knoppix selbst ist ebenfalls gepackt. Und das war erstaunlich flott!
Daraus und aus ähnlichen Erlebnissen folgerte ich, dass die Reaktivität von Systemen nicht durch das Entpacken beeinträchtigt wird, sondern im Gegenteil, desto gepacktere Daten umso schneller gelesen und entpackt werden können.
Der Fehler in meinem Denken ist natürlich, dass ich von rein statischen Systemen ausging, bei denen Schreiben ausgeblendet werden kann.
Im echten Leben ist Lesen ja eher kein Problem, sondern eben das Schreiben von Daten. Da war ich mal wieder regelrecht Betriebs-blind.


Was mir auch aufgefallen ist: dass ich immer noch nicht wirklich ZFS denke.
Ob das jemals besser wird?
Ich versuche mal, meine Denkschwierigkeiten zu erklären.
Wieso ist die compression eine Eigenschaft eines Datasets?
Wieso will jemand auf einem Pool unterschiedliche Kompressionen nutzen?
In meinem Hirn ist irgendwie verankert, dass man einen Pool baut und dem dann die Kompression mitgibt. Ein Mirror aus drei Platten oder so, sollte auch gleiche Kompression aufweisen. Einheitlichkeit eben. Und alle Datasets auf einem Pool sollten dem folgen.
Die zusätzliche Flexibilität mit ZFS fließt nur tröpfchenweise in mein Denken.

Trotzdem, der wichtigste Punkt ist mir nun doch klarer, dass nämlich die alten Daten bleiben, wie sie sind.
 
pit234a schrieb:
Wieso will jemand auf einem Pool unterschiedliche Kompressionen nutzen?
Zum Vergrößern anklicken....
Weil in den Datasets ggf. verschiedene Arten von Daten liegen. Sagen wir da ist ein Dataset welches nur h265 komprimierte Videos enthält. Da kann man die compression eigentlich ganz ausschalten, das wird nicht mehr viel besser.
Ein anderes dataset enthält Dokumente, die lassen sich wiederum super komprimieren.
 
pit234a schrieb:
Wieso ist die compression eine Eigenschaft eines Datasets?
Zum Vergrößern anklicken....
Es kann eine Eigenschaft eines pools oder eines datasets sein. Was der pool gesetzt hat, wird an das dataset vererbt, wenn man es aktiv hat (inherit) oder man etwas anderes je dataset festlegt.

pit234a schrieb:
Wieso will jemand auf einem Pool unterschiedliche Kompressionen nutzen?
Zum Vergrößern anklicken....
Um den Speicherplatz und Rechnerleistung möglichst effizient auszunutzen. zstd-19 ist perfekt für logfiles/Textdateien/sonst. Dokumente.
Bei bereits komprimierten Dateien wie pdf, mp3, opus, h264, h265 usw. holt man max. 1-2% raus, egal ob zstd-3 oder zstd-19. Nur letzteres dauert ewig und hat dann keinen Nutzen als Gegenwert, außer sinnlos die CPU zu beschäftigen.

Vielleicht hilft das fürs einfachere Denken: Betrachte einen pool einfach als Festplatte (mit features!) und datasets als Ordner (mit features!).
Auf einer Platte hat man schon immer seine Dateien in Ordnern wegsortiert, es ist einfach nochmal ne Ebene davor (mit features!) :)
 
pit234a schrieb:
Wieso will jemand auf einem Pool unterschiedliche Kompressionen nutzen?
Zum Vergrößern anklicken....

Wurde jetzt zwar schon beantwortet aber noch als Beispiel wie es auf meinem Heimserver aussieht:

Früher: Fast überall lz4, auf einigen Datasets (wo ohnehin nur Mediendaten, schon kompremierte Daten oder verschlüsselte Daten liegen) keine Kompression.

Seit einiger Zeit bin ich auch auf zstd umgestiegen (ohne Migration, das alte Zeug bleibt lz4, sehe keinen Grund solange der Pool nicht zu 90% voll läuft da was zu machen): Fast überall zstd-1, wie gehabt manche Datasets ohne, und manche, wo vorallem selten Backups hinkommen zstd-13 (19 ist auf meinem 8 Jahre alten Server zu langsam).
Dann hab ich noch als Spezialfall ein Dataset wo Gigabyteweiße Logs pro Woche hinkommen, da ist zstd-3 (default) mein Freund da es gerade bei Text nochmal nen ordentlichen Unterschied zu -1 macht, aber man mit -3 noch in Echtzeit damit arbeiten kann im Vergleich zu höheren Einstellungen.


edit: Hier ist ein wie ich finde gutes Dokument zu diesem Thema: https://freebsdfoundation.org/wp-content/uploads/2021/05/Zstandard-Compression-in-OpenZFS.pdf
 
Mal quer reingegretscht: Wo wir eben bei Blocksize waren, gibt's ne Faustformel, wie man die festlegen sollte? Also z.B. habe ich ein Dataset nur für raw files meiner Kamera, ein Bild ist etwa 30..40Mb groß, ein anderes Dataset hat fertige jpegs mit 5..15Mb etc.
 
Die Blocksize bei ZFS ist immer die max. Blocksize. Es spricht also nichts dagegen in beiden Fällen 1M zu nehmen.

Es gibt ein paar wenige Anwendungsfälle wo man aufpassen muss, z.b. Datenbanken oder wenn voraussichtlich viele kleine Änderungen in großen Files stattfinden auf denen Snapshots liegen, VM Images könnten z.b. so ein Fall sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben