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.