(57)【要約】【課題】ファイルシステムのメンテナンス作業時間を削減する。【解決手段】ファイルシステムによって管理される第１の記憶領域から読み出したデータについて異常があるかを検出し、異常が検出されたデータである異常データを修復して第２の記憶領域に格納する修復処理を行い、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致する場合に、第１の記憶領域における修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが示す領域から読み出したデータについて再度修復処理を行い、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致しない場合に、第１の記憶領域における、異常データの読み出し元のアドレスに修復されたデータを書き込む。【選択図】図１
2015049633.tif 000002
【特許請求の範囲】
【請求項１】
ファイルシステムによって管理される第１の記憶領域と、データを格納する第２の記憶領域と、を含む記憶部と、
前記第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する修復部と、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む書込部と、
を含むことを特徴とする情報処理装置。
【請求項２】
前記情報処理装置は、さらに、
前記第１の記憶領域において、所定期間内に更新されたデータが格納されたアドレスを特定する特定部
を含み、
前記修復部は、前記第１の記憶領域において特定された前記アドレスから読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行う
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記修復部は、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記異常データの読み出し元のアドレスのうち前記所定期間内に更新されたデータが格納されたアドレスと、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記書込部は、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データのうちの前記修復されたデータの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む
ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
コンピュータに、
ファイルシステムによって管理される第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納し、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む、
処理を実行させることを特徴とするデータ修復プログラム。
【請求項６】
ファイルシステムによって管理される第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納し、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む、
処理を実行することを特徴とするデータ修復方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステムの整合性のチェック及び修復処理に関する。
【背景技術】
【０００２】
ファイルシステムの不整合は、ファイルサーバのソフトまたはハードの誤動作や故障によるデータ破壊により発生する。このようなファイルシステムの不整合が長期にわたって放置され、ファイルシステムへの業務Ｉ／Ｏエラー等で不整合が検出された場合、既に修復が困難なほど多数の不整合が発生しているケースも少なくない。
【０００３】
ファイルシステムの不整合を探索し修復する技術として、ＦＳＣＫ（file system check）がある。ＦＳＣＫは、ファイルシステムの可用性維持のための重要な高信頼化機能の一つである。
【０００４】
しかしながら、ＦＳＣＫは、膨大な処理時間を要するという問題点がある。これは、例えば、ＦＳＣＫでは、処理対象のファイルシステムのメタデータの大部分が読み出されることなどに起因する。
【０００５】
一方、近年の電子データの増大に伴って、企業で運用されるファイルシステムの規模が増大してきている。このような状況において、オフライン実行可能な時間内（例えば、夜間のバッチ処理用の時間帯などの実運用上問題の無い時間内）に、ＦＳＣＫを処理し終えることが困難になってきている。その上、グローバル化する業務においては２４時間体制でファイルシステムのデータがアクセスされるケースが増加している。そのため、ＦＳＣＫのオフライン実行のための業務停止自体も難しくなっている。
【０００６】
このような状況から、例えばペタバイト級の、規模が大きなファイルシステムでのＦＳＣＫの高速化技術が求められている。例えば、ファイルシステムを、小規模の複数のファイルシステムに分割することが考えられている。また、ファイルシステムでジャーナリングを行うことも考えられている。ジャーナリングとは、障害発生時の復旧用に、ファイル更新履歴を保持・管理する機能である。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１６５４７４号公報
【特許文献２】特開平９−６６５３号公報
【特許文献３】特開２００５−２５０８１９号公報
【非特許文献】
【０００８】
【非特許文献１】Val Henson, Arjanvan 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
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、上記技術は、ＦＳＣＫの実行時間等のメンテナンス作業時間の長期化を、十分に抑止することができない。
【００１０】
例えば、ファイルシステムを小規模のファイルシステムに分割する技術は、小規模のファイルシステムの集合での運用が許容できるシステムに限定される。しかも、多数ファイルシステムのＦＳＣＫを並列実行すると、それによるサーバメモリの枯渇の恐れがあり、小規模化にも限界がある。そのため、ある程度以上にボリュームの規模が増大すると、ＦＳＣＫ等のメンテナンス作業時間の長期化を抑止できなくなる。
【００１１】
また、ジャーナリングを用いれば、ファイルシステム不整合の一因となる突然停止の後でも、ジャーナル処理を続行することで不整合を高速に復旧することができる。これにより、ＦＳＣＫの必要性を軽減することができる。しかしながら、サーバのソフトウェアまたはハードウェアの誤動作によるファイルシステムの不整合の発生の可能性が残り、ジャーナリングを用いたとしても、完全にＦＳＣＫを不要なものとすることはできない。
【００１２】
そこで、１つの側面では、本発明は、ファイルシステムのメンテナンス作業時間を削減することを目的とする。
【課題を解決するための手段】
【００１３】
一態様の情報処理装置は、記憶部、修復部、及び書込部を含む。記憶部は、ファイルシステムによって管理される第１の記憶領域と、データを格納する第２の記憶領域と、を含む。修復部は、第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出されたデータである異常データを修復して第２の記憶領域に格納する修復処理を行い、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致する場合に、第１の記憶領域における修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出されたデータを修復して第２の記憶領域に格納する。書込部は、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致しない場合に、第１の記憶領域における、異常データの読み出し元のアドレスに修復されたデータを書き込む。
【発明の効果】
【００１４】
一実施態様によれば、ファイルシステムのメンテナンス作業時間を削減することができる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態に係る情報処理装置の一実施例の構成を図解した機能ブロック図である。
【図２】本実施形態に係る情報処理装置の構成の一例を示す。
【図３】更新マップの一例を示す。
【図４】スナップショットの退避マップの一例を示す。
【図５】クローンの格納マップの一例を示す。
【図６】整合性チェックと修復処理における、クローンとオンラインボリュームとの関係を説明する図である。
【図７】整合性チェックと修復処理の再実施における、クローンとオンラインボリュームとの関係を説明する図である。
【図８】修復処理により変更されたクローンのデータのアドレスと、アプリケーションにより変更されたオンラインボリュームのデータのアドレスとが一致するものが存在しない場合の、取得対象ボリュームのアドレス空間の一例を説明する図である。
【図９】修復処理により変更されたクローンのデータのアドレスと、整合性のチェック及び修復処理中に変更されたオンラインボリュームのデータのアドレスとが一致するものが存在する場合の、取得対象ボリュームのアドレス空間の一例を説明する図である。
【図１０】整合性のチェック及び修復処理の再実施の対象範囲を説明する図である。
【図１１】ファイルシステムの不整合のチェックおよび修復処理の処理内容を図解したフローチャートの前半である。
【図１２】ファイルシステムの不整合のチェックおよび修復処理の処理内容を図解したフローチャートの後半である。
【図１３】情報処理装置のハードウェア構成の一例を示す。
【図１４】記憶装置がＣＭを含み、通信インターフェースを介して情報処理装置と接続される構成の一例である。
【発明を実施するための形態】
【００１６】
ＦＳＣＫは、整合性チェック処理と不整合の修復処理の２つの処理を含む。整合性チェック処理は、ファイルシステムの整合性を種々の観点からチェックする処理である。修復処理は、整合性チェックにより不整合が見つかったブロックに対して、不整合が解消するように修復を行う処理である。
【００１７】
本実施形態では、これらの整合性のチェック及び修復処理は、スナップショット機能を用いて行うことにより実現する。これにより、ファイルシステムがオンラインの状態（システムまたはサービス停止を伴わない状態）でＦＳＣＫを実行することが可能となる。スナップショット機能は、例えば、ＲＡＩＤ（Redundant Arrays of Independent Disks）やＬＶＭ（Logical Volume Manager）に備わるものを用いてもよい。
【００１８】
しかしながら、スナップショットに対して整合性のチェック及び修復処理が行われている間にも、スナップショットの取得元のファイルシステムに対しては、通常の業務による入出力が発生し続ける。このとき、取得元のファイルシステムに対する更新処理と、不整合の修復処理の更新対象とが競合する場合には、スナップショットに対して行った修復処理結果を取得元のファイルシステムに反映する際に新たな不整合が生じる虞がある。例えば、業務による入出力処理とＦＳＣＫの修復処理において、同一ブロックが更新される場合などが、更新対象が競合する場合に該当する。このような場合に、競合条件が解消されるまで同じ整合性のチェックおよび修復処理を再実施していては、特に２４時間体制の業務で継続的にアクセスされるファイルシステムでは、不整合修復が長期に渡って行われない虞が生じる。
【００１９】
そこで、本実施形態においては、更新対象が競合した場合に、整合性のチェック及び修復処理を再実施するが、その際に整合性のチェック及び修復処理の再実施の対象を絞り込む。これにより、整合性チェックおよび修復処理をオンラインで且つ高速に実現できる。その結果、業務継続性をスポイルしないためファイルシステムの可用性が向上するとともに、不整合の発見および修復が早期化しファイルシステムの高信頼化に繋がる。
【００２０】
図１は、本実施形態に係る情報処理装置の一実施例の構成を図解した機能ブロック図である。情報処理装置１０は、記憶部１、修復部２、書込部３、及び特定部４を含む。
【００２１】
記憶部１は、ファイルシステムによって管理される第１の記憶領域と、データを格納する第２の記憶領域と、を含む。
【００２２】
修復部２は、第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出されたデータである異常データを修復して第２の記憶領域に格納する修復処理を行う。また、修復部２は、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致する場合に、次の動作を行う。すなわち、修復部２は、先ず第１の記憶領域における修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが示す領域からデータを読み出す。そして、修復部２は、読み出したデータについて異常があるかを検出し、検出の結果、異常が検出されたデータを修復して第２の記憶領域に格納する。
【００２３】
書込部３は、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致しない場合に、第１の記憶領域における、異常データの読み出し元のアドレスに修復されたデータを書き込む。
【００２４】
特定部４は、第１の記憶領域において、所定期間内に更新されたデータが格納されたアドレスを特定する。そして、修復部２は、第１の記憶領域において特定されたアドレスから読み出したデータについて異常があるかを検出し、検出の結果、異常が検出されたデータである異常データを修復して第２の記憶領域に格納する修復処理を行う。
【００２５】
また修復部２は、第１の記憶領域において修復処理の間に変更されたデータのアドレスと、異常データの読み出し元のアドレスとが一致する場合に、次の動作を行う。すなわち、修復部２は、先ず、異常データの読み出し元のアドレスのうち所定期間内に更新されたデータが格納されたアドレスと、第１の記憶領域における修復処理の間に変更されたデータのアドレスとが示す領域から読み出したデータについて異常があるかを検出する。そして、修復部２は、検出の結果、異常が検出されたデータを修復して第２の記憶領域に格納する。
【００２６】
また書込部３は、第１の記憶領域において修復処理の間に変更されたデータのアドレスと異常データのうち修復されたデータの読み出し元のアドレスとが一致しない場合に、第１の記憶領域における異常データの読み出し元のアドレスに修復されたデータを書き込む。
【００２７】
図２は、本実施形態に係る情報処理装置の構成の一例を示す。図２において、情報処理装置は、アプリケーション２０ａ、２０ｂ、２０ｃ、ファイルシステムドライバ２１、ボリューム管理部２２、及び記憶部２３を含む。
【００２８】
アプリケーション２０ａ、２０ｂ、２０ｃはファイルシステムドライバを通して、記憶部２３に格納されているファイルまたはディレクトリにアクセスし、データの読み書きを行う。以下の説明では、アプリケーション２０ａ、２０ｂ、２０ｃを特に区別しない場合にはアプリケーション２０と記す。このアプリケーション２０は、例えば、情報処理装置を利用する利用者が通常業務で使用するサービスを提供するものであってよいし、他の端末とデータのやり取りを行うものであってもよい。
【００２９】
ファイルシステムドライバ２１（以下の説明ではＦＳＤ２１と記す）は、記憶部２３に作成されたファイルシステムを管理する。ＦＳＤ２１は、アプリケーション２０からデータの読み書きの要求を受け付け、ファイルシステムの整合性を保ちつつ、ボリューム管理部２２に対してデータの読み書きを指示する。ＦＳＤ２１は、ファイルシステム整合性チェック部を含む。ファイルシステムとは、記憶装置に記録されているデータを管理するための機能である。
【００３０】
ファイルシステム整合性チェック部（以下の説明では、ＦＳＣＫ部２４と記す）は、ＦＳＤ２１のサブモジュールであり、ファイルシステムの整合性のチェックおよび不整合の修復処理を行う。また、ＦＳＣＫ部２４は、ボリューム管理部２２に対して、アプリケーション２０から受け付けたファイルまたはディレクトリに対する入出力の要求を行う。
【００３１】
ＦＳＣＫ部２４は、ファイルシステムの整合性のチェック及び不整合の修復処理を、所定の時間間隔で実行する。そして、ＦＳＣＫ部２４は、前回の整合性のチェック及び修復処理により整合性が確認された時点から、更新が発生したブロックを対象として、次の整合性のチェック及び修復処理を行う。
【００３２】
ファイルシステムの整合性のチェックとして、例えば、ＦＳＣＫ部２４は、ファイルシステムの各ファイル（ディレクトリを含む）と、それらのファイルの管理情報（メタデータ）の整合性をチェックする。ここで、管理情報は、例えばｉｎｏｄｅの情報である。また、例えば、ＦＳＣＫ部２４は、複数の管理情報間の整合性のチェックを行う。
【００３３】
具体的には、例えば、ＦＳＣＫ部２４は、ファイル割当チェック、ブロック割当チェック、及びディレクトリ構成チェックを行う。
【００３４】
ファイル割当チェックでは、ＦＳＣＫ部２４は、管理情報（例えばｉｎｏｄｅ）のファイルへの割当の有無を示すｉｎｏｄｅ割当情報の、所定期間内での変化と、その管理情報の所定期間内での変化との整合性をチェックする。
【００３５】
ブロック割当チェックでは、ＦＳＣＫ部２４は、ファイルシステムのブロックのファイルへの割当の有無を示すブロック割当情報の、所定期間内での変化と、管理情報に基づく単位記憶領域の管理対象情報への割当の、所定期間内での変化との整合性をチェックする。また、ＦＳＣＫ部２４は、ファイルに割り当てられたブロックの、所定期間内での変化と、そのファイルの管理情報に示される、そのファイルに割り当てられているブロック数の、所定期間内での変化との整合性をチェックする。
【００３６】
ディレクトリ構成チェックでは、ＦＳＣＫ部２４は、ディレクトリへのファイルのエントリの、所定期間内での変化に基づく、ファイルが属しているディレクトリの数を算出する。またＦＳＣＫ部２４は、ファイルの管理情報に設定されている、そのファイルが属しているディレクトリ数の、所定期間内での変化を算出する。そして、ＦＳＣＫ部２４は、ディレクトリへのファイルのエントリに基づく、ファイルが属しているディレクトリの数と、ファイルの管理情報に基づく、ファイルが属しているディレクトリの数との整合性をチェックする。
【００３７】
また、ＦＳＣＫ部２４は、整合性チェック及び修復処理において、整合性チェックの対象の論理ボリュームの所定の時刻におけるスナップショット、及び、そのスナップショットを基としたクローンの採取を行うようにボリューム管理部２２に指示する。
【００３８】
ボリューム管理部２２は、記憶部２３に含まれる複数のディスクとディスク上のデータを管理する。また、ボリューム管理部２２は、ＦＳＣＫ部２４からの入出力要求に応じて、記憶部２３に対してデータの読み書きを行う。
【００３９】
具体的には、例えば、ボリューム管理部２２は、ディスク２６ａ、２６ｂ、２６ｃ、２６ｄのいずれかまたは複数を、一つの論理ドライブとして管理する。そして、その論理ドライブ上に、ボリューム管理部２２は、論理的な仮想パーティションである論理ボリュームを設定し、この論理ボリューム上にファイルシステムを作成する。
【００４０】
ボリューム管理部２２は、履歴管理部２５を含む。履歴管理部２５は、ＦＳＣＫ部２４からの指示に応じて、論理ボリューム単位で、所定時点におけるディスクイメージを復元可能とするスナップショットを作成し、論理ボリュームの所定時点からの変更を管理する。また、履歴管理部２５は、整合性のチェック及び修復処理のために用いるスナップショットのクローンを作成し、クローンに対してなされた変更を管理する。
【００４１】
記憶部２３は、１つまたは複数のディスク２６ａ、２６ｂ、２６ｃ、２６ｄを含む。ディスク２６ａ、２６ｂ、２６ｃ、２６ｄには、ボリューム管理部２２により論理ボリュームが設定され、その論理ボリューム上にファイルシステムが作成される。
【００４２】
記憶部２３は、記憶部１の一例である。ＦＳＤ２１は、修復部２、書込部３、及び特定部４の一例である。
【００４３】
次に、スナップショットの実現方法について説明する。尚、以下の説明では、スナップショットの取得対象である論理ボリュームを取得対象ボリュームと記す。また、スナップショットを用いることにより、所定時点の取得対象ボリュームのデータの状態が復元可能となるが、この復元可能な時点を静止点と記す。さらに、本実施形態では、スナップショットの取得対象は、アプリケーション２０から使用可能なオンライン状態の所定の論理ボリュームとなる。以下の説明では、アプリケーション２０から使用可能なオンライン状態の論理ボリュームをオンラインボリュームと記す。
【００４４】
スナップショットの実現方法の一例として、本実施形態では、取得対象ボリュームのデータの内容をすべてコピーするのではなく、静止点から変更されたブロックの変更前のデータを所定の記憶領域に退避することにより実現する。この方法では、静止点から変更されていないブロックのデータはコピーされずに、そのブロックへのポインタ（ブロック番号またはＬＢＡ（Logical Block address））が所定の記憶領域に記録される。尚、以下の説明では、静止点から変更されたブロックの変更前のデータを退避する退避先の所定の記憶領域を退避領域と記す。
【００４５】
スナップショットの参照時には、静止点から未変更のブロックのデータに対しては、記憶しておいたポインタを用いて、参照時における取得対象ボリュームのブロックのデータが参照される。これは、静止点と参照時点でデータが変更されていないため、参照時における取得対象ボリュームのデータを静止点におけるブロックのデータとして使用できるからである。そして、静止点から変更のあったブロックのデータに対しては、退避領域に退避したデータが参照される。このようにして、静止点における取得対象ボリュームのディスクイメージが復元可能となる。以下の説明では、静止点から変更されたブロックの変更後の内容を示す変更後イメージをＡＩ（After Image）と記す場合がある。また、静止点から変更されたブロックの変更前の内容を示す変更前イメージをＢＩ（Before Image）と記す場合がある。
【００４６】
次に、具体的なスナップショット機能を実現するためのデータ構成の一例について説明する。スナップショット機能を実現するために、取得対象ボリューム内のデータ、及び、退避領域に退避された、静止点から変更されたブロックの変更前のデータ（ＢＩ）と、例えば、以下の２つの管理表が用いられる。２つの管理表は、すなわち、取得対象ボリュームのブロックのうち静止点から変更されたブロックを特定するための管理表（更新マップ）、及び、静止点から変更されたブロックの変更前のデータが退避されたアドレスを特定するための管理表（退避マップ）である。
【００４７】
更新マップは、取得対象ボリュームに含まれる各ブロックのブロック番号（またはＬＢＡ）と、そのブロック番号のデータが更新されたか否かを示す情報と、を対応付けた管理表である。更新マップにより、取得対象ボリュームのどのブロックが静止点から変更されたのかが特定される。
【００４８】
図３は、更新マップの一例を示す。図３において、更新マップ４１は、６４ビット整数の可変長配列のデータ構造となっている。配列の各ビットはファイルシステムの各ブロックに１対１で対応付けられており、各ビットの値は対応するブロックの静止点からの更新の有無を示している。すなわち、ブロックに更新がある場合には、対応するビットの値に「１」が格納され、ブロックに変更がない場合には、対応するビットの値に「０」が格納される。尚、図３の例の場合、更新マップのエントリ数は、ボリュームサイズ／ブロックサイズ／６４となる。
【００４９】
退避マップは、取得対象ボリュームのブロックのアドレス（またはブロック番号）をキーとして取得し、キーに対応するＢＩのデータが退避された退避領域のアドレスを返す。退避マップにより、取得対象ボリュームのアドレスから、そのアドレスの変更前のデータが退避された退避領域のアドレスが特定される。
【００５０】
図４は、スナップショットの退避マップの一例を示す。図４において、スナップショットの退避マップ５１はＢ＋木の構造をとる。図４の例では、取得対象ボリューム５４のブロック５２のデータが更新され、更新前のデータが退避領域５５のブロック５３に退避されている。このとき、スナップショットの退避マップ５１には、ブロック５２のアドレス（ＬＢＡ）をキーとして、ブロック５３のアドレスが、キー（ブロック５２のＬＢＡ）に対応するレコードに格納されている。尚、Ｂ＋木では、レコードは、木の最下層（葉ノード）に格納され、内部ノードにはキーが格納される。
【００５１】
尚、退避マップ５１のデータ構造はＢ＋木に限定されず取得対象ボリュームのアドレスをキーとして取得し、キーに対応するＢＩのデータが退避された退避領域のアドレスを返すものであれば、種々のアルゴリズムを用いてもよい。
【００５２】
次に、スナップショットの採取開始からの動作について説明する。尚、本実施形態では、スナップショットの採取開始時点を静止点とする。履歴管理部２５は、ＦＳＣＫ部２４からスナップショットの採取要求を受信すると、先ず、取得対象ボリュームに対応する更新マップを作成する。作成時点における更新マップは、取得対象ボリューム内のブロックに対応するすべてのビットの値が０として初期化される。また、履歴管理部２５は、所定の記憶領域にＢＩを退避するための退避領域５５を確保する。この退避領域５５は、スナップショットの取得対象ボリューム内に確保されてもよいし、記憶部２３の他の論理ボリュームに確保されてもよい。さらに、履歴管理部２５は、退避マップ５１を作成する。
【００５３】
その後、取得対象ボリューム（オンラインボリューム）のデータに対して、アプリケーション２０から変更要求が発生すると、履歴管理部２５は、変更対象のブロックの変更前のデータを退避領域５５に退避する。そして、履歴管理部２５は、変更対象のブロックのアドレスに対応する、更新マップ４１のビットの値を「１」に更新する。次に、履歴管理部２５は、変更対象のブロックのアドレスをキーとして、変更前のデータ（ＢＩ）を退避した退避領域５５のアドレスを取得できるように、退避マップ５１を設定する。すなわち、履歴管理部２５は、退避マップ５１に、変更対象のブロックのアドレスをキーとして、変更前のデータ（ＢＩ）を格納した退避領域５５のアドレスのレコードを追加する。そして、履歴管理部２５は、アプリケーション２０からの変更要求の内容にオンラインボリュームのデータを変更する。
【００５４】
次に、スナップショット参照時の動作について説明する。ここで、スナップショットを参照することは、静止点における取得対象ボリュームのイメージを取得することを意味する。
【００５５】
履歴管理部２５は、ＦＳＣＫ部２４からスナップショットの参照要求を受信すると、静止点から参照時までに変更のあったブロックのデータを退避領域５５から取得し、変更のなかったブロックを参照時の取得対象ボリューム５４から取得する。そして、履歴管理部２５は、取得した各々のブロックのデータを統合してＦＳＣＫ部２４に返す。
【００５６】
具体的には、静止点から参照時までに変更のあったブロックのデータを取得するために、履歴管理部２５は、先ず、スナップショットの更新マップ４１を参照して、静止点から変更のあったブロックのアドレスを取得する。そして、履歴管理部２５は、退避マップ５１に、変更のあったブロックのアドレスをキーとして入力し、変更のあったブロックの変更前のデータ（ＢＩ）が格納されている退避領域５５のアドレスを取得する。そして、履歴管理部２５は、取得した退避領域のアドレスに格納されている変更前のデータ（ＢＩ）を取得する。
【００５７】
また、静止点から変更のなかったブロックのデータについては、履歴管理部２５は、参照時点の取得対象ボリューム（オンラインボリューム）のブロックから取得する。そして、履歴管理部２５は、静止点から変更のあったブロックのＢＩと静止点から変更のないブロックのデータを統合して、静止点における取得対象ボリュームのイメージをＦＳＣＫ部２４に返す。
【００５８】
次に、スナップショット廃棄時の動作について説明する。
履歴管理部２５は、ＦＳＣＫ部２４からスナップショットの廃棄要求を受信すると、更新マップ４１、退避マップ５１を削除し、退避領域５５に退避したブロックを削除し、退避領域５５を開放する。
【００５９】
次に、スナップショットに対するクローンの取得について説明する。本実施形態において、スナップショットに対するクローン（以下の説明では、単にクローンと記す）は、ファイルの整合性のチェック及び修復処理を行うために使用される一時的なデータである。すなわち、ファイルの修復処理において、先ずクローンのデータが修復され、クローンに対してなされた修復をオンラインボリュームに反映しても問題ないかが確認された後に、オンラインボリュームに修復が反映される。
【００６０】
尚、スナップショットに対して発生する変更は、オンラインボリュームに対するアプリケーション２０からの入出力による変更であり、クローンに対して発生する変更は、修復処理においてなされる変更である。
【００６１】
クローンの実現方法の一例として、本実施形態では、スナップショットの取得対象ボリュームのデータの内容をすべてコピーするのではなく、所定の時点（静止点）から変更されたブロックの変更後のデータを所定の記憶領域に退避することにより実現する。この方法では、静止点から変更されていないブロックのデータはコピーされずに、そのブロックへのポインタ（ブロック番号またはＬＢＡ）が記録される。尚、以下の説明では、静止点から変更されたブロックの変更後のデータを格納する格納先の記憶領域を修復データ格納領域と記す。修復データ格納領域はスナップショットの退避領域５５と同じ論理ボリュームに確保されてもよいし、異なる論理ボリュームに確保されてもよい。
【００６２】
クローンは、スナップショットを基に作成されるが、クローンと、クローンの基となるスナップショットとは同じ静止点をもつように作成される。
【００６３】
静止点におけるクローンは、静止点におけるスナップショットと同じ内容であり、静止点におけるクローンを参照することは、静止点のスナップショットを参照することと同じとなる。そして、クローンに対する所定のブロックのデータに変更が発生すると、変更後のブロックのデータが修復データ格納領域に格納される。
【００６４】
修復処理によるクローンのデータに対する変更を管理するために、スナップショットと同様に、更新マップが使用される。クローンの更新マップでは、クローンのブロック番号（またはＬＢＡ）と、そのブロック番号のデータが修復処理により変更されたか否かを示す情報と、が対応付けられている。ここで、クローンのブロック番号（またはＬＢＡ）は、対応するスナップショットの取得対象ボリュームのブロック番号（またはＬＢＡ）と同じである。
【００６５】
また、修復処理による変更後のデータが格納された修復データ格納領域のアドレスを特定するために、格納マップが使用される。格納マップは、クローンのアドレス（またはブロック番号）をキーとして取得し、キーに対応する変更後のデータが格納された修復データ格納領域のアドレスを返す。格納マップにより、クローンのアドレスから、そのアドレスの変更後のデータが格納された修復データ格納領域のアドレスが特定される。
【００６６】
図５は、クローンの格納マップの一例を示す。図５において、クローンの格納マップ６１はＢ＋木の構造をとる。図５の例では、クローン６４のブロック６２のデータが更新され、更新後のデータが修復データ格納領域６５のブロック６３に格納されている。このとき、クローンの格納マップ６１には、ブロック６２のアドレス（ＬＢＡ）をキーとして、ブロック６３のアドレスが、キー（ブロック６２のＬＢＡ）に対応するレコードに格納されている。
【００６７】
尚、格納マップ６１のデータ構造はＢ＋木に限定されずクローンのアドレスをキーとして取得し、キーに対応するＡＩが退避された修復データ格納領域のアドレスを返すものであれば、種々のアルゴリズムを用いてもよい。
【００６８】
次に、クローンの採取開始からの運用動作について説明する。尚、本実施形態では、クローンの採取開始時点を、そのクローンの静止点とする。
【００６９】
履歴管理部２５は、ＦＳＣＫ部２４からスナップショットに対するクローンの採取要求を受信すると、先ず、基となるスナップショットに対応する更新マップを作成する。作成時点における更新マップは、スナップショット内のブロックに対応するすべてのビットの値が０として初期化される。尚、スナップショットは、取得対象ボリュームを基に作成されているので、クローンの更新マップのブロックは、取得対象ボリューム内のブロックに対応しているともいえる。また、履歴管理部２５は、所定の記憶領域にＡＩを格納するための修復データ格納領域６５を確保する。この修復データ格納領域６５は、スナップショットの退避領域５５と同じ論理ボリュームに確保されてもよいし、他の論理ボリュームに確保されてもよい。さらに、履歴管理部２５は、クローンの格納マップ６１を作成する。
【００７０】
その後、不整合の修復処理においてＦＳＣＫ部２４からクローンのデータに対して変更要求が発生すると、履歴管理部２５は、変更対象のブロックの変更後のデータをクローンの修復データ格納領域６５に退避する。そして、履歴管理部２５は、変更対象のブロックのアドレスに対応する、更新マップのビットの値を「１」に更新する。次に、履歴管理部２５は、変更対象のブロックのアドレスをキーとして、変更後のデータ（ＡＩ）を格納した修復データ格納領域６５のアドレスを取得できるように、クローンの格納マップ６１を設定する。すなわち、履歴管理部２５は、格納マップ６１に、変更対象のブロックのアドレスをキーとして、変更後のデータ（ＡＩ）を格納した修復データ格納領域６５のアドレスのレコードを追加する。
【００７１】
次に、クローンの参照時の動作について説明する。履歴管理部２５は、ＦＳＣＫ部２４からクローンの参照要求を受信すると、静止点から参照時までに変更のあったブロックのデータを退避領域から取得し、変更のなかったブロックを、静止点におけるスナップショットから取得する。そして、履歴管理部２５は、取得した各々のブロックのデータを統合してＦＳＣＫ部２４に返す。
【００７２】
具体的には、静止点から参照時までに変更のあったブロックのデータを取得するために、履歴管理部２５は、先ず、クローンの更新マップを参照して、静止点から変更のあったブロックのアドレスを取得する。そして、履歴管理部２５は、クローンの格納マップ６１に、変更のあったブロックのアドレスをキーとして入力し、変更のあったブロックの更新後のデータ（ＡＩ）が格納されている修復データ格納領域６５のアドレスを取得する。そして、履歴管理部２５は、取得した修復データ格納領域６５のアドレスに格納されている変更後のデータ（ＡＩ）を取得する。
【００７３】
また、静止点から変更のなかったブロックのデータについては、履歴管理部２５は、静止点におけるスナップショットのブロックから取得する。これは、スナップショットを参照すると、静止点におけるブロックのデータを取得できるからである。よって、履歴管理部２５は、静止点から変更のなかったブロックのデータを、スナップショットを参照することにより取得する。
【００７４】
そして、履歴管理部２５は、静止点から変更のあったブロックのＡＩと静止点から変更のないブロックのデータを統合して、静止点におけるクローンのイメージをＦＳＣＫ部２４に返す。
【００７５】
次に、クローン廃棄時の動作について説明する。
履歴管理部２５は、ＦＳＣＫ部２４からクローンの廃棄要求を受信すると、クローンの更新マップ４１、格納マップ６１を削除し、修復データ格納領域６５に退避したブロックを削除し、修復データ格納領域６５を開放する。
【００７６】
以上のようにして、スナップショット及びクローンの機能を実現する。スナップショット及びクローンでは、変更されたブロックの値のみ複製されるため、整合性のチェック及び修復処理で使用するメモリの量を抑制することができる。
【００７７】
ＦＳＣＫ部２４は、クローンに対して行った修復処理の内容を、取得対象ボリュームに反映する。クローンに対するファイルの整合性チェックと修復処理には所定の時間がかかるが、この間に、オンライン状態の取得対象ボリュームにはアプリケーション２０からの様々な変更が加えられる可能性がある。したがって、修復処理対象のアドレスのデータは、オンラインボリュームでは既にアプリケーション２０により変更されている可能性があり、その場合、修復処理を行ったクローンのデータをオンラインボリュームに反映すると、新たな不整合が生じる可能性がある。
【００７８】
そこで、本実施形態では、先ず、ＦＳＣＫ部２４は、修復処理により変更されたクローンのデータのアドレスと、アプリケーション２０により変更されたオンラインボリュームのデータのアドレスとが一致するか否かを判定する。そして、一致しないと判定した場合に、ＦＳＣＫ部２４は、クローンの修復したデータをオンラインボリュームに反映する。
【００７９】
一方、修復処理により変更されたクローンのデータのアドレスと、アプリケーション２０により変更されたオンラインボリュームのデータのアドレスとが一致する場合には、ＦＳＣＫ部２４は、クローン上の修復したデータをオンラインボリュームには反映しない。この場合は、ＦＳＣＫ部２４は、対象範囲を絞り込んで整合性のチェックと修復処理を再実施する。
【００８０】
この整合性の再チェック及び修復処理の範囲の絞込みについて図６〜図９を参照して説明する。
【００８１】
先ず、クローンに対して行った修復処理の内容を、取得対象ボリュームに反映しても新たな不整合が発生せず、整合性の再チェックが不要なケースについて説明する。整合性の再チェックが不要なケースとは、言い換えると、修復処理が行われたデータのブロックと、整合性のチェック及び修復処理の間にアプリケーション２０からの入出力により変更された取得対象ボリュームのブロックとで一致するものがないケースである。
【００８２】
図６は、整合性チェックと修復処理における、クローンとオンラインボリュームとの関係を説明する図である。図６において、横軸は時刻を表している。そして、時刻Ｔ（ｉ）は、オンラインボリュームのファイルシステムの整合性が取れていることが保証されている時点である。この時刻Ｔ（ｉ）において、Ｔ（ｉ）を静止点としたスナップショット「ｓｎａｐ０」の採取が開始されている。また、時刻Ｔ（ｉ＋１）において、Ｔ（ｉ＋１）を静止点としたスナップショット「ｓｎａｐ１」、クローン「ｃｌｏｎｅ１」の採取が開始されている。
【００８３】
図６において、ＦＳＣＫ部２４は、時刻Ｔ（ｉ＋１）において整合性のチェックを開始する。具体的には、Ｔ（ｉ＋１）において、ＦＳＣＫ部２４は先ず、整合性のチェック及び修復処理対象のブロックの集合（集合Ａと記す）を取得する。ここで、集合Ａは、Ｔ（ｉ）からＴ（ｉ＋１）の間にアプリケーション２０により変更されたオンラインボリュームのブロックである。集合Ａを取得するために、ＦＳＣＫ部２４は、集合Ａの取得要求を履歴管理部２５に送信する。その取得要求を受信すると、履歴管理部２５は、ｓｎａｐ０の更新マップ４１を参照し、更新マップ４１のビット値が「１」であるブロックの集合Ａを取得し、ＦＳＣＫ部２４に取得したブロックの集合Ａを返信する。
【００８４】
そして、ＦＳＣＫ部２４は、集合Ａに含まれるブロックに対して、クローン上で整合性チェック及び修復処理を行う。整合性のチェックにおいて、ＦＳＣＫ部２４は、集合Ａに含まれるブロックの、Ｔ（ｉ）におけるデータとＴ（ｉ＋１）におけるデータとを用いる。
【００８５】
集合Ａに含まれるブロックのＴ（ｉ）におけるデータを取得するために、ＦＳＣＫ部２４は、集合Ａに含まれるブロックのＴ（ｉ）におけるデータの取得要求を履歴管理部２５に送信する。その取得要求を受信すると、履歴管理部２５は先ず、集合Ａに含まれるブロックのそれぞれをキーとしてｓｎａｐ０の退避マップ５１に入力し、集合ＡのブロックのＢＩが退避された退避領域のアドレスを取得する。そして、履歴管理部２５は、取得した退避領域のアドレスに格納されているＢＩのデータを取得し、ＢＩのデータをＦＳＣＫ部２４に返信する。このように取得したＢＩのデータがＴ（ｉ）におけるブロックのデータである。
【００８６】
また、集合Ａに含まれるブロックのＴ（ｉ＋１）におけるデータについても、ＦＳＣＫ部２４は、履歴管理部２５にデータの取得要求を送信する。その取得要求を受信すると、履歴管理部２５は、Ｔ（ｉ＋１）の時点において、オンラインボリュームの集合Ａに含まれるブロックのデータを参照して取得し、ＦＳＣＫ部２４に返信する。
【００８７】
このように取得した集合Ａに含まれるブロックの、Ｔ（ｉ）におけるデータとＴ（ｉ＋１）におけるデータとを用いて、ＦＳＣＫ部２４は整合性のチェックを行う。具体的には、例えば、ＦＳＣＫ部２４は、ファイル割当チェック、ブロック割当チェック、ディレクトリ構成チェック等を行う。
【００８８】
ＦＳＣＫ部２４は、集合Ａに対して整合性のチェックを行った結果、不整合が生じていると判定されたブロックの修復処理を行う。尚、ＦＳＣＫ部２４は、修復処理をｃｌｏｎｅ１に対して行う。修復処理において変更されたブロックは、ｃｌｏｎｅ１の更新マップ、及び格納マップ６１により管理される。
【００８９】
ここで、不整合が生じていると判定されたブロックは２つの種類に分けられる。一つは、実際に修復対象となるブロックであり、もう一つは、他のブロックが修復されることにより不整合が解消されるために、実際には修復されないブロックである。ここで、不整合が生じていると判定されたブロックうち、実際に修復対象となるブロックの集合を集合Ｃ、実際には修復されないブロックの集合を集合ａと記す。例えば、２つのファイルに重複して同じｉｎｏｄｅ番号が割り当てられている場合、一方のファイル（ファイルＸ）に割り当てられたｉｎｏｄｅ番号を修復すれば、他方のファイル（ファイルＹ）の不整合は解消される。この場合、修復されたファイルＸのブロックが集合Ｃに含まれ、実際には修復されないファイルＹのブロックが集合ａに含まれることとなる。
【００９０】
ここでは、Ｔ（ｉ＋１）から開始された整合性チェック及び修復処理は、Ｔ（ｉ＋２）で終了したとする。すると、ＦＳＣＫ部２４は、Ｔ（ｉ＋２）において、Ｔ（ｉ＋１）からＴ（ｉ＋２）の間にアプリケーション２０により変更されたオンラインボリュームのブロック（このブロックの集合を集合Ｂと記す）を取得する。すなわち、ＦＳＣＫ部２４は、Ｔ（ｉ＋２）において、集合Ｂの取得要求を履歴管理部２５に送信する。集合Ｂの取得要求を受信すると、履歴管理部２５は、ｓｎａｐ１の更新マップ４１を参照し、ビットの値が「１」であるブロックを集合Ｂに含まれるブロックとして特定し、ＦＳＣＫ部２４に返信する。また、ＦＳＣＫ部２４は、集合Ｃの取得要求を履歴管理部２５に送信する。集合Ｃの取得要求を受信すると、履歴管理部２５は、クローン上で修復処理を行ったブロックの集合Ｃを取得する。すなわち、履歴管理部２５は、ｃｌｏｎｅ１の更新マップを参照し、ビットの値が「１」であるブロックを集合Ｃに含まれるブロックとして特定する。そして、履歴管理部２５は、特定した集合ＣをＦＳＣＫ部２４に返信する。
【００９１】
そしてＦＳＣＫ部２４は、クローン上で修復処理を行ったブロックの集合Ｃと、Ｔ（ｉ＋１）からＴ（ｉ＋２）の間にアプリケーション２０により変更されたオンラインボリュームのブロックの集合Ｂと、に共通して含まれるブロックが存在するか否かを判定する。
【００９２】
集合Ｃと集合Ｂに共通して含まれるブロックが存在しないと判定した場合、ＦＳＣＫ部２４は、ｃｌｏｎｅ１の修復処理の内容をオンラインボリュームに反映するように履歴管理部２５に指示する。反映の指示を受信すると、履歴管理部２５は、先ず、集合Ｃに含まれる各ブロックのアドレスをキーとしてｃｌｏｎｅ１の格納マップ６１に入力し、集合Ｃに含まれる各ブロックの修復後のデータが格納されている修復データ格納領域６５のアドレスを取得する。そして、取得したアドレスのデータを、履歴管理部２５は、オンラインボリュームの対応するアドレス、すなわち、格納マップ６１にキーとして入力したアドレスに格納する。
【００９３】
この反映処理は、Ｔ（ｉ＋３）で終了する。Ｔ（ｉ＋３）においては、オンラインボリュームのファイルシステムは整合性がとれている状態となる。尚、Ｔ（ｉ+２）とＴ（ｉ＋３）の時間差は僅少である。
【００９４】
ファイルシステムの整合性が保障されている時点から、クローンの修復内容がオンラインボリュームに反映された時点までが一連の整合性チェック及び修復処理であり、この一連の整合性チェック及び修復処理は、所定の時間間隔で繰り返される。すなわち、図６において、Ｔ（ｉ）からＴ（ｉ＋３）までが一連の整合性チェック及び修復処理であり、一連の処理が終了すると、Ｔ（ｉ＋３）をＴ（ｉ）として、次の一連の整合性チェック及び修復処理が開始される。
【００９５】
次に、整合性チェックと修復処理の再実施が行われる場合の、クローンとオンラインボリュームとの関係について説明する。尚、整合性チェックと修復処理の再実施が行われるのは、図６の集合Ｃと集合Ｂに共通して含まれるブロックが存在した場合である。
【００９６】
図７は、整合性チェックと修復処理の再実施における、クローンとオンラインボリュームとの関係を説明する図である。時刻Ｔ（ｉ＋２）においてＦＳＣＫ部２４が集合Ｃと集合Ｂに共通して含まれるブロックが存在するか否かを判定するまでは、整合性のチェック及び修復処理は、図６においてと同様の動作となる。Ｔ（ｉ＋２）における判定の結果、集合Ｃと集合Ｂに共通して含まれるブロックが存在すると判定した場合、ＦＳＣＫ部２４は、対象を絞り込んで、整合性のチェック及び修復処理の再実施を行う。
【００９７】
整合性のチェック及び修復処理の再実施においては、ＦＳＣＫ部２４は、整合性のチェック及び修復処理の対象を、前回の整合性のチェック及び修復処理における集合ａ∪Ｂ∪（Ａ∩Ｃ）とする。
【００９８】
図７において、ＦＳＣＫ部２４は、Ｔ（ｉ＋２）において整合性のチェック及び修復処理の再実行を開始する。具体的には、Ｔ（ｉ＋２）において、ＦＳＣＫ部２４は先ず、整合性のチェック及び修復処理の再実施対象のブロックの集合Ａ’を、前回の整合性のチェック及び修復処理における集合ａ∪Ｂ∪（Ａ∩Ｃ）として設定する。そして、ＦＳＣＫ部２４は、スナップショット「ｓｎａｐ２」及びクローン「ｃｌｏｎｅ２」の採取を開始する。すなわち、ＦＳＣＫ部２４は、ｓｎａｐ２及びｃｌｏｎｅ２の採取を開始するように、履歴管理部２５に指示する。
【００９９】
そして、ＦＳＣＫ部２４は、集合Ａ’に含まれるブロックに対して、クローン上で整合性チェック及び修復処理を行う。整合性のチェックにおいて、ＦＳＣＫ部２４は、集合Ａ’に含まれるブロックの、Ｔ（ｉ）におけるデータとＴ（ｉ＋２）におけるデータとを用いる。
【０１００】
集合Ａ’に含まれるブロックのＴ（ｉ）におけるデータは、上述した集合Ａに含まれるブロックのＴ（ｉ）におけるデータの取得と同様に取得される。
【０１０１】
また、集合Ａ’に含まれるブロックのＴ（ｉ＋２）におけるデータについては、ＦＳＣＫ部２４は、履歴管理部２５に集合Ａ’に含まれるブロックの取得要求を送信する。その取得要求を受信すると、履歴管理部２５は、Ｔ（ｉ＋２）の時点において、オンラインボリュームの集合Ａ’に含まれるブロックのデータを参照して取得し、ＦＳＣＫ部２４に返信する。
【０１０２】
このように取得した集合Ａ’に含まれるブロックの、Ｔ（ｉ）におけるデータとＴ（ｉ＋２）におけるデータとを用いて、ＦＳＣＫ部２４は整合性のチェックの再実施を行う。具体的には、例えば、ＦＳＣＫ部２４は、ファイル割当チェック、ブロック割当チェック、ディレクトリ構成チェック等を行う。
【０１０３】
ＦＳＣＫ部２４は、集合Ａ’に対して整合性のチェックの再実施を行った結果、不整合が生じていると判定したブロックの修復処理を行う。ここで、不整合が生じていると判定されたブロックうち、実際に修復対象となるブロックの集合を集合Ｃ’、実際には修復されないブロックの集合を集合ａ’と記す。
【０１０４】
図７では、Ｔ（ｉ＋２）から開始された整合性チェック及び修復処理は、Ｔ（ｉ＋３）で終了したとする。すると、ＦＳＣＫ部２４は、Ｔ（ｉ＋３）において、Ｔ（ｉ＋２）からＴ（ｉ＋３）の間にアプリケーション２０により変更されたオンラインボリュームのアドレス（このアドレスの集合を集合Ｂ’と記す）を取得する。すなわち、ＦＳＣＫ部２４は、Ｔ（ｉ＋３）において、集合Ｂ’の取得要求を履歴管理部２５に送信する。集合Ｂ’の取得要求を受信すると、履歴管理部２５は、ｓｎａｐ２の更新マップ４１を参照し、ビットの値が「１」であるブロックを集合Ｂ’に含まれるブロックとして特定する。また、ＦＳＣＫ部２４は、クローン上で修復処理を行ったブロックの集合Ｃ’を取得する。すなわち、ＦＳＣＫ部２４は、集合Ｃ’の取得要求を履歴管理部２５に送信する。集合Ｃ’の取得要求を受信すると、履歴管理部２５は、ｃｌｏｎｅ２の更新マップを参照し、ビットの値が「１」であるブロックを集合Ｃ’に含まれるブロックとして特定する。そして、履歴管理部２５は、特定した集合Ｃ’をＦＳＣＫ部２４に返信する。
【０１０５】
そしてＦＳＣＫ部２４は、集合Ｃ’と集合Ｂ’に共通して含まれるブロックが存在するか否かを判定する。
【０１０６】
集合Ｃ’と集合Ｂ’に共通して含まれるブロックが存在しないと判定した場合、ＦＳＣＫ部２４は、ｃｌｏｎｅ２の修復処理の内容をオンラインボリュームに反映するように履歴管理部２５に指示する。反映の指示を受信すると、履歴管理部２５は、先ず、集合Ｃ’に含まれる各ブロックのアドレスをキーとしてｃｌｏｎｅ２の格納マップ６１に入力し、集合Ｃ’に含まれる各ブロックの修復後のデータが格納されている修復データ格納領域６５のアドレスを取得する。そして、取得したアドレスのデータを、履歴管理部２５は、オンラインボリュームの対応するアドレス、すなわち、ｃｌｏｎｅ２の格納マップ６１にキーとして入力したアドレスに格納する。
【０１０７】
この反映処理は、Ｔ（ｉ＋４）終了する。Ｔ（ｉ＋４）においては、オンラインボリュームのファイルシステムは整合性がとれている状態となる。
【０１０８】
次に、整合性のチェック及び修復処理の対象領域について説明する。図８は、修復処理により変更されたクローンのデータのアドレスと、アプリケーション２０により変更されたオンラインボリュームのデータのアドレスとが一致するものが存在しない場合の、取得対象ボリュームのアドレス空間の一例を説明する図である。
【０１０９】
集合Ｕは、オンラインボリューム全体のブロックの集合を示している。
【０１１０】
集合Ａは、整合性チェック及び修復処理の対象となるブロックの集合を示している。ファイルシステムの整合性がとれていることが保証されている所定の時点から変更されたブロックが整合性チェック及び修復処理の対象となるブロックである。集合Ａは、図６におけるＴ（ｉ）からＴ（ｉ＋１）の間に変更されたオンラインボリュームのブロックの集合であるともいえる。
【０１１１】
集合Ｂは、整合性チェック及び修復処理の、開始から終了までの間に、アプリケーション２０により変更されたオンラインボリュームのブロックの集合を示している。
【０１１２】
集合Ｃは、修復処理が行われたブロックの集合を示している。すなわち、集合Ｃに含まれるブロックは、修復処理によりＡＩが修復データ格納領域６５に格納されたオンラインボリュームのブロックの集合である。尚、集合Ｃは、集合Ａ以外のブロックを含む可能性がある。これは、集合Ａのブロックの更新により生じた不整合が、更新されていない他のブロックに不整合を生じさせることがあるからである。例えば、集合Ａに含まれるブロックから構成されるファイルＡと、集合Ａに含まれないブロックから構成されるファイルＢとを考える。このとき、ファイルＡのｉｎｏｄｅ番号が更新されファイルＢのｉｎｏｄｅ番号と重複したとする。この場合、更新さていないファイルＢのｉｎｏｄｅ番号にも不整合が生じることとなる。このように、集合Ａのブロックの更新により生じた不整合が、更新されていない他のブロックに不整合を生じさせる可能性があるため、集合Ｃは、集合Ａ以外のブロックを含む可能性がある。
【０１１３】
尚、集合Ｃには、整合性チェックにおいて不整合が見つかったブロックに対して修復処理を行った結果、新たに修復が必要となり修復が行われたブロックも含まれてもよい。
【０１１４】
集合ａは、整合性チェックにおいて不整合が見つかったブロックのうちで、他のブロックを修復することにより、不整合が解消されるブロックの集合を示している。すなわち、集合ａに含まれるブロックは、自身の修復処理は行われることなく不整合が解消されるブロックである。
【０１１５】
図８の例においては、集合Ｂと集合Ｃが重なっている部分がなく、集合Ｂと集合Ｃの両方に含まれるブロックは存在しない。これは、修復処理により変更されたクローンのデータのアドレスと、整合性のチェック及び修復処理中にアプリケーション２０により変更されたオンラインボリュームのデータのアドレスとが一致するものが存在しないことを示している。このような場合、整合性の再チェックは不要であり、集合Ｃに含まれるアドレスのデータをオンラインボリュームの対応するアドレスに反映することで、修復処理が終了する。
【０１１６】
図９は、修復処理により変更されたクローンのデータのアドレスと、整合性のチェック及び修復処理中に変更されたオンラインボリュームのデータのアドレスとが一致するものが存在する場合の、取得対象ボリュームのアドレス空間の一例を説明する図である。
【０１１７】
図９において、集合Ｕ、Ａ、Ｂ、Ｃ、ａはそれぞれ、図８における集合Ｕ、Ａ、Ｂ、Ｃ、ａに対応している。図９を参照すると、集合Ｂと集合Ｃが重なっている部分があり（Ｂ∩Ｃ≠φ）、集合Ｂと集合Ｃの両方に含まれるブロックが存在する。これは、修復処理により変更されたクローンのデータのアドレスと、整合性のチェック及び修復処理の間に、アプリケーション２０により変更されたオンラインボリュームのデータのアドレスとが一致するものが存在することを示している。このような場合、チェックの対象範囲を絞った上で、整合性のチェック及び修復処理が再実施される。
【０１１８】
整合性の再チェックの対象範囲は、図９において、集合ａ∪Ｂ∪（Ａ∩Ｃ）の範囲となる。これにより、整合性のチェック及び修復処理の再実施にかかる時間を削減することができる。
【０１１９】
対象を絞り込んだ後に行われる整合性のチェック及び修復処理の再実施方法は、最初に行われる整合性のチェック及び修復処理と同様にして行われる。
【０１２０】
図１０は、整合性の再チェック及び修復処理の対象範囲を説明する図である。図９と比較するために、図９の集合Ａ、Ｂ、Ｃ、ａに相当する集合を、図１０においては、Ａ’、Ｂ’、Ｃ’、ａ’として記す。すると、Ａ’＝ａ∪Ｂ∪（Ａ∩Ｃ）となる。そして、Ａ’を対象範囲として、整合性のチェック及び修復処理が再実施され、Ｂ’とＣ’の両方に含まれるブロックが存在するか否かが判定される。Ｂ’とＣ’の両方に含まれるブロックが存在しないと判定した場合には、ＦＳＣＫ部２４は、クローンのＣ’のブロックに対して行った修復内容をオンラインボリュームに反映する。一方、Ｂ’とＣ’の両方に含まれるブロックが存在すると判定した場合、ＦＳＣＫ部２４は、ａ’∪Ｂ’∪（Ａ’∩Ｃ’）を対象範囲として、整合性のチェック及び修復処理を行う。図１０の場合、Ｂ’とＣ’の両方に含まれるブロックが存在するため、ＦＳＣＫ部２４は、ａ’∪Ｂ’∪（Ａ’∩Ｃ’）を対象範囲として、整合性のチェック及び修復処理を再実施する。
【０１２１】
ａ’∪Ｂ’∪（Ａ’∩Ｃ’）を対象範囲として行う整合性のチェック及び修復処理の再々実施は、ａ∪Ｂ∪（Ａ∩Ｃ）を対象範囲として行う整合性のチェック及び修復処理と同様に行われる。
【０１２２】
このように、整合性のチェック及び修復処理が繰り返されても、徐々に対象範囲が狭まっていくこととなる。従って、整合性のチェックおよび修復処理の再実施を繰り返しても、処理すべき領域が増大し続けることを回避することができる。これにより、ファイルシステムが例えばペタバイト級に増大しても、整合性のチェックおよび修復処理をオンラインで実行することができる。
【０１２３】
次に、ファイルシステムの不整合のチェックおよび修復処理の動作について、図１１及び図１２を参照して説明する。
【０１２４】
図１１は、ファイルシステムの不整合のチェックおよび修復処理の処理内容を図解したフローチャートの前半である。図１２は、ファイルシステムの不整合のチェックおよび修復処理の処理内容を図解したフローチャートの後半である。尚、図１１、１２の説明においてオンラインボリュームとは、整合性のチェック対象及び修復の対象となるオンラインボリュームのことを指すものとする。また、図１１、１２における集合Ａ、Ｂ、Ｃ、ａは、それぞれ、図８〜１０における集合Ａ、Ｂ、Ｃ、ａに対応するものとする。
【０１２５】
図１１のフローにおいて、先ず、ＦＳＣＫ部２４は、オンラインボリュームの整合性が保証されている所定の時点で、オンラインボリュームのスナップショットｓｎａｐ０の採取を開始するように履歴管理部２５に指示する（Ｓ１０１）。この採取の開始時点をｓｎａｐ０の静止点とする。
【０１２６】
次に、ＦＳＣＫ部２４は、ｓｎａｐ０の静止点からのオンラインボリュームに対する更新量が所定の閾値以上であるか否かを判定する（Ｓ１０２）。この判定では、ＦＳＣＫ部２４は、先ず、履歴管理部２５にｓｎａｐ０の静止点からのオンラインボリュームに対する更新量の取得要求を送信する。その取得要求を受信すると、履歴管理部２５は、ｓｎａｐ０の更新マップを参照することにより更新量を取得し、ＦＳＣＫ部２４に取得した更新量を返信する。具体的には例えば、履歴管理部２５は、ｓｎａｐ０の更新マップのビット値が「１」であるブロックの数を更新量として返してもよいし、ｓｎａｐ０の更新マップのビット値が「１」であるブロックの数にブロックサイズを掛けた値を更新量として返してもよい。ＦＳＣＫ部２４は、履歴管理部２５からｓｎａｐ０の静止点からのオンラインボリュームに対する更新量を受信すると、その更新量が所定の閾値以上か否かを判定する。すなわち、例えば、ｓｎａｐ０の更新マップのビット値が「１」であるブロックの数が所定の閾値以上である場合、ＦＳＣＫ部２４は、更新量が所定の閾値以上であると判定する。また、ｓｎａｐ０の更新マップのビット値が「１」であるブロックの数が所定の閾値未満である場合、ＦＳＣＫ部２４は、更新量が所定の閾値未満であると判定する。尚、所定の閾値はＦＳＣＫ部２４の所定の記憶領域に記憶されたものか、または記憶部２３に記憶されたものをＦＳＣＫ部２４が所定の記憶領域に読み込むことによって使用する。
【０１２７】
ｓｎａｐ０の静止点からの更新量が所定の閾値未満であると判定された場合（Ｓ１０２でＮｏ）、再度Ｓ１０２が繰り返される。一方、ｓｎａｐ０の静止点からのオンラインボリュームに対する更新量が所定の閾値以上であると判定した場合（Ｓ１０２でＹｅｓ）、ＦＳＣＫ部２４は、スナップショットｓｎａｐ１、及びｓｎａｐ１を基としたクローンｃｌｏｎｅ１の採取を開始するように履歴管理部２５に指示する（Ｓ１０３）。この採取の開始時点をｓｎａｐ１及びｃｌｏｎｅ１の静止点とする。
【０１２８】
次に、ＦＳＣＫ部２４は、ｓｎａｐ０の静止点からオンラインボリュームに対して更新されたブロックの集合Ａを特定する（Ｓ１０４）。具体的には、ＦＳＣＫ部２４は、ｓｎａｐ０の静止点からオンラインボリュームに対して更新されたブロックの集合Ａの取得要求を履歴管理部２５に送信する。その取得要求を受信すると、履歴管理部２５は、ｓｎａｐ０の更新マップを参照することによりブロックの集合Ａを取得し、ＦＳＣＫ部２４に取得したブロックの集合Ａを返信する。すなわち、履歴管理部２５は、ｓｎａｐ０の更新マップのビット値が「１」であるブロックのブロック番号（またはＬＢＡ）の集合をＦＳＣＫ部２４に返信する。ここで特定されるブロックの集合Ａは、整合性チェック及び修復処理の対象となるブロックの集合である。
【０１２９】
次に、ＦＳＣＫ部２４は、Ｓ１０４で特定した集合Ａと、この集合Ａに含まれるブロックの変更前後のデータとを基に、ｃｌｏｎｅ１上で集合Ａの範囲で整合性チェック及び修復処理を行う（Ｓ１０５）。ここで、集合Ａに含まれるブロックの変更前後のデータは、言い換えると、オンラインボリュームにおけるｓｎａｐ０の静止点とｓｎａｐ１の静止点との差分である。ＦＳＣＫ部２４は、整合性のチェック及び修復処理の結果から、修復処理を行ったブロックの集合Ｃを特定する（Ｓ１０６）。また、ＦＳＣＫ部２４は、整合性チェックの結果、修復対象と判定されたブロックのうち、他のブロックを修復することにより、不整合が解消されるブロックの集合ａを特定する（Ｓ１０７）。
【０１３０】
次に、ＦＳＣＫ部２４は、Ｓ１０５の整合性チェックの結果、不整合が発生しているブロックが存在するか否かを判定する（Ｓ１０８）。すなわち、ＦＳＣＫ部２４は、集合Ｃ及び集合ａに含まれるブロックが存在するか否かを判定する。
【０１３１】
不整合が発生しているブロックが存在しないと判定した場合（Ｓ１０８でＮｏ）、ＦＳＣＫ部２４は、ｓｎａｐ０、ｃｌｏｎｅ１、及び集合Ａ、ａ、Ｃを破棄する（Ｓ１０９）。すなわち、ＦＳＣＫ部２４は、履歴管理部２５にｓｎａｐ０及びｃｌｏｎｅ１の廃棄要求を送信するとともに、集合Ａ、ａ、Ｃを削除する。そして、ＦＳＣＫ部２４は、ｓｎａｐ１をｓｎａｐ０として新たに設定する（Ｓ１１０）。そして、処理は、Ｓ１０２に遷移する。
【０１３２】
Ｓ１０８において、不整合が発生しているブロックが存在すると判定した場合（Ｓ１０８でＹｅｓ）、ＦＳＣＫ部２４は、ｓｎａｐ１の静止点から更新されたオンラインボリュームのブロックの集合Ｂを特定する（Ｓ１１１）。具体的には、ＦＳＣＫ部２４は、ｓｎａｐ１の静止点からオンラインボリュームに対して更新されたブロックの集合Ｂの取得要求を履歴管理部２５に送信する。その取得要求を受信すると、履歴管理部２５は、ｓｎａｐ１の更新マップを参照することによりブロックの集合Ｂを取得し、ＦＳＣＫ部２４に取得したブロックの集合Ｂを返信する。すなわち、履歴管理部２５は、ｓｎａｐ１の更新マップのビット値が「１」であるブロックのブロック番号（またはＬＢＡ）の集合をＦＳＣＫ部２４に返信する。
【０１３３】
次に、ＦＳＣＫ部２４は、Ｓ１０６で特定した集合ＣとＳ１１１で特定した集合Ｂの両方に含まれるブロックが存在するか否か（Ｂ∩Ｃ≠φか否か）を判定する（Ｓ１１２）。すなわち、ＦＳＣＫ部２４は、集合Ｃのブロックのアドレスと集合Ｂのブロックのアドレスとで一致するものがあるか否かを判定する。集合Ｃと集合Ｂの両方に含まれるブロックが存在する（Ｂ∩Ｃ≠φ）と判定した場合（Ｓ１１２でＹｅｓ）、ＦＳＣＫ部２４は、対象範囲を絞って整合性のチェック及び修復処理を再度行うために、集合Ａをａ∪Ｂ∪（Ａ∩Ｃ）に更新する（Ｓ１１３）。そして、ＦＳＣＫ部２４は、ｓｎａｐ１、ｃｌｏｎｅ１、集合ａ、Ｂ、Ｃを破棄する（Ｓ１１４）。すなわち、ＦＳＣＫ部２４は、履歴管理部２５にｓｎａｐ１、及びｃｌｏｎｅ１の廃棄要求を送信し、集合ａ、Ｂ、Ｃを破棄する。次に、ＦＳＣＫ部２４は、ｓｎａｐ１、及びｃｌｏｎｅ１を再採取するように履歴管理部２５に指示する（Ｓ１１５）。尚、再採取を開始した時点がｓｎａｐ１、及びｃｌｏｎｅ１の新たな静止点となる。そして、処理はＳ１０５に遷移する。
【０１３４】
一方、Ｓ１１２において、集合Ｃと集合Ｂの両方に含まれるブロックが存在しない（Ｂ∩Ｃ＝φ）と判定した場合（Ｓ１１２でＮｏ）、処理は、Ｓ１１６（図１２参照）に遷移する。
【０１３５】
Ｓ１１２において、集合Ｃと集合Ｂの両方に含まれるブロックが存在しないと判定した場合、図１２において、ＦＳＣＫ部２４は、集合Ｃに含まれるブロックの変更後のデータをオンラインボリュームに反映するように履歴管理部２５に指示する（Ｓ１１６）。反映の指示を受信すると、履歴管理部２５は、先ず、集合Ｃに含まれるブロックのアドレスをキーとしてｃｌｏｎｅ１の格納マップ６１に入力し、変更後のデータ（ＡＩ）が格納された修復データ格納領域６５のアドレスを取得する。次に、履歴管理部２５は、取得した修復データ格納領域６５のアドレスを参照して、変更後のデータ（ＡＩ）を取得する。そして、履歴管理部２５は、オンラインボリュームの集合Ｃに含まれるブロックを変更後のデータ（ＡＩ）に変更する。
【０１３６】
次に、ＦＳＣＫ部２４は、ｓｎａｐ０、ｓｎａｐ１、ｃｌｏｎｅ１、集合Ａ、ａ、Ｂ、Ｃの破棄を行う（Ｓ１１７）。すなわち、ＦＳＣＫ部２４は、履歴管理部２５にｓｎａｐ０、ｓｎａｐ１、及びｃｌｏｎｅ１の廃棄要求を送信し、集合Ａ、ａ、Ｂ、Ｃを削除する。そして、ＦＳＣＫ部２４は、ｓｎａｐ０を再採取するように履歴管理部２５に指示し（Ｓ１１８）、処理をＳ１０２（図１１参照）に遷移させる。
【０１３７】
次に、情報処理装置１０の構成について説明する。図１３は、情報処理装置のハードウェア構成の一例を示す。
【０１３８】
情報処理装置１０は、ＣＰＵ４０１、メモリ４０２、記憶装置４０３、読取装置４０４、及び通信インターフェース４０５を含む。ＣＰＵ４０１、メモリ４０２、記憶装置４０３、読取装置４０４、及び通信インターフェース４０５はバスを介して接続される。
【０１３９】
ＣＰＵ４０１は、メモリ４０２を利用して上述のフローチャートの手順を記述したプログラムを実行することにより、アプリケーション２０、ＦＳＤ２１、ボリューム管理部２２の一部または全部の機能を提供する。
【０１４０】
メモリ４０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。記憶装置４０３は、例えばハードディスクであり、実施形態の整合性のチェック及び修復処理に関わるプログラムを格納する。なお、記憶装置４０３は、フラッシュメモリ等の半導体メモリであってもよい。また、記憶装置４０３は、外部記録装置であってもよい。メモリ４０２または記憶装置４０３は、スナップショット、及びクローンを実現するためのデータを格納する。すなわち、メモリ４０２または記憶装置４０３は、例えば、スナップショットの更新マップ、スナップショットの退避マップ、クローンの更新マップ、及びクローンの格納マップの何れかまたは全てを格納する。メモリ４０２または記憶装置４０３は、記憶部２３の一部または全部の機能を提供する。
【０１４１】
読取装置４０４は、ＣＰＵ４０１の指示に従って着脱可能記録媒体４５０にアクセスする。着脱可能記録媒体４５０は、たとえば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。尚、読取装置４０４は情報処理装置１０に含まれなくてもよい。
【０１４２】
通信インターフェース４０５は、他の情報処理装置に接続し、ＣＰＵ４０１の指示に従ってネットワークを介して、アプリケーション２０と他の情報処理装置１０の間でデータを送受信する。尚、通信インターフェース４０５は情報処理装置１０に含まれなくてもよい。
【０１４３】
実施形態の通信プログラムは、例えば、下記の形態で情報処理装置１０に提供される。
（１）記憶装置４０３に予めインストールされている。
（２）着脱可能記録媒体４５０により提供される。
（３）プログラムサーバ（図示せず）から通信インターフェース４０５を介して提供される。
【０１４４】
情報処理装置１０の構成の他の例について説明する。図１４は、情報処理装置１０のハードウェア構成のうち、記憶装置４０３がＣＭ（Controller Module）を含み、通信インターフェースを介して情報処理装置１０と接続される構成の一例である。
【０１４５】
記憶装置４０３は、ＣＭ５００、ディスク５０４ａ、５０４ｂ、及び通信インターフェース５０５を含む。
【０１４６】
ＣＭ５００は、ＣＰＵ５０１、メモリ５０２、ＤＡ（Device Adapter）５０３ａ、５０３ｂを含む。ＣＰＵ５０１は、ＣＭ５００の動作を制御する。メモリ５０２は、ＣＭ５００の制御に用いられる各種情報を記憶する。ＣＰＵ５０１は、ボリューム管理部の一部または全ての機能を提供する。尚、ＣＰＵ５０１がボリューム管理部２２の全ての機能を提供する場合、情報処理装置１０のＣＰＵ４０１は、ボリューム管理部２２の機能は提供しない構成としてもよい。メモリ５０２は、例えば半導体メモリであり、ＲＡＭ領域およびＲＯＭ領域を含んで構成される。また、メモリ５０２は、ＣＰＵ５０１に実行させる処理が記述されたプログラムを記憶する。メモリ５０２は例えば、スナップショットの更新マップ、スナップショットの退避マップ、クローンの更新マップ、及びクローンの格納マップの何れかまたは全てを格納してもよい。ＤＡ５０３ａ、５０３ｂは、それぞれディスク５０４ａ，５０４ｂに接続され、接続されたディスクへのデータの入出力を行う。
【０１４７】
ディスク５０４ａ、５０４ｂは、例えばハードディスクである。ディスク５０４ａ、５０４ｂは、フラッシュメモリ等の半導体メモリであってもよい。また、ディスク５０４ａ、５０４ｂは、記憶部２３の一部または全部の機能を提供する。
【０１４８】
通信インターフェース５０５は、情報処理装置１０の通信インターフェース４０５に接続し、ＣＰＵ５０１の指示に従ってネットワークを介して、データを送受信する。
【０１４９】
尚、本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【０１５０】
上記実施形態に関し、更に以下の付記を開示する。
（付記１）
ファイルシステムによって管理される第１の記憶領域と、データを格納する第２の記憶領域と、を含む記憶部と、
前記第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する修復部と、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む書込部と、
を含むことを特徴とする情報処理装置。
（付記２）
前記情報処理装置は、さらに、
前記第１の記憶領域において、所定期間内に更新されたデータが格納されたアドレスを特定する特定部
を含み、
前記修復部は、前記第１の記憶領域において特定された前記アドレスから読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行う
ことを特徴とする付記１に記載の情報処理装置。
（付記３）
前記修復部は、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記異常データの読み出し元のアドレスのうち前記所定期間内に更新されたデータが格納されたアドレスと、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する
ことを特徴とする付記２に記載の情報処理装置。
（付記４）
前記書込部は、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データのうちの前記修復されたデータの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む
ことを特徴とする付記１に記載の情報処理装置。
（付記５）
コンピュータに、
ファイルシステムによって管理される第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納し、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む、
処理を実行させることを特徴とするデータ修復プログラム。
（付記６）
コンピュータに、
前記第１の記憶領域において、所定期間内に更新されたデータが格納されたアドレスを特定し、
前記第１の記憶領域において特定された前記アドレスから読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行う
処理を実行させることを特徴とする付記５に記載のデータ修復プログラム。
（付記７）
コンピュータに、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記異常データの読み出し元のアドレスのうち前記所定期間内に更新されたデータが格納されたアドレスと、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する
処理を実行させることを特徴とする付記６に記載のデータ修復プログラム。
（付記８）
コンピュータに、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データのうちの前記修復されたデータの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む
処理を実行させることを特徴とする付記５に記載のデータ修復プログラム。
（付記９）
ファイルシステムによって管理される第１の記憶領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して第２の記憶領域に格納する修復処理を行い、前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納し、
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における、前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む、
処理を実行することを特徴とするデータ修復方法。
（付記１０）
前記第１の記憶領域において、所定期間内に更新されたデータが格納されたアドレスを特定し、
前記第１の記憶領域において特定された前記アドレスから読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データである異常データを修復して前記第２の記憶領域に格納する修復処理を行う
処理を実行することを特徴とする付記９に記載のデータ修復方法。
（付記１１）
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データの読み出し元のアドレスとが一致する場合に、前記異常データの読み出し元のアドレスのうち前記所定期間内に更新されたデータが格納されたアドレスと、前記第１の記憶領域における前記修復処理の間に変更されたデータのアドレスとが示す領域から読み出したデータについて異常があるかを検出し、検出の結果、異常が検出された該データを修復して前記第２の記憶領域に格納する
処理を実行することを特徴とする付記１０に記載のデータ修復方法。
（付記１２）
前記第１の記憶領域において前記修復処理の間に変更されたデータのアドレスと、前記異常データのうちの前記修復されたデータの読み出し元のアドレスとが一致しない場合に、前記第１の記憶領域における前記異常データの読み出し元のアドレスに前記修復されたデータを書き込む
処理を実行することを特徴とする付記９に記載のデータ修復方法。
【符号の説明】
【０１５１】
１        記憶部
２        修復部
３        書込部
４        特定部
５        第１の記憶領域
６        第２の記憶領域
１０      情報処理装置
２０      アプリケーション
２１      ＦＳＤ
２２      ボリューム管理部
２３      記憶部
２４      ＦＳＣＫ部
２５      履歴管理部
４１      更新マップ
５１      退避マップ
５２      ブロック
５３      ブロック
５４      取得対象ボリューム
５５      退避領域
６１      格納マップ
６２      ブロック
６３      ブロック
６４      クローン
６５      修復データ格納領域
４０１    ＣＰＵ
４０２    メモリ
４０３    記憶装置
４０４    読取装置
４０５    通信インターフェース
４５０    着脱可能記録媒体
５００    ＣＭ
５０１    ＣＰＵ
５０２    メモリ
５０３    ＤＡ
５０４    ディスク
５０５    通信インターフェース
【図１】
2015049633.tif 000003
【図２】
2015049633.tif 000004
【図３】
2015049633.tif 000005
【図４】
2015049633.tif 000006
【図５】
2015049633.tif 000007
【図６】
2015049633.tif 000008
【図７】
2015049633.tif 000009
【図８】
2015049633.tif 000010
【図１１】
2015049633.tif 000011
【図１２】
2015049633.tif 000012
【図１３】
2015049633.tif 000013
【図１４】
2015049633.tif 000014
【図９】
2015049633.tif 000015
【図１０】
2015049633.tif 000016