Il Software Raid 10 di Linux si è bloccato dopo 1 unità guasta, mdadm non mi consente di forzare la rimozione del dispositivo difettoso

Ho una configurazione RAID 10 del software Linux composta da 5 RAID 1 (due unità per configurazione speculare) e un RAID 0 su tutte e 5 le coppie RAID 1. Per provare che nessuna delle unità si sarebbe guastata rapidamente sotto carico, ho usato i badblock su RAID 0 con una modalità di lettura / scrittura distruttiva.

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

Uno dei dispositivi si è guastato e al posto del programma badblock si è felicemente bloccato. Se eseguo un comando di sincronizzazione, anche questo si blocca. Innanzitutto suppongo che questo non sia un comportamento standard per un dispositivo RAID 1. Se una delle unità si guasta, dovrebbe comunque essere in grado di scrivere sul dispositivo virtuale che le due unità compongono senza problemi.

Quindi ho provveduto a forzare il guasto dell'unità e provare a rimuoverlo. Posso impostare l'azionamento su difettoso senza alcun problema (tuttavia le operazioni di IO sono ancora bloccate). Non riesco a rimuovere completamente il dispositivo dal raid che dice che è occupato. La mia ipotesi è che se riesco a buttarlo fuori dal raid, l'IO continuerà, ma questo è solo un presupposto e penso di avere a che fare con una specie di bug.

Cosa sta succedendo qui esattamente? Sono in un punto irrecuperabile a causa di un bug?

Il sistema esegue il kernel 2.6.18, quindi non è esattamente nuovo, ma penso che dato che il raid del software è in circolazione da così tanto tempo non si verifichino problemi come questi.

Qualsiasi consiglio é ben accetto.

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  

Totale dispositivi: 5 Preferenza minore: 13 Persistenza: il superblocco è persistente

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

Dispositivi guasti: 0 Dispositivi di riserva: 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

L'output del raid non riuscito:

/ dev / md8: Versione: 00.90.03 Tempo di creazione: gio 21 gen 14:20:47 2010 Livello raid: raid1 Dimensione array: 488383936 (465,76 GiB 500,11 GB) Dimensione dispositivo: 488383936 (465,76 GiB 500,11 GB) Dispositivi RAID: 2
Totale dispositivi: 2 Preferenza minore: 8 Persistenza: il superblocco è persistente

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

Dispositivi guasti: 1 Dispositivi di riserva: 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

Mi dispiace, forse non ho capito bene e un cat / proc / mdstat potrebbe essere utile, ma per quanto posso vedere ti sei sparato nel piede distruggendo i tuoi dati su RAID0 e così via sugli array RAID1 sottostanti. Se devi testare l'affidabilità RAID devi contrassegnare come unità guasta, un disco, per non distruggere i blocchi logici che si riferiscono a tutti i dischi RAID1 sottostanti, se ho capito bene il problema (fammi sapere).

Forse è necessario chiedere al kernel di rimuovere l'unità guasta. rilascerà il RAID hangy.

Puoi rimuoverlo con uno script come http://bash.cyberciti.biz/diskadmin/rescan-linux-scsi-bus/