Questão O scrub do ZFS encontra erros de soma de verificação, mas os badblocks e o smartctl não


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 dois em cada unidade 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, desconectei a unidade da piscina e exportei a piscina. Sem importar a unidade, eu corri badblocks -b 4096 -s -v -w sobre isso, mas relatou (0/0/0) erros. Além disso smartctl -a /dev/sda 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 de unidade WD Green não fosse corrompida. Não consegui encontrar nenhuma outra ação para retorná-la ao pool do que desanexá-la. ele, limpando a tabela de partições e recolocando-a. Durante o processo de reciclagem, alguns blocos não puderam ser lidos na unidade WD Red e eu restaurei o arquivo afetado dos backups. Esfregando erros de checksum detectados antes e depois desse incidente.)


0


origem




Respostas:


Não existe uma maneira fácil de saber do que as falhas de checksum foram causadas, uma vez que elas ocorrem 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). o smartctl e badblocks os sucessos me fazem ter esperanças de que o problema não seja um disco com falha.

Esta é a página que ajuda você a entender o erro: http://illumos.org/msg/ZFS-8000-9P. 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.


1



Obrigado. Desconectei as unidades pelo menos duas vezes e troquei os cabos SATA ao mesmo tempo. Eu duvido que um cabo defeituoso ou eles sendo mal conectados poderia ser o caso para os problemas. - taneli