-Nuke-
Well-Known Member
Heyho,
beim Rumprobieren einen Weg zu finden ISO bzw. CUE/BIN-Daten effektiver zu speichern habe ich mal etwas rumgetestet. Ich habe zwar damals bei Systemeinrichtung lz4 als Kompression auf alle Datasets gesetzt, aber ich wollte nun mal wissen, ob es hierfür nicht lohnt einen eigenen Pool mit anderer Kompression zu nehmen. Weiterhin habe ich mir gedacht: Eine andere Recordsize ist bestimmt auch sinnvoll. Die Daten sind allesamt prinzipiell komprimierbar, da die ZIP-Archive dieser Daten kleiner sind. Um sie aber z.B. in einem Emulator zu nutzen, dürfen diese oft nicht in einem ZIP-Archiv liegen. Ein Image mal eben aus einem ZIP-Archiv mounten ist auch nicht drin.
Als Testdaten dienen mal die CUE/BIN Dateien von Tomb Raider 1-5 (USA und Germany) von der Playstation 1. Zwischen allen Tests wurde das dataset zerstört und neu erstellt.
Wie man sieht wird die Kompression mit höherer Recordsize teils deutlich effektiver, besonders bei gzip. Das ist an sich auch logisch, aber ich habe im Netz durchaus schon Aussagen gelesen, die das eher verneinen.
Nachdem was ich bisher gelesen habe, ist die Recordsize nur ein "upper limit" für ZFS die Daten zu speichern. D.h. anders als die Blocksize wird eine 100 KB Datei nicht plötzlich 1MB groß, nur weil man die Recordsize entsprechend gesetzt hat. 1MB ist hier übrigens das Maximum für die Recordsize.
Zur "Gegenprobe" mal alle Dateien gzippen und schauen was so dabei raus kommt:
Lustig! ZFS Compression mit gzip ist wohl effektiver als alle Daten per Hand selbst zu komprimieren. Man erreicht per Hand nur eine Compressratio von ~1.16. Auf dem gzip-Dataset liefert "zfs list" nämlich: datatank/isotest 4,48G, was der gemeldeten 1.41 entspricht. Kann sich das jemand erklären, oder Fehler meinerseits?
beim Rumprobieren einen Weg zu finden ISO bzw. CUE/BIN-Daten effektiver zu speichern habe ich mal etwas rumgetestet. Ich habe zwar damals bei Systemeinrichtung lz4 als Kompression auf alle Datasets gesetzt, aber ich wollte nun mal wissen, ob es hierfür nicht lohnt einen eigenen Pool mit anderer Kompression zu nehmen. Weiterhin habe ich mir gedacht: Eine andere Recordsize ist bestimmt auch sinnvoll. Die Daten sind allesamt prinzipiell komprimierbar, da die ZIP-Archive dieser Daten kleiner sind. Um sie aber z.B. in einem Emulator zu nutzen, dürfen diese oft nicht in einem ZIP-Archiv liegen. Ein Image mal eben aus einem ZIP-Archiv mounten ist auch nicht drin.
Als Testdaten dienen mal die CUE/BIN Dateien von Tomb Raider 1-5 (USA und Germany) von der Playstation 1. Zwischen allen Tests wurde das dataset zerstört und neu erstellt.
Code:
Standard-Recordsize von 128K:
zfs create -o compression=lz4 -o recordsize=128K datatank/isotest
-> datatank/isotest compressratio 1.20x
zfs create -o compression=gzip -o recordsize=128K datatank/isotest
-> datatank/isotest compressratio 1.33x
zfs create -o compression=gzip-9 -o recordsize=128K datatank/isotest
-> datatank/isotest compressratio 1.33x
Record-Size von 1M:
zfs create -o compression=lz4 -o recordsize=1M datatank/isotest
-> datatank/isotest compressratio 1.25x
zfs create -o compression=gzip -o recordsize=1M datatank/isotest
-> datatank/isotest compressratio 1.41x
zfs create -o compression=gzip-9 -o recordsize=1M datatank/isotest
-> datatank/isotest compressratio 1.41xWie man sieht wird die Kompression mit höherer Recordsize teils deutlich effektiver, besonders bei gzip. Das ist an sich auch logisch, aber ich habe im Netz durchaus schon Aussagen gelesen, die das eher verneinen.
Nachdem was ich bisher gelesen habe, ist die Recordsize nur ein "upper limit" für ZFS die Daten zu speichern. D.h. anders als die Blocksize wird eine 100 KB Datei nicht plötzlich 1MB groß, nur weil man die Recordsize entsprechend gesetzt hat. 1MB ist hier übrigens das Maximum für die Recordsize.
Zur "Gegenprobe" mal alle Dateien gzippen und schauen was so dabei raus kommt:
Code:
Unkomprimiert:
$ du -hd0 /datatank/isotest/
6,3G /datatank/isotest/
alles zippen:
$ find . -type f -exec gzip {} \;
$ du -hd0 /datatank/isotest/
5,4G /datatank/isotest/Lustig! ZFS Compression mit gzip ist wohl effektiver als alle Daten per Hand selbst zu komprimieren. Man erreicht per Hand nur eine Compressratio von ~1.16. Auf dem gzip-Dataset liefert "zfs list" nämlich: datatank/isotest 4,48G, was der gemeldeten 1.41 entspricht. Kann sich das jemand erklären, oder Fehler meinerseits?
