P: MDADM mismatch_cnt> 0. ¿Alguna forma de identificar qué bloques están en desacuerdo?

Bueno. Después de una rutina de limpieza, mi MDADM RAID5 informa que no coincide_cnt = 16. Según tengo entendido, esto significa que si bien ningún dispositivo informó un error de lectura, hay 16 bloques en los que los datos y la paridad no están de acuerdo.

Pregunta # 1: ¿Se puede obtener una lista de estos bloques?

Pregunta # 2: Suponiendo que el # 1 es posible, dado que el sistema de archivos subyacente es EXT4, ¿hay alguna manera de identificar qué archivos están asociados con estos bloques?

Tengo copias de seguridad casi en línea y, en un mundo ideal, podría diferenciar la matriz en vivo contra los datos de la copia de seguridad para localizar cualquier archivo que se haya corrompido silenciosamente. Pero la realidad es recordar que 6 TB de datos de respaldo serían prohibitivamente costosos y lentos. Saber dónde buscar y qué recuperar simplificaría enormemente las cosas.

(Debo señalar que solo ejecuto el exfoliante RAID con la opción 'verificar'. Ejecutar el exfoliante con la opción 'reparar' parece terriblemente peligroso porque MDADM solo sabe que los datos o la paridad son incorrectos, pero no sabe cuál. Parece que hay un 50% de posibilidades de que MDADM adivine mal y reconstruya datos incorrectos. De ahí mi deseo de saber qué archivos están potencialmente afectados para poder restaurarlos desde la copia de seguridad, si es necesario)

Cualquier sugerencia muy apreciada!

linux mdadm

— arcasinky
fuente

comprobar dmesgo / var / log / syslog?

— psusi

Hola. Por lo que puedo decir, los únicos mensajes que el depurador registró en syslog fueron los mensajes de inicio y detención. No se registraron mensajes sobre desajustes.

— arcasinky

Vea icheck+ nchecken debugfspara identificar archivos basados en el desplazamiento del sector.

— sch

Intenté agregar el registro para el número de sector. Ahora estoy tratando de averiguar qué hacer a continuación: unix.stackexchange.com/questions/266432/…

— Peter Cordes

Sé que nada dice que los discos son malos, pero revíselos. Use el paquete smartmontools para hacerlo para cada disco (como en smartctl -a /dev/sday así sucesivamente), o use cualquier otro método para ejecutar una prueba SMART corta en cada disco e imprimir un informe completo. Es muy probable que uno de ellos esté muriendo, y se necesita una gran cantidad de maldad para activar una alarma de salud INTELIGENTE.

— Cola

Lo sentimos, 'check' de hecho vuelve a escribir en la matriz cuando encuentra un error: consulte https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray

'check' es una operación de solo lectura, aunque los registros del kernel sugieran lo contrario (por ejemplo, / proc / mdstat y varios mensajes del kernel mencionarán "resincronización"). Consulte también la pregunta 21 de las preguntas frecuentes.

Sin embargo, si durante la lectura se produce un error de lectura, la verificación activará la respuesta normal a los errores de lectura, que es generar los datos 'correctos' e intentar escribirlos, por lo que es posible que una 'verificación' active un escribir. Sin embargo, en ausencia de errores de lectura, es de solo lectura.

... así que ya puede ser demasiado tarde para recopilar los datos que está buscando, lo siento.

A largo plazo, vale la pena señalar que RAID5 (y 6, y 1) no tienen protección contra la pudrición de bits, que probablemente sea la situación que haya encontrado. Cuando los datos en un disco salen mal, no tienen forma de determinar cuál de los datos es bueno o malo. Sugeriría planear migrar a un sistema de archivos que sume cada disco, como btrfs o zfs.

(RAID-5 realmente no debería usarse en nuevas implementaciones, y realmente no debería donde la capacidad de los discos en bruto es superior a 2 TB cada uno; consulte http://www.zdnet.com/article/why-raid-5- deja de trabajar en 2009 / )

— Andrew W
fuente