O Linux Software Raid 10 travou após uma unidade falhar, o mdadm não permitirá que eu remova o dispositivo com defeito

Eu tenho uma instalação do RAID 10 do software Linux que consiste em 5 RAID 1s (duas unidades por instalação espelhada) e um RAID 0 em todos os 5 pares RAID 1. Para testar se nenhuma das unidades falharia rapidamente sob carga, usei badblocks no RAID 0 com um modo destrutivo de leitura / gravação.

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

Um dos dispositivos falhou e, em vez do programa de badblocks, o movimento feliz foi interrompido. Se eu executar um comando de sincronização, isso também trava. Primeiro, eu diria que esse comportamento não é padrão para um dispositivo RAID 1. Se uma das unidades falhar, ainda será possível gravar no dispositivo virtual que as duas unidades compõem sem problemas.

Então, comecei a forçar a falha na unidade e tente removê-la. Posso definir a unidade com defeito sem nenhum problema (no entanto, as operações de E / S ainda estão suspensas). Não consigo remover o dispositivo completamente do ataque que ele diz estar ocupado. Minha suposição é que, se eu puder expulsá-lo completamente do ataque, o IO continuará, mas isso é apenas uma suposição e acho que estou lidando com um tipo de bug.

O que está acontecendo exatamente aqui? Estou em um ponto irrecuperável devido a um bug?

O sistema está executando o kernel 2.6.18, portanto não é exatamente novo, mas eu acho que, dado que a invasão de software existe há tanto tempo, problemas como esses não aconteceriam.

Qualquer visão é muito 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 Menor preferido: 13 Persistência: o superbloco é persistente

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

Dispositivos com falha: 0 Dispositivos de reposição: 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

A saída do ataque com falha:

/ dev / md8: Versão: 00.90.03 Tempo de criação: quinta-feira, 21 de janeiro 14:20:47 2010 Nível de raide: raid1 Tamanho da matriz: 488383936 (465,76 GiB 500,11 GB) Tamanho do dispositivo: 488383936 (465,76 GiB 500,11 GB) Dispositivos Raid: 2
Total de dispositivos: 2 Menor preferido: 8 Persistência: O superbloco é persistente

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

Dispositivos com falha: 1 Dispositivos de reposição: 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

Desculpe, talvez eu não tenha entendido bem e um cat / proc / mdstat possa ser útil, mas, tanto quanto posso ver, você se matou destruindo seus dados no RAID0 e assim nas matrizes RAID1 subjacentes. Ou seja, se você precisar testar a confiabilidade do RAID, deverá marcar como uma unidade com falha, um disco, para não destruir os blocos lógicos que se referem a todos os discos RAID1 subjacentes, se entendi bem o problema (avise-me).

Talvez você precise pedir ao kernel para remover a unidade defeituosa. ele lançará o RAID irritante.

Você pode removê-lo com um script como http://bash.cyberciti.biz/diskadmin/rescan-linux-scsi-bus/