問題
再起動が計画的であったかどうかに関係なく、システムの起動後にディスク パーティションがマウントされません。再起動する前に、ディスク パーティションはマウントされ、正常に動作していました。他のシステムの再起動後、ディスクは正しくマウントされましたが、機能しなくなりました。
この動作は、パーティション上のファイル システムの種類に関係なく発生する可能性があり、ファイル システムの種類とは関係ありません。 EXT4 または OCFS2 ファイル システムのディスクの障害が報告されていますが、どのファイル システム タイプでも発生する可能性があります。
/etc/fstab ファイルの一般的なエントリは次のようになります:
/dev/sda1 /mydir ext4 defaults 0 0 /dev/mapper/mpath2 /otherdir ocfs2 _netdev 0 0
またはこれらのさまざまな組み合わせ。
解決策
ディスク ドライブとパーティションは、バスの位置と検出順序に従って、Linux で地理的にアドレス指定されます。 SAN デバイスは、SAN またはクライアントの再起動タイミングが異なるため、検出順序の変更に対して特に脆弱です。
通常は /dev/ ディレクトリにある Linux のファイル名は、システムの起動ごとに動的に割り当てられます。カーネルが起動すると、使用可能な各デバイスが検出され、通知が UDEV (ユーザー空間デバイス管理) サブシステムに送信されます。カーネルのデバイス ID の情報を /etc/udev/rules.d ディレクトリの UDEV ルールセットと比較することにより、UDEV はデバイスに名前を割り当て、/dev/sda または /dev/mapper/mpath1 などのデバイス ノードを作成します。アプリケーションがデバイスにアクセスできること。検出されたデバイスがブロック構造のデバイスである場合、多くの場合、/etc/fstab ファイルの仕様に従ってマウントできるファイル システムを含むパーティションがあります。
Linux は、システムの再起動後も同じデバイス名を維持するためにあらゆる努力を払っていますが、外部環境の変化が実際の名前の選択に影響を与える可能性があります。たとえば、同じ SAN パーティションが、あるクライアントでは /dev/sda である可能性がありますが、別のクラスター ノードでは /dev/sdf である可能性があります。これは、各ホストがデバイスを検出した順序、またはどのマルチパス リンクが最初にオンラインになるかによって異なります。通常、ノードは起動ごとに同じ順序でデバイスを検出しますが、これは保証されません。永続的で予測可能なデバイス ID を保証する方法が必要です。
Linux は再起動のたびに同じデバイス名を再割り当てしようとしますが、クラスター ノード間でそのような調整は行われません。 1 つのクラスター ノードで確実に /dev/sda1 として表示されるパーティションは、別のクラスター ノードでは /dev/sdj として簡単かつ正当に一貫して表示される可能性があります。これにより、クラスタ全体のシステム管理が必要以上に難しくなる可能性があります。以下に示す解決策は、この再起動の問題が発生しないクラスターにも適用できます。
永続的で予測可能なデバイス名を使用するための代替手法を利用できます。難易度順に以下に示します。
ラベルによるマウント
多くのファイル システム タイプでは、各ファイル システムに任意の文字列またはラベルを関連付けることができます。 EXT3 ファイル システムは一例です:
# /sbin/e2label /dev/sda5 /home
次のような /etc/fstab エントリがよく見られます:
LABEL=/HOME /home auto defaults 0 0
OCFS2 ファイル システムは、同様に使用できる認識可能なラベルも提供します。 OCFS2 ラベルを決定する方法については、以下の OCFS2 の例を参照してください。
UUID によるマウント
多くのファイル システム タイプでは、フォーマットされた各ディスク パーティションに Universally Unique Identifier (UUID) が割り当てられます。 EXT3 および OCFS2 ファイル システムは、この例です。通常、UUID は自動的に割り当てられ、システム管理者は通常、値を手動で変更することをお勧めしません。
EXT3 およびその他のタイプのファイル システムでは、e2fsprogs RPM パッケージの一部として提供される blkid ユーティリティを使用します。この例では、出力は次のようになります:
# /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/home" UUID="0c960108-7649-4d8c-a28c-2f75e2f906d3" SEC_TYPE="ext2" TYPE="ext3"
厳密に言えば、UUID は 16 進数のみであることに注意してください。 「-」文字は単なる句読点であり、無視されます。
OCFS2 ファイル システムでは、UUID は常に fsck.ocfs2 ユーティリティによって報告されます。このユーティリティは、「-n」スイッチを使用して読み取り専用テストを確実に行う場合、マウントされたディスク パーティションで安全に使用できます。
# /sbin/fsck.ocfs2 -n /dev/hda1 Checking OCFS2 filesystem in /dev/hda1: label: OCFS2 uuid: bc d0 de d0 58 ea 43 11 bd a9 e0 66 e6 cb 37 b4 number of blocks: 209632 bytes per block: 1024 number of clusters: 52408 bytes per cluster: 4096 max slots: 4 /dev/hda1 is clean. It will be checked after 20 additional mounts.
繰り返しますが、適切な UUID は 16 進数の文字列であることに注意してください。ここではスペースで区切られていますが、実際の UUID は単なる数字です。 UUID だけを取得するには、短い awk(1) プログラムで十分です:
# /sbin/fsck.ocfs2 -n /dev/hda1 | /bin/awk '/uuid/ { $1 = ""; gsub( / /, "" ); print }'
bcd0ded058ea4311bda9e066e6cb37b4 UUID を取得したので、次のような /etc/fstab エントリは EXT3 または OCFS2 パーティションをマウントします:
UUID=bcd0ded058ea4311bda9e066e6cb37b4 /ocfs2 ocfs2 _netdev 0 2 UUID=0c96010876494d8ca28c2f75e2f906d3 /home ext3 defaults 0 2
UUID はディスク パーティション自体に保存されるため、実際のデバイス名が変更されても問題ありません。これにアクセスするための永続的で予測可能な方法が保証されています。
UDEV ルールセットの使用
永続的で予測可能なデバイス名を持つもう 1 つの方法は、カーネルがデバイス名の割り当てに使用するのと同じ UDEV サービスを利用することです。これには、デバイス属性を使用してデバイスを識別し、そのデバイス ノードを作成する UDEV 一致ルールの作成が含まれます。多くの場合、ルールは、カーネルが割り当てる実際の低レベル デバイス ノードへのシンボリック リンクを作成するだけです。
これは、デバイス マッパー マルチパス デバイスを実装するために使用される手法です。カーネルは /dev/dm-X デバイスを作成します。次に、UDEV ルールとマルチパス デーモンが /dev/mpath/
作成される /dev/mapper/ ファイル名のタイプは、/etc/multipath.conf ファイルの user_friendly_names 設定によって制御されます。デフォルト設定は次のとおりです:
default {
user_friendly_names yes
}
奇妙なことに、これはまったく意味のない /dev/mapper/mpathN 名を作成します。これをコメントアウトすることで、より印象的な /dev/mapper/
以下は、UDEV マッチング ルールの例です。行は、一連の述語または一致する式で始まります。これらは「==」演算子でマークされます。すべての述語が検出されたデバイスのものと一致する場合、「=」句で示されるアクションが実行されます。
SYSFS{vendor}=="iriver" SYSFS{model}=="T10" OWNER="user" MODE="0600" SYMLINK+="iriver%n" この例では、最初の IRiver T10 プレーヤーが USB ポートに接続されたときに、シンボリック リンク /dev/iriver0 を作成します。デバイスは、ファイル アクセス許可 0600 を持つユーザーによって所有されます。USB サブシステムは、デバイスが接続されたことを認識し、カーネルに通知します。デバイスに関して検出された属性もカーネルに渡されます。この情報は最終的に UDEV サブシステムに到達し、/etc/udev/rules.d 内のルール セットの読み取りが開始され、デバイス属性が各ルールの述語に一致します。すべての述語がルールに一致する場合、そのルールで指定されたすべてのアクションが実行されます。
UDEV ルールを記述するための構文を含む、UDEV システムに関するドキュメントは、udev マニュアル ページからオンラインで入手できます。
UDEV ルールを作成する際の難しい部分は、ルールによってデバイスを適切に識別できるように、どの属性が利用可能かを知ることです。 udevinfo ユーティリティは、ルールで使用可能なデバイス名と属性を表示します。この例では、/var/log/messages を確認すると、IRiver デバイスがブロック デバイスとして検出され、名前 /dev/sdb が割り当てられていることがわかります。これで、/block/sdb システム情報を調べることで、すべてのデバイス情報と属性を取得できます。
# /usr/bin/udevinfo -q all -p /block/sdb P: /block/sdb N: sdb S: disk/by-id/usb-iriver_T10 S: disk/by-path/pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0 E: ID_VENDOR=iriver E: ID_MODEL=T10 E: ID_REVISION=1.00 E: ID_SERIAL=iriver_T10 E: ID_TYPE=disk E: ID_BUS=usb E: ID_PATH=pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0注意 パスは、従来のルートではなく、/sys/ ディレクトリからの相対パスです。完全なファイル名は /sys/block/sdb ですが、udevinfo は /sys の部分を想定しています。
最小限の属性セットを選択するのは難しい場合がありますが、過度に指定する誘惑は避けてください。ここでは、ベンダー名とモデル名を使用することを選択しましたが、オブジェクト デバイスを識別する任意の属性セットを使用できます。述語とアクションを選択したら、ルールを /etc/udev/rules.d ディレクトリ内の独自のファイルに配置します。ディストリビューションからルールセットを変更しないでください。変更すると、パッケージが更新されたときに変更が失われる可能性があります。この例では、ファイル名に /etc/udev/rules.d/49-iriver.rules を使用しました。
UDEV ルールを設定したら、udevtest ユーティリティを使用して UDEV の実行をシミュレートし、何が行われるかを示します。