再起動後に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/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が再起動後に起動すると、デバイスのスキャンが開始され、順序によってデバイスに文字が自動的に割り当てられます(最初に見つけます-最初の文字を取得します)。通常、ユーザーが何も変更しない場合、再起動後にデバイスは同じデバイス名で表示されますが、デバイス名が変更され、別のデバイスに割り当てられる場合があります。

ユーザーがファイル・システムをデバイスのUUIDではなく/dev/sciniXにマウントした場合、ファイル・システムは破損していると考えられますが、別のデバイス名に割り当てられています。これはLinuxの問題であり、ScaleIOだけの問題ではありません。 

 

Example: ユーザーは10台のデバイスを持っていましたが、それを5台に減らし、わずか1日後に再起動を行いました。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

Now:つまり、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を使用するようユーザーに依頼します。

 Example: デバイス名ではなく、デバイス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.