INCONSITÊNCIA INESPERADA executar fsck manualmente redhat

Question

Eu reiniciei meu servidor erroneamente antes de concluir um redimensionamento do sistema de arquivos. Aqui está o comando que foi executado com sucesso antes de reiniciar:

lvresize -L -400GB /dev/mapper/vg_yavin-lv_home

Na inicialização, recebo esse erro

/dev/mapper/vg_yavin-lv_home: UNEXPECTED INCONSITENCY run fsck MANUALLY

Quando tento fsck -y /dev/mapper/vg_yavin-lv_home , obtenho isto:

e2fsck 1.41.12 (17-May-2010)
Error reading block 63471616 (Invalid argument).  Ignore error? yes

Force rewrite? yes

Error writing block 63471616 (Invalid argument).  Ignore error? yes

Superblock has an invalid journal (inode 8).
Clear? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Superblock has_journal flag is clear, but a journal inode is present.
Clear? yes

The filesystem size (according to the superblock) is 127047680 blocks
The physical size of the device is 22190080 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

Error writing block 63471616 (Invalid argument).  Ignore error? yes

Se eu comentar esse sistema de arquivos no fstab, posso inicializar, mas existe uma maneira de recuperar esse sistema de arquivos?

    

Answer 1

ProTip: quando diz

Run fsck manually

O que isso realmente significa é

Run fsck in interactive mode and evaluate the output to decide what you want to do

NÃO "Use cegamente -y porque é o que todo mundo parece fazer e não pode machucar nada". fsck -y pode ser destrutivo. É por isso que não é o comportamento padrão.

Parece que você tem uma corrupção muito séria (o "bloco de leitura de erro 63471616" faz com que eu pense em possíveis danos no disco físico) e, francamente, fsck pode ter piorado as coisas.

Se você tiver backups, agora seria a hora de usá-los. Se não, e os dados são importantes, eu imagino a partição (você pode tentar executar ferramentas de recuperação como debugfs na imagem).

Em última análise, você provavelmente deseja apenas newfs (ou mkextfs , qualquer que seja o equivalente a Linux) a partição - se você tem certeza que isso não é devido a uma falha no disco físico .

    

Answer 2

Observe que o método a seguir não recuperará seus dados. Pode restaurar os metadados do seu grupo de volumes. Você sempre pode ler a documentação do lvm no guia do produto. Tem uma explicação detalhada dos comandos que vou contar.

Comente o fs no fstab e depois inicialize. Agora, encontre o VG no qual você executou o lvresize. Eu acho que é vg_yavin.

Execute isto

vgcfgrestore --list <VG-NAME>

Isso fornecerá uma lista dos pontos de interrupção no VG antes que qualquer operação significativa seja realizada. Você tem que descobrir o arquivo correspondente à sua operação de lvresize. Teoricamente, deve ser o mais recente.

Nesse arquivo executado

 vgcfgrestore --file /etc/lvm/archive/<file-name> <VG-NAME>

Isso restaurará os metadados do VG antes do lvresize.

Inicialize normalmente e veja se funciona.

Na mensagem de erro, o superbloco padrão do fs está corrompido. Tente inicializar com os superblocos de backup que devem estar presentes se você tiver uma saída de trabalho dumpe2fs. Então

e2fsck -b <backup_sb> <disk-name>

Mas dependendo da corrupção e do quão ruim o fs é agora, é tudo uma probabilidade.

    

Answer 3

Dada a sua última pergunta, você provavelmente só precisará executar resize2fs conforme as instruções. Atualmente, seu volume diminuiu, mas o sistema de arquivos não diminuiu para corresponder a ele. Faça isso, execute fsck novamente e você ficará bem.

    

Answer 4

Veja o que acabei fazendo e parece estar funcionando bem agora

1.Comente a linha em / etc / fstab

#/dev/mapper/vg_yavin-lv_home /home                   ext4    defaults        1 2

2. Reinicie

3.Recriar / Remontar

mkfs -c /dev/mapper/vg_yavin-lv_home
fsck /dev/mapper/vg_yavin-lv_home
mount /dev/mapper/vg_yavin-lv_home /home

4.Uncomment line in / etc / fstab

/dev/mapper/vg_yavin-lv_home /home                   ext4    defaults        1 2

5.Reiniciar

Claro, perdemos todos os nossos arquivos, mas não temos nada para nos preocupar.