(57)【特許請求の範囲】
【請求項１】
オブジェクトを構成するデータをファイルとして記憶するオブジェクトストレージシステムであって、前記ファイルを記憶する記憶装置と、前記ストレージシステムを制御するオペレーティングシステムと、前記ファイルを前記オブジェクトと対応付けて管理するオブジェクト管理手段と、を有し、前記記憶装置は前記ファイルの更新履歴を保持するジャーナルを有し、前記オブジェクト管理手段は前記ファイルに前記オブジェクトとの対応を示すオブジェクト識別子を設定するオブジェクト識別子設定手段を有し、前記オペレーティングシステムは前記記憶装置および前記ファイルを制御するファイルシステムと前記ファイルシステムのマウント時に前記記憶装置で更新された前記ファイルを検証するマウント時更新ファイル検証手段を有し、前記ファイルシステムは前記ファイル検証手段が発見したオブジェクト識別子付破損ファイルを格納するオブジェクト識別子付破損ファイル格納手段を有する、ことを特徴とするオブジェクトストレージシステム。
【請求項２】
前記オブジェクト管理手段が、前記オブジェクトを他のストレージシステムから複製して前記オブジェクト識別子付破損ファイルを修復するオブジェクト修復手段を有している、ことを特徴とする請求項１に記載のオブジェクトストレージシステム。
【請求項３】
前記オブジェクト識別子付破損ファイル格納手段が、前記オブジェクト識別子付破損ファイルを前記オブジェクト識別子が識別可能なファイル名で格納する、ことを特徴とする請求項１または請求項２に記載のオブジェクトストレージシステム。
【請求項４】
前記オブジェクト識別子付破損ファイル格納手段が、前記オブジェクト識別子が識別可能な名前のフォルダを生成するオブジェクト識別子付破損ファイル格納フォルダ生成手段を、有していることを特徴とする請求項３に記載のオブジェクトストレージシステム。
【請求項５】
オブジェクトを構成するデータをファイルとして記憶するオブジェクトストレージシステムの制御方法であって、オブジェクト管理手段が前記ファイルに前記オブジェクトとの対応を示すオブジェクト識別子を設定し、ファイルシステムが記憶装置に前記ファイルを格納し、前記ファイルシステムが前記ファイルの更新履歴を前記記憶装置内のジャーナルに格納し、前記ファイルシステムのマウント時にマウント時更新ファイル検証手段が前記ジャーナルを参照して更新された前記ファイルを検証し、前記マウント時更新ファイル検証手段が発見したオブジェクト識別子付破損ファイルをオブジェクト識別子付破損ファイル格納手段に格納する、ことを特徴とするオブジェクトストレージシステムの制御方法。
【請求項６】
前記オブジェクトを他のストレージシステムから複製して前記オブジェクト識別子付破損ファイルを修復する、ことを特徴とする請求項５に記載のストレージシステムの制御方法。
【請求項７】
前記オブジェクト識別子付破損ファイル格納手段が、前記オブジェクト識別子付破損ファイルを前記オブジェクト識別子が識別可能なファイル名で保存する、ことを特徴とする請求項５または請求項６に記載のオブジェクトストレージシステムの制御方法。
【請求項８】
前記オブジェクト識別子付破損ファイル格納手段が、前記オブジェクト識別子が識別可能な名前のフォルダを生成し、対応する前記フォルダの配下に前記オブジェクト識別子付破損ファイルを格納する、ことを特徴とする請求項７に記載のオブジェクトストレージシステムの制御方法。
【請求項９】
オブジェクトを構成するデータをファイルとして記憶するオブジェクトストレージシステムの制御プログラムであって、オブジェクト管理手段が前記ファイルに前記オブジェクトとの対応を示すオブジェクト識別子を設定するステップと、ファイルシステムが記憶装置に前記ファイルを格納するステップと、前記ファイルシステムが前記ファイルの更新履歴を前記記憶装置内のジャーナルに格納するステップと、前記ファイルシステムのマウント時にマウント時更新ファイル検証手段が前記ジャーナルを参照して更新された前記ファイルを検証するステップと、前記マウント時更新ファイル検証手段が発見したオブジェクト識別子付破損ファイルをオブジェクト識別子付破損ファイル格納手段に格納するステップと、を有することを特徴とするオブジェクトストレージシステムの制御プログラム。
【請求項１０】
前記オブジェクト識別子付破損ファイル格納手段が、前記オブジェクト識別子付破損ファイルを前記オブジェクト識別子が識別可能なファイル名で保存するステップを有する、ことを特徴とする請求項９に記載のオブジェクトストレージシステムの制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクトストレージシステムおよびその制御方法およびその制御プログラムに関する。
【背景技術】
【０００２】
オブジェクトストレージシステムは一連のデータをオブジェクトとして取り扱うシステムである。ファイルベースのオブジェクトストレージのオペレーティングシステム（ＯＳ）は、記憶装置へ記録したデータを制御するために、ファイルシステムを持つ。ファイルシステムは記憶装置内の記憶空間を分割し、分割した記憶空間にデータの格納先となるファイルを作成する。そしてファイルシステムはファイルおよび他の記憶空間をどのように使うか管理する。大容量のオブジェクトの場合、所定単位以下の大きさのデータに分割され、それぞれのデータがファイルに格納される。このようなファイルシステムの中には、障害からの復旧を速やかに行うため、処理のログを記録するものがある。このようなファイルシステムはジャーナリングファイルシステムと呼ばれる。ジャーナリングファイルシステムについての一般的な解説は、例えば非特許文献１に記載されている。
【０００３】
また一般的なストレージシステムでは、例えば非特許文献２に記載されているように、ファイル検証プログラムが常駐し、格納されている全てのファイルの完全性を定期的に検証している。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】ウィキペディア（登録商標）、“ジャーナリングファイルシステム”、［２０１４年３月２５日検索]、インターネット＜ＵＲＬ：http://ja.wikipedia.org/wiki/%E3%82%B8%E3%83%A3%E3%83%BC%E3%83%8A%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0＞
【非特許文献２】ヴィーエー・リナックス・システムズ・ジャパン株式会社Ｗｅｂサイト、“ＯｐｅｎＳｔａｃｋ：分散オブジェクトストレージ Ｓｗｉｆｔ”、［２０１４年３月２５日検索]、インターネット＜ＵＲＬ：http://www.valinux.co.jp/technologylibrary/document/cloud/openstack0001＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、非特許文献２のように、ファイル検証プログラムが常駐し全ファイルのデータ検証を行う方法では、格納するデータ量が多くなると、システムの負荷が大きくなるという問題がある。具体的には１００万オブジェクトで数十％のＣＰＵ負荷や入出力負荷を消費する。
【０００６】
本発明は上記の問題に鑑みてなされたものであり、ファイル検証プログラムの常駐および全ファイルの検証を必要としないデータ検証方法を提供し、データ検証によるシステム負荷を削減することを目的としている。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明のオブジェクトストレージシステムは、オブジェクトを構成するデータをファイルとして記憶するオブジェクトストレージシステムであって、前記ファイルを記憶する記憶装置と、前記ストレージシステムを制御するオペレーティングシステムと、前記ファイルを前記オブジェクトと紐付けて管理するオブジェクト管理手段と、を有し、前記記憶装置は前記ファイルの更新履歴を保持するジャーナルを有し、前記オブジェクト管理手段は前記ファイルに前記オブジェクトとの対応を示すオブジェクト識別子を設定するオブジェクト識別子設定手段を有し、前記オペレーティングシステムは前記記憶装置および前記ファイルを制御するファイルシステムと前記オペレーティングシステムのマウント時に前記記憶装置で更新された前記ファイルを検証するマウント時更新ファイル検証手段を有し、前記ファイルシステムは前記ファイル検証手段が発見した破損ファイルを前記オブジェクト識別子と対応付けて格納するオブジェクト識別子付破損ファイル格納手段を有する、を有している。
【発明の効果】
【０００８】
本発明の効果は、データ検証のためのシステム負荷が軽減されることである。また破損ファイルの属性を速やかに特定し修復できることである。
【図面の簡単な説明】
【０００９】
【図１】本発明第１の実施の形態を示すブロック図である。
【図２】本発明第１の実施の形態の動作を示すフローチャートである。
【図３】本発明第２の実施の形態を示すブロック図である。
【図４】本発明第２の実施の形態の動作を示すフローチャートである。
【図５】一般的な技術のメタデータを示す構成図である。
【図６】本発明第３の実施の形態のメタデータを示す構成図である。
【図７】本発明第４の実施の形態のファイル格納動作を示すシーケンス図である。
【図８】本発明第５の実施の形態を示すディレクトリ構成図の一例である。
【図９】一般的な技術のディレクトリ構成図の一例である。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら本発明について詳細に説明する。
（第１の実施の形態）
本発明のオブジェクトストレージシステムは、オブジェクトを構成するデータをファイルとして記憶する、ファイルベースのオブジェクトストレージシステムに関する。
【００１１】
図１は本実施の形態のオブジェクトストレージシステム１００を示すブロック図である。オブジェクトストレージシステム１００は、ファイル１１を記憶する記憶装置１０と、オペレーティングシステム２０と、ファイル１１をオブジェクト１と紐付けて管理するオブジェクト管理手段３０と、を有する。オペレーティングシステム２０は、記憶装置１０を含む接続装置を制御したり、アプリケーションプログラムとデバイス、アプリケーションプログラム間の仲立ちや制御を行ったりする。なお、オブジェクト管理手段３０は、オペレーティングシステム２０内で実装していてもよい。また、以降、オペレーティングシステム２０をＯＳ２０とも称する。
【００１２】
記憶装置１０は、ファイル１１の記憶領域の他に、ファイル１１の更新履歴を保持するジャーナル１２を有する。
【００１３】
オブジェクト管理手段３０は、ファイル１１にオブジェクト１との対応を示すオブジェクト識別子２を設定するオブジェクト識別子設定手段３１を有する。一般的な形式では、ファイル１１にはデータ３とメタデータ４とが含まれるが、オブジェクト識別子２は、例えばメタデータ４の一要素として設定される。
【００１４】
オペレーティングシステム２０は、オブジェクトストレージシステム１００の動作を制御する。そして、ファイルシステム４０と、マウント時更新ファイル検証手段５０とを有する。
【００１５】
ファイルシステム４０は、ファイル１１を制御する。ここで、ファイル１１の制御には、例えば、記憶装置１０の記憶空間を分割してファイル１１を配置したり、ファイル１１が属するディレクトリの階層構造を制御したりすることが含まれる。
【００１６】
マウント時更新ファイル検証手段５０は、ファイルシステム４０のマウント時に、記憶装置１０において更新されたファイル１１を検証する。更新されたファイル１１の特定は、ジャーナル１２を参照することによって行う。
【００１７】
ファイルシステム４０はまた、オブジェクト識別子付破損ファイル格納手段４１を有する。識別子付破損ファイル格納手段４１は、マウント時更新ファイル検証手段５０から渡されたオブジェクト識別子付破損ファイル５を格納する。
【００１８】
以上説明した構成によれば、破損したファイルがオブジェクト識別子付破損ファイル５として、オブジェクト識別子付破損ファイル格納手段４１に格納される。このため破損したオブジェクトを容易に特定することができる。また、ファイルシステム４０のマウント時に、更新されたファイルだけを検証するため、検証プログラムが常駐し、全ファイルを検証する方法に比べシステムの負荷を大幅に低減することができる。なお、更新ファイル以外は既に検証済みであるため、検証の必要は無い。またオブジェクトストレージシステム１００は、ＯＳ２０を利用するアプリケーションプログラム６０を有していても良い。
【００１９】
次に各部の詳細について説明する。
【００２０】
オブジェクト管理手段３０は、一連のデータを一つのオブジェクトとして扱い、内部ではオブジェクトに対応したファイル１１を入出力する。オブジェクト識別子設定手段３１は、オブジェクトをファイル１１として記憶装置１０に格納する際に、メタデータ４にオブジェクト識別子２を設定する。そしてオブジェクト管理手段３０は、個々のオブジェクト１を、オブジェクト識別子２で判別し管理する。
【００２１】
ファイルシステム４０は、記憶装置１０の記憶空間を分割してデータ３の格納先となるファイル１１を生成し制御する。またオブジェクト管理手段３０あるいはアプリケーションプログラム６０と記憶装置１０との間でデータの入出力を行う。またファイルシステム４０は、マウント時更新ファイル検証手段５０から受信したオブジェクト識別子付破損ファイル５を格納するオブジェクト識別子付破損ファイル格納手段４１を有する。
【００２２】
マウント時更新ファイル検証手段５０は、前述した通り、ファイルシステム４０のマウント時に、記憶装置１０において更新されたファイル１１を検証する。更新されたファイル１１の特定は、ジャーナル１２を参照することによって行う。検証で破損が発見されたファイルは、オブジェクト識別子付破損ファイル５として、ファイルシステム４０に渡され、オブジェクト識別子付破損ファイル格納手段４１に格納される。またメタデータ４が破損していてオブジェクト識別子２が特定できない破損ファイル６は、別のフォルダに格納される。このフォルダは、例えば一般的な技術で用いるＬＯＳＴ＋ＦＯＵＮＤ８０とすることができる。
【００２３】
次に、動作について説明する前に、この仕組みが必要になる理由について簡単に述べる。一般に、ストレージシステムでは、正常に終了する際にファイルシステムが正常終了したことを示す記録を保存する。ストレージシステムが異常終了した時は、ファイルシステムが正常終了したことを示す記録を残せないため、次の起動時に正常終了していないことがわかる。ストレージシステムが異常終了していた場合、次のマウント時にファイルシステムの正常性確認を行い、異常がみられる場合には復旧を行う。ジャーナルを用いたジャーナリングファイルシステムでは、ファイルを格納する記憶装置と同期の取れた後の更新記録がジャーナルに記録されている。異常終了した場合には、ジャーナルに記録された更新分の復旧だけを行えばよい。このため全体を検証して復旧する方法に比べ、処理量を大幅に削減することができる。本発明は、上記のジャーナリングファイルシステムの技術をベースにしている。なおジャーナリングファイルシステムの詳細については周知技術であるため、説明を省略する。
【００２４】
ところで、復旧の過程で破損ファイルが発生する場合がある。これは次の理由による。ジャーナリングファイルシステムの目的はデータの保全そのものではなく、ファイルシステム全体を保護することにある。ジャーナリングファイルシステムの復旧では、最後に同期をとったログから後ろのログを読み取り、完了していた操作やコミットされたトランザクションを順番に再実行し、ファイルシステムの再構築を行う。再構築を行うと、ファイルシステム全体としての整合性は保障されるが、アプリケーションなど上位レイヤにとって必ずしも正しい状態になるとは限らない。こうしてファイルの破損問題が発生する。
【００２５】
発明に戻り、動作について説明する。図２は本実施の形態の動作を示すフローチャートである。
【００２６】
まず、システム起動の際にＯＳ２０が起動し、記憶装置１０など接続されたデバイスを有効化する。次に、ファイルシステム４０が起動する（Ｓ１）。ファイルシステムは、マウント指定された領域をファイルシステムとして扱えるようにする。以下の処理は、マウント時に実施する処理の一部となる。そして、マウント時更新ファイル検証手段３０を起動する（Ｓ２）。次にマウント時更新ファイル検証手段３０がジャーナル１２を参照し（Ｓ３）、最後に同期をとられた後更新されたファイル１１を検証対象として特定する（Ｓ４）。そしてジャーナルに記録され、コミットされているが反映されていないトランザクションを再度実行する（Ｓ５）。
【００２７】
次に、更新されたファイル１１に格納されたデータの検証を実行する （Ｓ６）。具体的な検証方法としては、メタデータ領域に保存されたデータのチェックサム値とデータから算出したチェックサム値が同じ値を示すか、などが考えられる。メタデータ４に保存するチェックサム値は、データ格納時（ファイルの作成、変更時）にストレージ管理手段３０が算出し、メタデータ４へ保存する。
【００２８】
マウント時更新ファイル検証手段３０による検証の結果、データが不正と判断した場合は（Ｓ７＿ｙｅｓ）、オブジェクト識別子付破損ファイル格納手段４１へ該当するファイルを渡す。オブジェクト識別子付破損ファイル格納手段４１は、オブジェクト識別子２が付いたファイルを専用のディレクトリの下へ格納する（Ｓ８）。不正が無いと判断した場合は（Ｓ７＿ｎｏ）、当該ファイルの検証を終了し、他に未検証のファイルがあるか確認する（Ｓ９）。未検証のファイルがあれば（Ｓ９＿ｙｅｓ）、Ｓ６に戻り、このファイルに対し、データの検証を行う。これをジャーナルに記録されているものに順次繰り返す。未検証ファイルが無くなったら（Ｓ９＿ｎｏ）、すなわちＳ４で特定した全てのファイルの検証を完了したら終了する。
【００２９】
ファイルの検証完了後、ファイルシステムは、該当領域をファイルシステムとして公開する。（ファイルシステムのマウントを完了する）。この処理は一般的に知られているマウント処理方法を実施すればよい。マウント後は、アプリケーションプログラムからファイルを使用できるようになる。
【００３０】
以上、説明したように、本実施の形態によれば、破損したファイルがオブジェクト識別子付破損ファイル５として、オブジェクト識別子付破損ファイル格納手段４１に格納される。このため破損したオブジェクトを容易に特定することができる。また更新ファイルのみを検証しているので、全ファイルを常時検証する方法に比べて大幅にシステムリソースの消費を削減することができる。
（第２の実施の形態）
図３は本発明第２の実施の形態を示すブロック図である。本実施の形態のオブジェクト管理手段３０は、オブジェクト修復手段３２を有している。
【００３１】
次に、オブジェクト１の修復方法について説明する。図４は、この動作を示すフローチャートである。
【００３２】
まず、ファイルシステム４０が起動する（Ｓ１０１）。次いでオブジェクト管理手段３０が起動する（Ｓ１０２）。オブジェクト管理手段３０が起動すると、オブジェクト修復手段３２は、オブジェクト識別子付破損ファイル格納手段４１を参照し、ファイル１１に破損が生じたオブジェクト１を特定する（Ｓ１０３）。オブジェクト識別子付破損ファイル格納手段４１に格納されたファイルはオブジェクト識別子２によって、そのファイルがどのオブジェクト１に属するものなのかを容易に識別できる。次に、オブジェクト修復手段３２は、他のオブジェクトストレージに格納されたバックアップのオブジェクト１をコピーし（Ｓ１０４）、ファイル１１を生成し、記憶装置１０に格納する（Ｓ１０５）。そしてオブジェクト識別子付破損ファイル格納手段４１からオブジェクト識別子付破損ファイル５を削除する。（Ｓ１０６）。以上により格納オブジェクトの復旧が完了する。
【００３３】
以上の動作とすることにより、破損のあったオブジェクト１を迅速に修復することができる。
（第３の実施の形態）
本実施の形態は、メタデータ４の構成に関する。そこで、メタデータ４の構成について、一般的な技術と比較して説明する。
【００３４】
図５に、一般的な技術におけるメタデータ４の一例を示す。ｉ−ｎｏｄｅ番号４−１、作成日付４−２、更新日付４−３、データ長４−４や対応するデータ保存場所のアドレス（記憶装置上に保存した位置）が記載されている。ＵＮＩＸ（登録商標）やＬｉｎｕｘ（登録商標）などの既存技術ではファイルが破損した場合、破損ファイルはｌｏｓｔ＋ｆｏｕｎｄと呼ばれる特定の破損ファイル用保存ディレクトリにｉ−ｎｏｄｅ番号４−１をファイル名として格納される。ここで、ｉ−ｎｏｄｅ番号４−１はオブジェクトの情報を含んでいない。なおメタデータ４は通常ファイルシステムが自動的に作成、変更するが、外部からも登録が行える。
【００３５】
図６に、本実施の形態におけるメタデータ４の一例を示す。一般的な技術と同様に、ｉ−ｎｏｄｅ番号４−１、作成日付４−２、更新日付４−３、データ長４−４、対応するデータ保存場所のアドレスを使用する。また、データの検証を行うチェックサム４−５を付加してもよい。さらに本実施の形態ではメタデータ４にオブジェクト識別子２が付加されている。オブジェクト識別子２は、ファイル１１のデータ３をオブジェクト１と対応付けて格納するために使用される。本実施の形態によれば、オブジェクト識別子２を導入することで、破損したファイルの属性を特定できるため、オブジェクト１の復元が容易になる。
（第４の実施の形態）
本実施の形態では、ファイル作成に関して説明する。まず、メタデータ４にオブジェクト識別子２を付加して、ファイル１１にデータ３を格納する動作について説明する。
【００３６】
図７は、この動作を示すシーケンス図である。まずオブジェクト管理手段３０が、オブジェクト識別子設定手段３１を用いて、ファイル１１として格納したいデータ３のオブジェクト識別子２を決定する（Ｓ２０１）。
【００３７】
次に保存先となるファイル名を指定して、ファイルシステム４０へデータ３の書込み要求を出す（Ｓ２０２）。
【００３８】
ファイルシステム４０はデータ３を記憶領域へ書込む（Ｓ２１１）。記憶装置１０への書込みが完了すると、記憶装置１０から書込み完了通知が返る（Ｓ２１２）。
【００３９】
次に、ファイルシステム４０は、データ３が持つｉ−ｎｏｄｅ番号４−１に対応するメタデータ４を、ファイル１１に書き込む（Ｓ２１３）。またファイルシステム４０に設けられたメタデータ記憶手段（図示せず）にもメタデータ４を記憶する。これは既存技術（ジャーナリングファイルシステム）では、ジャーナル１２へ書込むことに相当する。
【００４０】
記憶装置１０への書込みが完了すると、記憶装置１０から書込み完了通知が返ってくる（Ｓ２１４）。
【００４１】
記憶装置１０に書き込めたら、ファイルシステム４０は、オブジェクト管理手段３０へ書込み完了を通知する（Ｓ２０３）。次に、オブジェクト管理手段３０は書き込んだデータ３に対するオブジェクト識別子２をファイルのメタデータ４に登録する。オブジェクト管理手段３０はこの登録要求をファイルシステム４０へ出す（Ｓ２０４）。
【００４２】
要求を受け付けたファイルシステム４０は、データ３に対応するｉ−ｎｏｄｅのメタデータ４にオブジェクト識別子２を加える（Ｓ２１５）。メタデータ４が書き込めたら書込み完了通知を受け取る（Ｓ２１６）。
【００４３】
ファイルシステム４０は書込み完了通知を受け取ると、オブジェクト管理手段３０へ書込み完了を通知する（Ｓ２０５）。
【００４４】
以上により、オブジェクト識別子２を付加した形でデータ３を格納することができる。
（第５の実施の形態）
本実施の形態では、本発明を効果的に用いるための、オブジェクト識別子付破損ファイル格納手段４１の構成例を示す。図８は、オブジェクト識別子付破損ファイル格納手段４１の一例を示すディレクトリ構成図である。本発明では、例えばファイルシステム４０のルートディレクトリ直下に、オブジェクト識別子付破損ファイル格納手段４１としてＬＯＳＴＦＩＬＥＳ４１ａというディレクトリを作成する。そしてＬＯＳＴＦＩＬＥＳ４１ａの下に、例えば、オブジェクト識別子２の下位３文字をディレクトリ名としたサブディレクトリ４２ａを作成する。なお、下位３文字以外の方法で分割してもよい。また、オブジェクト識別子２（＝ファイル名）が名前空間上衝突しないのであれば単一のディレクトリにしてもよい。ただし、多数のファイルが見込まれる場合、性能問題を引き起こす可能性があるため、前記のように区分することが望ましい。そして、サブディレクトリ４２の下にオブジェクト識別子２をファイル名としたオブジェクト識別子付破損ファイル５を配置する。なおオブジェクト識別子２が認識できる形であれば、ファイル名はオブジェクト識別子２そのものでなくても良い。
【００４５】
このように、配置すると、オブジェクト管理手段３０は破損したファイルを持つオブジェクト１を容易に特定することができる。オブジェクト１が特定できれば、バックアップデータを用いて、これを直接修復することができるので、全ファイル検証および修復を行う方法に比べて、大幅に修復時間を短縮することができる。
【００４６】
次に比較のため、一般的な技術における識別子の無い破損ファイル６の格納について説明する。図９はこの格納例を示すディレクトリ構成図である。一般的技術では、破損ファイル６は、例えばＬＯＳＴ＋ＦＯＵＮＤ７０というディレクトリにまとめて入れられる。このため、場合によっては、一つのディレクトリに非常に多くの破損ファイル６が格納されることになる。また、ファイル名がｉ-ｎｏｄｅ番号であるため、ユーザは元のファイル名やオブジェクトとの関連を特定することが非常に困難となる。
【００４７】
以上、説明したように、本実施の形態によれば、ファイルシステム４０を復旧した場合に発生する破損ファイルとオブジェクトとの関係を容易に特定し、迅速な修復に結び付けることができる。
【符号の説明】
【００４８】
１    オブジェクト
２    オブジェクト識別子
３    データ
４    メタデータ
５    オブジェクト識別子付破損ファイル
６    破損ファイル
１０    記憶装置
１１    ファイル
１２    ジャーナル
２０    オペレーティングシステム
３０    オブジェクト管理手段
３１    オブジェクト識別子設定手段
３２    オブジェクト修復手段
４０    ファイルシステム
４１    オブジェクト識別子付破損ファイル格納手段
５０    マウント時更新ファイル検証手段
６０    アプリケーションプログラム
１００    オブジェクトストレージシステム
【図１】
0006327028.tif 000002
【図２】
0006327028.tif 000003
【図３】
0006327028.tif 000004
【図４】
0006327028.tif 000005
【図５】
0006327028.tif 000006
【図６】
0006327028.tif 000007
【図７】
0006327028.tif 000008
【図８】
0006327028.tif 000009
【図９】
0006327028.tif 000010