Temos placa personalizada baseada em BBB, tem 256 MB de RAM e 4 GB ou eMMC. Estamos usando Linux-3.12 e no eMMC temos partições ext4.
Estou escrevendo um script que é executado periodicamente e verifica erros no sistema de arquivos e, se as partições não estiverem montadas, estou tentando corrigir erros usando e2fsck.
Inicialmente eu estava usando e2fsck -n /dev/mmcblk0pN (N is partition number)para verificar erros na partição do sistema de arquivos.
No entanto, o comando acima começou a dar resultados errados quando a partição é montada e os arquivos estão sendo criados na partição.
Agora eu precisava de uma alternativa para verificar erros no sistema de arquivos.
Uma das opções é usar tune2fs -lo comando naquele Filesystem statecampo de verificação de partição.
Agora não tenho certeza se este campo é confiável para verificar erros do sistema de arquivos ou não. E quais valores possíveis esse campo pode ter? Eu vi seus valores clean, clean with errorsmas not cleannão recebo mais informações na página de manual.
Então, é tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”confiável para detectar erros no sistema de arquivos? Alguma outra opção melhor para verificar erros do sistema de arquivos na partição?
Alguma sugestão/indicadores/informações?
Responder1
"Tune2fs -l" informará se o kernel notou problemas de corrupção no sistema de arquivos enquanto estava em execução. Por exemplo, se você pedir ao ext4 para excluir um arquivo e o ext4 descobrir que alguns dos blocos nesse arquivo já foram marcados como desalocados, isso significa que o bitmap de alocação está corrompido. Observe que o bitmap de alocação já estava corrompido no momento em que o ext4 o descobriu. Na verdade, ele poderia estar corrompido por dias ou semanas, e se você estivesse gravando novos arquivos, é possível que o ext4 tenha alocado blocos para novos arquivos que eram usados para arquivos mais antigos, e o usuário pode ter perdido dados como resultado. resultado.
A única maneira de dizer com segurança se um sistema de arquivos é consistente ou não ou pode estar corrompido é executar o e2fsck nele. Fazer isso requer que o sistema de arquivos seja desmontado ou a criação de um instantâneo somente leitura. (Se você estiver usando o LVM, você pode criar um instantâneo somente leitura, verificar o instantâneo somente leitura e, se o sistema de arquivos estiver corrompido, você pode reinicializar o sistema e deixar o e2fsck consertar o sistema de arquivos, ou envie um e-mail ao administrador do sistema para agendar um tempo de inatividade para corrigir o sistema de arquivos.)
Dito isso, se o sistema de arquivos foi corrompido, provavelmente é devido a um problema de hardware, o caso mais comum. É possível que seja por causa de um bug do kernel, embora eu execute periodicamente testes de regressão nos kernels estáveis, não apenas no upstream, e não tenhamos problemas de corrupção de fs há muito tempo. É possível que haja um bug de corrupção de memória em um driver de dispositivo e (a) o driver do dispositivo não esteja no upstream e o fornecedor do hardware não tenha feito o controle de qualidade adequado ou (b) o bug tenha sido corrigido no upstream , e até mesmo enviado para o kernel estável mais recente, mas o kernel do dispositivo não estava recebendo atualizações da série de kernel estável.
Observe que se você está procurando ver se o sistema de arquivos foi corrompido porque o kernel tropeçou em algo flagrantemente errado, você não precisa apenas raspar 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á a hora (usando a época Unix) em que uma corrupção do sistema de arquivos foi detectada pelo kernel. O arquivo errors_count nesse diretório informará quantas corrupções no sistema de arquivos foram detectadas (mas isso pode ser apenas o sistema tropeçando no mesmo problema repetidamente). Também é interessante que, se você quiser testar como seu sistema está lidando com 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"
Finalmente, dê uma olhada no botão de comportamento de erros que você pode definir no tune2fs. Pode ser que, se você realmente quiser ter certeza de que mais danos não serão causados após a detecção de um problema de corrupção do sistema de arquivos, você queira 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 sequência de inicialização para corrigir um problema antes que (ainda mais) dados do usuário sejam corrompidos ou perdidos.