Quando deve preocupar-se com correções repetidas de somas de verificação ZFS?

Preocupe-se quando os erros de soma de verificação regressarem depois de registar e limpar a linha de base antiga, não simplesmente porque um contador não é zero.

O ZFS pode reparar um bloco danificado quando a redundância fornece uma cópia válida, mas a reparação não explica por que motivo os dados incorretos chegaram. Guarde zpool status -v e os registos do sistema relevantes, verifique as cópias de segurança e, em seguida, use a recorrência, o padrão dos dispositivos afetados e uma limpeza sem erros para decidir se o evento foi isolado ou se a falha continua ativa.

Registe o que o ZFS corrigiu antes de limpar qualquer coisa

Guarde o estado completo do pool, o carimbo temporal da limpeza, as contagens de erros por dispositivo e qualquer lista de erros permanentes. Capture também, nesse mesmo período, as mensagens do kernel relativas a reposições de ligação, tempos limite de comandos, falhas do controlador, verificações da máquina e eventos de alimentação inesperados.

Uma explicação detalhada da comunidade sobre contadores de somas de verificação reparados pelo ZFS e as suas possíveis causas distingue os blocos corrigidos da falha no cabo, na alimentação, no controlador, na memória ou no disco que poderá tê-los produzido. A reparação não certifica o caminho de hardware.

Confirme que existe outra cópia utilizável dos dados importantes antes de submeter o pool a esforço. Limpar os contadores só é aceitável depois de guardar as provas, porque a decisão seguinte depende de saber se surgem erros genuinamente novos.

Use a recorrência e o alcance como limiar de decisão

Depois de guardar a linha de base, limpe os contadores e execute uma limpeza durante um período de alimentação e temperatura estáveis. Se a limpeza terminar sem erros e a utilização normal não produzir novos erros, monitorize em vez de substituir hardware com base num único evento histórico.

Se o mesmo disco acumular novas somas de verificação incorretas, inspecione o respetivo caminho de dados e alimentação, o histórico SMART, as estatísticas da ligação e a porta do controlador. Se vários discos acumularem erros em conjunto, dê prioridade aos componentes partilhados, como o HBA, o backplane, a fonte de alimentação, o cablagem, a memória ou a estabilidade do sistema.

Qualquer erro de dados permanente, erro de E/S repetido, suspensão do pool ou contagem em rápido aumento eleva a urgência. Pare as escritas não essenciais, atualize a cópia de segurança e isole a camada suspeita antes de outra limpeza adicionar carga.

Altere uma camada e comprove o resultado

Com o sistema desligado, volte a encaixar ou substitua o cabo de dados e de alimentação suspeito, ou mova o dispositivo para uma porta conhecida como funcional. Não troque várias camadas ao mesmo tempo, caso contrário o resultado positivo não identificará qual foi o componente que alterou o desfecho.

Para um padrão específico de dispositivo, execute o teste do fabricante da unidade ou uma leitura controlada depois de analisar o histórico SMART. Para um padrão que afete vários dispositivos, teste a memória e a estabilidade da alimentação e inspecione o caminho do controlador antes de presumir que várias unidades falharam simultaneamente.

O guia de sistemas operativos para servidores domésticos ajuda a identificar onde se encontram o estado do pool, os registos do kernel e a gestão do controlador em plataformas NAS e Linux comuns.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique a recuperação sob a carga de trabalho original

Execute uma limpeza completa depois da reparação isolada e, em seguida, repita a carga de trabalho que anteriormente expôs o problema. A recuperação significa que a limpeza termina sem novos erros de soma de verificação, leitura ou escrita e que os contadores permanecem estáveis após um reinício e durante outra janela de carga de trabalho representativa.

Substitua uma unidade quando as provas a seguirem através de um caminho conhecido como funcional, quando o SMART ou os autotestes também se deteriorarem, ou quando produzir novos erros depois de eliminados os problemas de cablagem e alimentação. Substitua ou repare a camada partilhada quando os erros permanecerem associados a uma porta, caixa, controlador ou evento de alimentação.

Escalone imediatamente em caso de erros permanentes, de um pool degradado sem redundância adequada ou de incerteza sobre qual cópia é a oficial. Um evento corrigido é um aviso para diagnosticar; uma correção nova e repetível é prova de que o diagnóstico não pode ser adiado.

Perguntas frequentes

O zpool clear corrige a causa? Não. Repõe os contadores registados depois de guardar as provas; apenas uma limpeza sem erros e uma carga de trabalho de acompanhamento estável mostram que o caminho subjacente já não está a produzir dados incorretos.

É possível ignorar um único erro de soma de verificação corrigido? Trate-o como um aviso registado. Se não voltar a ocorrer depois de limpar a linha de base e realizar uma limpeza sem erros, a monitorização poderá ser proporcional; a recorrência ou falhas de E/S relacionadas exigem isolamento.

Um relatório SMART saudável elimina as suspeitas sobre o disco? Não. O SMART pode não detetar falhas no cabo, no controlador, na alimentação e algumas falhas do próprio dispositivo, por isso combine-o com o alcance do ZFS, os registos do sistema, trocas controladas e limpezas posteriores à reparação.