Synology tiene una versión personalizada del controlador md y los conjuntos de herramientas mdadm que agrega un indicador 'DriveError' a la estructura rdev-> flags en el kernel.
Efecto neto: si tiene la mala suerte de tener una falla en la matriz (primera unidad), combinada con un error en una segunda unidad, la matriz entra en el estado de no permitirle reparar / reconstruir la matriz a pesar de que las lecturas de la unidad están funcionando multa.
En este punto, no estoy realmente preocupado por esta pregunta desde el punto de vista de ESTA matriz, ya que ya saqué el contenido y tengo la intención de reconstruirlo, pero más de querer tener una ruta de resolución para esto en el futuro , ya que es la segunda vez que me muerde, y sé que he visto a otros hacer preguntas similares en foros.
El soporte de Synology ha sido menos que útil (y en su mayoría no responde), y no compartirá NINGUNA información en absoluto sobre el manejo de las incursiones en la caja.
Contenido de / proc / mdstat:
ds1512-ent> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]
md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
2097088 blocks [5/5] [UUUUU]
md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
2490176 blocks [5/5] [UUUUU]
unused devices: <none>
Estado de un mdadm --detail / dev / md2:
/dev/md2:
Version : 1.2
Creation Time : Tue Aug 7 18:51:30 2012
Raid Level : raid5
Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent
Update Time : Fri Jan 17 20:48:12 2014
State : clean, degraded
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Name : MyStorage:2
UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
Events : 427234
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 21 1 active sync /dev/sdb5
2 8 37 2 active sync /dev/sdc5
3 8 53 3 active sync /dev/sdd5
4 8 69 4 active sync /dev/sde5
5 8 5 - spare /dev/sda5
Como puede ver, / dev / sda5 se ha vuelto a agregar a la matriz. (Fue la unidad que falló por completo), pero aunque md ve la unidad como repuesto, no se reconstruirá en ella. / dev / sde5 en este caso es la unidad del problema con el estado (E) DiskError.
He intentado detener el dispositivo md, ejecutar fuerza para volver a ensamblar, eliminar / leer sda5 del dispositivo / etc. No hay cambio en el comportamiento.
Pude recrear completamente la matriz con el siguiente comando:
mdadm --stop /dev/md2
mdadm --verbose \
--create /dev/md2 --chunk=64 --level=5 \
--raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5
lo que devolvió la matriz a este estado:
md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
Luego volví a agregar / dev / sda5:
mdadm --manage /dev/md2 --add /dev/sda5
después de lo cual comenzó una reconstrucción:
md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
[>....................] recovery = 0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec
Tenga en cuenta que la posición de la unidad "que falta" coincide con la posición exacta de la ranura que falta.
Una vez que esto termine, creo que probablemente extraeré la unidad cuestionable y la reconstruiré nuevamente.
Estoy buscando alguna sugerencia sobre si hay alguna forma "menos aterradora" de hacer esta reparación, o si alguien ha pasado por esta experiencia con una matriz de Synology y sabe cómo forzarla a reconstruir, además de desconectar el dispositivo md y recrear la matriz desde cero.
fuente
Respuestas:
Solo una adición a la solución que encontré después de experimentar el mismo problema. Seguí la publicación de blog de dSebastien sobre cómo volver a crear la matriz:
Descubrí que ese método de recrear la matriz funcionó mejor que este método anterior. Sin embargo, después de volver a crear la matriz, el volumen aún no se mostraba en la interfaz web. Ninguno de mis LUN se mostraba. Básicamente muestra una nueva matriz con nada configurado. Me puse en contacto con el soporte de Synology, y se conectaron a distancia para solucionar el problema. Desafortunadamente, se conectaron mientras yo estaba lejos de la consola. Sin embargo, logré capturar la sesión y examiné lo que hicieron. Mientras intentaba recuperar algunos de mis datos, la unidad se bloqueó nuevamente y volví a la misma situación. Volví a crear la matriz como en el blog de dSebastien y luego revisé la sesión de sincronización para realizar su actualización. Después de ejecutar los siguientes comandos, mi matriz y los LUN aparecieron en la interfaz web, y pude trabajar con ellos. Prácticamente no tengo experiencia en Linux, pero estos fueron los comandos que realicé en mi situación. Espero que esto pueda ayudar a alguien más, pero use esto bajo su propio riesgo. Sería mejor ponerse en contacto con el soporte de Synology y hacer que solucionen esto por usted, ya que esta situación podría ser diferente a la suya.
fuente
Otra adición: me encontré con un problema muy similar con mi dispositivo de un disco / nivel RAID 0.
El soporte de Synology fue muy útil y restauró mi dispositivo. Esto es lo que sucedió, espero que esto ayude a otros:
Mi disco tenía errores de lectura en un bloque en particular, los mensajes en el registro del sistema (
dmesg) fueron:Unos segundos más tarde recibí el terrible
Volume 1 has crashedcorreo de mi dispositivo.- Descargo de responsabilidad: asegúrese de reemplazar el nombre del dispositivo por el suyo y no simplemente copie y pegue estos comandos, ya que esto podría empeorar las cosas. -
Después de detener smb pude volver a montar la partición de solo lectura y ejecutar e2fsk con badblocks check (
-c):(También se podría utilizar
e2fsck -C 0 -p -v -f -c /dev/md2para ejecutar lo más desatendido posible, aunque esto no funcionó en mi caso, porque los errores tuvieron que ser reparados manualmente. Así que tuve que reiniciar e2fsck. Conclusión: -p no tiene mucho sentido en caso de error de disco)Aunque e2fsck pudo corregir los errores y smartctl tampoco mostró más aumento en Raw_Read_Error_Rate, el volumen aún no se montaría en modo lectura-escritura por el dispositivo. DSM todavía mostró "volumen bloqueado"
Entonces abrí un boleto con apoyo. Tomó bastante tiempo poner las cosas en marcha primero, pero al final lo arreglaron reconstruyendo la matriz RAID con:
Asegúrese de verificar los nombres de sus dispositivos (
/dev/mdXy/dev/sdaX) antes de hacer nada.cat /proc/mdstatmostrará la información relevante.fuente