Falta de memória executando fsck em sistemas de arquivos grandes

Eu cuido de uma antiga caixa Linux Debian (executando etch) com apenas 512 MB de RAM, mas muito armazenamento externo conectado. Um sistema de arquivos ext3 tem 2,7 TB de tamanho e o fsck não pode verificá-lo, porque fica sem memória, com um erro como este:

   Erro ao alocar a matriz de blocos de diretório: Falha na alocação de memória
   e2fsck: abortado

Adicionei uma partição de swap de 4 GB e ela ainda não está completa, mas esse é um kernel de 32 bits, então não espero que adicionar mais ajude.

Além de inicializar em um kernel de 64 bits, existem outras maneiras de fazer o fsck concluir sua verificação?

Um kernel de 64 bits e grandes quantidades de RAM permitirá que o fsck termine de maneira rápida e agradável. Como alternativa, agora existe uma opção no e2fsck que diz para armazenar todos os seus resultados intermediários em um diretório em vez de na RAM, o que ajuda imensamente. Crie /etc/e2fsck.confcom o seguinte conteúdo:

[scratch_files]
directory = /var/cache/e2fsck

(E, obviamente, verifique se o diretório existe e se está em uma partição com alguns GB de espaço livre). O e2fsck executará SLLOOOOWWWWWWW, mas pelo menos será concluído.

Obviamente, isso não funcionará com o FS raiz, mas se você tiver swap, estará montando o FS raiz de qualquer maneira.

Acabei tentando o que sugeria; Aqui estão mais alguns detalhes que podem ser úteis se, como eu, você não viu essa nova funcionalidade no e2fsck antes.

A opção de configuração "scratch_files" do e2fsck ficou disponível em algum momento no período da versão 1.40.x. (No nosso caso, tivemos que atualizar para a distribuição Debian mais recente para obter essa funcionalidade.)

Assim como a opção "directory = / var / cache / e2fsk" sugerida, existem outras opções de configuração para ajustar como o armazenamento de arquivos de rascunho é usado. Eu usei "dirinfo = false", já que o sistema de arquivos tinha um grande número de arquivos, mas não um número tão grande de diretórios. Se a situação fosse revertida, a opção "icount" seria apropriada. Essas opções foram todas documentadas na página de manual do e2fsck.conf.

Aliás, Ted T'so escreveu sobre essas opções neste tópico .

Eu descobri que o e2fsck estava rodando extremamente devagar, muito mais do que o previsto por Ted. Ele estava rodando com 99,9% de utilização da CPU na maioria das vezes (em um processador antigo extremamente lento), o que sugere que o armazenamento dessas estruturas de dados no disco em vez da memória não era a principal causa da desaceleração. Pode ser que algo mais sobre o que foi armazenado no sistema de arquivos tenha tornado o e2fsck particularmente lento. No final, abandonei a verificação do sistema de arquivos por enquanto; o sistema de arquivos estava sujeito a uma verificação, mas não tinha erros (tanto quanto eu sei), então vou providenciá-lo em um momento mais conveniente, quando pudermos ter uma interrupção de uma semana.