Linux und Große Dateien???

[le-pathfinder]

Hi Leute,

Ich habe hier ein Problem mit meinem Debian/Etch fileserver.
Beim verifizieren einer Datei zwischen 800-1100 MB die vorher vom Windowsclient mit Totalkommander im binärmodus kopiert wurde, treten sehr häufig fehler auf. soll heißen, die dateien sind nicht gleich.
Nun hab ich gestern mal drei Stunden lang memtest+ laufen lassen um auszuschließen das das RAM ´ne macke hat. Danach hatte ich mit md5sum direkt auf dem linux die checksumme von einer bestimmten Datei mehrmals errechnen lassen. Bei ca 75% der Berechnungen war das Ergebniss immer anders.
Kann mir jemand sagen was ich noch testen kann um irgend etwas auszuschließen??
Ach ja, die hardware:
CPU: P3 550MHz
RAM: 512MB
HDD: Davicontrol SATA-Controller mit 4X500GB im SoftwareRAID5


vielen Dank

le-pathfinder

 

[Wolfgang]

Hallo
Überprüfe mal das Filesystem der Partition.
Auch ein Blick in dmesg beim Zugriff darauf könnte IO-Fehler zeigen.


Gruß Wolfgang

 

[rikola]

Befindet sich die Datei auf einer Festplatte oder einem USB-Stick? Auf einem Stick passiert mir das auch regelmaessig, was ich der Tatsache zuordne, dass ich den schon ein paarmal habe fallen gelassen.
Auf einer Festplatte hatte ich das Problem noch nie. Als ich den Titel 'grosse Dateien' gelesen habe, dachte ich schon irgendwas im TB Bereich. 1GB ist nicht wirklich gross und sollte auf Linux kein Problem darstellen. Ich wuerde sehr ueberzeugt auf einen Hardware tippen. Die Platte mal getestet, oder die Datei auf eine andere Partition kopiert? Liegt sie auf einer Netzwerkpartiton? Falls es um Samba geht, kopier sie zunaechst auf eine lokale Partition. Samba ist sehr unzuverlaessig (was nicht an den Entwicklern der freien Version, sondern an der nicht existenten Dokumentation durch MS liegt).

 

[Jabo]

Das ist echt komisch, weil ja gerade Linux ständig in Form von ISO-Images vergleichbarer Größe verbreitet wird, auch VMs und Virtaual Appliences. Immer werden Prüfsummen angegeben, um den Download zu verifizieren.

Ich habe selber noch nicht ein einziges mal so einen Effekt gehabt, obwohl ich mit Demo-CDs / Live-CDs und DVDs ziemlich experimentierfreudig bin. Ich muß regelmäßig ISOs auf DVDs / CDs brennen, weil ich das so betreibe, daß ich mir sonst meine Platte voll kleistere.....

Da wäre evtl. mal interessant, was für ein Linux du hast und was für ein Dateisystem du verwendest. Auch wie du die Prüfsummen abfragst.

Die Idee von Wolfgang, daß evtl. das Dateisystem selber defekt ist, hatte ich auch zuerst.

Ich habe gerade mal eine Datei von 1.4 GB (eine AVI, die ich aus einer DVD erstellt habe) mehrfach mit md5 gecheckt. Annähernd gleiche Laufzeiten und immer identische Summen:

~> time md5sum gottsein-010.avi >> test-summen.txt

real    1m27.633s
user    0m5.866s
sys     0m6.129s

~> [i][color=gray][... mehrfach ...][/color][/i]
~>cat test-summen.txt
dc478fbbf3ace109e3aeaba6125f76d4  gottsein-010.avi
dc478fbbf3ace109e3aeaba6125f76d4  gottsein-010.avi
dc478fbbf3ace109e3aeaba6125f76d4  gottsein-010.avi
dc478fbbf3ace109e3aeaba6125f76d4  gottsein-010.avi

Auch VMs zerlege ich in 2 GB große Dateien, die nie Probleme machen. Ein Linux-Problem ist das sicher nicht, eher schon ein Defekt, wie die anderen vermuten

 

[le-pathfinder]

filesystem hab ich schon getesten, war ok.
dmesg ist noch ne idee.

die datei liegt auf dem besagten RAID und die platten sind erst zwei monate alt.
der fileserver stellt die netzlaufwerke über sambe für windows bereit.
Wenn ich die datei auf eine andere lokale partition kopiere, ist alles ok.
Ich denke auch, dass es nicht an der netzwerkübertragung liegt denn
wenn ich lokal auf dem server die datei prüfe, ist die prüfsumme oft anders...

le-pathfinder

 

[marcellus]

=> smart?

vllt ist die festplatte am abnippeln

 

[Jabo]

=> smart?

und =>smart

aber:

Eine unabhängige Google-Studie über neun Monate, alle Hersteller und insgesamt 100.000 Festplatten brachte 2006 folgendes Ergebnis: Unter Einbeziehung aller relevanten Parameter sind 64% aller Ausfälle mit S.M.A.R.T. vorhersagbar. Hierbei würden alle anderen, also akustisch oder als Datenfehler bemerkbaren Warnsignale ignoriert. Im übrigen Drittel aller Ausfälle meldet sich die Festplatte selbst zu unrecht als problemfrei.

und bei dem zu RAID:

Seit Mitte 2007 zeigen mehrere Studien, dass die S.M.A.R.T.-Daten zur Vorhersage eines Ausfalls auch nur sehr beschränkt nützlich sind.

Als zusätzliche Diagnose wohl ok, aber wenn es nichts meldet, sagt das offenbar nicht so viel wie man annehmen würde.

 

[Bâshgob]

Zumindest der direkte Vergleich der Werte

Raw_Read_Error_Rate
Throughput_Performance
Spin_Up_Time
Reallocated_Sector_Ct
Seek_Error_Rate
Seek_Time_Performance
Spin_Retry_Count
Offline_Uncorrectable

lässt relative Rückschlüsse auf die Gesundheit der Platte zu. Mehrfach habe ich festgestellt, das insbesondere der Wert Offline_Uncorrectable direkte Rückschlüsse auf die Oberflächengesundheit zulässt. Hier haben Platte nach Auftreten von Unregelmäßigkeiten bei diesem Wert regelmäßig kurzeitig danach (schon in Beobachtungsquarantäne in Testsystem) versagt.

Ich empfehle daher auch den Einsatz von badblocks und besonders den Einsatz der Herstellerdiagnosetools.

Möglicherweise ist aber nur lediglich ein Kabel hin, oder eine Einstellung im verschwurbelt, alles schon erlebt.

 

[le-pathfinder]

hi Leute,

vielen Dank für die anregenden Tips.

Habe auch heute viel rumprobiert, unteranderem habe ich noch eine Platte (Ext3) in den Server gehängt und von der Platte eine Datei (<4GB) auf das RAID kopiert und das kam wärend des Kopierens als Meldung:

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ... \
fileserver kernel: Call Trace:

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ...
fileserver kernel: Code: 00 00 00 00 00 00 ba 03 00 00 00 6a 00 e8 af 29 84 f7 31 c0 83 c4 18 5b 5e 5f c3 89 c2 eb 0b f3 90 8b 02 a9 00 00 20 00 75 f5 90 <0f> ba 2a 15 19 c0 85 c0 75 ec 8b 02 31 c9 f6 c4 40 74 06 8b 4a

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ...
fileserver kernel: EIP: [<c88d3cde>] journal_grab_journal_head+0x10/0x42 [jbd] SS:ESP 0068:c7f2fe20
81 1.29
Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ... 59
fileserver kernel: Oops: 0002 [#1]

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ...
fileserver kernel: EIP is at journal_grab_journal_head+0x10/0x42 [jbd]

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ...
fileserver kernel: SMP

Message from syslogd@fileserver at Sun Dec 16 16:33:52 2007 ...
fileserver kernel: CPU: 0


kann mir das jemand so erklären, dass ich das auch verstehe...

dank Euch
le-pathfinder

 

[le-pathfinder]

Hi Leute,

hab heute aus lauter verzweiflung das RAID mit Controller in einen anderen Rechner gebaut auf dem auch Debian/Etch läuft. Ich hatte gestern die CPU und das RAM getauscht und alle Komponenten, die nicht wirklich wichtig sind, rausgeschissen. Außerdem die Datenkabel getauscht usw. UND,...NICHTS!!!

Dachdem das RAID jetzt schon ca 4 Stunden in dem anderen Rechner läuft und ich permanent files hin und her kopiere und auch verifiziere, kann ich bis jetzt keinen Ausfall beklagen. Ich vermute, dass das mainboard ´ne macke hat...

Gruß
le-pathfinder