# Prüfsummenfehler beim Kopieren von Dateien

## Antimon

Hallo zusammen,

ich habe ein seltsames Problem, welches ich aber nicht gerade lustig finde.

Wenn ich eine (größere) Datei auf meiner Gentoo Kiste von einem Verzeichnis in ein anderes schiebe, stimmt plötzlich die md5-Summe nicht mehr mit der alten überein - also sind irgendwo einige Bytes fehlerhaft übertragen worden.

Aufgefallen ist mir das bisher hauptsächlich mit ISO-Dateien, die danach teilweise nicht mehr lesbar waren...

Jetzt ist die Frage an was das liegen könnte... Kabelproblem? Software-Raid5? Dateisystem? Festplatte?

Das System ist ein 1,4 GHz Athlon mit Asus A7N8X-Mainboard, 2,6'er Kernel (2.6.17-gentoo-r4) und einem Software-Raid5. Das Raid5 bedient 4x 250 GB Platten, wobei zwei an den Mainboard-Controllern angeschlossen sind, die anderen zwei an einer PCI SIL3114 Karte.

Ich dachte erst dass es am Netzwerk liegt, da der Rechner mein Domänencontroller ist und ich das Thunderbird-Profil auf diesem liegen habe. Und der bringt ab und zu eine Meldung, dass er eine Datei nicht schreiben konnte - ich weiss nicht ob das ein eigenständiges Problem ist oder ob es mit dem Plattenproblem zu tun hat.

Und nicht ganz normal ist auch, dass ich häufig beim Booten das Dateisystem überprüfen muss und dann jede Menge Fehler angezeigt werden, die ich manuell korrigieren darf.

Wie kann ich versuchen, den Fehler einzugrenzen um zu sehen ob es die Hardware/Software ist - und welcher Teil davon? Fehler meldet das Raid nicht, die Platten sind laut SMART auch in Ordnung (wobei ich den langen Selbsttest ausführen könnte) und sonst wüsste ich nicht, was ich noch nachschauen könnte.

Hat jemand ein paar Tips für mich? Ich wäre sehr dankbar!

----------

## Mr. Anderson

Unwahrscheinlich, aber... RAM getestet?

Und woher weiß das Dateisystem beim Booten, dass Fehler vorhanden sind. Das geht doch fast nur, wenn beim Runterfahren was nicht sauber ausgehängt wurde. *grübel*

----------

## Antimon

Hmm RAM könnte ich mal testen - danke für den Tip!

Also das FS wird meist getestet, weil entweder die maximale Anzahl an Mounts bzw. Tagen verstrichen ist, oder weil sich mein System vorher aufgehängt hat.

Ich hatte es schon 2-3mal dass der Rechner komplett eingefroren ist und NICHTS mehr ging... nicht mal die Konsole kam mehr zum Vorschein. Das war irgendwann so in der Nacht um 4 rum oder so - und woran das lag weiss ich nicht - ich habs auf ein Kernelmodul (DVB-Karte oder so) geschoben, aber das könnte theoretisch auch vom RAM kommen, wie du sagst...

Ich werde morgen gleich mal testen... sonst noch Ideen was es sein könnte?

----------

## pom

Hi,

ich habe die Probleme nicht, aber kann bestätigen, das es mit der Stabilität der SATA-Treiber noch suboptimal ist.

In meiner Kiste ist ein Controler von JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02) drin. Der Treiber ist extrem buggi, noch. Die CPU Last steigt um ca. 10-20% beim kopieren und der maximale Durchsatz liegt bei 5MB/s.

Nicht schön. Warten wir halt auf einen neuen Kernel, alles wird gut.

Gruß

POM

----------

## Antimon

Hehe warten würd ich ja gern... nur wenn bis dahin meine Dateien alle defekt sind bringt mir ein neuer Treiber auch nix  :Wink: 

Ich hab übrigens noch ein wenig rumprobiert und festgestellt, dass scheinbar nur bestimmte Dateien betroffen sind. Zum einen wärs die eine ISO von der CD und dann hab ich noch das MediaWiki abgespeichert, entpackt und auf meinen Webserver übertragen - dort waren dann zwei Dateien hinüber - da standen dann plötzlich ganz andere Zeichen im PHP-Skript, weshalb der nen Parse Error gebracht hat...

Allerdings, wenn ich die zweite ISO-Datei (also CD2) hin- und herverschiebe bleibt die Checksum immer gleich - die Datei hat so ca. 150 MB.

Was mich halt so dermaßen wundert ist, dass die eine Datei beim rumschieben _immer_ ihre Daten ändert, während die andere gleich bleibt. So nach dem Motto: Du gefällst mir, du nicht, bei dir bring ich mal ein paar Fehler rein...

----------

## Keruskerfuerst

Vielleicht ist rsync ein Blick Wert.

----------

## Antimon

Ich kann deinem Wink leider nicht ganz folgen...

Ja ich kenne rsync... aber wie soll mir das in diesem Fall weiterhelfen?

Falls du meinst, ich soll mit Prüfsummen arbeiten, dann weiss ich zwar dass eine Datei defekt oder nicht defekt übertragen wurde - aber das weiss ich jetzt auch. Nur die Gründe nicht, warum das so ist.

Oder kann ich die mit rsync irgenwie rausfinden?

Hilf mir doch mal bitte auf die Sprünge...

----------

## Finswimmer

rsync würde dir beim Übertragen helfen. Natürlich nicht bei der Fehlersuche.

Ich würde mal auf ne Knoppix Cd reinschmeißen und dann schauen, wie es da ist.

Wenn es da auch ist, kannst du einen Konfig Fehler in Gentoo ausschließen.

Tobi

----------

## Antimon

Das ist auch ne ausgezeichnete Idee... das werde ich auch ausprobieren.

Ich hoffe nur dass die Knoppix-Versionen auch Raid und LVM im Kernel aktiviert haben, sonst komm ich gar ned an die Daten. Ich glaub da gabs nämlich bei einigen Knoppixen was... aber das find ich schon raus, notfalls gibts ja noch andere Distris...

Bin ja echt mal gespannt, worans liegt - sofern ich das rausfinde...

----------

## Antimon

Also mal ein paar updates:

Der RAM ist in Ordnung, das meint zumindest memtest86+ nach 3 Durchläufen. Die Festplatten sind angeblich auch in Ordnung, meinen die Tools der Hersteller.

Nicht in Ordnung ist dagegen das Dateisystem - ich habe mal zum testen nen fsck über das volume gejagt, ohne Parameter meint er dass alles in Ordnung ist, hat also keine offensichtlichen Fehler festgestellt. Aber mit der force-Option rattern die Fehler nur so durch, von "multiplicity-claimed blocks" über andere Fehler, momentan läuft er seit ca. ner halben Stunde über einen Verzeichnisbaum mit irgendwelchen "mod time" meldungen - dabei habe ich das Gefühl, als ob er die gleichen Verzeichnisse immer wieder erneut durchrattert...

Mit Knoppix habe ich noch nichts probiert, die 4'er Version hat kein LVM drauf und die 5'er Version findet ihre CD nicht, wenn ich von nem SCSI-Laufwerk boote - da werde ich wohl oder übel mal ein IDE-Laufwerk in den Server einbauen müssen.

Bin ja mal gespannt, was das noch wird...

----------

## Antimon

Wieder ein Update:

Ich habe das System mit Knoppix 5.1.1 gebootet und wieder versucht eine Datei von einem Verzeichnis ins Unterverzeichnis zu verschieben - genau das gleiche: Andere Prüfsumme.

Ergo ists vermutlich nicht die Software, sondern die Hardware, die Probleme verursacht, oder was meint Ihr?

Was könnte es sein - Kabelprobleme? Die Festplatten (bzw. eine davon) selbst? Ein Controller?

----------

## Antimon

Es wird leider immer schlimmer... und langsam hab ich Angst um meine Daten.

Heute sehe ich folgende Ausgabe:

server tags # ls -la

ls: Zugriff auf .svn nicht möglich: Eingabe-/Ausgabefehler

insgesamt 8

drwxr-xr-x 3 antimon users 4096 11. Mär 01:05 .

drwxr-xr-x 6 antimon users 4096 28. Aug 2006  ..

d????????? ? ?       ?        ?             ? .svn

Wenn es ne normale Platte wäre, würde ich auf defekte Sektoren oder so tippen - aber das ist ein Raid5!

Ich hab langsam die Befürchtung, meine Daten sind auf ner normalen Platte sicherer als auf dem Raid...

Habt Ihr noch ein paar Tips, was ich noch probieren könnte, um dem Übeltäter auf die Schliche zu kommen?

----------

## Mr. Anderson

Wenn es eine einzelne Festplatte wäre, müsste an sich ja der Raid meckern, oder nicht? Festplatte kann es also wohl nicht sein. RAM ist es nicht. CPU ist extrem unwahrscheinlich. Raid-Controller kann es nicht sein, da keiner vorhanden ^^

Hm, mal versuchen, streng logisch das zu betrachten:

Eine Datei nimmt wohl etwa diesen Weg:

RAM -> Systembus/Mainboard -> Northbridge -> Systembus -> Cache -> Die -> CPU -> [Raid-Treiber] -> CPU -> Die -> Cache -> Systembus -> Northbridge -> Systembus -> Southbridge -> PCI/IDE-Controller -> Steckplatz -> PCI-Karte/IDE-Kabel -> Festplatte

und umgekehrt.

Das Dateisytem ist beschädigt. Der Raid sagt, alles sei in Ordnung -> Alle Festplatten enthalten die gleichen Fehler

RAM -> Systembus/Mainboard -> Northbridge -> Systembus -> Cache -> Die -> CPU -> [Raid-Treiber] -> CPU -> Die -> Cache -> Systembus -> Northbridge -> Systembus -> Southbridge

Der RAM ist in Ordnung, wie die Testdurchläufe mit memtest86+ gezeigt haben. Die Binaries sind in Ordnung (keine Übersetzungsfehler), denn in Knoppix treten genau die gleichen Fehler auf. Es bleibt also nur:

Systembus/Mainboard -> Northbridge -> Systembus -> Cache -> Die -> CPU -> ... ->  -> Die -> Cache -> Systembus -> Northbridge -> Systembus -> Southbridge

Es reduziert sich also auf Mainboard (ggf. inklusive Netzteil  :Wink: ) und CPU (ausgehend davon, dass in der Software keine ganz massiven Fehler enthalten sind).

Kannste den ganzen Raid vielleicht testweise in ein anderes System umziehen?

----------

## Antimon

Hmm die Erklärung scheint logisch. Wobei ich nicht weiss ob das so "einfach" zu handhaben ist, dazu fehlen mir leider die Einblicke ins Raid.

Nehmen wir an, eine Festplatte ist defekt... bekommt es das Raid denn mit? Es kommen Daten, die ge-XORt und auf die Platten verteilt werden. Beim Lesen werden ja nicht alle n Festplatten zum Lesen genommen, sondern nur n-1, oder irre ich mich da? Prüft das Raid beim Lesen ob die Parity-Bits stimmen (können)?

Wann kann das Raid feststellen ob eine Festplatte defekt ist - wenn sie nicht mehr ansprechbar ist oder wenn defekte Sektoren gelesen werden, ...?

Was ich mir noch vorstellen könnte ist, dass z.B. ein Bug im Software-Raid ist, oder dass sich die Konstellation LVM auf Raid5 nicht so gut verträgt... 

Die ganzen Platten in nen anderen Rechner einbauen könnte ich prinzipiell auch - nur habe ich da das Problem des Raid-Controllers, ich glaube nicht dass ich ein Board mit 4 SATA-Steckplätzen habe - also müsste ich den SATA-Controller mit umbauen - und gerade der könnte die Probleme bereiten.

Vielleicht noch ein paar Worte zur Konstellation: Da auf dem Board nur 2 SATA-Anschlüsse waren, habe ich einen (billigen) SIL3114 Controller nachgerüstet, von dem nur 2 Anschlüsse belegt sind. Ich könnte natürlich alle 4 Platten an diesen Controller hängen, dann würde ich zumindest den onboard-Controller ausschliessen können, aber ich befürchte fast wenn Hardware, dann ists der PCI-Controller...

Ich werd mal versuchen, irgendwie die Hardware zu tauschen, mal sehen was ich da für Möglichkeiten habe. Angenommen es ist die Hardware, was wäre dann zu empfehlen? Gleich nen Hardware-Raid-Controller zu verwenden? Wobei ich da ungern mehr als 100 EUR ausgeben würde - und in dem Preissegment bekommt man nur "billige" Raid5-Controller, also vielleicht wieder das gleiche Problem?

Es ist irgendwie ärgerlich, ich habe langsam das Gefühl, Daten sind leichtflüchtig, so wie Spiritus oder so - bei meinem letzten Server hatte ich auch das Problem der langsam kaputtgehenden Dateisysteme, deswegen habe ich den Server dann auf neuer Hardware komplett neu aufgesetzt. Und vor kurzem ist mir meine Festplatte für die automatischen Backups hops gegangen, jetzt bleibt nur noch der Backup-Server. Ich dachte ich übertreibs mit Backups, aber mittlerweile bin ich da anderer Meinung.

Auf jeden Fall probier ich mal das Raid in nem anderen Rechner, vielleicht hift das ein wenig.

Dir bzw. Euch auf jeden Fall mal vielen, vielen Dank für die Hilfe - ich halte Euch auf dem Laufenden...

----------

## Niethi

Hi, das erinnert mich irgendwie an an einen anderen Serverausfall:

http://www.planet3dnow.net/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1172751971

Ebenfalls ein Sil 3114. War zwar ein SUN Solaris als OS drauf, aber vielleicht findest du dort noch die ein oder andere Info.

Ich drücke jedenfalls die Daumen  :Confused: 

----------

## Antimon

Danke für Eure Hilfe, ich habe jetzt den Fehler glaube ich lokalisiert.

Nachdem ich alle 4 Platten in ein anderes System eingebaut hatte, wollte ich testen, ob auf dem System eine einwandfreie Kopie erstellt werden kann. Aber schon beim Kopiervorgang gab es Fehler von der einen Platte, irgendwie hat die auch so komisch geklackt... also dachte ich, die Festplatte ist hinüber - ausgebaut und das Herstellertool drüberlaufen lassen.

Parallel dazu habe ich mit den restlichen 3 Platten (die 4. wurde vorher automatisch aus dem Verbund genommen) weiter getestet - und siehe da, plötzlich keine Prüfsummenunterschiede mehr...

Nachdem es nur noch die Platte oder der Port am Controller sein konnte (die Platte war grad beim _langen_ Selbsttest), habe ich mal den nun freien Controller-Steckplatz für eine andere Platte verwendet, also einfach umgesteckt - und schon kamen wieder die Fehler.

Die Platte hat laut Herstellertool keine Fehler, also ist wohl ziemlich sicher der Controller im Eimer und ich werde mir schnellstmöglich einen anderen bestellen. Momentan läuft das Raid mit 3 Platten wieder, wobei mir da einige Seltsamkeiten aufgefallen sind:

- Als die "defekte" Platte aus dem Raid entfernt wurde, dachte ich mir: toll, dann teste ich mit den verbleibenden. Aber trotz entfernter Platte gab es Zugriffsfehler, er wollte die Platte unbedingt ansprechen - wie kann das sein?

- Vor dem Umbau in einen anderen Rechnern hatte ich am Controller die Ports 1 und 2 in Betrieb, die restlichen beiden befanden sich auf dem Mainboard. Im anderen Rechner habe ich alle 4 Ports des S-ATA Controllers benutzt, aber da machte nur Port 4 Probleme- vermutlich treten die Fehler auf allen Ports auf und das total sporadisch. Momentan läufts jedenfalls.

Allerdings läuft das Raid momentan nur mit 3 von 4 Platten - ich hoffe dass nicht noch Probleme auftreten, die Daten werde ich auf jeden Fall noch verstärkt sichern, bis mein Ersatz-Controller und meine Backup-Platten gekommen sind. Aber die 4. Platte füge ich dem Raid vorerst nicht hinzu, nicht dass der Controller beim Rebuid wieder massenweise Mist auf die Platte schreibt, der dann auch den Controller-Tausch übersteht... ich hoffe das geht gut!

Auf jeden Fall schon mal vielen, vielen Dank für Eure Hilfe und Bemühungen, es hat mir sehr weitergeholfen. Ich melde mich spätestens wenn (hoffentlich) wieder alles so läuft wie es soll...!

----------

## Antimon

*dingdingding*

Nächste Runde...

Nachdem ich das Array mit 3 Platten in Betrieb genommen habe, um wenigstens mit den Daten arbeiten zu können, habe ich heute festgestellt, dass der Server hängt - und zwar so, dass nicht mal eine Fehlermeldung auf dem Bildschirm erscheint. Also Rechner rebootet und hochfahren lassen - gleich beim Laden des Kernels gabs nen automatischen Reboot ... toll.

Beim zweiten Mal ist er einfach hängen geblieben - wieder reboot.

Dann hab ich vorsichtshalber mal die Platte deaktiviert, die eh nicht mehr im Verbund war - dann hat er wenigstens das System gestartet, konnte aber das Array nicht starten...

Jetzt hoffe ich nur dass das Array keinen Schaden genommen hat und nur einfach wegen des defekten Controllers nicht mehr ansprechbar war - und dass der neue Controller morgen kommt, denn wenn nix mehr geht merkt man erst wie sehr man drauf angewiesen ist.

Naja jetzt bin ich mal gespannt wie es weitergeht - und ob ich an die 500 GB Daten jemals wieder rankomme - damit wäre jahrelange Arbeit mit einem Schlag weg - bis auf die Daten die ich noch irgendwie sichern konnte. Aber nachdem meine Backup-Platte ja auch vor ner Woche den Geist aufgegeben hat und die neue in dem Paket ist, welches hoffentlich bald eintrifft, siehts damit auch schon mal schlecht aus...

Ich lass mich überraschen - hoffentlich positiv.

----------

