Porque é que os erros de verificação do NAS seguem uma porta do controlador entre diferentes unidades?
Os erros de scrub que seguem uma porta do controlador através de diferentes unidades costumam apontar para o caminho partilhado, e não para o suporte de gravação dos discos.
Um scrub lê um conjunto abrangente de blocos e pode detetar falhas que o acesso diário normal nunca alcança. Se diferentes unidades conhecidas como funcionais desenvolvem erros apenas quando ligadas através da mesma porta, os componentes comuns incluem o canal do controlador, o conector, o cabo, a via do backplane, a rota do expansor, o circuito de alimentação, o firmware e a refrigeração em torno desse caminho. O diagnóstico tem de provar que o erro segue a porta, preservando simultaneamente a identidade da unidade, os carimbos temporais e o tipo de erro.
Confirme que o erro segue a porta, e não o nome da unidade
Registe os números de série das unidades, os IDs de dispositivo estáveis, a porta do controlador ou PHY do HBA, o cabo, a baía, o membro do pool e os contadores de leitura, escrita e soma de verificação antes do próximo scrub. Não dependa apenas da alteração dos nomes /dev/sdX.
O fluxo de resolução de problemas de unidades do TrueNAS salienta a recolha de dados do pool e do SMART antes de limpar erros ou substituir um dispositivo.
Depois de uma troca com o equipamento desligado, verifique se o erro segue a unidade, a baía, o cabo ou a porta do controlador. Altere apenas um componente por teste, para que o resultado continue a ser interpretável.
Separe os erros de soma de verificação do scrub dos erros de leitura e escrita da unidade
Guarde o resultado completo do scrub e os contadores de cada dispositivo. Uma discrepância de soma de verificação, um tempo limite de comando, um setor ilegível e uma escrita falhada representam camadas de falha diferentes.
A Oracle documenta que um scrub ZFS verifica as somas de verificação dos dados ativos, enquanto o estado do pool comunica separadamente os erros de leitura, escrita e soma de verificação de cada dispositivo.
Se os erros de soma de verificação aumentarem sem erros de suporte físico e seguirem um único caminho físico, suspeite de corrupção de dados entre a memória e a unidade ou de um transporte instável. Se os erros de leitura seguirem a unidade através de diferentes portas, aumenta a probabilidade de o problema estar no disco.
Mapeie o disco para o controlador e a ligação exatos
Siga o caminho estável do disco através do controlador anfitrião, do endereço PCI, do expansor SAS ou da porta SATA, do compartimento, do cabo e da baía. Guarde o mapeamento antes de mover o hardware.
A vista de dispositivos do lspci identifica o controlador de armazenamento PCI independentemente dos nomes do sistema de ficheiros e do pool, ajudando a distinguir um caminho de controlador com falhas de um disco que apenas recebeu um novo nome de dispositivo.
No caso de um HBA, inclua as informações do PHY e do expansor, quando disponíveis. Duas baías frontais podem partilhar um cabo mini-SAS ou uma via do expansor, embora a interface as apresente como ranhuras separadas.
Inspecione as reinicializações da ligação SATA ou SAS durante o scrub
Monitorize o registo do kernel desde o momento em que o scrub começa. Procure reinicializações forçadas, falhas de COMRESET, eventos de perda de ligação, tempos limite de comandos, erros de protocolo e alterações na velocidade negociada no caminho afetado.
O guia libATA do Linux descreve a reinicialização da ligação por porta e a recuperação de erros, mostrando por que razão mensagens repetidas associadas a uma única porta ATA constituem indícios mais fortes do que um aviso genérico do pool.
Preserve a primeira mensagem de transporte. Os erros posteriores do sistema de ficheiros podem ser apenas consequências da perda de comunicação entre o controlador e a unidade durante uma leitura.
Compare os contadores de CRC da interface e de tempos limite de comandos
Capture os atributos e registos SMART de cada unidade antes e depois de um scrub. Verifique se os contadores de CRC da interface ou de tempos limite de comandos aumentam apenas no caminho afetado.
O Unraid explica que os erros CRC UDMA ocorrem entre a unidade e o controlador, implicando normalmente cabos, conectores, encaminhamento ou a ligação do controlador, e não danos nos pratos.
Os totais históricos de CRC não identificam o componente atual. Registe o valor bruto, execute um teste delimitado e verifique apenas se o valor aumentou.
Execute testes à unidade separadamente da carga de trabalho do scrub
Execute testes SMART curtos e prolongados suportados quando o pool estiver, de resto, inativo e os dados estiverem protegidos. Evite agendar um teste SMART completo ao mesmo tempo que outro scrub ou uma reconstrução.
A referência do smartctl para Debian separa os autotestes internos da unidade e os registos de erros da verificação do sistema de ficheiros no anfitrião.
Uma unidade que passe um teste interno, mas produza erros apenas numa porta específica do controlador, reforça a hipótese de um problema no caminho. Isso não prova que o disco esteja perfeito, pelo que deve continuar a monitorizá-lo depois de mudar a porta.
Troque um componente partilhado e repita um scrub delimitado
Com as cópias de segurança atualizadas e o servidor desligado, mova uma unidade conhecida como funcional através do caminho suspeito ou substitua um cabo, mantendo as restantes variáveis estáveis. Não troque todas as unidades em simultâneo.
O guia da ZimaSpace sobre um disco desligado versus uma baía com problemas apresenta o método de troca controlada relacionado; este artigo aplica essa lógica especificamente aos erros de scrub que seguem repetidamente uma porta do controlador.
Pare o scrub e dê prioridade à proteção dos dados se os erros aumentarem rapidamente, se várias unidades do mesmo controlador forem reinicializadas, se o pool ficar degradado ou se as aplicações comunicarem ficheiros corrompidos. O problema só estará resolvido depois de o mesmo caminho da porta concluir vários scrubs e operações normais de E/S sem novos erros.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
