Pro-Linux Kommentare: Schnell komprimieren mit lzop

Re[3]: nice

Tue, 15 May 2012 21:41:25 +0200

1. Hier geht es nicht um Parallelverarbeitung sondern um Hintergrundjobs 2. Ob 1h oder 4h ist nicht egal 3. Die Plattenzugriffe dürften mit xz (was du ja unten selbst vorschlägst) keine Rolle spielen 4. Bei nice 20 werden keine "Hochleistungszeitfenster" verschwendet 5. Threats treten hoffentlich überhaupt nicht auf

Re[3]: md5sum

Tue, 15 May 2012 17:51:35 +0200

> Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels > tee vor dem Packen sondern anschliessend mit > > gzip -cd test.gz | md5sum > > Man will ja wissen ob die Daten korrekt gepackt wurden und nicht ob sie korrekt > dem Packer übergeben wurden. Wenn du eine Prüfsumme von den komprimierten Daten bildest (und prüfst) weißt du doch nicht ob der Komprimierer korrekt...

Re: So läufts hier

Tue, 15 May 2012 17:40:22 +0200

> Wenn es sich irgendwie vermeiden läßt umgehe ich Snapshots auf LVM-Ebene - das gibt "LVM-Fragmentierung" Wenn man nicht gerade während eines Backups ein "normales" LV anliegt, gibt es keine Fragmentierung. Außerdem kann man die SS-LVs auch auf ein extra PV legen.

So läufts hier

Tue, 15 May 2012 06:26:43 +0200

Ich arbeite ähnlich, aber die Unterschiede sind sicher interessant: Eine zu sichernde Partition(*1) fülle ich erstmal mit Nullen damit das Image wirklich klein wird, z.B. mount /dev/whatever /mnt && cat /dev/zero >/mnt/zero ; rm /mnt/zero && umount /mnt Images werden dadurch MASSIV kleiner. Selbst frisch installierte Partitionen werden bei gzip anschliessend 20-40% kleiner. Bei lange genutzten...

Re[2]: nice

Tue, 15 May 2012 06:16:09 +0200

Hätte man besser nicht zusammenfassen können. Ein Nachtrag: Wer auf einem Vielbenutzer-VM-System unnötig parallel arbeitet verschwendet nunmal Resourcen. Ob der lownice-Job nun mit einem Threat in vier Stunden fertig ist oder mit vier Threats in einer Stunde - das ist egal. Wichtiger ist daß der Viererthreat mehr RAM belegt, mehr Plattenzugriffe in kürzerer Zeit erzeugt usw. D.h. es bleiben...

Re[2]: md5sum

Tue, 15 May 2012 06:12:07 +0200

Sehr wichtiger Hinweis: IMMER nochmal mit md5sum eine Prüfsumme bilden!!! rzip und lzip haben z.B. in einigen Versionen/Compileroptionen Bitfehler produziert. Und defekte Hardware - ein überraschend häufiges Problem - macht das sowieso immer. Und auch wichtig: Die Prüfsumme extra und nicht inline bilden, also nicht mittels tee vor dem Packen sondern anschliessend mit gzip -cd test.gz | md5sum...

Re: nice

Mon, 14 May 2012 20:30:04 +0200

für die .bash_aliases: alias lownice='ionice -c 3 nice -n 20'

Re: md5sum

Mon, 14 May 2012 19:04:01 +0200

Sollte natürlich heißen: md5sum > /backup/vmname.img .md5

nice

Mon, 14 May 2012 18:42:06 +0200

> Haben Sie schon einmal versucht, 40 GByte mit gzip zu komprimieren? Das dauert > (fast) ewig, die CPU wird heiß und Ihr Server, wenn er nicht gerade im Leerlauf > läuft, reagiert plötzlich nur noch träge. träge? -> man nice

md5sum

Mon, 14 May 2012 18:39:47 +0200

Wer einem solch unbekannten Programm nicht ganz traut, hängt noch ein md5sum mit rein: dd if=/dev/vg0/vmname_snap bs=4M | tee >(md5sum > /backup/vmname.img) | lzop -c > /backup/vmname.img.lzo (die >(...)-Syntax ist allerdings bash-spezifisch!)

Re: LZOP - Lempel Ziv Oberhummer Packer

Mon, 14 May 2012 18:20:06 +0200

Siehe hier: http://www.oberhumer.com/opensource/ Jahrelange solide Systemarbeit. Bewundernswert. 8)

LZOP - Lempel Ziv Oberhummer Packer

Mon, 14 May 2012 18:10:31 +0200

Klingt irgendwie nach der Wildsau von Graz, der den UPX-Packer geschrieben hat. ;)

Re: Warum dd?

Mon, 14 May 2012 17:40:32 +0200

Die Macht der Gewohnheit ... Ich habe es gerade schnell getestet, cat spart tatsächlich nochmals ein paar Sekunden. Danke für den Hinweis!

Re: Es gibt noch mehr Alternativen

Mon, 14 May 2012 17:39:59 +0200

LZ4 und Snappy sollten gleich schnell und gleich gut komprimieren, sind jedoch zusätzlich bei der Dekompression bis zu doppelt so schnell. (kleiner Benchmark des LZ4 machers: https://code.google.com/p/lz4/) Snappy ist von Google und für 64bit Betriebssysteme optimiert. Bei 32bit ist jedoch LZ4 bei weitem schneller. Leider keine Ahnung ob es dafür schon fertige Pakete gibt.

Re: Warum dd?

Mon, 14 May 2012 17:20:34 +0200

Habe auch nie verstanden, warum man bei Block-Devices immer 'dd' benutzt. Vielleicht sehe ich aber auch nur nicht den Unterschied zwischen dd und cat (abgesehen von Blockgrößen und ähnlichem Kram, von DD den ich aber eher hinderlich finde). Persönlich benutzte ich gerne 'pv' um Block-Devices auszulesen, da man da noch ne schicke Fortschrittsanzeige mitbekommt.

Re: RAR?

Mon, 14 May 2012 16:46:33 +0200

Das macht sich rar.

Re: Es gibt noch mehr Alternativen

Mon, 14 May 2012 16:45:46 +0200

7z und peazip nicht zu vergessen.

Warum dd?

Mon, 14 May 2012 16:19:49 +0200

Warum dd? dd umgeht einige Optimierungen beim Zugriff indem es direkt RAW auf das Device-Zugreift, ein normales "< " oder ein cat sollte noch einmal schneller sein und man spart sich das herausfinden der "korrekten" Blockgröße.

RAR?

Mon, 14 May 2012 16:19:45 +0200

Und wo ist rar?

Es gibt noch mehr Alternativen

Mon, 14 May 2012 15:28:56 +0200

Neben gzip, bzip2 und lzop, sollte man auch unbedingt lzip und xz Utils ausprobieren. Insbesondere mit lzip haben wir sehr gute Erfahrungen gemacht, wenn es um Speed versus Compression geht.

Re: Typo

Mon, 14 May 2012 14:44:11 +0200

Gängige Kompressionsalgorithmen sind generell besser als naives Run-Length-Encoding. Das versucht man zu minimieren, indem man die virtuelle Disk als Sparse File anlegt oder komplett mit Nullen initialisiert. Aber selbst wenn mal alles voll ist, ist lzop trotzdem noch viel schneller als die anderen :)

Re: Typo

Mon, 14 May 2012 14:34:58 +0200

Danke, wurde korrigiert. Cheers, demon

Re[2]: Typo

Mon, 14 May 2012 14:25:19 +0200

Ja, der Sinn ist geradezu diametral entgegengesetzt... Schön, dass ich helfen konnte.

Re: Typo

Mon, 14 May 2012 14:21:59 +0200

Puh danke, ich hätte den Satz sonst nämlich nicht verstanden mit dem Schreibfehler ...

Typo

Mon, 14 May 2012 14:10:42 +0200

Ein kleiner Fehler ist im Text versteckt: "Der KVM-Host reagiert auch dann noch zufriedenstellen d , wenn gerade ein Backup läuft, der Platzbedarf des Backups ist OK, der Zeitaufwand ebenso." Interessant wäre es auch gewesen, mal zu sehen wie sich ein per Hand implementiertes Run-Length-Encoding schlägt. Ich nehme an, dass bei Plattenimages viele Wiederholungen (beispielsweise Nullen)...