2016-04-29 3 views
1

Ich habe zwei relativ neue 4T-Festplatten (WD Data Center Re WD4000FYYZ) als btrfs mit Raid1-Daten und Raid1-Metadaten formatiert.btrfs unkorrigierbarer Fehler bei unmodifizierter Datei nach dem Scrubben

Ich kopierte eine große Binärdatei auf das Volume (~ 76 GB). Bald nach dem Kopieren der Datei, habe ich einen Btrfs-Scrub ausgeführt. Es gab keine Fehler.

Einige Monate später gab eine Bereinigung einen nicht behebbaren Fehler für diese Datei zurück. Es wurde nicht geändert, seit es ursprünglich kopiert wurde. Ich könnte hinzufügen, dass die SMART-Attribute für beide Laufwerke keine Fehler anzeigen (Current_Pending_Sector oder anders).

Das System mit den Laufwerken hat keinen ECC-Speicher.

Das einzige, was ich denken kann, dass diese Art von Fehler ist, dass beim Schreiben in eine andere Datei, deren Daten Prüfsummen im selben Block wie einige der Prüfsummen für die große Datei enthalten waren, einige Beschädigungen im Speicher aufgetreten Dadurch konnten fehlerhafte Daten eine oder mehrere Prüfsummen für die große Datei verschmutzen.

Leider hatte ich bei der Migration zu btrfs gehofft, dass sobald Daten geladen und erfolgreich geschrubbt wurden, Sie sicher sein konnten, dass es so bleiben würde, wenn es nicht geschrieben wäre (in raid1/5/6 Konfiguration natürlich). Offensichtlich ist dies nicht der Fall.

Kann mir jemand erklären, wie das hätte passieren können? Wenn ich einen Snapshot des Volumes gemacht hätte, das die große Datei enthielt, hätte ich dann noch Zugriff auf die ursprünglichen, unverfälschten Daten aus dem Snapshot?

+0

Haben Sie Memtest ausgeführt? Vielleicht Badblocks? Wurde der Dateiname in dmesg erwähnt? Ist das in einem VM, durch Zufall? Sind andere Dateien/Inodes ebenfalls beschädigt? Ist etwas Besonderes geschehen, bevor es beschädigt wurde, war das System unter hoher Last oder etwas? – basic6

+0

Ich hatte umfangreiche Diskussionen auf der Btrfs-Mailing-Liste, nachdem ich das gepostet habe. Ich hatte tatsächlich einen schlechten Speicherchip. Gelegentlich würden ein oder mehrere Bits einen Kontrollsummenblock verfälschen. Die Daten selbst waren gut, aber die gespiegelten Prüfsummen waren aufgrund eines stillen Speicherfehlers schlecht. Ich habe den Widder ersetzt und das Problem ist nicht wieder aufgetaucht. –

+0

Nun, das erklärt es. Ein schlechter Speicher kann alle Arten von Schaden verursachen. Dies würde nicht wegen Btrfs passieren. Tatsächlich hat btrfs Ihnen geholfen, das Speicherproblem zu finden, und es hat Ihnen auch gesagt, welche Dateien beschädigt wurden. Ich schlage vor, dass Sie dies als Antwort auf Ihre Frage veröffentlichen. – basic6

Antwort

1

Diese stille Datenkorruption wurde durch einen fehlerhaften Speicherstick verursacht. Die Erinnerung wurde ersetzt und das Problem ist nicht mehr aufgetreten.