Resumen de TL; DR : traduzca un número de sector de md en compensaciones dentro del /dev/mdXdispositivo y cómo investigarlo xfs_db. El número de sector es de sh->sectoradentro linux/drivers/md/raid5.c:handle_parity_checks5().
No conozco las partes internas de MD, por lo que no sé exactamente qué hacer con la salida del printkregistro que agregué.
Las compensaciones en los dispositivos componentes (para ddo un editor / visor hexadecimal) también serían interesantes.
Supongo que debería preguntar esto en la lista de correo de incursiones de Linux. ¿Es solo para suscriptores, o puedo publicar sin suscribirme?
Tengo xfs directamente sobre MD RAID5 de 4 discos en mi escritorio (sin LVM). Un matorral reciente detectó un valor distinto de cero mismatch_cnt(8 de hecho, porque md opera en páginas de 4 kB a la vez).
Este es un RAID5, no RAID1 / RAID10 donde mismatch_cnt! = 0 puede ocurrir durante la operación normal . (Los otros enlaces en la parte inferior de esta página wiki pueden ser útiles para algunas personas).
Podría hacerlo a ciegas repair, pero no tendría idea de qué archivo verificar para detectar posibles daños, además de perder cualquier oportunidad de elegir qué camino reconstruir. La respuesta de Frostschutz a una pregunta similar es la única sugerencia que encontré para rastrear una diferencia en el sistema de archivos. Es engorroso y lento, y prefiero usar algo mejor para reducirlo primero a unos pocos archivos.
Parche de kernel para agregar registro
Curiosamente, la función de verificación de md no informa dónde se encontró un error . Agregué un printkmd / raid5.c para iniciar sesión sh->sectoren la iframa que se incrementa mddev->resync_mismatchesenhandle_parity_checks5() (pequeño parche publicado en github , originalmente basado en 4.5-rc4 de kernel.org). Para que esto sea correcto para uso general, probablemente sea necesario evite inundar los registros en reparaciones con muchos desajustes (tal vez solo registre si el nuevo valor de resync_mismatcheses <1000?). También tal vez solo inicie sesión checky no repair.
Estoy bastante seguro de que estoy registrando algo útil (¡aunque no conozco los componentes internos de MD!), Porque la misma función imprime ese número de sector en el caso de manejo de errores delswitch .
Compilé mi kernel modificado y lo arranqué, luego volví a ejecutar el cheque:
[ 399.957203] md: data-check of RAID array md125
...
[ 399.957215] md: using 128k window, over a total of 2441757696k.
...
[21369.258985] md/raid:md125: check found mismatch at sector 4294708224 <-- custom log message
[25667.351869] md: md125: data-check done.
Ahora no sé exactamente qué hacer con ese número de sector. ¿Hay sh->sector * 512una dirección lineal dentro /dev/md/t-r5(aka /dev/md125)? ¿Es un número de sector dentro de cada dispositivo componente (por lo que se refiere a tres datos y un sector de paridad)? Supongo que esto último, ya que una falta de coincidencia de paridad en RAID5 significa que los sectores N-1 del dispositivo md están en peligro, compensados entre sí por la unidad de banda. ¿Es el sector 0 el comienzo mismo del dispositivo componente, o es el sector después del superbloque o algo así? ¿Hubo más información handle_parity_checks5()que debería haber calculado / registrado?
Si quisiera obtener solo los bloques que no coinciden, ¿es esto correcto?
dd if=/dev/sda6 of=mmblock.0 bs=512 count=8 skip=4294708224
dd if=/dev/sdb6 of=mmblock.1 bs=512 count=8 skip=4294708224
dd if=/dev/sda6 of=mmblock.2 bs=512 count=8 skip=4294708224
dd if=/dev/sdd of=mmblock.3 bs=512 count=8 skip=4294708224 ## not a typo: my 4th component is a smaller full-disk
# i.e.
sec_block() { for dev in {a,b,c}6 d; do dd if=/dev/sd"$dev" of="sec$1.$dev" skip="$1" bs=512 count=8;done; }; sec_block 123456
Supongo que no, porque obtengo 4k de ceros de los cuatro componentes de la incursión y 0^0 == 0, por lo tanto, esa debería ser la paridad correcta, ¿verdad?
Otro lugar en el que he visto mencionar el uso de direcciones de sector en md es para sync_miny sync_max(en sysfs). Neil Brown en la lista de incursiones de Linux , en respuesta a una pregunta sobre una unidad fallida con números de sector de hdrecover, donde Neil utilizó el número de sector de disco completo como un número de sector de MD. Eso no está bien, ¿verdad? ¿No serían los números de sector md relativos a los dispositivos componentes (particiones en ese caso), no al dispositivo completo del que forma parte la partición?
sector lineal a nombre de archivo XFS:
Antes de darme cuenta de que el número de sector md era probablemente para los componentes, no para el dispositivo RAID, intenté usarlo en solo lectura xfs_db:
La breve sugerencia de Dave Chinner sobre cómo encontrar cómo XFS está utilizando un bloque dado no me pareció en absoluto útil. (Hubiera esperado algún tipo de resultado, para algún sector, ya que el número no debería estar más allá del final del dispositivo, incluso si no es el sector no coincidente)
# xfs_db -r /dev/md/t-r5
xfs_db> convert daddr 4294708224 fsblock
0x29ad5e00 (699227648)
xfs_db> blockget -nv -b 699227648
xfs_db> blockuse -n # with or without -c 8
must run blockget first
eh? ¿Qué estoy haciendo mal aquí? Supongo que esta debería ser una pregunta separada. Reemplazaré esto con un enlace si / cuando lo pregunto o encuentro una respuesta a esta parte en otro lugar.
Mi RAID5 está esencialmente inactivo, sin actividad de escritura y lectura mínima (y noatime, por lo tanto, las lecturas no producen escrituras).
Cosas adicionales sobre mi configuración, nada importante aquí
Muchos de mis archivos son videos u otros datos comprimidos que brindan una manera efectiva de saber si los datos son correctos o no (ya sea sumas de verificación internas en el formato de archivo o simplemente si se decodifica sin errores). Eso haría viable este método de bucle invertido de solo lectura , una vez que sepa qué archivo verificar. Sin embargo, no quería ejecutar una diferencia de 4 vías de cada archivo en el sistema de archivos para encontrar la discrepancia, cuando el núcleo tiene la información necesaria durante la verificación, y podría registrarla fácilmente.
mi /proc/mdstatpara mi matriz de datos masivos:
md125 : active raid5 sdd[3] sda6[0] sdb6[1] sdc6[4]
7325273088 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/19 pages [0KB], 65536KB chunk
Está en particiones en tres unidades Toshiba de 3 TB y en una unidad WD25EZRS de energía verde (lenta) no particionada que estoy reemplazando por otra Toshiba. (Solía mdadm --replacehacerlo en línea sin vacíos en la redundancia. Después de una copia me di cuenta de que debería verificar el estado de RAID antes y después para detectar problemas. Fue entonces cuando detecté la falta de coincidencia. Es posible que haya existido durante mucho tiempo , ya que tuve algunos bloqueos hace casi un año, pero no tengo registros antiguos y mdadm no parece enviar correos sobre esto por defecto (Ubuntu 15.10).
Mis otros sistemas de archivos están en dispositivos RAID10f2 hechos de particiones anteriores en los tres HD más grandes (y RAID0 para / var / tmp). El RAID5 es solo para almacenamiento masivo, no /homeo /.
Mis unidades están bien: los recuentos de errores SMART son 0 todos los contadores de bloques defectuosos en todas las unidades, y se superaron las pruebas automáticas SMART cortas + largas.
casi duplicados de esta pregunta que no tienen respuestas:
- ¿Qué fragmentos no coinciden en una matriz md de Linux?
- http://www.spinics.net/lists/raid/msg49459.html
- MDADM mismatch_cnt> 0. ¿Alguna forma de identificar qué bloques están en desacuerdo?
- Otras cosas ya están vinculadas en línea, pero sobre todo la idea de loopback de solo lectura de frostschutz .
- fregar en la página RAID de Arch wiki
.damagedo algo así, en lugar de saber que probablemente hay un archivo roto en alguna parte.
mdadm -E /dev/xxx.