Quando o fsck é perigoso?

Question

Recentemente, vi o sistema de arquivos raiz de uma máquina em um datacenter remoto ser remontado como somente leitura, como resultado de problemas de consistência.

Na reinicialização, esse erro foi exibido:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Depois de executar o fsck como sugerido e aceitar as correções manualmente com Y , os erros foram corrigidos e o sistema agora está bem.

Agora, acho que seria interessante se o fsck fosse configurado para executar e reparar tudo automaticamente, já que a única alternativa em alguns casos (como este) é ir pessoalmente ao datacenter remoto e conectar um console ao afetado. máquina.

A minha pergunta é: por que o fsck, por padrão, pede intervenção manual? Como e quando uma correção executada por tal programa seria insegura? Quais são os casos em que o administrador de sistema pode querer deixar uma correção sugerida de lado por algum tempo (para realizar algumas outras operações) ou abortar tudo isso?

    

Answer 1

fsck definitivamente causa mais danos do que benefícios se o hardware subjacente estiver danificado de alguma forma; CPU ruim, RAM ruim, disco rígido em estado de morte, controlador de disco que ficou ruim ... nesses casos, mais corrupção é inevitável.

Se estiver em dúvida, é uma boa ideia apenas tirar uma imagem do disco corrompido com dd_rescue ou alguma outra ferramenta e, em seguida, verificar se você consegue consertar essa imagem. Dessa forma, você ainda tem a configuração original disponível.

    

Answer 2

Você viu um exemplo em que fsck funcionou, mas eu vi mais que sistemas de arquivos danificados onde eles não funcionaram com sucesso. Se funcionasse de maneira totalmente automática, talvez você não tivesse nenhuma chance de fazer coisas como um dd de despejo de disco ou algo parecido que, em muitos casos, seria uma excelente ideia para fazer antes de tentar um reparo.

nunca, nunca é uma boa ideia tentar algo assim automático.

Ah, e servidores modernos devem ter consoles remotos ou, pelo menos, sistemas de resgate independentes para se recuperar de algo parecido sem arrastar um rack KVM para o servidor.

    

Answer 3

Primeiro de tudo, você precisa entender que com sistemas de arquivos modernos (journalizados), uma pane no sistema não corromperá o sistema de arquivos e nenhum fsck será requerido no momento da inicialização.

Ext3, Ext4, ZFS, btrfs, xfs e todos os FS modernos são 100% consistentes após uma falha ou reinicialização do sistema.

O FS não jornalizado como ext2 ou vfat é um grande NOGO para um sistema rootfs.

Agora, se o seu sistema requer um fsck no momento da inicialização, você deve se perguntar: qual foi a razão para isso em primeiro lugar?

Você deve investigar seus logs do kernel depois para descobrir, quando e o que aconteceu. Você também deve voltar no tempo nos logs para localizar desde quando o erro foi iniciado. Você deve verificar seus discos com o smartctl. Etc ... Se você precisa de um fsck em um fs em diário, é praticamente certo que seu hardware está falhando, supondo que o fs não tenha sido danificado por um administrador (com ferramentas em nível de bloco como dd) ou por um bug.

Portanto, é bobagem usar o fsck para "corrigir" o problema sem investigar e corrigir a causa raiz (substituindo / atualizando o hardware / firmware / software com defeito).

Fazer um fsck, completar o boot e ser feliz é ingênuo para dizer o mínimo. Afirmar "Eu tive fsck trabalhar uma porcentagem maior do que o que você cita" está me fazendo pensar no que você quer dizer com "trabalho fsck". O fsck pode ter trazido de volta seu fs para um estado consistente, perdendo alguns arquivos e dados no processo ... Você comparou com um backup? Muitas pessoas perdem arquivos ou obtêm corrupção de dados de arquivos sem perceber ...