10
Linux-to-Linux-Copy mit unterschiedlichen Ergebnissen
Hallo zusammen,
vielleicht kann mir jemand auf die Sprünge helfen, welchen Fehler ich bei folgendem Vorgehen mache.
Ich habe zwei kleine Linux-Server (keine VMs). Beide sind mit Ubuntu-Server 12.04 installiert. Beide haben 4 GB RAM und genügend Festplattenplatz. Alle Dateisysteme haben den Typ ext3.
Nun erstelle ich zwei tar-Archive der selben Daten (Attachments eines Zarafa-Servers aus /var/lib/zarafa). Diese werden ca. 9 GB groß ist. Bei der einen Datei verwende ich die Komprimierungsoption "z" für gzip, bei der anderen verwende ich die Option "J" für xz.
Die beiden Dateien kopiere ich mit scp (und auch mal mit rsync) vom einen System auf das andere. Das Ergebnis ist "spannend".
Die mit gzip komprimierte Datei hat am Zielsystem immer eine andere MD5-Summe und endet beim Entpacken mit einem CRC-Fehler.
Die mit xz komprimierte Datei hat am Zielsystem die selbe MD5-Summe wie am Quellsystem. Beim Entpacken kommt aber die Fehlermeldung, dass die Daten korrupt seien.
Das Ganze habe ich jetzt sowohl für gz als auch für xz 3 Mal gemacht, 3 Mal kopiert und probiert zu entpacken. Jedesmal mit dem obigen Ergebnis... wo ist mein Denkfehler? Was läuft hier schief?
Ich bin *sehr* gespannt
Danke im Voraus und viele Grüße,
Frank
vielleicht kann mir jemand auf die Sprünge helfen, welchen Fehler ich bei folgendem Vorgehen mache.
Ich habe zwei kleine Linux-Server (keine VMs). Beide sind mit Ubuntu-Server 12.04 installiert. Beide haben 4 GB RAM und genügend Festplattenplatz. Alle Dateisysteme haben den Typ ext3.
Nun erstelle ich zwei tar-Archive der selben Daten (Attachments eines Zarafa-Servers aus /var/lib/zarafa). Diese werden ca. 9 GB groß ist. Bei der einen Datei verwende ich die Komprimierungsoption "z" für gzip, bei der anderen verwende ich die Option "J" für xz.
Die beiden Dateien kopiere ich mit scp (und auch mal mit rsync) vom einen System auf das andere. Das Ergebnis ist "spannend".
Die mit gzip komprimierte Datei hat am Zielsystem immer eine andere MD5-Summe und endet beim Entpacken mit einem CRC-Fehler.
Die mit xz komprimierte Datei hat am Zielsystem die selbe MD5-Summe wie am Quellsystem. Beim Entpacken kommt aber die Fehlermeldung, dass die Daten korrupt seien.
Das Ganze habe ich jetzt sowohl für gz als auch für xz 3 Mal gemacht, 3 Mal kopiert und probiert zu entpacken. Jedesmal mit dem obigen Ergebnis... wo ist mein Denkfehler? Was läuft hier schief?
Ich bin *sehr* gespannt
Danke im Voraus und viele Grüße,
Frank
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 243173
Url: https://administrator.de/contentid/243173
Printed on: April 24, 2024 at 11:04 o'clock
10 Comments
Latest comment
Moin,
Mein erster Tipp wäre: defekter Datenträger oder defektes Filessystem.
lks
Mein erster Tipp wäre: defekter Datenträger oder defektes Filessystem.
- verändern sich die Quelldaten während des Packens?
- funktioniert das korrekte Entpacken auf dem Quellsystem in einem temporären Verzeichnis.
- funktioniert die Übertragung über Datenträger (USB-Stick, Diskette, Bänder, etc.)
- funktioniert das kopieren über (s)ftp oder rsync?
- hast Du mal statt md5 mal sha-Prüfsummen ausprobiert?
lks
Hallo Frank,
ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.
- Du hast keinen ECC RAM und bei solchen großen Operationen kommt es dann eben zu CRC
Fehlern.
Verteil doch einfach die gesamte Last und somit auch die gesamten Daten auf mehrere kleine
Archive und benutze .tar.gzip eventuell fällt das dann nicht so ins Gewicht und es kommt nicht
zu Fehlern dieser Art.
Gruß
Dobby
ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.
- Du hast keinen ECC RAM und bei solchen großen Operationen kommt es dann eben zu CRC
Fehlern.
Verteil doch einfach die gesamte Last und somit auch die gesamten Daten auf mehrere kleine
Archive und benutze .tar.gzip eventuell fällt das dann nicht so ins Gewicht und es kommt nicht
zu Fehlern dieser Art.
Gruß
Dobby
Zitat von @108012:
ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.
ich denke es verhält sich so;
- Die Dateien werden im RAM gecachet und weil der nicht gerade üppig ist wird auf die HDDs
ausgelagert (/temp & /swap) und dann kommt es eben zu solchen Fehlern.
Swappen wäre nur dann ein Grund, wenn der Kernel eine Macke hätte, was ich für unwahrscheinlich halte, wenn die Kisten stabil laufen. Wenn, dann ist es der RAM, wenn kein ECC-RAM verwendet wird.
lks
Hallo,
ein paar Ansatzpunkte...
Außerdem -rein interessehalber- die Frage, wie lange ein "tar cJf" dauert, der eine 9 GB große Archivdatei erzeugt... Ich lese hier: "it takes significantly longer to do the compression" und "also take a hit in the memory requirements".
Läuft währenddessen der Zarafa-Server?
Gruß,
Gersen
ein paar Ansatzpunkte...
Außerdem -rein interessehalber- die Frage, wie lange ein "tar cJf" dauert, der eine 9 GB große Archivdatei erzeugt... Ich lese hier: "it takes significantly longer to do the compression" und "also take a hit in the memory requirements".
Läuft währenddessen der Zarafa-Server?
Gruß,
Gersen
Hallo,
Touché. War ja noch nicht fertig - musste aber ins Bett...
Gruß,
Gersen
Die alle schon oben erwähnt wurden.
Touché. War ja noch nicht fertig - musste aber ins Bett...
Gruß,
Gersen
Zitat von @Gersen:
Hallo,
> Die alle schon oben erwähnt wurden.
Touché. War ja noch nicht fertig - musste aber ins Bett...
Hallo,
> Die alle schon oben erwähnt wurden.
Touché. War ja noch nicht fertig - musste aber ins Bett...
Macht nichts, aber manchmal hilft es alles doppelt zu sagen
lks
Hallo zusammen,
vielen Dank für die vielen Anregungen, da hab ich heute Abend was zum Testen
Hier auch schon mal die ersten Antworten:
- die Quelldateien verändern sich während des Packens nicht, da ich Zarafa immer vorher gestoppt habe.
- das Entpacken auf dem Quellsystem funktioniert, die MD5-Summe ist dort richtig (sorry, hatte ich vergessen zu erwähnen)
- Das Übertragen habe ich außer mit scp auch mal mit rsync probiert, aber nicht mit (s)ftp
Das Kopieren auf eine USB-Platte habe ich heute morgen angeworfen, das probiere ich heute abend auch aus.
Ich kann heute Abend das auch mal genauer stoppen, wie lange das Packen mit xz bei dieser Datenmenge dauert und das dann posten.
Und ich werde den Speicher testen, das hätte ich nicht gedacht, muss ich gestehen, aber nach allem was ich jetzt gelesen habe, klingt das plausibel. Der Speicher ist kein ECC-RAM und der Speicher ist (genau wie die Maschinen) ca. 4 Jahre alt. Das könnte dann schon sein.
Vielen Dank erstmal, ich halte Euch auf dem Laufenden, viele Grüße,
Frank
vielen Dank für die vielen Anregungen, da hab ich heute Abend was zum Testen
Hier auch schon mal die ersten Antworten:
- die Quelldateien verändern sich während des Packens nicht, da ich Zarafa immer vorher gestoppt habe.
- das Entpacken auf dem Quellsystem funktioniert, die MD5-Summe ist dort richtig (sorry, hatte ich vergessen zu erwähnen)
- Das Übertragen habe ich außer mit scp auch mal mit rsync probiert, aber nicht mit (s)ftp
Das Kopieren auf eine USB-Platte habe ich heute morgen angeworfen, das probiere ich heute abend auch aus.
Ich kann heute Abend das auch mal genauer stoppen, wie lange das Packen mit xz bei dieser Datenmenge dauert und das dann posten.
Und ich werde den Speicher testen, das hätte ich nicht gedacht, muss ich gestehen, aber nach allem was ich jetzt gelesen habe, klingt das plausibel. Der Speicher ist kein ECC-RAM und der Speicher ist (genau wie die Maschinen) ca. 4 Jahre alt. Das könnte dann schon sein.
Vielen Dank erstmal, ich halte Euch auf dem Laufenden, viele Grüße,
Frank
Das Übertragen habe ich außer mit scp auch mal mit rsync probiert...
Was mich wundert: rsync macht grundsätzlich nach jedem Transfer eine Checksum-Prüfung ("Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred"; http://linux.die.net/man/1/rsync). Die müsste doch schon auf die Nase fallen - und der rsync-Prozess mit Fehler stoppen. Oder?
Hallo zusammen,
danke für Eure Inputs. Das Problem war bzw. ist der Zielserver. Das mit dem Speicher hat sich als richtig rausgestellt. Ich habe noch folgende Tests gemacht:
Kopieren auf mein Linux-Notebook funktioniert mit scp und rsync problemlos, gleiche MD5-Summe.
Wenn ich eine USB-Platte verwende, kommt die selbe MD5-Summe, solange ich das File auf dem Quellsystem habe oder auf der USB-Platte:
- MD5 ist ok auf dem Quellsystem
- MD5 ist ok auf dem Quellsystem nach dem Kopieren auf USB
- MD5 ist ok auf dem Zielsystem auf der USB-Platte
- MD5 ist *nicht* ok auf dem Zielsystem nach dem Kopieren auf das lokale Filesystem
Ein Memtest auf dem Zielsystem hat ziemlich viele Fehler angezeigt, das dürfte damit auch der Grund für die Probleme sein, denke ich. Der neue Speicher ist bestellt.
Die Frage war noch, wie lange das Erstellen einer .tar.xz-Datei dieses Umfangs bei ext3 benötigt. Die Datei mit etwas mehr als 9 GB wird bei mir in ca. 1 Stunde und 40 Minuten erstellt. Zugrunde liegt ein Filesystem mit ext3, bestehend aus 4 RED-Festplatten von WD und einem Software-RAID. Allerdings ist die CPU nicht die Stärkste, diese war auch die meiste Zeit zu 100% ausgelastet (Intel Core 2 Duo, E8400).
Danke euch und viele Grüße,
Frank
danke für Eure Inputs. Das Problem war bzw. ist der Zielserver. Das mit dem Speicher hat sich als richtig rausgestellt. Ich habe noch folgende Tests gemacht:
Kopieren auf mein Linux-Notebook funktioniert mit scp und rsync problemlos, gleiche MD5-Summe.
Wenn ich eine USB-Platte verwende, kommt die selbe MD5-Summe, solange ich das File auf dem Quellsystem habe oder auf der USB-Platte:
- MD5 ist ok auf dem Quellsystem
- MD5 ist ok auf dem Quellsystem nach dem Kopieren auf USB
- MD5 ist ok auf dem Zielsystem auf der USB-Platte
- MD5 ist *nicht* ok auf dem Zielsystem nach dem Kopieren auf das lokale Filesystem
Ein Memtest auf dem Zielsystem hat ziemlich viele Fehler angezeigt, das dürfte damit auch der Grund für die Probleme sein, denke ich. Der neue Speicher ist bestellt.
Die Frage war noch, wie lange das Erstellen einer .tar.xz-Datei dieses Umfangs bei ext3 benötigt. Die Datei mit etwas mehr als 9 GB wird bei mir in ca. 1 Stunde und 40 Minuten erstellt. Zugrunde liegt ein Filesystem mit ext3, bestehend aus 4 RED-Festplatten von WD und einem Software-RAID. Allerdings ist die CPU nicht die Stärkste, diese war auch die meiste Zeit zu 100% ausgelastet (Intel Core 2 Duo, E8400).
Danke euch und viele Grüße,
Frank
