JP2007527074A - ファイルシステム内での効率的なファイルコンテンツをサーチするためのシステム及び方法 - Google Patents

Abstract

ファイルシステム内での効率的なファイルコンテンツをサーチするためのシステム及び方法。１つの実施形態において、本システムは、データを記憶するように構成されたストレージデバイスと、ストレージデバイスへのアクセスを管理するように構成されたファイルシステムを含む。ファイルシステムは、サーチオペレーションを検出しストレージデバイスに記憶された第１ファイル内の所与のデータパターンの存在を判定し、第１ファイルに関連した第１レコードに所与のデータパターンの指標とサーチオペレーションの結果データの指標を記憶するように構成される。
【選択図】図２

Description

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

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

従来の多くのファイルベースコンピュータシステムでは、関心対象のデータをストレージシステムの異種論理と物理エリアに位置付けられた多数のファイルにわたり分散させている。様々なコンピューティングプラットフォームは、テキストストリングスなどの特定のデータパターンをどのファイルが含むかをユーザーが決定することができるサーチアプリケーションの種々のタイプを提供する場合が多い。例えば、コード開発者は、このようなサーチアプリケーションを使用して、大きく複雑なコードベース内のどのファイルが特定の修正ストリングを含むのかを識別し、これらのファイルをオペレーション用に選択することができるようにする。

しかしながら、典型的なサーチアプリケーションは、ほとんどの場合所与のデータパターンがともかく所与のファイル内に存在する場合に総ファイルコンテンツのごく一部を含むとしても、所与のデータパターンが当該ファイル内に発生するかどうかを判定するためにファイルの全コンテンツを読取ることを必要とする。更に、多くの典型的なサーチアプリケーションには履歴がなく、その結果、所与のファイル内の所与のデータパターンのサーチが繰り返される場合には、サーチの途中でファイルの全コンテンツを再調査する場合がある。このような冗長ファイルアクセスは、ファイルコンテンツサーチを頻繁に実行するシステムの性能を大幅に低下させる恐れがある。

ファイルシステム内における効率的なファイルコンテンツサーチのためのシステム及び方法の種々の実施態様が開示される。１つの実施態様において、本システムは、データを記憶するように構成されたストレージデバイスと、ストレージデバイスへのアクセスを管理するように構成されたファイルシステムを含む。ファイルシステムは、サーチオペレーションを検出し、ストレージデバイスに記憶された第１ファイル内の所与のデータパターンの存在を判定し、所与のデータパターンの指標とサーチオペレーションの結果データの指標とを第１ファイルに関連する第１レコードに記憶するように構成する。

本システムの１つの特定の実装において、サーチオペレーションの検出に続いて、ファイルシステムは、第１レコードをスキャンし所与のデータパターンの指標が第１レコードに記憶されているかどうかを判定し、指標が第１レコードに記憶されている判定に応じて第１ファイルの部分だけにアクセスするように更に構成することができる。

本システムの別の特定の実装においては、所与のデータパターンが第１ファイルに存在しない場合、ファイルシステムは、第１レコードに所与のデータパターンの指標を記憶するように更に構成することができる。他方、所与のデータパターンが第１ファイルに存在する場合、ファイルシステムは、第２レコードに所与のデータパターンの指標とパターンロケーション情報を記憶するように更に構成することができる。

１つの実施態様において、複数のファイルを記憶するステップと、サーチオペレーションを検出し第１ファイル内の所与のデータパターンの存在を判定するステップと、所与のデータパターンの指標とサーチオペレーションの結果データの指標とを第１ファイルに関連する第１レコードに記憶するステップとを含むことができる方法も企図される。

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

ストレージシステムとファイルシステムの概要
ここで図１を参照すると、ストレージシステムの１つの実施形態のブロック図が示されている。図示の実施形態において、ストレージシステム１０は、システム相互接続４０を介して複数のストレージデバイス３０ａ、３０ｂに結合された複数のホストデバイス２０ａ、２０ｂを含む。更に、ホストデバイス２０ｂは、図示の実施形態においてシステムメモリ２５を含む。参照を簡単にするために、参照番号とその後に続く文字により本明細書で示される要素は、参照番号単独で総称して参照することができる。例えば、ホストデバイス２０ａ、２０ｂとストレージデバイス３０ａ、３０ｂは、総称してホストデバイス２０やストレージデバイス３０として参照することができる。

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

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

更に別の実施形態において、ストレージシステム１０を、混成型ストレージシステムとして構成することができ、ここでは幾つかのストレージデバイス３０が幾つかのホストデバイス２０と同じコンピュータシステム内に統合され、他のストレージデバイス３０がネットワーク間で他のホストデバイス２０に結合される独立型デバイスとして構成される。このような混成型ストレージシステムでは、システム相互接続４０は、上述の周辺バスとネットワーク相互接続のような多種多様な相互接続メカニズムを含むことができる。

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

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

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

所与のホストデバイス２０上での実行中、オペレーティングシステム又は所与のアプリケーションのいずれかは、所与のストレージデバイス３０からロードされ、或いは該デバイスに記憶されたデータに対してリクエストを生成する。例えば、オペレーティングシステムの一部又はアプリケーション自体に対応するコードは、所与のストレージデバイス３０上に記憶させることができ、そのため、求められるオペレーションシステムルーチン又はアプリケーションプログラムの呼出しに応じて、対応するコードを実行するために検索することができる。同様に、オペレーティングシステム又はアプリケーションの実行は、記憶されることになるデータを生成する。

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

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

図２は、ストレージデバイスに対するオペレーティングシステムアーキテクチャとそのインターフェースの１つの実施形態を示す。図示の実施形態において、オペレーティングシステム２００は、ユーザースペース２１０とカーネルスペース２２０とを含む。ユーザースペース２１０は、複数のプロセス２１２Ａ−Ｃを含み、その各々は、所与のユーザーアプリケーションに対応する。幾つかの実施形態において、ユーザースペース２１０内の幾つかのアプリケーションプロセス２１２は、オペレーティングシステム２００とは別個のものでもよい。このようなプロセスは、オペレーティングシステム２００によって提供される環境内で動作するか、或いはオペレーティングシステム２００の「上で」動作すると言える。プロセス２１２の各々は、アプリケーションプログラミング・インターフェース（ＡＰＩ）２１４への呼出しを介してストレージデバイス２３０Ａ−Ｃにアクセスするように構成される。ＡＰＩ２１４は、ファイルシステム２０５へのアクセスに関するプロセス２１２を提供し、カーネルスペース２２０内で機能するように構成される。１つの実施形態において、ストレージデバイス２３０は、図１のストレージデバイス３０の例とすることができる。同様に、１つの実施形態において、オペレーティングシステム２００、その構成要素のいずれか、及び／又はプロセス２１２のいずれかは、例えば図１のシステムメモリ２５のようなコンピュータアクセス可能媒体内に記憶されたプログラム命令とデータとして図１の１つ又はそれ以上のホストデバイス２０上で実行するように構成させることができる。

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

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

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

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

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

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

ファイルサーチオペレーションの最適化
上述のように、ファイルシステム２０５は、ストレージデバイス２３０上に記憶された複数のファイルへのアクセスを管理するように構成されている。幾つかの実施形態において、オペレーティングシステム２００及び／又はプロセス２１２は、１つ又はそれ以上のファイルをサーチし、サーチされたファイルが特定のデータパターンを含むかどうかを判定するように構成される。例えば、Ｕｎｉｘの「ｇｒｅｐ」、「ｅｇｒｅｐ」、又は「ｆｇｒｅｐ」コマンド或いはＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓの「ｆｉｌｅ ｓｅａｒｃｈ」ユーティリティなどのアプリケーションプログラムを呼び出して、特定のテキストストリングスがファイルの１つのセットに存在するかどうかを判定することができる。幾つかの実施形態において、サーチアプリケーションは、例えば正規表現のような任意の複雑性のデータパターンを指定することができる。また幾つかの実施形態では、サーチアプリケーションは、文字パターンやファイルに加えてバイナリデータパターンとファイルを処理するように構成してもよい。

呼び出されると、サーチアプリケーションは、例えばプロセス２１２の１つとして実行され、指定されたファイルのコンテンツを検索するためにファイルシステム２０５に対する読取りオペレーションを生成する。サーチアプリケーションによっては、ワイルドカードの使用、フォルダ又はディレクトリ名の指定、或いは他のいずれかの適切な手段で複数のファイル名をサーチアプリケーションへの引数として規定することにより、サーチオペレーションのターゲットとして複数のファイルを指定することができる。各指定されたファイルからのデータがファイルシステム２０５を介して検索されると、サーチアプリケーションは、いずれかの適切なサーチアルゴリズムを用いて検索データを調べ、指定されたサーチデータパターンを含むかどうかを判定する。サーチアプリケーションの実装によっては、所与のファイルのサーチは、サーチデータパターンの（あるとすれば）第１のマッチ又は指定された数のマッチが検出されると終了し、或いはファイルの最後に達するまで継続し、検出された全てのマッチを報告する。幾つかの実施形態において、サーチアプリケーション機能のこれら又は他の態様を、コマンドライン引数、メニュー、又は類似の手段を介してユーザーが選択することができる。

幾つかの従来の実施形態では、サーチアプリケーションは、同一のサーチ（すなわち同じデータパターン及びターゲットファイルセットを指定すること）が既に実行されている場合でも、各指定ファイルの全体の読取りを行うことがある。このような状況下でファイルに余分にアクセスすることは、場合によってはファイルシステム使用率を増大させ、システム性能全体を低下させる可能性がある。例えばこのような実施形態では、同じファイルでの同じパターンの２つの連続したサーチは各々、全ての対応するファイルデータが二度読取られサーチされることになり、これは、サーチを一回実行することよりもかなり長い処理時間を要する可能性がある。

１つの実施形態において、ファイルシステム２０５は、ファイル上のサーチオペレーションを検出し、このようなサーチオペレーションによって指定されたデータパターンやサーチ結果データを、サーチされたファイルに対応するレコードに記憶するように構成される。図３は、ファイルシステムの１つのこのような実施形態を示す。図３に示されたファイルシステム２０５の実施形態は、図２の実施形態に示された要素を含むことができるが、理解し易いようにこれらの要素の一部は図示していない。図示の実施形態では、ファイルシステム２０５は、フィルタドライバ２２１、任意の数のファイル３１０ａ−ｎ、ファイル３１０ａ−ｎの各々に関連したそれぞれのメタデータ名前付きストリーム３２０ａ−ｎを含む。ファイルシステム２０５は更に、ファイル３１０ａ−ｎの各々に関連したそれぞれのネガティブサーチ名前付きストリーム３３０ａ−ｎとそれぞれのポジティブサーチ名前付きストリーム３４０ａ−ｎを含む。ファイル３１０ａ−ｎ又は名前付きストリーム３２０ａ−ｎ、３３０ａ−ｎ、又は３４０ａ−ｎの１つの汎用例は、ファイル３１０又は名前付きストリーム３２０、３３０又は３４０とそれぞれ呼ぶことができ、ファイル３１０ａ−ｎと名前付きストリーム３２０ａ−ｎ、３３０ａ−ｎ、又は３４０ａ−ｎを総称して、それぞれファイル３１０及び名前付きストリーム３２０、３３０、又は３４０と呼ぶことができる点に留意されたい。

ファイル３１０は、ファイルシステム２０５によって管理されるファイルを表わす。ファイル３１０の各々は、単にメタデータ３２０と呼ぶことができる対応するメタデータ名前付きストリーム３２０を有する。メタデータ名前付きストリーム３２０の各々は、本明細書ではメタデータと呼ぶ対応するファイルについての情報を記憶するように構成されている。種々の実施形態において、メタデータは、（限定ではないが）ファイルアイデンティティ、サイズ、所有権、ファイルアクセス許可を含み、さらに以下に説明されるように検出されたサーチオペレーションに対応するレコードなどの情報を含む。図示の実施形態では、フィルタドライバ２２１は、ファイル３１０のファイルデータや対応するメタデータストリーム３２０のファイルメタデータの読取り及び書込みを協働するように構成される。

更に図示の実施形態において、ファイル３１０の各々は、単にネガティブストリーム３３０と呼ぶことができる対応するネガティブサーチ名前付きストリーム３３０と、単にポジティブストリーム３４０と呼ぶことができる対応するポジティブサーチ名前付きストリーム３４０とを有する。ネガティブストリーム３３０とポジティブストリーム３４０の各々は、以下に更に詳細に説明するように対応するファイル３１０上で実行されるサーチオペレーションに関する情報を記憶するように構成されている。図示の実施形態では、フィルタドライバ２２１は、ネガティブストリーム３３０とポジティブストリーム３４０のためのこのようなサーチオペレーションレコードの読取り及び書込みを協働するように構成させることができる。

ファイル３１０、メタデータ３２０、ネガティブストリーム３３０、ポジティブストリーム３４０は、図２のストレージデバイス２３０のような１つ又はそれ以上のストレージデバイス上に物理的に記憶させることができる点に留意されたい。しかしながら、例の目的でこれらの要素の各々は、ファイルシステム２０５内に概念的に存在するように示されている。

ファイルオペレーションのレコードの記憶とサーチオペレーションの検出
ファイルシステム２０５の幾つかの実施形態において、フィルタドライバ２２１は、種々のアプリケーションからファイルシステム２０５によって受け取られた所与のファイルに対する読取り又は書込みオペレーションのような種々のオペレーションを検出するように構成される。特定のファイル３１０に向けられたオペレーションの検出後、フィルタドライバ２２１は、ターゲットファイル３１０に対応するメタデータ３２０における検出されたオペレーションのレコードを記憶するように構成される。種々の実施形態において、ファイルオペレーションの検出に続きフィルタドライバ２２１によって記憶されたレコードは、例えばファイルアイデンティティ、ファイルタイプ、オペレーションタイプ、ファイルサイズ、ファイルコンテンツシグニチャ（例えば、ハッシュ又はメッセージダイジェスト５（ＭＤ５）シグニチャなど）、ファイル所有者、及び／又はファイル許可などのターゲットファイル３１０や検出されたオペレーションについての種々の種類の情報を含むことができる。更に、レコードは、アプリケーション名、呼出し引数、プロセスＩＤ、又は他の利用可能な情報などのオペレーションを発生させるプロセス又はアプリケーションについての情報を含むことができる。

１つの特定の実施形態において、ファイルシステム２０５は、サーチオペレーションを検出して所与のデータパターンが１つ又はそれ以上のファイル内に存在しているかどうかを判定するように構成される。例えば、フィルタドライバ２２１は、オペレーションを発生させているアプリケーション名及び／又はアプリケーションの呼び出された引数を調べることによって、特定のファイル読取りオペレーションがサーチアプリケーションによって生成されたことを検出するように構成される。幾つかの実施形態において、フィルタドライバ２２１は、サーチアプリケーション名のリストとして構成され、更にリストされたアプリケーションの１つから受け取られたファイル読取りアプリケーションがサーチオペレーションであると判定することができる。このような実施形態では、フィルタドライバ２２１は、サーチアプリケーション又はその修正によってどのような特定の動作もなくサーチオペレーションを検出することができ、すなわちサーチオペレーションの検出はサーチアプリケーションに対しトランスペアレントとすることができる点に留意されたい。他の実施形態において、フィルタドライバ２２１は、アプリケーションが自らをサーチアプリケーションとして登録できる登録アプリケーションプログラミング・インターフェース（ＡＰＩ）のような機能を提供することができ、従って、フィルタドライバ２２１は名前又は他の識別データによって任意のサーチアプリケーションを識別することができるようになる。更に他の実施形態において、フィルタドライバ２２１は、ファイルオペレーションを呼び出すための関数呼び出しの他のセットを提供することによって、或いはサーチ固有のセマンティクスで標準ファイルオペレーション関数呼び出しをオーバーロードするための１つ又はそれ以上のメカニズムを提供することなどによって、サーチオペレーションに固有のＡＰＩを提供するように構成される。このような実施形態において、所与のサーチアプリケーションは、サーチに関係するファイルオペレーションを実行する際にサーチ固有のＡＰＩを使用してファイルシステム２０５と対話することができ、フィルタドライバ２２１は、サーチオペレーションとしてＡＰＩなどを介して受け取られたオペレーションを検出することができる。サーチオペレーションを検出するようにファイルシステム２０５を構成する他の多数のメカニズムも可能であり企図される。

特定のファイル３１０に向けられたサーチオペレーションが検出されると、フィルタドライバ２２１は、対応するメタデータ名前付きストリーム３２０にサーチオペレーションのレコードを記憶するように構成される。このようなレコードの記憶は、関連のオペレーションの検出の後で何時でも行うことができる。例えば１つの実施形態において、レコードの記憶は、ファイル３１０ａ上のオペレーションが終了するまで遅延させることができ、別の実施形態では、レコードの記憶は、オペレーション終了前に行うことができる。後者のケースでは、オペレーションが終了を保証されない（すなわち不確かである）場合、フィルタドライバ２２１は、オペレーションが終了しない場合にその対応するオペレーションに先立って記憶レコードを削除するためのメカニズムを提供することができる。

１つの実施形態において、サーチオペレーションの検出の後にフィルタドライバ２２１によって記憶レコードを、拡張可能マーク付け言語（ＸＭＬ）フォーマットで作成し記憶することができるが、他の実施形態においてどのような適切なフォーマットを使用してもよいことが企図される。ＸＭＬフォーマットレコードの１つの実施例は、以下の通りである。
<record sequence="3">
<path>/test1/foo.txt</path>
<type>ascii<type>
<group id=119>groupname</group>
<perm>rw-r--r--</perm>
<md5>d41d8cd98f00b204e9800998ecf8427e</md5>
<size>58937</size>
<process>
<name>grep</name>
<args>grep release4 /test1/*.txt<args>
<pid>7168</pid>
<ppid>409</ppid>
<pgrpid>409<pgrpid>
</process>
</record>
このようなレコードは、引数「grep release4/test1/*.txt」によって呼び出されるサーチアプリケーション「grep」に続くファイルアイデンティティ「/test1/foo.pdf」を有するファイル（例えばファイル３１０ａ）と関連付けられたメタデータ名前付きストリーム（例えばメタデータ３２０ａ）に添付することができる。上述のように、１つの実施形態においてフィルタドライバ２２１は、発信プロセス名として「grep」を検出することによってサーチオペレーションとしてこのオペレーションを検出するように構成させることができ、他の実施形態では、このような検出は異なる方法を用いて行うことができる。「grep」サーチアプリケーションのこの特定の呼出しは、テキストパターン「release4」の「/test1」ディレクトリに存在する拡張子「.txt」によって各ファイルをサーチすることができる。１つの実施形態において、ワイルドカード表現「/test1/*.txt」は、ファイルシステム２０５が「/test1/foo.txt」のような特定のファイルに対応するサーチオペレーションを受け取る前に、プリプロセッサ（シェル環境又はコマンドプロセッサなど）によって表現式を満たすファイルの明示リストに拡張することができる。別の実施形態では、ファイルシステム２０５は、ワイルドカード表現式を内部に拡張するように構成される。

この例では、「record sequence」フィールドに関連する数は、このレコードがファイル３１０ａと関連する第３レコードであることを示している。「path」フィールドはファイルアイデンティティを含み、「type」フィールドは、ファイルタイプを示し、１つの実施形態ではファイル作成オペレーションを発するプロセスによって定義することができ、他の実施形態では例えばファイル名の拡張部又はファイル内のヘッダ情報から決定することができる。「user id」フィールドは、ファイル作成オペレーションを発するプロセスに関連するユーザーの数値ユーザーＩＤと文字ユーザー名の両方を記録し、「group id」フィールドは、そのユーザーの数値グループＩＤと文字グループ名の両方を記録する。「perm」フィールドは、ファイルシステム２０５及び／又はオペレーティングシステムに固有のフォーマットでファイル３１０ａに関連するファイル許可を記録する。「md5」フィールドは、ファイルコンテンツに対応するＭＤ５シグニチャを記録し、「size」フィールドは、ファイル３１０ａの長さをバイト単位で記録する。

更に、「process」フィールドは、コンテンツアクセスオペレーションを実行するプロセスについての情報を記録するサブフィールドを含むことができる。「name」サブフィールドは、オペレーションを発信しているプロセス又はアプリケーションの名前を記録し、「args」サブフィールドは、名前付きプロセスが呼び出されたときに与えられる引数を記録する。「pid」、「ppid」、「pgrpid」サブフィールドは、それぞれプロセスＩＤ、プロセスの親のＩＤ、プロセスのグループＩＤを記録する。別の実施形態において、フィルタドライバ２２１は、多少のフィールドを含み、かつ種々の定義とコンテンツを有するフィールドを含む検出されたサーチオペレーションに対応するレコードを記憶することができる。幾つかの実施形態では、フィルタドライバ２２１は、サーチオペレーションを検出し、上記に示されたようにメタデータストリーム３２０内にレコードを生成することなく以下に説明されるようにこれを処理することができることが更に企図される。

ファイルシステム内でのサーチオペレーションの処理
図示の実施形態では、ファイルシステム２０５は、ネガティブストリーム３３０とポジティブストリーム３４０内に記憶された情報を用いて対応するファイル３１０上の検出されたサーチオペレーションの処理を最適化するように構成される。具体的には、ネガティブストリーム３３０は、以下に示されるＸＭＬレコードなどのレコードを記憶するように構成され、該レコードは所与のサーチデータパターンがその対応するファイル３１０内に存在しないことが既知であるかどうかを示す。同様に、ポジティブストリーム３４０は、対応するファイル３１０内に所与のサーチデータパターンが存在することが既知であることを示すレコードとサーチデータパターンが見つけられたファイル３１０内のロケーションを記憶するように構成される。

上述のようなサーチオペレーションの検出に応じて、１つの実施形態においてフィルタドライバ２２１は、サーチオペレーションによって指定されるデータパターンを決定するように構成される。例えば、フィルタドライバ２２１は、サーチオペレーションを発信しているアプリケーションの呼び出された引数を調べ、そのアプリケーションの構文に従ってそれらの引数を構文解析する。上述の例を参照すると、フィルタドライバ２２１は、「grep」オペレーションに対して指定されたデータパターンがテキストストリングス「release4」であることを判定することができる。上述のように、幾つかの実施形態ではデータパターンは、ワイルドカード、正規表現構文、又は他の抽象パターンマッチング構文を含む。

サーチオペレーションによって指定されるデータパターンを決定した後で、１つの実施形態においてフィルタドライバ２２１は、ネガティブストリーム３３０とポジティブストリーム３４０をスキャンし、指定されたデータパターンの指標がいずれかのストリームに記憶されているかどうかを判定するように構成される。幾つかの実施形態において、フィルタドライバ２２１は、指定されたデータパターンをネガティブストリーム３３０とポジティブストリーム３４０のコンテンツに対して厳密にマッチするように構成される。指定されたデータパターンが抽象構文を含む実施形態では、フィルタドライバ２２１は、構文とストリーム３３０、３４０のコンテンツの構文を評価し、指定されたデータパターンの指標がいずれかのストリームに記憶されているかどうかを判定するように構成される。例えば、２つの文字通り別個の正規表現は、評価される際に同じデータパターンを識別することができる。

指定されたデータパターンの指標がいずれかのストリームにも記憶されていない場合、１つの実施形態においてフィルタドライバ２２１は、検出されたサーチオペレーションによってターゲットファイル３１０をサーチし、指定されたデータパターンがそこに存在するかどうかを判定するように構成される。例えば１つの実施形態では、ファイルシステム２０５内のフィルタドライバ２２１又は別のモジュールは、図２のカーネルスペース２２０内で実行できるサーチアルゴリズムを実装する。別の実施形態では、フィルタドライバ２２１は、図２のユーザースペース２１０内で実行できる外部サーチアプリケーションを呼び出すように構成される。幾つかのこのような実施形態では、呼び出される外部サーチアプリケーションは、ファイルシステム２０５が初期化されたとき、或いはＡＰＩを介してなどのプログラマー又はシステム管理者によって要求されたときに選択される。

フィルタドライバ２２１がファイル３１０をサーチした後に指定されたデータパターンのマッチが見つからない場合、１つの実施形態においてフィルタドライバ２２１は、ネガティブストリーム３３０内にデータパターンの指標を記憶するように構成される。１つの実施形態において、フィルタドライバ２２１は、ネガティブストリーム３３０内にＸＭＬレコードとしてデータパターンを記憶することができる。例えば、フィルタドライバ２２１がファイル「foo.txt」をサーチした後に上記で説明された例において言及されたパターン「release4」が見つからない場合、フィルタドライバ２２１は、下記レコードを対応するネガティブストリーム３３０内に記憶することができる。
<pattern>release4</pattern>

同様に、フィルタドライバ２２１がファイル３１０をサーチした後に指定されたデータパターンのマッチが見つかった場合、１つの実施形態においてフィルタドライバ２２１は、ポジティブストリーム３４０内にデータパターンの指標を記憶し、かつファイル３１０内でパターンが見つかった場所に関する情報を記憶するように構成される。１つの実施形態では、フィルタドライバ２２１は、ポジティブストリーム３４０内にＸＭＬレコードとしてデータパターンを記憶することができる。例えば、上記に示す例で言及されたパターン「release4」は、ファイルのライン２０とライン４８５においてファイル「foo.txt」内に存在することができる。更に、ライン２０を、ファイルのブロック２内に位置付けることができ、ライン４８５をファイルのブロック４内に位置付けることができ、ここでブロック寸法と境界は、ファイルシステム２０５によって決定される（例えばファイルシステム２０５は、１０２４バイトブロックを使用してファイルコンテンツを編成し操作することができる）。このような場合、ファイル「foo.txt」でパターン「release4」をサーチした後、フィルタドライバ２２１は、対応するポジティブストリーム３４０内に以下のＸＭＬレコードを記憶することができる。
<occurs>
<pattern>release4</pattern>
<record>
<linenumber>20</linenumber>
<blocknumber>2</blocknumber>
</record>
<record>
<linenumber>485</linenumber>
<blocknumber>4</blocknumber>
</record>
</occurs>

ライン数とブロック数に加えた又はその代わりの何らかの適切なインデックスを用いて、ファイルの対応する部分にインデックスを付けることができる。例えば幾つかの実施形態において、ファイルの最初から測定されたバイトオフセットは、図示されたもののようなレコード内のライン数とブロック数の代わりに用いることができる。また、種々のＸＭＬタグを使用して、他の実施形態ではネガティブストリーム３３０とポジティブストリーム３４０に記憶されたレコードを区切り構造化することができ、或いはＸＭＬ以外の構文を使用してレコードを構造化することができることも企図される。幾つかの実施形態において、サーチオペレーションのターゲットファイル３１０はテキストファイルとしてフォーマットできない（例えばファイル３１０はバイナリファイルとすることができる）ことが更に企図される。幾つかのこのような実施形態では、所与のターゲットファイル３１０がテキストファイルでない場合、ライン数はファイルへのインデックス付けに関係しない可能性があり、これらは、対応するポジティブストリーム３４０内のレコードから省くことができる。

上述のように、１つの実施形態でフィルタドライバ２２１は、サーチオペレーションを受け取り、指定されたサーチデータパターンの指標がいずれかのストリームに記憶されているかどうかを判定した後でネガティブストリーム３３０とポジティブストリーム３４０をスキャンするように構成される。図示された例のレコードのフォーマットを用いる実施形態では、フィルタドライバ２２１は、各ストリームに記録された「パターン」フィールドをスキャンするように構成される。指定されたデータパターンがネガティブストリーム３３０に記憶されたパターンにマッチする場合、フィルタドライバ２２１は、対応するファイル３１０のコンテンツにアクセスすることなくサーチオペレーションを発信しているアプリケーションにネガティブサーチ指標を返すように構成される。例えば、フィルタドライバ２２１は、どのようなファイルデータも必要とすることなく、発信しているアプリケーションにエンドオブファイル指標が送られるようにすることによって、ネガティブサーチ指標を発信アプリケーションに間接的且つトランスペアレントに返すことができ、すなわち、フィルタドライバ２２１により、ファイル３１０が発信アプリケーションに対してヌル長であるように見せることができる。このような場合、発信アプリケーションは、指定されたサーチデータパターンのためのファイルシステム２０５によって返されたヌルファイルデータのサーチを試みることができるが、ヌルパターンがサーチデータパターンに対する有効マッチでない場合、この試みは失敗する可能性が高い。別の実施形態において、フィルタドライバ２２１は、ファイル３１０と同じ長さのデータを返すことによってネガティブサーチ指標を発信アプリケーションに間接的に且つトランスペアレントに返すことができるが、ここで返されたファイルデータは、空白文字（例えば、スペース、タブ）及び／又は改行文字だけを含む。

ファイルシステム２０５が上述のようにサーチ固有のＡＰＩを実装する実施形態では、フィルタドライバ２２１は、例えば、エンドオブファイル指標を返すことによってではなく関数呼び出し又は他の定義されたインターフェースを介してネガティブサーチ結果を発信アプリケーションに直接表示するように構成される。ネガティブサーチ結果が発信サーチアプリケーションに示される特定のメカニズムに関係なく、これらのネガティブサーチ結果は、ターゲットファイル３１０のコンテンツに実際にアクセスすることなく示すことができ、従ってファイルシステム使用率が低減される可能性がある点に留意されたい。

指定されたデータパターンがポジティブストリーム３４０に記憶されたパターンにマッチする場合、フィルタドライバ２２１は、ポジティブストリーム３４０でのマッチングレコードによって示されたファイル３１０の一部分だけにアクセスし、ファイルデータのその部分を発信アプリケーションに返すように構成される。１つの実施形態では、フィルタドライバ２２１は、ポジティブストリーム３４０のマッチングレコードに示されるライン又はブロックまで空白文字（例えば、スペース、タブ）及び／又は改行文字を返し、次いで対応するファイル３１０の表示ブロックを読取り当該ブロックだけのファイルデータを発信アプリケーションに返すことによって、その特定のファイル部分をトランスペアレントに返すように構成される。上記に説明されたようなデータパターンに対応する複数のレコードによって示されるように所与のデータパターンが所与のファイル３１０で複数回マッチする場合、フィルタドライバ２２１は、レコードによって示された次のライン又はブロックに達するまで所与の返されたデータブロックの後に付加的な空白文字及び／又は改行文字が続く。例えば、サーチオペレーションがデータパターン「release4」を指定し、ポジティブストリーム３４０が上記に説明されたような「occurs」レコードを含む場合、フィルタドライバ２２１は、対応するファイル３１０のブロック２と４だけにアクセスして返すように構成させることができ、これらのブロックに適切な数の空白文字及び／又は改行文字を割り込ませる。発信サーチアプリケーションは、指定されたデータパターンに対してファイルシステム２０５によって返された空白／改行埋め込みファイルデータのサーチを試みることができるが、読取られていない部分の代わりに使用される文字が有効なサーチパターンデータでない場合には、ファイルシステム２０５によって実際に返されたターゲットファイル３１０の一部分の当該データパターンにだけマッチする。

ファイルシステム２０５が上述のようにサーチ固有のＡＰＩを実装する実施形態では、フィルタドライバ２２１は、ポジティブサーチ結果を発信アプリケーションに直接示すように構成される。例えば１つのこのような実施形態では、フィルタドライバ２２１は、ファイル３１０の特定の部分と、該特定の部分がファイル３１０内に位置付けられる場所に関する情報を空白文字のストリームに埋め込まれたこうした部分を返すことによってではなく関数呼び出し又は他の定義されたインターフェースを介して返すように構成される。上述のネガティブサーチ結果と同様に、ポジティブサーチ結果が発信サーチオペレーションに示される特定のメカニズムに関係なく、これらのポジティブサーチ結果は、実際にターゲットファイル３１０の一部分だけにアクセスする間は示すことができ、従って場合によってはファイルシステム使用率が低減される点に留意されたい。

所与のファイル３１０のコンテンツが例えばファイル書込みオペレーションによって修正された場合には、対応するネガティブストリーム３３０とポジティブストリーム３４０に記憶データパターンは、もはや修正されたファイルコンテンツを正確には反映することができない。すなわち、データパターンが記憶された時点で記憶データパターンが参照される情報は変更されている可能性があるので、記憶データパターンはもはや、所与のファイル３１０の修正コンテンツに対する参照一貫性を示すことはできない。幾つかの実施形態において、フィルタドライバ２２１は、例えばストリーム３３０、３４０をゼロ長まで切り捨てることによって、対応するファイル３１０への書込みに続いてネガティブストリーム３３０とポジティブストリーム３４０内に記憶レコードをクリアするように構成される。他の実施形態において、フィルタドライバ２２１は、修正コンテンツに対して記憶データパターンを調べ、ファイルコンテンツの修正後の各記憶レコードの有効性を判定するように構成される。例えば、１つのこのような実施形態において、フィルタドライバ２２１は、ネガティブストリーム３３０とポジティブストリーム３４０内に記憶された各データパターンについてファイル３１０をサーチすることができ、これに従ってストリームを更新することができる。更に、幾つかの実施形態において、フィルタドライバ２２１は、ネガティブストリーム３３０とポジティブストリーム３４０からレコードを取り除き、ストリームにより必要とされる記憶容量を低減させることができる。例えば、フィルタドライバ２２１は、ストリームのサイズがスレショルドを越える場合又はある時間期間が経過した後に所与のストリームからより古いレコードを取り除くように構成される。

ネガティブストリーム３３０とポジティブストリーム３４０がサーチされる順序は、種々の実施形態で異なる可能性がある点に留意されたい。１つの実施形態において、サーチオペレーションの検出の後でフィルタドライバ２２１は、ネガティブストリーム３３０の指定されたデータパターンを最初にサーチするように構成される。パターンが見つからなかった場合、フィルタドライバ２２１は次にポジティブストリーム３４０をサーチすることができ、指定されたファイル３１０自体を最後にサーチする。別の実施形態において、フィルタドライバ２２１は、ネガティブストリーム３３０、ポジティブストリーム３４０、ファイル３１０の一部又は全てを同時に或いは異なる順序でサーチするように構成される。更に、サーチ固有のＡＰＩを提供するファイルシステム２０５の幾つかの実施形態において、これらの項目がサーチされる並行処理の順序と程度は、サーチアプリケーションが指定することができる。例えばこのような指定は、所与のデータパターンが所与のファイルにおいて見つかる可能性が高いかどうか、従ってポジティブ又はネガティブストリームにおいて見つかる可能性が高いか、或いは所与のサーチが最近実行されたかどうかが既知であるか、従ってデータパターンがいずれかのストリームに存在する可能性があるか否かを示唆することができる経験則に応じて行うことができる。

幾つかの実施形態においてファイルシステム２０５は、ネガティブストリーム３３０又はポジティブストリーム３４０の一方に対してサポートを実装することができるが、他方に対しては実装できず、或いは、フィルタドライバ２２１以外のモジュールにおいて上述されたネガティブストリーム３３０及び／又はポジティブストリーム３４０の管理を実装することができる点に更に留意されたい。更に、幾つかの実施形態において、ネガティブストリーム３３０及び／又はポジティブストリーム３４０は完全に省略することができ、ネガティブとポジティブサーチ結果に対応するレコードは、メタデータストリーム３２０又は別の名前付きストリーム内に直接記憶することができる。このような実施形態では、レコードは、ポジティブサーチレコードをネガティブサーチレコードと区別するために、上記で説明されたもの以外のＸＭＬフィールドタグで区切ることができる。

最後に、所与のネガティブストリーム３３０又はポジティブストリーム３４０のコンテンツに対し、或いは全体としてファイルシステム２０５のサーチ関係のコンテンツに対して種々のタイプのインデックスを適用することができることが企図される。例えば、１つの実施形態おけるファイルシステム２０５は、記憶レコードの構文を事前に構文解析し、解析されたフォーマット（バイナリフォーマットのような）でレコードデータを記憶するなどによって所与のネガティブストリーム３３０又はポジティブストリーム３４０に記憶されたレコードにインデックスを付けるように構成させることができ、従って、所与のストリームをサーチするのに必要な時間を削減することができる。更に、１つの実施形態でのファイルシステム２０５は、既存のネガティブストリーム３３０とポジティブストリーム３４０にインデックスを付ける付加的な名前付きストリーム又はファイルを作成して保持するように構成される。例えば、ファイルシステム２０５は、所与のサーチデータパターンが発生することが判定された特定のネガティブストリーム３３０のレコードを含むネガティブインデックスストリームと類似のポジティブインデックスストリームを作成するように構成される。ファイルシステム２０５は更に、所与のネガティブストリーム３３０と所与のポジティブストリーム３４０が上述のようにこれらの対応するファイル３１０へのアクセスを低減できる方法に類似した方法で、このようなインデックスストリームを使用してサーチ使用率に応じてネガティブストリーム３３０とポジティブストリーム３４０へのアクセス数を低減するように構成される。

図４は、ファイル上のサーチオペレーションを検出し該サーチオペレーションに対応するレコードを記憶する方法の１つの実施形態を示す。図１から図４をまとめて参照すると、オペレーションはブロック４００で始まり、ここで所与のファイルにおけるデータパターンをサーチするオペレーションが検出される。例えば、１つの実施形態においてフィルタドライバ２２１は、既知のサーチアプリケーションに名前が対応するアプリケーションから発信している所与のファイル３１０上でファイル読取りオペレーションを検出する。他の実施形態では、ファイルシステム２０５はＡＰＩを提供し、これによってサーチアプリケーションはサーチオペレーションをファイルシステム２０５に実行依頼する。

サーチオペレーションが検出されると、１つの実施形態でのネガティブストリーム３３０をサーチして、サーチオペレーションによって指定されたデータパターンの指標が記憶されているか否かを判定する（ブロック４０２、４０４）。指定されたデータパターンの指標がそこに記憶されると、ネガティブ指標は、対応するファイルにアクセスすることなく発信アプリケーションに返される（ブロック４０６）。例えば、フィルタドライバ２２１は、エンドオブファイル指標をこの場合は発信アプリケーションに返すように構成することができ、或いはＡＰＩを介してネガティブサーチ状態を示すことができる。

指定されたデータパターンの指標がネガティブストリーム３３０で検出されない場合には、１つの実施形態においてポジティブストリーム３４０をサーチして、このような指標がレコード内に記憶されているか否かを判定する（ブロック４０８、４１０）。このような指標が見つかった場合、レコードによって示されたファイル３１０のデータブロックだけにアクセスする（ブロック４１２）。これらのデータブロックは、発信アプリケーションに返すことができる（ブロック４１４）。例えば１つの実施形態において、データブロックは、フィルタドライバ２２１によって作成された空白文字の１つのストリームにこれらを埋め込むことによって発信アプリケーションにトランスペアレントな方法で返すことができる。別の実施形態では、データブロックは、ＡＰＩなどを介してファイル内のこれらのロケーションに関する情報と共に発信アプリケーションに直接返すことができる。

ポジティブストリーム３４０で指定されたデータパターンの指標が検出されない場合、対応するファイル３１０をサーチして、データパターンが記憶されているか否かを判定することができ、サーチ結果に応じてネガティブストリーム３３０又はポジティブストリーム３４０内に適切なレコードを記憶する（ブロック４１６）。

本方法の幾つかの実施形態では、ネガティブストリーム３３０、ポジティブストリーム３４０、ファイル３１０は異なる順序で或いは同時にサーチする点に留意されたい。本方法の幾つかの実施形態では、ネガティブストリーム３３０とポジティブストリーム３４０の一方又は他方だけを実装することができ、或いは両方のタイプのレコードを単一の名前付きストリームに組み合わることができる点に更に留意されたい。

図５は、サーチオペレーションに対応する記憶レコードの参照一貫性を維持する方法の１つの実施形態を示す。図１から図３、図５をまとめて参照すると、オペレーションはブロック５００で始まり、ここでファイルサーチオペレーションに対応するレコードが記憶される。例えば、図３、４の説明と共に上述されたように、サーチオペレーションを検出でき、サーチデータパターンを含む対応するレコードをネガティブストリーム３３０又はポジティブストリーム３４０内に記憶する。

ファイルサーチオペレーションのレコードの記憶に続いて、対応するファイルのコンテンツを修正するオペレーションを検出する（ブロック５０２）。例えば、１つの実施形態においてフィルタドライバ２２１は、対応するネガティブストリーム３３０又はポジティブストリーム３４０内に記憶レコードを有するファイルへのファイル書込みオペレーションを検出する。

ファイル上でのコンテンツ修正オペレーションの検出に応じて、当該ファイルに対応する記憶されたサーチレコードをクリアする（ブロック５０４）。例えば、１つの実施形態においてフィルタドライバ２２１は、対応するファイル３１０上でのファイル書込みオペレーションなどのコンテンツ修正オペレーションの検出に応じてネガティブストリーム３３０とポジティブストリーム３４０をゼロ長まで切り捨てるように構成される。他の実施形態では、各記憶されたサーチレコードを、例えばフィルタドライバ２２１によって調べて、コンテンツ修正オペレーションの検出に続いてその参照一貫性を評価することが企図される。このような実施形態では、その一貫性がコンテンツ修正オペレーションによって影響を受けるレコードだけをクリアする。

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

ストレージシステムの１つの実施形態を示すブロック図である。 オペレーティングシステムアーキテクチャ及びストレージデバイスへのインターフェースの１つの実施形態を示すブロック図である。 ファイル上でサーチオペレーションを検出して対応するレコードを記憶するように構成されたファイルシステムの１つの実施形態を示すブロック図である。 ファイル上でサーチオペレーションを検出して対応するレコードを記憶する方法の１つの実施形態を示すフロー図である。 サーチオペレーションに対応する記憶レコードの参照一貫性を維持する方法の１つの実施形態を示すフロー図である。

符号の説明

２００ オペレーティングシステム、２０５ ファイルシステム、２１０ ユーザースペース、２１２Ａ プロセスＡ、２１２Ｂ プロセスＢ、２１２Ｃ プロセスＣ、２１４ ＡＰＩ、２２０ カーネル、２２１ フィルタドライバ、２２２ 仮想ファイルシステム、２２４ デバイスドライバ、２２５ ネットワークプロトコル、２３０Ａ ストレージデバイス、２３０Ｂ ストレージデバイス、２３０Ｃ ストレージデバイス、２４０Ａ ローカルファイルシステム（ＶｘＦＳ）、２４０Ｂ ローカルファイルシステム（ＦＦＳ）、２４０Ｘ ローカルファイルシステム

Claims (22)

1. データを記憶するように構成されたストレージデバイスと、
   前記ストレージデバイスへのアクセスを管理するように構成されたファイルシステムとを備えるシステムであって、前記ファイルシステムが、
   サーチオペレーションを検出して前記ストレージデバイスに記憶された第１ファイル内の所与のデータパターンの存在を判定し、
   前記所与のデータパターンの指標と前記サーチオペレーションの結果データの指標とを前記第１ファイルに関連する第１レコードに記憶する
   ように構成されていることを特徴とするシステム。
2. 前記ファイルシステムが更に、前記サーチオペレーションの検出に続いて前記第１レコードをスキャンし、前記所与のデータパターンの指標が該第１レコードに記憶されているかどうかを判定するように構成されており、前記ファイルシステムが更に、前記指標が記憶されている判定に応じて前記第１ファイルの部分だけにアクセスするように構成されていることを特徴とする請求項１に記載のシステム。
3. 結果データの前記指標は、前記所与のデータパターンが発生している前記第１ファイルの１つ又はそれ以上の部分に対応するインデックスを含み、前記所与のデータパターンの指標が前記第１レコードに記憶されている判定に応じて、前記ファイルシステムが更に、前記インデックスに対応する前記第１ファイルの１つ又はそれ以上の部分だけにアクセスするように構成されていることを特徴とする請求項２に記載のシステム。
4. 前記サーチオペレーションの検出に続いて、前記ファイルシステムが更に、前記第１レコードをスキャンし前記所与のデータパターンの指標が前記第１レコードに記憶されているかどうかを判定し、前記所与のデータパターンの指標が前記第１レコードに記憶されている場合に前記第１ファイルにアクセスすることなくネガティブ指標を返すように構成されていることを特徴とする請求項１に記載のシステム。
5. 前記所与のデータパターンが前記第１ファイルに存在する場合、前記ファイルシステムが更に、前記所与のデータパターンの指標とパターンロケーション情報を前記第１レコードに記憶するように構成されており、前記所与のデータパターンが前記第１ファイルに存在しない場合、前記ファイルシステムが更に、前記所与のデータパターンの指標を第２レコードに記憶するように構成されていることを特徴とする請求項１に記載のシステム。
6. 前記第１レコードと前記第２レコードは、前記第１ファイルに各々対応するそれぞれの名前付きストリームに記憶されることを特徴とする請求項５に記載のシステム。
7. 前記第１ファイルに記憶されたデータを修正するためのオペレーションの検出に応じて、前記ファイルシステムが更に、前記第１ファイルに関連した前記レコードをクリアするように構成されていることを特徴とする請求項１に記載のシステム。
8. 前記ファイルシステムが更に、サーチオペレーションを検出し前記ストレージデバイスに記憶された複数のファイルの１つ又はそれ以上内の所与のデータパターンの存在を判定し、前記所与のデータパターンの指標と前記サーチオペレーションの結果データの指標を前記複数のファイルの１つ又はそれ以上の各々に関連したそれぞれのレコードに記憶するように構成されていることを特徴とする請求項１に記載のシステム。
9. 複数のファイルを記憶するステップと、
   サーチオペレーションを検出して第１ファイル内で所与のデータパターンの存在を判定するステップと、
   前記所与のデータパターンの指標と前記サーチオペレーションの結果データの指標とを前記第１ファイルに関連した第１レコードに記憶するステップと、
   を含む方法。
10. 前記サーチオペレーションの検出に続いて、前記第１レコードをスキャンし、前記所与のデータパターンの指標が第１レコードに記憶されているかどうかを判定するステップと、
    前記指標が前記第１レコードに記憶されている判定に応じて、前記第１ファイルの一部分だけにアクセスするステップと
    を更に含む請求項９に記載の方法。
11. 結果データの指標は、前記所与のデータパターンが発生する前記第１ファイルの１つ又はそれ以上の部分に対応するインデックスを含み、前記方法が更に、前記所与のデータパターンの指標が前記第１レコードに記憶されている判定に応じて、前記インデックスに対応する前記第１ファイルの１つ又はそれ以上の部分だけにアクセスするステップを含む請求項１０に記載の方法。
12. 前記サーチオペレーションの検出に続いて、前記第１レコードをスキャンし前記所与のデータパターンの指標が前記第１レコードに記憶されているかどうかを判定するステップと、
    前記所与のデータパターンの指標が前記第１レコードに記憶されている場合に前記第１ファイルにアクセスすることなくネガティブ指標を返すステップと、
    を更に含む請求項９に記載の方法。
13. 前記所与のデータパターンが前記第１ファイルに存在する場合、前記所与のデータパターンの指標とパターンロケーション情報を前記第１レコードに記憶するステップと、
    前記所与のデータパターンが前記第１ファイルに存在しない場合、前記所与のデータパターンの指標を第２レコードに記憶するステップと、
    を更に含む請求項９に記載の方法。
14. 前記第１レコードと前記第２レコードが、前記第１ファイルに各々が対応するそれぞれの名前付きストリームに記憶される請求項１３に記載の方法。
15. 前記第１ファイルに記憶されたデータを修正するためにオペレーションの検出に応じて前記第１ファイルに関連したレコードをクリアするステップを更に含む請求項９に記載の方法。
16. プログラム命令を含むコンピュータアクセス可能媒体であって、
    前記プログラム命令が、
    複数のファイルを記憶し、
    サーチオペレーションを検出し第１ファイル内で所与のデータパターンの存在を判定し、
    前記所与のデータパターンの指標と前記サーチオペレーションの結果データの指標とを前記第１ファイルに関連した第１レコードに記憶する、
    ようにコンピュータ実行可能であることを特徴とするコンピュータアクセス可能媒体。
17. 前記プログラム命令が更に、
    前記サーチオペレーションの検出に続いて、前記第１レコードをスキャンし前記所与のデータパターンの指標が前記第１レコードに記憶されているかどうかを判定し、
    前記指標が前記第１レコードに記憶されている判定に応じて、前記第１ファイルの部分だけにアクセスする、
    ようにコンピュータ実行可能であることを特徴とする請求項１６に記載のコンピュータアクセス可能媒体。
18. 結果データの前記指標は、前記所与のデータパターンが発生する前記第１ファイルの１つ又はそれ以上の部分に対応するインデックスを含み、前記プログラム命令が更に、前記所与のデータパターンの指標が前記第１レコードに記憶されている判定に応じて前記インデックスに対応する前記第１ファイルの１つ又はそれ以上の部分だけにアクセスするようにコンピュータ実行可能であることを特徴とする請求項１７に記載のコンピュータアクセス可能媒体。
19. 前記プログラム命令は更に、
    前記サーチオペレーションの検出に続いて、前記第１レコードをスキャンし前記所与のデータパターンの前記指標が前記第１レコードに記憶されているかどうかを判定し、
    前記所与のデータパターンの指標が前記第１レコードに記憶されている場合、前記第１ファイルにアクセスすることなくネガティブ指標を返す、
    ようにコンピュータ実行可能であることを特徴とする請求項１６に記載のコンピュータアクセス可能媒体。
20. 前記プログラム命令が更に、
    前記所与のデータパターンが前記第１ファイルに存在する場合、前記所与のデータパターンの指標とパターンロケーション情報を前記第１レコードに記憶し、
    前記所与のデータパターンが前記第１ファイルに存在しない場合、前記所与のデータパターンの指標を第２レコードに記憶する、
    ようにコンピュータ実行可能であることを特徴とする請求項１６に記載のコンピュータアクセス可能媒体。
21. 前記第１レコード及び前記第２レコードが、前記第１ファイルに各々が対応するそれぞれの名前付きストリームに記憶されることを特徴とする請求項２０に記載のコンピュータアクセス可能媒体。
22. 前記プログラム命令が更に、前記第１ファイルに記憶されたデータを修正するためにオペレーションの検出に応じて、前記第１ファイルに関連した前記レコードをクリアするようにコンピュータ実行可能であることを特徴とする請求項１６に記載のコンピュータアクセス可能媒体。

Images