JP4782017B2 - 拡張可能なファイルシステムメタデータの作成及びファイルシステムコンテンツ処理のためのシステムと方法 - Google Patents

Description

本発明は、コンピュータシステムに関し、更に具体的にはファイルベースのストレージシステムに関する。

コンピュータシステムは、アプリケーションデータやこのようなデータを処理するように構成された実行可能なコードを含む大量の情報を処理することが多い。多くの実施態様において、コンピュータシステムは、データを格納するように構成された、磁気や光学のディスクドライブ、テープドライブなどの種々のタイプの大容量ストレージデバイスを設けている。これらの格納されたデータにアクセスするための系統的正規インターフェースを提供するためには、このようなストレージデバイスは、オペレーティングシステムなどのソフトウェアによってファイルの階層に頻繁に編成される。多くの場合、ファイルは、ストレージデバイス内でユーザーが操作できるデータ細分性の最小レベルを定義するが、種々のアプリケーションとオペレーティングシステムプロセスは、ファイル全体よりも低レベルの細分性でファイル内のデータに対し操作することができる。

幾つかのファイルベースのコンピュータシステムでは、メタデータとも呼ばれるファイルに関する種々のタイプの情報が、ファイル自体に加えて記憶される。しかしながら、一般的な従来のコンピュータシステムでは、メタデータのサポートは、少数の固定されたタイプのファイル属性に制限され、ファイル情報の追加が必要とされる場合に増補することができない。更に、メタデータにアクセスする手続きは、よりフレキシブルな手続きではなく、所与のファイルを識別し、次いでその関連するメタデータを検索することに限定される場合がある。

更に、複合コンピュータ環境では多数のアプリケーションが用意され、特定の機能を実行するために、その各々が、ファイルやストレージデバイスと相互作用する。場合によっては、幾つかのアプリケーションの各々は、複合多段階トランザクションの特定のステップを実行するように構成される。しかしながら、このようなアプリケーションは、相互の相互作用又は協調機能を制限する場合があり、トランザクション処理を協調させるためにシステムユーザー側でかなりの程度の介入を必要とする。

拡張可能なファイルシステムメタデータを生成するためのシステムと方法の種々の実施態様が開示される。１つの実施態様では、本システムは、データを格納するように構成されたストレージデバイスと、該ストレージデバイスへのアクセスを管理し、ファイルシステムコンテンツを格納するように構成されたファイルシステムとを含む。ファイルシステムは、ファイルシステムコンテンツアクセスイベントを検出し、そのファイルシステムコンテンツアクセスイベントの検出に応答して、メタデータレコードを生成するように更に構成され、該メタデータレコードは、拡張可能な自己記述データフォーマットで格納される。

システムの１つの特定の実装において、ファイルシステムコンテンツアクセスイベントを検出することは、以下に更に詳細に説明されるようにバンド内で実行される。システムの別の特定の実装においては、拡張可能な自己記述データフォーマットは、あるバージョンの拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することができる。

１つの実施態様において、ファイルシステムコンテンツを格納し、ファイルシステムコンテンツアクセスイベントを検出し、ファイルシステムコンテンツアクセスイベントの検出に応答してメタデータレコードを生成し、拡張可能な自己記述データフォーマットでメタデータレコードを格納することを含む方法も企図される。

本発明は種々の修正及び代替形態が可能であるが、本発明の特定の実施形態を図面において例として示し、本明細書で詳細に説明する。しかしながら、本明細書の図面及び詳細な説明は、開示される特定の形態に本発明を限定するものではなく、添付の請求項によって定義される本発明の精神及び範囲内に含まれる全ての修正形態、均等物、及び代替形態を保護するものである点を理解されたい。

（コンピュータシステムの概要）
ここで図１を参照すると、コンピュータシステムの１つの実施形態のブロック図が示されている。図示された実施形態では、システム１０は、システム相互接続部４０を介して複数のストレージデバイス３０ａ、３０ｂに結合された複数のホストデバイス２０ａ、２０ｂを含む。更に、ホストデバイス２０ｂは、図示の実施形態ではシステムメモリ２５を含む。説明を簡単にするために、参照番号の後に続く文字によって本明細書で示される要素は、参照番号だけで総称して参照する場合がある。例えば、ホストデバイス２０ａ、２０ｂとストレージデバイス３０ａ、３０ｂは、ホストデバイス２０とストレージデバイス３０として総称して参照する場合がある。

システム１０の種々の実施形態では、ホストデバイス２０は、ストレージデバイス３０の１つ又はそれ以上に格納されたデータにアクセスするように構成される。１つの実施形態では、システム１０は、例えば統合ストレージサーバとして単一のコンピュータシステム内に実装される。このような実施形態では、例えば、ホストデバイス２０は、個々のプロセッサとすることができ、システムメモリ２５は、スタティックＲＡＭ（ＳＲＡＭ）のようなキャッシュメモリとすることができ、ストレージデバイス３０は、ハードディスクドライブ又は他の書き込み可能もしくは書き換え可能媒体などの大容量ストレージデバイスとすることができ、更にシステム相互接続部４０は、周辺コンポーネントインターフェース（ＰＣＩ）バスのような周辺バス相互接続部を含む。幾つかのこのような実施形態では、システム相互接続部４０は、ホストデバイス２０とストレージデバイス３０の間の幾つかのタイプの相互接続部を含む。例えば、システム相互接続部４０は、ホストデバイス２０に結合されるように構成された１つ又はそれ以上のプロセッサバス（図示せず）、該プロセッサバスを１つ又はそれ以上の周辺バスに結合するように構成された１つ又はそれ以上のバスブリッジ（図示せず）、周辺バスをストレージデバイス３０に結合するように構成された１つ又はそれ以上のストレージデバイスインターフェース（図示せず）を含む。ストレージデバイスインターフェースのタイプは、種々の実施形態において、例えば、小型コンピュータシステムインターフェース（ＳＣＳＩ）、ＡＴＡパケットインターフェース（ＡＴＡＰＩ）、ファイアワイヤ、及び／又はユニバーサルシリアルバス（ＵＳＢ）を含むが、他のインターフェースタイプを含む多くの他の実施形態が可能であり企図される。

単一のコンピュータシステム内に実装されるシステム１０の実施形態では、システム１０は、１つ又はそれ以上の他のコンピュータシステム（図示せず）のためのデータストレージ要件の大部分を提供するように構成され、このような他のコンピュータシステムと通信するように構成される。他の実施形態では、システム１０は、例えばストレージエリアネットワーク（ＳＡＮ）などの分散ストレージシステムとして構成される。このような実施形態では、例えば、ホストデバイス２０は、サーバシステムなどの個々のコンピュータシステムとすることができ、システムメモリ２５は、ダイナミックＲＡＭ（ＤＲＡＭ）の１つ又はそれ以上のタイプから構成され、ストレージデバイス３０は、各々が１つ又はそれ以上のハードディスクドライブ又は他のタイプのストレージを含むスタンドアロンのストレージノードとすることができ、更にシステム相互接続部４０は、Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット（登録商標））又はＦｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバーチャネル）などの通信ネットワークとすることができる。システム１０の分散ストレージ構成は、ストレージシステム容量及びホストとストレージデバイスとの間のデータ帯域幅のスケーリングを容易にすることができる。

更に別の実施形態では、システム１０は、ハイブリッドストレージシステムとして構成され、ここでは一部のストレージデバイス３０は、幾つかのホストデバイス２０と同じコンピュータシステム内に統合され、他のストレージデバイス３０は、ネットワークを介して他のホストデバイス２０に結合されたスタンドアロンデバイスとして構成される。このようなハイブリッドストレージシステムでは、システム相互接続部４０は、上述の周辺バスやネットワーク相互接続部などの種々の相互接続部メカニズムを含む。

２つのホストデバイス２０と２つのストレージデバイス３０が図１に示されているが、システム１０は、別の実施形態ではこれらのタイプのデバイスの各々の任意の数を有してもよいことに留意されたい。またシステム１０の幾つかの実施形態では、１つより多いシステムメモリ２５のインスタンスを、例えば他のホストデバイス２０又はストレージデバイス３０で用いることができる。更に、幾つかの実施形態では、所与のシステムメモリ２５は、ホストデバイス２０やストレージデバイス３０の外部に存在することができ、所与のホストデバイス２０又はストレージデバイス３０に直接結合し、或いはシステム相互接続部４０を介して間接的に結合することができる。

システム１０の多くの実施形態では、１つ又はそれ以上のホストデバイス２０は、プログラム命令を実行して、データを参照するように構成され、これによって計算機能を実行する。幾つかの実施形態では、システムメモリ２５は、このようなプログラム命令とデータを記憶するように構成されたコンピュータアクセス可能媒体の１つの実施形態とすることができる。しかし、他の実施形態では、プログラム命令及び／又はデータを別のタイプのコンピュータアクセス可能媒体上で受け取り、送り、或いは格納することができる。一般的に言うと、コンピュータアクセス可能媒体は、ストレージデバイス３０としてシステム１０内に含まれる磁気又は光学媒体（例えば、ディスク又はＣＤ−ＲＯＭ）などのストレージ媒体又はメモリ媒体を含む。コンピュータアクセス可能媒体はまた、システムメモリ２５としてシステム１０の幾つかの実施形態において含むＲＡＭ（例えばＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどの揮発性又は不揮発性媒体を含む。更に、コンピュータアクセス可能媒体は、システム相互接続部４０としてシステム１０の幾つかの実施形態内に含む、ネットワーク及び／又は無線リンクなどの通信媒体を介して伝達される電子、電磁、又はデジタル信号といった送信媒体又は信号を含む。

幾つかの実施形態では、上述のようなコンピュータアクセス可能媒体内に格納されたプログラム命令とデータは、種々のアプリケーションプログラムを実行するための環境を提供できるオペレーティングシステムを実装する。例えば、所与のホストデバイス２０は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム、Ｕｎｉｘ（登録商標）／Ｌｉｎｕｘオペレーティングシステム、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈオペレーティングシステム、或いは別の適切なオペレーティングシステムのあるバージョンを実行するように構成される。更に、所与のホストデバイスは、多くの他の利用可能なアプリケーションの中から、ワードプロセッサ、ウェブブラウザ及び／又はサーバ、電子メールクライアント及び／又はサーバ、マルチメディアアプリケーションなどといったアプリケーションプログラムを実行するように構成される。

所与のホストデバイス２０で実行中に、オペレーティングシステム又は所与のアプリケーションのいずれかは、所与のストレージデバイス３０からロードされるか、又は所与のストレージデバイス３０に格納されるデータに対する要求を生成することができる。例えば、オペレーティングシステムの一部又はアプリケーション自体に対応するコードは、所与のストレージデバイス３０に格納することができ、従って、求められるオペレーションシステムルーチン又はアプリケーションプログラムの呼出しに応答して、対応するコードを検索して実行することができる。同様に、オペレーティングシステム又はアプリケーションの実行は、格納されるべきデータを作成することができる。

幾つかの実施形態では、ストレージデバイス３０に格納されたデータの移動と処理は、ソフトウェアベースのストレージシステムによって管理することができる。１つのこのような実施形態が図２に示されており、コンテンツアウェアストレージシステム(content aware storage system)１５０を介して複数のストレージデバイス２３０Ａ−Ｃにインターフェースするアプリケーションレイヤ１００を示している。図２に示されている幾つかのモジュールは、ユーザー実行モード又は「ユーザースペース」で実行するように構成され、他のモジュールは、カーネル実行モード又は「カーネルスペース」で実行するように構成される。図示された実施形態では、アプリケーションレイヤ１００は、複数のユーザースペースソフトウェアプロセス１１２Ａ−Ｃを含む。プロセス１１２の各々が、ＡＰＩ１１４Ａ−Ｃの各々にアクセスするように、各プロセスは複数のアプリケーションプログラミングインターフェース（ＡＰＩ）１１４Ａ−Ｃを介してストレージシステム１５０にインターフェースする。ストレージシステム１５０は、ＡＰＩ１１４Ａを介したアプリケーションレイヤ１００へのインターフェースを示すカーネルスペースストレージ管理システム２００；ＡＰＩ１１４Ｂを介したアプリケーションレイヤ１００へのインターフェースを示すユーザースペースコンテンツ処理システム３００；ＡＰＩ１１４Ｃを介したアプリケーションレイヤ１００へのインターフェースを示すユーザースペース問い合わせシステム４００を含む。図示の実施形態では、ストレージ管理システム２００は更に、ストレージデバイス２３０Ａ−Ｃにインターフェースする。

幾つかの実施形態では、任意の数のプロセス１１２及び／又はストレージデバイス２３０を実装することができる。幾つかの実施形態では、コンテンツ処理システム３００及び／又は問合せシステム４００の全部又は一部をカーネルスペースで実装することができ、幾つかの実施形態では、カーネルスペースで実行するように構成されたプロセスが、ＡＰＩ１１４又はカーネルスペースプロセスに固有の他のＡＰＩを介してストレージシステム１５０にアクセスするように構成される。

１つの実施形態では、プロセス１１２の各々は、所与のユーザーアプリケーションに対応することができ、更に各々は、ＡＰＩ１１４への呼出しを介してストレージデバイス２３０Ａ−Ｃにアクセスするように構成される。ＡＰＩ１１４は、プロセス１１２をストレージシステム１５０の種々の構成要素へアクセスさせる。例えば、１つの実施形態でＡＰＩ１１４は、所与のプロセス１１２が呼び出すことのできるストレージシステム１５０によって示される関数呼出しを含むことができ、他の実施形態ではＡＰＩ１１４は、プロセス間通信の他のタイプをサポートすることができる。１つの実施形態では、ストレージデバイス２３０は、図１のストレージデバイス３０の例とすることができる。更に、１つの実施形態では、ストレージシステム１５０の構成要素のいずれか及び／又はプロセス１１２のいずれかは、例えば、図１のシステムメモリ２５のようなコンピュータアクセス可能媒体内に格納されたプログラム命令とデータとして図１の１つ又はそれ以上のホストデバイス２０上で実行されるように構成される。

図３から図９の説明と共に以下に更に詳細に説明されるように、ストレージシステム１５０は、種々のストレージ関連サービスを提供するように構成される。例えば、１つの実施形態では、ストレージ管理システム２００は、ファイルシステムを使用してストレージデバイス２３０によって格納されたデータを編成するように構成され、種々のプロセス１１２は、階層ファイルとしてデータを記憶し、操作することができる。更に、ストレージシステム１５０は、格納されたデータへのアクセス及び／又は操作のオペレーションを監視し、このようなオペレーションのレコードを生成するように構成される。問合せシステム４００は、ストレージデバイス２３０によって格納されたデータを問い合わせる、及びこのようなデータにアクセスするオペレーションのレコードを問い合わせるためのインターフェースをプロセス１１２に提供するように構成される。最後に、コンテンツ処理システム３００は、ストレージ管理システム２００のアクティビティを監視し、こうしたアクティビティの追加のレコードを生成するように構成される。以下に更に詳細に説明されるように、コンテンツ処理システム３００は更に、このようなアクティビティの検出に応答して１つ又はそれ以上のアプリケーションを呼び出すように構成され、これにより、アプリケーションレイヤ１００のアクティビティに直接（例えばプロセス１１２によるデータ要求に）基づくのではなく、ストレージ管理システム２００のアクティビティに基づいてコンテンツ処理アクティビティを開始するためのメカニズムを提供する。ストレージシステム１５０の幾つかの実施形態では、コンテンツ処理システム３００、問合せシステム４００、又はこの両方のシステムを省くことができると同時に、ストレージ管理システム２００によって提供されるサービスを維持することができる点が企図される。

（ストレージ管理システム及びファイルシステム）
上で述べたように、幾つかの実施形態では、ストレージ管理システム２００は、ストレージデバイス２３０によって提供されるストレージスペースをファイルに編成するためのデータ構造と制御構造を提供することができる。種々の実施形態では、データ構造は、例えば、各ファイルのアイデンティティ、ストレージデバイス２３０内の位置（例えば、特定のストレージデバイス内の特定の物理位置へのマッピング）などの情報、以下に更に詳細に説明されるような各ファイルについての他の情報を記憶するように構成された１つ又はそれ以上のテーブルを含む。また種々の実施形態では、制御構造は、例えばファイルアイデンティティの変更やファイルコンテンツの修正のための関数呼出しなどのファイルを操作するための実行可能なルーチンを含む。総称して、これらのデータと制御構造を、本明細書ではファイルシステムと呼び、所与のファイルシステムによって実施される特定のデータフォーマットとプロトコルは、本明細書ではファイルシステムのフォーマットと呼ぶことがある。

幾つかの実施形態では、ストレージデバイス２３０に格納されたデータへのいずれかのアクセスがファイルシステムの制御とデータ構造によって管理されるように、ファイルシステムをオペレーティングシステムに統合することができる。種々のオペレーティングシステムは、種々のフォーマットを使用して種々の固有ファイルシステムを実装することができるが、幾つかの実施形態では、所与のオペレーティングシステムは、他のオペレーティングシステムに固有のファイルシステムフォーマットを含む、複数の異なるタイプのファイルシステムフォーマットをサポートするファイルシステムを含む。このような実施形態では、ファイルシステムによってサポートされる種々のファイルシステムフォーマットは、本明細書ではローカルファイルシステムと呼ぶことができる。更に、幾つかの実施形態では、ファイルシステムは、図３に示されるように階層状に配列された複数レイヤの機能を使用して実装できる。

図３は、ストレージ管理システム２００の１つの実施形態を示す。図示の実施形態では、ストレージ管理システムは、１つ又はそれ以上のデバイスドライバ２２４とインターフェースするように構成されたファイルシステム２０５を含み、該デバイスドライバはストレージデバイス２３０にインターフェースするように構成される。図２のストレージシステム１５０内で図示されたように、ストレージ管理システム２００の構成要素は、カーネルスペース内で実行するように構成されるが、幾つかの実施形態では、ストレージ管理システム２００の一部の構成要素は、ユーザースペース内で実行するように構成されることも意図される。同様に、１つの実施形態では、ストレージ管理システム２００の構成要素のいずれかは、例えば図１のシステムメモリ２５のようなコンピュータアクセス可能媒体内に記憶されたプログラム命令とデータのように、図１の１つ又はそれ以上のホストデバイス２０上で実行するよう構成される。

図１のシステム１０に関して上述されたように、所与のホストデバイス２０は、所与のストレージデバイス３０とは異なるコンピュータシステムに存在することができ、ネットワークを介して当該ストレージデバイスにアクセスできる。同様にストレージ管理システム２００に関して、１つの実施形態において、プロセス１１２Ａのような所与のプロセスはリモートで実行することができ、ネットワークを介してストレージデバイス２３０にアクセスすることができる。図示された実施形態では、ファイルシステム２０５は、リモートプロセスによるファイルシステムへのアクセスをサポートするためにネットワークプロトコル２２５を含む。幾つかの実施形態では、ネットワークプロトコル２２５は、例えばネットワークファイルシステム（ＮＦＳ）プロトコル又は共通インターネットファイルシステム（ＣＩＦＳ）プロトコルに対するサポートを含むが、いずれかの適切なネットワークプロトコルを用いてもよく、複数のこのようなプロトコルを幾つかの実施形態においてサポートすることができる。

ファイルシステム２０５は、複数のローカルファイルシステムをサポートするよう構成される。図示された実施形態では、ファイルシステム２０５は、ＶＥＲＩＴＡＳ（ＶｘＦＳ）フォーマットローカルファイルシステム２４０Ａ、Ｂｅｒｋｅｌｅｙ高速ファイルシステム（ＦＦＳ）フォーマットローカルファイシステム２４０Ｂ、プロプラエタリ（Ｘ）フォーマットローカルファイルシステム２４０Ｘを含む。しかしながら、他の実施形態において、いずれかの数のローカルファイルファイルシステムフォーマット又はこれらの組合せをファイルシステム２０５によってサポートすることができる。種々のローカルファイルシステム２４０への共通インターフェースを提供するために、ファイルシステム２０５は、仮想ファイルシステム２２２を含む。１つの実施形態では、仮想ファイルシステム２２２は、プロセス１１２により生じるファイルシステムオペレーションを各オペレーションによってターゲットされた特定のローカルファイルシステム２４０に適用可能なフォーマットに翻訳するように構成される。更に、図示された実施形態ではストレージ管理システム２００は、ローカルファイルシステム２４０がストレージデバイス２３０にアクセスできるデバイスドライバ２２４を含む。デバイスドライバ２２４は、ストレージデバイス２３０によって用いられるインターフェースのタイプに固有のデータ転送プロトコルを実装する。例えば、１つの実施形態では、デバイスドライバ２２４は、ＳＣＳＩ及びＡＴＡＰＩインターフェース全体に渡るデータの転送をサポートすることができるが、他の実施形態では、デバイスドライバ２２４は、インターフェースの他のタイプ及び組合せをサポートすることができる。

図示された実施形態では、ファイルシステム２０５はまたフィルタドライバ２２１を含む。幾つかの実施形態では、フィルタドライバ２２１は、ファイルシステム２０５に入力する各オペレーションを監視し、オペレーションの特定のタイプを検出した後、追加のオペレーションを実行し、或いは検出されたオペレーションの動作を変更するように構成される。例えば、１つの実施形態では、フィルタドライバ２２１は、複数の書き込みオペレーションを単一の書き込みオペレーションに統合してファイルシステム性能を向上させるように構成される。別の実施形態では、フィルタドライバ２２１は、当該ファイルへの書き込みを検出した後にファイルのシグネチャを計算するように構成される。更に別の実施形態では、フィルタドライバ２２１は、以下に更に詳細に説明するように、これらのファイルに対するオペレーションの幾つかの種類を検出することに続いて、特定のファイルに関連したレコードなどの情報を記憶するように構成される。幾つかの実施形態では、フィルタドライバ２２１が具体的には言及しない他のフィルタオペレーションを含む上述のオペレーションの１つ又はそれ以上の組合せを実装するように構成される。

ファイルシステムオペレーションが要求又は処理されるときに、該オペレーションを検出するように構成されているフィルタドライバ２２１の実施形態は、このようなオペレーションの「バンド内」検出を実行する、ということができる。或いは、このような検出は、検出されたオペレーション又はイベントの発生に対して同期している、ということができる。幾つかの実施形態では、オペレーションのバンド内検出に応答して取られる処理動作は、オペレーションが終了される方法に影響を与える可能性がある。例えば、ファイル読み取りオペレーションのバンド内検出は、オペレーションのソースが要求されたファイルにアクセスするのに十分な特権が与えられていない場合には、オペレーションの取消しを生じることがある。幾つかの実施形態では、オペレーションのバンド内検出は、オペレーション自体の終了にどのような影響をも及ぼすことはないが、以下に説明されるようにメタデータレコードで検出されたオペレーションの発生を記録するような追加のオペレーションを生成することができる。

逆に、ファイルシステムオペレーション又はイベントは、この発生の後に続いて検出してもよく、その結果、オペレーション又はイベントが既に終了した後に検出を行うようにすることができる。このような検出は、「バンド外」、又は検出されたオペレーション又はイベントに対して非同期である、ということができる。例えば、ユーザープロセス１１２は、ファイルを定期的にチェックしてファイルの長さを求めることができる。ファイル長は、ユーザープロセス１１２による最後のチェック以降いつでも変更することができるが、チェックは、ファイルの長さを変更したオペレーションに対してバンド外とすることができる。場合によっては、バンド外検出が幾つかのイベントの検出に失敗する可能性がある。前記の例を参照すると、ファイル長は、ユーザープロセス１１２による最後のチェック以降に数回変更することができるが、最後の変更だけを検出してもよい。

オペレーション又はイベントはバンド内で検出することができるが、このような検出に応答して取られる動作は、検出されたオペレーションの終了の前後のいずれかで行うことができる点に留意されたい。前記の例を参照すると、１つの実施形態では、チェックされたファイルの長さを修正するための各オペレーションは、バンド内で検出して記録することができる。ユーザープロセス１１２は、レコードを定期的に検査してファイルの長さを求めるように構成される。長さ修正オペレーションが検出されバンド内で記録されたので、ユーザープロセス１１２は、このような各オペレーションを考慮に入れることができ、これらのオペレーションの発生後でも良好に行うことができる。

フィルタドライバ２２１はファイルシステム２０５の一部であり、ユーザースペース内のアプリケーション又はプロセスではない点に留意されたい。従って、フィルタドライバ２２１は、ユーザースペース２１０内のアプリケーションやプロセスとは無関係に動作するように構成される。代替的に、又は上記に加えて、フィルタドライバ２２１は、ユーザースペース２１０内のアプリケーション又はプロセスから受け取られた要求に応じてオペレーションを実行するように構成される。

幾つかの実施形態では、カーネルスペース２２０は、ユーザースペースプロセス１１２に類似したストレージデバイス２３０へのアクセスを生成するプロセス（図示せず）を含む点に更に留意されたい。このような実施形態では、カーネルスペース２２０で実行するプロセスは、ユーザースペースプロセス１１２に類似した方法でカーネルモードＡＰＩ（図示せず）を介してファイルシステム２０５にアクセスするように構成される。従って、幾つかの実施形態では、ストレージデバイス２３０への全てのアクセスは、アクセスオペレーションを生じるプロセスのタイプ又はスペースに関わらずファイルシステム２０５によって処理することができる。

ストレージ管理システム２００とファイルシステム２０５の多数の別の実施形態が可能であり企図される。例えば、ファイルシステム２０５は、種々の数及びフォーマットのローカルファイルシステム２４０をサポートし、或いは単一のローカルファイルシステム２４０だけをサポートすることができる。幾つかの実施形態では、ネットワークプロトコル２２５は省略することができ、或いはファイルシステム２０５の外部のストレージ管理システム２００の一部に統合してもよい。同様に、幾つかの実施形態では、例えば単一のローカルファイルシステム２４０だけが使用中である場合、仮想ファイルシステム２２２は省略又は無効にすることができる。更に、幾つかの実施形態では、フィルタドライバ２２１は、ファイルシステム２０５の異なるレイヤ内に実装される。例えば、１つの実施形態では、フィルタドライバ２２１は、仮想ファイルシステム２２２に統合することができ、別の実施形態では、フィルタドライバ２２１のインスタンスをローカルファイルシステム２４０の各々に実装することができる。

ファイル及びメタデータ
上述のように、ファイルシステム２０５は、ストレージデバイス２３０に格納された複数のファイルへのアクセスを管理するように構成される。多くの実施形態では、各格納ファイルは、各ファイルを他のファイルと区別するためにファイルシステムにより使用される関連するアイデンティティを有することができる。ファイルシステム２０５の１つの実施形態では、ファイルのアイデンティティをファイル名とすることができ、例えば「ｆｉｌｅｎａｍｅ．ｔｘｔ」などの文字列を含む。しかしながら、フォルダ又はディレクトリの階層などのファイル階層を実施するファイルシステム２０５の実施形態においては、ファイル階層の全部又は一部をファイル・アイデンティティに含めることができる。例えば、所与のファイル名の「ｆｉｌｅ１．ｔｘｔ」は、ディレクトリ「ｕｓｅｒｓ」に存在するディレクトリ「ｓｍｉｔｈ」内に存在することができる。ディレクトリ「ｕｓｅｒｓ」は、ファイルシステム２０５内のトップレベルすなわちルートレベルのディレクトリであるディレクトリ「ｔｅｓｔ１」内に存在することができる。幾つかの実施形態では、ファイルシステム２０５は、高レベルのディレクトリがルートディレクトリを含まない場合に、全てのルートレベルのディレクトリを含むように単一の「ルートディレクトリ（ｒｏｏｔ ｄｉｒｅｃｔｏｒｙ）」を定義できる。他の実施形態では、複数のトップレベルのディレクトリは、高レベルのディレクトリがどのようなトップレベルのディレクトリも含まないように共存することができる。所与のファイルが位置付けられる特定のフォルダ又はディレクトリの名前を、本明細書では所与のファイルのパス又はパスネームと呼ぶことができる。

ファイル階層を実装するファイルシステム２０５の幾つかの実施形態では、所与のファイルのアイデンティティが、ファイルのパス並びにファイル名に各ディレクトリをリストすることによって指定される。上記で与えられた例を参照すると、ファイル名「ｆｉｌｅ１．ｔｘｔ」の所与のインスタンスのアイデンティティを、「／ｔｅｓｔ１／ｕｓｅｒｓ／ｓｍｉｔｈ／ｆｉｌｅ１．ｔｘｔ」のように指定することができる。ファイルシステム２０５の幾つかの実施形態において、ファイル名だけでは所与のファイルを一意的に識別するのは不十分な可能性があり、パス情報を含む完全指定のファイル・アイデンティティは、所与のファイルを一意的に識別するのに十分とすることができる点に留意されたい。例えば、上述のファイルと同じファイル名を共用するにも関わらず、そのパスによって明確に区別できる、「／ｔｅｓｔ２／ｕｓｅｒｓ／ｓｍｉｔｈ／ｆｉｌｅ１．ｔｘｔ」として識別されるファイルが存在することができる。パスとファイル名情報を使用して所与のファイル・アイデンティティを表す別の方法が可能であり企図される点に留意されたい。例えば、種々の文字を用いてディレクトリ／フォルダ名とファイル名を区切ることができ、或いはディレクトリ／フォルダ名とファイル名を異なる順序で指定してもよい。

ファイルシステム２０５によって管理されるファイルは、総称してファイルデータと呼ぶことができるアプリケーションデータ又はプログラム情報を、幾つかの符号化フォーマットのいずれかで記憶する。例えば、所与のファイルは、ＡＳＣＩＩ符号化フォーマットのプレーンテキスト、又は特定のワードプロセッサ又は表計算符号化フォーマットなどのプロプラエタリアプリケーションフォーマットのデータを記憶する。更に、所与のファイルは、二進フォーマットでビデオ又はオーディオデータ或いは実行可能なプログラム命令を記憶する。データと符号化フォーマットの他の多くのタイプや、データと符号化フォーマットの組合せが、ファイルデータとしてファイルで使用する点が企図される。

ストレージデバイス、該ストレージデバイス上に格納された種々のファイル、上述のようなファイルのファイルデータへのアクセスを管理することに加えて、幾つかの実施形態では、ファイルシステム２０５は、１つ又はそれ以上の所与のファイルに対応する情報を格納するように構成される。該情報は、本明細書ではメタデータと呼ぶことができる。一般的に言えば、メタデータは、ファイルに関連付けられた情報のあらゆるタイプを含む。種々の実施形態では、メタデータは、（限定ではないが）ファイル・アイデンティティ、サイズ、所有権、ファイルアクセス許可などの情報を含む。メタデータはまた、以下に更に詳細に説明されるようにファイルシステムオペレーションに対応するレコードなどの自由形式又はユーザー定義のデータを含む。幾つかの実施形態では、メタデータに含まれる情報は、例えばファイルシステム２０５のベンダー又はインテグレーターによって定義されたメタデータタイプの集まりとしてファイルシステム２０５に事前定義する（すなわちハードコードされる）。他の実施形態では、ファイルシステム２０５は、オペレーション中にメタデータ定義の新しいタイプを生成するように構成される。更に別の実施形態では、ファイルシステム２０５の外部にある１つ又はそれ以上のアプリケーションプロセス１１２は、例えばその目的のために定義されたＡＰＩ１１４のインスタンスを介してファイルシステム２０５によって管理される新しいメタデータを定義する。メタデータを定義するこのような技術の組合せを幾つかの実施形態で利用できる。定義されているがファイルに対応するメタデータや、ファイルのデータコンテンツは、本明細書では総称してファイルシステムコンテンツと呼ぶことができる。

図４は、ファイル及び関連するメタデータを格納するように構成されたファイルシステムの１つの実施形態を示す。図４に示されるファイルシステム２０５の実施形態は、図３の実施形態に示された要素を含むが、簡単にするためにこれらの要素の一部は示していない。図示された実施形態では、ファイルシステム２０５は、フィルタドライバ２２１、任意の数のファイル２５０ａ−ｎ、ディレクトリ２５５、ファイル２５０ａ−ｎの各々に関連付けられたそれぞれの名前付きストリーム２６０ａ−ｎ、ディレクトリ２５５に関連付けられたそれぞれの名前付きのストリーム２６０、イベントログ２７０を含む。ファイル２５０ａ−ｎ又は名前付きストリーム２６０ａ−ｎの１つの汎用インスタンスは、それぞれファイル２５０又は名前付きストリーム２６０と呼ぶことができ、ファイル２５０ａ−ｎ及び名前付きストリーム２６０ａ−ｎは、それぞれ総称してファイル２５０及び名前付きストリーム２６０と呼ぶことができる点に留意されたい。上述のように、ファイル２５０及び名前付きストリーム２６０は、総称してファイルシステムコンテンツと呼ぶことができる。幾つかの実施形態では、ディレクトリ２５５はまた、ファイルシステムコンテンツに含めることもできる。

ファイル２５０は、ファイルシステム２０５によって管理されるファイルを表すことができ、上述のようにデータとプログラム命令の種々のタイプを格納するように種々の実施形態において構成される。ファイルシステム２０５の階層的実施において、１つ又はそれ以上のファイル２５０を、ディレクトリ２５５（フォルダと呼ぶこともできる）に含めることができる。種々の実施形態では、任意の数のディレクトリ２５５を提供することができ、一部のディレクトリ２５５は、他のディレクトリ２５５とファイル２５０を階層的に含むように構成される。図示の実施形態では、ファイル２５０とディレクトリ２５５の各々は、対応する名前付きストリーム２６０を有する。名前付きストリーム２６０の各々は、その対応するファイルに関係するメタデータを格納するように構成される。ファイル２５０、ディレクトリ２５５、名前付きストリーム２６０は、図２のストレージデバイス２３０などの１つ又はそれ以上のストレージデバイス上に物理的に格納される。しかしながら、例証の目的のためにファイル２５０、ディレクトリ２５５、名前付きストリーム２６０は、概念的にファイルシステム２０５内に存在するように示されている。また、幾つかの実施形態では、ディレクトリ２５５はメタデータ生成の観点からファイル２５０に類似のものとする点が企図され、このような実施形態では、以下の説明におけるファイル２５０への言及は、ディレクトリ２５５にも適用できる点を理解されたい。

幾つかの実施形態では、フィルタドライバ２２１は、所与のファイル２５０に格納されたファイルデータにアクセスするよう構成される。例えば、フィルタドライバ２２１は、ファイルシステム２０５によって受け取られた読み取り及び／又は書き込みオペレーションを検出するように構成され、これに応答して、受け取られたオペレーションに対応する所与のファイル２５０からファイルデータを読み取り、又は該所与のファイルに書き込むことができる。幾つかの実施形態では、フィルタドライバ２２１は、所与のファイル２５０に対応するバンド内メタデータを生成し、対応する名前付きストリーム２６０内に生成されたメタデータを格納するように構成される。例えば、所与のファイル２５０に向けられたファイル書き込みオペレーションを検出すると、フィルタドライバ２２１は、所与のファイル２５０の最後の修正時間に対応するメタデータを更新して、名前付きストリーム２６０内にこの更新されたメタデータを格納するように構成される。また、幾つかの実施形態では、フィルタドライバ２２１は、特定のアプリケーションに代わって、指定されたファイルに対応するメタデータを検索するように構成してもよい。

メタデータは、図２のプロセス１１２によって開始される種々のタイプのファイルシステムアクティビティに応答して生成される。幾つかの実施形態では、生成されたメタデータは、任意の複雑さのレコードを含む。例えば、１つの実施形態では、フィルタドライバ２２１は、ファイル作成、削除、リネームなどのファイル操作オペレーション、及び／又は複写オペレーション、さらにファイル読み取り及び書き込みオペレーションの種々のタイプを検出するように構成される。幾つかの実施形態では、このようなオペレーションは、上述のようにバンド内で検出する。特定のファイルオペレーションを検出した後で、フィルタドライバ２２１は、オペレーションのレコードを生成し、オペレーションによってターゲットされたファイル２５０のメタデータとして適切な名前付きストリーム２６０内にそのレコードを格納するように構成される。

更に一般的には、ファイルデータ又はメタデータの読み取り又は書き込みなどのファイルシステムコンテンツのいずれかの態様にアクセスするいずれかのオペレーションは、ファイルシステムコンテンツアクセスイベントと呼ぶことができる。１つの実施形態では、フィルタドライバ２２１は、ファイルシステムコンテンツアクセスイベントの検出に応答してメタデータレコードを生成するように構成される。幾つかの実施形態では、アクセスイベントターゲッティングメタデータ自体が、追加のメタデータを生成する。以下に更に詳細に説明するように、図示された実施形態では、イベントログ２７０は、追加のメタデータがイベント検出に応答して特定の名前付きストリーム２６０内に格納されるかどうかに関係なく、検出されたファイルシステムコンテンツアクセスイベントのレコードを格納するように構成される。

記憶されたメタデータレコードは、種々の実施形態において、例えば、オペレーションを生成するプロセスのアイデンティティ、ファイル・アイデンティティ、ファイルタイプ、ファイルサイズ、ファイル所有者、及び／又はファイル許可などのファイル２５０及び検出されたオペレーションについての種々の情報を含む。１つの実施形態では、レコードは、ファイル２５０のコンテンツを示すファイルシグネチャを含む。ファイルシグネチャは、ファイルコンテンツの全て又は一部のハッシュタイプ関数とすることができ、ファイルコンテンツの僅かな相違が定量的に別個のファイルシグネチャをもたらすプロパティを有する。例えば、ファイルシグネチャは、僅かに単一のビットだけファイルコンテンツが相違する別のファイル用シグネチャを生じることができるメッセージダイジェスト５（ＭＤ５）アルゴリズムを用いることができるが、どのような適切なシグネチャ生成アルゴリズムを用いてもよいことは企図される。レコードはまた、具体的には列挙しない追加の情報を含む。

１つの実施形態では、特定のファイルオペレーションの検出に続いてフィルタドライバ２２１により格納されるメタデータレコードが、関連するデータフィールドの重要度を記述するタグと共にデータフィールドを含むフォーマットで生成し、格納する。このようなフォーマットは、「自己記述的な」データフォーマットと呼ぶことができる。例えば、メタデータレコード内のデータ要素は、一般的構文：
<descriptive_tag>data element</descriptive_tag>
を有するこのようなタグフィールドによって区切ることができる。ここで、「ｄｅｓｃｒｉｐｔｖｉｅ＿ｔａｇ」区切り子は、「ｄａｔａ ｅｌｅｍｅｎｔ」フィールドのある態様を記述することができ、これによりメタデータレコード内の種々のデータ要素を構成する働きをする。種々の実施形態では、自己記述データフォーマットは、タグをデータ要素と区別するための種々の規定を含む種々の構文のいずれかを用いることができる。

自己記述データフォーマットはまた、幾つかの実施形態では拡張可能である。すなわち、データフォーマットは、必要に応じて追加の構造要素を含むように拡張する。例えば、非拡張可能なフォーマットは、表形式の行と列のデータフォーマット又はタグフィールドの数と種類が固定されているフォーマットなどといった、データ要素が従う必要のある固定構造を指定する。逆に、１つの実施形態では、拡張可能な自己記述データフォーマットは、データを区切り且つ構成されるのに使用される任意に定義されたタグフィールドの任意の数を考慮する。別の実施形態では、拡張可能な自己記述データフォーマットは、所与のデータ要素を指定するのに使用される構文の修正を可能にする。幾つかの実施形態では、拡張可能な自己記述データフォーマットは、データが生成又は使用されている間ユーザー又はアプリケーションにより拡張可能である。

１つの実施形態では、拡張可能なマーク付け言語（ＸＭＬ）フォーマット、又はＸＭＬのいずれかのバージョンに準拠したいずれかのデータフォーマットは、メタデータレコードを格納するための拡張可能な自己記述フォーマットとして使用できるが、他の実施形態では、拡張可能或いは自己記述式ではないフォーマットを含むどのような適切なフォーマットを使用してもよいことが企図される。ＸＭＬフォーマットレコードは、記録される所要のメタデータに従ってレコードフィールドの任意の定義を可能にする。ＸＭＬフォーマットレコードの１つの例は以下の通りである。
<record sequence="1">
<path>/test1/foo.pdf</path>
<type>applciation/pdr</type>
<user id=1598>username</user>
<group id=119>groupname</group>
<perm>rw-r--r--</perm>
<md5>d41d8cd98f00b204e9800998ecf8427e</md5>
<size>0</size>
</record>
このようなレコードは、例えばファイル作成オペレーションに続いて、ファイル・アイデンティティ「／ｔｅｓｔ１／ｆｏｏ．ｐｄｆ」を有するファイル（例えばファイル２５０ａ）に関連した名前付きストリーム（例えば名前付きストリーム２６０ａ）に付加する。この場合、「ｒｅｃｏｒｄ ｓｅｑｕｅｎｃｅ」フィールドに関連した数字は、このレコードがファイル２５０ａに関連した第１レコードであることを示す。「ｐａｔｈ」フィールドは、ファイル・アイデンティティを含み、「ｔｙｐｅ」フィールドは、１つの実施形態ではファイル作成オペレーションを出すプロセスによって提供することができ、他の実施形態では、例えばファイル名の拡張又はファイル内のヘッダ情報から判定するファイルタイプを示す。「ｕｓｅｒ ｉｄ」フィールドは、ファイル作成オペレーションを出すプロセスに関連したユーザーの数字のユーザーＩＤと文字のユーザー名の両方を記録し、「ｇｒｏｕｐ ｉｄ」フィールドは、そのユーザーの数字のグループＩＤと文字のグループ名の両方を記録する。「ｐｅｒｍ」フィールドは、ファイルシステム２０５及び／又はオペレーティングシステムに固有のフォーマットでファイル２５０ａに関連するファイル許可を記録する。「ｍｄ５」フィールドは、ファイルコンテンツに対応するＭＤ５シグネチャを記録し、「ｓｉｚｅ」フィールドは、バイト単位のファイル２５０ａの長さを記録する。他の実施形態では、フィルタドライバ２２１は、レコードが、いくつかのフィールドと、種々の定義とコンテンツを有するフィールドとを含む場合の検出されたオペレーションに対応するレコードを格納する点が企図される。幾つかの実施形態では、フィルタドライバ２２１は、ファイルへの読み取りオペレーションがベースとなるファイルデータフォーマットに関係なくＸＭＬデータを返すことができるように、ＸＭＬフォーマット内の所与のファイル２５０から読み取られたデータを包含できる。同様に、幾つかの実施形態では、フィルタドライバ２２１は、所与のファイル２５０に書き込まれるＸＭＬフォーマットデータを受け取るように構成される。このような実施形態では、フィルタドライバ２２１は、ファイルデータを所与のファイル２５０に書き込む前にＸＭＬフォーマッティングを取り除くように構成される。

幾つかの実施形態では、メタデータは、名前付きストリームではない構造内に格納される点に留意されたい。例えば、１つの実施形態では、１つ又はそれ以上のファイルに対応するメタデータは、データベースフォーマット又は別のフォーマットの別のファイルに格納される。また、幾つかの実施形態では、ファイルシステム２０５の他のソフトウェアモジュール又は構成要素は、メタデータの生成、格納、及び／又は検索を行うように構成されることも企図される。例えば、フィルタドライバ２２１のメタデータ関数は、別のソフトウェアモジュールに組み込むか、該モジュールにより複製する。

図示された実施形態では、ファイルシステム２０５はイベントログ２７０を含む。イベントログ２７０は、名前付きストリーム２６０に類似した名前付きストリームとするが、特定のファイルに関連するのではなく、ファイルシステム２０５に直接関連付けることができる。幾つかの実施形態では、ファイルシステム２０５は、１つだけのイベントログ２７０を含むことができ、他の実施形態では、１つより多いイベントログ２７０を設けることができる。例えば、図２に示されたような複数のローカルファイルシステム２４０を含むファイルシステム２０５の１つの実施形態では、１つのローカルファイルシステム２４０につき１つの履歴ストリームを設けることができる。

幾つかの実施形態では、フィルタドライバ２２１は、ファイルシステムオペレーション又はイベントの検出に応答して、イベントログ２７０にメタデータレコードを格納するように構成される。例えば、特定のファイル２５０に向けられた読み取り又は書き込みオペレーションを検出することができ、続いてフィルタドライバ２２１は、イベントログ２７０にオペレーションを示すレコードを格納する。幾つかの実施形態では、フィルタドライバ２２１は、対応するメタデータレコードも同様に名前付きストリーム２６０内に格納されたかどうかに関わらず、イベントログ２７０内にメタデータレコードを格納するように構成される。幾つかの実施形態では、イベントログ２７０は、全ての検出されたオペレーションと、ファイルシステム２０５内で起こっているイベントの集中履歴として機能する。

名前付きストリーム２６０内に格納されたレコードと同様に、イベントログ２７０にフィルタドライバ２２１によって格納されたレコードは、１つの実施形態では、拡張可能なマーク付け言語（ＸＭＬ）フォーマットのような拡張可能な自己記述データフォーマットで生成するが、他の実施形態において、いずれかの適切なフォーマットを使用できることも企図される。一例として、「／ｔｅｓｔ１／ｆｏｏ．ｐｄｆ」という名前の付いた所与のファイル２５０ａを作成して修正し、次いでファイルシステム２０５のオペレーションの途中でファイル２５０ｂ「／ｔｅｓｔ１／ｄｅｓｔｉｎａｔｉｏｎ．ｐｄｆ」にリネームする。１つの実施形態では、イベントログ２７０は、リネームオペレーションに続く以下の例のレコードを含む。
<recrod>
<op>create</op>
<path>/test1/foo.pdf</path>
</record>
<record>
<op>modify</op>
<path>test1/foo.pdf</path>
</record>
<recrod>
<op>rename</op>
<path>/test1/destination.pdf<path>
<oldpath>/test1/foo.pdf<oldpath>
</record>
この例では、各レコードの「ｏｐ」フィールドは、実行されたオペレーションを示し、「ｐａｔｈ」フィールドは、そこで実行されたファイル２５０ａのファイル・アイデンティティを示す。ファイルリネームオペレーションの場合、「ｐａｔｈ」フィールドは、リネームオペレーションの宛先ファイル２５０ｂのファイル・アイデンティティを示し、「ｏｌｄｐａｔｈ」フィールドは、ソースファイル２５０ａのファイル・アイデンティティを示す。他の実施形態では、フィルタドライバ２２１は、いくつかのフィールドや種々の宛先とコンテンツを有するフィールドを含むレコードをイベントログ２７０内に格納する。

メタデータ生成の上記の説明は、図５に示されるフローチャートに更に全体的に示されている。図１から図５をまとめて参照すると、ファイルデータ又はメタデータのようなファイルシステムコンテンツが格納されるオペレーションがブロック５００で始まる。１つの実施形態では、ファイルシステムコンテンツは、ファイルデータとメタデータの両方を含む。ファイルシステムコンテンツの格納に続いて、ファイルシステムコンテンツアクセスイベントが検出される（ブロック５０２）。１つの実施形態では、ファイルシステムコンテンツアクセスイベントは、例えば上述のようなフィルタドライバ２２１によってバンド内で検出する。幾つかの実施形態では、ファイルシステムコンテンツの最初の格納は、それ自体が検出可能なファイルシステムコンテンツアクセスイベントである。例えば、ファイル作成オペレーションは、ステップ５０２で検出可能なファイルシステムコンテンツアクセスイベントとする。

ファイルシステムコンテンツアクセスイベントの検出に応答して、メタデータレコードが生成される（ブロック５０４）。例えば、ファイル・アイデンティティ、ファイル所有権、アクセスイベントを生成するプロセスのアイデンティティなどといった、所与のファイルにアクセスするためのオペレーションに関係する種々のメタデータ要素を集めることができる。

メタデータレコードの生成に続いて、メタデータレコードは、拡張可能な自己記述データフォーマットで格納される（ブロック５０６）。１つの実施形態では、データフォーマットは、あるバージョンのＸＭＬフォーマットに準拠する。種々の実施形態では、メタデータレコードは、名前付きストリーム２６０の１つなどの所与のファイルに関連した名前付きストリーム内に、或いはイベントログ２７０のようなイベントログ内に格納する。

コンテンツ処理システム
説明されたように、幾つかの実施形態では、ストレージシステムは、種々の検出されたファイルシステムオペレーション又はイベントに応答して、バンド内メタデータを生成するように構成される。このようなオペレーション又はイベントは、場合によっては種々のアプリケーションプロセスの実行の結果として発生する。例えば、所与のアプリケーションにより、対応するメタデータレコードを生成する種々の方法（開始、終了、読み取り、書き込み、複写、リネーム、又はファイルアクティビティの他のいずれかのタイプのような）のいずれかでファイルを操作できるようになる。このような実施形態では、結果として生じたメタデータレコードは、所与のアプリケーション又はプロセスによって生成されたファイルシステムアクティビティのシステマティック追跡を可能にし、このような追跡は、特異性の任意の程度まで実行することができ、そのアプリケーションに対しトランスペアレントとする。

場合によっては、多数のアプリケーションが複合ヘテロジニアスデータ処理システムの一部としてストレージシステム１５０と相互作用する。例えば企業は、在庫と生産を管理するためのデータベースアプリケーション、請求と受領を追跡するための会計アプリケーション、四半期報告書を作成するための財務アプリケーション、人員の詳細を識別するための人事アプリケーションを使用する。追加又は種々のアプリケーションを種々の実施形態で設けることができる。

これらのアプリケーションの幾つかは、同じアプリケーションのバージョンとすることができ（例えば、会計と財務は、共通又は関係するアプリケーションを使用する）、或いは密結合アプリケーションとすることができ、すなわち直接通信し協調する共通ＡＰＩを共用することなどによって、互いの存在及びデータにほぼ気付くことができる。例えば、請求書を処理するときに、会計アプリケーションは、予算を更新するよう財務アプリケーションに直接通知する。他のアプリケーションは、種々のベンダーによって提供することができ、疎結合だけであってもよく、すなわち他のアプリケーションは共通データフォーマットを共用するが、直接互いのオペレーションと通信して協調することが制限された機能を有する。例えば、財務アプリケーションは、ユーザーの介入に応答して、人事アプリケーションによって生成された給与と諸手当情報をインポート可能とするが、このようなある介入なしには当該情報を直接要求し、受け取ることはできない。最後に、場合によっては、幾つかのアプリケーションは、データの共用又は直接相互作用することができない、完全に互換性のないものとする。

幾つかの複合企業オペレーションは、１つだけではないが、幾つかのアプリケーションを伴うことができ、その全ては必ずしも互いに密結合である訳ではない可能性がある。トランザクションと呼ぶことができるこのようなオペレーションは、特定の順序或いは特定のイベントに応答して、１つ又はそれ以上のアプリケーションによって引き受けられる一連のオペレーションを含む。トランザクションを含む一連のオペレーションはまた、トランザクションによって実施されるプロセス又は手続きと呼ぶことができ、利用可能な種々のアプリケーションの能力に従って任意に定義する。

トランザクションのステータスは、単一構成アプリケーションのアクティビティからは明らかにならず、逆にトランザクションは、トランザクションを定義するプロセスに関する情報と共に得られた全ての関連アプリケーションのアクティビティの機能である。例えば、所与の企業で定義された手続きに応じて、購入注文の処理は、幾つかのステップを含む。最初に、専用のアプリケーション又は電子メールインターフェースなどを介して購入注文を入力する。入力すると、依頼者のアイデンティティと権限が、人事アプリケーションを使用して依頼者が適切なシグネチャ権限を有する従業員であることを検証するなどによって確認される。続いて、財務アプリケーションを使用することを含む財務承認を取得し、要求が注文を要求する個人又は組織の予算内であることを検証する。これらの種々のステップの結果と企業ポリシーの複雑さに応じて、管理承認のような付加的な検証を得ることができる。全ての要件が満たされると、注文をベンダーに送信することができ、購入注文トランザクションプロセスが終了する。

複合トランザクションをサポートして機能するアプリケーションのいずれかは、ファイルシステムコンテンツが操作されるときにストレージシステム１５０内のアクティビティを生成する。アクティビティに対応するファイルデータ及び／又はメタデータレコードを含むファイルシステムコンテンツは、上述のようなアクティビティに応答して作成する。しかしながら、上述のように、場合によってはその定義されたプロセスを通じた所与のトランザクションの進行は、そのアクティビティに対応するファイルシステムコンテンツに反映されるような所与のアプリケーションのアクティビティからは明らかにならないことがある。例えば、人事アプリケーションは、個人データを反映できるが、予算データは反映できない。従って、人事アプリケーションに問合せることにより、所与の個人が特定の購入のための適切なシグネチャ権限を有することを検証することになり、その問合せの結果をファイルシステムコンテンツに示すことができる。しかしながら、人事アプリケーションは、購入のための十分な予算が存在するかどうかを判断することはできない。実際、場合によっては人事アプリケーションのような何らかのアプリケーションは、一般的に、そのオペレーションの広範なトランザクションコンテンツには気付かない可能性がある。すなわち、アプリケーションは、所与の問合せが、複数のアプリケーションに及ぶ可能性のある所与のトランザクションのプロセスの一部であるかどうか識別することができない場合がある。

他のアプリケーションと直接相互作用可能な所与のトランザクションに場合によっては加わることのできる各アプリケーションを構成することは、困難であるか又は実際的でない可能性がある。例えば、１つ又はそれ以上のアプリケーションの機能が外部メーカーによって固定されている場合、このような構成を実行することができない場合がある。図２に示された実施形態では、ストレージシステム１５０は、コンテンツ処理システム３００を含み、該コンテンツ処理システム３００は種々の実施形態において、ストレージ管理システム２００によって格納されるファイルシステムコンテンツを監視し、このような監視に基づいて追加のメタデータを生成し、更にこのような監視に応答してアプリケーションを呼び出すように構成される。幾つかの実施形態では、コンテンツ処理システム３００は、その構成アプリケーションに気付くことのできない複合トランザクションを協調又は監視するように構成される。

コンテンツ処理システム３００の１つの実施形態が図６に示されている。図示の実施形態では、コンテンツ処理システム３００は、図４に示されたファイルシステム２０５の実施形態と共に示されている。コンテンツ処理システム３００は、単にコンテンツプロセッサ３３０と呼ぶこともできる、複数のコンテンツタイプ特定プロセッサ３３０ａ−ｃと相互作用するように構成されたコンテンツ処理デーモン３２０を含む。コンテンツ処理デーモン３２０は、ファイルシステム２０５のファイル２５０、名前付きストリーム２６０、イベントログ２７０と相互作用するように構成されている。更に、コンテンツ処理デーモン３２０は、このような問合せシステムを含むストレージシステム１５０の実施形態では、問合せシステム４００のような問合せシステムと相互作用するように構成される。

図示された実施形態では、コンテンツ処理デーモン３２０は、フィルタドライバ２２１によってバンド内で検出され記録されたオペレーションとイベントのバンド外検出を実行するように構成される。例えば、コンテンツ処理デーモン３２０は、場合によってはイベントログ２７０をスキャンし、最後のスキャン以降にファイルシステムコンテンツアクセスイベントが発生したことを求めることができる。検出されたイベントに応答して、コンテンツ処理デーモン３２０は、以下に更に詳細に説明されるように追加のファイルシステムコンテンツを生成する。幾つかの実施形態では、コンテンツ処理デーモン３２０は、ファイル２５０及び／又は名前付きストリーム２６０を直接スキャンでき、他の実施形態ではコンテンツ処理デーモン３２０は、イベントログ２７０を使用して、記録されたイベントに対応するこれらのファイル２５０及び名前付きストリーム２６０にアクセス可能であることが企図される。更に、幾つかの実施形態では、コンテンツ処理システム３００は、イベントログ２７０を使用するのではなく、フィルタドライバ２２１による通知に応答して更新されたイベントの固有のログを含む。

コンテンツ処理デーモン３２０は、１つ又はそれ以上のコンテンツプロセッサ３３０の代わりに、ファイルシステム２０５と相互作用してファイルデータとメタデータを含むファイルシステムコンテンツを生成し又は修正する。１つの実施形態では、コンテンツプロセッサ３３０は、特定のトランザクションの定義されたプロセスを監視するように構成された手続きコード又は論理を含む。例えば、所与のコンテンツプロセッサ３３０は、特定のトランザクションの一部として定められた一連のオペレーションを記述するアルゴリズム又は状態機械を実装する。コンテンツプロセッサ３３０は、トランザクションの途中でアクセスできる特定のファイル２５０のようなトランザクションに関係するファイルシステムコンテンツの情報を識別することを含む。更に、コンテンツプロセッサ３３０は、種々のオペレーションに対応する特定のアプリケーションを識別するための情報を含む。例えば、所与のトランザクションが会計アプリケーションによって実行されるステップを含む場合、対応するコンテンツプロセッサ３３０は、そのファイルが会計アプリケーションによってアクセスされるときに所与のファイル２５０のフィルタドライバ２２１によって生成されたメタデータレコードに含む、アプリケーション名又は識別コードのような情報を識別する特定のアプリケーションを含む。

幾つかの実施形態では、所与のコンテンツプロセッサ３３０は、特定のトランザクションの全てのインスタンスを処理するように構成される。例えば、上述の購入注文トランザクションを監視するように構成されたコンテンツプロセッサ３３０は、所与の時間に進行中である全ての購入注文トランザクションを処理するように構成される。このような実施形態では、所与のコンテンツプロセッサ３３０はデータ構造を含み、これによって個々のトランザクションは、タイムスタンプ又は固有識別子などによってプロセッサ内で識別する。他の実施形態では、各コンテンツプロセッサ３３０は、所与のトランザクションの単一のインスタンスに対応する。例えば、新しいトランザクションが検出された場合、コンテンツプロセッサ３３０の新しいインスタンスは、既存のインスタンス（テンプレートなどのような）から又はコンテンツ処理デーモン３２０から生成する。幾つかの実施形態では、コンテンツプロセッサ３３０とコンテンツ処理デーモン３２０は、単一のソフトウェアモジュールのような単一の処理エンティティとして実施する。

所与のコンテンツプロセッサ３３０のオペレーションは、コンテンツ処理デーモン３２０を介して受け取られたファイルシステムコンテンツアクセスイベント情報と共に実現されるアルゴリズムによって決定できる。１つの実施形態ではコンテンツプロセッサ３３０は、最初に、特定のファイルシステムコンテンツアクセスイベントによって起動されるまで非アクティブ又はアイドル状態にする。例えば、特定の電子メールアカウントに購入注文をメールで送ることによって購入注文が開始されるシステムでは、フィルタドライバ２２１は、受け取られた購入注文のコンテンツを特定の電子メールアカウントに関連したファイルに付加することに応答して、イベントログ２７０内にメタデータレコードを作成する。続いて、コンテンツ処理デーモン３２０は、レコードを検出し、これに応答して起動する購入注文コンテンツプロセッサ３３０にレコードの指示を伝達する。他の実施形態では、コンテンツプロセッサ３３０の個々のインスタンスは、適切な起動イベントの検出に応答してコンテンツプロセッサデーモン３２０によって生成する。

１つの実施形態では、コンテンツプロセッサ３３０は、イベントの所与のシーケンスが発生した時点、又はファイルシステムコンテンツの所与の状態が生じた時点を検出するよう機能する受動モニタである。例えば、コンテンツプロセッサ３３０は、プロセス中に引き受けられたアプリケーションアクティビティに応答してフィルタドライバ２２１によって生成されたメタデータレコードを調べることによって、承認プロセスのステップなどの一連のイベントが適切な順序で実行されたかどうかを検出するように構成される。別の事例では、コンテンツプロセッサ３３０は、特定の構文又はスキーマに従ってファイルシステムコンテンツが適格に形成されているかどうかを判断するように構成される。例えば、コンテンツプロセッサ３３０は、構文的に正しく適切に構成されている（すなわち、所要のデータが存在する）かどうかなどを判定するために更新に続いてメタデータレコード又はファイルデータを調べることができる。

別の実施形態では、コンテンツプロセッサ３３０は、ファイルシステムコンテンツをアクティブに修正し、及び／又はコンテンツの種々のイベント又は状態の検出に応答して他のアプリケーションを呼び出すように構成される。例えば、文書出版環境では、所与の文書は、幾つかの種々のフォーマット（例えば、ポータブルドキュメントフォーマット（ＰＤＦ）、ＨＴＭＬフォーマット、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄフォーマット）でユーザーが使用できる。このような実施形態では、コンテンツプロセッサ３３０は、所与の文書の必要なバージョンの生成を自動化するように構成される。例えば、コンテンツプロセッサ３３０は、名前付きストリーム２６０及び／又はイベントログ２７０で当該ファイルへの更新のメタデータレコードを検出することによって、所与のファイル２５０での文書のマスターバージョンが更新された時点を検出するように構成される。更新を検出すると、コンテンツプロセッサ３３０は、更新されたマスターバージョンを所要のフォーマットの各々に変換するために適切なジェネレータ又はトランスレータアプリケーションを呼び出すことができる。このような変換は、マスター文書を更新するユーザー又はアプリケーションにトランスペアレントに行うことができる。

別の例として、コンテンツプロセッサ３３０は、上述の購入承認プロセスのような複合トランザクションをアクティブに実行するように構成される。このような場合、コンテンツプロセッサ３３０は、トランザクションに対応する手続きで指定されるように種々のアプリケーションを呼び出すよう構成される。例えば、コンテンツプロセッサ３３０は、新しい購入注文要求が上述のように電子メールを介して受け取られたことを検出するように構成される。次いで、コンテンツプロセッサ３３０は、要求データを格納するファイル２５０にアクセスすることによって、依頼者のアイデンティティと要求のドル額などといった、要求からの情報を抽出する。抽出された情報を使用して、コンテンツプロセッサ３３０は、上述のように承認を得るために種々のアプリケーションと相互作用する。例えば、コンテンツプロセッサ３３０は、人事アプリケーション内のシグネチャ権限、財務アプリケーション内の予算状態などを検証するために問合せを生成する。ユーザー介入が必要な場合には、コンテンツプロセッサ３３０は、例えば電子メールを介して応答のためにユーザーに伝達されるプロンプトを生成するように構成される。

種々の実施形態では、コンテンツプロセッサ３３０は、種々の形式の出力を生成するように構成される。１つの実施形態では、コンテンツプロセッサ３３０は、その処理に応答してバンド外メタデータレコードを生成する。例えば、所与のファイル２５０で構造化データのスキーマ妥当性検証を実行するように構成されたコンテンツプロセッサ３３０は、対応する名前付きストリーム２６０内のチェックのステータスを示すメタデータレコードを生成する。他の実施形態では、コンテンツプロセッサ３３０は、メタデータの代わりに、或いはこれに加えてファイルデータを生成するか、修正するように構成される。例えば、前述のスキーマ検証ソフトは、不正な形式のレコードを切り捨てるか、又は欠落しているデータフィールドを埋めることなどによって、構造化データを検証しながら検出された幾つかの欠陥を訂正するように構成される。別の例として、コンテントプロセッサ３３０は、以下に更に詳細に説明されるように、問合せエンジンと相互作用して、問合せエンジンによってインデックスされたデータの参照一貫性を維持するように構成される。更に他の実施形態では、コンテンツプロセッサ３３０は、アプリケーション又はユーザーと相互作用するように構成される。例えば、上述のようにコンテンツプロセッサ３３０は、文書コンテンツ更新などの特定のイベントの検出に応答して、アプリケーションのＡＰＩを呼び出すように構成される。１つの実施形態では、１つ又はそれ以上のコンテンツプロセッサ３３０は、ＸＭＬフォーマットのいずれかのバージョンに準拠したフォーマットを含む上述のような拡張可能な自己記述データフォーマットでメタデータレコードを生成するように構成されることが企図される。

コンテンツ処理システム３００及びその種々の構成要素は、上述のようにアプリケーションレイヤ１００内のプロセス１１２であるアプリケーションと相互作用することができ、コンテンツ処理システム３００やその種々の構成要素は、アプリケーションとは異なることに留意されたい。一般に、特定のアプリケーションは、他のアプリケーションのアクティビティに気付くことはできず、ファイルシステム２０５のオペレーションの途中で生成されたメタデータにアクセスすることはできない。しかしながら、図示された実施形態では、コンテンツ処理システム３００は、このようなメタデータへアクセスすることができ、このようなアクセスによって、特定のアプリケーションのオペレーションにより十分には提示されないトランザクションイベントを検出するように構成される。

コンテンツ処理システム３００を含むストレージシステム１５０のオペレーションの方法の１つの実施形態を図７に示す。図１から図４、図６、図７をまとめて参照すると、オペレーションはブロック７００で始まり、ここでファイルデータ又はメタデータのようなファイルシステムコンテンツが格納される。１つの実施形態では、ファイルシステムコンテンツは、ファイルデータとメタデータの両方を含む。ファイルシステムコンテンツの格納に続いて、ファイルシステムコンテンツアクセスイベントがバンド内で検出される（ブロック７０２）。例えば、ファイルシステムコンテンツアクセスイベントは、上述のようにフィルタドライバ２２１によってバンド内で検出される。上述のように、幾つかの実施形態ではファイルシステムコンテンツの最初の格納は、それ自体を検出可能なファイルシステムコンテンツアクセスイベントである。例えば、ファイル作成オペレーションは、ステップ７０２で検出可能なファイルシステムコンテンツアクセスイベントである。

ファイルシステムコンテンツアクセスイベントの検出に応答して、イベントレコードが生成される（ブロック７０４）。例えば、１つの実施形態ではフィルタドライバ２２１は、イベントのタイプやそれによってアクセスされるファイルシステムコンテンツのようなファイルシステムコンテンツアクセスイベントについての情報を含むイベントレコードを生成するように構成される。１つの実施形態では、このようなレコードは、イベントログ２７０に格納される。幾つかの実施形態では、ファイルシステムコンテンツアクセスイベントについての追加情報を含むメタデータレコードも生成する。例えば、１つの実施形態では、フィルタドライバ２２１は、ファイル・アイデンティティ、ファイル所有権、アクセスイベントを生成するプロセスのアイデンティティなどといった所与のファイルにアクセスするためのオペレーションに関係する種々のメタデータ要素を集めるように構成される。１つの実施形態では、イベント検出に応答して生成されたイベントレコード及び／又はいずれかの追加のメタデータレコードは、上述のようにＸＭＬフォーマットのような拡張可能な自己記述データフォーマットで格納する。

イベントレコードが生成された後、該イベントレコードはバンド外で検出する（ブロック７０６）。例えば、１つの実施形態では、コンテンツ処理デーモン３２０又はコンテンツプロセッサ３３０は、イベントログ２７０をスキャンして、イベントレコードを検出するように構成される。幾つかの実施形態では、イベントレコードの検出は、幾つかのアプリケーションを含むトランザクションの検出を含む。例えば、特定のコンテンツプロセッサ３３０は、所与のイベントレコードが幾つかのアプリケーションの一部でのアクティビティを伴ったトランザクションにおける特定のタイプの最初のステップ又は連続するステップを示すことを検出する。

バンド外イベントレコード検出に応答して、追加のファイルシステムコンテンツが生成される（ブロック７０８）。１つの実施形態では、生成される追加のファイルシステムコンテンツは、１つ又はそれ以上のファイル２５０に格納されたファイルデータ、或いは１つ若しくはそれ以上の名前付きストリーム２６０に格納されたメタデータレコード、又は両方を含む。１つの実施形態では、アプリケーションは、バンド外イベントレコード検出に応答して追加して呼び出すことができる。例えば、所与のコンテンツプロセッサ３３０は、上述されたようにトランザクションを処理する途中でアプリケーションを呼び出すことができる。

（ファイルシステムコンテンツの問合せ）
上述されたように、幾つかの実施形態では、ファイルシステム２０５は、種々のタイプのファイルシステムコンテンツを格納するように構成される。ファイルシステム２０５は、１つ又はそれ以上のファイル内に多数のタイプのファイルデータを格納することができ、所与のファイルに対応する任意の複雑性のメタデータを格納する。ファイルシステム２０５は、ファイルシステムコンテンツを消費するように構成される。例えば、ファイルシステム２０５は、特定の記憶ポリシーを実施することができ、これによってそれらのメタデータで示されたような幾つかの使用特性を有するファイルは、特定のタイプのストレージに割り当てられる。１つの実施形態では、例えば、ごく最近に使用されたファイル又は幾つかのタイプのプロセスによってアクセスされたファイルを、より高速のストレージタイプに割り当てることができ、他のファイルは低速のストレージに割り当てることができる。

幾つかの実施形態では、ファイルシステム２０５の外部にあるアプリケーション又はオペレーティングシステムプロセス（図２のプロセス１１２のような）は、ファイルシステムコンテンツを消費するように構成される。例えば、アプリケーションソフトウェアモジュールを書くプログラマーは、アプリケーションデータを格納又は検索するために特定のファイルとこれらに関連するファイルデータを作成し操作することを望む場合がある。更に、このようなプログラマーは、最後のバックアップの時間以降に修正されたファイルだけを選択するようにバックアッププログラムを構成するなど、幾つかのファイルのメタデータ特性に左右される動作を実行することを望む場合がある。幾つかの実施形態では、フィルシステムコンテンツを問合せて特定の基準を満たすコンテンツを識別することによって、特定のファイルシステムコンテンツを指定する。ファイルシステムコンテンツを問合せるための利用可能な基準は、ファイルシステムコンテンツが格納されるフォーマットに依存する。例えば、１つの実施形態では、ファイルシステムコンテンツは、データ項目の記述が自己記述フォーマットタグからではなく、行及び列の定義から継承される表形式データ構造などの固定の非拡張可能フォーマットで格納する。このような実施形態では、ファイルシステムコンテンツを選択できる基準は、利用可能な行及び列の定義などのフォーマットの定義された構造によって決定付けることができる。ファイルシステムコンテンツが上述のようなＸＭＬフォーマットなどの拡張可能な自己記述フォーマットで格納される実施形態において、所要のファイルシステムコンテンツを選択するために利用可能な基準は、当該コンテンツの自己記述機能のいずれかを含む。

図２に示されたストレージシステム１５０の実施形態では、問合せシステム４００は、種々のプロセス１１２にＡＰＩ１１４Ｃを介してファイルシステムコンテンツ問合せ機能を提供するように構成されている。問合せシステム４００の１つの詳細な実施形態を図８に示す。この実施形態では、問合せシステム４００は、接続マネージャー４２０、問合せエンジン４３０、インデックス／コミットエンジン４４０、データレイアウトマネージャー４５０を含み、各々について以下に更に詳細に説明する。

一般的に言えば、問合せは、例えば自己記述フォーマットで格納されたレコードの１つ又はそれ以上のデータフィールドの評価を通じて、データのサブセットがデータのより大きなセットから選択される方法を指定する。例えば、ユーザーは、更に分析するためｆｉｌｅ／ｔｅｓｕｔ１／ｆｏｏ．ｐｄｆに対応する全ての格納されたレコードを選択するよう要望する。これに応じて、ユーザーは、データフィールドが「／ｔｅｓｔ１／ｆｏｏ．ｐｄｆ」などの特定の値に等しいデータフィールドタグ付き「ｐａｔｈ」を有する全てのレコードの選択を指定する問合せを構成する。幾つかの実施形態では、ファイル２５０内に格納されたファイルデータ並びに名前付きストリーム２６０内に格納されたメタデータを含む、ファイルシステムコンテンツの全体は、例えばフィルタドライバ２２１によってバンド内で作成されたか、又は例えば特定のコンテンツプロセッサ３３０によってバンド外で生成されたかどうか、或いは、メタデータが例えば上述のようにＡＰＩ１１４を介したアプリケーションプロセス１１２によってファイルシステム２０５の外部で定義及び／又は生成されたかどうかを問合せることができる。更に、ファイルシステムコンテンツアクセスイベントが上述のようにイベントログ２７０内に記録される幾つかの実施形態では、これらの記録されたイベントも問合せることができる。

問合せは問合せ言語で構成され、該問合せ言語は、１つ又はそれ以上のタグ付きデータフィールドの値に基づいてデータのセットの選択のための構文構成を提供する。幾つかの実施形態では、所与の問合せ言語は、例えばセット選択機能に加えて関数などの手続き関数をサポートする。更に、幾つかの実施形態では、所与の問合せ言語は、例えばＪａｖａ（登録商標）又はＣのような他のプログラミング言語でコード化された手続きルーチンの問合せ内への埋め込みをサポートする。ＸＭＬフォーマットがファイルシステムコンテンツを構成するのに使用される場合、所与のアプリケーションは、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって指定されるようなＸＭＬ問合せ（ＸＱｕｅｒｙ）言語、又はいずれかの機能ＸＱｕｅｒｙ基準又はその変形で特定のファイルシステムコンテンツを選択するための問合せを構成する。しかしながら、どのような適切な問合せ言語を用いてもよい。

上述のように、図示された実施形態では、プロセス１１２は、問合せを生成してこれをＡＰＩ１１４を介して問合せシステム４００に伝える。幾つかの実施形態では、問合せシステム４００は、所与の時間に未処理の並行問合せを有する幾つかのプロセス１１２をサポートするように構成される。更に、幾つかの実施形態では、問合せプロセス１１２は、ネットワークを介してリモートコンピュータシステムからその問合せを実行依頼する。更に、問合せプロセス１１２は、例えば問合せシステム４００へのアクセスを制限するために、幾つかの実施形態では認証されることが必要な場合がある。１つの実施形態では、接続マネージャー４２０は、問合せプロセス１１２と問合せシステム４００との間に接続を設定し維持するオーバーヘッドを管理するように構成される。例えば、接続マネージャー４２０は、認証インターフェース（ユーザー名及びパスワードインターフェースなど）を提供するように構成され、これにより問合せプロセス１１２は、問合せを実行するためにこれらの権限を設定する。更に、１つの実施形態では、接続マネージャー４２０は、問合せプロセス１１２のための接続ベース又はセッションベースの意味論をサポートするのに必要なあらゆる情報を保持するように構成される。例えば、接続マネージャー４２０は、問合せ結果が正しい問合せプロセス１１２に向けられるように、進行中の問合せをこれらに関係する依頼者にマップするようにデータ構造を維持する。幾つかの実施形態では、接続マネージャー４２０は、例えば全体的な問合せスループットを向上させるために問合せエンジン４３０の複数のインスタンスの中から要求を区別することによって問合せ要求のロードバランシングを行うように構成される。

１つの実施形態では、問合せエンジン４３０は、接続マネージャー４２０を介して問合せシステム４００に提示された問合せを構文解析して評価するように構成される。例えば、問合せエンジン４３０は、時間のある範囲内で特定のユーザーによって修正された全ファイル２５０の名前を要求する問合せを受け取ることができる。問合せエンジン４３０は、構文上の正当性について問合せを構文解析することができ、問合せが不正な形式である場合にはエラー状態を戻す。幾つかの実施形態では、問合せエンジン４３０はまた、例えば問合せを複数の問合せに分解し、及び／又は性能上で問合せを最適化するために、問合せに構造変換を行う。次に、問合せエンジン４３０は、特定の基準を満たし、これらのファイルの名前を問合せプロセス１１２に戻すファイル２５０を識別するために名前付きストリーム２６０に格納されたメタデータレコードを調べる。問合せの構文解析と評価のために構成された問合せエンジン４３０の多数の実装が可能である。

幾つかの実施形態では、問合せエンジン４３０は、ストレージ管理システム２００と直接相互作用し、問合せの評価に応答してファイルシステムコンテンツにアクセスする。しかしながら、場合によっては、問合せ評価性能は、ファイルシステムコンテンツの１つ又はそれ以上のインデックスを作成して、これらのインデックスを用いて問合せ評価を助けることにより改善する。図示された実施形態では、インデックス／コミットエンジン４４０は、これらのインデックスを生成して保持し、更に問合せの評価中に問合せエンジン４３０にインデックス情報を提供するように構成される。

一般的に言うと、インデックスは、ある態様又は属性に従ってデータの集まりを編成するあらゆるデータ構造とすることができ、インデックスされた態様又は属性によってデータの問合せを容易にする。例えば、１つの実施形態では、インデックスは、アルファベット順に編成されたファイルシステム２０５で定義された全ファイル２５０の名前のリストである。幾つかの実施形態では、ファイルシステムコンテンツの複数のインデックスを用いることができる。例えば、名前、関連するユーザー、コンテンツ作成／修正時間によって、ファイルシステムコンテンツを頻繁に問合せる場合、これらの属性の各々によってファイルシステムコンテンツをソート又は編成する個々のインデックスを作成してもよい。幾つかの実施形態では、複数のコンテンツ属性を複合状態スペースに組み合わせるインデックスを含む、更に複合されたインデックス方式を用いることができる。更に、インデックスは、リスト、テーブル、ツリー、高位データ構造を含むあらゆる適切なデータ構造を用いて実装可能である。

インデックス／コミットエンジン４００によって作成されたインデックスは、これ自体をファイルシステム２０５内に格納する。幾つかの実施形態では、これらのインデックスは、他のファイルシステムコンテンツとは別個に格納する。このような実施形態では、データレイアウトマネージャー４５０は、ファイルシステム２０５内のインデックスの位置を追跡するように構成される。１つの実施形態では、データレイアウトマネージャー４５０は、インデックスアクセスに対応するバンド内メタデータが生成されないように、インデックスに関連したストレージにアクセスしながらフィルタドライバ２２１をバイパスするように構成される。このような実施形態では、インデクシングやメタデータを含む幾つかの不整合性のケースが回避される。例えば、インデックス／コミットエンジン４４０が所与のインデックス内に修正タイムスタンプのような所与のインデックスのメタデータを含み、次いで該所与のインデックスをフィルタドライバ２２１を介してストレージに書き込むことを試みる場合には、書き込みに続く所与のインデックスのメタデータは、例えばフィルタドライバ２２１が書き込みオペレーションに応答して新しい修正タイムスタンプを作成した場合、所与のインデックスのコンテンツにはもはや一致することはない。

幾つかの実施形態では、問合せシステム４００を介してファイルシステムコンテンツを修正するために、問合せプロセス１１２が問合せを使用する。例えば、問合せを用いて、利用可能なファイルシステムコンテンツの中からファイル２５０のようなデータ項目のセットを選択する。次いで、選択されたデータ項目が修正される、しかし、ストレージデバイス２３０に伝播されるファイルシステム２０５に直接修正する代わりに、問合せシステム４００がデータ更新を協調して行い、これによってファイルシステムコンテンツ修正のための代替経路を提示する。しかしながら、ファイルシステムコンテンツを修正するための複数の経路が存在する実施形態では、これらの経路の間での協調が、共通データへの競合する修正を防ぐために必要である。１つの実施形態では、インデックス／コミットエンジン４４０は、ファイルシステムコンテンツへの更新が確実に一致するようにコミットプロトコル（例えば２相コミットなど）を実施するように構成される。

インデックス／コミットエンジン４４０によって維持されるインデックスは一般に、ファイルシステムコンテンツの派生物であるが、その結果、ファイルシステムコンテンツが変化する（問合せシステム４００を介した更新により、コンテンツプロセッサ３００のアクティビティにより、或いはファイルシステム２０５と直接相互作用しているプロセス１１２によるいずれか）場合、修正されたコンテンツに対応する１つ又はそれ以上のインデックスが、もはやコンテンツの新しい状態を正確には反映しないようになる可能性がある。例えば、インデックス／コミットエンジン４４０が、ファイル名毎にファイルシステムコンテンツのインデックスを含み、所与のファイル２０５がプロセス１１２によってリネームされる場合、ファイル名ベースのインデックスは、リネーム後では古いものになる可能性がある。一般的に言うと、インデックスが、インデックスデータの状態に関して通用している場合、該インデックスは、インデックスデータに関する参照一貫性が保存されていると言われる。

インデックスされたファイルシステムコンテンツが変化する場合、インデックス／コミットエンジン４４０は、この変化を反映させるために関連のインデックスを更新することによって、そのインデックスの参照一貫性を保存するように構成される。１つの実施形態では、インデックス／コミットエンジン４４０は、コンテンツ処理システム３００内のコンテンツ処理デーモン３２０又は特定のコンテンツプロセッサ３３０と協調し、ファイルシステムコンテンツの変化を検出して、これに応答してインデックスを更新するように構成される。例えば、１つの実施形態では、コンテンツ処理デーモン３２０は、イベントログ２７０をスキャンするなどによって、ファイルシステムコンテンツに対して何らかの変更が起こったことを検出するように構成される。コンテンツでの変更をもたらす可能性のあるファイルシステムコンテンツアクセスイベント（例えば、ファイルシステムコンテンツの作成、修正、又は削除を生じるイベント）の検出に応答して、コンテンツ処理デーモン３２０は、検出されたイベントをインデックス／コミットエンジン４４０に通知するよう構成される。これに応答して、インデックス／コミットエンジン４４０は、検出されたイベントによって影響を受ける１つ又はそれ以上のインデックスを更新して、これらの参照一貫性を維持する。例えば、特定のファイル２５０が削除された場合、コンテンツ処理デーモン３２０は、イベントログ２７０内でその削除に対応するイベントレコードを検出し、そのイベントと削除されたファイル２５０をインデックス／コミットエンジン４４０に通知する。次いで、インデックス／コミットエンジン４４０は、削除されたファイル２５０への参照の除去を維持するためにインデックスを修正する。

別の実施形態では、１つ又はそれ以上の特定のコンテンツプロセッサ３３０は、インデックス／コミットエンジン４４０によって維持される特定のインデックスに対応するファイルシステムコンテンツを監視するように構成される。例えば、１つの実施形態では、インデックス／コミットエンジン４４０は、インデックスに関連する自己記述データフィールド（例えば、ファイル名、ファイルサイズ、ファイルシグネチャなど）やこれらの現在値などの特定のインデックスの構造とコンテンツを所与のコンテンツプロセッサ３３０に通知する。次いで、コンテンツプロセッサ３３０は、特定のインデックスの構造とコンテンツに関係するイベントのためのファイルシステムコンテンツアクセスイベントを監視するように構成され、インデックス／コミットエンジン４４０にこれらの関係するイベントだけを通知する。このような通知を受けると、インデックス／コミットエンジン４４０は、例えばインデックスからの情報を追加又は除去することによって、その参照一貫性を保存するために関連するインデックスを更新する。

問合せシステム４００を含むストレージシステム１５０のオペレーションの方法の１つの実施形態を図９に示している。図１から図４、図８、図９をまとめて参照すると、オペレーションはブロック９００で始まり、ここで、ファイルデータ又はメタデータのようなファイルシステムコンテンツが格納される。１つの実施形態では、ファイルシステムコンテンツは、ファイルデータとメタデータの両方を含む。幾つかの実施形態では、問合せシステム４００は、上述のようにファイルシステムコンテンツの１つ又はそれ以上のインデックスを生成する（ブロック９０２）ように構成されるが、他の実施形態ではこのステップを省くことができる。

ファイルシステムコンテンツの格納に続いて、ファイルシステムコンテンツアクセスイベントがバンド内で検出される（ブロック９０４）。例えば、ファイルシステムコンテンツアクセスイベントは、上述のようにフィルタドライバ２２１によってバンド内で検出される。上記のように、幾つかの実施形態では、ファイルシステムコンテンツの最初の格納は、これ自体を検出可能なファイルシステムコンテンツアクセスイベントである。例えば、ファイル作成オペレーションは、ステップ９０２で検出可能なファイルシステムコンテンツアクセスイベントである。

ファイルシステムコンテンツアクセスイベントの検出に応答して、メタデータレコードが生成される（ブロック９０６）。例えば、１つの実施形態では、フィルタドライバ２２１は、タイムスタンプ、ファイルシグネチャ、イベントを生成するプロセスのアイデンティティなどといった、アクセスされるイベント又はファイルシステムコンテンツに関係する情報を含むメタデータレコードを生成するように構成される。１つの実施形態では、このようなレコードは、特定の名前付きストリーム２６０内に格納する。更に、幾つかの実施形態では、イベントレコードは、イベント検出に応答して生成する。このようなイベントレコードは、例えばイベントログ２７０に格納する。１つの実施形態では、イベント検出に応答して生成されたメタデータレコード及び／又はイベントレコードは、上述のようにＸＭＬフォーマットのような拡張可能な自己記述データフォーマットで格納する。

ファイルシステムコンテンツがインデックスされる実施形態では、ファイルシステムコンテンツアクセスイベントの通知を受け取ることができ（ブロック９０８）、関係するインデックスの参照一貫性をファイルシステムコンテンツアクセスイベントに対して維持する（ブロック９１０）。例えば、コンテンツ処理デーモン３２０は、全ファイルシステムコンテンツアクセスイベントをインデックス／コミットエンジン４４０に通知するように構成され、或いは、特定のコンテンツプロセッサ３３０は、上述のようにインデックス／コミットエンジン４４０によって維持されるインデックスに関係するこれらのイベントを監視するように構成される。関係するイベントの通知の受領に応答して、インデックス／コミットエンジン４４０は、関係するインデックスを更新して、上述のようにその参照一貫性を維持するように構成される。これらのステップは、インデクシングを用いない実施形態では省略可能である。

メタデータレコードの生成に続いて、ファイルシステムコンテンツを問い合わせる（ブロック９１２）。例えば、問合せシステム４００は、ファイルデータ及び／又はメタデータを問合せることによって、プロセス１１２により実行依頼される問合せに応答するように構成される。ファイルシステムコンテンツがＸＭＬフォーマットで格納される実施形態では、問合せは、ＸＭＬ問合せ（ＸＱｕｅｒｙフォーマット）で生成する。

上記でかなり詳細に実施形態を説明してきたが、上記開示を完全に理解すると当業者であれば多くの変形及び修正が明らかになるであろう。添付の請求項は、全てのこのような変形及び修正を含むよう解釈されるものとする。

ストレージシステムの１つの実施形態を示すブロック図である。 ソフトウェアベースのストレージシステムアーキテクチャとストレージデバイスへのインターフェースの１つの実施形態を示すブロック図である。 ストレージ管理システムの１つの実施形態を示すブロック図である。 ファイル及び関連するメタデータを格納するように構成されたファイルシステムの１つの実施形態を示すブロック図である。 メタデータ生成の方法の１つの実施形態を示すフロー図である。 コンテンツ処理システムの１つの実施形態を示すブロック図である。 コンテンツ処理システムを含むストレージシステムのオペレーションの方法の１つの実施形態を示すフロー図である。 問合せシステムの１つの実施形態を示すブロック図である。 問合せシステムを含むストレージシステムのオペレーションの方法の１つの実施形態を示すフロー図である。

符号の説明

２０５ ファイルシステム、２２１ フィルタドライバ、２５０ ファイル、２６０ 名前付きストリーム、２７０ イベントログ、２５５ ファイル

Claims (42)

1. データを格納するためのストレージ空間を提供するように構成されたストレージデバイスと、そして
   前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するように、そして前記ストレージデバイスへのアクセスを管理するように、構成されたファイルシステムと
   を含むシステムであって、
   前記ファイルシステムが、
   ファイルシステムコンテンツアクセスイベントを検出し、前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するように更に構成され、
   前記ファイルシステムは拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを生成するように更に構成され、
   前記メタデータレコード内に含まれる個々のデータエレメントは１つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記１つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示する
   ことを特徴とするシステム。
2. 前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項１に記載のシステム。
3. 前記拡張可能な自己記述データフォーマットは、あるバージョンの拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項１に記載のシステム。
4. 前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項１に記載のシステム。
5. 前記メタデータレコードは、前記ファイルシステムに対応するイベントログに格納されることを特徴とする請求項１に記載のシステム。
6. 前記ファイルシステムコンテンツは、前記複数のファイルの１つ又はそれ以上に格納された１つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項１に記載のシステム。
7. コンテンツプロセッサとアプリケーションを更に含み、前記コンテンツプロセッサは、前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答して、前記アプリケーションを呼び出すように構成され、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生することを特徴とする請求項１に記載のシステム。
8. 問合せエンジンを更に含み、これによってアプリケーションが前記ファイルシステムコンテンツを問い合わせることを特徴とする請求項１に記載のシステム。
9. ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、
   前記ファイルシステムがファイルシステムコンテンツアクセスイベントを検出するステップと、
   前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するステップと、そして
   前記ファイルシステムが拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを記憶するステップであって、前記メタデータレコード内に含まれる個々のデータエレメントは１つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記１つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示するステップと
   を含む方法。
10. 前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項９に記載の方法。
11. 前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項９に記載の方法。
12. 前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項９に記載の方法。
13. 前記メタデータレコードは、イベントログに格納されることを特徴とする請求項９に記載の方法。
14. 前記ファイルシステムコンテンツは、複数のファイルの１つ又はそれ以上に格納された１つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項９に記載の方法。
15. 前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答してアプリケーションを呼び出すステップであって、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生する、ステップを更に含むことを特徴とする請求項９に記載の方法。
16. 前記ファイルシステムコンテンツを問い合わせる段階を更に含むことを特徴とする請求項９に記載の方法。
17. プログラム命令を記録したコンピュータアクセス可能な記録媒体であって、前記プログラム命令は、
    ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、
    前記ファイルシステムがファイルシステムコンテンツアクセスイベントを検出するステップと、
    前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するステップと、そして
    前記ファイルシステムが拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを記憶するステップであって、前記メタデータレコード内に含まれる個々のデータエレメントは１つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記１つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示するステップと
    を含む方法をコンピュータに実行させることを特徴とするコンピュータアクセス可能な記録媒体。
18. 前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
19. 前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
20. 前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
21. 前記メタデータレコードは、イベントログに格納されることを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
22. 前記ファイルシステムコンテンツは、複数のファイルの１つ又はそれ以上に格納された１つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
23. 前記プログラム命令は前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答してアプリケーションを呼び出すように更に実行可能であり、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生する、請求項１７に記載のコンピュータアクセス可能な記録媒体。
24. 前記プログラム命令は、前記ファイルシステムコンテンツを問い合わせるために更に実行可能であることを特徴とする請求項１７に記載のコンピュータアクセス可能な記録媒体。
25. データを記憶するためのストレージ空間を提供するように構成されたストレージデバイスと、そして
    前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するように、そして前記ストレージデバイスへのアクセスを管理し、ファイルシステムコンテンツを格納し、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントのバンド内検出を実行し、更にこれに応答して前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、そして前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを記憶するように構成されたファイルシステムと、そして
    前記イベントレコードのバンド外検出を実行し、これに応答して追加のファイルシステムコンテンツを生成するように構成された前記アプリケーションとは異なるコンテンツプロセッサと
    を含むシステムであって、
    前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期し、
    前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生し、
    前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして
    前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの２つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するように更に構成されている、
    ことを特徴とするシステム。
26. 前記トランザクションを実行するために、前記コンテンツプロセッサは、前記イベントレコードの少なくとも１つのバンド外検出の実行に応答して前記アプリケーションの少なくとも１つを呼び出すように更に構成され、前記バンド外検出は前記イベントレコードが生成されてしまった後で発生することを特徴とする請求項２５に記載のシステム。
27. 前記コンテンツプロセッサは、前記ファイルシステムコンテンツアクセスイベントを問合せシステムに通知するように更に構成され、これに応答して前記問合せシステムは、前記ファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項２５に記載のシステム。
28. １つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項２５に記載のシステム。
29. 前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項２５に記載のシステム。
30. 前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項２９に記載のシステム。
31. ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、
    前記ファイルシステムが、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントのバンド内検出を実行するステップであって、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期しているステップと、
    前記バンド内検出に応答して、前記ファイルシステムが前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを記憶するステップと、
    前記アプリケーションとは異なるコンテンツプロセッサが前記イベントレコードのバンド外検出を実行するステップであって、前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして前記コンテンツプロセッサによる前記バンド外検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生するステップと、そして
    前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの２つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するステップと
    を含む方法。
32. 前記コンテンツプロセッサが前記イベントレコードの少なくとも１つのバンド外検出の実行に応答して前記アプリケーションの少なくとも１つを呼び出すステップを更に含むことを特徴とする請求項３１に記載の方法。
33. 前記コンテンツプロセッサが前記ファイルシステムコンテンツアクセスイベントの所与の１つを問合せシステムに通知するステップを更に含み、これに応答して前記問合せシステムは、前記所与のファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項３１に記載の方法。
34. １つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項３１に記載の方法。
35. 前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項３１に記載の方法。
36. 前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項３５に記載の方法。
37. プログラム命令を記録したコンピュータアクセス可能な記録媒体であって、前記プログラム命令は、
    ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、
    前記ファイルシステムが、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントをバンド内での検出を実行するステップであって、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期しているステップと、
    前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、かつ前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを格納するステップと、そして
    前記アプリケーションとは異なるコンテンツプロセッサが前記イベントレコードのバンド外検出を実行するステップであって、前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして前記コンテンツプロセッサによる前記バンド外検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生するステップと、そして
    前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの２つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するステップと
    を含む方法をコンピュータに実行させることを特徴するコンピュータアクセス可能な記録媒体。
38. 前記プログラム命令は、前記イベントレコードのバンド外検出の実行に応答して前記アプリケーションの少なくとも１つを呼び出すステップを前記コンテンツプロセッサに実行させることが更に可能であることを特徴とする請求項３７に記載のコンピュータアクセス可能な記録媒体。
39. 前記プログラム命令は、所与の１つのファイルシステムコンテンツアクセスイベントを問合せシステムに通知するステップを前記コンテンツプロセッサに実行させることが更に可能であり、これに応答して前記問合せシステムは、前記所与のファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項３７に記載のコンピュータアクセス可能な記録媒体。
40. １つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項３７に記載のコンピュータアクセス可能な記録媒体。
41. 前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項３７に記載のコンピュータアクセス可能な記録媒体。
42. 前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語（ＸＭＬ）フォーマットに準拠することを特徴とする請求項４１に記載のコンピュータアクセス可能な記録媒体。

Images