precisamos corrigir a corrupção do sistema de arquivos no sdb na versão 6 do redhat
sdb é um sistema de arquivos xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data porque os dados no sdb são enormes
queremos saber qual é a melhor opção 1 ou 2?
ou outra ideia para consertar o sistema de arquivos?
opção 1
umount /data fsck -y /dev/sdb mount /data opção 2
umount /data e2fsck -y /dev/sdb mount /data opção 3
umount /data xfs_repair /dev/sdb mount /data segundo – quais são os riscos ao fazer fsck em dados enormes?
Comentários
Resposta
Citando esta postagem do SuperUser :
fscké apenas o nome original. Quando eles lançassem novos sistemas de arquivos, precisariam de uma ferramenta específica para cada um,efsckpara ext,e2fsckpara ext2,dosfsck,fsckvfat. Então, eles criaramfscko front end que apenas chama a ferramenta apropriada.
fsck.xfs é provavelmente o que você deseja.
Atualização relacionada ao XFS:
xfs_check e xfs_repair deve ajudá-lo a avaliar os danos e conserte se possível.
Por favor, veja as páginas de manual para informações específicas de uso.
Comentários
- para que possamos estar seguros quando fazemos – fsck -y / dev / sdb?
- @yael Isso depende, eu pessoalmente acho que é, mas provavelmente é baseado em opinião.
- então o que é melhor fsck .xfs -y / dev / sdb ou fsck -y / dev / sdb
- @yael Acho que ambos fariam o mesmo trabalho. Mas tendo a sempre especificar o tipo, ou seja. Eu usaria
fsck.xfs. - então qual é a diferença entre xfs_repair e fsck.xfs?
Resposta
Para as pessoas que votam em fsck.xfs … é apenas uma versão renomeada de / bin / true. Não faz nada, exceto retornar “0” e sair . A resposta adequada é:
umount /data xfs_repair /dev/sdb mount /data Comentários
- Você notará que xfs_repair foi mencionado em a outra resposta
e2fscknele?