22.3.4 ファイル・システム・ロックのデバッグ

このドキュメントで説明するソフトウェアは、Extended SupportまたはSustaining Supportのいずれかにあります。詳細は、https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdfを参照してください。
Oracleでは、このドキュメントに記載されているソフトウェアをできるだけ早くアップグレードすることをお薦めします。

機械翻訳について

22.3.4 ファイル・システム・ロックのデバッグ

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: Invalid

Lockresフィールドは、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リカバリ・プロセスは、無反応のノードが所有していたすべてのロックをクリアするため、クラスタは動作を継続できます。