Linux Software Raid 10 bloqué après l'échec d'un lecteur, mdadm ne me laisse pas forcer le retrait du périphérique défectueux

J'ai une configuration de raid logiciel 10 Linux comprenant 5 RAID 1 (deux disques par configuration en miroir) et un RAID 0 sur les 5 paires RAID 1. Pour tester qu'aucun des disques n'allait tomber en panne rapidement sous charge, j'ai utilisé des badblocks sur le RAID 0 avec un mode de lecture / écriture destructif.

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

L'un des appareils est tombé en panne et au lieu du programme badblocks, il a heureusement été suspendu. Si j'exécute une commande de synchronisation, cela se bloque également. Tout d'abord, je suppose que ce n'est pas un comportement standard pour un périphérique RAID 1. Si l'un des disques tombe en panne, il devrait toujours être en mesure d'écrire sur le périphérique virtuel que les deux disques constituent sans problème.

J'ai donc continué à forcer la panne du disque et à essayer de le retirer. Je peux régler le lecteur sur défectueux sans aucun problème (Cependant, les opérations d'E / S sont toujours bloquées). Je ne peux pas retirer complètement l'appareil du raid qui indique qu'il est occupé. Mon hypothèse est que si je peux le chasser complètement du raid, l'IO continuera, mais ce n'est qu'une hypothèse et je pense que j'ai affaire à une sorte de bug.

Que se passe-t-il ici exactement? Suis-je dans un endroit irrécupérable en raison d'un bug?

Le système exécute le noyau 2.6.18, ce n'est donc pas exactement nouveau, mais je pense qu'étant donné que le raid logiciel existe depuis si longtemps, de tels problèmes ne se produiraient pas.

Tout conseil est grandement apprécié.

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  

Nombre total d'appareils: 5 Mineur préféré: 13 Persistance: le superbloc est persistant

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

Périphériques défaillants: 0 Périphériques de rechange: 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 sortie de raid défaillante:

/ dev / md8: Version: 00.90.03 Heure de création: jeu 21 jan 14:20:47 2010 Niveau de raid: raid1 Taille de la baie: 488383936 (465,76 Gio 500,11 Go) Taille de l'appareil: 488383936 (465,76 Gio 500,11 Go) Périphériques de raid: 2
Nombre total d'appareils: 2 Mineurs préférés: 8 Persistance: le superbloc est persistant

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

Périphériques défaillants: 1 Périphériques de rechange: 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

Désolé, peut-être que je n'ai pas bien compris et un cat / proc / mdstat pourrait être utile, mais autant que je sache, vous vous êtes tiré une balle dans le pied en détruisant vos données sur RAID0 et ainsi de suite les tableaux RAID1 sous-jacents. C'est, si vous devez tester la fiabilité RAID, vous devez marquer comme un disque, un disque défectueux, pour ne pas détruire les blocs logiques qui fait référence à tous les disques RAID1 sous-jacents, si j'ai bien compris le problème (faites-le moi savoir).

Vous devrez peut-être demander au noyau de supprimer le lecteur défectueux. il libérera le RAID suspendu.

Vous pouvez le supprimer avec un script comme http://bash.cyberciti.biz/diskadmin/rescan-linux-scsi-bus/