[RalphS]

Ja, natürlich. Sorry. Ich wollte das auch gar nicht Abrede stellen.

Fürs Länger-Zeit-Archivieren sicherlich prima, und ~3G*B in ~10M*B stopfen klingt - ich möcht sagen -- zu gut um wahr zu sein.

- Ich seh halt nur das Problem in der Daten'haltung'. Da hat man also sein 10MB großes Archiv, welches ~3GB Daten rekonstruieren kann oder können soll und entsprechend ist dann natürlich jedes einzelne Bit significant für die (erfolgreiche und fehlerfreie) Rekonstruktion des Originals.

- Allerdings kippen grad bei dauerhaftem Speichern einzelne Bits schonmal um. Kommt vor, läßt sich nicht vermeiden. Normal merkt man das auch so gut wie nicht, da steht dann in der Textdatei eben statt "Winfuture" "Winfutvre" weil die das letzte Bit des kleinen u (0111 0100) umgekippt war (0111 0101) und nun eben den ASCII-Code für 'v' hatte. Wenn sowas aber in so einem hochkomprimierten Archiv passiert, dann wird das schon wahnsinnig kritisch, und wenn der Algorithmus noch ein, zwei solcher Bitflips mitmacht, irgendwann war's das dann aber trotzdem.

- Kurz, auf optischen Medien wo Bits gefühlt alle paar Minuten umklappen und nach paar Jahren erst gar nicht mehr lesbar sind, würde ich solche Daten dann doch nicht speichern wollen. Ausgerechnet da dann doch lieber mit redundanter Recovery-Information.

[MasterP82]

Microsoft verwendet auch Kompression, Ihr glaubt doch nicht wirklich, dass der KGB Archiver 3GB aus 10MB fehlerfrei wiederherstellen kann
Bitte mal lesen Wikipedia

[Sturmovik]

Na toll, jetzt hast du den Wikipedia-Joker gezogen, da können alle anderen Argumente einpacken, schließlich steht in Wikipedia die Wahrheit™

Was Microsoft als ZIP-Algorithmus verwendet, kann ich nur spekulieren, aber es ist weder schnell, noch effizient.
Andere handelsübliche Algorithmen erzielen da deutlich bessere Kompressionsraten.
Und das, obwohl sich MS damals (unfreiwillig) LZX eingetreten hat, was die cabinet-files schon ganz gut zusammenquetscht.

Die behauptete Kompressionsrate von dem KGB-Dingens klingt ziemlich utopisch, aber es kommt immer auf die zu komprimierenden Daten an. Wenn da haufenweise gleiche Muster drin sind, dann lässt sich das prima quetschen, aber bei ordentlichen Zufallsdaten können die komprimierten Dateien sogar größer werden als das Original.

Angenommen, die 3GB sind reiner Textkram, da kann das mit den 10MB schon hinkommen.

---

Ich fahr grad nen kleinen Test aller hier installierten Packer (gzip,bzip2,xz,zpaq)
Erstes Ergebnis: 1GB Zufallsdaten => alle Packer versagen, auch mit extremen Einstellungen werden die "komprimierten" DAteien ~10% größer als das Original.

Test2 läuft grade mit nem 13GB großen Betriebssystemimage. Mal schaun was da rauskommt. Wenn ich ganz viel Zeit hab, zieh ich mir noch den KGB runter. Aber soviel erwarte ich von nem seit 10 Jahren nicht mehr weiterentwickelten Programm nicht.

Edit: grad gesehen, zpaq ist wie vermutet ne Weiterentwicklung von dem PAQ6. Also muss ich gar nicht nachschaun, wie ich den KGBler zum compilen überrede^^ (nein, ich hab jetzt keine Lust wegen dem Quatsch Windows zu installieren)

Dieser Beitrag wurde von Sturmovik bearbeitet: 01. September 2016 - 21:30

[KingGozza]

Ich wollte hier keine Diskussion über den KGB losbrechen, ich kann nur aus meiner Erfahrung sprechen, die positiv gegenüber dem KGB ist.
Solche stark komprimierten Archive würde ich sicher auch nicht auf einen optischen Datenträger packen, was durch die erreichte Kompressionsrate nicht nötig ist.

Ich hab viele Kompressionssoftware durch und irgendwie, kam keins, was die Kompression betrifft, nichts hinter KGB und dem PAQ6/7 hinter her...
Sicher gibt es nachteile, wie eben die Zeit, die investiert werden muss aber neben der Kompressionsrate, ist für mich noch ein riesen Pluspunkt, der geringe RAM-Verbrauch.
7z und WinRAR fressen mir den RAM weg, da gibt es keine bremse, was mich sehr stört, besonders wenn ich es eben sehr klein haben möchte.

Und natürlich hängt das von den zu komprimierenden Dateien ab.
Ein Windows 7 DVD Image bekommst du zu Hauf im Internet, mit dem KGB komprimiert, einfach nach Windows 7 DVD 10MB suchen.
Und es lässt sich alles fehlerfrei entpacken, ist halt auch eine Frage der Zeit.

[Sturmovik]

Ich glaube mich zu erinnern, dass man 7zip auch in Sachen Mem-Use und Threads begrenzen kann. Aber nur auf der Kommandozeile, nicht in der GUI.

Den Test fahr ich grad nur aus rein persönlichem Interesse und für meinen häufigsten Use-Case. zpaq wird da wohl wegen der Zeitdauer verlieren, egal wie die Kompressionsrate aussieht.

Zum KGB: Ich glaub dir das schon mit dieser krassen Kompressionsrate. Ich hab mich ja nicht umsonst früher™ gewundert, warum Programme von gewissen FTP-Servern so klein gepackt waren, aber beim Entpacken die Festplatte gesprengt haben

Und wers mal schnell ausprobieren will, dem empfehle ich 42.zip
Disclaimer: vor dem Entpacken die Beschreibung lesen, ich hafte nicht für übergelaufene Platten
https://www.unforgettable.dk/
https://de.wikipedia...iki/Archivbombe

Dieser Beitrag wurde von Sturmovik bearbeitet: 01. September 2016 - 21:58

[RalphS]

Und aktuelle ZPAQ-Implementierungen gibts laut Hersteller auch als 32bit-Varianten, die dann (wenn ich das nicht falsch verstanden hab) maximal 2 Kerne und 2GB RAM belegen können.

(Wobei ich schon der Meinung bin, daß das zu arg eingeschränkt ist, aber egal.)

Ich persönlich hab schon seit längerem die Nase... nicht voll, aber so halbvoll in bezug auf komprimierte Daten.

Denn die muß man ja noch entpacken vorm Verwenden. Das dauert Zeit und kostet Plattenplatz - also ganz genau das, was man ja nicht hatte und weswegen man komprimieren wollte.

Was bleibt, ist Dateisystemkompression - soweit unterstützt -- sowie Deduplizierung - soweit es Dateisystem und Ressourcen hergeben, wobei natürlich Dateisystemkompression weitaus 'preiswerter' zu haben ist in bezug auf Ressourcenhunger.

NTFS kann das, ZFS kann es auch, und ich geh mal stark davon aus daß zumindest irgendein™ Linux-Dateisystem das auch kann.

Dann kann man nämlich seine Archivdaten sofort verwenden, ohne daß man erst anfangen müßte, sich sein 2.9GB .iso.rar irgendwo als 3.1GB .iso hinzuschreiben (jetzt hat man's doppelt) und dann *dieses* vielleicht auch noch auspacken zu müssen (falls es nicht zu mounten geht => ja, das ist wohl eher unwahrscheinlich).

Eine Ausnahme sind natürlich Pakete, die nicht nur aus einer (oder ein paar) Datei(en) bestehen. Das hat dann aber eher was mit ein bissel Ordnung auf dem Datenträger zu tun. Sagen wir Microsofts kumulative Updates. Die werden als MSU vertrieben. Da kann man sich die .cab-Dateien rausholen (der Rest wird eh nicht unbedingt gebraucht). Aber wenn man jetzt die .cab-Dateien auch noch auspacken würde, hätte man ganz flink Tausende und Abertausende Ordner und Dateien in klein und noch kleiner. Könnte man so auch installieren - muß man aber nicht.

[Sturmovik]

Wenn die Linuxer schon beim ZFS abgucken, dann richtig. Natürlich gibts bei btrfs die Mountoption 'compress'
Oder halt SquashFS. Oder irgendwas anderes.

Aber Dateisystemkompression is bäh, klaut mir viel zu viel Performance. Bei den Plattenpreisen stopf ich da lieber noch ne Spindel nach. Ansonsten hilft auch aufräumen.

Interessant wird Kompression da, wo die Übertragungsraten geringer sind als die Kompressionsgeschwindigkeit. On the fly komprimiert woanders ablegen, z.B. auf nem optischen Medium oder übers Netz. Unter Windows keine Ahnung, aber tar {z,j,J} durch SSH tunneln und am anderen Ende mit cat empfangen kann bei dünnen Leitungen Wunder wirken.

---

Aber um mal back2topic zu kommen:
Für den Anwendungsfall würde ich am besten zu 7zip greifen mit LZMA und maximaler Kompression.
Das schreibt auch noch genug Wiederherstellungsinfos um ein paar verkippte Bits auszugleichen.

Dieser Beitrag wurde von Sturmovik bearbeitet: 01. September 2016 - 22:38

[KingGozza]

@RalphS "Und aktuelle ZPAQ-Implementierungen gibts laut Hersteller auch als 32bit-Varianten, die dann (wenn ich das nicht falsch verstanden hab) maximal 2 Kerne und 2GB RAM belegen können."

Das hast du genau richtig verstanden.
Das Thema mit PAQ ist nur wesentlich komplexer. Die PAQ Versionen sind in dem Sinne keine Weiterentwicklung sondern immer andere Ansätze zu komprimieren, weshalb sie auch untereinander inkompatibel sind.
Es gibt massig Forks der verschiedenen Versionen, wobei PAQ8* darunter die beliebteste ist, da gibt es ganze Foren drüber.

Das Problem an der ganzen Sache ist, dass PAQ im allgemeinen sehr viel Zeit benötigt aber auch sehr viel RAM fressen kann (siehe paq8pxd v18, was bis zu ~10GB braucht).

Durch die unterschiedlich Algorithmen, hat jeder Fork seine Vor- und Nachteile.
So ist der neuste Fork von PAQ8 nicht für .WAV oder .JPG Dateien zu gebrauchen (vielleicht überspitzt geschrieben).
Auch ZPAQ hat da so seine Probleme, mit einigen Dateitypen.

Wie schon geschrieben, ist es ein großes und komplexes Thema, mit dem ich mich schon lange beschäftige und wenn man von allen PAQs die Vor- und Nachteile erörtern möchte, kann man da schon ein ganzes Buch zu schreiben.
Aber im schnell Verfahren, einen guten Allrounder zu nennen, ist recht einfach, denn das ist PAQ7. Will man einfach einen speziellen Dateityp komprimieren, so muss man sich in die Materie einlesen.

Wie schon geschrieben, ich beschäftige mich schon sehr lange damit, ich habe viele Forks getestet und bin einfach zu dem Ergebnis gekommen, das PAQ7 die beste Komprimierung verschiedener Dateitypen hin bekommt und das zu einer "annehmbaren" Zeit (was man eben investieren will an Zeit).

Ich freue mich aber, einigen hier eine Alternative aufgeboten zu haben und hoffe auch auf eine größere Nutzerbasis.
Wenn Interesse da ist, einfach nach PAQ suchen und testen, was für eure Bedürfnisse passender ist, ich würde mich auch über weitere Erfahrungsberichte sehr freuen.

Nun schweife ich aber ab.

Back to Topic:
Es gibt sehr viele Arten zu komprimieren und auch viele verschiedene Ergebnisse.
Hätte ich nicht PAQ empfohlen, wäre es sicher auch 7z gewesen, wie es hier schon erwähnt wurde.
Letztendlich kommt es auf dein System an und wie viel Zeit du darin investieren möchtest, deine Dateien zu komprimieren.

Dieser Beitrag wurde von KingGozza bearbeitet: 02. September 2016 - 11:14