Falha no kernel com o software RAID-1 devido a erros de leitura de unidade única

Question

Estou executando o Fedora 19 (kernel 3.11.3-201.fc19.x86_64) com uma configuração de software RAID-1 (mdadm) em duas unidades Seagate de 1 GB idênticas:

# cat /proc/mdstat 
Personalities : [raid1] 
md1 : active raid1 sdb3[1] sda3[0]
      973827010 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Recentemente, alguns erros estão sendo apresentados em uma das duas unidades: o smartd detectou "1 setores atualmente ilegíveis (pendentes)" e "1 setores incorrigíveis offline". A matriz RAID "reescalonou" alguns setores. Então, cerca de um dia depois, o kernel produziu várias mensagens / exceções de E / S:

Oct 18 06:39:20 x smartd[461]: Device: /dev/sdb [SAT], 1 Currently unreadable (pending) sectors
Oct 18 06:39:20 x smartd[461]: Device: /dev/sdb [SAT], 1 Offline uncorrectable sectors
...
Oct 18 07:09:20 x smartd[461]: Device: /dev/sdb [SAT], 1 Currently unreadable (pending) sectors
Oct 18 07:09:20 x smartd[461]: Device: /dev/sdb [SAT], 1 Offline uncorrectable sectors
...
Oct 18 07:30:28 x kernel: [467502.192792] md/raid1:md1: sdb3: rescheduling sector 1849689328
Oct 18 07:30:28 x kernel: [467502.192822] md/raid1:md1: sdb3: rescheduling sector 1849689336
Oct 18 07:30:28 x kernel: [467502.192846] md/raid1:md1: sdb3: rescheduling sector 1849689344
Oct 18 07:30:28 x kernel: [467502.192870] md/raid1:md1: sdb3: rescheduling sector 1849689352
Oct 18 07:30:28 x kernel: [467502.192895] md/raid1:md1: sdb3: rescheduling sector 1849689360
Oct 18 07:30:28 x kernel: [467502.192919] md/raid1:md1: sdb3: rescheduling sector 1849689368
Oct 18 07:30:28 x kernel: [467502.192943] md/raid1:md1: sdb3: rescheduling sector 1849689376
Oct 18 07:30:28 x kernel: [467502.192966] md/raid1:md1: sdb3: rescheduling sector 1849689384
Oct 18 07:30:28 x kernel: [467502.192991] md/raid1:md1: sdb3: rescheduling sector 1849689392
Oct 18 07:30:28 x kernel: [467502.193035] md/raid1:md1: sdb3: rescheduling sector 1849689400
...
Oct 19 06:26:08 x kernel: [550035.944191] ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 19 06:26:08 x kernel: [550035.944224] ata3.01: BMDMA stat 0x64
Oct 19 06:26:08 x kernel: [550035.944248] ata3.01: failed command: READ DMA EXT
Oct 19 06:26:08 x kernel: [550035.944274] ata3.01: cmd 25/00:08:15:fb:9c/00:00:6c:00:00/f0 tag 0 dma 4096 in
Oct 19 06:26:08 x kernel: [550035.944274]          res 51/40:00:1c:fb:9c/40:00:6c:00:00/10 Emask 0x9 (media error)
Oct 19 06:26:08 x kernel: [550035.944322] ata3.01: status: { DRDY ERR }
Oct 19 06:26:08 x kernel: [550035.944340] ata3.01: error: { UNC }
Oct 19 06:26:08 x kernel: [550036.573438] ata3.00: configured for UDMA/133
Oct 19 06:26:08 x kernel: [550036.621444] ata3.01: configured for UDMA/133
Oct 19 06:26:08 x kernel: [550036.621507] sd 2:0:1:0: [sdb] Unhandled sense code
Oct 19 06:26:08 x kernel: [550036.621516] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550036.621523] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 19 06:26:08 x kernel: [550036.621530] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550036.621537] Sense Key : Medium Error [current] [descriptor]
Oct 19 06:26:08 x kernel: [550036.621555] Descriptor sense data with sense descriptors (in hex):
Oct 19 06:26:08 x kernel: [550036.621562]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Oct 19 06:26:08 x kernel: [550036.621606]         6c 9c fb 1c 
Oct 19 06:26:08 x kernel: [550036.621626] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550036.621638] Add. Sense: Unrecovered read error - auto reallocate failed
Oct 19 06:26:08 x kernel: [550036.621646] sd 2:0:1:0: [sdb] CDB: 
Oct 19 06:26:08 x kernel: [550036.621653] Read(10): 28 00 6c 9c fb 15 00 00 08 00
Oct 19 06:26:08 x kernel: [550036.621692] end_request: I/O error, dev sdb, sector 1822227228
Oct 19 06:26:08 x kernel: [550036.621719] raid1_end_read_request: 9 callbacks suppressed
Oct 19 06:26:08 x kernel: [550036.621727] md/raid1:md1: sdb3: rescheduling sector 1816361448
Oct 19 06:26:08 x kernel: [550036.621782] ata3: EH complete
Oct 19 06:26:08 x kernel: [550041.155637] ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 19 06:26:08 x kernel: [550041.155669] ata3.01: BMDMA stat 0x64
Oct 19 06:26:08 x kernel: [550041.155694] ata3.01: failed command: READ DMA EXT
Oct 19 06:26:08 x kernel: [550041.155719] ata3.01: cmd 25/00:08:15:fb:9c/00:00:6c:00:00/f0 tag 0 dma 4096 in
Oct 19 06:26:08 x kernel: [550041.155719]          res 51/40:00:1c:fb:9c/40:00:6c:00:00/10 Emask 0x9 (media error)
Oct 19 06:26:08 x kernel: [550041.155767] ata3.01: status: { DRDY ERR }
Oct 19 06:26:08 x kernel: [550041.155785] ata3.01: error: { UNC }
Oct 19 06:26:08 x kernel: [550041.343437] ata3.00: configured for UDMA/133
Oct 19 06:26:08 x kernel: [550041.391438] ata3.01: configured for UDMA/133
Oct 19 06:26:08 x kernel: [550041.391501] sd 2:0:1:0: [sdb] Unhandled sense code
Oct 19 06:26:08 x kernel: [550041.391510] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550041.391517] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 19 06:26:08 x kernel: [550041.391525] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550041.391532] Sense Key : Medium Error [current] [descriptor]
Oct 19 06:26:08 x kernel: [550041.391546] Descriptor sense data with sense descriptors (in hex):
Oct 19 06:26:08 x kernel: [550041.391553]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Oct 19 06:26:08 x kernel: [550041.391596]         6c 9c fb 1c 
Oct 19 06:26:08 x kernel: [550041.391616] sd 2:0:1:0: [sdb]  
Oct 19 06:26:08 x kernel: [550041.391624] Add. Sense: Unrecovered read error - auto reallocate failed
Oct 19 06:26:08 x kernel: [550041.391636] sd 2:0:1:0: [sdb] CDB: 
Oct 19 06:26:08 x kernel: [550041.391643] Read(10): 28 00 6c 9c fb 15 00 00 08 00
Oct 19 06:26:08 x kernel: [550041.391681] end_request: I/O error, dev sdb, sector 1822227228
Oct 19 06:26:08 x kernel: [550041.391737] ata3: EH complete
Oct 19 06:26:08 x kernel: [550041.409686] md/raid1:md1: read error corrected (8 sectors at 1816363496 on sdb3)
Oct 19 06:26:08 x kernel: [550041.409705] handle_read_error: 9 callbacks suppressed
Oct 19 06:26:08 x kernel: [550041.409709] md/raid1:md1: redirecting sector 1816361448 to other mirror: sda3

O computador continuou a registrar algumas entradas no syslog até cerca de uma hora depois, e finalmente ficou completamente sem resposta. Nenhum "kernel oops" foi gravado no syslog. O computador teve que ser reinicializado, ponto em que a matriz de ataque estava em um status de ressincronização. Após a ressincronização, tudo parece bem e as unidades parecem estar funcionando normalmente.

Eu também notei que todos os setores reprogramados são exatamente 8 setores à parte, o que parece muito estranho para mim.

Por fim, após a reinicialização e aproximadamente um ou dois dias depois, mas significativamente após a conclusão da ressincronização do RAID, a unidade redefiniu a contagem incorreta do setor ilegível (pendente) e offline, o que acredito ser normal, pois a unidade coloca esses setores offline e remapeia:

Oct 20 01:05:42 x kernel: [    2.186400] md: bind<sda3>
Oct 20 01:05:42 x kernel: [    2.204826] md: bind<sdb3>
Oct 20 01:05:42 x kernel: [    2.209618] md: raid1 personality registered for level 1
Oct 20 01:05:42 x kernel: [    2.210079] md/raid1:md1: not clean -- starting background reconstruction
Oct 20 01:05:42 x kernel: [    2.210087] md/raid1:md1: active with 2 out of 2 mirrors
Oct 20 01:05:42 x kernel: [    2.210122] md1: detected capacity change from 0 to 997198858240
Oct 20 01:05:42 x kernel: [    2.210903] md: resync of RAID array md1
Oct 20 01:05:42 x kernel: [    2.210911] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Oct 20 01:05:42 x kernel: [    2.210915] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
Oct 20 01:05:42 x kernel: [    2.210920] md: using 128k window, over a total of 973827010k.
Oct 20 01:05:42 x kernel: [    2.241676]  md1: unknown partition table
...
Oct 20 06:33:10 x kernel: [19672.235467] md: md1: resync done.
...
Oct 21 05:35:50 x smartd[455]: Device: /dev/sdb [SAT], No more Currently unreadable (pending) sectors, warning condition reset after 1 email
Oct 21 05:35:50 x smartd[455]: Device: /dev/sdb [SAT], No more Offline uncorrectable sectors, warning condition reset after 1 email

smartctl -a /dev/sdb agora mostra

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
...
  5 Reallocated_Sector_Ct   0x0033   096   096   036    Pre-fail  Always       -       195
...
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
...

Algumas questões surgem:

1) Por que todos os setores remarcados seriam exatamente 8 separados?

2) Por que o kernel não responde e requer uma reinicialização? Não deveria ser exatamente a situação em que o RAID-1 deveria funcionar sem que o sistema explodisse?

3) Por que as contagens ilegíveis e ilegíveis off-line são redefinidas apenas 23 horas após a conclusão da ressincronização da invasão?

    

Answer 1

1) Why would all the rescheduled sectors be exactly 8 apart?

Tais brechas nos números do setor são esperadas, a questão é quanto essas lacunas seriam grandes (4k ou maiores). 8x 512 bytes são 4k, que é o tamanho de setor com que a maioria dos sistemas de arquivos trabalha. Assim, o sistema de arquivos provavelmente solicitou a leitura de 4k do RAID, o RAID pergunta o /dev/sdb para esses dados. O primeiro setor dessa leitura falha (esse é o número do setor que você vê nos seus logs), o RAID muda para /dev/sda e serve o 4k de lá. Então o sistema de arquivos solicita para ler o próximo 4k, de volta para /dev/sdb com o número do setor +8 que falha novamente, o que é novamente o que você vê nos seus logs ...

2) Why would the kernel become unresponsive and require a reboot?

Não deveria acontecer normalmente. O problema é que a situação de realocação é a mais cara que você pode obter. Cada leitura que falha, deve ser redirecionada para o outro disco, tem que ser reescrita no disco original, etc. Se ela preencher seu arquivo de log ao mesmo tempo, causando novas solicitações de gravação, que por sua vez precisam ser realocadas novamente, etc. Seria mais barato apenas chutar o disco completamente neste caso.

É também uma questão de como o resto do hardware (como o controlador SATA) lida com unidades com falha. Se o controlador em si der um soluço, isso prejudicará ainda mais o desempenho.

É difícil dizer exatamente o que aconteceu se não houver entrada de registro; é um ponto fraco do kernel do Linux, não existe uma solução direta para preservar essas últimas mensagens quando as coisas realmente vão para o sul.

3) Why would the unreadable and offline uncorrectable counts reset only 23 hours after the raid resync was complete?

Alguns valores são atualizados apenas quando você coleta dados off-line (coluna UPDATED Offline), o que pode levar algum tempo. Se o disco estiver configurado para fazer isso automaticamente, isso depende do disco, por ex. a cada quatro horas. Se você não quer confiar no disco, você deve configurá-lo usando o smartmontools.