☰

Linux Software Raid 10 travou após falha em 1 unidade, o mdadm não me permitirá forçar a remoção do dispositivo defeituoso

tag-icon • tag-icon linux raid software-raid mdadm raid10
Linux Software Raid 10 travou após falha em 1 unidade, o mdadm não me permitirá forçar a remoção do dispositivo defeituoso

Eu tenho uma configuração de software RAID 10 do 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 falharia rapidamente sob carga, usei badblocks no 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 badblocks, movendo-se alegremente, ele travou. Se eu executar um comando de sincronização, isso também trava. Primeiro, eu presumiria que esse não é um comportamento padrão para um dispositivo RAID 1. Se uma das unidades falhar, ainda será possível gravar no dispositivo virtual que as duas unidades constituem sem problemas.

Então, forcei a falha da unidade e tentei removê-la. Posso definir a unidade como defeituosa sem nenhum problema (no entanto, as operações de E/S ainda estão suspensas). Não consigo remover totalmente o dispositivo do ataque, ele diz que está ocupado. Minha suposição é que, se eu conseguir expulsá-lo totalmente do ataque, o IO continuará, mas isso é apenas uma suposição e acho que estou lidando com uma espécie de bug.

O que está acontecendo aqui exatamente? Estou em uma situação irrecuperável devido a um bug?

O sistema está executando o kernel 2.6.18, então não é exatamente novo, mas eu acho que, dado que o ataque 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 Menores preferidos: 13 Persistência: Superblock é persistente

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

Dispositivos com falha: 0 Dispositivos sobressalentes: 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: qui 21 de janeiro 14:20:47 2010 Nível de invasão: RAID1 Tamanho da matriz: 488383936 (465.76 Gib 500.11 GB) Tamanho do dispositivo: 48838396 (465.76 Gib 500.11 GB)
Total de dispositivos: 2 Menores preferidos: 8 Persistência: Superblock é persistente

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

Dispositivos com falha: 1 Dispositivos sobressalentes: 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

Responder1

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

Responder2

Talvez você precise pedir ao kernel para remover a unidade defeituosa. isso irá liberar o RAID travado.

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

informação relacionada