Maneira correta de lidar com sistemas de arquivos XFS corrompidos

13

Eu recentemente tive um sistema de arquivos XFS corrompido devido a um powerfail. (Sistema CentOS 7). O sistema não inicializaria corretamente.

Eu inicializei a partir de um CD de recuperação e tentei xfs_repair , ele me disse para montar a partição para lidar com o log.

Eu montei a partição e fiz um ls para verificar se sim, parece estar lá. Desmontei a partição e tentei xfs_repair novamente e recebi a mesma mensagem.

O que devo fazer nesta situação? Há algo de errado com o meu CD de resgate (System Rescue CD, versão 4.7.1)? Existe algum outro procedimento que eu deveria ter usado?

Acabei de simplesmente restaurar o sistema a partir de backups (foi rápido e fácil neste caso), mas gostaria de saber o que fazer no futuro.

    
por Michael Kohne 17.05.2016 / 17:32

2 respostas

14

Se você está tentando executar xfs_repair , recebendo a mensagem de erro que sugere montar o sistema de arquivos para reproduzir o log e, após a montagem, continuar recebendo a mesma mensagem de erro, talvez seja necessário executar um reparo forçado (usando o -L flag com xfs_repair ). Esta opção deve ser o último recurso.

Por exemplo, vou usar um caso em que tive uma partição raiz corrompida na minha instalação do CentOS 7. Ao tentar montar a partição, recebi continuamente a mensagem de erro abaixo:

mount: mount /dev/mapper/centos-root on /mnt/centos-root failed: Structure needs cleaning

Infelizmente, forçar um reparo envolveria zerar (destruir) o log antes de tentar um reparo. Ao usar este método, existe um potencial de acabar com dados mais corruptos do que o inicialmente previsto; no entanto, podemos usar as ferramentas xfs apropriadas para ver que tipo de dano pode ser causado antes de fazer qualquer alteração permanente.

Usando xfs_metadump e xfs_mdrestore , você pode criar uma imagem de metadados da partição afetada e executar o reparo forçado na imagem em vez da própria partição. Os benefícios disso são a capacidade de ver o dano que vem com um reparo forçado antes de executá-lo na partição.

Para fazer isso, você precisará de um disco rígido USB ou externo de tamanho decente. Comece montando o drive USB - meu USB estava localizado em /dev/sdb1 , o seu pode ser nomeado de forma diferente.

mkdir -p /mnt/usb
mount /dev/sdb1 /mnt/usb

Uma vez montado, execute xfs_metadump para criar uma cópia dos metadados da partição para o USB - novamente, sua partição afetada pode ser diferente. Nesse caso, eu tinha uma partição raiz corrompida, localizada em /dev/mapper/centos-root :

xfs_metadump /dev/mapper/centos-root /mnt/usb/centos-root.metadump

Em seguida, você desejará restaurar os metadados em uma imagem para que possamos reparar e medir o dano.

xfs_mdrestore /mnt/usb/centos-root.metadump /mnt/usb/centos-root.img

Descobri que no modo de recuperação xfs_mdrestore não está disponível e, em vez disso, você precisará estar no modo de recuperação de um CD do CentOS ao vivo.

Por fim, podemos executar o reparo na imagem:

xfs_repair -L /mnt/usb/centos-root.img

Após o reparo ser concluído e você avaliar a saída e possíveis danos, você poderá determinar se deseja executar o reparo contra a partição.

Para executar o reparo contra a partição, basta executar:

xfs_repair -L /dev/mapper/centos-root

Não se esqueça de verificar também as outras partições por corrupção. Após os reparos, reinicie o sistema e você será capaz de inicializar com sucesso.

Lembre-se de que o sinalizador -L deve ser usado como último recurso, onde não há outras opções possíveis para reparo.

Descobri que esses artigos on-line ajudaram:

por 18.05.2016 / 05:54
0

Eu tive esse erro whe centos 7 parada ruim dentro de uma máquina virtual kvm:

Corrupção de metadados

detectada no xfs ...

quando eu uso o log com “journalctl -xe”, descobri uma montagem de erro:

/ dev / mapper / root / sysroot

Eu resolvo usando:

xfs_repair / dev / mapper / root

Em seguida, o sistema completa as sete fases e, em seguida, reinicializa usando

./ shutdown

E então a máquina virtual centos 7 funciona bem…

Atenciosamente

Nota: talvez você / dev / mapper / root tenha outro nome, por favor, assista ao seu registro de erros com journalctl -xe para encontrar o nome da sua unidade montada incorretamente

    
por 24.09.2017 / 18:43