JP2007305013A - Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 - Google Patents

Abstract

【課題】一次ストレージにおける空き領域の生成を効率的に行うＨＳＭ制御プログラム、ＨＳＭ制御装置、ＨＳＭ制御方法を提供する。
【解決手段】ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製１５１として管理するメタデータ複製情報管理ステップと、ファイル毎のリリースに関する情報をリリース情報として管理し、メタデータ複製１５１が更新された場合、メタデータ複製１５１とリリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、リリースが指示された場合、リリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップとをコンピュータに実行させる。
【選択図】図７

Description

本発明は、一次ストレージの空き領域の生成を効率的に行うＨＳＭ制御プログラム、ＨＳＭ制御装置、ＨＳＭ制御方法に関するものである。

ＨＳＭ（Hierarchical Storage Management：階層記憶管理）は、テープライブラリなどの低速なストレージ装置（二次ストレージ）とハードディスクなどの高速なストレージ装置（一次ストレージ）を組み合わせることにより、安価な大容量ファイルシステムを構築するものである。

ＨＳＭ制御装置においては、一次ストレージにおいて長時間アクセスされていないファイルを特定し、そのファイルを二次ストレージに書き出し、アクセスが要求された時点で一次ストレージに移動することが必要となる。従来、これを実現するために、従来のＨＳＭ制御装置は、階層構造を持つファイルシステムの名前空間を総なめし、ファイルシステムがファイル単位に保持するアクセス時刻を参照することにより、二次ストレージに書き出すファイルを特定する方式を用いている。

なお、本発明の関連ある従来技術として、例えば、下記に示す特許文献１が知られている。このデータ処理装置は、メタデータデータの内容が更新されると、ログが採取され、このログを用いてファイルシステムの不整合の修正を行うものである。
特開２０００−４８４９９５号公報

しかしながら、上述した名前空間を総なめする方式のＨＳＭ制御装置には、以下の問題がある。

第１にファイルシステム総なめオーバヘッドの問題がある。従来のＨＳＭ制御装置では階層構造を持つファイル名前空間を定期的に総なめするために、オーバヘッドが大きくなってしまう。

第２に名前空間の排他問題がある。ＨＳＭ制御装置が名前空間を総なめしている間に、ｒｅｎａｍｅ操作などのファイル名変更操作が行われると、総なめの過程で求めたパス名が、実際には存在しない不当なものとなってしまう。このため、ＨＳＭ制御装置は、顧客が設定したポリシと矛盾するデータ移動操作を行ってしまう可能性がある。例えば、検索の途中で、上位ディレクトリがゴミ箱に移されたとすると、ゴミ箱全体を移動対象としてしまうようなことが起こる。こうした問題を防ごうとすると、ＨＳＭ制御装置は総なめの過程で、頻繁に矛盾をチェックし、矛盾があれば総なめをやり直すことが必要となり、論理が非常に複雑となるとともにオーバヘッドが大幅に増加する。

第３にＨＳＭポリシ制御の柔軟性がある。一般に階層構造の名前空間は格納されているファイル群の性格を表しているため、ＨＳＭポリシも名前空間に基づいて設定する（あるディレクトリ以下の全ファイルなど）のが自然である。しかし、上述した名前空間の排他問題により、名前空間に基づく複雑なポリシ制御を実現することが難しいという問題があった。

第４に二次ストレージに退避されたデータの属性情報不足の問題がある。また上述した名前空間の排他問題により、二次ストレージに格納されるデータに正しいパス名を付加することが難しい。このため、二次ストレージに格納されたデータはファイルシステムのメタデータのみからしかアクセスできないことになり、ファイルシステムのメタデータが壊れると、二次ストレージ上にデータは残っているのにもかかわらず、パス名と対応づけることができないため、ファイルデータを復旧することができないという問題があった。

本発明は上述した問題点を解決するためになされたものであり、一次ストレージにおける空き領域の生成を効率的に行うためのＨＳＭ制御プログラム、ＨＳＭ制御装置、ＨＳＭ制御方法を提供することを目的とする。

上述した課題を解決するため、本発明は、ＨＳＭの制御をコンピュータに実行させるＨＳＭ制御プログラムであって、ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップとをコンピュータに実行させるものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記リリース情報管理ステップは、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記リリース情報は、更にファイル識別子を含み、前記リリース情報管理ステップは、ファイル識別子に対応するリリース情報を検索するためのファイル識別子インデックスを管理し、前記メタデータ複製情報が更新された場合、または、前記ディレクトリリリースポリシが設定された場合、ファイル識別子とファイル識別子インデックスに基づいて対応するリリース情報を特定することを特徴とするものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記リリーススコアインデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記ファイル識別子インデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするものである。

また、本発明に係るＨＳＭ制御プログラムにおいて、前記ファイル決定ステップは、前記リリーススコアが大きいファイルから順に、リリース対象とすることを特徴とするものである。

また、本発明は、ＨＳＭ制御装置であって、ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理部と、ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理部により管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理部と、リリースが指示された場合、前記ファイル情報管理部により管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定部とを備えたものである。

また、本発明に係るＨＳＭ制御装置において、前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするものである。

また、本発明に係るＨＳＭ制御装置において、前記リリース情報管理部は、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするものである。

また、本発明に係るＨＳＭ制御装置において、前記リリース情報は、更にファイル識別子を含み、前記リリース情報管理部は、ファイル識別子に対応するリリース情報を検索するためのファイル識別子インデックスを管理し、前記メタデータ複製情報が更新された場合、または、前記ディレクトリリリースポリシが設定された場合、ファイル識別子とファイル識別子インデックスに基づいて対応するリリース情報を特定することを特徴とするものである。

また、本発明に係るＨＳＭ制御装置において、前記リリーススコアインデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするものである。

また、本発明に係るＨＳＭ制御装置において、前記ファイル識別子インデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするものである。

また、本発明に係るＨＳＭ制御装置において、前記ファイル決定部は、前記リリーススコアが大きいファイルから順に、リリース対象とすることを特徴とするものである。

また、本発明は、ＨＳＭの制御を行うＨＳＭ制御方法であって、ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップとを実行するものである。

本発明によれば、一次ストレージにおける空き容量の生成を効率的に行うことができる。

以下、本発明の実施の形態を説明するため、その前提となる技術について図面を参照しつつ説明する。

（前提技術１）
前提技術１においては、ＨＳＭ制御装置であるサーバについて説明する。

まず、前提技術１に係るサーバを有するＨＳＭ装置の構成について説明する。

図１は、前提技術１に係るＨＳＭ装置の構成の一例を示すブロック図である。最近アクセスされたファイルを格納しているディスク装置などの高速ストレージ装置である一次ストレージ１、および長時間アクセスされていないファイルデータが格納されるテープライブラリ装置などの低速ストレージ装置である二次ストレージ２と、前提技術１に係るＨＳＭ制御装置であり、ファイルデータをアクセスするアプリケーションが動作するサーバ３から構成される。

また、サーバ３は、アプリケーション部１１、ファイルシステム制御部１２、名前空間複製部１３、名前空間追随部１４、名前空間複製ＤＢ（Database）１５、マイグレート決定部１６を備える。また、ファイルシステム制御部１２は、イベントデータ記録部２１を備える。

次に、サーバ３の各部について説明する。

イベントデータ記録部２１は、アプリケーションプログラムが発行したファイル操作要求の履歴をイベントデータとして蓄積するファイルシステム制御部１２内に配置されるプログラムである。イベントデータ記録部２１は、アプリケーション部１１が発行したファイル操作要求の内容をイベントデータに変換してメモリ上に蓄積しておき、一定量たまったところで名前空間複製部１３や名前空間追随部１４に渡す。イベントデータの受け渡しは、通信を使用してもよいし、専用のファイルを介して受け渡してもよい。

名前空間複製部１３は、アプリケーション部１１の動作と平行して、ファイルシステムの名前空間の複製を行うプログラムである。名前空間複製部１３は、ファイルシステムの名前空間をたどり、存在するファイルのファイル情報を取得する。このファイル情報と、ファイル情報取得中にイベントデータ記録部２１から受け取ったイベントデータを組み合わせて、名前空間の初期複製を名前空間複製ＤＢ１５として完成させる。

名前空間追随部１４は、名前空間の初期複製が完成した後、イベントデータ記録部２１から受け取ったイベントデータに従って複製を更新し、名前空間複製ＤＢ１５を最新の状態に維持する機能を受け持つ。また、名前空間追随部１４は、通知されたファイルアクセスやアーカイブ状態を名前空間複製ＤＢ１５に反映する役割も担う。

マイグレート決定部１６は、ポリシ制御の一例として、名前空間複製部１３が設定したファイルアクセス記録とユーザが設定したポリシに従い、一次ストレージ１において長時間アクセスされていないファイルを二次ストレージ２に追い出すため、ファイルシステム制御部１２に指示を出すプログラムである。通常、二次ストレージ２に追い出された（マイグレートされた）ファイルは、アプリケーション部１１がそのファイルをアクセスしたときに、ファイルシステム制御部１２が二次ストレージ２から一次ストレージ１に戻す（リコール）。また、ファイルを更新したタイミングで、ファイルシステム制御部１２により二次ストレージ２上のデータ（アーカイブデータ）が無効化される。二次ストレージ２上のデータはこのタイミングでは消えず、二次ストレージ２が不足するまで、バックアップデータとして残され、ファイルシステム障害時などのリカバリで使われる。

次に、イベントデータ、ファイル情報、名前空間複製ＤＢ１５の詳細について説明する。

まず、イベントデータについて説明する。

イベントデータ記録部２１により作成されるイベントデータ（ｅｖｅｎｔ）はファイルやディレクトリの生成や削除、ファイル名の変更、ファイルアクセス、アーカイブ状態変化などのファイル操作の内容を表しており、操作名と操作が行われた時刻に加え、それぞれ以下のデータを含む。ここで、アーカイブ状態変化とは、アーカイブデータの有効化・無効化、マイグレート、リコールなどの事象を含む。

（１） ファイルあるいはディレクトリの作成
ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ｃｒｅａｔｅ
ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃ ＝ 親ディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｆｔｙｐｅ ＝
ｄｉｒ （ｍｋｄｉｒ時）あるいはｆｉｌｅ （ｃｒｅａｔｅ時）
ｅｖｅｎｔ．ｆｎａｍｅ ＝ 作成されたファイルの名前
ｅｖｅｎｔ．ｉｎｏｄｅ＃ ＝
作成されたファイルあるいはディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｔｉｍｅ ＝ このイベントが発生した時刻

（２） ファイルあるいはディレクトリの削除
ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ｄｅｌｅｔｅ
ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃ ＝ 親ディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｆｔｙｐｅ ＝ ｄｉｒ （ｒｍｄｉｒ時）あるいはｆｉｌｅ （ｒｅｍｏｖｅ時）
ｅｖｅｎｔ．ｉｎｏｄｅ＃ ＝ 削除されたファイルあるいはディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｔｉｍｅ ＝ このイベントが発生した時刻

（３） ファイル名の変更
ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ｒｅｎａｍｅ
ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃ ＝ 親ディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｆｔｙｐｅ ＝
ｄｉｒ（対象がディレクトリの場合）
あるいはｆｉｌｅ（対象がファイルの場合）
ｅｖｅｎｔ．ｉｎｏｄｅ＃ ＝
対象のファイルあるいはディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｔａｒｇｅｔ．ｍ＿ｉｎｏｄｅ＃ ＝
移動先ディレクトリのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｔａｒｇｅｔ．ｆｎａｍｅ ＝
変更後のファイルあるいはディレクトリ名
ｅｖｅｎｔ．ｔｉｍｅ ＝ このイベントが発生した時刻

（４） ファイルアクセス（アプリケーションプログラムがファイルをｒｅａｄ／ｗｒｉｔｅ）
ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ａｃｃｅｓｓ
ｅｖｅｎｔ．ｉｎｏｄｅ＃ ＝ ファイルのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｔｉｍｅ ＝ このイベントが発生した時刻

（５） アーカイブ状態変化
ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ａｒｃｈｉｖｅ
ｅｖｅｎｔ．ｉｎｏｄｅ＃ ＝ ファイルのｉｎｏｄｅ番号
ｅｖｅｎｔ．ｍｉｇｒａｔｅ ＝
オン（マイグレート状態となった）
あるいはオフ（リコールが起動され、マイグレート状態でなくなった）
ｅｖｅｎｔ．ａｒｃｈｉｖｅ ＝
オン（二次記憶へのファイルデータの書き出しが完了し、アーカイブデータが有効となった）
あるいはオフ（ファイルが更新された結果アーカイブデータが無効となった）
ｅｖｅｎｔ．ｔｉｍｅ ＝ このイベントが発生した時刻

次に、ファイル情報について説明する。

名前空間複製復元中にファイルシステムから取得するファイル情報（ｆｓｔａｔ）には、以下のものがある。
ｆｓｔａｔ．ｍ＿ｉｎｏｄｅ＃ ＝ 親ディレクトリのｉｎｏｄｅ番号
ｆｓｔａｔ．ｆｔｙｐｅ ＝ ｄｉｒ（対象がディレクトリの場合）
あるいはｆｉｌｅ （対象がファイルの場合）
ｆｓｔａｔ．ｆｎａｍｅ ＝ ディレクトリあるいはファイルの名前
ｆｓｔａｔ．ｉｎｏｄｅ＃ ＝
ファイルあるいはディレクトリのｉｎｏｄｅ番号
ｆｓｔａｔ．ａｒｃｈｉｖｅ ＝ オン（アーカイブデータが有効なとき）
あるいはオフ（アーカイブデータが無効なとき）
ｆｓｔａｔ．ｍｉｇｒａｔｅ ＝ オン（マイグレート状態のとき）
あるいはオフ（マイグレートされていないとき）
ｆｓｔａｔ．ａｔｉｍｅ ＝ ファイルを最後にアクセスした時刻
ｆｓｔａｔ．ｔｉｍｅ ＝ ファイル情報取得時刻

次に、名前空間複製ＤＢ１５の構成について説明する。

名前空間複製ＤＢ１５は、以下のカラム（ｄｂｅ）を持つ、ディレクトリに設定されているファイルあるいはディレクトリ要素ごとにタプルを持つリレーショナルＤＢである。

ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝ 親ディレクトリのｉｎｏｄｅ番号
ｄｂｅ．ｆｔｙｐｅ ＝ ｄｉｒ（このタプルがディレクトリをあらわすとき） あるいは ｆｉｌｅ （このタプルがファイルを表すとき）
ｄｂｅ．ｆｎａｍｅ ＝ ファイルあるいはディレクトリの名前
ｄｂｅ．ｉｎｏｄｅ＃ ＝ ファイルあるいはディレクトリのｉｎｏｄｅ番号
ｄｂｅ．ａｒｃｈｉｖｅ ＝ オン（アーカイブデータが有効なとき）
あるいはオフ（アーカイブデータが無効なとき）
ｄｂｅ．ｍｉｇｒａｔｅ ＝ オン（マイグレート状態のとき）
あるいはオフ（マイグレートされていないとき）
ｄｂｅ．ａｔｉｍｅ ＝ ファイルを最後にアクセスした時刻
ｄｂｅ．ａｃｔｉｖｅ ＝ オン（ファイル情報取得済みのとき）
あるいはオフ（まだファイル情報を取得していないとき）

次に、サーバ３の動作について説明する。

図２は、前提技術１に係るファイル情報取得処理の動作の一例を示すフローチャートである。サーバ３は、名前空間複製処理（Ｓ１１）、名前空間追随処理（Ｓ１２）、マイグレート処理（Ｓ１３）を実行する。

次に、サーバ３における動作の詳細について説明する。

まず、名前空間複製処理について説明する。

名前空間複製処理は、名前空間複製部１３が名前空間の初期複製を作成する処理であり、ファイル情報取得処理とイベントデータ反映処理からなる。また、名前空間複製処理は、障害発生後のサーバ再立ち上げ時など、メモリ上に蓄積されていたイベントデータが失われ、名前空間複製ＤＢ１５の内容がファイルシステムの最新状態を反映できなくなったときに、名前空間複製ＤＢ１５を再作成する目的で動作する。このように名前空間複製ＤＢ１５を動的に再作成する構成では、イベントデータをイベント発生時に不揮発化する必要がなく、小さい容量のメモリに蓄積するのみで良く、後の名前空間複製ＤＢの追随のオーバヘッドを削減することができる。

名前空間複製部１３は、まず、ファイル情報取得処理として、親ディレクトリをオープンし、子ファイル名あるいは子ディレクトリ名を引数として指定し、ファイルシステムの情報取得機能（ｇｅｔｉｎｆｏ）を発行することにより求める。また、名前空間複製部１３は、パス名昇順（あるいは降順）とした名前空間をたどることにより、ファイルシステム内に存在するディレクトリ、ファイルの情報を漏れなく求める。この過程で見逃したものは、イベントデータとして記録されているので、後で補正する。

図３は、名前空間におけるディレクトリの階層構造の一例を示す図である。この名前空間は、ディレクトリの階層構造を持ち、ディレクトリ名やファイル名を昇順に左から右へソートしたものである。図４は、前提技術１に係るファイル情報取得処理の動作の一例を示すフローチャートである。

まず、名前空間複製部１３は、対象ファイルシステムのルートディレクトリを基点とし、ディレクトリを左下方向（ディレクトリ名の昇順）に順にたどり、最も左下のディレクトリを見つける。見つけた最も左下のディレクトリを対象ディレクトリとし、検索の過程で求めた対象ディレクトリのパス名を対象ディレクトリパス名とする（Ｓ２０１）。次に、名前空間複製部１３は、対象ディレクトリのファイル情報および対象ディレクトリ内に存在する全ファイルのファイル情報をファイル名昇順にひとつずつ順に求め、ファイル情報記録ファイルの末尾に順に書き込む（Ｓ２０２）。次に、名前空間複製部１３は、対象ディレクトリがルートディレクトリであるか否かの判断を行う（Ｓ２０３）。対象ディレクトリがルートディレクトリである場合（Ｓ２０３，Ｙ）、全ファイルを処理し終わったことを意味するのでファイル情報取得処理を終了する。

一方、対象ディレクトリがルートディレクトリでない場合（Ｓ２０３，Ｎ）、名前空間複製部１３は、対象ディレクトリパス名から、対象ディレクトリのひとつ上のディレクトリパス名を求める、すなわち、パス名を構成する最終構成ディレクトリ名を取り除いたパス名を新しいパス名とする。次に、名前空間複製部１３は、求めたディレクトリパス名をルートディレクトリから下方に順に再度検索し、この検索で存在を確認できた最終ディレクトリを基点ディレクトリとする（Ｓ２０５）。パスの途中のディレクトリがｒｅｎａｍｅなどで名前空間の別の位置に動かされている場合、途中でみつからなくなるが、この部分は後続のファイル情報取得処理で見つかるか、イベントデータで必ず通知され、後で補正されるため、無視しても問題ない。

次に、名前空間複製部１３は、基点ディレクトリの内容を読み込み、基点ディレクトリ内に未処理のディレクトリがあるか否かの判断を行う（Ｓ２０６）。未処理のディレクトリがある場合（Ｓ２０６，Ｙ）、名前空間複製部１３は、未処理の最も左下のディレクトリを求め、これを対象ディレクトリとし（Ｓ２０７）、処理Ｓ２０２に移行する。未処理のディレクトリが存在しない、すなわち基点ディレクトリ内に対象ディレクトリパス名で示されるより大きなファイル名をもつディレクトリが存在しない場合（Ｓ２０６，Ｎ）、対象ディレクトリパス名を基点ディレクトリのパス名に設定し（Ｓ２０８）、処理Ｓ２０３に移行する。

次に、名前空間複製部１３は、対象ファイルシステムのファイル情報取得処理が全て終了すると、その間に発生したイベントデータをファイル情報に反映するイベントデータ反映処理を行う。ファイル情報記録ファイルを先頭から順によみ、ファイル情報記録ファイルに記録されている全てのファイル情報を処理したら、イベントデータ反映処理は終了する。

図５は、前提技術１に係るイベントデータ反映処理の動作の一例を示すフローチャートである。まず、名前空間複製部１３は、未処理のファイル情報を取り出し（Ｓ３０２）、ファイル情報に設定されていた情報取得時刻以前の時刻を持つ、イベントデータを順に取り出し、名前空間複製ＤＢ１５に反映する（Ｓ３０３）。

ここで、名前空間複製ＤＢ１５への反映について、イベントデータが、削除系、生成系、ファイル名の変更、ファイルアクセス、アーカイブ状態変化のそれぞれの場合について説明する。

イベントデータが削除系（ファイル削除，ディレクトリ削除）の場合、名前空間複製部１３は、削除対象ファイルあるいはディレクトリが既に名前空間複製ＤＢ１５に登録済みなら削除する。そうでなければ何もしない。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｎａｍｅ ＝＝ ｅｖｅｎｔ．ｆｎａｍｅ

イベントデータが生成系（ファイル生成，ディレクトリ生成）の場合、名前空間複製部１３は、作成されたファイルあるいはディレクトリが名前空間複製ＤＢ１５に登録済みでなければ情報取得済みで登録する。登録済みならこのイベントデータを無視し、何もしない。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｎａｍｅ ＝＝ ｅｖｅｎｔ．ｆｎａｍｅ

未登録時の設定内容を以下に示す。

ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝ ｅｖｅｎｔ． ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｔｙｐｅ ＝ ｅｖｅｎｔ． ｆｔｙｐｅ
ｄｂｅ．ｆｎａｍｅ ＝ ｅｖｅｎｔ．ｆｎａｍｅ
ｄｂｅ．ｉｎｏｄｅ＃ ＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃
ｄｂｅ．ａｒｃｈｉｖｅ ＝ オフ
ｄｂｅ．ｍｉｇｒａｔｅ ＝ オフ
ｄｂｅ．ａｔｉｍｅ ＝ ｅｖｅｎｔ．ｔｉｍｅ
ｄｂｅ．ａｃｔｉｖｅ ＝ オン

イベントデータがファイル名の変更（ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝＝ ｒｅｎａｍｅ）の場合、名前空間複製部１３は、改名後と同じ名前をもつファイルあるいはディレクトリがすでに登録されていた場合（ファイル名と親ｉｎｏｄｅ番号で評価）、そのエントリを名前空間複製ＤＢ１５から削除する。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｎａｍｅ ＝＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｆｎａｍｅ
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝＝
ｅｖｅｎｔ．ｔａｒｇｅｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｎａｍｅ ＝＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｆｎａｍｅ

ここで、対象ファイルが名前空間複製ＤＢ１５に既に登録されているならそのエントリの親情報とファイル名を変更する。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｎａｍｅ ＝＝ ｅｖｅｎｔ．ｆｎａｍｅ

このときの変更内容を以下に示す。

ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｎａｍｅ ＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｆｎａｍｅ

ここで、対象ファイルが未登録なら、改名後のファイルを名前空間複製ＤＢ１５に新しいエントリとして登録する。

ｄｂｅ．ｉｎｏｄｅ＃ ＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｎａｍｅ ＝ ｅｖｅｎｔ．ｔａｒｇｅｔ．ｆｎａｍｅ
ｄｂｅ．ａｃｔｉｖｅ ＝ オフ

イベントデータがファイルアクセス（ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝＝ ａｃｃｅｓｓ）の場合、名前空間複製部１３は、対象ｉｎｏｄｅが未登録ならこのイベントデータを無視する。登録されていたら、登録済みのすべてのエントリのファイル最終アクセス時刻、アーカイブ情報、リコール情報を更新（ハードリンクがあるため）する。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃

このときの変更内容を以下に示す。

ｄｂｅ．ａｔｉｍｅ ＝ ｅｖｅｎｔ．ｔｉｍｅ

イベントデータがアーカイブ状態変化（ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝＝ ａｒｃｈｉｖｅ）の場合、対象ｉｎｏｄｅが未登録ならこのイベントデータを無視。登録されていたら、すべてのエントリのアーカイブ情報を更新（ハードリンクがあるため）する。ここで、以下の条件を全て満たすエントリが存在する場合、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｅｖｅｎｔ．ｉｎｏｄｅ＃

このときの変更内容を以下に示す。

ｄｂｅ．ａｒｃｈｉｖｅ ＝ ｅｖｅｎｔ．ａｒｃｈｉｖｅ
ｄｂｅ．ｍｉｇｒａｔｅ ＝ ｅｖｅｎｔ．ｍｉｇｒａｔｅ

次に、名前空間複製部１３は、ファイル情報の内容を名前空間複製ＤＢ１５に未登録なら情報取得済みとして登録する（Ｓ３０５）。同一ｉｎｏｄｅ番号を持つタプルが登録されていた場合には、登録されている全てのエントリの内容を変更する。ここで、以下の条件をすべて満たすエントリが存在するとき、登録済みとみなす。

ｄｂｅ．ｉｎｏｄｅ＃ ＝＝ ｆｓｔａｔ．ｉｎｏｄｅ＃
ｄｂｅ．ｆｎａｍｅ ＝＝ ｆｓｔａｔ．ｆｎａｍｅ
ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝＝ ｆｓｔａｔ．ｍ＿ｉｎｏｄｅ＃

また、未登録時の設定内容を以下に示す。

ｄｂｅ．ｍ＿ｉｎｏｄｅ＃ ＝ ｆｓｔａｔ． ｍ＿ｉｎｏｄｅ＃
ｄｂｅ．ｆｔｙｐｅ ＝ ｆｓｔａｔ． ｆｔｙｐｅ
ｄｂｅ．ｆｎａｍｅ ＝ ｆｓｔａｔ．ｆｎａｍｅ
ｄｂｅ．ｉｎｏｄｅ＃ ＝ ｆｓｔａｔ．ｉｎｏｄｅ＃
ｄｂｅ．ａｒｃｈｉｖｅ ＝ ｆｓｔａｔ．ａｒｃｈｉｖｅ
ｄｂｅ．ｍｉｇｒａｔｅ ＝ ｆｓｔａｔ．ｍｉｇｒａｔｅ
ｄｂｅ．ａｔｉｍｅ ＝ ｆｓｔａｔ．ａｔｉｍｅ
ｄｂｅ．ａｃｔｉｖｅ ＝ オン

また、同一ｉｎｏｄｅ番号が既に登録済み（すなわちｄｂｅ．ｉｎｏｄｅ＃ ＝ ｆｓｔａｔ．ｉｎｏｄｅ＃の場合）の設定内容を以下に示す。

ｄｂｅ．ａｒｃｈｉｖｅ ＝ ｆｓｔａｔ．ａｒｃｈｉｖｅ
ｄｂｅ．ｍｉｇｒａｔｅ ＝ ｆｓｔａｔ．ｍｉｇｒａｔｅ
ｄｂｅ．ａｔｉｍｅ ＝ ｆｓｔａｔ．ａｔｉｍｅ
ｄｂｅ．ａｃｔｉｖｅ ＝ オン

次に、名前空間複製部１３は、記録されていた全ファイル情報の処理を終了すると、名前空間の変更との競合のため情報取得で見逃した名前空間のセグメント（情報取得済みが表示されていないディレクトリ）が存在するか否かの判断を行う（Ｓ３１１）。存在しない場合（Ｓ３１１，Ｎ）、このフローを終了する。一方、存在する場合（Ｓ３１１，Ｙ）、そのディレクトリをルートとするファイル情報取得処理、およびその間に発生したイベントデータ反映処理を行い（Ｓ３１２）、処理Ｓ３１１へ戻り、次の情報取得済みが表示されていないディレクトリを見つけ、この処理を繰り返す。

次に、名前空間追随処理について説明する。

名前空間追随部１４は、名前空間複製処理が完了した後に発生したイベントデータをイベントデータ記録部２１から受け取り、名前空間複製ＤＢ１５に順次反映していく。イベントデータ反映処理は名前空間複製処理とほほ同じだが、ファイル情報を用いない分、単純となる。

イベントデータが削除系ファイル操作イベント（ファイル削除、ディレクトリ削除）である場合、名前空間追随部１４は、イベントデータで示されるｉｎｏｄｅ番号、親ｉｎｏｄｅ番号、ファイル名を全て含むエントリを名前空間複製ＤＢ１５上から削除する。

イベントデータが生成系ファイル操作イベント（ファイル生成、ディレクトリ生成）である場合、名前空間追随部１４は、イベントデータで示されるｉｎｏｄｅ番号を含むエントリを名前空間複製ＤＢ１５上に登録し、イベントデータで伝えられた属性（タイプ）、および親ｉｎｏｄｅ番号を設定する。

イベントデータがファイル名の変更（ｒｅｎａｍｅ）でターゲットと同じファイルがあれば、名前空間追随部１４は削除する。また、名前空間追随部１４は、ソースの親属性を変更する。

イベントデータがファイルアクセスイベントである場合、名前空間追随部１４は、イベントデータで伝えられたアクセス時刻をｉｎｏｄｅ番号で特定し、名前空間複製ＤＢ１５に設定する。

イベントデータがアーカイブ状態変化である場合、名前空間追随部１４は、アーカイブ情報を更新する。

次に、マイグレート処理について説明する。

マイグレート決定部１６は、ファイルシステムが提供するコマンドなどを使い、一次ストレージ１の空きスペース状況を定期的に調べ、空きスペース量がユーザにより指定された量以下になった場合、名前空間複製ＤＢ１５に設定されている情報を使って、マイグレートの対象ファイルを決定し、ファイルシステム制御部１２にマイグレートを要求する。この際、マイグレート決定部１６は、名前空間複製ＤＢ１５から求めたファイルのパス名をファイルシステム制御部１２に渡し、ファイルデータとともに二次ストレージ２に書き出してもらう。マイグレート決定処理は、ユーザポリシに応じて様々な実装を行うことができるが、一例を以下に示す。

図６は、前提技術１に係るマイグレート決定処理の動作の一例を示すフローチャートである。まず、マイグレート決定部１６は、一次ストレージ１の不足が深刻であるか否かの判断を行う（Ｓ４０１）。

一次ストレージ１の不足が深刻である場合（Ｓ４０１，Ｙ）、マイグレート決定部１６は、名前空間複製ＤＢ１５を検索し、アーカイブ済みでかつマイグレート済みではないファイルを見つけ（Ｓ４１１）、見つけた全てのファイルに対し以下のリリース処理（一次ストレージ域の解放）を行う。次に、マイグレート決定部１６は、見つけたファイルのうち未処理のファイルがあるか否かの判断を行う（Ｓ４１２）。

未処理のファイルがなければ（Ｓ４１２，Ｎ）、このフローを終了する。一方、未処理のファイルがあれば（Ｓ４１２，Ｙ）、マイグレート決定部１６は、名前空間複製ＤＢ１５に設定されているｉｎｏｄｅ番号を引数としてファイルシステム制御部１２に対象ファイルのリリース（一次ストレージ解放）を要求する（Ｓ４１３）。次に、マイグレート決定部１６は、ファイルシステム制御部１２からの応答を得ると、処理Ｓ４１２へ戻り、次の対象ファイルの処理を行う。

ここで、マイグレート決定部１６は、名前空間複製ＤＢ１５はファイルシステムに遅れて追随するため、実際にはファイルが存在しなくなっている場合や、アーカイブが無効になっている場合があり、この場合にはファイルシステム制御部１２がエラー応答を返す。ファイルがアーカイブ済みであった場合、ファイルシステム制御部１２はそのファイルに割り当てていた一次ストレージ領域を解放して正常応答を返す。

一方、一次ストレージ１が不足しているがそれほど深刻ではない場合（Ｓ４０１、Ｎ）、マイグレート決定部１６は、深刻な不足が発生したときに、事態をただちに改善できるようにするため、一定時間以上アクセスされていないファイルをアーカイブする。このため、マイグレート決定部１６は、名前空間複製ＤＢ１５を検索し、最終アクセス時刻が所定の時刻（例えば現時刻―１日）以前でかつ、アーカイブ無効（アーカイブ済みでない）なものを見つける（Ｓ４２１）。次に、マイグレート決定部１６は、見つけたファイルのうち未処理のファイルがあるか否かの判断を行う（Ｓ４２２）。

未処理のファイルがなければ（Ｓ４２２，Ｎ）、このフローを終了する。一方、未処理のファイルがあれば（Ｓ４２２，Ｙ）、マイグレート決定部１６は、名前空間複製ＤＢ１５に設定されている親ｉｎｏｄｅ番号をキーとして、繰り返し名前空間複製ＤＢ１５を検索することで、ファイルのパス名を求める（Ｓ４２３）。次に、マイグレート決定部１６は、ｉｎｏｄｅ番号、ファイルパス名を引数としたアーカイブ要求をファイルシステム制御部１２に出す（Ｓ４２４）。ここで、ファイルシステム制御部１２は、指定されたファイルのデータとファイルパス名、ｉｎｏｄｅ番号を一括して二次ストレージ上に書き出し、処理Ｓ４２２へ戻り、次の対象ファイルの処理を行う。ここで、要求されたファイルが存在しなくなっている場合、ファイルシステム制御部１２はエラーを応答し、要求を無視する。

次に、その他の各部の動作について説明する。

まず、ファイルシステム制御部１２について説明する。

まず、マイグレート決定部１６からのリリース要求があった場合、ファイルシステム制御部１２は、リリース要求を処理し、二次ストレージにファイルデータのコピーが存在する（アーカイブ済み）なら、一次ストレージを返却し、マイグレート済みとする。このとき、イベントデータ記録部２１はアーカイブ状態変化イベントを作成する。

ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ａｒｃｈｉｖｅ
ｅｖｅｎｔ．ａｒｃｈｉｖｅ ＝ オン
ｅｖｅｎｔ．ｍｉｇｒａｔｅ ＝ オン

また、マイグレート決定部１６からのアーカイブ要求があった場合、ファイルシステム制御部１２は、アーカイブ要求を処理し、ファイルデータの二次ストレージ２への書き出しを起動し、マイグレート決定部１６に復帰する。この際、二次ストレージ２に書き出すデータのヘッダ部にファイルのマイグレート決定部１６から通知されたファイルのパス名を付加して書き出す。二次ストレージ２への書き出しが完了すると、イベントデータ記録部２１はアーカイブ状態変化イベントを作成する。

ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ａｒｃｈｉｖｅ
ｅｖｅｎｔ．ａｒｃｈｉｖｅ ＝ オン
ｅｖｅｎｔ．ｍｉｇｒａｔｅ ＝ オフ

また、アプリケーション部１１がマイグレート済みファイルをアクセスしようとした場合、ファイルシステム制御部１２は、アプリケーション部１１がアクセスしようとしたタイミングで、一次ストレージ１上に領域を新たに割り当て、二次ストレージ２上のデータをその領域に読み込む。その後、イベントデータ記録部２１は、リコール完了を表示したアーカイブ状態変化イベントを作成する。

ｅｖｅｎｔ．ｒｅｃｔｙｐｅ ＝ ａｒｃｈｉｖｅ
ｅｖｅｎｔ．ａｒｃｈｉｖｅ ＝ オン
ｅｖｅｎｔ．ｍｉｇｒａｔｅ ＝ オフ

また、アプリケーション部１１がファイル操作（ファイル生成・削除、ディレクトリ生成・削除、ファイルｒｅａｄ／ｗｒｉｔｅ）を要求した場合、ファイルシステム制御部１２は要求を処理し、正常に完了した時点で、イベントデータ記録部２１は対応するイベントデータを作成する。

名前空間複製部１３からｇｅｔｉｎｆｏでファイル情報を要求された場合、ファイルシステム制御部１２は、指定されたファイルが親ディレクトリに存在することを確認した上で、指定されたファイルのファイル情報を返す。存在しなければ、エラーを応答。エラーが返された場合の名前空間複製部１３はそのファイルがなかったものとして処理を続ける。

次に、イベントデータ記録部２１について説明する。

イベントデータ記録部２１は、ファイルシステム制御部１２内に存在し、ファイルシステム制御部１２の説明で述べたタイミングでイベントデータを作成し、メモリ上に蓄積する部分である。また、イベントデータ記録部２１は、メモリ上に蓄積されたイベントデータが一定量以上となった、あるいは最後に通知してから、一定時間経過したときに、メモリ上に蓄積されていたイベントデータを一括して、名前空間追随部１４あるいは名前空間複製部１３に通知する。また、システム停止時にも、イベントデータ記録部２１が蓄積していたイベントデータを名前空間追随部１４に通知し、名前空間追随部１４がメモリ上に蓄積されているイベントデータを名前空間複製ＤＢ１５に全て反映する、システム停止処理を行う。

また、イベントデータ記録部２１では、通知するデータ量を削減するため、以下の最適化を施す。まず、イベントデータ記録部２１がファイルアクセスイベントを作成する場合、メモリ上に蓄積されている未通知のイベントデータの中に同じファイルに対するファイルアクセスイベントが含まれているなら、後続のファイルアクセスイベントは捨てる。すなわち、メモリ上に蓄積しない。また、イベントデータ記録部２１がファイル削除イベントの作成を依頼されたときに、対応するファイル生成イベントが未通知のイベントデータとして含まれるなら、ファイル生成イベントをメモリ上で無効化し、イベントデータ通知の対象から取り除く。

次に、サーバ３におけるシステム立ち上げの処理について説明する。

システムを正常終了した場合、上述したように名前空間追随部１４がメモリ上に滞留していたイベントデータを一括して名前空間複製ＤＢ１５に反映する正常終了処理を行うため、次回立ち上げ時に名前空間複製部１３を動作させる必要はない。一方、障害発生の場合、その後の再立ち上げ時には、名前空間複製部１３を動作させ、名前空間複製ＤＢ１５を再初期化するシステム異常終了後起動処理を行う。なお、この場合でも、障害発生直前の名前空間情報は残っているので、名前空間複製の再初期化が完了するまでの間にマイグレーション対象を決定する必要が発生した場合には、マイグレート決定部は古い複製を使って処理を行う。

なお、前提技術１においては、名前空間複製ＤＢ１５に基づくポリシ制御の例としてマイグレート決定部１６について説明したが、ＨＳＭ制御における他のポリシ制御を名前空間複製ＤＢ１５に基づいて行う構成としても良い。

この前提技術１のようなＨＳＭ装置は、一次ストレージ１上に存在しないデータへのアクセスが発生すると、二次ストレージ２から一次ストレージ１の空き領域へ該当するデータをコピーした後、一次ストレージ１にアクセスする手段を提供する（リコール）。この場合の一次ストレージ１の空き領域生成において、事前アーカイブや使用量しきい値を用いた空き領域生成が行われる。

まず、事前アーカイブは、一次ストレージ１の空き容量を増やす際、一次ストレージ１から二次ストレージ２へのデータコピー（アーカイブ）を行うことなく、一次ストレージ１上でデータの使用域を解放することができるように、業務に影響を与えない時間帯等に事前にアーカイブを行う機能である。事前アーカイブの実施によって、一次ストレージ１と二次ストレージ２の両方にデータが存在する状態になる。この事前アーカイブは、ユーザの設定するポリシに従って定期的に行われる、または、ユーザからのアーカイブのコマンドに従って行われる。

また、一次ストレージ１には、新規に作成するファイルやデータのための領域、および、一次ストレージ１に存在しないデータを二次ストレージ２から書き戻す（リコール）ための領域として、常に一定量以上の空き領域を確保しておく必要がある。このため、一次ストレージ１の使用量が予めユーザポリシに設定された上限のしきい値（ＨＷＭ：High Water Mark）を超えた時点で、サーバ３は、一次ストレージ１の使用量が予めユーザポリシに設定された下限のしきい値（ＬＷＭ：Low Water Mark）を下回るまで使用済みの領域を開放する。

ここで、空き領域生成は、以下の２フェーズで行われる。最初に、事前アーカイブによりアーカイブ済みのデータ領域を開放する（リリース）。このリリースにより一次ストレージ１の使用量をＬＷＭ未満にできない場合、二次ストレージ２へのデータコピーと一次ストレージ１の領域解放を行う（マイグレート）。ここで、サーバ３は、リリースの対象となるデータの優先順位を、ユーザポリシに従い、更新頻度、サイズ、格納場所等から決定する。

上述した事前アーカイブは、業務にできるだけ影響を与えないように実施される。つまり、事前アーカイブは、一次ストレージ１上のファイルアクセスに必要なＣＰＵ資源、Ｉ／Ｏ資源を奪わないように、かつ、リコールに備えて２次ストレージ２のデバイスを占有しないように実施される。また、上述した使用量しきい値を用いた空き領域生成は、業務への影響を減らすことはもちろん、一次ストレージ１の使用量がＨＷＭを超えてから空き領域が生成されるまでのタイムラグが小さいことが要求される。

従来、事前アーカイブ対象となるファイルやリコール対象となるファイルを特定するために、ファイルシステム全体を対象としてメタデータ（名前空間およびファイル属性）をスキャンする必要があり、上述した空き領域生成を実施する際にファイルシステムを管理するためのＣＰＵやＩ／Ｏを大量に消費していた。前提技術１によれば、名前空間複製ＤＢ１５をスキャンすることにより、アーカイブ対象ファイルやリリース対象ファイルを特定するため、ファイルシステム制御部１２への負担が掛からない。

しかしながら、従来技術と前提技術１は、使用量しきい値を用いた空き容量生成を実施する際、ファイルシステムのメタデータまたは複製されたメタデータを全てスキャンしながら、ユーザポリシと突き合わせてリリースの優先順位を示すスコアを計算し、そのスコアによるソートを行う。このソートが完了するまで空き領域生成を実施できないため、一次ストレージ１の使用量がＨＷＭを超えてから空き領域が生成されるまでのタイムラグが非常に大きい。

以下、本発明の実施の形態について図面を参照しつつ説明する。

実施の形態１．
本実施の形態では、前提技術１と同様にして名前空間（メタデータ）の複製を作成、更新するＨＳＭシステムにおいて、一次ストレージの空き領域生成処理を高速化するＨＳＭシステムについて説明する。

まず、本実施の形態に係るＨＳＭシステムの構成について説明する。

図７は、本実施の形態に係るＨＳＭシステムの構成の一例を示すブロック図である。この図において、図１と同一符号は図１に示された対象と同一又は相当物を示しており、ここでの説明を省略する。このＨＳＭシステムは、一次ストレージ１、二次ストレージ２、ＦＳ（File System）制御サーバ１１１、ストレージ管理サーバ１１２（ＨＳＭ制御装置）、ＨＳＭデータベース１１３を備える。

ＦＳ制御サーバ１１１は、ＡＣ（Access Client）１２１、ＭＤＳ（Meta Data Server）１２２、仮想ボリューム管理部１２３を備える。ＭＤＳ１２２は、メタ更新通知部１３１、定期容量通知部１３２、リリース部１３３を備える。ストレージ管理サーバ１１２は、メタ複製部１４１（メタデータ複製管理部）、ディレクトリポリシ設定部１４２、ファイルポリシ変更部１４３、しきい値制御部１４４、リリース対象決定部１４５（ファイル決定部）、データ移動部１４６を備える。ＨＳＭデータベース１１３は、メタデータ複製１５１（メタデータ複製情報）、ディレクトリポリシ１５２（ディレクトリリリースポリシ）、ファイルポリシカタログ１５３（リリース情報）を備える。

なお、リリース情報管理部は、実施の形態におけるディレクトリポリシ設定部１４２とファイルポリシ変更部１４３に対応する。また、メタデータ複製情報管理ステップは、実施の形態におけるメタ複製部１４１の処理に対応する。また、リリース情報管理ステップは、実施の形態におけるディレクトリポリシ設定部１４２とファイルポリシ変更部１４３の処理に対応する。また、ファイル決定ステップは、実施の形態におけるリリース対象決定部１４５の処理に対応する。

なお、前提技術１におけるファイルシステム制御部１２は、本実施の形態におけるＦＳ制御サーバ１１１に対応する。また、前提技術１における名前空間複製部１３、名前空間追随部１４、マイグレート決定部１６は、本実施の形態におけるストレージ管理サーバ１１２に対応する。また、前提技術１における名前空間複製ＤＢ１５は、本実施の形態におけるメタデータ複製１５１に対応する。また、前提技術１におけるイベントデータ記録部２１は、本実施の形態におけるメタ更新通知部１３１に対応する。また、前提技術１における名前空間複製部１３、名前空間追随部１４は、本実施の形態におけるメタ複製部１４１に対応する。

仮想ボリューム管理部１２３は、一次ストレージ１における複数のディスクの連結、ストライピング構成、ミラー構成などを管理する。ＡＣ１２１、ＭＤＳ１２２は、仮想ボリューム管理部１２３を介して、それぞれ一次ストレージ１におけるファイルデータ領域、メタデータ領域にアクセスを行う。

次に、メタデータ複製１５１について説明する。

ストレージ管理サーバ１１２は、ファイルシステムのメタデータ（ファイルの属性、ファイル名の階層関係）の複製をメタデータ複製１５１として、ストレージ管理サーバ１１２が管理するＨＳＭデータベース１１３上に構築する。これは、ファイルの階層制御を行う際にファイルシステムのメタデータを参照せず、ストレージ管理サーバ１１２がメタデータ複製１５１を参照することにより、ＣＰＵ・Ｉ／Ｏ負荷をＦＳ制御サーバ１１１からストレージ管理サーバ１１２へオフロードすることが目的である。

メタデータ複製１５１の構造は、ファイルシステムと同じである必要はないが、ファイルシステムのメタデータの要件を満たす必要がある。具体的には、ファイルの名前空間が階層的な名前グラフによって表現される一般的なファイルシステムにおいて、以下の要件を満たした構造であれば良い。

・ファイル毎にユニークな名前が整数値として管理される。これは、例えばｉｎｏｄｅ番号である。
・ｉｎｏｄｅ番号毎に名前以外のメタデータが保持される。これは、例えばｉｎｏｄｅである。
・ファイルシステムの基点となるディレクトリは、無名である。基点のディレクトリのｉｎｏｄｅ番号は、例えば２とされ、基点を一意に特定可能としている。
・基点となるディレクトリ以外のファイルに付けられる名前は、そのファイルの親ディレクトリと対応付けられ、名前空間データとして管理される。
・名前空間データは、それが対応付けられたディレクトリは以下の名前の集合と対応するファイルのｉｎｏｄｅ番号の集合からなる。

・ファイルシステムのメタデータは、ｉｎｏｄｅ番号からｉｎｏｄｅ格納位置を高速に決定できる構造でなければならない。一般的に、ｉｎｏｄｅ番号は、一次元もしくは二次元アフィン変換によりｉｎｏｄｅ格納位置に変換可能である。本実施の形態においては、ｉｎｏｄｅ番号からｉｎｏｄｅ格納位置を割り出すためにＢ−Ｔｒｅｅ構造のインデックスを用いる。
・ファイルシステムのメタデータは、ディレクトリのｉｎｏｄｅ番号もしくはｉｎｏｄｅから、そのディレクトリと対応付けられた名前空間データの格納位置を高速に決定できる構造でなければならない。一般的に、ｉｎｏｄｅ内に名前空間データの格納位置を持つことが多い。本実施の形態においては、ディレクトリのｉｎｏｄｅ番号から名前空間データの格納位置を割り出すためにＢ−Ｔｒｅｅ構造のインデックスを用いる。
・ファイルシステムのメタデータは、名前空間データの中から特定の名前と対応付けられたｉｎｏｄｅ番号を高速に決定できる構造であることが望ましい。一般的に、名前をキーとしたハッシュテーブルやＢ−Ｔｒｅｅ構造のインデックスが構築される。本実施の形態においては、ファイル名からｉｎｏｄｅ番号を特定するためにＢ−Ｔｒｅｅ構造のインデックスを用いる。

本実施の形態におけるファイルシステムは、上述した要件を満たす構造により、名前空間中の任意のファイルに対して、多くの場合、名前の階層数に比例したコストでファイルのメタデータにアクセス可能となる。

メタデータ複製１５１の構築は、メタ更新通知部１３１とメタ複製部１４１により実現される。

メタ更新通知部１３１は、ＦＳ制御サーバ１１１においてファイルシステムの一部として動作し、メタデータが変更される事象（例えば、ファイル作成、ファイル更新）を、ストレージ管理サーバ１１２に伝える。事象の通知は、ファイルシステムのメタデータ更新とは非同期に行われることにより、ファイルシステムの操作時間がメタデータ複製１５１の更新処理時間の影響を受けず、ＨＳＭを行わない場合のファイルシステムと同等の性能を実現する。事象通知の電文（イベント）には、以下の情報が含まれる。

・更新対象となるｉｎｏｄｅの情報全て
・追加。削除を含めて、ファイル名の変更を伴う事象の場合、上記に加え、ファイル名および親ディレクトリのｉｎｏｄｅの情報全て

メタ複製部１４１は、ストレージ管理サーバ１１２で動作し、メタ更新通知部１３１からのイベントを元にメタデータ複製１５１を更新する。

次に、ディレクトリポリシ１５２について説明する。

ディレクトリポリシ１５２は、ＨＳＭのためにユーザが決定する運用ルールのうち、ディレクトリ毎に指定するリリースポリシであり、メタデータ複製１５１内のディレクトリのｉｎｏｄｅと対応付けて管理される。リリースポリシは、一次ストレージ１の使用量がＨＷＭを超え、空き領域を生成する場合に、リリースの対象とするファイルの優先順位を決定するためのルールである。リリースポリシは、以下の情報から構成される。

・ｉｎｏｄｅ番号：
ディレクトリのｉｎｏｄｅ番号
・パタン：
リリーススコア重み値は、ディレクトリ単位で指定するだけではなく、ディレクトリ内のファイルをグループ分けすることにより、グループ単位で指定することができる。パタンは、どのグループに属するかを決定するための情報であり、ファイル名が所定の条件を満たすこと、または、ファイルのオーナ・グループが所定の条件を満たすことを指定することができる。
・リリース対象フラグ：
リリース対象とするか（対象）否か（非対称）を示す。
・ファイルサイズ重み値、最終アクセス時刻重み値：
リリース優先順位を表す値をリリーススコアと呼ぶ。あるファイルのリリーススコアは、ファイルサイズ、ファイルの最終アクセス時刻からの経過時間等から決定されることが一般的である。リリーススコアを算出する際におけるファイルサイズの重みをファイルサイズ重み値、最終アクセス時刻の重みを最終アクセス時刻重み値と呼び、後述するリリーススコア算出式で用いられる。ファイルサイズ重み値、最終アクセス時刻重み値は、ユーザにより指定可能である。
・データホールドサイズ：
ｆｉｌｅコマンドによるファイルの精査等による頻繁なリコールを抑止するために、リリース時にファイルの先頭領域の一部を一次ストレージ１上に残すことが一般的である。ユーザはデータホールドサイズをポリシとして指定することができる。

図８は、本実施の形態に係るディレクトリポリシの一例を示す表である。このディレクトリポリシ１５２は、ディレクトリ毎のエントリを持つ。上述したように各エントリは、ディレクトリのｉｎｏｄｅ番号、パタン、リリース対象フラグ、ファイルサイズ重み値、最終アクセス時刻重み値を持つ。

次に、ファイルポリシカタログ１５３について説明する。

ファイルポリシカタログ１５３は、一次ストレージ１の空き容量がＨＷＭを超えた場合のリリース対象となるファイルを特定する処理を高速に行うためのデータカタログである。図９は、本実施の形態に係るファイルポリシカタログの構造の一例を示す表である。ファイルポリシカタログ１５３は、ファイルシステム上の全てのファイル毎のエントリを持つ。各エントリは、ファイル識別子、リリース可能フラグ、リリースポリシ（ファイルリリースポリシ）、リリーススコアを持つ。更に、ファイルポリシカタログ１５３は、エントリを特定するためのファイル識別子インデックスとリリーススコアインデックスを持つ。

ファイル識別子は、ファイルをユニークに特定するキーであり、例えば、ｉｎｏｄｅ番号である。また、ＨＳＭシステムが複数のファイルシステムを管理の対象とする場合、ファイル識別子は、個々のファイルシステムを識別する。リリース可能フラグは、ファイルがリリース可能であるか（可）否か（不可）を示すフラグである。リリース可能とは、ファイルがアーカイブ済みであることを指す。リリースポリシは、リリース対象を制御するため、および、リリース方法を制御するためにユーザにより指定されるポリシである。このポリシは、以下のもので構成される。

・リリース対象フラグ
・ファイルサイズ重み値、最終アクセス時刻重み値

リリース対象決定部１４５は、リリース時、このリリーススコアでソートされた順序に従ってリリースを行う。リリーススコアは、ディレクトリポリシ設定部１４２またはファイルポリシ変更部１４３により、リリースポリシにおける重み値（ファイルサイズ重み値、最終アクセス時刻重み値）と、ファイルの属性（ファイルサイズ、最終アクセス時刻）を元に計算される。リリーススコアは、次のリリーススコア算出式により算出される。

リリーススコア＝ファイルサイズ×ファイルサイズ重み値
＋最終アクセス時刻からの経過時間×最終アクセス時刻重み値

ファイル識別子インデックスは、ファイルポリシカタログ１５３のエントリを更新する際、ファイル識別子から対象となるエントリを高速に特定するためのインデックスである。なお、ファイル識別子インデックスの代わりに、最大ｉｎｏｄｅ数（ファイルシステム作成時に決定される）だけエントリの領域を予め用意し、ｉｎｏｄｅ番号からエントリの位置を一意に特定できる構造を用いても良い。

リリーススコアインデックスは、リリース対象を特定する際、ソートせずエントリをリリーススコア順に抽出するためのインデックスである。従って、リリーススコアインデックスは、インデックスへのデータ格納とともにソートを行う、Ｂ−Ｔｒｅｅのような形式である必要がある。このリリーススコアインデックスを用いることにより、ソートのコストは、リリーススコアの変更契機（ファイルサイズ変更、最終アクセス時刻変更）に分散されることになる。本実施の形態に係るＨＳＭシステムにおいては、ファイルシステム操作と非同期にストレージ管理サーバ１１２へファイルシステムの更新イベントが到達し、かつ、イベントの反映処理をある程度遅延して行うことが許されることから、ファイルシステムのユーザは、上述したような分散されたコストが見えないという利点がある。

次に、ディレクトリポリシ設定部１４２について説明する。

前提技術１において、ディレクトリポリシは、ファイルシステムのメタデータの複製上に、ディレクトリと一対一の情報として保持される。本実施の形態においては、ファイルポリシカタログ１５３内にもディレクトリポリシ１５２の情報の一部を格納する必要があるため、ディレクトリポリシ設定部１４２は、ファイルポリシカタログ１５３を更新する。ディレクトリポリシ設定部１４２は、ユーザにより起動され、ストレージ管理サーバ１１２で動作する。

図１０は、本実施の形態に係るディレクトリポリシ設定部の動作の一例を示すフローチャートである。まず、ディレクトリポリシ設定部１４２は、指定されたディレクトリ直下のファイルのうち、対象ファイルとして最初のファイルを選択し、メタデータ複製１５１から対象ファイルのメタデータを取得する（Ｓ５１１）。次に、ディレクトリポリシ設定部１４２は、対象ファイルがディレクトリであるか否かの判断を行う（Ｓ５１２）。

ディレクトリである場合（Ｓ５１２，Ｙ）、ディレクトリポリシ設定部１４２は、対象ファイルを指定してディレクトリポリシ設定部１４２を再帰的に呼び出し（Ｓ５１３）、処理Ｓ５３１へ移行する。一方、ディレクトリでない場合（Ｓ５１２，Ｎ）、ディレクトリポリシ設定部１４２は、対象ファイルが通常ファイルであると判断し、対象ファイルのメタデータ（サイズ、時刻）と、ディレクトリポリシ１５２の重み値から新しいリリーススコアを算出する（Ｓ５２２）。次に、ディレクトリポリシ設定部１４２は、ファイル識別子インデックスを利用してファイルのｉｎｏｄｅ番号からファイルポリシカタログ上のエントリを特定し（Ｓ５２３）、特定したエントリのリリースポリシとリリーススコアを更新する（Ｓ５２４）。

次に、ディレクトリポリシ設定部１４２は、対象ファイルの次のファイルを選択して新たな対象ファイルとし、対象ファイルのメタデータをメタデータ複製１５１から取得し（Ｓ５３１）、メタデータを取得できたか否かの判断を行う（Ｓ５３２）。メタデータが取得できた場合（Ｓ５３２，Ｙ）、処理Ｓ５１２へ戻る。一方、次の対象ファイルがなく、メタデータを取得できなかった場合（Ｓ５３２，Ｎ）、このフローを終了する。

次に、ファイルポリシ変更部１４３について説明する。

ファイルポリシ変更部１４３は、ＦＳ制御サーバ１１１からストレージ管理サーバ１１２に伝えられるファイルシステムの更新イベントから、メタデータ複製１５１を更新する契機において、変更対象となるファイルと対応するファイルポリシカタログ１５３上のエントリのリリースポリシとリリーススコアを更新する。ファイルポリシ変更部１４３は、ＦＳ制御サーバ１１１からの更新イベントの内容（ファイル作成、ファイル削除、アーカイブ、アーカイブ無効化、リリース、ファイルサイズ変更、最終アクセス時刻変更）に応じた処理を行う。更新イベントの内容は、複数の内容を含む場合もある。

まず、更新イベントがファイル作成である場合について説明する。図１１は、本実施の形態に係るファイルポリシ変更部のファイル作成時の動作の一例を示すフローチャートである。ここで、ファイル作成が行われたファイルを対象ファイルとする。まず、ファイルポリシ変更部１４３は、メタデータ複製１５１から対象ファイルの親ディレクトリのポリシを取得する（Ｓ６１１）。次に、ファイルポリシ変更部１４３は、対象ファイルのメタデータと親ディレクトリのポリシから、対象ファイルのリリーススコアを算出する（Ｓ６１２）。次に、ファイルポリシ変更部１４３は、対象ファイルのエントリをファイルポリシカタログ１５３に追加し（Ｓ６１３）、このフローを終了する。

次に、更新イベントがファイル削除である場合について説明する。図１２は、本実施の形態に係るファイルポリシ変更部のファイル削除時の動作の一例を示すフローチャートである。ここで、ファイル削除が行われたファイルを対象ファイルとする。まず、ファイルポリシ変更部１４３は、ファイル識別子インデックスを利用して、対象ファイルのｉｎｏｄｅ番号からファイルポリシカタログ１５３における対象ファイルのエントリを特定する（Ｓ６２１）。次に、ファイルポリシ変更部１４３は、特定されたエントリを削除し（Ｓ６２２）、このフローを終了する。

次に、更新イベントがアーカイブである場合について説明する。図１３は、本実施の形態に係るファイルポリシ変更部のアーカイブ時の動作の一例を示すフローチャートである。ここで、アーカイブが行われたファイルを対象ファイルとする。まず、ファイルポリシ変更部１４３は、ファイル識別子インデックスを利用して、対象ファイルのｉｎｏｄｅ番号からファイルポリシカタログ１５３における対象ファイルのエントリを特定する（Ｓ６３１）。次に、ファイルポリシ変更部１４３は、特定されたエントリのリリース可能フラグを「可」に変更し（Ｓ６３２）、このフローを終了する。

次に、更新イベントがアーカイブ無効化またはリリースである場合について説明する。図１４は、本実施の形態に係るファイルポリシ変更部のアーカイブ無効化時またはリリース時の動作の一例を示すフローチャートである。ここで、アーカイブ無効化またはリリースが行われたファイルを対象ファイルとする。まず、ファイルポリシ変更部１４３は、ファイル識別子インデックスを利用して、対象ファイルのｉｎｏｄｅ番号からファイルポリシカタログ１５３における対象ファイルのエントリを特定する（Ｓ６４１）。次に、ファイルポリシ変更部１４３は、特定されたエントリのリリース可能フラグを「不可」に変更し（Ｓ６４２）、このフローを終了する。

次に、更新イベントがファイルサイズ変更または最終アクセス時刻変更である場合について説明する。図１５は、本実施の形態に係るファイルポリシ変更部のファイルサイズ変更時または最終アクセス時刻変更時の動作の一例を示すフローチャートである。ここで、ファイルサイズ変更または最終アクセス時刻変更が行われたファイルを対象ファイルとする。まず、ファイルポリシ変更部１４３は、ファイル識別子インデックスを利用して、対象ファイルのｉｎｏｄｅ番号からファイルポリシカタログ１５３における対象ファイルのエントリを特定する（Ｓ６５１）。次に、ファイルポリシ変更部１４３は、特定されたエントリを取得する（Ｓ６５２）。次に、ファイルポリシ変更部１４３は、取得したエントリ中のリリースポリシと変更されたファイルサイズまたは最終アクセス時刻より、リリーススコアを算出する（Ｓ６５３）。次に、ファイルポリシ変更部１４３は、特定されたエントリのリリーススコアを算出した値に更新し（Ｓ６５４）、このフローを終了する。

次に、しきい値制御部１４４とリリース対象決定部１４５による空き領域生成処理について説明する。

ＦＳ制御サーバ１１１のファイルシステムの一部として動作する定期容量通知部１３２は、一定時間間隔で、一次ストレージ１の全体量と使用量をしきい値制御部１４４に通知する。しきい値制御部１４４は、通知されたファイルシステムの使用量がユーザにより予め指定されたしきい値ＨＷＭを超えた場合、ファイルシステムの空き容量を増やすために、リリース対象決定部１４５を起動する。また、しきい値制御部１４４は、リリース対象決定部１４５の起動中、通知されたファイルシステムの使用量がユーザにより予め指定されたしきい値ＬＷＭを下回ったか否かの判断を行い、リリース対象決定部１４５に通知する。

リリース対象決定部１４５は、空き領域を増やすためのリリース対象のファイルの特定を行うとともに、リリースの順序を決定する。図１６は、本実施の形態に係るリリース対象決定部の動作の一例を示すフローチャートである。

まず、リリース対象決定部１４５は、しきい値制御部１４４からの通知により一次ストレージ１の使用量がＬＷＭを下回ったか否かの判断を行う（Ｓ７１１）。ＬＷＭを下回った場合（Ｓ７１１，Ｙ）、このフローを終了する。一方、ＬＷＭを下回らない場合（Ｓ７１１，Ｎ）、リリース対象決定部１４５は、リリーススコアインデックスを利用してリリーススコアの大きいものから順にファイルポリシカタログ１５３のエントリを特定する（Ｓ７１２）。次に、リリース対象決定部１４５は、リリーススコアインデックスの終端に達したか否かの判断を行う（Ｓ７１３）。

終端に達した場合（Ｓ７１３，Ｙ）、このフローを終了する。終端に達していない場合（Ｓ７１３，Ｎ）、リリース対象決定部１４５は、特定したエントリを取得する（Ｓ７１４）。次に、リリース対象決定部１４５は、取得したエントリのリリース可能フラグが「可」であるか否かの判断を行う（Ｓ７２１）。「不可」である場合（Ｓ７２１，Ｎ）、処理Ｓ７１１へ移行する。一方、「可」である場合（Ｓ７２１，Ｙ）、リリース対象決定部１４５は、リリース対象フラグが「対象」であるか否かの判断を行う（Ｓ７２２）。「非対象」である場合（Ｓ７２２，Ｎ）、処理Ｓ７１１へ移行する。一方、「対象」である場合（Ｓ７２２，Ｙ）、特定したエントリに対応するファイルのリリースをリリース部１３３に指示し（Ｓ７２３）、処理Ｓ７１１へ移行する。

従来の空き領域生成処理は、ファイルシステムに存在する全ファイルについてｉｎｏｄｅを参照し、リリースポリシとファイルの属性からリリーススコアを算出するとともに、その結果を蓄積し、蓄積した情報をリリーススコア順にソートし、ソートした順に、ＬＷＭを下回るまで、リリースの指示を出し続ける。一方、本実施の形態によれば、空き領域生成処理時においてリリーススコアの算出とソートの処理時間が不要となる。

本実施の形態によれば、ＨＳＭの運用に際し、ＨＭＷを決定するための要因として空き領域生成処理のタイムラグを考慮して余裕を持たせる必要がなくなり、運用設計が簡単になるとともに、一次ストレージの領域を有効に利用することができる。

また、本実施の形態に係るＨＳＭ制御装置は、サーバに容易に適用することができ、サーバの性能をより高めることができる。

更に、ＨＳＭ制御装置を構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、ＨＳＭ制御プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、ＨＳＭ制御装置を構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

（付記１） ＨＳＭの制御をコンピュータに実行させるＨＳＭ制御プログラムであって、
ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、
ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、
リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップと
をコンピュータに実行させるＨＳＭ制御プログラム。
（付記２） 付記１に記載のＨＳＭ制御プログラムにおいて、
前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするＨＳＭ制御プログラム。
（付記３） 付記２に記載のＨＳＭ制御プログラムにおいて、
前記リリース情報管理ステップは、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするＨＳＭ制御プログラム。
（付記４） 付記３に記載のＨＳＭ制御プログラムにおいて、
前記リリース情報は、更にファイル識別子を含み、
前記リリース情報管理ステップは、ファイル識別子に対応するリリース情報を検索するためのファイル識別子インデックスを管理し、前記メタデータ複製情報が更新された場合、または、前記ディレクトリリリースポリシが設定された場合、ファイル識別子とファイル識別子インデックスに基づいて対応するリリース情報を特定することを特徴とするＨＳＭ制御プログラム。
（付記５） 付記１乃至付記４のいずれかに記載のＨＳＭ制御プログラムにおいて、
前記リリーススコアインデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御プログラム。
（付記６） 付記１乃至付記５のいずれかに記載のＨＳＭ制御プログラムにおいて、
前記ファイル識別子インデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御プログラム。
（付記７） 付記１乃至付記６のいずれかに記載のＨＳＭ制御プログラムにおいて、
前記ファイル決定ステップは、前記リリーススコアが大きいファイルから順に、リリース対象とすることを特徴とするＨＳＭ制御プログラム。
（付記８） ＨＳＭの制御を行うＨＳＭ制御装置であって、
ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理部と、
ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理部により管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理部と、
リリースが指示された場合、前記ファイル情報管理部により管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定部と
を備えるＨＳＭ制御装置。
（付記９） 付記８に記載のＨＳＭ制御装置において、
前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするＨＳＭ制御装置。
（付記１０） 付記９に記載のＨＳＭ制御装置において、
前記リリース情報管理部は、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするＨＳＭ制御装置。
（付記１１） 付記１０に記載のＨＳＭ制御装置において、
前記リリース情報は、更にファイル識別子を含み、
前記リリース情報管理部は、ファイル識別子に対応するリリース情報を検索するためのファイル識別子インデックスを管理し、前記メタデータ複製情報が更新された場合、または、前記ディレクトリリリースポリシが設定された場合、ファイル識別子とファイル識別子インデックスに基づいて対応するリリース情報を特定することを特徴とするＨＳＭ制御装置。
（付記１２） 付記８乃至付記１１のいずれかに記載のＨＳＭ制御装置において、
前記リリーススコアインデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御装置。
（付記１３） 付記８乃至付記１２のいずれかに記載のＨＳＭ制御装置において、
前記ファイル識別子インデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御装置。
（付記１４） 付記８乃至付記１３のいずれかに記載のＨＳＭ制御装置において、
前記ファイル決定部は、前記リリーススコアが大きいファイルから順に、リリース対象とすることを特徴とするＨＳＭ制御装置。
（付記１５） ＨＳＭの制御を行うＨＳＭ制御方法であって、
ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、
ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、
リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップと
を実行するＨＳＭ制御方法。
（付記１６） 付記１５に記載のＨＳＭ制御方法において、
前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするＨＳＭ制御方法。
（付記１７） 付記１６に記載のＨＳＭ制御方法において、
前記リリース情報管理ステップは、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするＨＳＭ制御方法。
（付記１８） 付記１７に記載のＨＳＭ制御方法において、
前記リリース情報は、更にファイル識別子を含み、
前記リリース情報管理ステップは、ファイル識別子に対応するリリース情報を検索するためのファイル識別子インデックスを管理し、前記メタデータ複製情報が更新された場合、または、前記ディレクトリリリースポリシが設定された場合、ファイル識別子とファイル識別子インデックスに基づいて対応するリリース情報を特定することを特徴とするＨＳＭ制御方法。
（付記１９） 付記１５乃至付記１８のいずれかに記載のＨＳＭ制御方法において、
前記リリーススコアインデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御方法。
（付記２０） 付記１５乃至付記１９のいずれかに記載のＨＳＭ制御方法において、
前記ファイル識別子インデックスは、Ｂ−Ｔｒｅｅ構造を有することを特徴とするＨＳＭ制御方法。

前提技術１に係るＨＳＭ装置の構成の一例を示すブロック図である。 前提技術１に係るファイル情報取得処理の動作の一例を示すフローチャートである。 前提技術１に係る名前空間におけるディレクトリの階層構造の一例を示す図である。 前提技術１に係るファイル情報取得処理の動作の一例を示すフローチャートである。 前提技術１に係るイベントデータ反映処理の動作の一例を示すフローチャートである。 前提技術１に係るマイグレート決定処理の動作の一例を示すフローチャートである。 本実施の形態に係るＨＳＭシステムの構成の一例を示すブロック図である。 本実施の形態に係るディレクトリポリシの一例を示す表である。 本実施の形態に係るファイルポリシカタログの構造の一例を示す表である。 本実施の形態に係るディレクトリポリシ設定部の動作の一例を示すフローチャートである。 本実施の形態に係るファイルポリシ変更部のファイル作成時の動作の一例を示すフローチャートである。 本実施の形態に係るファイルポリシ変更部のファイル削除時の動作の一例を示すフローチャートである。 本実施の形態に係るファイルポリシ変更部のアーカイブ時の動作の一例を示すフローチャートである。 本実施の形態に係るファイルポリシ変更部のアーカイブ無効化時またはリリース時の動作の一例を示すフローチャートである。 本実施の形態に係るファイルポリシ変更部のファイルサイズ変更時または最終アクセス時刻変更時の動作の一例を示すフローチャートである。 本実施の形態に係るリリース対象決定部の動作の一例を示すフローチャートである。

符号の説明

１ 一次ストレージ、２ 二次ストレージ、３ サーバ、１１ アプリケーション部、１２ ファイルシステム制御部、１３ 名前空間複製部、１４ 名前空間追随部、１５ 名前空間複製ＤＢ、１６ マイグレート決定部、２１ イベントデータ記録部、１１１ ＦＳ制御サーバ、１１２ ストレージ管理サーバ、１１３ ＨＳＭデータベース、１２１ ＡＣ、１２２ ＭＤＳ、１２３ 仮想ボリューム管理部、１３１ メタ更新通知部、１３２ 定期容量通知部、１３３ リリース部、１４１ メタ複製部、１４２ ディレクトリポリシ設定部、１４３ ファイルポリシ変更部、１４４ しきい値制御部、１４５ リリース対象決定部、１４６ データ移動部、１５１ メタデータ複製、１５２ ディレクトリポリシ、１５３ ファイルポリシカタログ。

Claims (5)

1. ＨＳＭの制御をコンピュータに実行させるＨＳＭ制御プログラムであって、
   ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、
   ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、
   リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップと
   をコンピュータに実行させるＨＳＭ制御プログラム。
2. 請求項１に記載のＨＳＭ制御プログラムにおいて、
   前記リリース情報は、ファイル毎のリリースポリシであるファイルリリースポリシを含むことを特徴とするＨＳＭ制御プログラム。
3. 請求項２に記載のＨＳＭ制御プログラムにおいて、
   前記リリース情報管理ステップは、ディレクトリのリリースポリシであるディレクトリリリースポリシが設定された場合、該ディレクトリリリースポリシに基づいて該ディレクトリの配下のファイルのファイルリリースポリシを更新すると共に、該ファイルリリースポリシと前記メタデータ複製情報に基づいてリリーススコアを算出し、前記リリーススコアインデックスを更新することを特徴とするＨＳＭ制御プログラム。
4. ＨＳＭの制御を行うＨＳＭ制御装置であって、
   ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理部と、
   ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理部により管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理部と、
   リリースが指示された場合、前記ファイル情報管理部により管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定部と
   を備えるＨＳＭ制御装置。
5. ＨＳＭの制御を行うＨＳＭ制御方法であって、
   ファイルシステムにおけるファイル毎のメタデータが複製された情報をメタデータ複製情報として管理するメタデータ複製情報管理ステップと、
   ファイル毎のリリースに関する情報をリリース情報として管理し、前記メタデータ複製情報管理ステップにより管理されたメタデータ複製情報が更新された場合、前記メタデータ複製情報と前記リリース情報とに基づいてファイル毎のリリースの優先度を示すリリーススコアを算出し、該リリーススコアに対応するリリース情報を検索するためのインデックスであるリリーススコアインデックスを管理するリリース情報管理ステップと、
   リリースが指示された場合、前記ファイル情報管理ステップにより管理されたリリーススコアインデックスに基づいてリリース対象のファイルを決定するファイル決定ステップと
   を実行するＨＳＭ制御方法。

Images