☰

Speichercache verliert Synchronisierung mit Festplatte

tag-icon • tag-icon linux memory cache
Speichercache verliert Synchronisierung mit Festplatte

(Ubuntu Linux-Server, 64 Bit) Ich war gerade dabei, ein Problem mit einer Datei (~3,0 GB) zu beheben, die ich gerade heruntergeladen hatte, die aber den Integritätstest nicht bestand, als ich etwas wirklich Ungewöhnliches entdeckte.

Dies ist zunächst der MD5-Wert der Datei nach dem Download, der nicht dem erwarteten Wert entsprach:

~% md5sum media.iso 
5d74facb904cc1765a468354908a8f34  media.iso

Es vergeht einige Zeit. In dieser Zeit sollte sich an der Datei nichts geändert haben. Als ich die Datei jedoch noch einmal überprüfen wollte, geschah Folgendes:

~% md5sum media.iso
a5b97c5016afb39bd67ccfc3fa6ca59e  media.iso

Das war wirklich unerwartet. Da ich viel RAM habe, vermutete ich, dass dies der Effekt des Caching war und dass etwas damit schief lief. Ich beschloss, es mit der gesamten Datei von der Festplatte noch einmal zu versuchen, und zu meiner Überraschung:

~% sudo sysctl -w vm.drop_caches=3    # This linux command invalidates
vm.drop_caches = 3                    # everything in the memory cache.
~% md5sum media.iso
2992aa6270f6e1de9154730ed3beedc1  media.iso

Ich habe es neu gemacht und jetzt scheint es konsistent zu bleiben, obwohl dies immer noch nicht der Wert ist, den ich erwartet hatte. Sicherlich,Der Inhalt im Speichercache unterschied sich vom Inhalt auf der FestplatteDas ist das große Problem.

Um den Download zu reparieren, habe ich auf dem Quellcomputer einen Torrent erstellt und ihn auf dem Zielcomputer geöffnet. Fünf 1-MB-Blöcke von ~3,0 GB haben die Integritätsprüfung nicht bestanden. Ich habe den Torrent verwendet, um diese Dateiblöcke zu reparieren und sicherzustellen, dass die Dateiintegrität in Ordnung ist.

Das Problem besteht nun darin, herauszufinden, wo die Daten nicht mehr synchron sind.

  1. Getestet habe ich den Speicher mitmemtest86+, alles außer dem Bit-Fading-Test. Ich hatte erwartet, ein fehlerhaftes Speichermodul zu sehen, aber da war nichts. Alles ist ok.
  2. Das Dateisystem ist Ext4 über LVM2 über einem RAID5-Array mit 3 Festplatten. Ext4 gilt als stabil, und wenn die Daten zwischen den Festplatten inkonsistent wären, hätte mdadm eine Warnung ausgegeben. Aber in den Protokollen steht nichts. Die SMART-Fehlerprotokolle sind sauber, die Festplatten sind neu (haben weniger als 30 Tage Betriebszeit).
  3. Ich suche nach Informationen zu Datenverlustfehlern in meinem aktuellen Kernel (2.6.35), aber soweit ich gesucht habe, scheint es nichts zu geben.

Irgendwelche Ideen, was ich noch überprüfen könnte oder wo genau der Defekt/Fehler liegen könnte?

Es ist ein Ubuntu 10.10 64-Bit, Core i7 930, 6 GB Nicht-ECC-RAM.

Aktualisieren:Ich habe bestätigt, dass die Dateien korrekt auf die Festplatte geschrieben werden und die Seiten geändert werden, nachdem sie von der Festplatte gelesen wurden, während sie sich im Speicher befinden. Ich habe noch viele weitere Memtests durchgeführt (ich habe es über Nacht einen Bit-Fade-Test durchführen lassen) und immer noch nichts. Alle Speichermodule scheinen in Ordnung zu sein.

Noch ein paar Tests:

~% md5sum media.iso 
cc8bcf1ce67ff7704eadc2222650c087  media.iso
~% cp media.iso tmp1
~% md5sum tmp1 
bde6c54b2d7b03404b43056b908036ed  tmp1
~% md5sum media.iso 
134f607cf4c633ef11d2576d1c635d08  media.iso    # ← THIS IS THE CORRECT VALUE
~% cmp -l media.iso tmp1
  98697009 101 121
~% udiff <(xxd -s ... media.iso) <(xxd -s ... tmp1 )
--- /proc/self/fd/11    2010-11-03 14:52:55.649433000 -0200
+++ /proc/self/fd/13    2010-11-03 14:52:55.649433000 -0200
@@ -13,7 +13,7 @@
 5e1fef1: 280f 5a87 37d2 e6d6 647d bebe f04e 64d8  (.Z.7...d}...Nd.
 5e1ff01: 19a5 2ff4 178b 1e37 afb0 e914 e03f bd62  ../....7.....?.b
 5e1ff11: 2b8d 4245 985f a9f8 a993 1f51 6d31 30e7  +.BE._.....Qm10.
-5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3541  .t.5........ .5A
+5e1ff21: 8274 0d35 ab8f 86b7 130f e1d7 20c6 3551  .t.5........ .5Q
 5e1ff31: 387b f226 6348 fabc 1eae 67ef adda c3b6  8{.&cH....g.....
 5e1ff41: a931 bf29 690f 25f9 8922 6dcc 009f 60a5  .1.)i.%.."m...`.
 5e1ff51: 559a 9d03 92cb fb5c a75f a26e 0954 0af4  U......\._.n.T..

~% md5sum media.iso        
54d67cc4dcad49b6d1bf6619074b471c  media.iso
~% direcat media.iso|md5sum
134f607cf4c633ef11d2576d1c635d08  -
~% direcat media.iso | cmp -l media.iso -
  98697009 121 101
 231297649 146 147
 519630641 177 157
2291859249 377 357
2442055473 127 107
2907131697 171 151

( direcatist eine Version von , catdie mit liest O_DIRECT, d. h. den Seitencache umgeht)

Es gibt ein klares Muster: Es passiert immer mit dem 2. Byte in einer 16-Byte-Anordnung. In diesem Byte wird fast immer Bit 4 (LSB) auf 1 umgeschaltet, aber es gab einen Fall, in dem Bit 2 auf 0 umgeschaltet wurde.

Antwort1

Wenn sich die MD5-Summe einer Datei ändert, gibt es dafür mehrere mögliche Erklärungen (in der Reihenfolge ihrer Wahrscheinlichkeit):

  • In die Datei wurde geschrieben.
  • Ihr RAM ist defekt (oder eine andere Motherboard-Komponente, aber RAM ist bei weitem am fehleranfälligsten).
  • Ihr Speicher ist defekt. (Unwahrscheinlich, da defekter Speicher normalerweise zu nicht lesbaren Dateien führt und nicht zu beschädigten Daten.)
  • Ein Kernelfehler, möglicherweise im Dateisystemcode. (Bei ext4 höchst unwahrscheinlich.)

Beachten Sie, dass „Inkonsistenz zwischen Festplatte und Cache“ ein Symptom und keine Ursache ist. Sie haben nicht einmal ein Symptom beobachtet: Was Sie beobachtet haben, war ein Unterschied zwischen dem Speicher zum Zeitpunkt T und dem Speicher zum Zeitpunkt T'.

Wenn Sie sicher sind, dass die Datei nicht geändert wurde, ist defekter RAM die wahrscheinlichste Ursache. Speichertests erkennen fehlerhaften RAM leider nicht immer. Wenn Sie zwei verschiedene Kopien der Datei erhalten können, vergleichen Sie sie ( cmp -l file1 file2); wenn die Unterschiede übereinstimmen (z. B. liegen die Unterschiede immer beim 42. Bit einer 16-Byte-Sequenz) oder aus verschobenen Blöcken bestehen (das Zeichen für eine Beschädigung einer Zeigervariable), deuten alle Zeichen auf defekten RAM hin.

verwandte Informationen