64bitファイルシステム XFSの実装Linuxファイルシステム技術解説(7)(2/3 ページ)

» 2004年08月24日 00時00分 公開

XFSのジャーナリング機能

 XFSのジャーナリング機能は、メタ・データをジャーナルする方式である。ext3のように、メタ・データを書き込む前にデータをディスクに書き込むといった特別な方式は取っていない。XFSの特徴は、ログを頻繁に更新することで、復旧時にこのログの手順を再生する確率を高めている点である。

図5 ログの保存 図5 ログの保存

 例えば、XFSはwriteなどのオペレーションが行われると、オペレーションのログとしてメタ・データの更新操作情報がメモリ上のバッファに書き込まれる(1)。バッファのデータは、ディスクに書き込まれるとジャーナルファイルとなる(2)。このディスクへの書き込みは非同期に行われる。ジャーナルファイルの書き込みが完了すると、リソースをディスクに書き込む。クラッシュ後の復旧は、マウント時にジャーナルファイルが読み込まれ、メタ・データのチェックを行うことで実行される。

XFSのジャーナルログの構造

 XFSでは、メモリ上のバッファに書き込まれるログをin-core logと呼び、図6のようにFIFOキューの構造をしている。in-core logに記録されているオペレーションは、アクティブオペレーションと呼ばれている。

図6 in-core logのFIFOキュー構造 図6 in-core logのFIFOキュー構造

 ディスクに書き込まれるログはon-disk logと呼ばれ、図7のように環状のキュー構造をしている。on-disk logに記録されているオペレーションは、コミットされたオペレーションと呼ばれる。on-disk logは環状構造であるため、新たなログを書き込む場合は、キュー末尾にある最も古いログのエントリが新しく書き込むログエントリによって上書きされる。

図7 on-disk logの環状キュー構造 図7 on-disk logの環状キュー構造

 ディスクへのログの書き込み回数を減らすために、in-core log上の複数のアクティブオペレーションは「ログレコード」というグループにまとめられている。このレコードはアクティブログレコードと呼ばれ、on-disk logに書き込まれるまでin-core log内に保存される。ディスクに書き込まれたログレコードは、コミットされたログレコードとして扱われる。

 in-core logからon-disk logへの書き込みは、次の3つのイベントの発生をトリガとする。

  • in-core logのキューが満杯に近づいたとき
  • ディスクへの書き込みを要求するリクエストがあったとき
  • 内部的なタイムアウトが発生したとき

 このように行うことで、XFSはディスクへのアクセス回数を減らし、ログの書き込みを効率的に行う。

トランザクションによるジャーナルログ書き込み

 XFSにおけるトランザクションは、図8のように7段階で構成されている。

図8 XFSのトランザクション処理 図8 XFSのトランザクション処理

(1)トランザクションのアロケーション

トランザクションの際に最初に行うのは、トランザクション構造体と一意なトランザクション識別子の割り当てである。トランザクション構造体は、重要なイベントやトランザクションに関連した情報の記録に使用される。トランザクション識別子は、on-disk log内のトランザクションに関連したデータに対して割り付けられるものである。

(2)ログスペースの確保

in-core logがあふれないように、トランザクションを行うために必要なログスペースの確保を行う。トランザクションが使用するin-core logのスペースが足りない場合は、そのトランザクションは待ち状態になるかキャンセルされる。in-core logのデータがディスクにフラッシュされ、そのデータがin-core logのキューから削除されると、削除されたスペースは新たなログスペースとして使用できる。

(3)リソースのロック

バッファやiノードといったリソースの読み込みやロックを行う。

(4)リソースの修正/オペレーションの明示

リソースがロックされると、そのリソースに対して修正を行うことができる。この段階で、オペレーションを記録するために使用するトランザクションオペレーション構造体が作られる。トランザクションオペレーション構造体は、システムがクラッシュした場合に復旧コードによって使用されるオペレーションを記録するものである。

(5)コミットトランザクション

リソースに対して必要な変更がすべて完了したとき、トランザクションはコミットされる。トランザクションコミットでは、すべてのリソースの修正情報やトランザクションオペレーションをin-core logに記録する。リソースの修正がin-core logにコミットされると、トランザクションがロックしているすべてのリソースを解放する。この時点で、更新データはメモリ上にあるため、トランザクションは永久的なものになっていない。

(6)ログ書き込みの完了

in-core logがディスクに書き込まれた時点で、トランザクションは永久的なものとなる。これらは、トランザクションの過程で自動的に行われる。また、このときトランザクション構造体も解放される。

(7)修正されたリソースのフラッシュ

修正を含んだログの書き込みが完了すると、そのリソースはディスクにフラッシュされる。


ライトアヘッドロギング

 ファイルシステムは、一般的にデータの書き込みを非同期に行うことで、書き込みの効率を高めることができる。しかし、非同期書き込みの実行中にシステムがクラッシュした場合は一部のデータが失われるなど、同期書き込みに比べて復旧不可能な矛盾がファイルシステムに発生する可能性が高い。そこで、XFSは「ライトアヘッドロギング」という方法を採用している。

 ライトアヘッドロギングは、リソースの更新前にログの書き込みを行う方法である。伝統的なライトアヘッドロギングは、ログをディスクに対して同期的に書き込んだ後、トランザクションのコミットを完了し、リソースのロックを解放する。更新データは保証されるが、ログがディスクへ書き込まれるのを待たなければならない。また、リソースもロックし続けるため、ファイルシステムの更新速度は遅くなる。

 XFSのライトアヘッドロギングは、ログがon-disk logにコミットされるまで、修正されたデータをディスクにフラッシュしない。つまり、ログがディスクに書き込まれたことを確認してから、修正されたデータをディスクに書き込む。リソースのロックは、トランザクションログがin-core logに書き込まれた時点で解放される。ログにはファイルシステムへの更新の順序が保存されているため、トランザクションコミットがin-core logに書き込まれれば、ロックを解放できるのだ。

 リソースデータは、トランザクションコミットがon-disk logに書き込まれるまで、メモリに保存される。

ファイルシステムの復旧

 XFSのファイルシステム復旧処理は、ほかのジャーナリングファイルシステムと同じ手順で行われる。

 クラッシュの後、XFSのリカバリシステムがon-disk logを読み、最後にディスクと同期を取ったログを探す。それよりも前のログはディスクとの同期が完了しているため、復旧の必要はない。

 on-disk logから最後に同期を取ったログを見つけると、on-disk logをその位置から終端方向に向かって読み取る。そして、完了したオペレーションやコミットされたトランザクションを、ログの終端に向かって順番に再実行(redo)することで、ファイルシステムの再構築を行う。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。