Файлова система PowerFlex не розпізнається після перезавантаження

Summary: Файлова система пошкоджена або не існує після перезавантаження.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

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/повідомлень:

[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 числа, коли "зникла" файлова система (FS)

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

Affected Products

PowerFlex rack, ScaleIO
Article Properties
Article Number: 000281262
Article Type: Solution
Last Modified: 05 Feb 2025
Version:  1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.