4.14. GFS2 の withdraw 関数

GF2S の withdraw 関数は、クラスター内における GFS2 ファイルシステムのデータ整合性機能です。GFS2 カーネルモジュールが、I/O 操作の後に GFS2 ファイルシステムで不整合を検出すると、クラスターはそのファイルシステムを使用できなくなります。その I/O 操作は停止して、システムはさらなる I/O 操作がエラーで停止するのを待ち、それ以上の被害を防ぎます。このような事態が発生した場合は、その他のサービスやアプリケーションをすべて手動で停止した後に、GFS2 ファイルシステムの再起動と再マウントを行い、ジャーナルを再生することができます。問題が解決しない場合は、クラスター内のすべてのノードからファイルシステムをアンマウントして、fsck.gfs2 コマンドでファイルシステムのリカバリを行います。GFS の withdraw 関数は、カーネルパニックほど深刻ではありません。カーネルパニックが発生した場合には、問題のあるノードは別のノードによってフェンシングされます。

gfs2 起動スクリプトを有効にして GFS2 ファイルシステムを /etc/fstab ファイルに含ませているようなシステム構成の場合、再起動を行うと GFS2 ファイルシステムも再マウントされます。GFS2 ファイルシステムに破損が検出され withdraw が作動してそのファイルシステムが使用できなくなった場合には、ファイルシステムの再マウントを行う前に fsck.gfs2 コマンドを実行することを推奨します。この場合、以下の手順で起動時にファイルシステムが再マウントされないようにします。

withdraw の作動で GFS2 が使用できなくなるような不整合の例のひとつとしてブロック数の不一致があります。GFS カーネルがファイルシステムからファイルを削除する場合、そのファイルに関連する全データおよびメタデータのブロックが体系的に削除されます。この動作が終了すると、ブロック数のチェックが行われます。カウントされたブロック数が 1 (残されたのはディスクの inode 自体のみ) にならない場合、ブロック数が検出されたブロック一覧と一致しないためファイルシステムが不整合であるということになります。

-o errors=panic オプションを指定してファイルシステムをマウントすると、GFS2 の withdraw 関数を上書きすることができます。このオプションを指定すると、通常 withdraw が作動するエラーでパニックが発生することになります。パニックでノードのクラスター通信が停止するためそのノードの排他処理が行われます。

内部では、カーネルが gfs_controld デーモンにメッセージを送信して withdraw を要求することにより GFS2 の withdraw 関数が作動します。gfs_controld デーモンは dmsetup プログラムを実行してデバイスマッパーエラーのターゲットをファイルシステム下に配置し、これ以上ブロックデバイスがアクセスされないようにします。次にこの動作が終了したことをカーネルに伝えます。CLVM デバイスを常に GFS2 下で使用することが GFS2 のサポート要件になっているのはこのためです。GFS2 下で CLVM デバイスを使用していない場合デバイスマッパーターゲットを挿入できなくなります。

デバイスマッパーエラーターゲットの目的はそれ以降の I/O 操作がすべて I/O エラーになることでファイルシステムを順番通りにアンマウントさせることです。このため、withdraw が作動するとデバイスマッパーデバイスからの多数の I/O エラーがシステムログにレポートされるのが見られますがこれが通常です。

dmsetup プログラムが要求通りにエラーターゲットを挿入できない場合、withdraw の作動に失敗する場合があります。withdraw 作動の時点でメモリー不足が発生している場合や、最初の段階で withdraw を作動させた問題が原因でメモリーを再利用できないなどの場合に withdraw の作動に失敗する可能性があります。

withdraw が作動したからといって必ずしも GFS2 にエラーがあるということではありません。ベースとなっているブロックデバイス関連のデバイス I/O エラーにより withdraw 関数が作動することもあります。withdraw が作動した場合には、GFS2 のエラーなのかそれ以外のエラーなのかを判断するためログを確認することを強く推奨します。