Necesitamos arreglar la corrupción del sistema de archivos en sdb en la versión Redhat 6
sdb es un sistema de archivos xfs
df -h | egrep "Filesystem|/data" Filesystem Size Used Avail Use% Mounted on /dev/sdb 8.2T 7.0T 1.0T 86% /data porque los datos en sdb son enormes
queremos saber ¿Cuál es la mejor opción 1 o 2?
¿u otra idea para arreglar el sistema de archivos?
opción 1
umount /data fsck -y /dev/sdb mount /data opción 2
umount /data e2fsck -y /dev/sdb mount /data opción 3
umount /data xfs_repair /dev/sdb mount /data segundo, ¿cuáles son los riesgos al hacer fsck en datos enormes?
Comentarios
Respuesta
Citando esta publicación de superusuario :
fsckes solo el nombre original. Cuando presentaran nuevos sistemas de archivos, necesitarían una herramienta específica para cada uno,efsckpara ext,e2fsckpara ext2,dosfsck,fsckvfat. Así que hicieronfsckla interfaz que solo llama a la herramienta adecuada.
fsck.xfs es probablemente lo que busca.
Actualización relacionada con XFS:
xfs_check y xfs_repair deberían ayudarlo a evaluar el daño y reparar si es posible.
Consulte las páginas del manual para obtener información de uso específico.
Comentarios
- para que podamos estar seguros cuando lo hacemos – fsck -y / dev / sdb?
- @yael Eso depende, personalmente creo que lo es, pero esto probablemente se basa en opiniones.
- Entonces, ¿qué es mejor fsck .xfs -y / dev / sdb o fsck -y / dev / sdb
- @yael Creo que ambos harían el mismo trabajo. Pero tiendo a especificar siempre el tipo, es decir. Yo usaría
fsck.xfs. - entonces, ¿cuál es la diferencia entre xfs_repair y fsck.xfs?
Respuesta
Para las personas que votan por fsck.xfs … es solo una versión renombrada de / bin / true. No hace nada excepto devolver «0» y salir . La respuesta correcta es:
umount /data xfs_repair /dev/sdb mount /data Comentarios
- Notarás que xfs_repair fue mencionado en la otra respuesta
e2fscken él?