Файловая система PowerFlex не распознается после перезагрузки
Summary: Файловая система повреждена или отсутствует после перезагрузки.
Symptoms
Сценарий
- Создание файловой системы на устройстве ScaleIO (scinia, sinib,...)
- Смонтируйте файловую систему в /dev/scinia
- Перезагрузите сервер.
Симптомы
После перезагрузки пользователь не может смонтировать файловую систему.
Когда сервер завершил перезагрузку, мне не удалось ни смонтировать файловую систему, ни восстановить ее с помощью 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
Из /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
Воздействие
Файловая система выглядит непригодной для использования и поврежденной.
Cause
Когда Linux заходит после перезагрузки, он начинает сканирование устройств и автоматически присваивает устройства буквы по порядку (первый находит - получает первую букву). Обычно, когда пользователь ничего не меняет, после перезагрузки устройства будут придумывать одно и то же имя устройства, однако иногда имя устройства может измениться, и быть назначено другому устройству.
Если пользователь смонтировал свою файловую систему в /dev/sciniX, а не в UUID устройства, он может подумать, что файловая система повреждена, но она назначена другому имени устройства. Это проблема Linux, а не только ScaleIO.
Пример. У пользователя было 10 устройств, потом он сократил его до 5 и сделал перезагрузку только через сутки. Вы можете увидеть, что устройство, которое было назначено scinia, позже будет назначено другому устройству.
17-й (после сокращения с 10 до 5 устройств)
На сервере-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
Сейчас: т.е. после перезагрузки 18-го числа, когда "исчезла" файловая система (ФС)
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
Временное решение
Попросите пользователя использовать UUID для монтирования.
Пример. Они должны сопоставить том, используя UUID устройства, а не имя устройства:
ls /dev/disk/by-uuid/ to find out the UUID
Пример для записи fstab:
UUID=<UUID> <mount point> ext4 defaults,errors=remount-ro 0 1