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, este erro foi mostrado:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
Depois de executar 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 rodar e consertar tudo automaticamente, já que a única alternativa em alguns casos (como este) é ir pessoalmente ao datacenter remoto e anexar um console à máquina afetada.
Minha pergunta é: por que o fsck por padrão solicita intervenção manual? Como e quando uma correção realizada por tal programa seria insegura? Quais são os casos em que o administrador do sistema pode querer deixar uma correção sugerida de lado por algum tempo (para realizar algumas outras operações) ou abortá-la de uma vez?
fsckdefinitivamente causa mais mal do que bem se o hardware subjacente estiver danificado de alguma forma; CPU ruim, RAM ruim, um disco rígido moribundo, controlador de disco que estragou... nesses casos, mais corrupção é inevitável.Em caso de dúvida, é uma boa ideia apenas tirar uma imagem do disco corrompido com
dd_rescueou alguma outra ferramenta e, em seguida, ver se você pode corrigir essa imagem com sucesso. Dessa forma, você ainda tem a configuração original disponível.Você viu um exemplo em que
fsckfuncionou, mas já vi sistemas de arquivos danificados mais do que suficientes em que não funcionou com êxito. Se funcionasse totalmente automático, talvez você não tivesse chance de fazer coisas como umdddespejo de disco ou algo parecido que, em muitos casos, seria uma excelente ideia antes de tentar um reparo.Nunca é uma boa ideia tentar algo assim automático.
Ah, e os servidores modernos devem ter consoles remotos ou, pelo menos, sistemas de resgate independentes para se recuperar de algo assim sem carregar um rack KVM para o servidor.
Em primeiro lugar, você precisa entender que, com sistemas de arquivos modernos (divulgados), uma falha no sistema não corromperá o sistema de arquivos e nenhum fsck será necessário 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.
FS não registrados como ext2 ou vfat são 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 o motivo disso em primeiro lugar?
Você deve investigar os logs do kernel posteriormente para descobrir quando e o que aconteceu. Você também deve voltar no tempo nos logs para descobrir desde quando o erro começou. Você deve verificar seus discos com smartctl. Etc... Se você precisar de um fsck em um fs registrado, é praticamente certo que seu hardware está falhando, assumindo que o fs não foi danificado por um administrador (com ferramentas de nível de bloco como dd) ou por um bug.
Portanto, é bobagem usar o fsck para "consertar" o problema sem investigar e corrigir a causa raiz (substituindo/atualizando o hardware/firmware/software com defeito).
Fazer fsck, completar a bota e ser feliz é no mínimo ingênuo. Afirmar "Eu tive fsck trabalhando uma porcentagem maior do tempo do que você citou" está me fazendo pensar o que você quer dizer com "fsck work". O fsck pode ter trazido seu fs de volta a um estado consistente, perdendo alguns arquivos e dados no processo... Você comparou com um backup? Muitas pessoas perdem arquivos ou corrompem os dados do arquivo sem perceber...