Linux Software Raid 10 travou depois que 1 unidade falhou, o mdadm não vai me deixar forçar a remoção do dispositivo defeituoso

Question

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

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 processo foi interrompido. Se eu executar um comando de sincronização, isso também trava. Primeiro eu diria que isso não é um comportamento padrão para um dispositivo RAID 1. Se uma das unidades falhar, ela ainda poderá gravar no dispositivo virtual que as duas unidades compõem sem problemas.

Então, continuei a forçar a falha na unidade e tente removê-la. Eu posso definir a unidade para defeituoso sem qualquer problema (No entanto, as operações de E / S ainda estão pendentes). Não consigo remover o dispositivo totalmente do ataque que diz que está ocupado. Minha suposição é que, se eu puder expulsá-lo do ataque, a OI continuará, mas isso é apenas uma suposição e eu acho que estou lidando com um tipo de erro.

O que está acontecendo exatamente aqui? Eu estou em um local irrecuperável devido a um bug?

O sistema está rodando o kernel 2.6.18, então não é exatamente novo, mas eu acho que, dado que o software raid existe há tanto tempo, problemas como esses não aconteceriam.

Qualquer insight é muito apreciado.

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 Devices : 5 Preferred Minor : 13 Persistence : Superblock is persistent

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

Failed Devices : 0 Spare Devices : 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 de raide com falha:

/dev/md8: Version : 00.90.03 Creation Time : Thu Jan 21 14:20:47 2010 Raid Level : raid1 Array Size : 488383936 (465.76 GiB 500.11 GB) Device Size : 488383936 (465.76 GiB 500.11 GB) Raid Devices : 2
Total Devices : 2 Preferred Minor : 8 Persistence : Superblock is persistent

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

Failed Devices : 1 Spare Devices : 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

    

Answer 1

Desculpe, talvez eu não tenha entendido bem e um cat / proc / mdstat poderia ser útil, mas até onde eu posso ver você se atirou no pé destruindo seus dados no RAID0 e assim por diante nos arrays RAID1 subjacentes. É, se você tem que testar a confiabilidade do RAID você deve marcar como falha uma unidade, um disco, não destruir blocos lógicos que se referem a todos os discos RAID1 subjacentes, se eu entendi bem o problema (me avise).

    

Answer 2

Talvez você precise pedir ao kernel para remover a unidade defeituosa. ele liberará o RAID hangy.

Você pode removê-lo com um script como link