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

17

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á.

BeowulfNode42
fuente
En cuanto a la protección de datos, el principal beneficio que veo en zfs es que elimina las ubicaciones de disco de los archivos cada vez que lee un archivo. Es por eso que actualmente lo tengo configurado con zfs. Pero todavía necesito realizar exfoliaciones completas regulares de todos modos. Tengo 2 grupos de zfs cada uno con 3 discos, y quiero actualizar a un sistema de 8 discos donde cualquier unidad puede fallar y todavía habrá 1 unidad redundante más y zfs no es flexible para permitir una reforma como esa. Como estoy reconstruyendo de todos modos, estoy volviendo a visitar mdadm.
BeowulfNode42
Has tenido suerte con RAID5 / 6 hasta ahora. El hecho es que es 2013 y RAID todavía sufre de un agujero de escritura. Si pierde energía después de que se escriben los datos, pero antes de que se escriba la paridad, acaba de corromper sus datos buenos y es posible que con la inconsistencia de que su matriz también sea tostada. Gracias RAID5.
bahamat
La cuestión es que lo que quieres hacer es hacerlo mejor en la capa del sistema de archivos. De lo contrario, necesitaría alguna forma de detectar y preferiblemente corregir la pudrición de bits, posiblemente en una situación de redundancia reducida o sin redundancia, y RAID simplemente no es adecuado para eso. No solo no hay garantía de que no terminará con la putrefacción de bits de todos modos (¿qué pasa si una unidad falla y otra lee el bit incorrectamente del disco?), Sino que RAID simple tampoco tiene un concepto de qué datos son importantes y qué es solo ruido Dado que ZFS solo elimina los datos de referencia , la descomposición de bits en una parte no utilizada del disco se convierte en un problema.
un CVn
Realmente, no puede esperar superponer un sistema de archivos aleatorio sobre múltiples discos (incluso con redundancia) para protegerlo repentinamente contra fallas de almacenamiento. No estoy en una cruzada sagrada para traer ZFS a las masas (aunque creo que es una gran invención, y lo uso yo mismo en Linux para básicamente todo menos la partición raíz, que es ext4 en mdraid1 por compatibilidad de software), pero También reconozco que el suyo es uno de los tipos de problemas que ZFS fue diseñado desde cero para resolver: detección garantizada y, si es posible, reparación de corrupción de datos independientemente de la causa.
un CVn
Creo que deberías revisar tus requisitos. ¿Realmente necesita protección bitrot incluso para el caso en que se aplica la corrección de errores? ¿Sabes cuán improbable es que exista un bitrot DADO que también fue corregido por el ECC del disco?
hombre de las cavernas

Respuestas:

5

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.

un CVn
fuente
55
En mi pregunta original, estaba tratando de evitar el argumento zfs vs raid ya que hay mucha información al respecto. Quiero información específica sobre mdadm. Además, dado que no leeré todos los datos con la suficiente frecuencia como para asegurarme de que los datos se eliminen regularmente, tendré que forzar un depuración de matriz completa con regularidad, independientemente de zfs o raid.
BeowulfNode42
@ BeowulfNode42 personalmente sugiero usar sumas de comprobación de la capa de aplicación para datos excepcionalmente importantes (por ejemplo, use sha256 para sumar sus datos importantes). ZFS puede hacer esto por bloque, lo que creo que es realmente una exageración. Creo que esto explica por qué no muchos sistemas de archivos suman sus bloques de verificación como lo hace ZFS porque, en mi opinión, esto es más un problema de la capa de aplicación.
hombre de las cavernas
1
@ Caveman No sé sobre ti; Realmente me gusta el hecho de que no tengo que revisar constantemente los archivos de suma para asegurarme de que no se hayan dañado. Claro, la gran mayoría de las veces no hay corrupción , en cuyo caso no se hace daño (con ZFS, puede elegir su algoritmo de suma de verificación entre un puñado, por lo que puede elegir su punto preferido a lo largo del continuo de seguridad / rendimiento), pero las sumas de comprobación automatizadas a nivel del sistema de archivos garantizan que no haya corrupción no corregida porque si la hay, lo sabrá, en el caso de ZFS al recibir un error de E / S en lugar de datos corruptos.
un CVn
@ MichaelKjörling no, no "garantiza" (solo reduce la probabilidad de errores no detectados en relación con las comprobaciones de solo disco, ¡en una cantidad que nadie ha cuantificado todavía! Por lo tanto, nadie sabe realmente cuán útil es la suma de comprobación de ZFS :)), más puede usar envoltorios simples de "lectura" y "escritura" que hacen la suma de comprobación de forma transparente por usted. Uno no necesita poner esta cosa elegante en el espacio del kernel.
hombre de las cavernas
3
@caveman no, zfs no está en el tema. Tampoco son posibles implementaciones de RAID que no sean mdadm. Quiero saber sobre mdadm. Ya he rechazado esta respuesta tanto como puedo y sus comentarios sobre una respuesta fuera del tema que completan más información sobre la respuesta fuera del tema no ayudan con la pregunta original.
BeowulfNode42
3

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.

sudoman
fuente
1
Pensé que todos los discos duros modernos tienen alguna forma de ECC interno. Si es o no efectivo, correcto o funciona mal es otro asunto. El ECC debe usarse internamente en la unidad para poder informar un URE. La putrefacción silenciosa, que es lo que más me interesa, no informa un URE incluso en unidades que lo admiten, ya que piensan que tienen los datos correctos, cuando no los tienen.
BeowulfNode42
Por pudrición de bits, supongo que te refieres a bits volteando al azar. En cualquier caso, el ECC está diseñado para detectar bits invertidos. Según Wikipedia, la corrección de errores Reed – Solomon es un formato ECC común inventado en 1960 y todavía se usa en discos Blu-Ray + HDD. Si descubres que ese algoritmo es extremadamente confiable, entonces tu pregunta debería ser respondida, ya que el hardware moderno decente, por definición, es igual de bueno, si no mejor, incluso si no conoces la decencia de una pieza de hardware simplemente por mirándolo.
sudoman
1
La pudrición de bits también puede ocurrir debido a otros problemas, como cuando algún problema hace que los cabezales de la unidad no se alineen correctamente donde cree que está escribiendo y se extienda a los sectores cercanos. Puede arreglar el sector en el que pretendía trabajar, pero el sector cercano se dañará. Si sucede que ha escrito sobre los datos + ecc de tal manera que el ECC para el sector cercano informa que está bien, entonces la unidad nunca sabrá que tiene un problema. Es mucho más probable que algún software no autorizado le indique al disco que escriba datos incorrectos, el disco duro almacenará fielmente esos datos incorrectos. por ejemplo, un comando dd incorrecto
BeowulfNode42
2

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.

djsmiley2k en la oscuridad
fuente
1
pero, ¿qué capacidades de detección / corrección de putrefacción de bit ofrece eso?
BeowulfNode42
1
RAID6 con fregado frecuente ofrece cierta protección contra la descomposición de bits, ya que la doble paridad crea efectivamente tres versiones del mismo bloque, por lo que se puede realizar una "votación" sobre la versión correcta. AFAIK, el lavado RAID6 en linux dm-raid hace exactamente eso, corrígeme si me equivoco.
P.Péter
1
@ P.Péter Me doy cuenta de que las matemáticas involucradas PODRÍAN usar un sistema de votación, pero ¿mdadm? ¿Conoce alguna documentación sobre esto o ha tenido una experiencia personal que lo haya llevado a esta conclusión? Particularmente a la luz de la respuesta de Ethan.
BeowulfNode42
Esto fue hace algún tiempo, pero recuerdo vagamente haber leído sobre los mecanismos mdadm RAID6 antes de comentar. Lo siento, no muy específico. :( Creo que podríamos usar un verdadero experto en mdadm ...
P.Péter
2

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.

Ethan
fuente
1
Esto parece bastante improbable, a menos que te malinterprete. ¿Quiere decir que los datos de los bloques dañados a menudo se copian sobre los bloques correctos? Para ello sería necesario que el bloque defectuoso no proviene de una unidad que soporta ECC (y por lo tanto no informar de una URE), y que está utilizando RAID 5 o RAID 1, 2 copias (en lugar de RAID6 como usted sugiere.)
sudoman
@sudoman, durante un fregado, si el subsistema Linux MD detecta una falta de coincidencia entre los datos y la paridad, asume ciegamente que la paridad es incorrecta y la reescribe en función de los datos. Es posible utilizar la doble paridad de RAID 6 para determinar cuál es el problema, pero el subsistema Linux MD no hace esto.
Mark
1
Ethan, supongo que no tienes referencias para esta información. o ejemplos de experiencia personal que estás dispuesto a compartir lo que recuerdas? Dadas las plantas rodadoras que ha generado esta Q, incluso la información anecdótica sería útil. Desde que se publicó este Q, he tenido algunos problemas con mdadm RAID1 para la unidad de arranque, en memorias USB (baratas) cuando 1 de ellas salió mal. Posteriormente, algunas investigaciones apuntan a que el dispositivo USB que falla no tiene suficiente verificación de error, o simplemente no pudo escribir datos en algunos bloques y no produjo un error de escritura. Tuve que reinstalar el sistema operativo.
BeowulfNode42
-2

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,

savvy2
fuente
1
Acabo de aclarar que estaba hablando de mi sistema doméstico, por lo que el hardware de grado ECC y de servidor está fuera de mi rango de precio económico. El laboratorio de mi casa es mucho más propenso a la pérdida inesperada de energía, incluso con sus mini ups u otros eventos aleatorios, como la caída de la torre o algo así. Hay muchas otras formas para que se le diga a un HDD que almacene los datos incorrectos y que el HDD almacene los bits de ECC para esos datos incorrectos. No me importa cómo ocurrieron los errores, quiero que se solucionen fácilmente.
BeowulfNode42