Toutes les réponses ci-dessus sont incorrectes en ce qui concerne 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 lecteur est corrompu, même sans erreur indiquée par le lecteur, il peut être détecté ET CORRIGÉ. L'algorithme pour ce faire est complètement expliqué dans
https://mirrors.edge.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Pour 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.
En outre, si l'identification du lecteur concerne 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 d'erreur non corrigible. Lorsqu'il y a beaucoup moins de 256 lecteurs dans l'ensemble, cela est détecté avec une forte probabilité par octet, et puisqu'il y a beaucoup d'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, là encore, plusieurs lecteurs fournissent des données corrompues, et généralement on peut rejeter la condition, mais tant que toutes les identifications de 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 cela ne doit être effectué qu'avec le syndrome (P et Q), le calcul montre une erreur.
Tout cela étant dit, cependant, je n'ai pas examiné le code mdadm pour déterminer si la corruption à un octet est gérée. Je suis conscient que mdadm signale des erreurs de syndrome RAID6 sur l'analyse mensuelle, mais à partir du message d'erreur, il n'est pas clair si elles sont corrigées - cela n'arrête pas la matrice de disques ni n'identifie aucun disque particulier dans le message.