Wie mit pig-zee gepackte Ordner wieder entpacken?

[CyborgBeta]

Moin,

ich "zippe" ein Verzeichnis mit: (https://zlib.net/pigz/)

function pigzdc {
    folder=$(basename "$1")
    tar cvf - "$folder" | pigz > "$folder".tar.gz
}

Das funktioniert auch super, es ist Lichtjahre schneller als zip (was mich gewundert hat) und das Ergebnis nur minimal größer.

Frage: Wie ist der offizielle Weg, um so ein Archiv wieder zu entpacken?

tar xvzf <file.tar.gz> funktioniert leider nicht.

 

[oicfar]

Hast du mit:

pigz -dc <file.tar.gz> | tar xvf -

versucht?

 

[CyborgBeta]

versucht?

Ja, damit geht es. Dann habe ich aber die Frage, weshalb es nur mit tar nicht funktioniert?

 

[oicfar]

@CyborgBeta ChatGPT sagt ..

Das Problem ist, dass der von dir erstellte Befehl pigzdc die Daten in einer bestimmten Reihenfolge mit tar und pigz kombiniert und ein gzip-komprimiertes Archiv erzeugt, das sich nicht mit einem Standard-tar xvzf entpacken lässt. Das liegt daran, dass tar direkt auf die Daten zugreift, während pigz als externer Kompressor genutzt wird.

Um ein solches Archiv wieder zu entpacken, musst du pigz explizit für die Dekompression verwenden.

 

[dms]

Frage: Wie ist der offizielle Weg, um so ein Archiv wieder zu entpacken?

.. die Man-Pages bemühen damit man versteht was man macht

 

[CyborgBeta]

Eh, jetzt bin ich nicht schlauer.

Ergänzung (2. Januar 2025)

ChatGPT sagt

Frag mal, ob pigz ein gzip Archiv erstellt oder nicht.

Ergänzung (2. Januar 2025)

Man-Pages

The compressed data format generated is in the gzip, zlib, or single-entry zip format using the deflate compression method. The compression produces partial raw deflate streams which are concatenated by a single write thread and wrapped with the appropriate header and trailer, where the trailer contains the combined check value.

https://linux.die.net/man/1/pigz

Ok, daran wird es wohl liegen, dass tar das nicht kann.

 

[dms]

, es ist Lichtjahre schneller als zip (was mich gewundert hat)

..

is a fullyfunctional replacement for gzip that exploits multiple processors and multiple cores

 

[CyborgBeta]

Ja und? Es ist ungefähr 10-mal schneller. Vorher: 1 Minute, nachher: 5 Sekunden.

 

[gaym0r]

@CyborgBeta
Er hat dir erklärt warum es schneller ist, da es dich gewundert hatte.

 

[Der Lord]

weshalb es nur mit tar nicht funktioniert

weil du es auch vorher nicht nur mit tar gepackt hast.

du pipest die ausgabe von tar ja zuvor auch nach pigz (tar ... | pigz ...) . entpacken dann also genau umgekehrt.

das ist halt das tolle am KISS-prinzip bei linux: viele kleine tools die sich aufs wesentliche beschränken und dann prima kombinierbar sind.

 

[oicfar]

Frag mal, ob pigz ein gzip Archiv erstellt oder nicht.

pigz file oder pigz -c file > custom_name.gz

Das Ergebnis ist eine Datei namens file.gz, die genau dem entspricht, was gzip erstellen würde.

 

[CyborgBeta]

Das Ergebnis ist eine Datei namens file.gz, die genau dem entspricht, was gzip erstellen würde.

Das stimmt, ist aber nur für einzelne Dateien anwendbar.

Ergänzung (2. Januar 2025)

Oder noch einmal anders: tar --use-compress-program="pigz -r" -cf test-data-1.tar.gz test-data oder tar cf - test-data | pigz > test-data-1.tar.gz (wobei test-data ein Verzeichnis ist) müssen irgendetwas anderes machen als pigz -c file > custom_name.gz (wobei file eine Datei ist).

Ergänzung (2. Januar 2025)

Er hat dir erklärt warum es schneller ist, da es dich gewundert hatte.

Ja schon, das erklärt aber noch nicht den signifikanten Geschwindigkeitsunterschied, imho.

 

[oicfar]

Am Ende bleibt die Frage, was das Ziel ist?

1. Häufig und Verzeichnisse und Dateien ins Archive-Packen?
2. Kompatible Archive zu anderen Tools erstellen?

 

[dms]

Wie wurde ich denn da vorgehen?

Erstmal mehr Rohmaterial packen und mit dem Monitoringtools meines BS schauen oder

aus der Doku

-p --processes n
Allow up to n processes (default is the number of online processors

mal schauen wie es so mit -p 1 läuft - kannst alles an deinem PC machen - was weiß ich denn schon zu deiner Plattform

 

[CyborgBeta]

Am Ende bleibt die Frage, was das Ziel ist?

1. Häufig und Verzeichnisse und Dateien ins Archive-Packen?
2. Kompatible Archive zu anderen Tools erstellen?

Eigentlich beides. Ich kann das pigz Resultat für Ordner auch mit 7zip auf Windows entpacken, das ist kein Problem.

 

[oicfar]

@CyborgBeta Welchen Use-Case hast du da, dass die Performance "wichtig" ist? Tauschst du die Archive zwischen Linux und Windows aus? Wie häufig erstellst du die und wie groß sind die Datenmengen?

Format	Kompression	Geschwindigkeit (Kompression)	Geschwindigkeit (Dekompression)	Kompatibilität
.zip	Mittel	Schnell	Sehr schnell	Sehr hoch (nativ überall)
.tar.gz	Mittel	Schnell	Schnell	Hoch (Linux nativ, Windows mit Tools)
.tar.bz2	Hoch	Langsam	Mittel	Hoch (Linux nativ, Windows mit Tools)
.tar.zst	Mittel-Hoch	Sehr schnell	Sehr schnell	Mittel (benötigt zstd)
.7z	Sehr hoch	Mittel	Mittel	Hoch (7-Zip erforderlich)

 

[CyborgBeta]

@oicfar Ich behaupte jetzt einfach mal, pigz ist wegen der Parallelität auf einem Linux 12-Core-Computer schneller als Zstd.

Use-Case: Ich muss regelmäßig Backups von einem Ordner erstellen, um ggf. zu einem früheren Zustand zurückzukehren können (das (so ein "Rollback") kommt nicht allzu häufig vor, die Backups müssen aber gemacht werden).

In diesem Ordner ist ein bunter Mix:

• Executables (auch große)
• Textdateien
• bereits gepackte Textdateien
• Datenbankdateien
• bestimmte, vorcompilierte Libraries

Größe: ca. 2,3 GB
Gepackte Größe: ca. 333 MB

Architektur:

product: Intel Xeon Processor (Skylake, IBRS, no TSX)
vendor: Intel Corp.
physical id: ...
bus info: ...
version: ...
slot: CPU 0
size: 2GHz
capacity: 2GHz
width: 64 bits
configuration: cores=8 ... threads=8

memory: 16 GB DIMM RAM

2. Use-Case: Gelegentlich Dateien zwischen Linux und Windows (bidirektional) austauschen.

 

[oicfar]

@oicfar Ich behaupte jetzt einfach mal, pigz ist wegen der Parallelität auf einem Linux 12-Core-Computer schneller als Zstd.

Wenn am Ende man pro Tag 1+h an Zeit spart, dann gehe ich da mit. Ansonsten sage ich, dass das vernachlässigbar ist.

Use-Case: Ich muss regelmäßig Backups von einem Ordner erstellen, um ggf. zu einem früheren Zustand zurückzukehren können (das (so ein "Rollback") kommt nicht allzu häufig vor, die Backups müssen aber gemacht werden).

In diesem Ordner ist ein bunter Mix:

• Executables (auch große)
• Textdateien
• bereits gepackte Textdateien
• Datenbankdateien
• bestimmte, vorcompilierte Libraries

Größe: ca. 2,3 GB
Gepackte Größe: ca. 333 MB

Das ist nicht groß.

Ich habe ein ca. 40GB Thunderbird Profil, der gebackup wird.

Mit robocopy mal die Änderungen kopieren und dann wird das dann noch als Archiv abgelegt. Läuft dann aasynchron und ob ich dann mit 16, 8 oder 2 Cores es packe, ist mir nicht so wichtig.

Wichtiger ist mir zuerst, dass die Änderungen schneller kopiert werden.