bzip2 mit Brechstange?
Sieghard Schicktanz
Ich muß sagen, ich bin jetzt schon etwas konsterniert.
Ich habe jetzt viermal (_4_ mal) versucht, ein Verzeichnis zu konservieren,
mittels tar und "nachgeschaltetem" bzip2. Zugegebenermaßen ein einigermaßen
umfängliches Verzeichnis, gute 2 GB an Umfang. Sollte aber kein
prinzipielles Problem sein.
Aber: Dabei wurde mir viermal (_4_ mal) die Maschine mitten in der Arbeit
_hart_ abgeschaltet - Strom weg, Netzteilabschaltung durch _Überlast_!
Das Netzteil ließ sich erst nach Trennen durch den Netzstecker wieder zum
Einschalten herbei, das war also _keine_ reguläre Abschaltung!
Grade eben habe ich das Verzeichnis mit derselben Methode, nur statt bzip2
mit gzip, komprimiert - _ohne_ Problem! Auch mehrfaches Hin- und Herkopieren
von Dateien mit mehreren GB Größe klappen ohne weiteres.
Dabei kam der Ausstieg von bzip2 keineswegs erst gegen Ende, wo evtl. eine
kritische Dateigröße (2 GB) erreicht worden sein könnte, das passierte schon
bei lediglich knapp 200 bis gut 300 MB.
(Das ist allerdings das erstemal, daß ich so einen Brocken mit bzip2
verarbeiten wollte, sonst waren das immer bloß ein paar MB. Mit gzip habe
ich schon früher größere Sachen komprimiert...)
Was ist denn _da_ faul? Ist da was bekannt, daß bzip2 bei umfangreichen Jobs
Probleme hat?
Ich habe vor kurzem auf glibc 2.3.5 aktualisiert, bzip2 meldet sich wie
folgt: bzip2, a block-sorting file compressor. Version 1.0.2, 30-Dec-2001.
Ist das dafür etwa zu alt?
(tar ist neuer: tar (GNU tar) 1.15.1 vom 22.2.2005)
Da der Effekt hundertprozentig reproduzierbar zu sein scheint, würd' ich
jetzt schon gerne wissen, ob das bzip(2) für solche Zwecke besser zu meiden
ist. (Nein, weitere Versuch stell' ich damit nicht mehr freiwillig an - ich
brauch' meine Maschine und meine Daten zum Arbeiten!)
Gespannt auf Antworten wünsch' ich dann erstmal
Einen Guten Rutsch
ins Neue Jahr!
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
--
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
- acht zwei fuenf vier sieben Achmuehle / Eurasburg
mailto:Sieg...@Schicktanz.schs.de
-----------------------------------------------------------
Werner Flamme
> Hello
Danke gleichfalls ;-)
>
> Ich muß sagen, ich bin jetzt schon etwas konsterniert.
>
...
>
> Was ist denn _da_ faul? Ist da was bekannt, daß bzip2 bei umfangreichen Jobs
> Probleme hat?
...
> Da der Effekt hundertprozentig reproduzierbar zu sein scheint, würd' ich
> jetzt schon gerne wissen, ob das bzip(2) für solche Zwecke besser zu meiden
> ist. (Nein, weitere Versuch stell' ich damit nicht mehr freiwillig an - ich
> brauch' meine Maschine und meine Daten zum Arbeiten!)
>
> Gespannt auf Antworten wünsch' ich dann erstmal
>
> Einen Guten Rutsch
> ins Neue Jahr!
Zu spät, bin schon gerutscht ;-)
Sieghard,
mit bzip2 habe ich ähnliche Erfahrungen gemacht. Wir hatten auf unseren
SAP-Linux-Servern das Backup auf "komprimiert" gestellt und "compress"
zeigte als Symlink auf bzip2 statt auf gzip. Am nächsten Morgen waren dann
SAP- und Maschinenlogs voll von Timeoutfehlern... Nachdem wir den Symlink
geändert hatten, trat kein einziger dieser Fehler mehr auf.
Die zu sichernden Daten waren etwa 2 Dutzend Files zu je max. 2 GB.
Insofern vermute ich stark, dass bzip2 Performanceprobleme hat. Es war
genau Dein "bzip2, a block-sorting file compressor. Version 1.0.2,
30-Dec-2001.".
HTH,
Werner
Heike C. Zimmerer
> Ich habe jetzt viermal (_4_ mal) versucht, ein Verzeichnis zu konservieren,
> mittels tar und "nachgeschaltetem" bzip2. Zugegebenermaßen ein einigermaßen
> umfängliches Verzeichnis, gute 2 GB an Umfang. Sollte aber kein
> prinzipielles Problem sein.
>
> Aber: Dabei wurde mir viermal (_4_ mal) die Maschine mitten in der Arbeit
> _hart_ abgeschaltet - Strom weg, Netzteilabschaltung durch _Überlast_!
Dann ist das Problem die Last. "While :; do:; done" dürfte dasselbe
Ergebnis haben.
> Was ist denn _da_ faul? Ist da was bekannt, daß bzip2 bei umfangreichen Jobs
> Probleme hat?
bzip ist rechenintensiver als gzip; das ist schon alles. Die paar
Pausen beim I/O-Zugriff langen halt bei gzip gerade noch. Weshalb soll
ein Abschalten des Netzteils ein bzip-Problem sein?
Wenn dein Netzteil nicht abkann, dass die CPU längere Zeit unter
Vollast läuft, ist das nicht die Schuld des Programms.
> Da der Effekt hundertprozentig reproduzierbar zu sein scheint, würd' ich
> jetzt schon gerne wissen, ob das bzip(2) für solche Zwecke besser zu meiden
> ist.
Das ist ein Fehler im Hardware-, nicht im Software-Design.
Gruß,
Heike
Sieghard Schicktanz
Du schriebst am Fri, 6 Jan 2006 10:30:39 +0100:
> > Ich habe jetzt viermal (_4_ mal) versucht, ein Verzeichnis zu
> > konservieren, mittels tar und "nachgeschaltetem" bzip2. Zugegebenermaßen
...
> > Aber: Dabei wurde mir viermal (_4_ mal) die Maschine mitten in der
> > Arbeit _hart_ abgeschaltet - Strom weg, Netzteilabschaltung durch
...
> Wenn dein Netzteil nicht abkann, dass die CPU längere Zeit unter
> Vollast läuft, ist das nicht die Schuld des Programms.
Wie später leider festgestellt (und hier gepostet) konnte es das tatsächlich
nicht mehr...
Die Versuche mit bzip2 fielen grade in die Anfangszeit seiner Endphase...
Sorry, falls das zur Verunsicherung führte.
Inzwischen ist klar, daß bzip2 nix dafür konnte.