mdadm impede a reconstrução de um array RAID5 em 99,9%

3

Instalei recentemente três novos discos no meu QNAP TS-412 NAS.

Esses três novos discos devem ser combinados com o disco já presente em um array RAID5 de 4 discos, então iniciei o processo de migração.

Após várias tentativas (cada uma demorando cerca de 24 horas), a migração pareceu funcionar, mas resultou em um NAS não responsivo.

Nesse momento, reiniciei o NAS. Tudo desceu de lá:

  • O NAS inicializa, mas marca o primeiro disco com falha e o remove de todos os arrays, deixando-os fracos.
  • Eu executei verificações no disco e não consigo encontrar nenhum problema com ele (o que seria estranho de qualquer maneira, já que é quase novo).
  • A interface de administração não oferecia opções de recuperação, por isso imaginei que faria isso manualmente.

Eu reconstruí todos os arrays RAID1 internos da QNAP usando mdadm (sendo /dev/md4 , /dev/md13 e /dev/md9 ), deixando apenas a matriz RAID5; /dev/md0 :

Eu tentei isso várias vezes agora, usando estes comandos:

mdadm -w /dev/md0

(Necessário porque o array foi montado como somente leitura pelo NAS depois de remover /dev/sda3 dele. Não é possível modificar o array no modo RO).

mdadm /dev/md0 --re-add /dev/sda3

Após o qual o array inicia a reconstrução. Ele fica em 99,9%, enquanto o sistema está extremamente lento e / ou sem resposta. (O login no SSH falha na maioria das vezes).

Estado atual das coisas:

[admin@nas01 ~]# cat /proc/mdstat                            
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md4 : active raid1 sdd2[2](S) sdc2[1] sdb2[0]
      530048 blocks [2/2] [UU]

md0 : active raid5 sda3[4] sdd3[3] sdc3[2] sdb3[1]
      8786092608 blocks super 1.0 level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      [===================>.]  recovery = 99.9% (2928697160/2928697536) finish=0.0min speed=110K/sec

md13 : active raid1 sda4[0] sdb4[1] sdd4[3] sdc4[2]
      458880 blocks [4/4] [UUUU]
      bitmap: 0/57 pages [0KB], 4KB chunk

md9 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      530048 blocks [4/4] [UUUU]
      bitmap: 2/65 pages [8KB], 4KB chunk

unused devices: <none>

(Está parado em 2928697160/2928697536 por horas agora)

[admin@nas01 ~]# mdadm -D /dev/md0
/dev/md0:
        Version : 01.00.03
  Creation Time : Thu Jan 10 23:35:00 2013
     Raid Level : raid5
     Array Size : 8786092608 (8379.07 GiB 8996.96 GB)
  Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Jan 14 09:54:51 2013
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 99% complete

           Name : 3
           UUID : 0c43bf7b:282339e8:6c730d6b:98bc3b95
         Events : 34111

    Number   Major   Minor   RaidDevice State
       4       8        3        0      spare rebuilding   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3
       2       8       35        2      active sync   /dev/sdc3
       3       8       51        3      active sync   /dev/sdd3

Após inspecionar /mnt/HDA_ROOT/.logs/kmsg , o problema real parece estar com /dev/sdb3 :

<6>[71052.730000] sd 3:0:0:0: [sdb] Unhandled sense code
<6>[71052.730000] sd 3:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
<6>[71052.730000] sd 3:0:0:0: [sdb] Sense Key : 0x3 [current] [descriptor]
<4>[71052.730000] Descriptor sense data with sense descriptors (in hex):
<6>[71052.730000]         72 03 00 00 00 00 00 0c 00 0a 80 00 00 00 00 01 
<6>[71052.730000]         5d 3e d9 c8 
<6>[71052.730000] sd 3:0:0:0: [sdb] ASC=0x0 ASCQ=0x0
<6>[71052.730000] sd 3:0:0:0: [sdb] CDB: cdb[0]=0x88: 88 00 00 00 00 01 5d 3e d9 c8 00 00 00 c0 00 00
<3>[71052.730000] end_request: I/O error, dev sdb, sector 5859367368
<4>[71052.730000] raid5_end_read_request: 27 callbacks suppressed
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246784 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246792 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246800 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246808 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246816 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246824 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246832 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246840 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246848 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5:md0: read error not correctable (sector 5857246856 on sdb3).
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.
<4>[71052.730000] raid5: some error occurred in a active device:1 of md0.

A sequência acima é repetida a uma taxa constante para vários setores (aleatórios?) na faixa 585724XXXX .

Minhas perguntas são:

  • Por que ele está parado tão perto do fim, enquanto ainda está usando tantos recursos que o sistema fica paralisado (os processos md0_raid5 e md0_resync ainda estão em execução).
  • Existe alguma maneira de ver o que está causando falhas / falhas? < - Provavelmente devido aos erros sdb3 .
  • Como posso concluir a operação sem perder meus 3 TB de dados? (Como pular os setores problemáticos em sdb3 , mas manter os dados intactos?)
por Remco Overdijk 14.01.2013 / 10:33

2 respostas

2

É provável que pare antes de terminar, porque exige que o disco com defeito retorne algum tipo de status, mas não está conseguindo.

Independentemente disso, todos os seus dados estão (ou devem estar) intactos com apenas 3 de 4 discos.

Você diz que ejeta o disco defeituoso do array - então ele ainda deve estar em execução, ainda que em modo degradado.

Você pode montá-lo?

Você pode forçar a matriz a ser executada executando o seguinte:

  • imprima os detalhes da matriz: mdadm -D /dev/md0
  • interrompe a matriz: mdadm --stop /dev/md0
  • recriar o array e forçar md a aceitá-lo: '' mdadm -C -n md0 --assume-clean / dev / sd [abcd] 3 '

Este último passo é totalmente seguro, desde que:

  • você não escreve no array e
  • você usou exatamente os mesmos parâmetros de criação de antes.

Esse último sinalizador impedirá uma reconstrução e ignorará os testes de integridade.
Você deve então poder montá-lo e recuperar seus dados.

    
por 14.01.2013 / 11:05
3

A abordagem óbvia seria substituir o disco defeituoso, recriar os arrays e repetir o backup que você fez antes da operação de extensão do array.

Mas, como você parece não ter essa opção, essa seria a melhor coisa a fazer:

  • obtenha um sistema Linux com espaço suficiente para acomodar o espaço bruto de todos os seus discos (12 TB, se acertar os números)
  • copie os dados dos seus discos para este sistema, os destinos podem ser arquivos ou dispositivos de bloco, isso não importa muito para mdraid . No caso do dispositivo sdb3 com defeito, talvez seja necessário usar ddrescue em vez de um simples dd para copiar os dados.
  • tente montar e reconstruir o array a partir daí

Além disso, dê uma olhada em esta página do blog para obter algumas dicas sobre o que pode ser feito para avaliar a situação em uma falha de vários dispositivos para uma matriz RAID 5.

    
por 14.01.2013 / 11:30