Detección y corrección de putrefacción de bits con mdadm

Estoy a punto de reorganizar todos mis discos duros en mi casa linux box nas y me gustaría usar mdadm raid para la protección de datos y su flexibilidad para remodelar los arreglos. Sin embargo, antes de usar mdadm para esto, me gustaría saber cómo se maneja la putrefacción . Específicamente, los tipos de descomposición de bits que no resultan en mensajes de error de lectura irrecuperables enviados desde el HDD.

Dado que probablemente usaré al menos 21 TB de discos duros en 8 discos en las NAS y las diversas citas sobre las probabilidades de fallas en los discos duros, estoy pensando que durante una reconstrucción desde una falla de un solo disco, es probable que me encuentre alguna forma de putrefacción en los discos restantes. Si es un error de lectura irrecuperable en 1 de las unidades, que la unidad realmente lo informa como un error, creo que debería estar bien con raid6 (¿verdad?). Sin embargo, si los datos leídos del disco son incorrectos pero el disco no los informa como tales, entonces no puedo ver cómo esto puede corregirse automáticamente incluso con raid6. ¿Es esto algo de lo que debemos preocuparnos? Dado el artículo , es 2010 y RAID5 todavía funcionay mis propias experiencias exitosas en el hogar y el trabajo, las cosas no son necesariamente tan pesimistas como las palabras de moda y el marketing nos hacen creer, pero odio tener que restaurar desde las copias de seguridad solo porque falló un HDD.

Dado que los patrones de uso serán, escribir como máximo algunas veces y leer ocasionalmente, tendré que realizar un barrido de datos . Veo en el wiki de Archlinux los comandos mdadm para el lavado de datos de una matriz como

echo check > /sys/block/md0/md/sync_action

luego para monitorear el progreso

cat /proc/mdstat

Esto me parece que leerá todos los sectores de todos los discos y verificará que los datos coincidan con la paridad y viceversa. Aunque me doy cuenta de que hay mucho énfasis en los documentos para decir que hay circunstancias importantes en las que la operación de "verificación" no podrá autocorregir, solo detectar y dejará que el usuario corrija.

¿Qué nivel (s) de mdadm RAID debo elegir para maximizar mi protección contra la pudrición de la broca y qué mantenimiento y otros pasos de protección debo realizar? ¿Y de qué no me protegerá esto?

Editar: no estoy buscando iniciar un RAID vs ZFS o cualquier otra tecnología QA. Quiero saber específicamente sobre la incursión mdadm. Por eso también pregunto en Unix y Linux y no en SuperUser .

Editar: es la respuesta: mdadm solo puede corregir los URE informados por los sistemas de disco durante un borrado de datos y detectar la putrefacción silenciosa de los bits durante un fregado, pero no puede / no lo solucionará.

Francamente, me parece bastante sorprendente que rechaces RAIDZ2 ZFS. Parece satisfacer sus necesidades casi a la perfección, excepto por el hecho de que no es Linux MD. No estoy en una cruzada para llevar ZFS a las masas, pero el simple hecho es que el suyo es uno de los tipos de problemas que ZFS fue diseñado desde cero para resolver. Confiar en RAID (cualquier RAID "normal") para proporcionar detección y corrección de errores posiblemente en una situación de redundancia reducida o sin redundancia parece riesgoso. Incluso en situaciones donde ZFS no puede corregir un error de datos correctamente, al menos puede detectar el error y hacerle saber que hay un problema, lo que le permite tomar medidas correctivas.

No tiene que hacer exfoliaciones completas regulares con ZFS, aunque es una práctica recomendada. ZFS verificará que los datos leídos del disco coincidan con lo que se escribió cuando se están leyendo los datos, y en el caso de una falta de coincidencia, (a) utilice redundancia para reconstruir los datos originales o (b) informe un error de E / S a la aplicación. Además, la depuración es una operación en línea de baja prioridad, bastante diferente de la verificación de un sistema de archivos en la mayoría de los sistemas de archivos que pueden ser de alta prioridad y sin conexión. Si está ejecutando un exfoliante y otra cosa que no sea el exfoliante quiere hacer E / S, el exfoliante ocupará el asiento trasero por el tiempo que dure. Un exfoliante ZFS toma el lugar de un exfoliante RAID y un metadato y datos del sistema de archivos verificación de integridad, por lo que es mucho más exhaustivo que simplemente fregar la matriz RAID para detectar cualquier descomposición de bits (lo que no le dice si los datos tienen algún sentido, solo que el controlador RAID los ha escrito correctamente).

La redundancia de ZFS (RAIDZ, duplicación, ...) tiene la ventaja de que no es necesario verificar la coherencia de las ubicaciones de los discos no utilizados durante los scrubs; solo se verifican los datos reales durante los scrubs, ya que las herramientas recorren la cadena de bloques de asignación. Esto es lo mismo que con un grupo no redundante. Para RAID "normal", todos los datos (incluidas las ubicaciones no utilizadas en el disco) deben verificarse porque el controlador RAID (ya sea hardware o software) no tiene idea de qué datos son realmente relevantes.

Al usar RAIDZ2 vdevs, cualquiera de las dos unidades constituyentes puede fallar antes de que corra el riesgo de pérdida de datos real de otra falla de la unidad, ya que tiene el valor de redundancia de dos unidades. Esto es esencialmente lo mismo que RAID6.

En ZFS, todos los datos, tanto los datos de usuario como los metadatos, se suman (excepto si eliges no hacerlo, pero eso se recomienda), y estas sumas de verificación se usan para confirmar que los datos no han cambiado por ningún motivo. Nuevamente, si una suma de verificación no coincide con el valor esperado, los datos se reconstruirán de manera transparente o se informará un error de E / S. Si se informa un error de E / S, o un exfoliante identifica un archivo con corrupción, sabrá con certeza que los datos en ese archivo están potencialmente dañados y puede restaurar ese archivo específico de la copia de seguridad; No es necesario restaurar una matriz completa.

El RAID simple, incluso de doble paridad, no lo protege contra situaciones como, por ejemplo, cuando falla una unidad y una más lee incorrectamente los datos del disco. Suponga que una unidad ha fallado y hay un solo giro en cualquier parte de cualquiera de las otras unidades: de repente, tiene corrupción no detectada y, a menos que esté contento con eso, necesitará una forma de al menos detectarlo. La forma de mitigar ese riesgo es sumar cada bloque en el disco y asegurarse de que la suma de verificación no pueda corromperse junto con los datos (protección contra errores como escrituras de alto vuelo, escrituras huérfanas, escrituras en ubicaciones incorrectas en el disco, etc.), que es exactamente lo que hace ZFS siempre que la suma de comprobación esté habilitada.

El único inconveniente real es que no puede hacer crecer un vdev RAIDZ fácilmente si le agrega dispositivos. Hay soluciones alternativas para eso, que generalmente involucran cosas como archivos dispersos como dispositivos en un vdev, y muy a menudo se denominan "No haría esto si fueran mis datos". Por lo tanto, si va a una ruta RAIDZ (independientemente de si va con RAIDZ, RAIDZ2 o RAIDZ3), debe decidir por adelantado cuántas unidades desea en cada vdev. Aunque el número de unidades en un vdev es fijo, puede hacer crecer un vdev gradualmente (asegurándose de permanecer dentro del umbral de redundancia del vdev) reemplazando las unidades con unidades de mayor capacidad y permitiendo una resistencia completa.

Esta respuesta es el producto del razonamiento basado en las diversas pruebas que he encontrado. No sé cómo funciona la implementación del kernel de Linux, ya que no soy un desarrollador de kernel y parece que hay una gran cantidad de información errónea sin sentido. Supongo que el kernel Linux toma decisiones sensatas. Mi respuesta debería aplicarse a menos que me equivoque.

Muchas unidades utilizan ECC (códigos de corrección de errores) para detectar errores de lectura. Si los datos están corruptos, el núcleo debería recibir un URE (error de lectura irrecuperable) para ese bloque de una unidad de soporte ECC. En estas circunstancias (y hay una excepción a continuación), copiar datos corruptos o vacíos sobre datos buenos equivaldría a locura. En esta situación, el núcleo debe saber cuáles son buenos datos y cuáles son malos. Según el Es 2010 y RAID5 todavía funciona ... artículo:

Considere esta alternativa, que sé que será utilizada por al menos un par de proveedores de arreglos. Cuando una unidad en un volumen RAID informa un URE, el controlador de matriz incrementa un conteo y satisface la E / S al reconstruir el bloque desde la paridad. Luego realiza una reescritura en el disco que informó la URE (potencialmente con verificación) y si el sector es malo, el microcódigo se reasignará y todo estará bien.

Sin embargo, ahora para la excepción: si una unidad no es compatible con ECC, una unidad miente sobre la corrupción de datos, o el firmware es particularmente disfuncional, entonces un URE puede no ser reportado, y los datos corruptos serían entregados al núcleo. En el caso de datos que no coinciden: parece que si está utilizando un RAID1 de 2 discos, o un RAID5, entonces el núcleo no puede saber qué datos son correctos, incluso en un estado no degradado, porque solo hay una paridad bloque y no se informó URE. En un RAID1 de 3 discos o un RAID6, un solo bloque corrupto no marcado con URE no coincidiría con la paridad redundante (en combinación con los otros bloques asociados), por lo que debería ser posible una recuperación automática adecuada.

La moraleja de la historia es: usar unidades con ECC. Desafortunadamente, no todas las unidades que admiten ECC anuncian esta característica. Por otro lado, tenga cuidado: conozco a alguien que usó SSD baratas en un RAID1 de 2 discos (o un RAID10 de 2 copias). Una de las unidades devolvió datos corruptos aleatorios en cada lectura de un sector en particular. Los datos corruptos se copiaron automáticamente sobre los datos correctos. Si el SSD usaba ECC y funcionaba correctamente, entonces el núcleo debería haber tomado las medidas correctivas adecuadas.

Para la protección que desea, iría con RAID6 + la copia de seguridad normal fuera del sitio en 2 ubicaciones.

De todos modos, personalmente friego una vez a la semana y hago copias de seguridad todas las noches, semanalmente y mensualmente, según la importancia de los datos y la velocidad de cambio.

No tengo suficiente representante para comentar, pero quiero señalar que el sistema mdadm en Linux NO corrige ningún error. Si le dice que "corrija" los errores durante una limpieza de, digamos, RAID6, si hay una inconsistencia, lo "arreglará" asumiendo que las porciones de datos son correctas y recalculando la paridad.

pudrición poco fud. seguro...

Supongo que necesitas hablar con SEAGATE. (¿Olvidaste? ¿Esa es la excusa?) todas las unidades ahora tienen una corrección ECC de 100 bits, primero debes probar la podredumbre.
Apuesto a que no puedes. (es algo de lo que preocuparse, ¿verdad?) como el miedo a los fantasmas o el # 13? y no hecho aquí prueba cero sucedió. y peor aún no hay prueba de causa.

Primero defina qué significa bit rot. ouch ... HDD: ECC comprueba los datos (incluso 1 bit) contra el almacenamiento ECC de 100 bits. si está mal, lo corrige, si sigue fallando el motor SMART, seguramente en las unidades SAS, reemplaza lógicamente el clúster o sector con uno que sea bueno. utilizando grupos de repuesto. Esto repara el daño. Sí, todas las unidades se vuelven malas desde el primer día hasta el final, desde las primeras unidades de IBM hasta AHORA. pero ahora nos reparamos a nosotros mismos. Lea los informes técnicos completos de Seagate. interminable allí, y aprender cómo funciona un disco. ¿De acuerdo?

esto continúa hasta que te quedas sin repuestos (hdd brain, smart) y luego SMART grita FIN DE LA VIDA. (o incluso más temprano, como lo hace HP) en un controlador HP P420, mira esto todo el tiempo. El mío incluso me envía un correo electrónico, mostrándome GRUPOS CERCA DE RECAMBIO En algún momento, los repuestos van mucho más rápido, un signo seguro de fatalidad pronto (10 años seguro, menos en sata de chatarra).

Llamo a BOGUS y FUD en putrefacción.

Mi conjetura es que una PC de juguete escribió los datos incorrectamente, por cualquier razón. no ejecuta memoria ECC? Uy, los servidores reales tienen RAM ECC. virus infectado? o perdió energía durante la escritura (sin UPS>?)? o tiene mala memoria? o ESD dañado. O PSU haciendo mucho ruido (malo)

Llamo a FUD aquí. lo siento,