Tar Archiv auf SMP CPUs beschleunigen?

[linuxhelp]

Hallo

mal eine Frage, gibt es die Möglichkeit # tar -cvf archiv.tar ordner
auf einem Multicore-SMP PC (Phenom-X4) zu starten das alle Kerne
von tar genutzt werden? laut htop nur jeweils eine CPU (-Lenny-SMP-KERNEL)

[Danielx]

Nein, denn tar wurde nicht mehrfädig programmiert.

Gruß,
Daniel

[mistersixt]

Bei "tar" ist vermutlich aber auch nicht die CPU der Flaschenhals, sondern die Platte, so dass Du I/O-Wait hast. Insofern bringt ein "tar" mit Threads vermutlich rein gar nichts. Wenn Du es auch noch zippen willst, dann kann ich pbzip (parallel bzip2) empfehlen - dort werden alle CPUs zum Packen herangezogen und es entsteht ein normale bz2-Archiv, so dass man es auch mit dem "normalen" bzip2 wieder entpacken kann. Wenn man dann 16 oder 32 Kerne hat, geht das Packen wie geschmiert !

Gruss, mistersixt.

[Colttt]

ich finde es irgendwie schade/komisch das solche standardprogramme wie gzip, tar, etc (halt die ganzen GNU-Tools) nicht auf SMP ausgelegt sind, komisch deswegen da grade damals Linux/Unix auf SMP-maschienen lief. da wäre es doch naheliegend dies auch gleich entsprechend so zu programmieren, oder es jetzt zumindest schon so umwandeln wenn man eine neue version davon rausbringt.

oder seh ich da etwas blauäugig??

[mistersixt]

Na ja, gibt es doch quasi schon hier und da, pbzip beispielsweise, parallel gzip auch, bei "tar" macht es halt eher keinen Sinn, 7-zip kann auch Threads, ...

Gruss, mistersixt.

[schorsch_76]

*Erwache mein verschütteter Thread zum Leben*

Hallo Debianuser, da ich grade ein ähnliches Problem hatte möchte ich euch auf die Lösung aufmerksam machen!

Code: Alles auswählen

tar cf myfile.tar.bz2 --use-compress-prog=pbzip2 dir_to_com‐press/

Endlich geht das

Gruß

schorsch

[yeti]

ich finde es irgendwie schade/komisch das solche standardprogramme wie gzip, tar, etc (halt die ganzen GNU-Tools) nicht auf SMP ausgelegt sind, komisch deswegen da grade damals Linux/Unix auf SMP-maschienen lief. da wäre es doch naheliegend dies auch gleich entsprechend so zu programmieren, oder es jetzt zumindest schon so umwandeln wenn man eine neue version davon rausbringt.

Tar weiß nicht wo es den Header und die Daten der 2ten zu packenden Datei im Ausgabefile hinsetzen soll bevor nicht die ertse Datei komplett verpackt ist. Warum sollte man das threaden? Damit Thread-2 auf das Fertigwerden von Thread-1 warten muß? Dann reicht auch 1 Thread der sich nacheinander um diese Sachen kümmert... den Gang entlang, dann rechts, die Treppe rauf... jeder nur 1 Kreuz!
...und bei vielen anderen der GNUtilities greifen ähnliche Überlegungen.

oder seh ich da etwas blauäugig??

Grübel einfach mal 'n bissl drüber nach, was die Befehle/Programme an Aktionen im Rechner auslösen und welche davon sich nicht sinnvoll parallelisieren lassen.

[peschmae]

Tar weiß nicht wo es den Header und die Daten der 2ten zu packenden Datei im Ausgabefile hinsetzen soll bevor nicht die ertse Datei komplett verpackt ist. Warum sollte man das threaden? Damit Thread-2 auf das Fertigwerden von Thread-1 warten muß? Dann reicht auch 1 Thread der sich nacheinander um diese Sachen kümmert... den Gang entlang, dann rechts, die Treppe rauf... jeder nur 1 Kreuz!

Das liesse sich schon threaden. Nachzugucken wie gross die zweite Datei ist, ist ja kein Problem. Der Punkt ist vielmehr, dass es nichts bringt weil Tar dadurch nicht schneller wird - das langsamste ist eh das Daten lesen und schreiben, nicht das Ausfüllen von Headern und eine kleine Checksumme.

MfG Peschmä