このドキュメントで説明するソフトウェアは、Extended SupportまたはSustaining Supportのいずれかにあります。 詳細は、https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdfを参照してください。
Oracleでは、このドキュメントに記載されているソフトウェアをできるだけ早くアップグレードすることをお薦めします。
OCFS2ボリュームがハングした場合、次のステップを使用すると、ビジー状態にあるロックと、ロックを保持している可能性の高いプロセスを特定するのに役立ちます。
debugファイル・システムをマウントします。
#
mount -t debugfs debugfs /sys/kernel/debug
ファイル・システム・デバイス(この例では
/dev/sdx1
)のロック・ステータスをダンプします。#
echo "fs_locks" | debugfs.ocfs2 /dev/sdx1 >/tmp/fslocks 62
Lockres: M00000000000006672078b84822 Mode: Protected Read Flags: Initialized Attached RO Holders: 0 EX Holders: 0 Pending Action: None Pending Unlock Action: None Requested Mode: Protected Read Blocking Mode: InvalidLockres
フィールドは、DLMによって使用されるロック名です。 ロック名は、ロック・タイプ識別子、inode番号および世代番号の組合せです。 次の表に、使用可能なロック・タイプを示します。識別子
ロック・タイプ
D
ファイル・データ。
M
メタデータ。
R
名前変更。
S
スーパーブロック。
W
読取り/書込み。
Lockres
値を使用して、ロックのinode番号および世代番号を取得します。#
echo "stat <M00000000000006672078b84822>" | debugfs.ocfs2 -n /dev/sdx1
Inode: 419616 Mode: 0666 Generation: 2025343010 (0x78b84822) ...次のコマンドを使用して、inode番号が関連付けられたファイル・システム・オブジェクトを特定します。
#
echo "locate <419616>" | debugfs.ocfs2 -n /dev/sdx1
419616 /linux-2.6.15/arch/i386/kernel/semaphore.cファイル・システム・オブジェクトに関連付けられたロック名を取得します。
#
echo "encode /linux-2.6.15/arch/i386/kernel/semaphore.c" |
\debugfs.ocfs2 -n /dev/sdx1
M00000000000006672078b84822 D00000000000006672078b84822 W00000000000006672078b84822この例では、ファイル・システム・オブジェクトにメタデータ・ロック、ファイル・データ・ロックおよび読取り/書込みロックが関連付けられています。
ファイル・システムのDLMドメインを特定します。
#
echo "stats" | debugfs.ocfs2 -n /dev/sdX1 | grep UUID: | while read a b ; do echo $b ; done
82DA8137A49A47E4B187F74E09FBBB4B次のコマンドでDLMドメインおよびロック名の値を使用して、DLMのデバッグを有効にします。
#
echo R 82DA8137A49A47E4B187F74E09FBBB4B
\M00000000000006672078b84822 > /proc/fs/ocfs2_dlm/debug
デバッグ・メッセージを調査します。
#
dmesg | tail
struct dlm_ctxt: 82DA8137A49A47E4B187F74E09FBBB4B, node=3, key=965960985 lockres: M00000000000006672078b84822, owner=1, state=0 last used: 0, on purge list: no granted queue: type=3, conv=-1, node=3, cookie=11673330234144325711, ast=(empty=y,pend=n), bast=(empty=y,pend=n) converting queue: blocked queue:DLMでは、ロックなし(
type=0
)、保護読取り(type=3
)および排他(type=5
)という3つのロック・モードがサポートされます。 この例では、ロックはノード1 (owner=1
)によって制御され、ノード3にファイルシステム・リソースに対する保護された読取りロックが付与されています。次のコマンドを実行し、
STAT
列のD
フラグによって示される中断不可能なスリープ状態にあるプロセスを検索します。#
ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN
中断不可能なスリープ状態にある1つ以上のプロセスが、他のノードでのハングに対応します。
プロセスがI/Oの完了を待機している場合、ブロック・デバイス・レイヤーからドライバを通じてディスク・アレイに至るI/Oサブシステム内のすべての場所で問題が発生する可能性があります。 ハングがユーザー・ロック(flock()
)に影響する場合、問題はアプリケーションに存在する可能性があります。 可能であれば、ロックの所有者を強制終了します。 ハングの原因がメモリーの不足またはメモリーの断片化にある場合、重要でないプロセスを強制終了してメモリーを解放できます。 最も迅速な解決策は、ロックを保持しているノードをリセットすることです。 DLMリカバリ・プロセスは、無反応のノードが所有していたすべてのロックをクリアするため、クラスタは動作を継続できます。