A depuração do ZFS encontra erros de soma de verificação, mas os badblocks e o smartctl não

Question

Eu configurei um pool do ZFS com duas unidades como um espelho. O sistema operacional é o Ubuntu 16.04 e eu tenho usado o zfs 0.6.5 como empacotado pelo fornecedor. As unidades são 3T WD Green e 3T WD Red (provavelmente não ideais para desempenho, mas isso não é uma consideração), que são do mesmo tamanho em bytes e setores. Eu não uso partições, mas zpool create fez duas em cada drive para mim, como é habitual. Por padrão, o SO executa o scrub no pool uma vez por mês e executei o scrub manualmente algumas vezes.

Várias vezes, o processo de limpeza encontrou erros de soma de verificação na unidade WD Red, mas não em todas as execuções. Eles foram reparados automaticamente e não causaram problemas, tanto quanto eu sei. O número mostrado na coluna CKSUM indicou 3, 5 e 9, e agora, após uma atualização recente para o próximo Ubuntu 18.04 e ZFS 0.7.5, também 31 (com informações extras "muitos erros" se eu lembrar da mensagem corretamente ).

Alarmado, desanexei a unidade do pool e exportei o pool. Sem importar a unidade, eu corri badblocks -b 4096 -s -v -w , mas ela reportou (0/0/0) erros. Também smartctl -a /dev/sda não indicou nada fora do comum, se eu entendi corretamente ( | grep -i error ):

  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

Eu reconectei o disco ao pool e ele está atualmente praticando novamente. Mas permaneço mistificado: o que poderia ter causado os erros de lavagem recorrentes? O que devo fazer no futuro para descobrir melhor o problema ou evitá-lo completamente? Eu não estou particularmente interessado em comprar a (s) unidade (s) de substituição, especialmente porque o WD Red é fabricado somente em 2016.

(Não tenho certeza se isso é relevante, mas em algum momento o erro do operador ou o bug do software fez com que a tabela de partição do WD Green não fosse corrompida. Não consegui encontrar nenhuma outra ação para retorná-la ao excluindo a tabela de partição e recolocando-a. Durante o processo de recriação de prata, alguns blocos não puderam ser lidos a partir da unidade WD Red e eu restaurei o arquivo afetado dos backups. A depuração detectou erros de soma de verificação antes e depois desta incidente.)

    

Answer 1

Não existe uma maneira fácil de saber do que as falhas de checksum foram causadas, já que elas acontecem independentemente do sistema de arquivos (a menos que sejam causadas por erros no próprio FS, mas não acho que é isso que está acontecendo aqui). Os smartctl e badblocks sucessos me deixam esperançoso de que o problema não seja um disco com falha.

Esta é a página que ajuda você a entender o erro: link . Citando isso:

For example, the following cases will all produce errors that do not 
indicate potential device failure:

- A network attached device lost connectivity but has now recovered
- A device suffered from a bit flip, an expected event over long
  periods of time
- An administrator accidentally wrote over a portion of the disk
  using another program

Acho que, neste ponto, verificar a conectividade com as unidades e executar o resilver é o caminho certo.