e2fsck - falta de memória apesar do [scratch_files] definido em /etc/e2fsck.conf

Question

Gostaria de reparar um sistema de arquivos ext2 em uma unidade externa de cartão SD de 16GB.

Quando eu emito o seguinte comando:

e2fsck -y /dev/xxx

meu sistema fica sem memória (Fedora 17 x64 8GB RAM, 8GB Swap).

Como sugerido em outro lugar , eu adicionado:

[scratch_files]
directory = /var/cache/e2fsck    # (this directory exists and is writable to all)

para:

/etc/e2fsck.conf

Infelizmente, essa correção parece não funcionar. O e2fsck usa o diretório / var / cache / e2fsck, mas ainda fica sem memória.

Quando executo o comando interativamente, ele é interrompido no seguinte prompt:

Inode 758 has an invalid extent
    (logical block 0, invalid physical block 140737488469058, len 1)
Clear<y>? yes
Inode 758, i_blocks is 8, should be 0.  Fix<y>? 

Responder sim ou não a esse prompt tem o mesmo resultado: a RAM usada pelo e2fsck salta repentinamente para 8 GB + e meu sistema congela.

EDIT: Dentro do VirtualBox

Eu tentei fsck dentro do VirtualBox, com um enorme espaço de swap de 40Gb. Fsck usou todos os 4GB de RAM e cerca de 30 GB de swap, então ele morreu com a seguinte mensagem de erro:

Error storing directory block information (inode=759, block=0, num=295645313): 
Memory allocation failed

    

Answer 1

Um salto de memória soa como um erro e2fsck . Se esse for o caso, o problema pode ser resolvido ao se preocupar com esse inode manualmente (com debugfs ; não estou familiarizado o suficiente para explicar como fazer isso).

Se não é um bug e e2fsck precisa de mais memória, então há uma "solução" que não requer adição de RAM, mas certamente "redefinir o desempenho" ... O problema é que o e2fsck não usa memória swap como equivalente. Pelo menos essa era a situação em um caso semelhante. Seu espaço de troca é preenchido completamente antes de e2fsck falhar? Provavelmente não.

Você pode enganar e2fsck ao aceitar swap como RAM real: você pode inicializar um segundo Linux em uma VM e exportar o dispositivo de bloco a ser verificado para a VM. Você configura a VM com mais memória do que fisicamente disponível. e2fsck na VM verá mais RAM. Claro, isso não torna o uso de scratch_files desnecessário.

Eu tive problemas ao iniciar uma VM com mais alocação de memória do que a RAM física (!) disponível, mas de acordo com as documentações do Fedora , isso deveria ser possível (talvez isso não fosse nem mesmo um problema do KVM / QEMU, mas algumas coisas extravagantes do kernel).

    

Answer 2

Eu resolvi isso criando um swapfile em um drive externo .. Eu criei um swap de 12gb para suprir a swap existente .. que permitia ao fsck completar sem nenhum problema em um servidor de arquivos de 12tb .. definitivamente retardava o desempenho do a verificação do disco, no entanto.

Este site documenta as etapas: link