PowerFlex-filsystemet gjenkjennes ikke etter omstart

Scenario

• Opprett et filsystem på en ScaleIO-enhet (scinia, sinib,...)
• Monter filsystemet på /dev/scinia
• Start serveren på nytt 

Symptomer

Etter omstart kan ikke brukeren montere filsystemet.

Da serveren hadde fullført omstarten, kunne jeg ikke montere filsystemet, og heller ikke reparere det med 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 

Fra /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

Innvirkning

Filsystemet ser ubrukelig og ødelagt ut.

Når Linux kommer opp etter omstart, begynner den å skanne enhetene og tildeler automatisk bokstaver til enheten etter ordre (først finner han - få første bokstav). Vanligvis, når brukeren ikke endrer noe, etter omstart, vil enhetene komme opp med samme enhetsnavn, men noen ganger kan enhetsnavnet endres og tilordnes en annen enhet.

Hvis brukeren monterte filsystemet til / dev / sciniX og ikke til UUID på enheten, kan han tro at filsystemet er ødelagt, men det er tildelt et annet enhetsnavn. Dette er et Linux-problem og ikke bare ScaleIO-relatert. 

Eksempel: Brukeren hadde 10 enheter, så reduserte han den til 5 og startet på nytt bare en dag senere. Du kan se at enheten som ble tilordnet scinia, senere er tilordnet en annen enhet. 

17^th (etter reduksjon fra 10 til 5 enheter)

På server-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

Nå: dvs. etter omstart den 18. da File System (FS) "forsvant"

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

Omgåelse av problemet

 Be brukeren om å bruke UUID for montering.

 Eksempel: De bør kartlegge volumet ved hjelp av enhetens uuid og ikke enhetsnavnet:

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

Eksempel på fstab-oppføring:

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