Para complementar as contribuições úteis à minha pergunta, fiz algumas pesquisas por conta própria. Como partes dos resultados também podem ser de interesse geral, eu os resumi nesta auto-resposta.

Observe: Definido pela pergunta, todos os itens a seguir se referem à e2fsckversão 1.41.1 e se concentram em sistemas de arquivos Ext2 sem journal. Mas os termos gerais também se aplicam a algumas versões contemporâneas de ambos, programa e sistema de arquivos.

Lições aprendidas

Vamos começar com as manchetes – as razões abaixo:

• Execute e2fsckna localidade C, por exemplo, assim:

  LC_ALL=C e2fsck ...
  

  Desta forma, você recebe mensagens em inglês que facilitam encontrar ajuda específica na rede.

• Tenha cuidado com a -yopção: Ela responderá automaticamente "sim" a todos os prompts que e2fscksurgirem. E nem sempre se referem a perguntas como "Corrigir este erro?", também há perguntas com a essência "Excluir o arquivo afetado?".

• Isso e2fsckfez algumas alterações no sistema de arquivos e saiu com status 1 (ou 3) não significa que houve erros no sistema de arquivos (corrupções).

• e2fsckalças SIGINT(Ctrl-C). Mas eu evitaria recorrer a ele. (Opinião pessoal.)

Os pontos a seguir se concentram nas informações que você obtém de e2fsck:

• Se você quiser saber quais erros seu sistema de arquivos provavelmente contém e o que e2fsckfazer sobre isso, não use a -popção (preen).

• Uma execução interativa de e2fsck(ou seja, uma sem as opções -n, -p, -a, -y) gera mais mensagens sobre os erros que encontra do que as execuções somente leitura ( -n) ou preening ( -p). -aé apenas um alias para -p. De corridas "sim" ( -y) você obtém basicamente as mesmas informações de uma corrida interativa.

• Apesar de ser bem próxima, a opção -nnão rende uma simulação exata de uma interativa.

• Se você não usar a -fopção, é provável que isso e2fsckforce a verificação por conta própria. Ao fazê-lo, fornece informações adicionais para fundamentar sua decisão. Exemplo:

  ... primary superblock features different from backup, check forced.
  

  Se você não quiser perder isso, comece sem a -fopção, usando-a apenas em uma segunda tentativa se e2fsckrecusar a verificação porque o sistema de arquivos parece estar limpo.

• Não se esqueça de olhar para o código de saída e2fsckpara obter a imagem completa: echo $?.

Tipos de cheques

Interativo: Sem usar as opções -n, -p, -ae -y, e2fsckexecuta uma verificação interativa do sistema de arquivos. Isso significa que ele perguntará a você em cada etapa o que fazer. Isso lhe dá o máximo controle sobre o processo.

Advertência: Dependendo do tamanho e da saúde do sistema de arquivos, isso pode se tornar tedioso rapidamente: imagine que você tenha que confirmar a correção de inode por inode. Essas sessões podem durar horas ou até pior.

Além disso, as coisas podem ficar realmente assustadoras se as perguntas evoluem em uma direção com a qual você não está familiarizado.

Interrompendo: Se uma verificação interativa ficar fora de controle dessa maneira, pode ser bom saber que e2fsckmanipula SIGINT(Ctrl-C).

De fato, há relatos encorajadores, por exemplo , de MadHatter e de Chris . Mas, como já mencionado, eu tentaria evitar tais interrupções.

A razão é simples: a verificação de um sistema de arquivos é um processo complicado, a reparação de corrupções deve ser feita de forma coerente e consistente, e o tratamento de interrupções aumenta ainda mais a complexidade. Como qualquer software complexo, os manipuladores de sinal podem apresentar bugs. Veja por exemplo este post de Andreas Dilger. Então, por que correr o risco? Pode haver boas razões, é claro, mas o peso por si mesmo.

Somente leitura: Se você sabe pouco sobre o status de integridade do sistema de arquivos para verificar, é uma boa ideia usar e2fscka -nopção primeiro. Como veremos abaixo, isso não produz uma simulação exata, mas dá uma boa impressão do que você pode esperar de uma execução interativa.

Preening: e2fsck preeniza o sistema de arquivos se a -popção for usada. A página de manual e2fsck(8) parece promissora:

Esta opção fará com que o e2fsck corrija automaticamente quaisquer problemas do sistema de arquivos que possam ser corrigidos com segurança sem intervenção humana.

Mas isso também significa que ele corrigirá apenas alguns erros do sistema de arquivos. Pode ser visto nas fontes de e2fsck, que uma -pexecução para assim que detecta um erro que não pode ser tratado com segurança, deixando o restante para execuções subsequentes que fazem mais do que apenas preening.

Além disso, como dito acima, -pdará menos informações sobre os erros e suas correções.

Sim: Iniciar e2fsckcom a -yopção produz o mesmo resultado de uma corrida interativa cujas perguntas foram todas respondidas com "sim". As armadilhas dessa abordagem já foram mencionadas acima.

Expect: Como aprendi nesta seção do mini-HOWTO Ext2fs Undeletion of Directory Structures , que se pode responder automaticamente as perguntas do e2fsck com uma granularidade mais fina usando o programa Expect . Lá, o seguinte script wrapper para e2fscké usado:

#!/usr/bin/expect -f
set timeout -1
spawn /sbin/e2fsck -f $argv
expect {
    "Clear<y>? " { send "n" ; exp_continue }
    "<y>? "      { send "y" ; exp_continue }
}

Isso responderá automaticamente a todas as perguntas que usam o prompt "Limpar?" com "n" e todas as outras com "y". Consulte a documentação do Expect para obter detalhes. Veja esta pergunta de Wrothgarr para outro exemplo de uso de expect para e2fsck.

Para esclarecer: eu não recomendo usar esses scripts cegamente. Eles são apenas referenciados aqui para "fins educacionais".

Para aqueles que desejam adotar essa ideia e adaptá-la às suas próprias necessidades: Perto do início do e2fsckarquivo de origem e2fsck/problem.c, o array prompté definido para conter todos os 20 prompts que e2fsckusa. Alguns deles são usados ​​apenas internamente. Mais sobre a inter-relação entre prompts e erros do sistema de arquivos segue abaixo.

Aprendi com as fontes

Diálogo: Para a maioria dos erros que encontra no sistema de arquivos, e2fsckconsulte a função fix_problemque está definida no arquivo e2fsck/problem.c. Esta função executa o diálogo com o usuário conforme apropriado para o erro individual, dependendo das e2fsckopções fornecidas.

Para isso, fix_problemprocure o código de erro atual no array problem_tableque está definido anteriormente no mesmo arquivo e2fsck/problem.c. Essa matriz atribui a cada código de erro um modelo para uma mensagem de erro, um prompt para perguntar ao usuário sobre o problema e uma máscara de bits que controla os detalhes do tratamento do erro. (Para alguns erros, há também uma referência a um código de erro adicional, chamado "depois do código", cujo diálogo foi executado posteriormente. Mas isso não importa para nós.)

Existem dois sinalizadores usados ​​ocasionalmente nesta máscara de bits que são importantes para nossa pergunta: PR_PREEN_NOMSGe PR_NO_NOMSG. Quando definidos, eles suprimem a mensagem de erro para-p execuções e -nexecuções, respectivamente. Portanto, eles definem os erros para os quais você obtém mais informações em uma execução interativa ou em uma -yexecução.

A definição de problem_tableespecifica 292 códigos de erro, dos quais 23 são sinalizados PR_PREEN_NOMSGe apenas 1 é sinalizado PR_NO_NOMSG. Nenhum deles carrega as duas bandeiras,PR_PREEN_NOMSG e PR_NO_NOMSG.

Outro sinalizador interessante é PR_PREEN_OK: Erros que carregam esse sinalizador podem ser tratados com segurança por preen ( -pexecuções). Existem outros erros que preen cuida, veja "casos especiais" abaixo, mas estes são a maioria deles. 82 erros na matrizproblem_table são sinalizados PR_PREEN_OK.

Iniciar: Para uma compilação Linux dee2fsck versão 1.41.1, a execução começa com a função mainno arquivo e2fsck/unix.c.

Passo 0: Após a inicialização e verificação do diário, o que não é relevante para esta questão, algumas verificações e limpezas fundamentais são realizadas no sistema de arquivos. Isso também é endereçado como passo 0. A maior parte disso é feita pela funçãocheck_super_block no arquivo fonte e2fsck/super.c.

Apesar do nome, esta função não apenas cuida do superbloco, mas também verifica os descritores do grupo de blocos. Ao fazer isso, ele soma as contagens de blocos e inodes livres por grupo de blocos e compara o resultado com os valores globais no superbloco.

O que acontece se esses valores não coincidirem depende das e2fsckopções da linha de comando: Para uma -nexecução, o sistema de arquivos é considerado inválido e uma verificação completa é forçada posteriormente. Em todos os outros casos (-p , -y, execução interativa), as contagens totais no superbloco são atualizadas silenciosamente, não forçando uma verificação completa. De fato, se as últimas execuções não encontrarem erros adicionais, eles relatarão o sistema de arquivos limpo apesar dessa correção silenciosa.

A funçãocheck_super_block também faz outras coisas, como verificar o inode de redimensionamento, limpar inodes órfãos, fazer algumas tarefas domésticas no journal, mas isso não parece ser importante para nossa pergunta.

Ignorar: Se uma verificação completa do sistema de arquivos ainda não for forçada pela -fopção, e2fsckdecido forçar uma verificação completa por si só. Critérios amplamente conhecidos para isso são o número de montagens desde a última verificação, a ausência de uma desmontagem limpa, erros de arquivos já conhecidos, etc.

Mas há outro critério que aplicou, mas apenas se a -nopção não foi utilizada: Diferenças entre o superbloco e seus backups em relação às seguintes quantidades:

• Recursos do sistema de arquivos habilitados, além de large_file, dir_nlink, extent,

• contagem total de blocos,

• contagem total de inodes,

• UUID do sistema de arquivos.

A razão para excluir alguns dos recursos do sistema de arquivos desse critério é que o kernel pode definir esses recursos rapidamente, conforme necessário, e faz isso apenas no superbloco, mas não nos backups. Para os recursos de exceção, essas diferenças não são consideradas importantes o suficiente para forçar uma verificação completa. Em contrapartida, oext_attr recurso também pode ser definido dinamicamente pelo kernel, mas neste caso uma atualização nos backups é crucial, razão pela qual esse recurso não é exceção.

Se e2fsckdecidir forçar uma verificação completa por conta própria, imprime uma mensagem para justificar o inconveniente. Se isso for devido a uma das diferenças nomeadas entre o superbloco e seus backups, a mensagem será:

... primary superblock features different from backup, check forced.

Observe que o termo "recursos" na mensagem tem um significado mais amplo do que "recursos do sistema de arquivos" puro: Ele também abrange a contagem total de blocos, por exemplo. Veja também este post de Eric Sandeen e este de Theodore Tso a esse respeito.

De qualquer forma, você nunca verá esta mensagem em uma -nexecução, pois, como dito acima, os backups de superbloco não são levados em consideração neste caso.

Se uma verificação completa não for forçada, nem por -fnem por e2fsck, a verificação é ignorada ( e2fsckdicção). Nesse caso, e2fsckrelata o sistema de arquivos como saídas de final limpo com status 0. Isso também é verdade, se houver alguns reparos na passagem 0, como uma correção da contagem total de blocos livres no superblock, por exemplo.

Passes 1 a 6: Em uma verificação completa, e2fsckfaz pelo menos cinco passagens completas pelo sistema de arquivos, cada uma com um foco diferente. Estes são executados pelas funções e2fsck_pass1dee2fsck_pass5 arquivos fonte e2fsck/pass1.c a e2fsck/pass5.c, respectivamente.

Pode haver passagens adicionais que complementam a passagem 1, se necessário, para lidar com corrupções especiais do sistema de arquivos. Estes são rotulados como pass 1B a pass 1D, e as funções correspondentes pass1ba pass1dsão todas definidas em e2fsck/pass1b.c.

O rehashing de diretórios, que faz parte do passo 3 e que é realizado pela função e2fsck_rehash_directoriesno arquivo e2fsck/rehash.c, é considerado como passo 3A.

Além disso, há um código de erro PR_6_RECREATE_JOURNALque é usado quando o diário precisa ser recriado. Obviamente, isso é considerado um passe separado: passe 6. É realizado em função main.

A maioria dos erros definidos na matriz problem_tablesão verificados nessas passagens. Para cada erro pode-se ver o número do passe ao qual está sujeito a partir do nome do seu código de erro: O número segue o primeiro sublinhado no nome do código. Assim, por exemplo, o erro PR_1_TOO_MANY_BAD_BLOCKSé tratado na passagem 1 e é resolvido na PR_3A_OPTIMIZE_DIR_ERRpassagem 3A.

É de particular interesse para esta questão que as contagens totais de blocos e inodes livres sejam verificados novamente no início da passagem 5: Exceto na verificação rápida na passagem 0, onde apenas os valores correspondentes dos descritores de grupo de blocos foram Resumindo, desta vez as contagens são calculadas com base nos dados e2fsckcoletados minuciosamente no decorrer de suas passagens pelo sistema de arquivos completo onde os papéis de cada bloco e cada inode foram analisados ​​individualmente. Isso é feito pelas funções check_block_bitmapse check_inode_bitmapsque são definidas no arquivo e2fsck/pass5.c.

As diferenças dos valores resultantes em comparação com os do superbloco são tratadas como erros PR_5_FREE_BLOCK_COUNTe PR_5_FREE_INODE_COUNT. A propósito, esses erros são sinalizados PR_PREEN_NOMSG, portanto, não são relatados explicitamente ao preening ( -p).

Casos especiais: Existem correções que e2fsckpodem ser executadas no sistema de arquivos sem chamar fix_problemou consultar o catálogo de erros em problem_table. Essas correções são realizadas apenas na ausência da -nopção e sem aviso na saída, mas talvez no status de saída. Encontrei três desses nas fontes:

• A correção do total de blocos livres e inodes livres conta no superbloco durante a passagem 0 (sem -n). Isso já foi discutido acima.

• Durante a passagem 1, o último campo órfão no superbloco é apagado silenciosamente se definido (sem -n).

• Se o valor da contagem de links armazenado no inode de um diretório indexado indicar que excedeu anteriormente seu limite superior enquanto a contagem verdadeira atual for inferior a esse limite, o valor no inode será corrigido silenciosamente na passagem 4 (sem -n).

Status de saída: Para uma verificação completa (forçada), o código de saída é determinado pela função mainapós a conclusão da verificação passar no curso da análise do resultado deste último: Se a verificação não foi cancelada no meio do caminho, o status de saída será zero se e somente se não houver alterações no sistema de arquivos até agora.

Toque final: Se a verificação não foi cancelada no meio do caminho, a função mainredefine a contagem de montagem no superbloco e atualiza o timestamp lá, para que e2fsckpossa dizer em execuções futuras quando a próxima verificação completa deve ser forçada. Isso é feito durante a limpeza após a determinação do status de saída, portanto, essa alteração não tem influência no status.

Manipulador de sinal: Na função PRSque é chamada por main, ambos definidos em e2fsck/unix.c, e2fsckgera manipuladores de sinal para SIGINT, SIGTERM, SIGUSR1e SIGUSR2. Os dois últimos podem ser usados ​​para alternar informações de progresso conforme explicado na página de manual e2fsck(8) .

Os primeiros são obviamente tratados para permitir interrupções seguras e encerramento de arquivos e2fsck.

Aprendi com os testes

Tentando reproduzir o comportamento do e2fsckque é mostrado na pergunta, montei um sistema de arquivos Ext2 de teste, preenchi-o com arquivos fictícios de até 10% de sua capacidade e usei um editor hexadecimal para introduzir alguns erros artificiais. Em seguida, esse sistema de arquivos foi verificado com os mesmos comandos da pergunta para comparar as saídas e os status de saída do e2fsck.

Na última execução da pergunta, a contagem de blocos usados ​​mudou. e2fsckcalcula esse valor de maneira óbvia a partir da contagem de blocos livres e da contagem total de blocos. Por isso escolhi essas quantidades como objeto dos erros artificiais.

Contagem de blocos livres em superblock: A estrutura de dados do superblock é descrita em detalhes neste documento . (Uma versão contemporânea deste documento, que descreve o sistema de arquivos Ext4, pode ser encontrada aqui .) Com base nisso, usei o editor hexadecimal para reduzir a contagem de blocos livres no superblock em 2.

Este erro artificial foi detectado por e2fsck -nv(sem -f) que reclamou em voz alta, forçou uma verificação completa e saiu com o status de saída 4.

Além disso, uma execução somente leitura forçada ( -nfv) relatou esse erro e saiu com o status 4.

A subsequent -pv run (without -f) found the filesystem clean and did not give any notice about an error. However, it corrected the error and output the number of used blocks based on the corrected values, yet exited with status 0.

After introducing the same error again, a forced preen run (-pfv) was also not reporting the error, but corrected it exiting with status 1.

This behavior of e2fsck can be well understood from what was learned from the sources, above.

This means, that it must have been a different error that led to the check results described in the question: Otherwise, it would have been reported by the read-only runs and corrected by the first (unforced) preen, so that the last run would have found a clean filesystem.

Total blocks count in superblock: Using a hex editor, I reduced the total blocks count in the superblock by 2.

This was not detected by an -nv run (without -f), which reported the filesystem as clean and exited with status 0.

Forcing this check (-nfv), several errors were found—wrong ones in a sense: e2fsck took the manipulated total block count seriously, and found in consequence wrong free blocks counts in the last block group and in the superblock. In addition, it found that the padding at the end of the block bitmap was not set. The exit status was 4.

A subsequent preening (-pv, without -f) forced a full check because of differences between the superblock and it backups. In the course, it corrected all the "wrong" errors that were previously found by the forced read-only run. However, it only reported the ("wrong") error in the bitmap padding, not giving any notice on the free blocks counts. It finally exited with status 1.

After introducing the same error again, a forced preening (-pfv) did essentially the same, except that is did not inform about the difference between the superblock and it backups that was previously given as the reason for the forced check.

Also this behavior of e2fsck can be understood from the discussion of the sources above. It was, however, different from what is described in the question. So it must have been another error there.

Free blocks count in backup: The block numbers of the superblock backups can be found with

LC_ALL=C dumpe2fs <device> | grep -i superblock

However, the free blocks count in the first superblock backup is totally ignored by e2fsck. In fact, it seems that this value differs from that in the primary superblock even in a truly clean filesystem. And indeed, if one thinks about it, it would be a huge overhead to keep this value constantly synchronized throughout all the backups. So I assume, that there it has no meaning at all.

Total blocks count in backup: Using the hex editor again, I reduced the total blocks count in the first superblock backup by 2.

This artificial error was totally ignored by e2fsck in read-only mode: -nv and -nfv.

A preen run (-pv, without -f) forced a full check giving the message

... primary superblock features different from backup, check forced.

In the course, it corrected the error without further related messages and exited with status 1.

After introducing the same error again, a forced preening (-pfv) did the same, yet without any notice on the error.

Again, this behavior can be well understood from the above discussion of the sources; and it is different from what was observed in the question.

In addition, the unforced e2fsck runs described in the question and the subsequently performed checks described in update 1 reported the same total blocks count. So this value was not changed in any of these runs and hence could not be the subject of the wanted error.

Does this yield an answer to the question?

In short: No.

For each individual run that is described in the question, I found possible errors that lead to the observed behavior of e2fsck. But I did not find a single error that causes that behavior of all runs in a sequence.

All errors in problem_table are ruled out, because they would have been reported either by the -nfv run or by the -pfv run or by both.

Considering the "special cases" above, a wrong free blocks or free inodes count would have been reported by the read-only runs. This was not the case.

The other "special cases" would not have led to a change of the used blocks count that was observed in the last run.

But after all, e2fsck is a complex piece of software, so it is most likely that I have overseen something.

Result

Facing these findings, it seems that the following workflow can be used to safely check an unmounted Ext2 filesystem with unknown health status while avoiding unpleasant surprises in the interactive part and getting a maximum of information from e2fsck.

This assumes a healthy hardware! If in particular the drive is not trustworthy in this respect, unconditionally begin with step 3 (back up the filesystem), proceeding with the remaining steps in the stated order:

1. Do an -nv run:

   LC_ALL=C e2fsck -nv <device>; echo $?
   

2. If e2fsck skips the full check reporting the filesystem as clean, force the check repeating step 1 with -f.

3. Depending on the corruptions found, back up the filesystem with dd. This allows to restore the current state if things get screwed up in the next steps.

4. If it seems feasible according to the results of the read-only runs, do an interactive check with

   LC_ALL=C e2fsck -v <device>; echo $?
   

   forcing it with -f if needed to get a full check.

5. What to do if an interactive run is not feasible depends on the findings so far.

Appendix: Inspecting filesystem features

dumpe2fs: The program dumpe2fs can be used to find out which features are enabled in a filesystem.

This does also work for unknown features. In this case, dumpe2fs uses generic feature names that uniquely identify the corresponding bits in the features fields of the superblock. For example FEATURE_R16 corresponds to bit 16 (counting from 0) in the read-only compatible features field of the superblock. Similarly, FEATURE_I31 corresponds to the most significant bit of the incompatible features field.

If the feature compression is set, dumpe2fs has to be started with the -f option.

However, version 1.41.1 of this program seems to be a little bit buggy, as it crashes with a floating point exception on some combinations of enabled and disabled features, e.g. for enabled 64bit and disabled journal_dev.

debugfs: The command show_super_stats of debugfs yields a similar output to that of dumpe2fs with regard to the enabled filesystem features. Also this program informs about unknown features.

The version 1.41.1 also of this program seems to be somehow buggy: The command show_super_stats crashes with a segmentation fault if compression or journal_dev is enabled. Like dumpe2fs, the whole program debugfs crushes with a floating point exception if the feature 64bit is enabled while journal_dev is disabled.

tune2fs: If only known filesystem features are enabled, they can be listed as part of the output of tune2fs -l. However, this program refuses to start if any unknown filesystem feature is enabled, even if the -f option is used.

Você mencionou que este sistema de arquivos é usado com máquinas muito antigas. Se o sistema de arquivos foi criado originalmente com uma mke2fsferramenta muito antiga que não suporta o resize_inoderecurso de sistema de arquivos para reservar algum espaço de metadados para extensão on-line do sistema de arquivos, pode ser possível que sua segunda execução com a e2fsckversão 1.14.1 tenha apenas adicionado automaticamente .

Se bem me lembro, a alocação é completamente benigna para sistemas antigos que não a entendem, mas garante que alguma estrutura de metadados crítica possa se estender sem uma grande reorganização, se o sistema de arquivos for estendido.

Você pode confirmar isso executando tune2fs -lno sistema de arquivos de sua unidade USB e em um dos sistemas de arquivos ext2 de suas máquinas antigas e comparando os resultados. Você pode fazer isso mesmo se os sistemas de arquivos estiverem montados. Se a saída da sua unidade USB incluir a palavra-chave resize_inodena Filesystem features:linha e os sistemas de arquivos ext2 locais em suas máquinas antigas não tiverem essa palavra-chave, a explicação mais provável é que você e2fsck -pfvacabou de aproveitar a oportunidade para fazer essa pequena alocação na esperança que pode ajudar a evitar tempo de inatividade no futuro.