PowerFlex-Dateisystem nach Neustart nicht erkannt
Summary: Das Dateisystem ist beschädigt oder nach dem Neustart nicht vorhanden.
Symptoms
Beispiel
- Erstellen eines Dateisystems auf einem ScaleIO-Gerät (scinia, sinib,...)
- Mounten Sie das Dateisystem auf /dev/scinia
- Starten Sie den Server neu.
Problem
Nach dem Neustart kann der Nutzer das Dateisystem nicht mounten.
Als der Server den Neustart abgeschlossen hatte, konnte ich das Dateisystem weder mounten noch mit fsck reparieren.
# 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
Von /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
Auswirkungen
Das Dateisystem sieht unbrauchbar und beschädigt aus.
Cause
Wenn Linux nach dem Neustart auftaucht, beginnt es mit dem Scannen der Geräte und ordnet dem Gerät automatisch Buchstaben nach Reihenfolge zu (zuerst findet er - holt sich den ersten Buchstaben). Wenn der Nutzer nach dem Neustart nichts ändert, erhalten die Geräte in der Regel denselben Gerätenamen, manchmal kann sich der Gerätename jedoch ändern und einem anderen Gerät zugewiesen werden.
Wenn der Benutzer sein Dateisystem auf /dev/sciniX und nicht auf der UUID des Geräts eingebunden hat, kann er denken, dass das Dateisystem beschädigt ist, aber es ist einem anderen Gerätenamen zugewiesen. Dies ist ein Linux-Problem und nicht nur im Zusammenhang mit ScaleIO.
Beispiel: Der Benutzer hatte 10 Geräte, dann reduzierte er die Anzahl auf 5 und führte nur einen Tag später einen Neustart durch. Sie sehen, dass das Gerät, das scinia zugewiesen wurde, später einem anderen Gerät zugewiesen wird.
17. (nach Reduzierung von 10 auf 5 Geräte)
Auf 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
Jetzt: d.h. nach dem Neustart am 18., wenn das Dateisystem (FS) "verschwunden" ist
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
Problemumgehung
Bitten Sie den Nutzer, die UUID für das Mounten zu verwenden.
Beispiel: Sie sollten das Volume mithilfe der Geräte-UUID und nicht mit dem Gerätenamen zuordnen:
ls /dev/disk/by-uuid/ to find out the UUID
Beispiel für fstab-Eintrag:
UUID=<UUID> <mount point> ext4 defaults,errors=remount-ro 0 1