Eu tenho uma matriz de 5 unidades WD Red 1TB em um gabinete externo em um multiplexador SATA. Isso está sendo alimentado em uma máquina desktop com um controlador multiplexador SATA.
Após cerca de um ano de serviço (isso aconteceu duas vezes), a matriz começará a ser redefinida como este vídeo . Não há nenhuma indicação de que qualquer unidade específica esteja em falha, apenas que o gabinete é desligado e todas as unidades se desconectam na matriz.
Eu tenho dois desses gabinetes, e a falha sempre acompanha o array redundante quando eu os movo de um para o outro. Os compartimentos permaneceram constantes durante anos, assim como as placas de interface, mas novas unidades instaladas resolveram o problema por mais um ano.
Podem ser dezenas de coisas, desde uma fonte de alimentação barulhenta, matando os circuitos de energia do drive lentamente até uma implementação ruim do sistema operacional do ZFS, mas é difícil saber por onde começar. Qual estratégia me deixaria descobrir qual é o problema?
-
OS: CentOS 7.0, kernel: 3.10.0
-
Gabinete: multiplexador SiI 3726
-
Placa de interface: desmultiplexador SiI 3132
-
Discos rígidos: WD10EFRX
Mensagens:
Quando as redefinições estão ocorrendo:
[ttt.tttt] ata4.03: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x6 frozen
[ttt.tttt] ata4.03: failed command: WRITE DMA EXT
[ttt.tttt] ata4.03: cmd 35/00:.. ...:00/e0 tag 3 dma 144688 out
[ttt.tttt] ata4.03: status: { Busy }
[ttt.tttt] ata4.03: error: { ICRC UNC AMNF IDNF ABRT }
Quando o zpool parar completamente:
[ttt.tttt] INFO: task txg_sync:xxxxx blocked for more than 120 seconds
[ttt.tttt] INFO: task zpool:xxxxx blocked for more than 120 seconds
Uma vez que o segundo ocorreu em resposta a comandos de terminal como
$ zpool status
o sistema é essencialmente inútil e requer uma reinicialização completa.
O problema não se correlaciona com uma queda nas voltagens das unidades, como pode ser visto no vídeo mais recente . Eu acho que é uma informação chave que a própria caixa está reiniciando, todas as luzes, até mesmo sua própria luz de energia está sendo reinicializada.
As mensagens para o dmesg são vastas, muito longas para serem anexadas.
Saída de badblocks :
$ badblocks -vn /dev/sdp1
irq_stat 0x00060002, device error via SDB FIS
SError: { Handshk }
failed command: WRITE FPDMA QUEUED
cmd 61/...
res 41/... ...Emask 0x410 (ATA bus error) <F>
status: { DRDY ERR }
error: { ICRC ABRT }
E isso ocorre igualmente para todas as 5 unidades na matriz. É como se a caixa estivesse sendo sobrecarregada e se redefinindo.
Atualização: 12/06/2017
Todas as unidades foram movidas para um segundo gabinete na interconexão USB3 em vez de eSATA.
- Gabinete: ICY BOX IB-3810U3
Chip de multiplexador: ASMedia ASM1074L
Host USB3 da placa-mãe do servidor: Gigabyte GA-B85-HD3 SKT 1150
Com todas as unidades movidas para o novo gabinete, o comando badblocks foi executado em cada unidade sem um único erro. Em seguida, a piscina foi importada e uma corrida de esfoliação. Nenhum erro foi encontrado e o scrub foi concluído com sucesso. Hoje, no entanto, uma mensagem foi listada para todos os 5 drives, (era impossível dizer se eles eram os drives deste pool / tank / array):
WARNING: Your hard drive is failing
Device: /dev/sdk [SAT], unable to open device
WARNING: Your hard drive is failing
Device: /dev/sdl [SAT], unable to open device
WARNING: Your hard drive is failing
Device: /dev/sdm [SAT], unable to open device
WARNING: Your hard drive is failing
Device: /dev/sdn [SAT], unable to open device
WARNING: Your hard drive is failing
Device: /dev/sdo [SAT], unable to open device
Depois disso, uma tentativa de listar o conteúdo da unidade bloqueou o terminal. Um novo terminal bloqueado em qualquer comando zpool . top listas txg_sync e uma horda de z_rd_int_x processa que todos têm algum uso da CPU. Dois outros pools estão servindo arquivos com sucesso através do SAMBA, com um continuando a se resilver (somente evidenciado pelas luzes HD), pois zpool status trava.
smartctl data: 12/12/2017
De acordo com um comentador, o seguinte é o smartctl data para UDMA_CRC_Error_Count .
Para a segunda iteração do array falhando no momento:
4193, 4030, 3939, 2869, 3977
Para o array original (com o drive três sendo trocado):
3003, 3666, 0, 4536, 5309
Para uma faixa RAID0 no mesmo gabinete e conectividade
523, 504, 526, 553, 476
Para um espelho ZFS com hot spare hospedado dentro da máquina host:
0, 0, 0
Em uma unidade do Seagate Archive, parece um disparate. :
Temperature_Celsius UDMA_CRC_Error_Count Head_Flying_Hours
40 (0 16 0 0 0) 0 57501022168585
Isso potencialmente apenas mostra que eSATA e USB 3.0 são inerentemente barulhentos e a corrupção de dados é inevitável.