Quando o fsck é perigoso?

37

Recentemente, vi o sistema de arquivos raiz de uma máquina em um datacenter remoto ser remontado 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)

Após executar o fsck, conforme sugerido, e aceitar as correções manualmente com Y, os erros foram corrigidos e o sistema agora está correto.

Agora, acho que seria interessante se o fsck estivesse configurado para executar e reparar tudo automaticamente, pois a única alternativa em alguns casos (como este) é ir pessoalmente ao datacenter remoto e conectar 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 esse programa seria insegura? Quais são os casos em que o administrador do sistema pode deixar uma correção sugerida de lado por algum tempo (para executar outras operações) ou anulá-la totalmente?

— scristalli
fonte

15

Se os desenvolvedores estivessem 100% confiantes de que o erro poderia ser corrigido automaticamente, não seria um erro em primeiro lugar.

— user253751

42

fsckdefinitivamente causa mais mal do que bem se o hardware subjacente estiver danificado; CPU ruim, RAM ruim, um disco rígido em extinção, controlador de disco com defeito ... nesses casos, mais corrupção é inevitável.

Em caso de dúvida, é recomendável tirar uma imagem do disco corrompido com dd_rescueou com alguma outra ferramenta e verificar se é possível corrigir essa imagem com êxito. Dessa forma, você ainda tem a configuração original disponível.

— Janne Pikkarainen
fonte

4

Eu trabalhei muito com falhas de hardware e concordo com isso. A última coisa que quero fazer é fsck, se houver suspeita de hardware defeituoso de qualquer tipo. Também vi um evento de baixo consumo de energia e uma recuperação subsequente que foi bastante atrasada pelo fsck automático.

— jorfus

Para dar um exemplo concreto: trabalhei em uma máquina com um controlador de disco que "aleatoriamente" (cerca de uma vez em 10 ^ 5) transformava uma leitura ou uma gravação no bloco XXXXXXYY em qualquer dispositivo, em uma gravação no bloco 000000YY no primeiro dispositivo. Ou seja, frequentemente enviava dados errados estruturados e não estruturados para o setor de inicialização e várias estruturas críticas do sistema de arquivos do disco de inicialização. A execução do fsck em tal situação (milhões de leituras) pode eliminar qualquer chance restante de recuperação de dados.

— Eric Towers

2

1 em 10 ^ 5 é muito ... são 10 bytes sempre Mb.

— Nelson

1

@ Nelson: É mais ou menos ... A unidade existe "transferências de bloco único", não "bytes". Portanto, dez gravações ruins de bloco por milhão de blocos (e os blocos são significativamente maiores que bytes).

— Eric Towers

21

Você viu um exemplo em que fscktrabalhou, mas já vi mais do que suficientes sistemas de arquivos danificados, onde não funcionou com êxito. Se funcionasse totalmente automático, talvez você não tenha chance de fazer coisas como um dddespejo de disco ou algo parecido que, em muitos casos, seria uma excelente idéia 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 no servidor.

— Sven
fonte

7

Na verdade, o que não é uma boa ideia é dizer " nunca, nunca " assim, quando não é verdade. Caso de uso em que é uma boa idéia: As principais partições do servidor podem ser recriadas do zero rapidamente, em caso de problema. Dados realmente importantes são acessados através de um sistema de arquivos remoto, com redundância apropriada para esses dados. Eu prefiro ter a chance de fsck -p /e fsck -p /var, etc., funcionando bem, e ficando servidor sem intervenção manual, e arriscar a pequena chance%, diferente de zero de grande catástrofe para essas partições que eu posso apenas recriar, se necessário .

— TOOGAM

1

Se o sistema puder ser reinstalado com facilidade, eu apenas o faço ...

— Sven

1

Isso levaria mais tempo. As opções são: A) Risco de fazê-lo automaticamente. B) Peça para alguém pedir fsckpara comer e tudo funciona bem. Leva cerca de 2 minutos, se isso. Tempo de inatividade até que isso aconteça. C) Peça a alguém para reinstalar o sistema operacional. Demora mais de 30 minutos. Você está escolhendo a opção C? Talvez a principal diferença que tenhamos seja o fato de eu ter fscktrabalhado uma porcentagem maior do tempo do que o que você cita em sua resposta. Meu ponto principal não era o design do sistema (esse sistema barato-o não usa um console remoto), mas apenas o ditado " nunca, nunca " era uma frase muito forte para ser precisa

— TOOGAM

Vamos apenas concordar em discordar.

— Sven

0

Primeiro de tudo, você precisa entender que, nos sistemas de arquivos modernos (registrados em diário), uma falha no sistema não corrompe 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 redefinição do sistema.

FS não jornalizados como ext2 ou vfat são um grande NOGO para um rootfs de sistema.

Agora, se o seu sistema exige 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 seu kernel posteriormente para descobrir, quando e o que aconteceu. Você também deve voltar no tempo nos logs para descobrir desde quando o erro foi iniciado. Você deve verificar seus discos com smartctl. Etc ... Se você precisar de um fsck em um fs com registro em diário, é praticamente certo que seu hardware está falhando, assumindo que o fs não foi danificado por um administrador (com ferramentas em nível de bloco como dd) ou por um bug.

Portanto, é tolice 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, concluir a inicialização e ser feliz é ingênuo, para dizer o mínimo. Afirmar que "tive o fsck work uma porcentagem maior do que o que você cita" está me fazendo pensar no que você quer dizer com "fsck work". O fsck pode ter trazido de volta o seu fs para um estado consistente, perdendo alguns arquivos e dados no processo ... Você comparou com um backup? Muitas pessoas perdem arquivos ou corrompem os dados sem perceber ...

— François Scheurer
fonte