O tune2fs -l / dev / mmcblk0pN é confiável para verificar o erro do sistema de arquivos?

Question

Temos placa personalizada com base em BBB, tem 256MB de RAM e 4GB ou eMMC. Estamos usando o Linux-3.12 e no eMMC temos partições ext4.

Estou escrevendo um script que é executado periodicamente e verifica se há erros no sistema de arquivos e se as partições não estão montadas. Estou tentando corrigir o erro usando o e2fsck.
Inicialmente eu estava usando e2fsck -n /dev/mmcblk0pN (N is partition number) para verificar o erro na partição do sistema de arquivos.
No entanto, o comando acima começou a dar resultados errados quando a partição foi montada e os arquivos foram criados na partição.

Agora eu precisava de uma alternativa para verificar o erro do sistema de arquivos,
Uma opção é usar o comando tune2fs -l nessa verificação de partição para o campo Filesystem state .

Agora não tenho certeza se esse campo é confiável para verificar erros no sistema de arquivos ou não? E quais valores possíveis esse campo pode ter? Vi seus valores clean , clean with errors e not clean , mas não recebo mais informações da página man.

Então, É tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error” confiável para detectar erros do sistema de arquivos? Qualquer outra opção melhor para verificar os erros do sistema de arquivos na partição?

Alguma sugestão / ponteiros / informação?

    

Answer 1

"Tune2fs -l" informará se o kernel detectou problemas de corrupção do sistema de arquivos enquanto está em execução. Por exemplo, se você solicitar que o ext4 exclua um arquivo, e o ext4 descobrir que alguns dos blocos desse arquivo já foram marcados como desalocados, isso significa que o bitmap de alocação está corrompido. Note que o bitmap allocaiton já estava corrompido no momento em que o ext4 o descobriu. Na verdade, poderia ter sido corrompido por dias ou semanas, e se você estivesse escrevendo novos arquivos, é possível que o ext4 possa ter alocado blocos para novos arquivos que foram usados em arquivos mais antigos, e o usuário pode ter perdido dados como um resultado.

A única maneira de dizer com certeza se um sistema de arquivos é consistente ou pode ter alguma quantidade de corrupção é executar o e2fsck nele. Isso exige que o sistema de arquivos seja desmontado ou crie uma captura instantânea somente leitura. (Se você estiver usando o LVM, você pode criar um instantâneo somente leitura, verificar o instantâneo somente leitura e, em seguida, se o sistema de arquivos estiver corrompido, você pode reinicializar o sistema e permitir que o e2fsck corrija o sistema de arquivos, ou envie um e-mail para o administrador do sistema para agendar o tempo de inatividade para corrigir o sistema de arquivos.)

Tudo isso dito, se o sistema de arquivos foi corrompido, é provável que seja devido a um problema de hardware como o caso mais comum. É possível que isso ocorra devido a um bug do kernel, embora eu execute periodicamente testes de regressão nos kernels estáveis, não apenas no upstream, e não tivemos um problema de corrupção do fs em um tempo muito longo. É possível que haja um erro de corrupção de memória em um driver de dispositivo e (a) o driver de dispositivo não seja upstream e o fornecedor de hardware não tenha controle de qualidade adequado ou (b) o bug tenha sido corrigido pelo desenvolvedor e até mesmo empurrado para o último kernel estável, mas o kernel do dispositivo não estava recebendo atualizações da série estável do kernel.

Note que se você está procurando para ver se o sistema de arquivos foi encontrado corrompido porque o kernel tropeçou em algo claramente errado, você não precisa apenas copiar o dmesg ou / var / log / messages. Você também pode tentar ler o arquivo / sys / fs / ext4 // first_error_time. Se esse arquivo contiver um valor diferente de zero, isso informará o tempo (usando a época do Unix) de que uma corrupção do sistema de arquivos foi detectada pelo kernel. O arquivo errors_count nesse diretório informará quantas corrupções do sistema de arquivos foram detectadas (mas isso pode ser apenas o sistema tropeçando no mesmo problema repetidas vezes). Também é interessante, se você quiser testar como seu sistema está manipulando os erros do sistema de arquivos detectados pelo kernel, você pode tentar escrever uma string no arquivo trigger_fs_error --- por exemplo, echo "test error" > / sys / fs / ext4 / sda1 / trigger_fs_error "

Por fim, dê uma olhada no botão de comportamento de erros que você pode definir em tune2fs. Pode ser, se você quiser realmente ter certeza de que mais danos não serão feitos depois que um problema de corrupção do sistema de arquivos for detectado, que você deseja configurar o sistema de arquivos para se remontar somente leitura quando um problema for encontrado --- ou talvez apenas forçar uma reinicialização, para que o e2fsck possa ser executado durante a seqüência de inicialização para corrigir um problema antes que (ainda mais) dados do usuário sejam corrompidos ou perdidos.