Execute e2fsck -y para dizer sim a todas as perguntas automaticamente, em vez de precisar dizer manualmente sim um milhão de vezes.
Recentemente, uma instalação do CentOS 6.5 do LVM'd foi acidentalmente desligada a frio. No bootup, ele diz que a partição home precisa de fscking:
/dev/mapper/vg_myserver-lv_home: Block bitmap for group 3072 is not in group. (block 3335668205)
/dev/mapper/vg_myserver-lv_home: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
... mas eu acho que a partição root está OK, já que me dá um shell lá. Então, corremos e2fsck -b 32768 /dev/mapper/vg_myserver/lv_home e depois de dizer Sim para várias correções, no Passo 5 ele imprime números infinitos na tela, muito rápido. De vez em quando ele os imprimirá em colunas limpas, e se estes forem números de bloco, depois de algumas horas ainda não estamos nem perto dos primeiros 2% que estão sendo feitos de nosso 1,2 TB LV.
Eu li que você pode usar cleap_mmp com tune2fs , mas ao tentar isso, ele não aceita cleap_mmp nem lista entre opções válidas.
A minha pergunta é: como é que todos lidam com um ext4 corrupto sem semanas de inatividade? Todo mundo tem esse dilema, ou semanas de inatividade versus reconstrução do seu servidor / dados perdidos? Em caso afirmativo, por que alguém usa ou recomenda o uso do ext4? Existe algum truque que eu estou perdendo que me permitiria atingir o bloco / grupo específico que está reclamando, para que possamos continuar com isso e montar o fs de novo?
A solução para o problema de um disco com falha ou problemático é restaurar a partir de backups. Se for um problema de hardware, substitua o disco primeiro.
A tentativa de reconstruir um sistema de arquivos quebrado é uma operação extremamente demorada que raramente resulta em bons resultados.
Na verdade, fsck terminou hoje. Reiniciado e tudo funcionou muito bem!
Dê uma olhada no recurso ext4 uninit_bg ( man tune2fs ). Usar isso pode reduzir e2fsck time:
dumpe2fs -h /dev/sdx | grep "^Filesystem features:"