Lösung 1:
Linux-Software-RAID schützt Sie nicht vor Bitkorruption, und stille Datenkorruption ist ein bekanntes Problem damit. Wenn der Kernel in der Lage ist, die Daten von einer Festplatte zu lesen, würde er niemals wissen, dass sie schlecht ist. Das RAID greift nur ein, wenn beim Lesen der Daten ein E/A-Fehler auftritt.
Wenn Sie sich Sorgen um die Datenintegrität machen, sollten Sie die Verwendung eines Dateisystems wie Btrfs oder ZFS in Betracht ziehen, das die Datenintegrität durch Speichern und Überprüfen von Prüfsummen gewährleistet. Diese Dateisysteme kümmern sich auch um die RAID-Funktionalität, sodass Sie das Kernel-Software-Raid nicht benötigen, wenn Sie diesen Weg gehen.
Lösung 2:
RAID5 und RAID6 können Bitfehler erkennen und normalerweise korrigieren, wenn Sie die Parität des gesamten Laufwerks überprüfen. Dies wird als „Scrubbing“ oder „Paritätsprüfung“ bezeichnet und dauert bei den meisten Produktions-RAID-Systemen normalerweise 24–48 Stunden. Während dieser Zeit kann die Leistung erheblich beeinträchtigt werden. (Bei einigen Systemen kann der Bediener das Scrubbing über den Lese-/Schreibzugriff oder darunter priorisieren.) RAID6 hat eine höhere Chance, es zu korrigieren, weil es es korrigieren kann, wenn Sie zwei Laufwerksfehler haben, während RAID5 nur 1 Laufwerksfehler verarbeiten kann, und Laufwerksausfälle sind aufgrund der erhöhten Aktivität wahrscheinlicher, wenn Sie scrubben.
Lösung 3:
Ich hätte dies als Kommentar hinzugefügt, aber ich habe keinen ausreichenden Ruf. Ich wollte klarstellen:RAID5 kann Bit-Korruption ERKENNEN, aber es weiß nicht, welches Laufwerk die Beschädigung ohne einen Lesefehler aufweist. Infolgedessen könnte ein Scrub dies nicht ohne einen Lesefehler beheben - es würde ihn höchstwahrscheinlich nur protokollieren und das Paritätsbit entsprechend aktualisieren. Der Algorithmus von RAID6 ist positionsabhängig, sodass er erkennen kann, welches Laufwerk den Fehler enthält, und die Bitbeschädigung korrigieren kann.
Lösung 4:
Alle obigen Antworten sind in Bezug auf die Fähigkeiten von RAID 6 falsch. RAID 6-Algorithmen arbeiten Byte für Byte genau wie RAID 5, und wenn ein einzelnes Byte auf einem Laufwerk beschädigt ist, kann dies der Fall sein, selbst wenn das Laufwerk keinen Fehler anzeigt erkannt und korrigiert werden. Der Algorithmus dafür ist vollständig erklärt in
https://mirrors.edge.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Um diese Prüfung durchzuführen, müssen auch die Paritätslaufwerke P und Q zusammen mit den Datenlaufwerken gelesen werden. Wenn sich die berechneten Paritäten P' und Q' ohne Laufwerksfehler unterscheiden, kann eine Analyse feststellen, welches der Laufwerke falsch ist, und die Daten korrigieren.
Wenn die Laufwerksidentifikation zu einem Laufwerk gehört, das nicht vorhanden ist (z. B. Laufwerk 137, wenn nur 15 Laufwerke vorhanden sind), liefert mehr als ein Laufwerk beschädigte Daten FÜR DIESES BYTE, was einen nicht korrigierbaren Fehler signalisiert. Wenn der Satz viel weniger als 256 Laufwerke enthält, wird dies mit hoher Wahrscheinlichkeit pro Byte erkannt, und da es viele Bytes in einem Block gibt, mit extrem hoher Wahrscheinlichkeit pro Block. Wenn die Laufwerksidentifikation nicht für alle Bytes innerhalb des RAID-Blocks konsistent ist, liefert wiederum mehr als ein Laufwerk beschädigte Daten, und im Allgemeinen könnte man die Bedingung ablehnen, aber solange alle Laufwerksidentifikationen gültig sind, muss der Block nicht unbedingt abgelehnt werden.
Die Durchführung dieser Korrektur dauert länger als die übliche Überprüfungszeit, muss aber nur durchgeführt werden, wenn die Berechnung des Syndroms (P und Q) einen Fehler aufweist.
Abgesehen davon habe ich jedoch den mdadm-Code nicht untersucht, um festzustellen, ob eine Einzelbyte-Korruption behandelt wird. Mir ist bekannt, dass mdadm beim monatlichen Scan RAID6-Syndrom-Fehler meldet, aber aus der Fehlermeldung geht nicht hervor, ob sie korrigiert werden – es stoppt weder das Drive Array noch identifiziert es ein bestimmtes Laufwerk in der Nachricht.