sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris/x86 und OpenSolaris => Thema gestartet von: Bentsch am 02. Januar 2009, 10:58:58
-
Hallo,
ich bin noch ein ziemlicher Solaris-Neuling und habe seit einigen Monaten einen OpenSolaris-Server laufen, auf den mit Windows- und Mac-Systemen zugegriffen wird. Und ich habe es bisher nicht geschafft, dass die Kompression mit ZFS richtig funktioniert.
Derzeit habe ich auf meinem System (OpenSolaris 2008.11, Asus P5W DH Deluxe-Mainboard, Core 2 Duo 5300, 4 GB RAM) mit einem RAID-Z1 aus 5 Platten mit je einem 1 TB eine Kompressionsrate von 1.00 bis 1.01. Die Kompression ist also aktiviert, aber der Kompressionsfaktor ist immer in einem niedrigen einstelligen Prozentbereich. Ich habe alle Optionen getestet, ob Standard-lzjb oder gzip, das Ergebnis sieht immer ähnlich schlecht aus. So sehe ich zwar, dass das System mit der Kompression bei gzip-9 deutlich mehr beschäftigt ist als wenn ich mit lzjb komprimiere, aber dann bekomme ich beispielsweise einen Faktor von 1.03 statt 1.02 mit gzip.
Und natürlich versuche ich nicht, bereits komprimierte Dateien noch einmal zu komprimieren und bekomme deshalb einen so schlechten Wert. Den meisten Platz brauchen unkomprimierte Audio- und Videodateien, und auch beim Rest der mehreren 10.000 Dateien handelt es sich um "Standarddateien" wie Textdateien, Bilder, pdfs ...
Als Beispiel habe ich eben einen Ordner mit 600 MB an Audiodateien im .wav-Format einmal mit lzjb und einmal mit gzip-9 komprimiert. Mit lzjb hat er gar nicht komprimiert und einen Faktor von 1.00, mit gzip-9 habe ich eine Kompression von 1.02 erreicht. (In Windows bekomme ich mit WinRAR die halbe Dateigröße)
Es ist mir also ein Rätsel, warum ich die Kompression aktivieren kann, sie dann aber trotzdem nicht funktioniert. Ich habe die Sache mit der Kompression mit RAID-Z1 und RAID-Z2 getestet, auf OS 2008.5 und OS 2008.11, mit Dutzenden file systems und allen Kompressionsoptionen, bekomme aber immer das gleiche Ergebnis. Hat jemand nen Vorschlag, was ich noch versuchen könnte oder woran es liegen könnte?
Danke im Voraus,
Beni
-
komprimiert zfs auch nachträglich alles, wenn man auf einen vorhandenen Dateisystem die Kompression anschaltet? Das müsste mal ausprobieren. Wenn ich Zeit habe, werde ich es mal machen, aber leider nur auf USB-Sticks, das sollte aber kein Unterschied sein.
Gruß
-
linus:
Nein, tut es nicht. Allerdings macht ZFS ein copy-on-write, das heisst wenn Du die Kompression einschaltest, werden alle neu geschriebenen Blöcke komprimiert.
Gruss
Dominik
-
gzip und Konsorten sind Entropiecodierer, damit lassen sich auch unkomprimierte Video/Audidaten nicht effektiv komprimieren. Dafuer braucht man Kodiersysteme mit Dekorrelationsalgorithmen (JPEG fuer Bilder z.B.). Das laesst sich aber in ne Disk-Compression nicht einbauen.
Wenn RAR das besser macht liegt das vielleicht daran, dass die quasi-intelligent kodieren, allerdings glaube ich nicht, dass das fuer on-the-fly compression geeignet ist (jedes mal 100% CPU last beim Diskzugriff)
Mfg. Erisch
-
Also dann kann das "Problem" darin liegen, das die Kompression evtl. zu einen spätern Zeitpunkt eingeschaltet wurde und schon Daten auf den Datenträger waren. Dann braucht es sehr viele neue Blöcke, damit was merkt.
Ich habe zumindest gelesen, dass bis zu einen Faktor von 5 bei log-Files drin ist. Ein Kumpel macht das und ist eigenlich sehr zufrieden. Was er erreicht muss ich mal erfragen. Gut reiner Text lässt sich auch mit einfachen Verfahren recht gut komprimieren.
-
mein Post bezog sich eher auf den Ursprungs-Post
-
Die Kompression habe ich immer aktiviert, bevor ich die Dateien kopiere, daran kann es also nicht liegen.
erisch: Dass ich bei solchen Dateien keinen Faktor 2,3 oder 5 erwarten kann, weiß ich, aber die Kompression macht ja fast gar nichts, egal bei welchen Dateien. Ich habe wie gesagt nicht nur Audio- und Videodateien im file system, und trotzdem zeigt er mir bei der compressratio einen Wert von 1.00 an. Weil er selbst Dateien, die sich ziemlich gut komprimieren lassen sollten, mit nur wenigen Prozent komprimiert. Gibt es vielleicht so was wie ne gut geeignete Testdatei zum Download, mit der ich meine Kompressionsrate mit jemand anderem vergleichen könnte?
-
root@sbsubs170 # zfs get compressratio zonedata_sbsubs170/ubs175_oradata
NAME PROPERTY VALUE SOURCE
zonedata_sbsubs170/ubs175_oradata compressratio 2.36x -
Das sind die Werte einer Oracle 10 OLTP Datenbank mit eingeschalteter ZFS compression.
Und hier noch das Zone-Root (Sol10U6) der gleichen Installation:
root@sbsubs170 # zfs get compressratio zonehome_sbsubs170/ubs175_zone
NAME PROPERTY VALUE SOURCE
zonehome_sbsubs170/ubs175_zone compressratio 1.57x -
Gruss
Dominik
-
Gibt es vielleicht so was wie ne gut geeignete Testdatei zum Download, mit der ich meine Kompressionsrate mit jemand anderem vergleichen könnte?
dd if=/dev/zero of=/path/to/testfile bs=1024 count=1048576
gibt dir ne 1GB grosse Datei voll mit Nullen, laesst sich also prima komprimieren.
Mfg. Erisch
-
erisch, danke für den Tipp. Ich habe für diesen Test drei neue Dateisysteme erstellt, ein unkomprimiertes, eines mit der Standardkompression und eines mit gzip-5. Mit zfs get compression bekomme ich entsprechend die Werte compression=off, "on" und "gzip". Ich habe die Testdatei im unkomprimierten Dateisystem erstellt und danach in die zwei anderen kopiert. Und jeweils zeigt er mir eine compressratio von 1.00 an ... ???
-
Bentsch:
Hast auch was reinkopiert? Nur eine dumme Frage, weil ohne was reinzukopieren zeigt er immer 1.00x an
# zfs create tank/test
# zfs set compression=on tank/test
# zfs get compression tank/test
NAME PROPERTY VALUE SOURCE
tank/test compression on local
# zfs get compressratio tank/test
NAME PROPERTY VALUE SOURCE
tank/test compressratio 1.00x -
Gruss
Dominik
-
Keine dumme, eine absolut berechtigte Frage :-) Ja, ich habe die Testdatei in jedes Filesystem einmal kopiert. Hier noch mal die Schritte dieses Tests:
1. Drei Dateisysteme erstellt, eines ohne Kompression, eines mit Standardkompression, eines mit gzip. zfs get compression zeigt die richtigen Werte, also off, on und gzip.
2. Die Testdatei mit dem Befehl dd if=/dev/zero of=/path/to/testfile bs=1024 count=1048576 im unkomprimierten Filesystem erstellt.
3. Von dort per Kopieren und Einfügen in die anderen zwei Dateisysteme eingefügt
4. zfs get compressratio zeigt für alle drei Dateisystem 1.00x an
-
Seltsame Sache. Kann das hier so nachvollziehen (Solaris 10 Update 6):
# dd if=/dev/zero of=/tmp/test.dmp bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
# cp /tmp/test.dmp /tank/test
# zfs get compressratio tank/test
NAME PROPERTY VALUE SOURCE
# ls -al
total 7
drwxr-xr-x 2 root root 3 Feb 2 14:10 .
drwxr-xr-x 3 root root 3 Feb 2 08:58 ..
-rw-r--r-- 1 root root 1073741824 Feb 2 14:10 test.dmp
root@sbsubs180 # du -sh
2K .
# tar cf test.tar /usr/openwin
# zfs get compressratio tank/test
NAME PROPERTY VALUE SOURCE
tank/test compressratio 1.28x -
# rm test.tar
# zfs get compressratio tank/test
NAME PROPERTY VALUE SOURCE
tank/test compressratio 1.00x -
Vielleicht liegt es daran, dass das leere File so stark komprimiert werden kann, dass die Anzeige "unsinnige" Werte ausgeben würde? Evtl. kann da ein Blick in den Sourcecode helfen.
Gruss
Dominik
-
Keine dumme, eine absolut berechtigte Frage :-) Ja, ich habe die Testdatei in jedes Filesystem einmal kopiert. Hier noch mal die Schritte dieses Tests:
1. Drei Dateisysteme erstellt, eines ohne Kompression, eines mit Standardkompression, eines mit gzip. zfs get compression zeigt die richtigen Werte, also off, on und gzip.
2. Die Testdatei mit dem Befehl dd if=/dev/zero of=/path/to/testfile bs=1024 count=1048576 im unkomprimierten Filesystem erstellt.
3. Von dort per Kopieren und Einfügen in die anderen zwei Dateisysteme eingefügt
4. zfs get compressratio zeigt für alle drei Dateisystem 1.00x an
pfiffiges beispiel ;-), /dev/zero ist hier der schluessel
also wenn kompression nicht angeschaltet ist wird ZFS all die bloecke fuer die 0en allokieren und schreiben
aber, wenn kompression angeschaltet ist (per default nur fuer meta daten an) dann ist mit diesem
beispiel alles anders.
Die komprimierung findet im SPA (storage pool allocator) statt, in der write I/O pipeline,
dh. wir nehmen den write, komprimieren den block and da alles 0en sind, kehren wir sofort
wieder zurueck mit einem zero block pointer (kein block allociert/zu schreiben),
dies passiert fuer alle bloecke in dieser 'testfile' datei.
Das resultat ist das wir eine dnode fuer die datei ondisk anlegen welche keine data blocks hat.
die "groesse" der datei ist im data teil znode_phys innerhalb der dnode gespeichert.
hth
frankB
-
Da ich zwar überhaupt keine Ahnung von ZFS habe, aber neugierig bin, möchte ich mal was fragen:
Heisst das, dass die Kompression gar nicht stattfindet, weil das File gar nicht geschrieben, sondern lediglich der Platz allokiert wird?
Claus
-
Da ich zwar überhaupt keine Ahnung von ZFS habe, aber neugierig bin, möchte ich mal was fragen:
Heisst das, dass die Kompression gar nicht stattfindet, weil das File gar nicht geschrieben, sondern lediglich der Platz allokiert wird?
Claus
nicht ganz, es ist sozusagen die "ueber" kompression, es werden in diesem fall in der tat keine user daten blocks
allokiert und geschrieben um komprimierte 0en zu schreiben, wozu auch. jeder block wurde komprimiert mit dem
ergebniss das er keinen platz braucht, ergo wird nur die ondisk dnode fuer die datei allokiert und geschrieben
und die vermeintliche groesse der datei in der ondisk dnode gespeichert, jedoch ohne weitere user daten
bloecke zu belegen. es ist eine datei voller 0en, ein sparse file, lesen davon liefert wiederum nur nullen.
ich wuerde also sagen das topic dieses threads: 'Kompression funktioniert nicht (richtig)'
ist nicht ganz korrekt..in der tat funktioniert sie excellent.
---
frankB
-
Da ich zwar überhaupt keine Ahnung von ZFS habe, aber neugierig bin, möchte ich mal was fragen:
Heisst das, dass die Kompression gar nicht stattfindet, weil das File gar nicht geschrieben, sondern lediglich der Platz allokiert wird?
Claus
nicht ganz, es ist sozusagen die "ueber" kompression, es werden in diesem fall in der tat keine user daten blocks
allokiert und geschrieben um komprimierte 0en zu schreiben, wozu auch. jeder block wurde komprimiert mit dem
ergebniss das er keinen platz braucht, ergo wird nur die ondisk dnode fuer die datei allokiert und geschrieben
und die vermeintliche groesse der datei in der ondisk dnode gespeichert, jedoch ohne weitere user daten
bloecke zu belegen. es ist eine datei voller 0en, ein sparse file, lesen davon liefert wiederum nur nullen.
ich wuerde also sagen das topic dieses threads: 'Kompression funktioniert nicht (richtig)'
ist nicht ganz korrekt..in der tat funktioniert sie excellent.
ich hab das mal mit einem zdb output anschaulich gemacht, 'zdb -dddddd' auf den pool der
die besispiel datei enthaelt _mit_ kompression an:
-- snip --
Object lvl iblk dblk lsize asize type
4 3 16K 128K 128K 0 ZFS plain file (K=inherit) (Z=inherit)
264 bonus ZFS znode
path /testfile
atime Wed Feb 4 10:31:32 2009
mtime Wed Feb 4 10:31:44 2009
ctime Wed Feb 4 10:31:44 2009
crtime Wed Feb 4 10:31:32 2009
gen 30850
mode 100644
size 1073741824
parent 3
links 1
xattr 0
rdev 0x0000000000000000
Indirect blocks:
-- snip --
keine indirekten bloecke allokiert, und 'asize' ist 0
im gegensatz dazu das gleiche beispiel auf mit ausgeschalteter kompression (1MB datei),
'asize' (physisch fuer daten & metadaten belegte bloecke) == 1MB
Object lvl iblk dblk lsize asize type
5 2 16K 128K 1M 1.00M ZFS plain file (K=inherit) (Z=inherit)
264 bonus ZFS znode
path /testfile1
atime Wed Feb 4 10:36:25 2009
mtime Wed Feb 4 10:36:25 2009
ctime Wed Feb 4 10:36:25 2009
crtime Wed Feb 4 10:36:25 2009
gen 31155
mode 100644
size 1048576
parent 3
links 1
xattr 0
rdev 0x0000000000000000
Indirect blocks:
0 L1 1:e0400:400 0:100400:400 4000L/400P F=8 B=31155
0 L0 0:2cc0000:20000 20000L/20000P F=1 B=31155
20000 L0 0:c0000:20000 20000L/20000P F=1 B=31155
40000 L0 0:a0000:20000 20000L/20000P F=1 B=31155
60000 L0 0:80000:20000 20000L/20000P F=1 B=31155
80000 L0 1:80000:20000 20000L/20000P F=1 B=31155
a0000 L0 0:e0000:20000 20000L/20000P F=1 B=31155
c0000 L0 1:a0000:20000 20000L/20000P F=1 B=31155
e0000 L0 1:c0000:20000 20000L/20000P F=1 B=31155
-- snip --
frankB