Jürgen's questions

Resumo: O E2fsck não encontrou erro com a -nopção mas com -p(preen). Ele corrigiu o erro, mas não deu nenhuma mensagem de erro. O erro é refletido apenas por meio do código de saída. Como interpretar isso?

Estou usando um disco rígido USB com um sistema de arquivos Ext2 para armazenar backups de várias máquinas. Recentemente, tive uma enorme taxa de transferência de dados nessa unidade, por isso decidi fazer uma verificação extra do sistema de arquivos. No total, fiz quatro e2fsckcorridas com opções diferentes. Aqui estão os comandos que usei (como root) junto com suas saídas, que também contêm o status de saída de e2fsck. Infelizmente, algumas frases estão localizadas em alemão, mas as (presumivelmente) importantes estão em inglês:

1ª execução, somente leitura:

# e2fsck -nv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0

2ª execução, somente leitura forçado:

# e2fsck -nfv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung

  709312 inodes used (1.16%)
   95492 non-contiguous inodes (13.5%)
         # von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258851 blocks used (39.42%)
       0 bad blocks
       8 large files

  564029 regular files
  121351 directories
       0 character device files
       0 block device files
      11 fifos
  506224 links
   23073 symbolic links (19397 fast symbolic links)
     839 sockets
--------
 1215527 files
0

3ª corrida, alisando:

# e2fsck -pv /dev/sdb1; echo $?
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0

4ª corrida, alisando forçado:

# e2fsck -pfv /dev/sdb1; echo $?

  709312 inodes used (1.16%)
   95492 non-contiguous inodes (13.5%)
         # von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258853 blocks used (39.42%)
       0 bad blocks
       8 large files

  564029 regular files
  121351 directories
       0 character device files
       0 block device files
      11 fifos
  506224 links
   23073 symbolic links (19397 fast symbolic links)
     839 sockets
--------
 1215527 files
1

Os comandos foram emitidos diretamente, um após o outro, sem tocar em mais nada entre eles.

Observe as diferenças:

• Nas duas primeiras execuções, o sistema de arquivos foi aberto somente leitura ( -nopção), enquanto as duas últimas foram execuções preening ( -popção).

• A primeira e a terceira corrida não foram forçadas, a segunda e a última corrida foram ( -f).

• Todas as execuções relataram dados coincidentes do sistema de arquivos com uma exceção: A última execução ( -pfv) relatou um número diferente de "blocos usados".

• Todas, exceto a última execução, saíram com status 0, a última ( -pfv) com status 1.

Obviamente, a última execução forçada de preening ( -pfv) encontrou (e corrigiu) um erro do sistema de arquivos que as outras execuções não conseguiram encontrar. Infelizmente, ele não dá nenhuma dica sobre esse erro em sua saída.

Agora as minhas perguntas:

• Qual erro foi encontrado e corrigido lá? Foi tão simples quanto uma contagem incorreta de blocos usados?

• O que pode ter causado esse erro? O sistema de arquivos sempre foi desmontado de forma limpa.

• O erro do sistema de arquivos foi finalmente corrigido pelo e2fsck. Mas posso confiar nos dados armazenados nele? Não poderia ser o que causou esse erro no sistema de arquivos em primeiro lugar, também corrompeu os dados no disco? Isso tornaria todos os dados no disco inúteis. Ou isso é paranóico? Por quê?

A última questão distingue entre sistema de arquivos e dados. A este respeito, a resposta de Mikel para " Os sistemas de arquivos de journaling garantem contra corrupção após uma falha de energia? " é de alta relevância. Infelizmente, ele se concentra em sistemas de arquivos com journaling, portanto, não se aplica ao Ext2.

Também a resposta de Gilles para " Como testar a correção do sistema de arquivos feita pelo fsck " é uma boa leitura: De acordo com isso, fsckapenas garante um estado consistente do sistema de arquivos, não necessariamente o mais recente.

Atualização 1

Em seu comentário , Luciano Andress Martini destacou que o comportamento observado e aparentemente intrigante de e2fsckpoderia ter sido causado por erros de RAM na máquina executora. Embora seja um aspecto altamente relevante em situações comparáveis, não parece se aplicar aqui: verifiquei a RAM com "memtest86+" durante a noite e completou 16 passagens sem erros. Além disso, executei e2fsck -nfv, e2fsck -pfv, e executei e2fsck -fvna unidade em teste usando outra máquina (hardware, kernel e versão diferentes de e2fsck). Eles não encontraram nenhum erro do sistema de arquivos e confirmaram os dados do sistema de arquivos que foram relatados pelo últimoe2fsckcomando mostrado acima, em particular o número de blocos usados. Também foi confirmado o número total de blocos (244182016) que foi relatado pelas verificações não forçadas.

Atualização 2

A resposta da telcoM sugere que o comportamento observado de e2fsckpode ser explicado com alterações nas configurações de recursos do sistema de arquivos que ocorrem e2fsckao lidar com sistemas de arquivos muito antigos. Infelizmente esta explicação muito consistente não se aplica aqui: O sistema de arquivos foi realmente criado com uma versão mais recente de mke2fs(1.42.8) que habilitou os recursos ext_attr, resize_inode, dir_index, filetype, sparse_super, large_file. Isso não foi alterado pelas e2fsckexecuções descritas acima.

Atualização 3

Enquanto isso, a unidade USB passou com sucesso em um teste não destrutivo de badblocks de leitura e gravação (levou 3 dias, e sim: o tamanho do bloco especificado ( -b) e o número de blocos ( -c) importam muito) e vários testes SMART offline.

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:

1. Sistema de arquivos limpo.

2. Sistema de arquivos sujo que e2fsck poderia reparar apenas reproduzindo o diário (ext4).

3. Sistema de arquivos mostrando contagens erradas de blocos e inodes livres que podem ser corrigidos pelo e2fsck.

4. Sistema de arquivos contendo inodes órfãos que o e2fsck conectou ao lost+found.

5. 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...