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

OCFS2ボリュームがハングする場合は、次の手順を使用して、ビジー状態のロックと、ロックを保持している可能性があるプロセスを確認できます。

次の手順では、Lockres値は、DLMで使用されるロック名を参照します。これは、ロック・タイプ識別子、iノード番号および世代番号の組合せです。次の表に、様々なロックタイプと関連する識別子を示します。

表6-1 DLMロック・タイプ

識別子	ロック・タイプ
`D`	ファイル・データ。
`M`	メタデータ
`R`	名前変更
`S`	スーパーブロック
`W`	読取り/書込み

debugファイル・システムをマウントします。
次のコマンドを使用してデバッグ・ファイル・システムをマウントします:
```
sudo mount -t debugfs debugfs /sys/kernel/debug
```
ロック・ステータスを表示します。
ファイル・システム・デバイス(次の例では/dev/sdx1)のロック・ステータスをダンプします。
```
echo "fs_locks" | sudo debugfs.ocfs2 /dev/sdx1 | sudo tee /tmp/fslocks
```
```
Lockres: M00000000000006672078b84822 Mode: Protected Read
...
```
iノードと世代番号を取得します。
前の出力からのLockres値を使用して、ロックのinode番号および世代番号を取得します。
```
sudo echo "stat lockres-value" | sudo debugfs.ocfs2 -n /dev/sdx1
```
たとえば、前のステップでのLocres値M00000000000006672078b84822の場合、コマンド出力は次のようになります。
```
Inode: 419616   Mode: 0666   Generation: 2025343010 (0x78b84822)
... 
```
ファイル・システム・オブジェクトを検索します。
ファイル・システム・オブジェクトを前の出力のiノード番号に関連付けます:
```
sudo echo "locate inode" | sudo debugfs.ocfs2 -n /dev/sdx1
```
たとえば、前のステップでのInode値419616の場合、コマンド出力は次のようになります。
```
419616 /linux-2.6.15/arch/i386/kernel/semaphore.c
```
ファイルシステム・オブジェクトのロック名を取得します。
ファイル・システム・オブジェクトに関連付けられているロックの名前を取得します。前のステップの出力は/linux-2.6.15/arch/i386/kernel/semaphore.cです。したがって、次のように入力します。
```
sudo echo "encode /linux-2.6.15/arch/i386/kernel/semaphore.c" | sudo debugfs.ocfs2 -n /dev/sdx1
```
```
M00000000000006672078b84822 D00000000000006672078b84822 W00000000000006672078b84822  
```
前述の例では、ファイル・システム・オブジェクトにメタデータ・ロック、ファイル・データ・ロックおよび読取り/書込みロックが関連付けられています。

DLMドメインを取得します。

次のコマンドを実行して、ファイル・システムのDLMドメインを確立します:

sudo echo "stats" | sudo debugfs.ocfs2 -n /dev/sdX1 | grep UUID: | while read a b ; do echo $b ; done

82DA8137A49A47E4B187F74E09FBBB4B

デバッグの有効化
DLMドメインの値とロック名を使用して、次のコマンドを実行してそのDLMをデバッグできるようにします:
```
sudo echo R 82DA8137A49A47E4B187F74E09FBBB4B M00000000000006672078b84822 | sudo tee /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には3つのロック・モードがあります: ロックなし(type=0)、保護読取り(type=3)および排他(type=5)。前述の例では、ロックはノード1 (owner=1)によって所有されており、ノード3にはファイルシステム・リソースに対する保護読取りロックが付与されています。
スリープ・プロセスの特定。
次のコマンドを使用して、STAT列のDフラグによって示される、中断不可能なスリープ状態にあるプロセスを検索します。
```
ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN
```
中断不可能なスリープ状態にある1つ以上のプロセスが、他のノードでのハングに対応します。

プロセスがI/Oの完了を待機している場合、ブロック・デバイス・レイヤーからドライバ、ディスク・アレイまで、I/Oサブシステム内のすべての場所で問題が発生する可能性があります。ハングがユーザー・ロック(flock())に影響する場合、問題はアプリケーションに存在する可能性があります。可能な場合は、ロックを保持しているプロセスを終了します。ハングがメモリー不足またはメモリーの断片化によるものである場合は、不要なプロセスを終了することでメモリーを解放できます。最も簡単な解決策は、ロックを保持しているノードをリセットすることです。その後、DLMリカバリ・プロセスによって、デッド・ノードが所有するすべてのロックがクリアされ、クラスタが引き続き動作できるようになります。