JP5090221B2 - ジャーナルログ記録制御方法 - Google Patents

Description

本発明は、ジャーナルログ記録制御方法に係り、特に、ジャーナルログを用いてファイルシステムの障害を回復する際に、ジャーナルログのデータを最小限に抑えても、修復機能を単純化かつ完全化することが可能となる方法に関するものである。

電源断やシステムクラッシュに対するファイルシステムの信頼性を確保するためには、トランザクション単位で更新されたメタデータをまずジャーナルログに記録してから、目的のメタデータを上書きする手段が取られている。このジャーナル機能を持ったファイルシステムは、一般的にジャーナルファイルシステムと呼ぶ。
既存の非ジャーナルファイルシステムにジャーナルログを記録する領域をファイルシステムの管理する領域内に確保することでジャーナルファイルシステムに拡張することが可能である。ジャーナルログを記録することによって、電源断やシステムクラッシュが発生した場合、ジャーナルログによる高速な修復が可能となる。
しかし、一方では、ジャーナルログの記録による性能劣化が発生するという欠点がある。この性能劣化を最小限に抑えるために、更新されたメタデータブロック全体ではなく、アプリケーションからのファイル操作種別と操作対象のファイル（すなわち、更新内容）をジャーナルログに記録する方法が知られている。（下記、特許文献１参照）
また、ファイルシステムの信頼性を向上するためには、メタデータのバックアップ領域を持つファイルシステムフォーマットがある（以降、バックアップ領域にあるメタデータをセカンダリメタデータ、元のメタデータをプライマリメタデータと呼ぶ）。プライマリメタデータが物理的に壊れて読めない場合は、セカンダリメタデータが使用される。
前述したジャーナル機能とメタデータのバックアップ機能を両方持ったファイルシステムでは、メタデータの更新処理がさらに性能を劣化させる大きな要因となるため、ジャーナルログの内容を如何に最小限にすることが重要である。

なお、本願発明に関連する先行技術文献としては以下のものがある。
特開２００４−７８４６１号公報

前述したメタデータの更新内容をジャーナルログに記録する方法では、ジャーナルログの量を減らすことが可能であるが、以下のような問題点がある。
（１）ファイル操作を追加または変更する場合、それに合わせて修復処理も変更する必要がある。
（２）ファイルシステムのフォーマットが複雑化すると、ジャーナルログに記録された更新内容と、途中まで更新されたメタデータを用いて、修復を行うことが困難である。
（３）更新されたメタデータブロックを磁気ディスクに上書きする際に、電源断が発生する場合、そのメタデータブロック全体が信用できない可能性があり、ジャーナルログに記録された更新内容の情報のみでは、修復ができなかった。
（４）セカンダリメタデータを記録するファイルシステムにおいて、プライマリメタデータとセカンダリメタデータの状態が異なる場合、修復を行うことが困難である。
本発明は、前記問題点を解決するためになされたものであり、本発明の目的は、ファイルシステムのフォーマット及びファイル操作に依存しないで、メタデータを完全に修復することが可能となるジャーナル記録制御方法を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、下記の通りである。
前述の目的を達成するために、本発明においては、記録手段にセカンダリメタデータを記録することを前提にし、前記セカンダリメタデータをジャーナルログの一部として兼用し、障害から回復する処理で、ジャーナルログとともにプライマリメタデータ及びセカンダリメタデータを活用することにより、前記ジャーナルログには更新されたメタデータのブロック番号のみを記録することを特徴とする。

本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明のジャーナル記録制御方法によれば、ジャーナルログの記録による性能劣化を最小限に抑えることができ、ファイル操作に依存しない単純な方法でメタデータを完全に修復することが可能となる。

以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
図１は、本発明の実施例のファイルシステムのボリュームの概略構成を示すブロック図である。図１において、１００はボリューム全体、１０１はプライマリメタデータ領域、１０２はデータ領域、１０３はジャーナルログ領域、１０４はセカンダリメタデータ領域を示す。セカンダリメタデータ領域１０４は、ジャーナルログ１０３の一部として兼用する。なお、本実施例では、前述のボリューム１００は磁気ディスク内の領域である。
図１に示すように、本実施例のファイルシステムの管理領域（ボリューム）は、プライマリメタデータ領域１０１とセカンダリメタデータ領域１０４を持つ。そして、同じくファイルシステムの管理領域内にジャーナルログ領域１０３が備えられている。
前記ジャーナルログ領域は予め確保され、ジャーナルログの記録に伴い、メタデータの更新が発生しないものである。前記セカンダリメタデータ領域１０４は、ジャーナルログと兼用することにより、前期ジャーナルログ領域１０３を最小限にすることが可能である。
図２は、本発明の実施例のメタデータ領域の概略構成を示すブロック図である。図２において、２００はメタデータ領域、２０１はメタデータブロック及びデータブロックの使用状態を表すスペースビットマップ領域、２０２はメタデータ領域を示す。
図２に示すように、メタデータブロック及びデータブロックの使用状態を示すスペースビットマップ２０１は、ファイル及びディレクトリの情報を格納するメタデータ２０２と一緒に含まれており、前記スペースビットマップ２０１はバックアップ対象となる。

図３は、本発明の実施例のファイルシステムのボリュームの変形例の概略構成を示すブロック図である。図３において、３００はボリューム全体、３０１はメタデータブロック及びデータブロックの使用状態を表すスペースビットマップ領域、３０２はプライマリメタデータ領域、３０３はデータ領域、３０４はジャーナルログ領域、３０５はセカンダリメタデータ領域を示す。セカンダリメタデータ領域３０５は、ジャーナルログ領域３０４の一部として兼用する。
図３に示す変形例でも、図１に示す構成１と同様に、ファイルシステムの管理領域（ボリューム）は、プライマリメタデータ領域３０２、セカンダリメタデータ領域３０５及びジャーナルログ領域３０４を備える。
しかし、図１に示す構成とは異なり、図３に示す変形例では、スペースビットマップ領域３０１がプライマリメタデータ領域３０２またはセカンダリメタデータ領域３０５に含まれず、バックアップ対象でない独立した領域となる。メタデータのバックアップは、基本的にプライマリメタデータが物理的に故障し読めない場合に利用しており、この場合は該当ボリュームが読み込み専用で運用するため、スペースビットマップ領域のバックアップは必ずしも必要としない。

図４は、本実施例のトランザクションタイプ１のジャーナルログデータフォーマットを示す図である。図４において、４００はトランザクションタイプ１のジャーナルログデータ全体のフォーマットであり、４０１は本トランザクションを記録する日時である。ジャーナルログ領域は、リングバッファ方式で使用するため、トランザクション日時４０１はトランザクションログの順序を判定するために使用する。
トランザクションタイプ４０２は以降で説明するタイプ２およびタイプ３のトランザクション情報と区別するために使用する。
本ランザクションデータのチェックサム４０３は、該当するトランザクション情報の信憑性を判定するために使用する。
トランザクションの番号４０４は、トランザクション情報のグループ分け、およびトランザクション日時４０１とともに、トランザクションログの順序を判定するために使用する。
また、図４に示すタイプ１のトランザクション情報には、トランザクションにて更新されたメタデータブロックの数４０５、トランザクションにて確保あるいは開放されたブロックのエクステント数４０６、トランザクションにて更新されたメタデータのブロック番号４０７、および、トランザクションにて確保あるいは開放されたブロックのエクステント情報４０８が記録される。
確保／開放ブロックのエクステント数４０６と実際のエクステント情報一覧４０８は、図３に示す変形例の場合に記録される。図１に示す構成では、スペースビットマップ領域２０１がメタデータ領域２００に含まれるため、本トランザクションにて確保あるいは開放されるブロックのエクステント情報４０８を記録しない。また、エクステント数４０６にはゼロを記録する。
なお、本実施例において、更新されたスペースビットマップの情報そのものを記録するようにしてもよい。

図５は、図４に示すトランザクションにて確保あるいは開放したブロックのエクステント情報４０８を示す図である。本情報は、図３に示す変形例の場合に記録する。
図５において、５００は前記トランザクションにて確保あるいは開放したブロックのエクステント情報フォーマット、５０１はブロック番号、５０２はブロック数、５０３はブロック操作の種別を示す。
図５に示すように、更新されたスペースビットマップの情報は、ブロック番号５０１、ブロック数５０２、及びブロック操作種別（確保または開放）５０３を用いて表される。一連のファイル操作で、同じブロックの確保と開放が繰り返されている場合は、最後に行ったブロック操作種別ではなく、初期状態からのブロック操作種別を記録する。
例えば、ブロック番号１０から１５が使用されていない状態だとし、あるファイル操作によって、ブロック番号１０から１５が確保され、次のファイル操作によって、ブロック番号１４から１５が開放された場合、トランザクションのコミット処理で、ブロック番号が“１０”、ブロック数が“４”、ブロック操作種別が“確保”というエクステント情報をタイプ１のトランザクションデータと一緒にジャーナルログに記録する。
前述したように初期状態からのブロック操作を前記エクステント情報４０８に記録することによって、障害回復処理では、前記ブロック操作をロールバックワードあるいロールフォーワードすることが可能となる。

図６は、本実施例のトランザクションタイプ２のジャーナルログデータフォーマットを示す図である。図６において、６００はトランザクションタイプ２のジャーナルログデータ全体のフォーマット、６０１は本トランザクションを記録する日時、６０２はトランザクションタイプ２、６０３は本トランザクションデータのチェックサム、６０４は本トランザクションの番号を示す。
図７は、本実施例のトランザクションタイプ３のジャーナルログデータフォーマットを示す図である。図７において７００はトランザクションタイプ３のジャーナルログデータ全体のフォーマット、７０１は本トランザクションを記録する日時、７０２はトランザクションタイプ３、７０３は本トランザクションデータのチェックサム、７０４は本トランザクションの番号を示す。
図６と図７に示すように、これらのデータフォーマットはデータ部分を持たない前記トランザクションタイプ１のジャーナルログと同じフォーマットである。トランザクションタイプ２のジャーナルログはセカンダリメタデータの更新が完了した時点で、トランザクションタイプ３のジャーナルログは、プライマリメタデータの更新が完了した時点、それぞれ前記ジャーナルログに追記する。
障害回復処理の一例では、前記ジャーナルログに記録された最終ジャーナルログのトランザクションタイプを判定し、最終ログがトランザクションタイプ１の場合、セカンダリメタデータの更新が完了していないと判断し、プライマリメタデータを用いてメタデータを修復する（ロールバックワード）。
最終ログがトランザクションタイプ２の場合は、プライマリメタデータの更新が完了していないと判断し、セカンダリメタデータを用いてメタデータを修復する（ロールフォーワード）。
なお、図３に示す変形例の場合は、前述したように、確保／開放ブロックのエクステント情報４０８を用いて、同様にスペースビットマップのロールバックワードかロールフォーワードを行う。

次に、図８と図９を用いて、メタデータの更新及びジャーナルログの記録手順、そしてジャーナルログを用いた障害回復手順の詳細について説明する。
まず、図８は、本実施例のメタデータの更新及びジャーナルログの記録手順を示すフローチャートである。
初めに、アプリケーションからのファイル操作に対して、必要に応じてファイルシステムが管理するキャッシュメモリ上でメタデータの更新処理を行う（ステップ８０２）
例えば、ファイルを新規作成する操作では、ファイルエントリ用のブロックを確保（スペースビットマップを更新）し、当該ファイルのメタデータを書き込み、当該ファイルを親ディレクトリに登録するために親ディレクトリのメタデータを更新する必要がある。
これらのメタデータの更新が全て完了してから、更新されたメタデータに基づいてタイプ１のトランザクションデータを作成しジャーナルログ領域８０１に記録する処理を行う（ステップ８０３）。
タイプ１のトランザクションデータの記録が完了したら、先にセカンダリメタデータ領域の更新処理を行う（ステップ８０４）。
セカンダリメタデータの更新が完了したら、ジャーナルログ領域８０１にタイプ２のトランザクションデータを追記する処理を行う（ステップ８０５）。
次に、プライマリメタデータの更新処理（ステップ８０６）、タイプ３のトランザクションデータを追記する処理を行う（ステップ８０７）。
前述のタイプ１のトランザクションデータを記録する処理（ステップ８０３）からタイプ３のトランザクションデータを記録する処理（ステップ８０７）は、通常コミット処理と呼ぶ。
コミット処理では、前述した手順の順序通りに行うことで、障害が発生した際に、ジャーナルログの状態を判定し、アプリケーションのファイル操作を完全にロールバックワードまたはロールフォーワードすることが可能となる。
すなわち、障害が発生した際に、最終ログがタイプ１のトランザクションデータの場合、ロールバックワード処理が必要、最終ログがタイプ２のトランザクションデータの場合、ロールフォーワード処理が必要と判断できる。なお、トランザクションログがない場合、あるいは、最終ログがタイプ３のトランザクションデータの場合は、修復する必要がない。
コミット処理は、前述したように、ひとつのファイル操作が完了してからすぐに実行する方法と、性能劣化を最小限に抑えるために、例えば、一定時間間隔で複数のファイル操作が完了してから実行する方法がある。
コミット処理が完了してから、次のトランザクションのために、トランザクション番号をインクリメントする処理を行う（ステップ８０８）。

図９は、本実施例において、図８に示すメタデータの更新及びジャーナルログの記録手順を採用した場合における障害回復の手順を示すフローチャートである。
障害回復は、ファイルシステムが初めてボリュームをマウントする際に、ジャーナルログの解析処理（ステップ９０１）を行い、ステップ９０１での解析結果、ジャーナルログに有効なデータが存在しない、または最終ログがタイプ３のトランザクションデータかを判定する処理（ステップ９０２）によって、障害があったかどうかを判断することが可能となる。
言い換えれば、最終ログがタイプ１またはタイプ２のトランザクションデータ（ステップ９０２でＮの場合）であれば、障害があったと判断することが可能となる。障害がなかった場合（ステップ９０２でＹ）は、通常のマウント処理（ステップ９０７）を行う。
障害があった場合は、最終ログがタイプ１またはタイプ２のトランザクションデータの判別処理（ステップ９０３）を行う。
最終ログがタイプ２のトランザクションデータの場合（ステップ９０３でＮ）は、セカンダリメタデータを用いて、プライマリメタデータを修復する処理（ロールフォーワード；ステップ９０４）を実行する。
最終ログがタイプ１のトランザクションデータの場合（ステップ９０３でＹ）は、プライマリメタデータを用いて、セカンダリメタデータを修復する処理（ロールバックワード；ステップ９０５）を実行する。
前述した修復処理が完了したら、タイプ３のトランザクションデータをジャーナルログに追記する処理（ステップ９０６）を行い、最後に通常マウント処理（ステップ９０７）を実行する。

次に、図１０と図１１を用いて、メタデータの更新及びジャーナルログの記録手順の変形例、そしてジャーナルログを用いた障害回復手順の変形例の詳細について説明する。
まず、図１０は、本実施例のメタデータの更新及びジャーナルログの記録手順の変形例を示すフローチャートである。
図１０に示す変形例でも、初めに、アプリケーションからのファイル操作に対して、必要に応じてファイルシステムが管理するキャッシュメモリ上でメタデータの更新処理を行い（ステップ８２２）、更新されたメタデータに基づいてタイプ１のトランザクションデータを作成しジャーナルログ領域８０１に記録する処理を行う（ステップ８２３）。
しかしながら、図１０に示す変形例では、タイプ１のトランザクションデータの記録が完了したら、先にプライマリメタデータ領域の更新処理を行う（ステップ８２４）。
プライマリメタデータの更新が完了したら、ジャーナルログ領域８０１にタイプ２のトランザクションデータを追記する処理を行う（ステップ８２５）。
次に、セカンダリメタデータの更新処理（ステップ８２６）、タイプ３のトランザクションデータを追記する処理を行う（ステップ８２７）。
コミット処理が完了してから、次のトランザクションのために、トランザクション番号をインクリメントする処理を行う（ステップ８２８）。

図１１は、本発明の実施例のジャーナルログ記録制御方法において、図１０に示すメタデータの更新及びジャーナルログの記録手順を採用した場合における障害回復の手順を示すフローチャートである。
図１１に示す例でも、障害回復は、ファイルシステムが初めてボリュームをマウントする際に、ジャーナルログの解析処理（ステップ９１１）を行い。
また、図１１に示す例でも、ステップ９１１での解析結果、ジャーナルログに有効なデータが存在しない、または最終ログがタイプ３のトランザクションデータかを判定する処理（ステップ９１２）によって、障害があったかどうかを判断する。
言い換えれば、最終ログがタイプ１またはタイプ２のトランザクションデータ（ステップ９１２でＮの場合）であれば、障害があったと判断することが可能となる。障害がなかった場合（ステップ９１２でＹ）は、通常のマウント処理（ステップ９１７）を行う。
障害があった場合は、最終ログがタイプ１またはタイプ２のトランザクションデータの判別処理（ステップ９１３）を行う。
しかしながら、図１１に示す例では、最終ログがタイプ２のトランザクションデータの場合（ステップ９１３でＮ）は、プライマリメタデータを用いて、セカンダリメタデータを修復する処理（ロールフォーワード；ステップ９１４）を実行する。
逆に、最終ログがタイプ１のトランザクションデータの場合（ステップ９１３でＹ）は、セカンダリメタデータを用いて、プライマリメタデータを修復する処理（ロールバックワード；ステップ９１５）を実行する。
前述した修復処理が完了したら、タイプ３のトランザクションデータをジャーナルログに追記する処理（ステップ９１６）を行い、最後に通常マウント処理（ステップ９１７）を実行する。
なお、前述の説明において、ジャーナルログは同じ磁気ディスクではなく、別の磁気ディスク、あるいはフラッシュメモリ等に記録するようにしてもよい。
さらに、ジャーナルログには更新されたメタデータを特定できるブロック番号を記録する代わりにメタデータを特定できるユニークな識別子を用いるようにしてもよい。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

本発明の実施例のファイルシステムのボリュームの概略構成を示すブロック図である。 本発明の実施例のメタデータ領域の概略構成を示すブロック図である。 本発明の実施例のファイルシステムのボリュームの変形例の概略構成を示すブロック図である。 本発明の実施例のトランザクションタイプ１のジャーナルログデータフォーマットを示す図である。 図４に示すトランザクションにて確保あるいは開放したブロックのエクステント情報を示す図である。 本発明の実施例のトランザクションタイプ２のジャーナルログデータフォーマットを示す図である。 本発明の実施例のトランザクションタイプ３のジャーナルログデータフォーマットを示す図である。 本発明の実施例のメタデータの更新及びジャーナルログの記録手順を示すフローチャートである。 本発明の実施例のジャーナルログ記録制御方法において、図８に示すメタデータの更新及びジャーナルログの記録手順を採用した場合における障害回復の手順を示すフローチャートである。 本発明の実施例のメタデータの更新及びジャーナルログの記録手順の変形例を示すフローチャートである。 本発明の実施例のジャーナルログ記録制御方法において、図１０に示すメタデータの更新及びジャーナルログの記録手順を採用した場合における障害回復の手順を示すフローチャートである。

符号の説明

１００，３００ ボリューム全体
１０１ プライマリメタデータ領域
１０２ データ領域
１０３，３０４ ジャーナルログ領域
１０４ セカンダリメタデータ領域
２００ メタデータ領域
２０１ スペースビットマップ領域
２０２ メタデータ
３０１ スペースビットマップ領域
３０２ プライマリメタデータ領域
３０３ データ領域
３０５ セカンダリメタデータ領域
４００ トランザクションタイプ１のジャーナルログデータフォーマット
４０１，６０１，７０１ トランザクション日時
４０２，６０２，７０２ トランザクションタイプ
４０３，６０３，７０３ チェックサム
４０４，６０４，７０４ トランザクション番号
４０５ 更新されたメタデータブロック数
４０６ 確保／開放ブロックのエクステント数
４０７ 更新されたメタデータのブロック番号
４０８ 確保／開放ブロックのエクステント情報
５００ 確保／開放ブロックのエクステント情報
５０１ ブロック番号
５０２ ブロック数
５０３ ブロック操作種別
６００ トランザクションタイプ２のジャーナルログデータフォーマット
７００ トランザクションタイプ３のジャーナルログデータフォーマット
８０１ ジャーナルログ
８０９ タイプ１のトランザクションデータが記録される状態
８１０ タイプ２のトランザクションデータが記録される状態
８１１ タイプ３のトランザクションデータが記録される状態

Claims (6)

1. プライマリメタデータと、メタデータのバックアップであるセカンダリメタデータと、ジャーナルログとを記録手段に記録し、前記セカンダリメタデータあるいは前記プライマリメタデータをジャーナルログとともに障害回復に利用するジャーナルファイルシステムにおけるジャーナルログ記録制御方法であって、
   前記セカンダリメタデータを先に更新してから前記プライマリメタデータを更新するとともに、前記ジャーナルログには更新されたメタデータを特定できるブロック番号あるいはセクタ番号のみを記録し、
   前記障害回復時に、前記ジャーナルログの状態により、前記プライマリメタデータを用いて前記セカンダリメタデータをファイル操作前の状態に戻す、あるいは、前記セカンダリメタデータを用いて前記プライマリメタデータをファイル操作後の状態に更新することを特徴とするジャーナルログ記録制御方法。
2. プライマリメタデータと、メタデータのバックアップであるセカンダリメタデータと、ジャーナルログとを記録手段に記録し、前記セカンダリメタデータあるいは前記プライマリメタデータをジャーナルログとともに障害回復に利用するジャーナルファイルシステムにおけるジャーナルログ記録制御方法であって、
   前記プライマリメタデータを先に更新してから前記セカンダリメタデータを更新するとともに、前記ジャーナルログには更新されたメタデータを特定できるブロック番号あるいはセクタ番号のみを記録し、
   前記障害回復時に、前記ジャーナルログの状態により、前記セカンダリメタデータを用いて前記プライマリメタデータをファイル操作前の状態に戻す、あるいは、前記プライマリメタデータを用いて前記セカンダリメタデータをファイル操作後の状態に更新することを特徴とするジャーナルログ記録制御方法。
3. 前記プライマリメタデータおよび前記セカンダリメタデータに、ブロック使用状態を示すスペースビットマップが含まれない場合、前記スペースビットマップの更新内容を前記ジャーナルログに追記し、前記スペースビットマップの更新内容を用いて前記スペースビットマップを修復することを特徴する請求項１または請求項２に記載のジャーナルログ記録制御方法。
4. 前記スペースビットマップの更新内容を前記ジャーナルログに記憶する代わりに、更新されたスペースビットマップそのものを前記ジャーナルログに追記することを特徴とする請求項３に記載のジャーナルログ記録制御方法。
5. 前記ジャーナルログを同じ記録手段ではなく、別の記録手段に記録することを特徴とする請求項１から請求項４のいずれか１項に記載のジャーナルログ記録制御方法。
6. 前記ブロック番号の代わりにメタデータを特定できるユニークな識別子を用いることを特徴とする請求項１ないし請求項５のいずれか１項に記載のジャーナルログ記録制御方法。

Images