• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[solved] TAR: Probleme mit dem Entpacken von großen Dateien

U

uli42

Hallo allerseits,

eigentlich dachte ich bis vor kurzem, ich hätte die meisten Dinge "im Griff". Nun zweifle ich aber doch recht massiv an mir. Hier der Hintergrund: Ich habe eine große Datei (10 GB), möchte die in einem TAR verpacken, anschließend wieder auspacken und da dann möglichst die gleiche Datei vorfinden wie am Anfang.

Damit das halbwegs schnell testbar ist, teste ich momentan mit sogenannten "sparse files". Das sind Dateien mit Löchern. Die kann man schnell in beliebiger Größe erzeugen und sie nehmen wenig Plattenplatz weg.
<p>
Hier der Ablauf:
Code: 
uli@sunball:~> mkdir /tmp/pr-uhe-0207 && cd /tmp/pr-uhe-0207
uli@sunball:/tmp/pr-uhe-0207> dd if=/dev/zero of=datei-10gb.txt seek=10240 bs=1024k count=1
1+0 Datensätze ein
1+0 Datensätze aus
uli@sunball:/tmp/pr-uhe-0207> time tar -cvSf pr-uhe-0207.tar datei-10gb.txt
datei-10gb.txt

real    1m12.572s
user    0m29.496s
sys     0m38.449s
uli@sunball:/tmp/pr-uhe-0207> mv datei-10gb.txt datei-10gb.txt.orig
uli@sunball:/tmp/pr-uhe-0207> tar -xvf pr-uhe-0207.tar
datei-10gb.txt
uli@sunball:/tmp/pr-uhe-0207> ls -ls
insgesamt 13326
 2049 -rw-r--r--  1 uli users  2148532224 2005-05-27 20:39 datei-10gb.txt
11265 -rw-r--r--  1 uli users 10738466816 2005-05-27 20:39 datei-10gb.txt.orig
   12 -rw-r--r--  1 uli users       10240 2005-05-27 20:40 pr-uhe-0207.tar
uli@sunball:/tmp/pr-uhe-0207> dd if=/dev/zero of=datei-10gb.txt2 seek=10240 bs=1024k count=1
1+0 Datensätze ein
1+0 Datensätze aus
uli@sunball:/tmp/pr-uhe-0207> ls -ls
insgesamt 24591
 2049 -rw-r--r--  1 uli users  2148532224 2005-05-27 20:39 datei-10gb.txt
11265 -rw-r--r--  1 uli users 10738466816 2005-05-27 20:50 datei-10gb.txt2
11265 -rw-r--r--  1 uli users 10738466816 2005-05-27 20:39 datei-10gb.txt.orig
   12 -rw-r--r--  1 uli users       10240 2005-05-27 20:40 pr-uhe-0207.tar
uli@sunball:/tmp/pr-uhe-0207>
Was fällt auf?

  • Das Dateisystem kann mit großen Dateien umgehen (reiserfs)
    Erstanlegen einer großen Datei ist kein Problem
    Abspeichern im TAR ist auch kein Problem.
    Beim Auspacken des TARs erscheint keine Fehlermeldung
    Die ausgepackte Datei ist viel zu kurz
    Auch nach dem Auspacken kann man erneut eine große Datei anlegen - Platzproblem scheidet aus!
Womit habe ich's getestet?

  • SuSE-9.2 und 9.3 mit verschiedenen Kernels
    Knoppix-3.8.2
    Standard-TAR von beiden SuSEs
    Selbst kompiliertes GNU-Tar (1.15.1)
    Schilling-Tar (star) von SuSE-9.3; das liefert einen cordump
    Selbst kompiliertes Schilling-Tar (1.5a60, 1.4.3)
Hat irgend jemand eine Idee? Danke schonmal,

Uli.
 
A

Anonymous

Gast
hi,
ich verwende zwar kein reiserfs, aber mit ext3 gehts trotz der wahnsinns blockgrösse von 1mb ;-)
hast Du schon versuch die blockgröße auf normal zu setzen ?
zb dd if=/dev/zero of=datei-10gb.txt seek=9999999 bs=1k count=1
Keine Ahnung wo die Limits für Blockgrößen bei reiserfs liegen aber der wert von 1mb erscheint mir etwas hoch ;-)
Hoffe das hilft Dir etwas weiter ;-)

Mƒg ®êïñï
 
A

Anonymous

Gast
keine Ahnung was du da gemacht hast, bei mir (Suse 9.1, Reiserfs) funktionierts und die md5sum sind auch alle gleich. Allerdings habe ich anderen Platzbedarf. mit dd belegt die Datei 1040k und beim auspacken der tar 16K - bei dir sind es bei dd schon 11265 Blocks ? sieht aus, als ob du nicht in eine neue Datei sondern in eine schon existierende Datei das sparse file rein erzeugt hättest, aber das kann evt. auch andere Ursachen haben.
Was mir aber bei deiner Ausgabe aufgefallen ist, datei-10gb.txt kann unmöglich aus der fertig abgespeicherten pr-uhe-0207.tar erzeugt worden sein, da der Zeitstempel der tar neuer ist als die der txt.
Lösche einfach mal die txt und packe deine tar neu aus.
Schau mal ob das dann passt. :?:

@reini123 mit der Blockgröße hat das nichts zu tun, es wird nach wie vor mit der Blockgröße gearbeitet die im FS festgelegt ist, der bs Wert hat nur Einfluss auf den seek und den count wert und damit mit der Entlänge der Datei.

robi
 
OP
U

uli42

Hallo Robi,

vielen Dank für Deine Antwort.
robi schrieb:
keine Ahnung was du da gemacht hast, bei mir (Suse 9.1, Reiserfs) funktionierts und die md5sum sind auch alle gleich. Allerdings habe ich anderen Platzbedarf. mit dd belegt die Datei 1040k und beim auspacken der tar 16K - bei dir sind es bei dd schon 11265 Blocks ? sieht aus, als ob du nicht in eine neue Datei sondern in eine schon existierende Datei das sparse file rein erzeugt hättest, aber das kann evt. auch andere Ursachen haben.
Zum Vergrößern anklicken....
Deine Vermutungen sind was meinen Ablauf angeht leider nicht richtig! Das ganze Verzeichnis wird zu Beginn des Ablaufes neu angelegt, die zuerst mit "dd" angelegte Datei ist definitiv neu, auch wenn's vom Ergebnis her nicht so aussieht.
robi schrieb:
Was mir aber bei deiner Ausgabe aufgefallen ist, datei-10gb.txt kann unmöglich aus der fertig abgespeicherten pr-uhe-0207.tar erzeugt worden sein, da der Zeitstempel der tar neuer ist als die der txt.
Zum Vergrößern anklicken....
Leider siehst Du auch das falsch! Das mit dem Zeitstempel erledigt "tar". "tar" versucht, den Zeitstempel auf die Originaldatei zu setzen, was idR. klappt.
robi schrieb:
Lösche einfach mal die txt und packe deine tar neu aus.
Schau mal ob das dann passt. :?:
Zum Vergrößern anklicken....
Das Ergebnis sieht ganz genau gleich aus!

Ich probier's kommende Woche mal mit SuSE-9.1. Mal sehen, ob ich's damit auch hinbekomme. Deine obigen Beobachtungen entsprechen jedenfalls genau dem, was ich mir unter 9.3 erwünscht hätte.

Eine Frage noch: Hast Du's mit einem 2.4-er Kernel oder einem 2.6-er Kernel probiert?

Nochmals vielen Dank, Uli.
 
A

Anonymous

Gast
Mit dem Zeitstempel hast du natürlich recht, :oops: und mit dem Blockverbrauch das hat sich auch relativiert ich war natürlich doch auf einem ext2 Filesystem aber auch auf einem reiser funktioniert es bei mir ohne Probleme

Code: 
rob@dhcppc1:~> uname -a
Linux dhcppc1 2.6.5-7.108-default #2 Sun Sep 5 19:14:57 CEST 2004 i686 athlon i386 GNU/Linux
rob@dhcppc1:~> rpm -q tar
tar-1.13.25-298
rob@dhcppc1:~> cd /tmp
rob@dhcppc1:/tmp> dd if=/dev/zero of=datei-10gb.txt seek=10240 bs=1024k count=1
1+0 Datensätze ein
1+0 Datensätze aus
rob@dhcppc1:/tmp> time tar -cvSf pr-uhe-0207.tar datei-10gb.txt
datei-10gb.txt

real    3m11.407s
user    0m58.049s
sys     2m5.408s
rob@dhcppc1:/tmp> mv datei-10gb.txt datei-10gb.txt.orig
rob@dhcppc1:/tmp> tar -xvf pr-uhe-0207.tar 
datei-10gb.txt
rob@dhcppc1:/tmp> ls -ls
.....
10245 -rw-r--r--  1 rob   users 10738466816 2005-05-28 14:34 datei-10gb.txt
11265 -rw-r--r--  1 rob   users 10738466816 2005-05-28 14:34 datei-10gb.txt.orig
   12 -rw-r--r--  1 rob   users       10240 2005-05-28 14:38 pr-uhe-0207.tar
....
rob@dhcppc1:/tmp> md5sum datei-10gb*
03bfe981253df450aeef58bb2c94ac04  datei-10gb.txt
03bfe981253df450aeef58bb2c94ac04  datei-10gb.txt.orig
rob@dhcppc1:/tmp>
Was aber auffällig ist, ext2 schneidet gegenüber von reiserfs bei diesem Versuch im Platzverbrauch im Filesystem besser ab, und zwar um Faktor 9 bei Erstellung mit dd und um Faktor 80 bei Rückgewinnung aus tar. Wer also nur sparse File in seinem Filesystem hat, der ist mit ext2 bedeuten besser beraten :lol:

robi
 
OP
U

uli42

Hallo Robi,

vielen Dank für die umfangreichen Tests. Da bin ich ja fast versucht, mir meine eigenen 9.1-er-Tests zu schenken :)

Nun gut: Ich denke, es dürfte kein Kernel-Problem sein. Ich habe da eher die GLIBC im Verdacht. Mal sehen, ob ich da noch was rausfinde.

MfG, Uli.
 
OP
U

uli42

OK, hab's nun auch unter 9.1 getestet. Ergebnis entspricht exakt den Beobachtungen von Robi. Schöner Mist!

  • SuSE-9.1: tar ist OK
    SuSE-9.2: tar ist KO
    SuSE-9.3: tar ist KO
    Knoppix-3.8.2: tar ist KO
MfG, Uli.
 
OP
U

uli42

So, die Tests sind nun ein wenig weiter. Leider ist das Ergebnis alles andere als befriedigend. Ziel: Funktionierendes TAR unter SuSE-9.3.

Nach den Hinweisen von Robi habe ich mit dem TAR-Binary (/bin/tar) von SuSE-9.1 rumgespielt und dieses einfach unter SuSE-9.3 unter dem Namen tar.91 eingespielt.

Erkenntnisse unter SuSE-9.3:
1. tar.91 hat keinerlei Probleme. Die TAR-Datei kann wie unter SuSE-9.1 problemlos erstellt und auch wieder entpackt werden.
2. die im vorigen Schritt erzeugte TAR-Datei kann auch mit dem TAR-Binary von SuSE-9.3 korrekt entpackt werden.
3. tar.91 kann eine mit dem TAR-Binary von SuSE-9.3 erstellte TAR-Datei nicht korrekt entpacken. Datei hat danach die Größe 0.
4. die TAR-Dateien der beiden Binaries haben gleiche Größe aber unterschiedlichen Inhalt

Also erzeugt das TAR von SuSE-9.3 (... und auch 9.2) offensichtlich korrupte TAR-Dateien. Diese können auch vom TAR von SuSE-9.1 nicht richtig entpackt werden. Umgekehrt erzeugt das 9.1-er-TAR richtige TAR-Dateien, die auch das 9.3-er-TAR richtig entpacken kann.

Somit sind meine Sicherungsdateien von SuSE-9.2
und SuSE-9.3 reif für den Mülleimer. Mist!
 
scg

scg

Sauber analysiert ! Ich setz den Ursprungsthread mal auf [solved].
(Dann kann man in der Übersicht gleich sehen, daß es gelöst ist)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben