Tema
Se um sistema de arquivos foi reparado com sucesso pelo e2fsck, é garantido que ele está em um estado consistente (limpo). No entanto, não é fácil avaliar a confiabilidade dos próprios arquivos após o reparo.
Esta questão visa critérios para julgar a integridade dos dados armazenados em sistemas de arquivos ext2 e ext4 que foram reparados após serem danificados em um cenário de falha específico.
Fundo
Eu uso um sistema de arquivos ext2 em um HDD USB externo (ou seja, baseado em prato, sem flash) para fazer backup de várias máquinas Linux. Para isso, monto o drive manualmente com as opções rw, relatime(no total), então nenhuma syncopção é usada.
Recentemente, depois de fazer um backup grande (vários 100 GB) de um sistema openSUSE 13.1 (kernel Linux 3.11.6-4) e depois que todas as atividades de gravação no HDD USB foram concluídas, não consegui desmontar essa unidade: O umountcomando bloqueado e não retornou. syncO mesmo se aplica a um comando emitido posteriormente , que entrou em suspensão ininterrupta ( psestado D).
Foi quando desconectei o HDD USB, que não liberou os blocos.
Uma tentativa de desligar a máquina posteriormente por meios padrão (pm-utils) também ficou presa. Para derrubar a máquina, usei a saudação SysRq r, e, i, s, u, b. Mas mesmo lá, as solicitações s(sincronizar) e u(remontar somente leitura) não foram bem-sucedidas: De acordo com a documentação do kernel para sysrq.c (sysrq.txt), essas solicitações não são concluídas antes de anunciarem explicitamente que são, o que nenhum dos fizeram neste caso. Portanto, nenhum dos sistemas de arquivos montados foi confirmado como desmontado corretamente quando o SysRq b(reinicialização) atingiu, o que finalmente iniciou uma reinicialização completa.
Verificando todos os sistemas de arquivos envolvidos (ext4 na partição raiz e ext2 no HDD USB) com e2fsck, felizmente encontrei o sistema de arquivos raiz limpo, e o sistema de arquivos no HDD USB mostrou apenas contagens erradas de blocos e inodes livres, que poderiam ser reparados pelo e2fsck.
O diário do Systemd da máquina que foi usado aqui não mostrou nenhuma entrada relacionada ao bloqueio do umount e das sincronizações. Em particular, não havia entradas relacionadas a problemas de IO. O evento USB unplug e o restante das minhas medidas, além dos SysRqs, foram registrados corretamente.
O SMART e badblocksos testes que foram realizados no HDD USB após esse incidente não revelaram nenhuma anomalia. A unidade, que tem cerca de 5 meses, parece funcionar normalmente agora.
Variações
Encontrei o mesmo cenário várias vezes nos últimos anos com diferentes HDDs USB (nenhum deles com mais de 16 meses) e em diferentes máquinas Linux executando diferentes versões do kernel. O único desvio no meu tratamento foi que às vezes eu usava o botão liga / desliga em vez do SysRq para desligar a máquina.
Em cada um desses incidentes, verifiquei todos os sistemas de arquivos possivelmente afetados (todos ext2 e ext4) com e2fsck, encontrando todos eles em um dos seguintes estados de erro:
Sistema de arquivos limpo.
Sistema de arquivos sujo que e2fsck poderia reparar apenas reproduzindo o diário (ext4).
Sistema de arquivos mostrando contagens erradas de blocos e inodes livres que podem ser corrigidos pelo e2fsck.
Sistema de arquivos contendo inodes órfãos que o e2fsck conectou ao lost+found.
Sistema de arquivos contendo inodes de várias reivindicações (reivindicados por vários arquivos) que foram clonados por e2fsck.
A pergunta real
Um sistema de arquivos ext2 ou ext4 que foi afetado pelo cenário descrito acima e posteriormente reparado com sucesso pelo e2fsck está certamente em um estado consistente (limpo).
Mas e quanto ao conteúdo e metadados dos arquivos dentro desse sistema de arquivos?
Existe uma correlação exclusiva entre os danos ao sistema de arquivos encontrados pelo e2fsck e a corrupção de dados? Por exemplo como:
Se nenhum outro dano além de contagens erradas for encontrado no sistema de arquivos, os dados reais do arquivo estão corretos.
Ou:
Se o sistema de arquivos contiver inodes com várias solicitações, o conteúdo de pelo menos um arquivo estará corrompido.
Ou é o contrário: o sistema de arquivos e os dados dos arquivos são independentes na medida em que não se pode concluir dos danos de um aos do outro - pelo menos sem um conhecimento exato sobre o que causou o dano no nível de comunicação do dispositivo?
No último caso, o cenário descrito poderia ter corrompido o conteúdo do arquivo, mesmo que o sistema de arquivos fosse posteriormente considerado limpo. Certo?
Existem valores de experiência ou critérios fundamentados que podem ser usados para avaliar a integridade dos arquivos, dependendo dos erros do sistema de arquivos encontrados pelo e2fsck?
Nesse contexto, a resposta de Gilles para "Como testar a correção do sistema de arquivos feita pelo fsck" é uma boa leitura.
A distinção entre sistema de arquivos e integridade de dados também é abordada na seção "Modo de dados" na documentação do kernel do sistema de arquivos ext4 . Para este último, fui apontado pela excelente resposta de Mikel para "Os sistemas de arquivos com journaling garantem contra corrupção após uma falha de energia?" , que também é muito relevante para este tópico.
Suposição própria e impacto
Systemd oferece a unidade de serviço (template) [email protected] que por padrão "preens" sistemas de arquivos selecionados passnoem /etc/fstab no momento da inicialização. De acordo com a descrição da -popção na página man e2fsck(8) , preening "corrige automaticamente quaisquer problemas do sistema de arquivos que podem ser corrigidos com segurança sem intervenção humana." Infelizmente, a descrição não especifica se "seguramente" se refere apenas à consistência do sistema de arquivos ou também inclui o conteúdo e os metadados dos arquivos.
No entanto, como esse serviço do Systemd inicia a limpeza de maneira totalmente transparente para o usuário, existem pelo menos alguns especialistas que confiam suficientemente nos resultados dos reparos do sistema de arquivos correspondentes.
Portanto, com base em um sentimento vago (!), eu diria que para sistemas de arquivos limpos (estado de erro 1 descrito acima) e tais que possam ser reparados apenas reproduzindo o diário (estado de erro 2), é seguro assumir que os próprios arquivos não são corrompidos, mesmo após tal incidente.
Para sistemas de arquivos que estavam no estado de erro 5, por outro lado, eu me referiria a um backup.
Então, por que tanto barulho? De acordo: No caso de um sistema de arquivos inicial ou raiz padrão, eu apenas compararia seu conteúdo com o backup mais recente. Mas, neste caso, esses backups estão no próprio HDD USB afetado. Se houver alguma dúvida sobre sua integridade, várias máquinas precisam ser copiadas instantaneamente novamente. , sem significado.
Portanto, seria bastante útil ter alguns critérios razoáveis e confiáveis sobre até que ponto podemos confiar nos dados em um sistema de arquivos ext2 ou ext4 que foi reparado após ser afetado pelo cenário descrito.
Outras descobertas
Tentando resolver esse problema sozinho, encontrei este excelente capítulo sobre fsck no Oracles System Administration Guide for Sun. Embora descreva a versão USF do fsck, as ideias gerais também se aplicam ao e2fsck. Mas também este documento muito detalhado se concentra no uso do fsck e no próprio sistema de arquivos, em vez de considerar a carga útil deste último.
Nesta resposta para "O que fsck -p (preen) faz no ext4?" , Noah postou uma lista de erros do sistema de arquivos que podem ser tratados automaticamente pelo fsck preening um sistema de arquivos ext4 e aqueles que não podem ser. Seria ótimo ter uma lista de erros do sistema de arquivos que indique quais deles implicam em corrupção de dados de arquivo e quais não - é claro, apenas se tal correlação existir ...
Em sua resposta , Michael Prokopec mencionou a importância dos caches de gravação para essa pergunta. A esse respeito, encontrei na resposta de Tall Jeff para "Discos SATA que manipulam o cache de gravação corretamente?" que pelo menos a maioria das unidades SATA tem o cache de gravação ativado por padrão. No entanto, de acordo com o mesmo post, as unidades tentam liberar esses caches o mais rápido possível. Mas é claro que não há garantias...
Você pode estar razoavelmente certo de que, se todas as verificações forem aprovadas, os dados são confiáveis. No entanto, dependendo da idade da unidade e do caso de uso, eu clonaria a unidade para uma mais recente e usaria a nova unidade.