Solución 1:
El software RAID de Linux no lo protegerá de la corrupción de bits y la corrupción silenciosa de datos es un problema bien conocido. De hecho, si el núcleo es capaz de leer los datos de un disco, nunca sabrá que es malo. El RAID solo se activa si hay un error de E/S al leer los datos.
Si le preocupa la integridad de los datos, debería considerar el uso de un sistema de archivos como Btrfs o ZFS que garantizan la integridad de los datos al almacenar y verificar las sumas de verificación. Estos sistemas de archivos también se encargan de la funcionalidad RAID, por lo que no necesita la incursión del software del kernel si elige ese camino.
Solución 2:
RAID5 y RAID6 pueden detectar y, por lo general, corregir la corrupción de bits si verifica la paridad de toda la unidad. Esto se denomina "depuración" o "comprobación de paridad" y suele tardar entre 24 y 48 horas en la mayoría de los sistemas RAID de producción. Durante ese tiempo, el rendimiento puede verse significativamente degradado. (Algunos sistemas permiten que el operador priorice la limpieza sobre el acceso de lectura/escritura o por debajo de él). RAID6 tiene una mayor probabilidad de corregirlo, porque puede corregirlo si tiene dos fallas en la unidad, mientras que RAID5 solo puede manejar una falla en la unidad, y las fallas de la unidad son más probables cuando está limpiando debido al aumento de la actividad.
Solución 3:
Hubiera agregado esto como un comentario pero no tengo suficiente reputación; Quería aclarar:RAID5 puede DETECTAR corrupción de bits pero no sabe qué unidad tiene la corrupción sin un error de lectura. Como resultado, un borrado no pudo solucionar esto sin un error de lectura; lo más probable es que simplemente lo registre y actualice el bit de paridad para que coincida. El algoritmo de RAID6 depende de la posición, por lo que puede detectar qué unidad contenía el error y corregir la corrupción de bits.
Solución 4:
Todas las respuestas anteriores son incorrectas con respecto a las capacidades de RAID 6. Los algoritmos de RAID 6 funcionan byte a byte como RAID 5, y si un solo byte en cualquier disco está dañado, incluso si el disco no indica ningún error, puede ser detectado Y CORREGIDO. El algoritmo para hacerlo se explica completamente en
https://mirrors.edge.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf
Para realizar esta verificación, las unidades de paridad P y Q también deben leerse junto con las unidades de datos. Si la paridad calculada P' y Q' difiere sin errores de unidad, un análisis puede identificar cuál de las unidades es incorrecta y corregir los datos.
Además, si la identificación de la unidad es para una unidad que no está presente (como la unidad 137 si solo hay 15 unidades), más de una unidad proporciona datos corruptos PARA ESE BYTE, lo que indica un error incorregible. Cuando hay mucho menos de 256 unidades en el conjunto, esto se detecta con una alta probabilidad por byte y, dado que hay muchos bytes en un bloque, con una probabilidad extremadamente alta por bloque. Si la identificación de la unidad no es consistente para todos los bytes dentro del bloque RAID, nuevamente, más de una unidad está proporcionando datos dañados y, en general, uno podría rechazar la condición, pero siempre que todas las identificaciones de la unidad sean válidas, el bloque no necesariamente tiene que ser rechazado.
Lleva más tiempo que el tiempo de verificación habitual realizar esta corrección, pero solo debe realizarse con el cálculo del síndrome (P y Q) que muestra un error.
Dicho todo esto, sin embargo, no he examinado el código mdadm para determinar si se maneja la corrupción de un solo byte. Soy consciente de que mdadm informa errores del síndrome RAID6 en el análisis mensual, pero a partir del mensaje de error no está claro si se están corrigiendo; no detiene la matriz de unidades ni identifica ninguna unidad en particular en el mensaje.