Linux Software Raid 10 se bloqueó después de que fallara 1 unidad, mdadm no me permitirá forzar la eliminación del dispositivo defectuoso

Tengo una configuración de incursión de software de Linux 10 que consta de 5 RAID 1 (dos unidades por configuración reflejada) y una RAID 0 en los 5 pares RAID 1. Para probar que ninguna de las unidades iba a fallar rápidamente bajo carga, utilicé bloques defectuosos en el RAID 0 con un modo destructivo de lectura / escritura.

Comando Badblocks: badblocks -b 4096 -c 98304 -p 0 -w -s / dev / md13

Uno de los dispositivos falló y en lugar del programa badblocks que se movía felizmente colgó. Si ejecuto un comando de sincronización, esto también se bloquea. Primero supondría que este no es un comportamiento estándar para un dispositivo RAID 1. Si una de las unidades falla, aún debería poder escribir en el dispositivo virtual que las dos unidades componen sin problemas.

Así que procedí a forzar el fallo de la unidad e intenté eliminarlo. Puedo configurar la unidad a defectuosa sin ningún problema (sin embargo, las operaciones de E / S todavía están bloqueadas). No puedo eliminar el dispositivo por completo de la redada, dice que está ocupado. Mi suposición es que si puedo expulsarlo de la redada por completo, el IO continuará, pero eso es solo una suposición y creo que estoy lidiando con un tipo de error.

¿Qué está pasando aquí exactamente? ¿Estoy en un lugar irrecuperable debido a un error?

El sistema está ejecutando el núcleo 2.6.18, por lo que no es exactamente nuevo, pero creo que dado que la incursión de software ha existido durante tanto tiempo, problemas como estos no sucederían.

Cualquier idea es muy apreciada.

mdadm --detail / dev / md13

/ dev / md13:

    Version : 00.90.03   Creation Time : Thu Jan 21 14:21:57 2010
 Raid Level : raid0
 Array Size : 2441919360 (2328.80 GiB 2500.53 GB)    Raid Devices : 5  

Total de dispositivos: 5 Preferido Menor: 13 Persistencia: Superblock es persistente

Update Time : Thu Jan 21 14:21:57 2010
      State : clean  Active Devices : 5 Working Devices : 5 

Dispositivos fallidos: 0 Dispositivos de repuesto: 0

 Chunk Size : 64K

       UUID : cfabfaee:06cf0cb2:22929c7b:7b037984
     Events : 0.3

Number   Major   Minor   RaidDevice State
   0       9        7        0      active sync   /dev/md7
   1       9        8        1      active sync   /dev/md8
   2       9        9        2      active sync   /dev/md9
   3       9       10        3      active sync   /dev/md10
   4       9       11        4      active sync   /dev/md11

La salida de incursión fallida:

/ dev / md8: Versión: 00.90.03 Tiempo de creación: jue 21 de enero 14:20:47 Nivel de incursión 2010: raid1 Tamaño de matriz: 488383936 (465.76 GiB 500.11 GB) Tamaño del dispositivo: 488383936 (465.76 GiB 500.11 GB) Dispositivos de incursión: 2
Total de dispositivos: 2 Preferido Menor: 8 Persistencia: Superblock es persistente

Update Time : Mon Jan 25 04:52:25 2010
      State : active, degraded  Active Devices : 1 Working Devices : 1

Dispositivos fallidos: 1 Dispositivos de repuesto: 0

       UUID : 2865aefa:ab6358d8:8f82caf4:1663e806
     Events : 0.11

Number   Major   Minor   RaidDevice State
   0      65       17        0      active sync   /dev/sdr1
   1       8      209        1      faulty   /dev/sdn1

Lo siento, tal vez no lo entendí bien y un cat / proc / mdstat podría ser útil, pero hasta donde puedo ver, te disparaste en el pie destruyendo tus datos en RAID0 y así sucesivamente en las matrices RAID1 subyacentes. Es decir, si tiene que probar la confiabilidad RAID, debe etiquetar como fallida una unidad, un disco, para no destruir los bloques lógicos que se refieren a todos los discos RAID1 subyacentes, si entendí bien el problema (hágamelo saber).

Tal vez necesite pedirle al núcleo que elimine la unidad defectuosa. lanzará el RAID colgante.

Puede eliminarlo con un script como http://bash.cyberciti.biz/diskadmin/rescan-linux-scsi-bus/