¿Cómo saber si tienes un filesystem corrupto en RedHat?

Me he encontrado con que tenía un filesystem montado en el servidor, en el que podía escribir y leer sin problemas… casi siempre. Pasaban cosas raras. El usuario reportaba problemas de este tipo:

Si miro el contenido del archivo /opt/oracle_crs/app/oracle/product/12.1.0.2/grid_1/bin/srvctl me sale como si fuera cluvfy. Si miro el contenido de cluvfy me sale el contenido de algo llamado “dropdb” y además otro “scrctl” truncado ¿¿??, he buscado el archivo “dropdb” y lo he encontrado en /opt/oracle_crs/app/oracle/product/12.1.0.2/grid_1/crs/install/

Si miro el contenido de dropdb comienza “partido”:
[oracle@lo02doe0 install]$ strings dropdb | head
; then
             /usr/bin/coreadm -e process > /dev/null 2>&1
           fi
         fi
       fi
       ;;

Y, de hecho, al mirar el contenido del filesystem el propietario de algunos archivos mostraba interrogantes:

Filesystem corrupto

Confirmación de que el Filesystem está corrupto

Parece muy obvio de que el filesystem está corrupto pero, para terminar de verificarlo, utilizo tune2fs:

[root@lo02doe0 opt]# tune2fs -l /dev/mapper/vgoraclesoft-lvoraclecrs
tune2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: /opt/oracle_crs
Filesystem UUID: a68af5bb-223b-448d-8064-99bec5318fa9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1966080
Block count: 7864320
Reserved block count: 393216
Free blocks: 4963373
Free inodes: 1869634
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 4
RAID stripe width: 4096
Flex block group size: 16
Filesystem created: Wed Jan 31 08:20:43 2018
Last mount time: Fri Mar 16 11:34:34 2018
Last write time: Fri Apr 6 13:49:19 2018
Mount count: 5
Maximum mount count: 27
Last checked: Wed Jan 31 08:20:43 2018
Check interval: 15552000 (6 months)
Next check after: Mon Jul 30 09:20:43 2018
Lifetime writes: 11 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: f34a246b-8e96-4a4f-b953-ab31b1c97c78
Journal backup: inode blocks
[root@lo02doe0 opt]#

La mala noticia es que para reparar el filesystem hay que parar el servicio, desmontarlo y ejecutar el fsck.

En el caso de que quieras forzar un fsck de todos tus filesystems al rebotar el servidor, ejecuta el comando touch /forcefsck y rebota el sistema. Si tienes filesystems muy grandes puede que tarde un buen rato.

Corrompiendo un Filesystem a propósito

He tenido la necesidad de corromper un filesystem ext4 en un RedHat 6 a propósito para realizar un test de chequeo de filesystem. En mi caso, el filesystem era el /dev/sdb.

Para corromperlo, he utilizado el siguiente comando:

dd if=/dev/zero count=1 bs=4096 of=/dev/sdb
Corromper filesystem

Como vemos, aparece el mensaje de «filesystem corruption».

Seguidamente, lo que quería saber era si podía hacer el kill del proceso fsck o, por el contrario, se quedaría en pausa esperando por input/output.

Para comprobar esto, ejecuté:

  • El fsck en backuground.
  • Un script que capturaba el PID del fsck y lo mataba con un kill -9.

Y funcionó. Es decir, sí pude matar el proceso.

killfsck

En cuanto al script killfsck.sh, este es el código fuente:

ps -ef |grep fsck |grep -v grep |awk '{print "kill -9 " $2}' |sh

Ahora voy a corromper más datos del filesystem para dejar los datos inservibles

  • Creo un filesystem de 40GB de prueba con un fichero de 10GB para luego corromperlo aposta:
[root@lhpilox01 ~]# df -hP /corromper/
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/vgrear-lvcorromper   40G   48M   38G   1% /corromper
[root@lhpilox01 ~]#

[root@lhpilox01 /]# ls -lh /corromper/
total 11G
drwx------ 2 root root 16K Dec 11 10:25 lost+found
-rw-r--r-- 1 root root 10G Dec 11 10:28 prueba_borrar01.txt
[root@lhpilox01 /]#
  • Corrompo el FS por varios sectores distintos:
[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=50 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.00190588 s, 215 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=100 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.000987114 s, 415 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=200 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.000903902 s, 453 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=1000 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.00153588 s, 267 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=5000 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.00198601 s, 206 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=10000 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.00161894 s, 253 MB/s
[root@lhpilox01 /]#

[root@lhpilox01 /]# dd if=/dev/zero count=100 bs=4096 seek=20000 of=/dev/mapper/vgrear-lvcorromper
100+0 records in
100+0 records out
409600 bytes (410 kB) copied, 0.00158615 s, 258 MB/s
[root@lhpilox01 /]#

El fichero de 10GB ha quedado inservible:

[root@lhpilox01 /]# ls -lh /corromper/
ls: cannot access /corromper/prueba_borrar01.txt: Input/output error
ls: cannot access /corromper/lost+found: Input/output error
total 0
d????????? ? ? ? ?            ? lost+found
-????????? ? ? ? ?            ? prueba_borrar01.txt
[root@lhpilox01 /]#
  • Voy a intentar recuperarlo, igualmente:
[root@lhpilox01 /]# time fsck -C -a /dev/mapper/vgrear-lvcorromper
fsck from util-linux-ng 2.17.2
fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/vgrear-lvcorromper
/dev/mapper/vgrear-lvcorromper:
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>


real    0m0.322s
user    0m0.007s
sys     0m0.027s
[root@lhpilox01 /]#

Lo intento con e2fsck:

[root@lhpilox01 /]# e2fsck -y /dev/mapper/vgrear-lvcorromper
e2fsck 1.41.12 (17-May-2010)
One or more block group descriptor checksums are invalid.  Fix? yes

Group descriptor 0 checksum is invalid.  FIXED.
Group descriptor 1 checksum is invalid.  FIXED.
Group descriptor 2 checksum is invalid.  FIXED.
Group descriptor 3 checksum is invalid.  FIXED.
Group descriptor 4 checksum is invalid.  FIXED.
Group descriptor 5 checksum is invalid.  FIXED.
Group descriptor 6 checksum is invalid.  FIXED.
Group descriptor 7 checksum is invalid.  FIXED.
Group descriptor 8 checksum is invalid.  FIXED.
Group descriptor 9 checksum is invalid.  FIXED.
Group descriptor 10 checksum is invalid.  FIXED.
Group descriptor 11 checksum is invalid.  FIXED.
Group descriptor 12 checksum is invalid.  FIXED.
Group descriptor 13 checksum is invalid.  FIXED.
Group descriptor 14 checksum is invalid.  FIXED.
/dev/mapper/vgrear-lvcorromper contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #15 (0, counted=32768).
Fix? Yes
…
Free inodes count wrong (2621427, counted=2621429).
Fix? yes


/dev/mapper/vgrear-lvcorromper: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/vgrear-lvcorromper: 11/2621440 files (0.0% non-contiguous), 176783/10485760 blocks
[root@lhpilox01 /]#

Ahora sí que puedo montar el filesystem pero el fichero de 10GB se ha perdido:

[root@lhpilox01 /]# mount /corromper/
[root@lhpilox01 /]# ls -lh /corromper/
total 4.0K
drwx------ 2 root root 4.0K Dec 11 11:17 lost+found
[root@lhpilox01 /]#

Te puede interesar

Aumentar el tamaño de Journal de un FS EXT4

COMPÁRTEME

Deja un comentario