(57)【要約】【課題】ファイルシステム検証の長期化を抑止する。【解決手段】情報処理装置ＣＰは、特定手段６と検証手段７とを有する。特定手段６は、ファイルシステムで管理される管理対象情報と、該管理対象情報の管理に使用する管理情報とを格納するボリューム１内の、複数の単位記憶領域１ａのうち、所定期間内に情報の更新が行われた単位記憶領域を特定する。検証手段７は、特定した単位記憶領域内の情報を用いて、ファイルシステムにおける管理対象情報と管理情報との整合性を検証する。【選択図】図１
2014182417.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置が、
ファイルシステムで管理される管理対象情報と、該管理対象情報の管理に使用する管理情報とを格納するボリューム内の、複数の単位記憶領域のうち、所定期間内に情報の更新が行われた単位記憶領域を特定し、
特定した前記単位記憶領域内の情報を用いて、前記ファイルシステムにおける管理対象情報と管理情報との整合性を検証する、
ファイルシステム検証方法。
【請求項２】
整合性の検証では、
前記所定期間内に情報の更新が行われた単位記憶領域に、前記所定期間の開始時に格納されていた第１の情報と、前記所定期間の終了時に該単位記憶領域に格納されていた第２の情報とを取得し、
前記第１の情報と前記第２の情報とに基づいて、管理対象情報の前記所定期間内での変化と、該管理対象情報に関する管理情報の前記所定期間内での変化との間の整合性を検証する、
ことを特徴とする請求項１記載のファイルシステム検証方法。
【請求項３】
整合性の検証では、管理情報の管理対象情報への割当の有無を示す第１の割当情報の、前記所定期間内での変化と、該管理情報の前記所定期間内での変化との整合性を検証する、
ことを特徴とする請求項１または２記載のファイルシステム検証方法。
【請求項４】
整合性の検証では、単位記憶領域の管理対象情報への割当の有無を示す第２の割当情報の、前記所定期間内での変化と、管理情報に基づく単位記憶領域の管理対象情報への割当の、前記所定期間内での変化との整合性を検証する、
ことを特徴とする請求項１乃至３のいずれかに記載のファイルシステム検証方法。
【請求項５】
整合性の検証では、管理対象情報に割り当てられた単位記憶領域の、前記所定期間内での変化と、該管理対象情報の管理情報に示される該管理対象情報に割り当てられている単位記憶領域数の、前記所定期間内での変化との整合性を検証する、
ことを特徴とする請求項１乃至４のいずれかに記載のファイルシステム検証方法。
【請求項６】
整合性の検証では、ディレクトリへのファイルのエントリの、前記所定期間内での変化に基づく、ファイルが属しているディレクトリの数の変化と、該ファイルの管理情報に設定されている、該ファイルが属しているディレクトリ数の、前記所定期間内での変化との整合性を検証する、
ことを特徴とする請求項１乃至５のいずれかに記載のファイルシステム検証方法。
【請求項７】
前記所定期間内に単位記憶領域内の情報の更新が行われると、前記ボリュームを有するストレージ装置または前記情報処理装置が、該単位記憶領域内の情報が更新されたことを更新領域情報に記録し、
単位記憶領域の特定では、前記更新領域情報を参照することで、所定期間内に情報の更新が行われた単位記憶領域と特定する、
ことを特徴とする請求項１乃至６のいずれかに記載のファイルシステム検証方法。
【請求項８】
前記所定期間内に単位記憶領域内の情報の更新が行われると、前記ボリュームを有するストレージ装置または前記情報処理装置が、該単位記憶領域内の更新前の情報を記憶手段に格納し、
整合性の検証では、前記記憶手段に格納された更新前の情報と、前記ボリュームに格納された更新後の情報との比較結果に基づいて、整合性を検証する、
ことを特徴とする請求項１乃至７のいずれかに記載のファイルシステム検証方法。
【請求項９】
更新された単位記憶領域の数が所定値を超えたときに、整合性の検証を行う、
ことを特徴とする請求項１乃至８のいずれかに記載のファイルシステム検証方法。
【請求項１０】
情報処理装置に、
ファイルシステムで管理される管理対象情報と、該管理対象情報の管理に使用する管理情報とを格納するボリューム内の、複数の単位記憶領域のうち、所定期間内に情報の更新が行われた単位記憶領域を特定し、
特定した前記単位記憶領域内の情報を用いて、前記ファイルシステムにおける管理対象情報と管理情報との整合性を検証する、
処理を実行させるファイルシステム検証プログラム。
【請求項１１】
ファイルシステムで管理される管理対象情報と、該管理対象情報の管理に使用する管理情報とを格納するボリューム内の、複数の単位記憶領域のうち、所定期間内に情報の更新が行われた単位記憶領域を特定する特定手段と、
特定した前記単位記憶領域内の情報を用いて、前記ファイルシステムにおける管理対象情報と管理情報との整合性を検証する検証手段と、
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステムの整合性をチェックするファイルシステム検証方法、ファイルシステム検証プログラム、および情報処理装置に関する。
【背景技術】
【０００２】
コンピュータに接続されるストレージ装置には、１または複数のボリュームが設けられる。ボリュームは、記憶媒体の管理単位である。ボリュームへのデータの入出力は、ファイルシステムによって管理される。ファイルシステムは、例えばファイルごとの管理情報（メタデータ）を有している。管理情報には、例えばコンピュータで作成されたファイルに対応付けて、そのファイルに含まれるデータの、ボリューム内での格納場所が設定されている。コンピュータ上のアプリケーションソフトウェアなどからファイルシステムに、ファイルを指定したアクセス要求が出されると、ファイルシステムは、そのファイルの管理情報に基づいて、指定されたファイルに対応付けられた格納場所のデータにアクセスする。これにより、アプリケーションソフトウェアは、ボリューム内の所望のデータにアクセスすることができる。
【０００３】
コンピュータがボリューム内のデータに正しくアクセスするには、ファイルシステムが有している管理情報と、ボリュームに格納されているデータとの整合性がとれていることが重要である。ところが、コンピュータの運用中に、ファイルシステムの管理情報と、ボリュームに格納されているデータとの間に、不整合が生じることがある。例えば、ソフトウェアまたはハードウェアの誤動作により管理情報が破壊されると、ファイルシステムの管理情報とボリューム内のデータとの間に不整合が生じる。ファイルシステムの不整合が長期にわたって放置された後のＩ／Ｏ（Input/Output）エラーなどで不整合が検出されたのでは、既に、管理情報の修復が困難な状態になっていることもある。そこでコンピュータの動作の信頼性を高めるために、ファイルシステム整合性チェック（ＦＳＣＫ）と呼ばれる処理により、定期的にファイルシステムの不整合の有無が探査される。
【０００４】
ＦＳＣＫは、チェック対象のファイルシステムの管理情報を読み出し、ボリューム内のデータとの整合性をチェックするものである。ボリューム全体に対するＦＳＣＫによる不整合の探査では、大量の管理情報の読み出しが行われる。そのため、ＦＳＣＫには膨大な処理時間を要する。しかも、近年の電子データの増大に伴って、企業で運用されるコンピュータシステムのボリュームの規模が増大している。その結果、実運用上問題のない時間内（例えば、夜間のバッチ処理用の時間帯）に、ＦＳＣＫを処理し終えることが困難になってきている。
【０００５】
そこでペタバイト級の巨大なファイルシステムでのＦＳＣＫを不要化または高速化する技術が考えられている。例えば、ファイルシステムを、小規模の複数のファイルシステムに分割することが考えられている。また、ファイルシステムでジャーナリングを行うことも考えられている。ジャーナリングとは、障害発生時の復旧用に、ファイル更新履歴を保持・管理する機能である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Val Henson, Arjan van de Ven, Amit Gud, Zach Brown,"Chunkfs: Using divide-and-conquer to improve file system reliability and repair" HOTDEP'06 Proceedings of the 2nd conference on Hot Topics in System Dependability - Volume 2, Pages 7-7, 2006
【非特許文献２】Stephen C. Tweedie "Journaling the Linux ext2fs Filesystem" Proceedings of the 4th Annual LinuxExpo, Durham, NC,1998
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、従来の技術は、ＦＳＣＫの実行時間の長期化を、十分に抑止することができない。
例えば、ファイルシステムを小規模のファイルシステムに分割する技術は、小規模のファイルシステムの集合での運用が許容できるシステムに限定される。しかも、多数ファイルシステムのＦＳＣＫを並列実行すると、それによるサーバメモリの枯渇の恐れがあり、小規模化にも限界がある。そのため、ある程度以上にボリュームの規模が増大すると、ＦＳＣＫの長期化を抑止できなくなる。
【０００８】
また、ジャーナリングを用いれば、ファイルシステム不整合の一因となる突然停止の後でも、ジャーナル処理を続行することで不整合を高速に復旧することができる。これにより、ＦＳＣＫの必要性を軽減することができる。しかしながら、サーバのソフトウェアまたはハードウェアの誤動作によるファイルシステムの不整合の発生の可能性が残り、ジャーナリングを用いたとしても、完全にＦＳＣＫを不要なものとすることはできない。
【０００９】
１つの側面では、本発明は、ファイルシステム整合性チェックの長期化を抑止することができるファイルシステム検証方法、ファイルシステム検証プログラム、および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
１つの案では、情報処理装置が、ファイルシステムで管理される管理対象情報と、該管理対象情報の管理に使用する管理情報とを格納するボリューム内の、複数の単位記憶領域のうち、所定期間内に情報の更新が行われた単位記憶領域を特定し、特定した単位記憶領域内の情報を用いて、ファイルシステムにおける管理対象情報と管理情報との整合性を検証する、ファイルシステム検証方法が提供される。
【発明の効果】
【００１１】
１態様によれば、ファイルシステム検証の長期化を抑止することができる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態に係る情報処理装置の機能構成の一例を示す図である。
【図２】第２の実施の形態のシステム構成の一例を示す図である。
【図３】第２の実施の形態に用いるサーバのハードウェアの一構成例を示す図である。
【図４】第２の実施の形態に用いるストレージ装置のハードウェア構成の一例を示す図である。
【図５】第２の実施の形態における整合性チェック機能を示すブロック図である。
【図６】ストレージ装置で管理される情報の一例を示す図である。
【図７】ファイルシステムボリューム領域の詳細を示す図である。
【図８】ファイルシステムボリューム領域内の情報間の関係を示す図である。
【図９】ブロック更新差分管理方法の一例を示す図である。
【図１０】ＷＢＭＡＰのデータ構造の一例を示す図である。
【図１１】ＦＳＣＫの処理手順の一例を示すフローチャートである。
【図１２】更新差分ＦＳＣＫ処理の手順の一例を示すフローチャートである。
【図１３】ファイル割当チェック処理の一例を示すフローチャートの前半である。
【図１４】キャッシュされたブロックとキャッシュテーブルの一例を示す図である。
【図１５】ファイル割当チェック処理の一例を示すフローチャートの後半である。
【図１６】ＶＢＭＡＰの一例を示す図である。
【図１７】ＶＦＢＭＡＰの一例を示す図である。
【図１８】ブロック割当チェック処理の手順の一例を示すフローチャートの前半である。
【図１９】ブロック割当チェック処理の手順の一例を示すフローチャートの後半である。
【図２０】ディレクトリ構成チェック処理の手順の一例を示すフローチャートの前半である。
【図２１】ディレクトリ構成チェック処理の手順の一例を示すフローチャートの後半である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る情報処理装置の機能構成の一例を示す図である。情報処理装置ＣＰは、ボリューム１、更新前情報格納手段２、更新領域記録手段３、更新前情報記憶手段４、更新領域情報記憶手段５、特定手段６、および検証手段７を有する。
【００１４】
ボリューム１は、ファイルシステムで管理される管理対象情報と、管理対象情報の管理に使用する管理情報とを格納する記憶領域である。ボリューム１には、複数の単位記憶領域１ａが設けられている。単位記憶領域１ａは、例えばブロックと呼ばれる記憶領域である。
【００１５】
更新前情報格納手段２は、所定期間内に単位記憶領域内の情報の更新が行われると、情報が更新された単位記憶領域内の更新前の情報を、更新前情報記憶手段４に格納する。ここで、所定期間は、例えば、ＦＳＣＫを実行後、現在までの期間である。
【００１６】
更新領域記録手段３は、所定期間内に単位記憶領域内の情報の更新が行われると、その単位記憶領域内の情報が更新されたことを更新領域情報５ａに記録する。例えば更新領域情報５ａには、複数の単位記憶領域１ａそれぞれに対応するビットが設けられており、各ビットの値が、対応する単位記憶領域の更新の有無を示す。この場合、更新領域記録手段３は、更新領域情報５ａ内の、情報が更新された単位記憶領域に対応するビットの値を、更新有りを示す値に変更する。
【００１７】
更新前情報記憶手段４は、更新前情報を記憶する。更新領域情報記憶手段５は、更新領域情報５ａを記憶する。
特定手段６は、ボリューム１内の複数の単位記憶領域１ａのうち、所定期間内に情報の更新が行われた単位記憶領域を特定する。例えば特定手段６は、更新領域情報５ａを参照し、更新領域情報５ａにおいて、対応するビットが更新済みとなっている単位記憶領域を、所定期間内に情報の更新が行われた単位記憶領域であると特定する。
【００１８】
検証手段７は、特定手段６が特定した単位記憶領域内の情報に関して、ファイルシステムにおける管理対象情報と管理情報との整合性をチェックする。例えば検証手段７は、更新された単位記憶領域の数が所定値を超えたときに、整合性の検証（チェック）を行う。管理対象情報は、例えばディレクトリやファイルである。なおディレクトリは、フォルダと呼ばれることもある。管理情報は、例えばメタデータと呼ばれる情報である。メタデータの一例としては、inodeがある。なおチェックされる整合性には、管理対象情報と管理情報との間での整合性に加え、複数の管理情報間での整合性も含まれる。
【００１９】
例えば検証手段７は、所定期間内に情報の更新が行われた単位記憶領域に、所定期間の開始時に格納されていた、更新前の情報８ａを、更新前情報記憶手段４から取得する。また検証手段７は、所定期間の終了時に該単位記憶領域に格納されていた更新後の情報８ｂを、ボリューム１から取得する。そして検証手段７は、更新前の情報８ａと更新後の情報８ｂとに基づいて、管理対象情報の所定期間内での変化と、その管理対象情報に関する管理情報の所定期間内での変化との間の整合性をチェックする。
【００２０】
なお検証手段７は、複数の観点から整合性のチェックを行うことができる。様々な観点で整合性をチェックするため、検証手段７は、ファイル割当検証手段７ａ、ブロック割当検証手段７ｂ、およびディレクトリ構成検証手段７ｃを有する。
【００２１】
ファイル割当検証手段７ａは、管理情報の管理対象情報（ディレクトリまたはファイル）への割当の有無を示す第１の割当情報の、所定期間内での変化と、その管理情報の所定期間内での変化との整合性をチェックする。例えば複数の管理情報それぞれに識別番号が付与されている。そして第１の割当情報では、管理情報の識別番号に対応付けて、その管理情報に対応する管理対象情報が存在するか否かが設定されている。このような第１の割当情報は、管理対象情報の新規作成や削除に伴って変化する。また管理対象情報の新規作成や削除が行われると、例えばその管理対象情報に対応する管理情報のタイプが変更される。そこでファイル割当検証手段７ａは、管理情報の変化と、その管理情報への管理対象情報の割当の有無を示す第１の割当情報の変化との整合性をチェックし、不整合があれば、エラーを出力する。
【００２２】
ブロック割当検証手段７ｂは、単位記憶領域１ａの管理対象情報への割当の有無を示す第２の割当情報の、所定期間内での変化と、管理情報に基づく単位記憶領域１ａの管理対象情報への割当の、所定期間内での変化との整合性をチェックする。例えば第２の割当情報では、複数の単位記憶領域１ａそれぞれに対応付けて、単位記憶領域１ａが、管理対象情報内のデータの格納領域として、管理対象情報に割り当てられているか否かを示すビットが設けられている。管理対象情報への単位記憶領域の新規割当、または単位記憶領域の割当解除が行われると、その単位記憶領域に対応する、第２の割当情報内のビットの値が変化する。また管理対象情報への単位記憶領域の新規割当、または単位記憶領域の割当解除が行われた場合、その管理対象情報に対応する管理情報において、割り当てられている単位記憶領域に関する情報が変更される。そこでブロック割当検証手段７ｂは、第２の割当情報の所定期間内での変化と、管理情報に基づく単位記憶領域１ａの管理対象情報への割当の変化との整合性をチェックし、不整合があれば、エラーを出力する。
【００２３】
またブロック割当検証手段７ｂは、管理対象情報に割り当てられた単位記憶領域の、所定期間内での変化と、その管理対象情報の管理情報に示される、その管理対象情報に割り当てられている単位記憶領域数の、所定期間内での変化との整合性をチェックする。例えば管理対象情報の管理情報には、その管理対象情報に対して、データの格納領域として割り当てられた単位記憶領域の情報と、割り当てられた単位記憶領域の数を示す情報とが含まれる。管理対象情報に対する単位記憶領域の新規割当が行われるか、または割当が解除されると、管理情報において、管理対象情報に割り当てられた単位記憶領域の情報が更新される。また管理対象情報に対する単位記憶領域の新規割当が行われるか、または割当が解除された場合、管理情報において、管理対象情報に割り当てられた権利記憶領域の数も更新される。そこでブロック割当検証手段７ｂは、管理対象情報に割り当てられた単位記憶領域の変化と、その管理対象情報の管理情報に示される、割り当てられている単位記憶領域数の変化との整合性をチェックし、不整合があれば、エラーを出力する。
【００２４】
ディレクトリ構成検証手段７ｃは、ディレクトリへのファイルのエントリの、所定期間内での変化に基づく、ファイルが属しているディレクトリの数を算出する。またディレクトリ構成検証手段７ｃは、ファイルの管理情報に設定されている、そのファイルが属しているディレクトリ数の、所定期間内での変化を算出する。そしてディレクトリ構成検証手段７ｃは、ディレクトリへのファイルのエントリに基づく、ファイルが属しているディレクトリの数と、ファイルの管理情報に基づく、ファイルが属しているディレクトリの数との整合性をチェックする。ディレクトリ構成検証手段７ｃは、整合性のチェックの結果、不整合があれば、エラーを出力する。
【００２５】
このような情報処理装置ＣＰによれば、ボリューム１内の管理対象情報が更新されると、その管理対象情報に対応する管理情報も更新される。すると、更新された管理対象情報や管理情報が格納された単位記憶領域の、更新前の情報が、更新前情報記憶手段４に格納される。また更新された単位記憶領域を示す情報が、更新領域情報５ａに設定される。
【００２６】
ここで、第１の実施の形態では、ある時点において、ボリューム１のファイルシステムの整合性がとれていることが確認できているものとする。そして第１の実施の形態では、所定の間隔で、ファイルシステムの整合性のチェックを実行する。例えば、前回のファイルシステムの整合性チェック後に更新された単位記憶領域の数が所定数を超えると、ファイルシステムの整合性チェックが開始される。ファイルシステムの整合性チェックが開始されると、特定手段６によって、前回のファイルシステムの整合性チェック後に更新された単位記憶領域が特定される。そして、検証手段７により、特定手段６が特定した単位記憶領域内の情報に関して、管理対象情報と、その管理対象情報に関する管理情報との間の整合性がチェックされる。例えば検証手段７は、特定された単位記憶領域の更新前の情報８ａと更新後の情報８ｂとを取得し、それらの情報を比較することで、前回のファイルシステムの整合性チェック後の情報の変化を認識する。そして検証手段７により、管理対象情報の変化と、管理情報との変化の整合性が合っているか否かが判断される。前回のファイルシステムの整合性チェックにおいて全体の整合性が合っていることが確認できており、その後の変化内容の整合性が合っていることが確認できれば、全体の整合性も合っていると判断できる。
【００２７】
このように、第１の実施の形態では、ボリューム１において、前回のファイルシステムの整合性チェック後に更新された単位記憶領域の情報を用いて、ファイルシステムの整合をチェックする。このような更新された情報のみをチェック対象としてファイルシステムの整合性をチェックすれば、チェックに用いる情報量が削減できる。その結果、ファイルシステムの整合性チェックに要する時間も短縮できる。しかも、更新された情報の情報量は、ボリューム１のサイズに直接的に依存するものではない。そのため、ボリューム１のサイズの増大に伴う、ファイルシステムの整合性のチェック時間の長期化を抑制することができる。
【００２８】
なお、ボリューム１のサイズが増大すれば、多くの場合、ファイルシステム内の情報の更新頻度も高頻度となる。その場合、ファイルシステムの整合性をチェックする間隔を短くすることで、１回当たりのファイルシステム整合性チェック時間の長期化を抑止できる。
【００２９】
なお、更新前情報格納手段２、更新領域記録手段３、特定手段６、および検証手段７は、例えば情報処理装置ＣＰが有するプロセッサにより実現することができる。また、ボリューム１、更新前情報記憶手段４、および更新領域情報記憶手段５は、例えば情報処理装置ＣＰが有するハードディスク装置などの記憶媒体により実現することができる。
【００３０】
また、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
第２の実施の形態は、ファイルシステムの更新差分の管理をストレージ装置内で行うようにしたものである。第２の実施の形態における更新差分とは、前回のＦＳＣＫ後に更新された情報である。
【００３１】
図２は、第２の実施の形態のシステム構成の一例を示す図である。第２の実施の形態では、サーバ１００に接続されたストレージ装置２００が設けられている。サーバ１００は、ファイルシステムによりストレージ装置２００内のボリュームを管理するコンピュータである。またサーバ１００はネットワーク１０を介して端末装置２１，２２に接続されている。端末装置２１，２２は、ネットワーク１０を介してサーバ１００にアクセスし、ストレージ装置２００に格納されたデータにアクセスできる。
【００３２】
図３は、第２の実施の形態に用いるサーバのハードウェアの一構成例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１００ａを介してＲＡＭ（Random Access Memory）１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１の機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００３３】
ＲＡＭ１０２は、サーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。
【００３４】
バス１００ａに接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７、ネットワークインタフェース１０８、およびストレージインタフェース１０９がある。
【００３５】
ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。
【００３６】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００３７】
入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００３８】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００３９】
機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置１５やメモリリーダライタ１６を接続することができる。メモリ装置１５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ１６は、メモリカード１７へのデータの書き込み、またはメモリカード１７からのデータの読み出しを行う装置である。メモリカード１７は、カード型の記録媒体である。
【００４０】
ネットワークインタフェース１０８は、ネットワーク１０に接続されている。ネットワークインタフェース１０８は、ネットワーク１０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００４１】
ストレージインタフェース１０９は、ストレージ装置２００に接続されている。ストレージインタフェース１０９は、ストレージ装置２００と通信し、ストレージ装置２００へのデータの書き込み、またストレージ装置２００からのデータの読み出しを行う。
【００４２】
以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置ＣＰも、図３に示したサーバ１００と同様のハードウェアにより実現することができる。
【００４３】
サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク１４、メモリ装置１５、メモリカード１７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００４４】
図４は、第２の実施の形態に用いるストレージ装置のハードウェア構成の一例を示す図である。ストレージ装置２００は、複数のＨＤＤ２１１，２１２，・・・、通信インタフェース（Ｉ／Ｆ）２２１、および制御モジュール（ＣＭ：Controller Module）２３０を有している。
【００４５】
ＨＤＤ２１１，２１２，・・・は、記憶装置の一例である。なおストレージ装置２００では、ＨＤＤ２１１，２１２，・・・に代えて、ＳＳＤ（Solid-State Drive）を使用することもできる。
【００４６】
通信インタフェース２２１は、サーバ１００と通信する。例えば通信インタフェース２２１は、サーバ１００から要求を受信し、受信した要求をＣＭ２３０に転送する。また通信インタフェース２２１は、要求に対する応答をＣＭ２３０から受け取り、その応答をサーバ１００に送信する。
【００４７】
ＣＭ２３０は、ストレージ装置２００内蔵のコンピュータであり、ストレージ装置２００内のＨＤＤなどの資源管理を行う。例えばＣＭ２３０には、ＨＤＤ２１１，２１２，・・・が接続されている。ＣＭ２３０は、接続されたＨＤＤ２１１，２１２，・・・で提供されるリソース（記憶機能）を管理する。ＣＭ２３０は、担当する複数のＨＤＤを組み合わせてＲＡＩＤ（Redundant Array of Inexpensive Disks）グループを生成し、生成したＲＡＩＤグループを論理的に１つのボリュームとすることができる。
【００４８】
ＣＭ２３０は、ＣＰＵ２３１、メモリ２３２、キャッシュメモリ２３３、および複数のＤＡ（Device Adapter）２３４，２３５，・・・を有する。ＣＭ２３０内の各構成要素は、ＣＭ２３０の内部バス２３９によって互いに接続されている。
【００４９】
ＣＰＵ２３１は、ＣＭ２３０全体を制御する。例えばＣＰＵ２３１は、通信インタフェース２２１から入力されるコマンド数を制限する。なおＣＭ２３０は、複数のＣＰＵを有していてもよい。その場合、複数のＣＰＵが連携してＣＭ２３０全体を制御する。
【００５０】
メモリ２３２は、ＣＭ２３０の制御に用いられる各種情報を記憶する。またメモリ２３２は、ＣＰＵ２３１に実行させる処理が記述されたプログラムも記憶する。メモリ２３２としては、例えばフラッシュメモリなどの不揮発性のメモリを使用することができる。
【００５１】
キャッシュメモリ２３３は、ＨＤＤ２１１，２１２，・・・に入出力するデータを一時的に保存するメモリである。ＤＡ２３４，２３５，・・・は、それぞれＨＤＤ２１１，２１２，・・・に接続され、接続されたＨＤＤへのデータの入出力を行う。
【００５２】
このようなハードウェア構成のシステムにおいて、ストレージ装置２００内のボリュームが、サーバ１００のファイルシステムで管理される。そして、ストレージ装置２００のハードウェア障害、またはサーバ１００におけるソフトウェアの異常などにより、ファイルシステムの管理情報と、ストレージ装置２００内のボリューム内のデータとの間で、不整合が生じる場合がある。そのような不整合を放置しないため、サーバ１００において、ＦＳＣＫが実行される。第２の実施の形態におけるＦＳＣＫでは、前回のＦＳＣＫの実行後に更新されたデータに関する整合性のチェックが行われる。
【００５３】
図５は、第２の実施の形態における整合性チェック機能を示すブロック図である。第２の実施の形態では、ストレージ装置２００において、ブロックの更新差分を管理する。サーバ１００は、ストレージ装置２００からブロックの更新差分の情報を取得して、前回のＦＳＣＫ後に更新された情報に関する整合性チェックを行う。
【００５４】
サーバ１００は、複数のアプリケーション１１１，１１２，１１３とファイルシステムドライバ（ＦＳＤ）１２０とを有している。
アプリケーション１１１，１１２，１１３は、端末装置２１，２２からの要求に応じて処理を実行する。アプリケーション１１１，１１２，１１３は、処理の実行過程で、例えばデータをストレージ装置２００から読み出す。またアプリケーション１１１，１１２，１１３は、処理の実行過程で、処理結果をストレージ装置２００に書き込むこともある。アプリケーション１１１，１１２，１１３による、ストレージ装置２００へのデータの書き込みや、ストレージ装置２００からのデータの読み出しは、ＦＳＤ１２０を介して行われる。
【００５５】
ＦＳＤ１２０は、ファイルシステムの処理を実行する。例えばＦＳＤ１２０は、ディレクトリやファイルに含まれるデータの格納場所を、管理情報により管理する。管理情報は、例えばinodeである。以下、inodeを管理情報として用いる場合の例を説明するが、inodeは管理情報の一例であり、ファイルシステムの管理情報としてinode以外の情報を用いることもできる。
【００５６】
ＦＳＤ１２０は、ストレージ装置２００内のＨＤＤ２１１〜２１４を用いて定義された論理ボリュームを管理する。例えばＦＳＤ１２０は、論理ボリュームのディレクトリ構造や、ディレクトリ内に格納されるファイルを管理する。ファイルは、例えばディレクトリ上の位置を示すパスとファイル名で一意に特定される。またＦＳＤ１２０は、ディレクトリやファイルそれぞれに対応するinodeを生成し、論理ボリューム内で管理する。ファイルに対応するinodeには、inode番号、そのファイルに含まれるデータの論理ボリューム内での格納場所となる論理ブロックのアドレス（ＬＢＡ：Logical Block Address）などの情報が設定されている。またディレクトリに対応するinodeには、そのディレクトリに属するファイルのファイル名、inode番号などの情報が設定される。
【００５７】
そしてＦＳＤ１２０は、所定のタイミングでＦＳＣＫを実行する。例えばＦＳＤ１２０は、予め設定された時刻にＦＳＣＫを実行することができる。またＦＳＤ１２０は、更新されたデータ量が所定の閾値以上となったときに、ＦＳＣＫを実行することもできる。このように、更新されたデータ量が閾値以上となったときにＦＳＣＫを実行するようにすれば、ＦＳＣＫにおける整合性の判断対象のデータ量が抑止される。その結果、ＦＳＣＫの処理時間が抑止される。
【００５８】
ＦＳＤ１２０は、ＦＳＣＫを実行する場合、ＦＳＣＫ実行部１３０を起動する。ＦＳＣＫ実行部１３０は、ＦＳＤ１２０に内蔵されていてもよく、ＦＳＤ１２０から呼び出し可能な外部機能として設けられていてもよい。
【００５９】
ＦＳＣＫ実行部１３０は、前回のＦＳＣＫの実行後に更新されたデータを対象に、整合性チェックを行う。ＦＳＣＫ実行部１３０は、ＦＳＣＫを実行するために、ファイル割当チェック部１３１、ブロック割当チェック部１３２、ディレクトリ構成チェック部１３３、およびクリーンアップ処理部１３４を有する。
【００６０】
ファイル割当チェック部１３１は、inodeへのファイルの割当状態に関するファイルシステムの整合性をチェックする。例えばファイル割当チェック部１３１は、前回のＦＳＣＫ実行後に更新されたinodeに基づいて、inodeのファイル割当状態の更新内容を判断する。inodeのファイル割当状態の更新内容は、例えば前回のＦＳＣＫ実行後に新規に作成されたファイルのinodeなのか、前回のＦＳＣＫ実行後に削除されたファイルのinodeなのかといった情報である。
【００６１】
またファイル割当チェック部１３１は、前回のＦＳＣＫ実行直後のinodeマップと、現在のinodeマップとに基づいて、ファイル割当状態の更新内容を判断する。inodeマップとは、inodeごとに、そのinodeが使用されているか否かをビットの値で示したものである。ファイル割当チェック部１３１は、inodeに基づいたファイル割当状態の更新内容と、inodeマップに基づいたファイル割当状態の更新内容とが一致するか否かを判断する。ファイル割当チェック部１３１は、ファイル割当状態の更新内容が一致していないinodeがあれば、そのinodeの内容について不整合が生じていると判断する。
【００６２】
ブロック割当チェック部１３２は、ブロック割当状態に関する、ファイルシステムの整合性をチェックする。例えばブロック割当チェック部１３２は、前回のＦＳＣＫ実行時から現在までの、inodeに割り当てられたブロックの変化に基づいて、前回のＦＳＣＫ実行後にブロック割当の変化内容を特定する。ブロック割当とは、データの格納先として、ファイルにブロックを割り当てることである。なおinodeでは、論理ボリューム内のブロック番号（論理ブロックアドレス）によって、そのinodeに対応するファイルに割り当てられたブロックが指定されている。割当の変化とは、ブロックが新たに割り当てられたり、ブロックの割当が解除され、そのブロックが解放されたりすることである。またinodeには、割り当てられているブロック数が示されている。そこでブロック割当チェック部１３２は、前回のＦＳＣＫ実行時と現在との間の、inodeに示される割当ブロック数の差分と、前回のＦＳＣＫ実行後におけるブロックの割当状態の変化内容との整合性を確認する。例えば、新たに割り当てられたブロック数から、解放されたブロック数を減算した値が、inodeに示されている割当ブロック数の差分と一致しない場合、不整合があると判断される。
【００６３】
さらに、ファイルサイズの差分をチェックすることもできる。例えばファイル割当チェック部１３１は、割当ブロック数の差分に、１ブロック当たりの容量を乗算することで、前回のＦＳＣＫ実行後における、割り当てられたブロックの総記憶容量の変化を求める。そしてファイル割当チェック部１３１は、割り当てられたブロックの総記憶容量の変化と、前回のＦＳＣＫ実行時と現在とのファイルサイズの差分とを比較し、一致しているか否かをチェックする。なお、ファイルサイズはinodeに示されている。割り当てられたブロックの総記憶容量の変化とファイルサイズの差分とが一致しなければ、不整合があると判断される。
【００６４】
またブロック割当チェック部１３２は、ストレージ装置２００内のボリューム管理マネージャ（ＶＭＧＲ）２４０から、更新されたブロックを示すビットマップ情報（更新ビットマップ：ＷＢＭＡＰ）を取得する。そして、ブロック割当チェック部１３２は、inodeに基づいて認識できる、更新されたブロックと、ＷＢＭＡＰとの不整合の有無をチェックする。
【００６５】
ディレクトリ構成チェック部１３３は、ディレクトリ構成に関する、ファイルシステムの整合性チェックを行う。例えばディレクトリ構成チェック部１３３は、ディレクトリタイプのinodeのうちの、前回のＦＳＣＫ後にディレクトリエントリファイルが更新されたinodeを特定する。次にディレクトリ構成チェック部１３３は、更新されたディレクトリエントリファイルにおける更新前と更新後との内容を比較し、追加されたエントリと削除されたエントリ（ファイル名とinodeとを含む）とを判断する。ディレクトリ構成チェック部１３３は、エントリが追加されたのか、削除されたのかに応じて、そのエントリに示されるinodeの参照増減情報を更新する。そしてディレクトリ構成チェック部１３３は、更新されたinodeについて、参照増減情報に示される増減数と、前回のＦＳＣＫ時と現在とのinodeの内容の比較によって認識できる参照増減数との整合性を判断する。
【００６６】
クリーンアップ処理部１３４は、ファイルシステムの整合性チェックの過程で構築した一時的な情報を削除すると共に、次回のＦＳＣＫの準備を行う。例えば、クリーンアップ処理部１３４は、メモリ内のinodeデータやブロックキャッシュの格納領域を解放する。またクリーンアップ処理部１３４は、ＶＭＧＲ２４０に更新ビットマップのクリア指示を送信する。
【００６７】
ストレージ装置２００は、ＶＭＧＲ２４０を有する。ＶＭＧＲ２４０は、ファイルシステムイメージを１つ以上の不揮発性のストレージメディア上に記録する。そしてＶＭＧＲ２４０は、ＦＳＤ１２０からのファイル／ディレクトリのＩ／Ｏ要求に応じて、論理ボリュームのブロックＩ／Ｏを行う。例えばＶＭＧＲ２４０は、アクセス対象の論理ブロック番号を指定したＩ／Ｏ要求に応じて、その論理ブロックに対応する、ハードディスク番号と物理ブロック番号との組を判断する。そしてＶＭＧＲ２４０は、該当ハードディスクの該当する物理ブロックに対して、Ｉ／Ｏ要求に応じたアクセスを行う。
【００６８】
またＶＭＧＲ２４０は、ブロックの更新差分を管理する。ＶＭＧＲ２４０は、ブロック更新差分情報を管理するために、ブロック更新差分管理部２４１を有している。ブロック更新差分管理部２４１は、例えば、以下の機能を有する。
【００６９】
ブロック更新差分管理部２４１は、更新のあったブロックのＬＢＡをビット１で、それ以外のブロックのＬＢＡをビット０で表現した、更新ビットマップ（ＷＢＭＡＰ）を管理する。
【００７０】
ブロック更新差分管理部２４１は、更新要求のあったブロックを、更新前ブロックデータ（ＢＩＢＬＫ）として別領域に退避しておき、その退避先のＬＢＡを別途管理する。
ブロック更新差分管理部２４１は、ＷＢＭＡＰの参照要求（ＷＢＭＡＰ＿ＲＥＱ）をＦＳＤ１２０から受理したら、その要求で指定されたＬＢＡを含むＷＢＭＡＰを応答する。
【００７１】
ブロック更新差分管理部２４１は、ＢＩＢＬＫの参照要求（ＢＩＢＬＫ＿ＲＥＱ）をＦＳＤ１２０から受理したら、その要求で指定されたＬＢＡのＢＩＢＬＫを応答する。
ブロック更新差分管理部２４１は、ＷＢＭＡＰのリセット要求（ＷＢＭＡＰ＿ＣＬＲ）をＦＳＤ１２０から受理したら、その要求で指定されたＬＢＡを含むＷＢＭＡＰの全ビットをクリアする。このときブロック更新差分管理部２４１は、セットされていたビットに対応するＢＩＢＬＫと、そのＬＢＡ管理エントリを廃棄する。
【００７２】
ブロック更新差分管理部２４１は、ＢＩＢＬＫの総量の参照要求（ＢＩＢＬＫＳＺ＿ＲＥＱ）をＦＳＤ１２０から受理したら、その時点で蓄積しているＢＩＢＬＫの総バイト数を応答する。
【００７３】
次に、ストレージ装置２００で管理される情報について説明する。
図６は、ストレージ装置で管理される情報の一例を示す図である。ストレージ装置２００は、ＨＤＤ２１１〜２１４の記憶領域を管理する。例えばストレージ装置２００は、ＨＤＤ２１１〜２１４内にファイルシステムボリューム領域２５０、更新前データ記憶領域２６０、および更新ビットマップ（ＷＢＭＡＰ）記憶領域２７０を構築する。
【００７４】
ファイルシステムボリューム領域２５０には、サーバ１００からアクセス可能な論理ボリュームの記憶領域である。更新前データ記憶領域２６０は、前回のＦＳＣＫ実行後にデータの更新が行われたブロックの、更新前の内容を格納する記憶領域である。更新ビットマップ記憶領域２７０は、論理ボリューム内の各ブロックについて、前回のＦＳＣＫ後に更新されたか否かを示すビットマップ情報（ＷＢＭＡＰ）を格納する記憶領域である。
【００７５】
図７は、ファイルシステムボリューム領域の詳細を示す図である。ファイルシステムボリューム領域２５０には、スーパーブロック領域２５１と、論理ボリュームごとのビットマップ領域２５２，２５５、inodeブロック領域２５３，２５６、およびデータブロック領域２５４，２５７が含まれる。例えば、ビットマップ領域２５２、inodeブロック領域２５３、およびデータブロック領域２５４の組が、ファイルシステムで管理している１つの論理ボリュームとなる。同様に、ビットマップ領域２５５、inodeブロック領域２５６、およびデータブロック領域２５７の組が、ファイルシステムで管理している１つの論理ボリュームとなる。
【００７６】
スーパーブロック領域２５１には、スーパーブロックと呼ばれる、論理ボリュームを管理するためのメタデータを格納する記憶領域である。スーパーブロックには、例えばinodeの総数やファイルシステムのサイズなどの情報が含まれる。
【００７７】
ビットマップ領域２５２，２５５は、inodeブロックやデータブロックを使用しているか否かを示すビットマップを格納する記憶領域である。ビットマップ領域２５２，２５５では、例えば使用しているブロックに対応するビットに「１」、未使用のブロックに対応するビットに「０」が設定される。
【００７８】
inodeブロック領域２５３，２５６は、inodeを格納する記憶領域である。inodeブロック領域２５３，２５６内のブロック単位の記憶領域に、inodeが格納される。
データブロック領域２５４，２５７は、データを格納する記憶領域である。データブロック領域２５４，２５７内のブロック単位の記憶領域に、ファイルに含まれるデータが格納される。
【００７９】
次に、ファイルシステムボリューム領域２５０内の情報間の関係について説明する。
図８は、ファイルシステムボリューム領域内の情報間の関係を示す図である。ビットマップ領域には、inodeマップ２５２ａとブロックビットマップ２５２ｂとが格納されている。
【００８０】
inodeマップ２５２ａには、ファイルシステム内のinode数分のビットが設けられている。各ビットは、inode番号に対応付けられている。各ビットは、対応するinode番号を有するinodeの使用の有無を示している。図８の例では、inodeが使用されていれば、対応するビットの値が「１」であり、inodeが使用されていなければ、対応するビットの値が「０」である。
【００８１】
ブロックビットマップ２５２ｂには、論理ボリュームのブロック数分のビットが設けられている。各ビットは、ＬＢＡに対応付けられている。各ビットは、対応するＬＢＡを有するデータブロックの使用の有無を示している。図８の例では、データブロックが使用されていれば、対応するビットの値が「１」であり、データブロックが使用されていなければ、対応するビットの値が「０」である。
【００８２】
inodeブロック領域には、inode番号に対応付けられたブロックが設けられている。そして、ディレクトリまたはファイルのinodeが、そのディレクトリまたはファイルのinode番号に対応するブロックに格納されている。なお、ディレクトリに対応するinodeには、例えば、ディレクトリエントリファイルが格納されたデータブロックへのポインタが設定されている。またファイルに対応するinodeには、そのファイルに含まれるデータが格納されたブロックへのポインタが設定されている。
【００８３】
データブロック領域には、ディレクトリエントリファイルやデータが格納される。ディレクトリエントリファイルには、ディレクトリに属する子ディレクトリまたはファイルのエントリを含んでいる。各エントリには、子ディレクトリまたはファイルを一意に示す情報が含まれる。例えばファイルのエントリには、ファイル名とinode番号との組が設定されている。
【００８４】
なおビットマップ領域に格納されたinodeマップ２５２ａとブロックビットマップ２５２ｂ、およびinodeブロック領域に格納されたinodeは、図１に示した第１の実施の形態における、管理情報の一例である。
【００８５】
次に、ＶＭＧＲ２４０内のブロック更新差分管理部２４１による、ブロックの更新差分の管理方法について説明する。
図９は、ブロック更新差分管理方法の一例を示す図である。ファイルシステムボリューム領域２５０のinodeブロック領域２５３，２５６またはデータブロック領域２５４，２５７のブロック内のデータが更新された場合を考える。この場合、ブロック更新差分管理部２４１は、更新された該当ブロックの更新前の内容を示す更新前イメージ（ＢＩ：Before Image）２６１を更新前データ記憶領域２６０に格納する。そしてブロック更新差分管理部２４１は、更新後のブロックの内容を示す更新後イメージ（ＡＩ：After Image）２５８を、ファイルシステムボリューム領域２５０内の更新対象のブロックに格納する。
【００８６】
ブロック更新差分管理部２４１は、更新前データ記憶領域２６０に格納したＢＩ２６１を、ＢＩ制御表２８０を用いて管理する。ＢＩ制御表２８０は、Ｂ＋木（Ｂ＋ｔｒｅｅ）２８１である。Ｂ＋木２８１は、挿入・検索・削除に用いる木構造の一種である。ＢＩ制御表２８０として使用するＢ＋木２８１は、論理ボリュームにおけるブロック番号（ＬＢＡ）をキーとして、ＬＢＡに対応する最下層のノード（葉ノード）まで辿れるように、木構造が構成されている。Ｂ＋木２８１の葉ノードには、更新されたブロックのＬＢＡに対応付けて、そのブロックのＢＩが格納された、更新前データ記憶領域２６０内のブロックの、ブロック番号が格納されている。
【００８７】
このようなＢ＋木２８１を用いれば、更新されたブロックのＬＢＡに対応するＢＩが格納されたブロックのブロック番号を、迅速に特定することができる。
また、ブロック更新差分管理部２４１は、ＷＢＭＡＰを用いて、論理ボリューム内の各ブロックの更新の有無を管理する。
【００８８】
図１０は、ＷＢＭＡＰのデータ構造の一例を示す図である。ＷＢＭＡＰ２７１は、管理対象の論理ボリュームの各ブロックに対応するビットを有している。各ビットの値は、対応するブロックが更新されたか否かを表している。例えば、更新されたブロックに対応するビットには「１」が設定され、更新されていないブロックに対応するビットには「０」が設定される。
【００８９】
図１０の例では、ＷＢＭＡＰ２７１は、６４ビット整数の可変長配列となっている。すなわち、ＷＢＭＡＰ２７１の１つのエントリが、６４ビットの整数で表されている。エントリ数は、論理ボリュームのボリュームサイズをブロックサイズで除算し、さらに１エントリのビット数（６４）で除算して得られる数である。
【００９０】
１つのエントリで、６４個のブロックの更新の有無が表されている。エントリの順番を０番目から昇順に数える場合、例えばＮ番目（Ｎは０以上の整数）のエントリは、（６４×Ｎ）番目のブロックから、（６４×Ｎ＋６３）番目のブロックまでの更新の有無を示す。
【００９１】
ＶＭＧＲ２４０は、サーバ１００からの要求に応じて、ＷＢＭＡＰ２７１をサーバに送信する。例えばＶＭＧＲ２４０は、サーバ１００から特定のブロック番号の範囲の指定を受けて、ＷＢＭＡＰの一部（指定されたブロック番号の範囲に相当する部分）をサーバ１００に送信することもできる。
【００９２】
なおＷＢＭＡＰ２７１は、例えば図７に示すようにファイルシステムボリューム領域２５０内に設けられた領域ごとに設けられる。例えば、ビットマップ領域２５２用のＷＢＭＡＰと、ビットマップ領域２５５用のＷＢＭＡＰとが設けられる。
【００９３】
このように、前回のＦＳＣＫ後のブロック更新差分とＷＢＭＡＰ２７１とを保持しておくことにより、更新されたブロックと更新内容とを、次回のＦＳＣＫ時に容易に認識することができる。
【００９４】
次に、第２の実施の形態におけるＦＳＤ１２０におけるＦＳＣＫの処理手順について説明する。
図１１は、ＦＳＣＫの処理手順の一例を示すフローチャートである。
【００９５】
［ステップＳ１０１］ＦＳＤ１２０は、ＯＳからの起動要求に応じて起動する。このときＦＳＤ１２０は、自身の起動処理の過程で、ＦＳＣＫ実行部１３０を起動する。例えばＦＳＤ１２０は、ＦＳＣＫ実行部１３０の起動要求をＯＳに出力する。すると、ＦＳＣＫ実行部１３０が起動され、ＦＳＣＫに関する処理が開始される。
【００９６】
［ステップＳ１０２］ＦＳＣＫ実行部１３０は、ＢＩＢＬＫの総量を取得する。例えば、ＦＳＣＫ実行部１３０は、ＢＩＢＬＫの総量の参照要求（ＢＩＢＬＫＳＺ＿ＲＥＱ）をストレージ装置２００に対して出力する。するとストレージ装置２００のＶＭＧＲ２４０が、ＢＩＢＬＫの総量を応答する。ＦＳＣＫ実行部１３０は、ＶＭＧＲ２４０から応答されたＢＩＢＬＫの総量を取得する。
【００９７】
［ステップＳ１０３］ＦＳＣＫ実行部１３０は、ＢＩＢＬＫの総量が所定の上限値以上か否かを判断する。例えばＦＳＣＫ実行部１３０は、ＢＩＢＬＫの総量と所定の上限値とを比較し、ＢＩＢＬＫの総量が所定の上限値以上か否かを判断する。ＢＩＢＬＫの総量が所定の上限値以上であれば、処理がステップＳ１０４に進められる。またＢＩＢＬＫの総量が所定の上限値未満であれば、処理がステップＳ１１０に進められる。
【００９８】
［ステップＳ１０４］ＦＳＣＫ実行部１３０は、ＦＳＤの静止化を行う。ＦＳＤ１２０の静止化とは、ＦＳＤ１２０の機能を停止することである。例えばＦＳＣＫ実行部１３０は、ＦＳＤ１２０に対して静止化を指示する。するとＦＳＤ１２０は、メモリ内に保持しているファイルシステムの情報を、ストレージ装置２００に書き出す。そしてＦＳＤ１２０は、アプリケーションなどからの論理ボリュームへのアクセス要求の受付を停止する。
【００９９】
［ステップＳ１０５］ＦＳＣＫ実行部１３０は、ファイルシステムの更新差分に対するＦＳＣＫを行う。この処理の詳細は後述する（図１２参照）。
［ステップＳ１０６］ＦＳＣＫ実行部１３０は、ＦＳＣＫで不整合が検出されずに、ＦＳＣＫが正常終了したか否かを判断する。例えばＦＳＣＫ実行部１３０では、終了コードが用意されている。ＦＳＣＫが不整合なしで正常終了すると、終了コードに正常を示すコードが設定される。またＦＳＣＫによって不整合が検出されると、終了コードにエラーが設定される。そこでＦＳＣＫ実行部１３０は、終了コードの値が正常であれば正常終了と判断し、終了コードの値がエラーであれば不整合が検出され、正常終了していないと判断する。ＦＳＣＫが正常終了した場合、処理がステップＳ１０７に進められる。また不整合が検出され、正常終了しなかった場合、処理がステップＳ１１１に進められる。
【０１００】
［ステップＳ１０７］ＦＳＣＫが正常終了した場合、ＦＳＣＫ実行部１３０内のクリーンアップ処理部１３４は、メモリクリーンアップ処理を行う。例えばクリーンアップ処理部１３４は、メモリ内の、チェック対象のinodeおよびブロックキャッシュの記憶領域を解放する。
【０１０１】
［ステップＳ１０８］クリーンアップ処理部１３４は、論理ボリュームの更新差分のリセット処理を行う。例えばクリーンアップ処理部１３４は、ストレージ装置２００に対して、すべてのＬＢＡをクリア対象として指定したＷＢＭＡＰ＿ＣＬＲ命令を送信する。すると、ブロック更新差分管理部２４１は、ＷＢＭＡＰの全ビットを「０」にクリアする。このときブロック更新差分管理部２４１は、更新前データ記憶領域２６０内の、クリアしたビットに対応するＢＩＢＬＫを解放する。さらにブロック更新差分管理部２４１は、ＢＩ制御表２８０内の、クリアしたビットに対応する葉ノード（ＢＩを指し示すエントリ）を削除する。
【０１０２】
［ステップＳ１０９］ＦＳＣＫ実行部１３０は、ＦＳＤ１２０のリジューム処理を行う。例えばＦＳＣＫ実行部１３０は、ＦＳＤ１２０に対して、アプリケーションからのＩ／Ｏ要求の受付を再開させる。
【０１０３】
［ステップＳ１１０］ＦＳＣＫ実行部１３０は、一定時間待機する。例えばＦＳＣＫ実行部１３０は、タイマによる時間計測を開始し、予め設定された待機時間が経過したかを、随時判断する。そして、ＦＳＣＫ実行部１３０は、時間計測開始から待機時間が経過した場合、処理をステップＳ１０２に進め、次回のＦＳＣＫの実行を開始する。
【０１０４】
［ステップＳ１１１］更新差分ＦＳＣＫで不整合が検出された場合、ＦＳＣＫ実行部１３０は、ＦＳＤ１２０を停止させる。例えばＦＳＣＫ実行部１３０は、ＯＳに対して、ＦＳＤ１２０のプロセスの停止コマンドを送信する。
【０１０５】
このようにして、更新差分に対するＦＳＣＫが定期的に実行される。そしてファイルシステムの不整合が検出されると、ＦＳＤ１２０が停止する。なお、ファイルシステムの不整合が検出された場合、ＦＳＤ１２０停止後に、ファイルシステムの整合性異常の修復処理が行われる。
【０１０６】
次に、更新差分ＦＳＣＫ処理について詳細に説明する。
図１２は、更新差分ＦＳＣＫ処理の手順の一例を示すフローチャートである。
［ステップＳ１２１］ＦＳＣＫ実行部１３０内のファイル割当チェック部１３１は、ファイル割当チェックを行う。この処理の詳細は後述する（図１３、図１５参照）。
【０１０７】
［ステップＳ１２２］ＦＳＣＫ実行部１３０内のブロック割当チェック部１３２は、ブロック割当チェックを行う。この処理の詳細は後述する（図１８、図１９参照）。
［ステップＳ１２３］ＦＳＣＫ実行部１３０内のディレクトリ構成チェック部１３３は、ディレクトリ構成チェックを行う。この処理の詳細は後述する（図２０、図２１参照）。
【０１０８】
次に、更新差分ＦＳＣＫにおける各種のチェック処理について詳細に説明する。
図１３は、ファイル割当チェック処理の一例を示すフローチャートの前半である。
［ステップＳ１３１］ファイル割当チェック部１３１は、inodeブロック領域２５３，２５６（図７参照）に関する未読み出しのＷＢＭＡＰを読み出す。例えばファイル割当チェック部１３１は、未読み出しのinodeブロック領域のＬＢＡを指定したＷＢＭＡＰの参照要求（ＷＢＭＡＰ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＷＢＭＡＰ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡに対応するinodeブロック領域のＷＢＭＡＰを、サーバ１００に応答する。ファイル割当チェック部１３１は、ブロック更新差分管理部２４１から応答されたＷＢＭＡＰを取得する。
【０１０９】
［ステップＳ１３２］ファイル割当チェック部１３１は、更新済みのinodeのＡＩブロックとＢＩブロックとを取得する。例えばファイル割当チェック部１３１は、読み出したＷＢＭＡＰで「１」のinodeブロック（更新があったブロック）のＬＢＡを指定したＢＩＢＬＫの参照要求（ＢＩＢＬＫ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＢＩＢＬＫ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡをキーとしてＢ＋木２８１を探索し、到達した葉ノードに示されるブロック番号のブロックのＢＩを、サーバ１００に応答する。ファイル割当チェック部１３１は、ストレージ装置２００から応答されたＢＩを取得する。またファイル割当チェック部１３１は、更新があったブロックのＬＢＡを指定して、論理ボリューム内のデータ要求をストレージ装置２００に送信する。ストレージ装置２００では、ＶＭＧＲ２４０が、通常の論理ボリュームへのアクセス処理と同様に、指定されたＬＢＡに対応するブロック内のＡＩを、サーバ１００に応答する。ファイル割当チェック部１３１は、ストレージ装置２００から応答されたＡＩを取得する。
【０１１０】
［ステップＳ１３３］ファイル割当チェック部１３１は、取得したＡＩとＢＩとを、メモリ（ＲＡＭ１０２）内のブロックキャッシュ領域に保持する。そしてファイル割当チェック部１３１は、取得したＡＩとＢＩとを示すエントリを、ブロックキャッシュテーブルに登録する。ブロックキャッシュテーブルは、ＬＢＡをキーとしてブロックキャッシュ領域内のブロックの格納位置を特定可能なハッシュテーブルである。
【０１１１】
この際、ファイル割当チェック部１３１は、ディレクトリ整合性チェック処理（ステップＳ１２３）でのリンクカウント差分値のチェックのために、メモリ上に保持したinodeの拡張属性領域に、ワークエリアを予約する。リンクカウント差分値とは、ファイルに対するリンクの数の、前回のＦＳＣＫ実行時から今回のＦＳＣＫ実行時の差である。リンクとは、ファイルをディレクトリにエントリすることである。１つのファイルに対して、複数のリンクを作成することができる。すなわち、１つのファイルを複数のディレクトリにエントリすることができる。この場合、複数のディレクトリそれぞれのエントリにおいて、異なるファイル名を使用することができる。後述するディレクトリ構成チェック処理では、予約したワークエリアを用いて、各ファイルへのリンク数の変化に関する整合性のチェックが行われる。
【０１１２】
［ステップＳ１３４］ファイル割当チェック部１３１は、inodeブロック領域２５３，２５６のＷＢＭＡＰのうち、未読み出しのＷＢＭＡＰがあるか否かを判断する。未読み出しのＷＢＭＡＰがあれば、処理がステップＳ１３１に進められる。未読み出しのＷＢＭＡＰがなければ、処理がステップＳ１３５に進められる。
【０１１３】
ステップＳ１３１〜ステップＳ１３４の処理により、更新差分のあるinodeのキャッシュが構築される。
［ステップＳ１３５］ファイル割当チェック部１３１は、ビットマップ領域２５２，２５５（図７参照）内のinodeマップの記憶領域に関する未読み出しのＷＢＭＡＰを読み出す。例えばファイル割当チェック部１３１は、未読み出しのinodeマップの記憶領域のＬＢＡを指定したＷＢＭＡＰの参照要求（ＷＢＭＡＰ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＷＢＭＡＰ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡに対応するinodeマップの記憶領域のＷＢＭＡＰを、サーバ１００に応答する。ファイル割当チェック部１３１は、ブロック更新差分管理部２４１から応答されたＷＢＭＡＰを取得する。
【０１１４】
［ステップＳ１３６］ファイル割当チェック部１３１は、更新済みのinodeマップのＡＩブロックとＢＩブロックとを取得する。例えばファイル割当チェック部１３１は、読み出したＷＢＭＡＰで「１」のinodeマップのブロック（更新があったブロック）のＬＢＡを指定したＢＩＢＬＫの参照要求（ＢＩＢＬＫ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＢＩＢＬＫ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡをキーとしてＢ＋木２８１を探索し、到達した葉ノードに示されるブロック番号のブロックのＢＩを、サーバ１００に応答する。ファイル割当チェック部１３１は、ストレージ装置２００から応答されたＢＩを取得する。またファイル割当チェック部１３１は、更新があったinodeマップのブロックのＬＢＡを指定して、論理ボリューム内のデータ要求をストレージ装置２００に送信する。ストレージ装置２００では、ＶＭＧＲ２４０が、通常の論理ボリュームへのアクセス処理と同様に、指定されたＬＢＡに対応するブロック内のＡＩを、サーバ１００に応答する。ファイル割当チェック部１３１は、ストレージ装置２００から応答されたＡＩを取得する。
【０１１５】
［ステップＳ１３７］ファイル割当チェック部１３１は、取得したinodeマップのＡＩとＢＩとを、メモリ（ＲＡＭ１０２）内のブロックキャッシュ領域に保持する。そしてファイル割当チェック部１３１は、取得したinodeマップのＡＩとＢＩとを示すエントリを、ブロックキャッシュテーブルに登録する。
【０１１６】
［ステップＳ１３８］ファイル割当チェック部１３１は、取得したinodeマップの各ビットに対応する、ブロックキャッシュ内のinodeに対し、拡張属性領域に予約されたワークエリアのリンクカウント差分値を０に初期化する。
【０１１７】
［ステップＳ１３９］ファイル割当チェック部１３１は、ビットマップ領域２５２，２５５内のinodeマップ領域のＷＢＭＡＰのうち、未読み出しのＷＢＭＡＰがあるか否かを判断する。未読み出しのＷＢＭＡＰがあれば、処理がステップＳ１３５に進められる。未読み出しのＷＢＭＡＰがなければ、処理がステップＳ１４１（図１５参照）に進められる。
【０１１８】
ステップＳ１３５〜ステップＳ１３９の処理により、更新差分のあるinodeマップのキャッシュが構築される。
このようにして、更新されたinodeを含むＡＩ／ＢＩや、更新されたinodeマップを含むＡＩ／ＢＩが、ブロック単位でサーバ１００のＲＡＭ１０２にキャッシュとして保持される。保持されたブロックや、そのブロックに含まれるinodeには、キャッシュテーブルを用いてアクセスできる。
【０１１９】
図１４は、キャッシュされたブロックとキャッシュテーブルの一例を示す図である。図１４には、inode領域のブロックをキャッシュした場合の例を示している。ストレージ装置２００から読み込まれたブロック（ブロックキャッシュ）３０には、inodeイメージ（inodeキャッシュ）３１が含まれている。inodeイメージ３１には、拡張属性領域３１ａがある。第２の実施の形態では、拡張属性領域内に、リンクカウント差分値を管理するためのワークエリアが設けられる。
【０１２０】
ブロック３０の格納場所は、ブロックキャッシュテーブル４０，４０−１によって管理される。例えばＡＩ用のブロックキャッシュテーブル４０とＢＩ用のブロックキャッシュテーブル４０−１とが設けられる。
【０１２１】
ブロックキャッシュテーブル４０は、ＬＢＡをキーとして、そのＬＢＡに対応するブロックのメモリ上での位置を特定するための管理テーブルである。例えば、ブロックキャッシュテーブル４０には、ＬＢＡを所定のハッシュ関数で演算して得られる複数のハッシュ値４１が設定されている。ハッシュ値には、そのハッシュ値が得られるＬＢＡに対応するブロックのエントリ４２，４３が関連付けられている。エントリ４２，４３には、対応するＬＢＡや、キャッシュされたブロックへのポインタが設定されている。ＢＩ用のブロックキャッシュテーブル４０−１の構造も、ＡＩ用のブロックキャッシュテーブル４０と同様である。
【０１２２】
またブロック３０内のinodeを特定するために、inodeキャッシュテーブル５０，５０−１が設けられている。例えばＡＩ用のinodeキャッシュテーブル５０とＢＩ用のinodeキャッシュテーブル５０−１とが設けられる。
【０１２３】
inodeキャッシュテーブル５０は、inode番号をキーとして、そのキーに対応するinodeのメモリ上での位置を特定するための管理テーブルである。例えば、inodeキャッシュテーブル５０には、inode番号を所定のハッシュ関数で演算して得られる複数のハッシュ値５１が設定されている。ハッシュ値には、そのハッシュ値が得られるinode番号に対応するinodeイメージのエントリ５２〜５４が関連付けられている。エントリ５２〜５４には、対応するinode番号や、キャッシュされたinodeイメージへのポインタが設定されている。ＢＩ用のinodeキャッシュテーブル５０−１の構造も、ＡＩ用のinodeキャッシュテーブル５０と同様である。
【０１２４】
なお、ハッシュ値とエントリとの間、およびエントリ間の関連付けは、例えば双方向リンク（ＤＬＬ：Doubly Linked List）によって関連付けられている。ハッシュ値からリンクを辿ることで、そのハッシュ値が得られるブロックまたはinodeのエントリを見つけ出すことができる。ファイル割当チェック部１３１は、例えばキャッシュされたＡＩのブロックを取得する場合、そのブロックのＬＢＡのハッシュ値を計算する。次にファイル割当チェック部１３１は、ＡＩ用のブロックキャッシュテーブル４０において、得られたハッシュ値からリンクを辿り、該当ＬＢＡに対応するエントリを探索する。そしてファイル割当チェック部１３１は、該当エントリのポインタで示される領域のブロックを取得する。
【０１２５】
図１４には、取得したinodeブロックのキャッシュ構造を示しているが、取得したinodeマップブロックも同様のキャッシュ構造で管理される。これらのキャッシュされたブロックを用いて、ファイル割当の整合性がチェックされる。
【０１２６】
図１５は、ファイル割当チェック処理の一例を示すフローチャートの後半である。
［ステップＳ１４１］ファイル割当チェック部１３１は、inodeマップの更新差分に合致するinodeキャッシュがないかどうかを確認する。inodeマップの更新差分とは、inodeマップのＡＩとＢＩとの差分（値の異なるビット）である。ファイルシステムの整合性が保たれていれば、差分に対応するinodeがキャッシュされているはずである。該当するinodeキャッシュが存在しない場合、ファイルシステムの不整合があると判断できる。そこで、更新差分に合致するinodeキャッシュがない場合、処理がステップＳ１４８に進められる。更新差分に合致するinodeキャッシュがあれば、処理がステップＳ１４２に進められる。
【０１２７】
［ステップＳ１４２］ファイル割当チェック部１３１は、ファイル割当が未チェックのinodeペアの中から、チェック対象のinodeペアを選択する。inodeペアとは、同じinode番号に対応するＡＩとＢＩの組である。
【０１２８】
［ステップＳ１４３］ファイル割当チェック部１３１は、選択したinodeペアについて、新規inodeであり、inodeマップでの対応ビットの変化が「０→１」ではないかどうかを判断する。新規inodeは、タイプが「０→非０」に変化したinodeである。inodeのタイプ「０」は、不使用であることを示している。inodeのタイプ「非０」は、使用されているinodeのタイプである。例えばユーザファイルのinodeタイプは「１」であり、ディレクトリのinodeのタイプは「２」である。一方、ビットマップのビットは、「０」の場合、inodeがないことを示し、「１」の場合、inodeがあることを示す。そのため、選択したinodeペアのタイプの変化が、新規inodeが作成されたことを示しているのに、inodeマップの対応ビットの変化が「０→１」でなければ、ファイルシステムに不整合がある。このような不整合が検出された場合、処理がステップＳ１４８に進められる。不整合が検出されなければ、処理がステップＳ１４４に進められる。
【０１２９】
［ステップＳ１４４］ファイル割当チェック部１３１は、選択したinodeペアについて、削除inodeであり、inodeマップでの対応ビットの変化が「１→０」ではないかどうかを判断する。削除inodeは、タイプが「非０→０」に変化したinodeである。選択したinodeペアのタイプの変化が、inodeが削除されたことを示しているのに、inodeマップの対応ビットの変化が「１→０」でなければ、ファイルシステムに不整合がある。このような不整合が検出された場合、処理がステップＳ１４８に進められる。不整合が検出されなければ、処理がステップＳ１４５に進められる。
【０１３０】
［ステップＳ１４５］ファイル割当チェック部１３１は、選択したinodeペアについて、更新inodeであり、inodeマップでの対応ビットが変化しているかどうかを判断する。更新inodeは、タイプは変化せず、inode内の情報が更新されたinodeである。例えばファイルのinodeであれば、そのファイル内のデータが増加し、そのデータを新たなブロックに格納した場合、そのブロックを特定する情報がinodeに追加される。inodeの内容が更新されても、そのinodeに対応するビットマップ中のビットは変化しない。選択したinodeペアの変化が、inodeの内容が更新されたことを示しているのに、inodeマップの対応ビットが変化していれば、ファイルシステムに不整合がある。このような不整合が検出された場合、処理がステップＳ１４８に進められる。不整合が検出されなければ、処理がステップＳ１４６に進められる。
【０１３１】
［ステップＳ１４６］ファイル割当チェック部１３１は、未チェックのinodeペアがあるか否かを判断する。未チェックのinodeペアがあれば、処理がステップＳ１４２に進められる。未チェックのinodeペアがなければ、処理がステップＳ１４７に進められる。
【０１３２】
［ステップＳ１４７］ファイル割当チェック部１３１は、ＦＳＣＫの終了コードを正常に設定する。その後、処理がステップＳ１４９に進められる。
［ステップＳ１４８］ファイル割当チェック部１３１は、ステップＳ１４１，Ｓ１４３〜Ｓ１４５のいずれかのチェックで不整合が検出された場合、終了コードをエラーに設定する。
【０１３３】
［ステップＳ１４９］ファイル割当チェック部１３１は、inodeマップのキャッシュを破棄する。
このようにinodeの割当の変化とinodeマップの変化との整合性がチェックされ、整合しないinodeが存在する場合、不整合が検出され、終了コードにエラーが設定される。すなわち、ファイルシステムの更新差分に基づいて、ファイル割当の整合性がチェック可能となっている。
【０１３４】
次に、ブロック割当のチェック処理について詳細に説明する。なおブロック割当のチェック処理では、論理ボリューム単位のブロック割当マップ（ＶＢＭＡＰ）と、ブロック解放マップ（ＶＦＢＭＡＰ）とを用いる。
【０１３５】
図１６は、ＶＢＭＡＰの一例を示す図である。ＶＢＭＡＰ６１は、論理ボリュームに含まれる各ブロックについて、前回のＦＳＣＫ以後にファイルに割り当てられたか否かを示すビットマップである。例えば、前回のＦＳＣＫ後にファイルに割り当てられたブロックに対応するビットには「１」が設定され、割り当てられていないブロックに対応するビットには「０」が設定される。
【０１３６】
図１６の例では、ＶＢＭＡＰ６１は、６４ビット整数の可変長配列となっている。すなわち、ＶＢＭＡＰ６１の１つのエントリが、６４ビットの整数で表されている。エントリ数は、論理ボリュームのボリュームサイズをブロックサイズで除算し、さらに１エントリのビット数（６４）で除算して得られる数である。
【０１３７】
１つのエントリで、６４個のブロックの新規割当の有無が表されている。エントリの順番を０番目から昇順に数える場合、例えばＮ番目（Ｎは０以上の整数）のエントリは、（６４×Ｎ）番目のブロックから、（６４×Ｎ＋６３）番目のブロックまでの新規割当の有無を示す。
【０１３８】
図１７は、ＶＦＢＭＡＰの一例を示す図である。ＶＦＢＭＡＰ６２は、論理ボリュームに含まれる各ブロックについて、前回のＦＳＣＫ以後に解放されたか否かを示すビットマップである。例えば、前回のＦＳＣＫ後にファイルへの割当が解除されたブロックに対応するビットには「１」が設定され、割当の解除が行われていないブロックに対応するビットには「０」が設定される。
【０１３９】
図１７の例では、ＶＦＢＭＡＰ６２は、６４ビット整数の可変長配列となっている。すなわち、ＶＦＢＭＡＰ６２の１つのエントリが、６４ビットの整数で表されている。エントリ数は、論理ボリュームのボリュームサイズをブロックサイズで除算し、さらに１エントリのビット数（６４）で除算して得られる数である。
【０１４０】
１つのエントリで、６４個のブロックの割当解除の有無が表されている。エントリの順番を０番目から昇順に数える場合、例えばＮ番目（Ｎは０以上の整数）のエントリは、（６４×Ｎ）番目のブロックから、（６４×Ｎ＋６３）番目のブロックまでの割当解除の有無を示す。
【０１４１】
図１８は、ブロック割当チェック処理の手順の一例を示すフローチャートの前半である。
［ステップＳ１６１］ブロック割当チェック部１３２は、ＶＢＭＡＰ６１とＶＦＢＭＡＰ６２とを、メモリ（ＲＡＭ１０２）内に作成する。そしてブロック割当チェック部１３２は、ＶＢＭＡＰ６１とＶＦＢＭＡＰ６２との各ビットの値を、オール０に初期化する。
【０１４２】
［ステップＳ１６２］ブロック割当チェック部１３２は、ブロック割当が未チェックのinodeペアの中から、チェック対象のinodeペア（ＡＩとＢＩ）を選択する。例えばブロック割当チェック部１３２は、ファイル割当チェック処理においてキャッシュした更新差分のあるinodeにおけるinodeペアをチェック対象とし、そのうちの１つのinodeペアを選択する。
【０１４３】
［ステップＳ１６３］ブロック割当チェック部１３２は、ＬＢＡを１つ選択する。例えばブロック割当チェック部１３２は、選択したinodeペアのＬＢＡの大きい方を上限として、ＬＢＡを、値が小さい方から昇順に選択する。
【０１４４】
［ステップＳ１６４］ブロック割当チェック部１３２は、選択したinodeペアのＡＩ側のinodeとＢＩ側のinodeとで、選択したＬＢＡに対応するブロックのファイルへの割当状況が同じか否かを判断する。割当状況が同じ場合とは、例えば選択したＬＢＡのブロックが、選択したinodeペアのＡＩ用のinodeとＢＩ用のinodeとの両方に割り当てられているか、あるいは両方に未割当の場合である。割当状況が同じであれば、処理がステップＳ１６９に進められる。割当状況が異なれば、処理がステップＳ１６５に進められる。
【０１４５】
［ステップＳ１６５］ブロック割当チェック部１３２は、ＢＩ側のinodeにおいて、選択したＬＢＡのブロックが割り当てられているか否かを判断する。ＢＩで割り当てられており、ＡＩで割り当てられていない場合、選択したＬＢＡのブロックは、前回のＦＳＣＫ後に解放されたものと考えられる。ＢＩ側のinodeにおいて割り当てられているのであれば、処理がステップＳ１６６に進められる。またＢＩ側のinodeにおいて割り当てられていなければ、処理がステップＳ１６７に進められる。
【０１４６】
［ステップＳ１６６］ブロック割当チェック部１３２は、ＶＦＢＭＡＰ６２における、選択したＬＢＡに対応するビットに、「１」を設定する。
［ステップＳ１６７］ブロック割当チェック部１３２は、ＡＩ側のinodeにおいて、選択したＬＢＡのブロックが割り当てられているか否かを判断する。ＡＩで割り当てられており、ＢＩで割り当てられていない場合、選択したＬＢＡのブロックは、前回のＦＳＣＫ後に新規に割り当てられたものと考えられる。ＡＩ側のinodeにおいて割り当てられているのであれば、処理がステップＳ１６８に進められる。またＡＩ側のinodeにおいて割り当てられていなければ、処理がステップＳ１６９に進められる。
【０１４７】
［ステップＳ１６８］ブロック割当チェック部１３２は、ＶＢＭＡＰ６１における、選択したＬＢＡに対応するビットに、「１」を設定する。
［ステップＳ１６９］ブロック割当チェック部１３２は、未チェックのＬＢＡがあるか否かを判断する。未チェックのＬＢＡがあれば、処理がステップＳ１６３に進められる。未チェックのＬＢＡがなければ、処理がステップＳ１７０に進められる。
【０１４８】
［ステップＳ１７０］ブロック割当チェック部１３２は、ブロックの「割当数−解放数」が、inode内のブロック数の差分と合致するか否かを判断する。例えばブロック割当チェック部１３２は、ＶＢＭＡＰにおける「１」のビットの数を、「割当数」とする。またブロック割当チェック部１３２は、ＶＦＢＭＡＰにおける「１」のビットの数を「解放数」とする。そしてブロック割当チェック部１３２は、ＶＢＭＡＰとＶＦＢＭＡＰとから得られた値により「割当数−解放数」を計算する。またブロック割当チェック部１３２は、既に選択したすべてのinodeペアそれぞれのＡＩ側のinodeに割当されたブロック数の合計から、ＢＩ側のinodeに割り当てられたブロック数の合計を減算し、減算結果をinode内のブロック数の差分とする。そしてブロック割当チェック部１３２は、「割当数−解放数」の計算結果と、inode内のブロック数の差分とを比較し、一致するか否かを判断する。一致した場合、処理がステップＳ１７１に進められる。一致しなかった場合、処理がステップＳ１８６（図１９参照）に進められる。
【０１４９】
［ステップＳ１７１］ブロック割当チェック部１３２は、未チェックのinodeペアがあるか否かを判断する。未チェックのinodeペアがあれば、処理がステップＳ１６２に進められる。未チェックのinodeペアがなければ、処理がステップＳ１８１（図１９参照）に進められる。
【０１５０】
図１９は、ブロック割当チェック処理の手順の一例を示すフローチャートの後半である。
［ステップＳ１８１］ブロック割当チェック部１３２は、ビットマップ領域内のブロックビットマップ２５２ｂ（図８参照）が格納されたブロックに関する未読み出しのＷＢＭＡＰを読み出す。例えばブロック割当チェック部１３２は、未読み出しのブロックビットマップの記憶領域のＬＢＡを指定したＷＢＭＡＰの参照要求（ＷＢＭＡＰ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＷＢＭＡＰ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡに対応するブロックビットマップの記憶領域のＷＢＭＡＰを、サーバ１００に応答する。ブロック割当チェック部１３２は、ブロック更新差分管理部２４１から応答されたＷＢＭＡＰを取得する。
【０１５１】
［ステップＳ１８２］ブロック割当チェック部１３２は、更新済みのブロックビットマップのＡＩブロックとＢＩブロックとを取得する。例えばブロック割当チェック部１３２は、読み出したＷＢＭＡＰで「１」のブロックビットマップが格納されたブロック（更新があったブロック）のＬＢＡを指定したＢＩＢＬＫの参照要求（ＢＩＢＬＫ＿ＲＥＱ）を、ストレージ装置２００に送信する。ＢＩＢＬＫ＿ＲＥＱを受信したストレージ装置２００では、ブロック更新差分管理部２４１が、指定されたＬＢＡをキーとしてＢ＋木２８１を探索し、到達した葉ノードに示されるブロック番号のブロックのＢＩを、サーバ１００に応答する。ブロック割当チェック部１３２は、ストレージ装置２００から応答されたＢＩを取得する。またブロック割当チェック部１３２は、更新があったブロックビットマップが格納されたブロックのＬＢＡを指定して、論理ボリューム内のデータ要求をストレージ装置２００に送信する。ストレージ装置２００では、ＶＭＧＲ２４０が、通常の論理ボリュームへのアクセス処理と同様に、指定されたＬＢＡに対応するブロック内のＡＩを、サーバ１００に応答する。ブロック割当チェック部１３２は、ストレージ装置２００から応答されたＡＩを取得する。
【０１５２】
［ステップＳ１８３］ブロック割当チェック部１３２は、取得したＡＩとＢＩとを、メモリ（ＲＡＭ１０２）内のブロックキャッシュ領域に保持する。そしてブロック割当チェック部１３２は、取得したＡＩとＢＩとを示すエントリを、ブロックキャッシュテーブルに登録する。
【０１５３】
［ステップＳ１８４］ブロック割当チェック部１３２は、ブロックビットマップの格納領域のＷＢＭＡＰのうち、未読み出しのＷＢＭＡＰがあるか否かを判断する。未読み出しのＷＢＭＡＰがあれば、処理がステップＳ１８１に進められる。未読み出しのＷＢＭＡＰがなければ、処理がステップＳ１８５に進められる。
【０１５４】
ステップＳ１８１〜ステップＳ１８４の処理により、更新差分のあるブロックビットマップのキャッシュが構築される。
［ステップＳ１８５］ブロック割当チェック部１３２は、ブロックビットマップのＢＩに対して、ＶＢＭＡＰの値を対応するビットごとに加算し、ＶＦＢＭＡＰの値を対応するビットごとに減算する。そしてブロック割当チェック部１３２は、計算の結果として得られたビットマップが、ブロックビットマップのＡＩと合致するか否かを判断する。合致する場合、処理がステップＳ１８７に進められる。合致しない場合、処理がステップＳ１８６に進められる。
【０１５５】
［ステップＳ１８６］ブロック割当チェック部１３２は、ステップＳ１７０またはステップＳ１８５のいずれかの判断で、不整合が検出された場合、終了コードをエラーに設定する。
【０１５６】
［ステップＳ１８７］ブロック割当チェック部１３２は、ＶＢＭＡＰとＶＦＢＭＡＰとを破棄する。
このようにして、inodeに示されているファイルへのブロック割当状況の変化を、ブロックビットマップのＢＩに反映することで、ブロックビットマップのＡＩに合致するかどうかにより、ブロック割当の整合性が確認される。すなわち、ファイルシステムの更新差分の情報を用いて、ブロック割当の整合性をチェックすることが可能となっている。
【０１５７】
次に、ディレクトリ構成のチェック処理について詳細に説明する。
図２０は、ディレクトリ構成チェック処理の手順の一例を示すフローチャートの前半である。
【０１５８】
［ステップＳ１９１］ディレクトリ構成チェック部１３３は、ディレクトリ構成が未チェックのinodeペアのうち、タイプがディレクトリのinodeペアを１つ選択する。
［ステップＳ１９２］ディレクトリ構成チェック部１３３は、ＬＢＡを１つ選択する。例えばブロック割当チェック部１３２は、選択したinodeペアのＬＢＡの大きい方を上限として、ＬＢＡを、値が小さい方から昇順に選択する。
【０１５９】
［ステップＳ１９３］ディレクトリ構成チェック部１３３は、選択したinodeペアのＡＩ側のinodeとＢＩ側のinodeとで、選択したＬＢＡに対応するブロックのファイルへの割当状況が同じか否かを判断する。割当状況が同じ場合とは、例えば選択したＬＢＡのブロックが、選択したinodeペアのＡＩ用のinodeとＢＩ用のinodeとの両方に割り当てられているか、あるいは両方に未割当の場合である。割当状況が同じであれば、処理がステップＳ１９４に進められる。割当状況が異なれば、処理がステップＳ１９５に進められる。
【０１６０】
［ステップＳ１９４］ディレクトリ構成チェック部１３３は、選択したＬＢＡに対応するＷＢＭＡＰのビットの値が「０」（未更新）であるか否かを判断する。該当ビットの値が「０」であれば、処理がステップＳ１９８に進められる。該当ビットの値が「１」であれば、処理がステップＳ１９５に進められる。
【０１６１】
［ステップＳ１９５］ディレクトリ構成チェック部１３３は、選択したＬＢＡのブロックのディレクトリエントリファイルにおいて、追加または削除されたエントリを特定する。ディレクトリ構成チェック部１３３は、該当ブロックのＡＩとＢＩそれぞれのディレクトリエントリファイルを比較することで、追加、削除、または更新されたエントリを特定することができる。例えばＡＩのディレクトリエントリファイルに含まれているエントリが、ＢＩのディレクトリエントリファイルに含まれていなければ、そのエントリは追加されたエントリである。またＢＩのディレクトリエントリファイルに含まれているエントリが、ＡＩのディレクトリエントリファイルに含まれていなければ、そのエントリは削除されたエントリである。
【０１６２】
［ステップＳ１９６］ディレクトリ構成チェック部１３３は、追加されたエントリごとに、そのエントリに対応するinodeのワークエリアのリンクカウント差分値に、増加分を反映（１を加算）する。
【０１６３】
［ステップＳ１９７］ディレクトリ構成チェック部１３３は、削除されたエントリごとに、そのエントリに対応するinodeのワークエリアのリンクカウント差分値に、減少分を反映（１を減算）する。
【０１６４】
［ステップＳ１９８］ディレクトリ構成チェック部１３３は、未チェックのＬＢＡがあるか否かを判断する。未チェックのＬＢＡがあれば、処理がステップＳ１９２に進められる。未チェックのＬＢＡがなければ、処理がステップＳ１９９に進められる。
【０１６５】
［ステップＳ１９９］ディレクトリ構成チェック部１３３は、未チェックのinodeペアがあるか否かを判断する。未チェックのinodeペアがあれば、処理がステップＳ１９１に進められる。未チェックのinodeペアがなければ、ディレクトリ構成チェック部１３３は、すべてのinodeペアを未チェックの状態に戻し、処理をステップＳ２０１（図２１参照）に進める。
【０１６６】
図２１は、ディレクトリ構成チェック処理の手順の一例を示すフローチャートの後半である。
［ステップＳ２０１］ディレクトリ構成チェック部１３３は、未チェックのinodeペアを１つ選択する。
【０１６７】
［ステップＳ２０２］ディレクトリ構成チェック部１３３は、選択したinodeペアのＡＩ側のinodeに予約されたワークエリア内のリンクカウント差分値と、inodeペアにおけるinodeを指すリンク数（参照数）の増減値とを比較する。そしてディレクトリ構成チェック部１３３は、リンクカウント差分値とリンク数増減値とが合致するか否かを判断する。inodeペアにおけるinode内のリンク数の増減は、ＡＩ側のinodeのリンク数からＢＩ側のinodeのリンク数を減算した値である。リンクカウント差分値とリンク数増減値とが合致する場合、処理がステップＳ２０３に進められる。またリンクカウント差分値とリンク数増減値とが合致しない場合、不整合があるとして、処理がステップＳ２０４に進められる。
【０１６８】
［ステップＳ２０３］ディレクトリ構成チェック部１３３は、未チェックのinodeがあるか否かを判断する。未チェックのinodeがあれば、処理がステップＳ２０１に進められる。また未チェックのinodeがなければ、ディレクトリ構成チェック処理が終了する。
【０１６９】
［ステップＳ２０４］ディレクトリ構成チェック部１３３は、終了コードをエラーに設定し、ディレクトリ構成チェック処理を終了する。
このようにして、ファイルシステムの更新差分に基づいて、ディレクトリ構成の整合性がチェックできる。
【０１７０】
以上説明したように、第２の実施の形態では、前回のＦＳＣＫ実行時からの更新差分の情報について、ファイルシステムの整合性をチェックするようにした。そのため、論理ボリューム全体に対して整合性チェックを実行する場合に比べ、処理データ量が低減し、短時間で整合性チェックを完了することが可能となる。しかも、更新されたブロック数が上限以上になったときにＦＳＣＫを実行するようにしたため、ボリュームの容量が増大しても、ＦＳＣＫ一回当たりに処理するデータ量は変わらずにすむ。その結果、ボリュームの大容量化に伴うＦＳＣＫの長期化が抑止できる。
【０１７１】
なお、第２の実施の形態では、ＦＳＣＫ中にＦＳＤの動作を停止させることを想定したが、ＦＳＣＫ中におけるＦＳＤの停止期間を短縮することも可能である。例えば、上記ＦＳＤの静止化処理のうち、バッファキャッシュなどをフラッシュした後、ＶＭＧＲに備わるオンラインスナップショット機能を用いてボリュームイメージを凍結し、この凍結イメージをＦＳＣＫの対象とすることができる。なおフラッシュとは、サーバ１００内に一時的に保持しているデータを、ストレージ装置へ書き出す処理である。このように、凍結イメージをＦＳＣＫの対象とすることで、凍結イメージ作成後は、ＦＳＤを再稼働させることができる。その結果、ＦＳＤの停止期間は、凍結イメージの作成に必要な期間だけとなり、停止期間を短縮することができる。
【０１７２】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１７３】
１  ボリューム
１ａ  単位記憶領域
２  更新前情報格納手段
３  更新領域記録手段
４  更新前情報記憶手段
５  更新領域情報記憶手段
５ａ  更新領域情報
６  特定手段
７  検証手段
７ａ  ファイル割当検証手段
７ｂ  ブロック割当検証手段
７ｃ  ディレクトリ構成検証手段
８ａ，８ｂ  情報
【図１】
2014182417.tif 000003
【図２】
2014182417.tif 000004
【図３】
2014182417.tif 000005
【図４】
2014182417.tif 000006
【図５】
2014182417.tif 000007
【図６】
2014182417.tif 000008
【図７】
2014182417.tif 000009
【図８】
2014182417.tif 000010
【図９】
2014182417.tif 000011
【図１０】
2014182417.tif 000012
【図１１】
2014182417.tif 000013
【図１２】
2014182417.tif 000014
【図１３】
2014182417.tif 000015
【図１４】
2014182417.tif 000016
【図１５】
2014182417.tif 000017
【図１６】
2014182417.tif 000018
【図１７】
2014182417.tif 000019
【図１８】
2014182417.tif 000020
【図１９】
2014182417.tif 000021
【図２０】
2014182417.tif 000022
【図２１】
2014182417.tif 000023