Por que é que um servidor doméstico perde uma unidade NVMe apenas depois de sair do modo de suspensão?
Uma unidade NVMe pode desaparecer depois de entrar em suspensão quando o respetivo controlador ou ligação PCIe não consegue sair corretamente de um estado de baixo consumo durante a retoma.
Uma unidade que funciona depois de um arranque a frio, mas desaparece apenas depois de ser suspensa, geralmente não tem um simples problema no sistema de ficheiros. A falha pode ocorrer antes de o espaço de nomes, a partição, o sistema de ficheiros ou a aplicação ficarem visíveis: o dispositivo PCIe pode não ser novamente enumerado, o controlador NVMe pode não ficar pronto ou uma combinação de mecanismos de gestão de energia pode deixar a ligação inacessível. Diagnostique primeiro a camada inferior que desapareceu e evite formatar, substituir ou reconstruir o armazenamento até compreender o caminho do dispositivo.
Determine a camada inferior que desaparece após a retoma
Antes de suspender, registe o dispositivo PCI, o controlador NVMe, os espaços de nomes, as partições, os UUID do sistema de ficheiros, os pontos de montagem e as aplicações que utilizam a unidade. Repita as mesmas verificações imediatamente após a retoma.
O subsistema NVMe do Linux expõe os controladores e os espaços de nomes como camadas separadas. O comando nvme list do Ubuntu ajuda a distinguir entre um controlador desaparecido e um controlador que continua presente, mas já não expõe o espaço de nomes esperado.
Se a função PCI estiver ausente, concentre-se no firmware, na gestão de energia da ligação PCIe e no comportamento durante a suspensão. Se o controlador continuar presente, mas o dispositivo de blocos desaparecer, concentre-se na reposição do NVMe, nos espaços de nomes, nos erros do controlador e no estado de prontidão do controlador.
Compare o arranque a frio, o reinício e cada estado de suspensão suportado
Teste um arranque a frio, um reinício normal, a suspensão para estado inativo e a suspensão profunda, mas apenas quando o sistema operativo e o firmware os disponibilizarem. Registe qual das transições reproduz a falha.
O kernel do Linux distingue entre suspensão para estado inativo, standby e suspensão para RAM, cada uma com um nível diferente de redução do consumo de energia dos dispositivos e da plataforma. A descrição dos estados de suspensão do kernel explica por que razão um controlador NVMe pode retomar corretamente a partir de um estado superficial, mas falhar depois de uma transição de plataforma mais profunda.
Uma falha limitada a um único estado é uma evidência mais forte de um problema de transição de energia do que de um problema de formatação do disco. Mantenha disponível o estado que funciona enquanto testa uma correção permanente de firmware ou do controlador.
Verifique se o dispositivo PCIe é novamente enumerado
Compare os dados do barramento PCI antes da suspensão e depois da retoma, incluindo o endereço do controlador NVMe, o estado negociado da ligação, o controlador do kernel e os contadores de erros. Guarde o endereço exato do barramento antes de testar.
O utilitário lspci apresenta o controlador na camada PCI antes de qualquer espaço de nomes ou sistema de ficheiros estar envolvido, sendo por isso o indicador correto quando todo o dispositivo NVMe parece desaparecer.
Se o dispositivo estiver ausente da enumeração PCI, voltar a pesquisar o sistema de ficheiros ou recriar os pontos de montagem não ajudará. Se continuar visível, recolha os erros do NVMe e do kernel antes de tentar repor o controlador.
Teste as transições autónomas de estado de energia do NVMe
Registe as definições atuais dos estados de energia do NVMe e se as transições autónomas de estado de energia estão ativadas. Altere apenas uma variável relacionada com a energia durante um único ciclo de suspensão controlado.
A ArchWiki documenta o comportamento de poupança de energia do NVMe e o controlo de latência do APST, utilizado para limitar a profundidade a que o controlador pode entrar em estados de baixo consumo quando determinado hardware retoma de forma pouco fiável.
Uma restrição temporária do APST é uma ferramenta de diagnóstico, não uma prova de que todos os estados profundos têm problemas. Se a unidade sobreviver a ciclos repetidos de retoma apenas com uma política de energia mais superficial, compare as correções de firmware e do kernel antes de manter a solução alternativa permanentemente.
Analise o firmware, o BIOS e o comportamento do Modern Standby
Registe a versão do firmware da placa-mãe, o firmware do NVMe, a compilação do sistema operativo e qualquer alteração recente ao BIOS ou ao controlador. Verifique se a plataforma utiliza a suspensão tradicional ou um modelo moderno de estado inativo de baixo consumo.
O modelo Modern Standby da Microsoft mostra que os dispositivos suportados permanecem sujeitos a um comportamento de baixo consumo gerido pela plataforma, em vez de seguirem o mesmo percurso da suspensão tradicional, o que pode alterar a forma como um problema de NVMe se reproduz entre sistemas.
Atualize uma camada de firmware de cada vez e mantenha a versão anterior ou um método de recuperação. Não combine uma atualização do BIOS, uma atualização do firmware do SSD e uma atualização do sistema operativo no mesmo teste, pois não será possível identificar qual alteração resolveu o problema.
Inspecione a gestão de energia da ligação PCIe e a gestão de energia em tempo de execução
Verifique as definições do ASPM PCIe, o estado da energia em tempo de execução e se o controlador NVMe entra num estado de suspensão em tempo de execução antes de o sistema ser suspenso. Compare a ranhura afetada com outra ranhura apenas se o design do servidor o permitir em segurança.
As orientações da Red Hat sobre gestão de energia explicam que a gestão de energia em tempo de execução e o ASPM PCIe são mecanismos separados; por isso, desativar um e observar uma alteração não identifica automaticamente esse mecanismo como a causa.
Se o problema acompanhar a unidade para outra ranhura, suspeite do controlador ou do firmware. Se permanecer numa única ranhura, analise o firmware da placa-mãe, a bifurcação, as pistas partilhadas, a alimentação da ranhura e a integridade do sinal.
Recupere em segurança e verifique ciclos repetidos de retoma
Quando a unidade desaparecer, preserve os registos antes de desligar a frio. Evite reposições a quente repetidas se o controlador comunicar um estado fatal, erros de ligação ou espaços de nomes desaparecidos.
A lista de verificação de recuperação de servidores domésticos da ZimaSpace fornece a regra complementar: verifique a visibilidade do hardware e o estado do armazenamento antes de executar uma reparação do sistema de ficheiros ou restaurar dados.
O problema está resolvido quando o controlador, o espaço de nomes, as partições, os pontos de montagem e as aplicações sobrevivem a ciclos repetidos de suspensão e retoma no estado de energia pretendido. Mantenha uma cópia de segurança atualizada até a correção também sobreviver ao reinício, ao tempo de inatividade e à carga normal de armazenamento.
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...
