Système de fichiers PowerFlex non reconnu après le redémarrage

Scénario

• Créer un système de fichiers sur un appareil ScaleIO (scinia, sinib,...)
• Montez le système de fichiers sur /dev/scinia
• Redémarrer le serveur 

Symptômes

Après le redémarrage, l’utilisateur ne parvient pas à monter le système de fichiers.

Lorsque le serveur a terminé le redémarrage, je n’ai pas pu monter le système de fichiers, ni le réparer avec 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 

À partir de /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

Impact

Le système de fichiers semble inutilisable et corrompu.

Lorsque Linux arrive après le redémarrage, il commence à scanner les périphériques et attribue automatiquement des lettres à l’appareil par ordre (d’abord il trouve - obtenez la première lettre). Généralement, lorsque l’utilisateur ne modifie rien, après le redémarrage, les appareils affichent le même nom de périphérique, mais il arrive que le nom du périphérique change et soit attribué à un autre périphérique.

Si l’utilisateur a monté son système de fichiers sur /dev/sciniX et non sur l’UUID du périphérique, il peut penser que le système de fichiers est corrompu, mais il est affecté à un nom de périphérique différent. Il s’agit d’un problème Linux qui n’est pas uniquement lié à ScaleIO. 

Exemple : L’utilisateur disposait de 10 appareils, puis il l’a réduit à 5 et a effectué un redémarrage seulement un jour plus tard. Vous pouvez voir que l’appareil qui a été attribué à scinia est ensuite attribué à un autre appareil. 

17^ème (après réduction de 10 à 5 appareils)

Sur le serveur 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

Maintenant : c’est-à-dire, après le redémarrage le 18, lorsque le système de fichiers (FS) a « disparu »

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

Solution

 Demandez à l’utilisateur d’utiliser l’UUID pour le montage.

 Exemple : Ils doivent mapper le volume à l’aide de l’UUID du périphérique et non du nom du périphérique :

ls /dev/disk/by-uuid/      to find out the UUID

Exemple pour l’entrée fstab :

 UUID=<UUID> <mount point>      ext4 defaults,errors=remount-ro 0 1