Como verificar e reparar o sistema de arquivos XFS no Linux

O comando xfs_repair repara sistemas de arquivos XFS corrompidos ou danificados. É altamente escalável, de alto desempenho e foi projetado para reparar efetivamente até mesmo sistemas de arquivos muito grandes com muitos inodes.

Ao contrário de outros sistemas de arquivos Linux, xfs_repair não é executado no momento da inicialização, mesmo que o sistema de arquivos XFS não tenha sido desmontado corretamente.

É um sistema de arquivos com journaling de 64 bits que suporta arquivos muito grandes (8 EB) e sistemas de arquivos (16 EB) em um único host. Saiba que o XFS é o sistema de arquivos padrão para Red Hat Enterprise Linux, mas também pode ser ajustado em qualquer distribuição Linux.

O sistema de arquivos a ser reparado não deve ser montado antes de executar xfs_repair, caso contrário, o sistema de arquivos resultante pode ser corrompido.

Este mesmo procedimento pode ser usado para outras partições do sistema que não podem ser desmontadas enquanto o sistema está em execução.

Neste guia, mostraremos como usar o comando ‘xfs_repair’ no Linux para reparar um sistema de arquivos XFS corrompido.

A Sintaxe do comando para reparar o XFS é:

xfs_repair [opção] [unidade ou partição]

Reparando um sistema de arquivos XFS

Você pode reparar um sistema de arquivos XFS corrompido não raiz em um sistema Linux em execução. Pode ser necessário inicializar o sistema com o Modo de Resgate ou o Modo de Emergência para reparar o sistema de arquivos quando ele não puder ser desmontado enquanto o sistema estiver em execução.

Passo 1: Desmonte o sistema de arquivos que você deseja executar o fsck.

Terminal
sudo umount /data

Passo 2: Execute xfs_repair com ‘-n’a opção de executar uma simulação. Observe que a ferramenta ‘xfs_check’ foi preterida em favor de ‘xfs_repair -n’.

Terminal
sudo xfs_repair -n /dev/sdb1
Saída do Terminal
Phase 1 - find and verify superblock…
Phase 2 - using internal log
- zero log…
- scan filesystem freespace and inode maps…
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x27fe08/0x1000
btree block 1/1 is suspect, error -74
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x77fa08/0x1000
btree block 3/1 is suspect, error -74
invalid start block 4294967285 in record 0 of bno btree block 3/1
Metadata CRC error detected at 0x564a76dad251, xfs_allocbt block 0x4ffc08/0x1000
btree block 2/1 is suspect, error -74
.
.
free inode 190 contains errors, would correct
bad CRC for inode 191, would rewrite
UUID mismatch on inode 191
would have cleared inode 191
- agno = 1
- agno = 2
- agno = 3
would rebuild corrupt refcount btrees.
No modify flag set, skipping phase 5
Inode allocation btrees are too corrupted, skipping phases 6 and 7
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Would format log to cycle 2161922.
No modify flag set, skipping filesystem flush and exiting.

Passo 3: Execute xfs_repair para reparar o sistema de arquivos:

Terminal
sudo xfs_repair /dev/sdb1
Saída do Terminal
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x4ffc08/0x1000 btree block 2/1 is suspect, error -74
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x8/0x1000 btree block 0/1 is suspect, error -74
bad magic # 0xb1bdccbd in btbno block 0/1
Metadata CRC error detected at 0x55ff18867251, xfs_allocbt block 0x77fa08/0x1000 btree block 3/1 is suspect, error -74
.
.
clearing reflink flag on inode 133
Phase 5 - rebuild AG headers and trees... - reset superblock...
Phase 6 - check inode connectivity...
reinitializing root directory
reinitializing realtime bitmap inode
reinitializing realtime summary inode
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
disconnected inode 133, moving to lost+found
disconnected inode 137, moving to lost+found
disconnected inode 139, moving to lost+found
disconnected inode 140, moving to lost+found
Phase 7 - verify and correct link counts...
Maximum metadata LSN (2161919:-1) is ahead of log (1:20).
Format log to cycle 2161922.
done

Passo 4: Depois que o sistema de arquivos for reparado, monte a partição.

Terminal
sudo mount /data

Sobre este tutorial

Neste tutorial você viu como reparar sistemas de arquivos XFS corrompidos no Linux. Note que utilizamos o comando xfs_repair nos volumes LVM. Caso você tenha algum dúvida entre em nosso grupo no Telegram em @sitesempreupdate.

Share This Article
Follow:
Fundador do SempreUPdate. Acredita no poder do trabalho colaborativo, no GNU/Linux, Software livre e código aberto. É possível tornar tudo mais simples quando trabalhamos juntos, e tudo mais difícil quando nos separamos.
Sair da versão mobile