El sistema de archivos de PowerFlex no se reconoce después del reinicio
Summary: El sistema de archivos está dañado o no existe después del reinicio.
Symptoms
Situación
- Crear un sistema de archivos en un dispositivo ScaleIO (scinia, sinib,...)
- Monte el sistema de archivos en /dev/scinia
- Reinicie el servidor
Síntomas
Después del reinicio, el usuario no puede montar el sistema de archivos.
Cuando el servidor completó el reinicio, no pude montar el sistema de archivos ni repararlo con fsck.
# mount /dev/scinia /mnt
mount: you must specify the filesystem type
# mount -t ext4 /dev/scinia /mnt
mount: wrong fs type, bad option, bad superblock on /dev/scinia,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# fsck /dev/scinia
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/scinia
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
# e2fsck -b 8193 /dev/scinia
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/scinia
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>not
En /var/log/messages:
[Reboot occurred here] Dec 18 13:15:48 e8c4-dl360g7-01 kernel: ECS R1_20:Created device scinia (16,0). Capacity 33554432 LB Dec 18 13:15:48 e8c4-dl360g7-01 kernel: scinia: unknown partition table Dec 18 13:25:21 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 13:26:58 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 13:27:11 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 13:28:30 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 13:33:26 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 13:34:07 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem Dec 18 16:11:00 e8c4-dl360g7-01 kernel: ECS R1_20:Created device scinia (16,0). Capacity 33554432 LB Dec 18 16:11:00 e8c4-dl360g7-01 kernel: scinia: unknown partition table Dec 18 16:11:00 e8c4-dl360g7-01 kernel: EXT4-fs (scinia): VFS: Can't find ext4 filesystem
Impacto
El sistema de archivos se ve inutilizable y dañado.
Cause
Cuando Linux se enciende después del reinicio, comienza a escanear los dispositivos y asigna automáticamente letras al dispositivo por orden (primero encuentra - obtiene la primera letra). Por lo general, cuando el usuario no cambia nada, después del reinicio, los dispositivos tendrán el mismo nombre de dispositivo; sin embargo, a veces el nombre del dispositivo puede cambiar y asignarse a un dispositivo diferente.
Si el usuario montó su sistema de archivos en /dev/sciniX y no en el UUID del dispositivo, puede pensar que el sistema de archivos está dañado, pero está asignado a un nombre de dispositivo diferente. Este es un problema de Linux y no solo está relacionado con ScaleIO.
Ejemplo: El usuario tenía 10 dispositivos, luego los redujo a 5 e hizo un reinicio solo un día después. Puede ver que el dispositivo que se asignó a scinia se asigna posteriormente a un dispositivo diferente.
17.º (después de la reducción de 10 a 5 dispositivos)
En el servidor 01
# ls -l /dev/disk/by-id/scaleio* lrwxrwxrwx 1 root root 12 Dec 17 12:00 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7a0000000c -> ../../scinij lrwxrwxrwx 1 root root 12 Dec 17 12:00 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7b0000000d -> ../../scinib lrwxrwxrwx 1 root root 12 Dec 17 12:00 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7c0000000e -> ../../scinii lrwxrwxrwx 1 root root 12 Dec 17 12:00 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7d0000000f -> ../../scinia lrwxrwxrwx 1 root root 12 Dec 17 12:00 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7e00000010 -> ../../scinih
Ahora: es decir, después del reinicio el día 18 cuando el sistema de archivos (FS) "desapareció"
ls -l /dev/disk/by-id/scaleio* lrwxrwxrwx 1 root root 12 Dec 19 10:51 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7a0000000c -> ../../scinia lrwxrwxrwx 1 root root 12 Dec 19 10:24 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7b0000000d -> ../../scinid lrwxrwxrwx 1 root root 12 Dec 19 10:24 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7c0000000e -> ../../scinic lrwxrwxrwx 1 root root 12 Dec 19 10:24 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7d0000000f -> ../../scinie lrwxrwxrwx 1 root root 12 Dec 19 10:33 /dev/disk/by-id/scaleio-vol-376584c0169c4216-49ff9f7e00000010 -> ../../scinib
Resolution
Solución alternativa
Solicite al usuario que utilice UUID para el montaje.
Ejemplo: Deben asignar el volumen mediante el UUID del dispositivo y no el nombre del dispositivo:
ls /dev/disk/by-uuid/ to find out the UUID
Ejemplo de la entrada fstab:
UUID=<UUID> <mount point> ext4 defaults,errors=remount-ro 0 1