Sem memória executando fsck em sistemas de arquivos grandes

Question

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

   Error allocating directory block array: Memory allocation failed
   e2fsck: aborted

Eu adicionei uma partição swap de 4 GB e ela ainda não está completa, mas este é um kernel de 32 bits, então eu não espero adicionar mais alguma ajuda.

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

    

Answer 1

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

[scratch_files]
directory = /var/cache/e2fsck

(E, obviamente, certifique-se de que o diretório exista e esteja em uma partição com alguns GB de espaço livre). O e2fsck executará o SLLOOOOWWWWWWWW, mas pelo menos ele será concluído.

Claro, isso não funcionará com o FS raiz, mas se você tiver uma troca, você já montou o FS raiz de qualquer maneira.

    

Answer 2

Acabei tentando o que womble sugeriu; 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" para o e2fsck tornou-se disponível no período da versão 1.40.x. (No nosso caso, nós tivemos que atualizar para a mais recente distribuição Debian para obter essa funcionalidade.)

Assim como a opção "directory = / var / cache / e2fsk" que foi sugerida, existem outras opções de configuração para ajustar como o armazenamento dos arquivos de rascunho é usado. Eu usei "dirinfo = false", uma vez 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 invertida, a opção "icount" seria apropriada. Estas opções foram todas documentadas na página man do e2fsck.conf.

BTW, Ted T'so escreveu sobre essas opções em este tópico .

Descobri que o e2fsck estava rodando de forma extremamente lenta, muito mais do que o previsto por Ted. Ele estava rodando a 99,9% da utilização da CPU na maioria das vezes (em um processador antigo extremamente lento), o que sugere que armazenar essas estruturas de dados no disco em vez de 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 tornou o e2fsck particularmente lento. No final, abandonei a verificação do sistema de arquivos por enquanto; o sistema de arquivos estava pronto para uma checagem, mas não tinha erros (tanto quanto eu sei), então eu vou providenciar para checá-lo em um momento mais conveniente, quando pudermos ter uma interrupção de uma semana. / p>