Solution 1 :
Le RAID logiciel Linux ne vous protégera pas de la corruption de bits et la corruption silencieuse des données est un problème bien connu. En fait, si le noyau est capable de lire les données d'un disque, il ne saura jamais qu'il est mauvais. Le RAID ne s'active qu'en cas d'erreur d'E/S lors de la lecture des données.
Si vous vous inquiétez de l'intégrité des données, vous devriez envisager d'utiliser un système de fichiers comme Btrfs ou ZFS qui garantit l'intégrité des données en stockant et en vérifiant les sommes de contrôle. Ces systèmes de fichiers prennent également en charge la fonctionnalité RAID, vous n'avez donc pas besoin du raid logiciel du noyau si vous suivez cette voie.
Solution 2 :
RAID5 et RAID6 peuvent détecter et généralement corriger la corruption de bits si vous vérifiez la parité de l'ensemble du lecteur. Cela s'appelle "nettoyage" ou "vérification de parité" et prend généralement 24 à 48 heures sur la plupart des systèmes RAID de production. Pendant ce temps, les performances peuvent être considérablement dégradées. (Certains systèmes permettent à l'opérateur de donner la priorité au nettoyage par rapport à l'accès en lecture/écriture ou en dessous.) RAID6 a plus de chances de le corriger, car il peut le corriger si vous avez deux pannes de disque, alors que RAID5 ne peut gérer qu'une panne de disque, et les pannes de disque sont plus probables lorsque vous nettoyez en raison de l'activité accrue.
Solution 3 :
J'aurais ajouté ceci comme commentaire mais je n'ai pas une réputation suffisante; Je voulais clarifier:RAID5 peut DÉTECTER la corruption de bits mais il ne sait pas quel lecteur est corrompu sans erreur de lecture. Par conséquent, un nettoyage ne pourrait pas résoudre ce problème sans erreur de lecture - il se contenterait probablement de l'enregistrer et de mettre à jour le bit de parité pour qu'il corresponde. L'algorithme de RAID6 dépend de la position afin qu'il puisse détecter quel lecteur contient l'erreur et corriger la corruption de bits.
Solution 4 :
Toutes les réponses ci-dessus sont incorrectes concernant les capacités de RAID 6. Les algorithmes RAID 6 fonctionnent octet par octet tout comme RAID 5, et si un seul octet sur un disque est corrompu, même sans erreur indiquée par le disque, il peut être détecté ET CORRIGÉ. L'algorithme pour le faire est complètement expliqué dans
https://mirrors.edge.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Afin d'effectuer cette vérification, les lecteurs de parité P et Q doivent également être lus avec les lecteurs de données. Si la parité calculée P' et Q' diffère sans erreur de lecteur, une analyse peut identifier lequel des lecteurs est incorrect et corriger les données.
De plus, si l'identification du lecteur correspond à un lecteur qui n'est pas présent (tel que le lecteur 137 s'il n'y a que 15 lecteurs), plusieurs lecteurs fournissent des données corrompues POUR CET OCTET, signalant une erreur non corrigible. Lorsqu'il y a beaucoup moins de 256 lecteurs dans l'ensemble, cela est détecté avec une probabilité élevée par octet, et comme il y a de nombreux octets dans un bloc, avec une probabilité extrêmement élevée par bloc. Si l'identification du lecteur n'est pas cohérente pour tous les octets du bloc RAID, encore une fois, plus d'un lecteur fournit des données corrompues, et généralement on peut rejeter la condition, mais tant que toutes les identifications du lecteur sont valides, le bloc n'a pas nécessairement besoin être rejeté.
Il faut plus de temps que le temps de vérification habituel pour effectuer cette correction, mais elle ne doit être effectuée que lorsque le calcul du syndrome (P et Q) indique une erreur.
Tout cela étant dit, cependant, je n'ai pas examiné le code mdadm pour déterminer si la corruption d'un seul octet est gérée. Je suis conscient que mdadm signale des erreurs de syndrome RAID6 lors de l'analyse mensuelle, mais d'après le message d'erreur, il n'est pas clair si elles sont corrigées - cela n'arrête pas la matrice de disques et n'identifie aucun disque particulier dans le message.