JP4302723B2 - リモート・ストレージに対してファイル・システムにネーティブな支援を与えるファイル・システム・プリミティブ - Google Patents

Description

本発明は、ファイル・システムにおいてリモート・ストレージに対する支援を与えるシステムおよび方法に関する。更に特定すれば、本発明は、ファイル・システムがリモート・ストレージに対してネーティブな支援(native support)を与えられるようにすることにより、一部分をリモートに格納してあるファイルまたはその他のエンティティにおいて、当該ファイル・システムが、ファイルまたはその他のエンティティに関係するＩ／Ｏ要求を本質的に識別しかつ処理することを可能とするものである。

コンピュータのハードウエアおよびソフトウエアにおいては多くの発展がなされたが、一般的原理の一部は不変のままである。メモリやデータ・ストレージのコストは減少し続け、所与のサイズのデバイスの記憶容量は増大し続けているが、データを格納するために用いる媒体や、データのアクセス性(accessibility)というようないくつかの要因によって、引き続きデータ格納コストには差がある。例えば、一般的に、１データ・ワードをキャッシュ・メモリに格納する方がシステムＲＡＭに格納するよりも高価である。一方、システムＲＡＭは、磁気ディスク・ストレージよりも１ワード当たりの格納は高価である。磁気ディスク・ストレージは、アーカイブ・ストレージよりも１ワード当たりの格納は高価である。このように、用いないデータまたは使用頻度の低いデータ程安価なストレージに移動させようという考えに進みつつある。加えて、これまで以上に増大しつつあるデータ量にアクセスする要望が、データを価格効率的に格納しながらも、同時に所望のデータに対する適度なアクセス速度を得ようとする動機付けになっている。

従来技術におけるデータのリモート・ストレージの開発および実施は、別個の非統合階層型記憶システムを有するメインフレーム計算機モデルに基づくものである。階層型記憶システムは、データセットと呼ぶ記憶単位の、記憶デバイスの階層における配置を管理する。記憶デバイスの階層は、ハイエンド高スループット磁気ディスク、通常のディスク群、ジュークボックス型光ディスク(jukeboxes of optical disks)、テープ・サイロ(tape silo)、オフ・ラインで格納するテープ群のように、広範囲のデバイスを含むことができる。種々のデータセットをどこに格納すべきか決定する場合、階層型記憶システムは、典型的に、格納のコスト、検索時間、アクセス頻度等のような種々の検討項目間のバランスを取る。

ファイルは、典型的に、ユーザまたはその他のソフトウエア・エンティティがデータを格納可能なデータ部分、名称部分、およびファイルへのアクセス制御というようなことに用いることができる種々のフラグのような、種々のコンポーネントを有する。従来技術のシステムでは、主ストレージから除去しリモート・ストレージに移動させるファイルは、多くの場合「スタブ・ファイル」で置換する。スタブ・ファイルとは、階層型記憶システムが、当該ファイル内のデータがどこに格納されているか判断可能にする情報を含むファイルである。しかしながら、このような手法には、いくつかの問題がある。

スタブ・ファイルは、ファイルのデータ部分においてリモート格納ファイルの位置を記述する情報を格納する。旧来のファイル・システムは、通常、ファイル・システムがファイルのデータ部分の内容を判定できるように構成されていない。したがって、従来技術のシステムは、非統合的な階層ストレージ・マネージャを頼りに、スタブ・ファイルのデータ部分を読み出し、リモート格納ファイルがどこに位置するのか判断している。このような非統合的な手法では、階層型記憶システムは、スタブ・ファイルと同じ外観を有するファイルに向けて送られるあらゆるＩ／Ｏ動作を傍受することが必要となる。言い換えると、ファイルを見ただけでは、それがスタブ・ファイルか、または単にスタブ・ファイルと同じ外観を偶然有するに過ぎない非スタブ・ファイルか判断することは不可能である。例えば、スタブ・ファイルは多くの場合固定長を有する。しかしながら、固定長以外には、スタブ・ファイルを、スタブ・ファイルと同じ長さを偶然有する通常のファイルから区別するものは、外部には何もない。全てのスタブ・ファイルを識別するためには、典型的に、スタブ・ファイルと同じ長さを有するファイルに向けられる全てのコールを傍受するように、階層ストレージ・マネージャを設定する。一旦コールを傍受したなら、次にファイルを検査し、これが本当にスタブ・ファイルなのか、または偶然長さが同じなだけの通常のファイルなのか判定することができる。

以上の検討から、階層ストレージ・マネージャによって非スタブ・ファイルを検査する可能性が確かにあることは明白である。この結果は望ましいものではない。何故なら、通常のファイルへのアクセスが遅れ、不要な処理オーバーヘッドが余分に生ずるからである。従来技術のシステムには、異なる方法を用いて、同じデータ・バイト数を有するが通常のデータ・ファイルであるユーザ・ファイルからスタブ・ファイルを差別化することによって、このオーバーヘッドを解消しようとしたものがある。これら種々の手法は、エラーの確率を低下させることができるが、完全にそれを解消することはできない。したがって、通常のデータ・ファイルと、リモート格納データを有するデータ・ファイルとの間で明確に差別化することが可能な階層ストレージ・マネージャを提供することができれば、当技術分野における発展となろう。また、このようなリモート格納ファイルが実際にＩ／Ｏシステムが処理するＩ／Ｏ動作に関与する場合にのみ、リモート格納ファイルに伴う余分なオーバーヘッドが発生する階層ストレージ・マネージャを有することができれば、当技術分野における発展となろう。

従来技術の階層ストレージ・マネージャには、当該階層ストレージ・マネージャの非統合的本質により、既存のファイル・システムに殆どまたは全く影響を与えることなく、システム内に階層型記憶を実施することができるという１つの利点がある。このような階層ストレージ・マネージャは、各コールを検査して、それがスタブ・ファイルに関係するか否かについて判定を行うことができる。コールがスタブ・ファイルに関係する場合、階層ストレージ・マネージャはこのコールを傍受し、このコールを処理することができる。しかしながら、このコールがスタブ・ファイルに関係しない場合、階層ストレージ・マネージャはこのコールを正規のファイル・システムに渡すことができる。したがって、ファイル・システムは、階層ストレージ・マネージャが存在することを知る必要がない。残念なことに、このような手法では、コールがスタブ・ファイルに関係しない場合でも、コールが行われる毎に余分なオーバーヘッドが生じてしまう。これは、階層ストレージ・マネージャが各コールを検査しなければならないからである。システムが多数の階層ストレージ・マネージャを使用する場合、オーバーヘッドは急速に増加する虞れがある。したがって、既存のファイル・システムに殆どまたは全く変更が生じないという利点を維持しつつ、同時にリモート格納データのないファイルに対するあらゆるオーバーヘッドを極力抑えるかあるいは解消するような階層ストレージ・マネージャを提供することが望ましい。言い換えると、リモート格納データのないファイルに対しては既存のアクセス速度を維持し、リモート格納データのあるファイルについてのみ追加のオーバーヘッドを発生する、階層型記憶の手法を有することができれば非常に有利であろう。また、単一のシステムに複数の階層ストレージ・マネージャを用いる場合においてもこれらの特性全てを維持することができれば、非常に有利であろう。

従来技術の階層ストレージ管理方法には、これらの基準となるモデルが新たな記憶要件への組み込みや適応化に容易に対応できないという別の欠点がある。例えば、従来技術のリモート・データ格納方法は、通常のファイルをスタブ・ファイルと置換することを必要とした。このようなスタブ・ファイルは、事実上通常のファイルの全コンポーネントをスタブ・ファイルのコンポーネントと置換する。したがって、何らかの動作が通常のファイルに関係する場合、典型的に、要求を満たすためにリモート・ストレージからこれを検索しなければならない。特定のファイルに関連する情報の内どれがリモートに格納されているのか判定する際に高い自由度を可能とし、実行する頻度が高いと考えられる動作は、リモート・ストレージからファイル全体を呼び出すことなく処理可能とすることができれば、非常に有利であろう。

本発明は、従来の技術的現状における前述の問題を効果的に克服するものであり、ファイル・システムにおいてリモート・データ格納に対するネーティブな支援を与えつつ、同時にこのようなネーティブな機能を組み込むために既存のファイル・システムに必要ないかなる変更も最小に抑えるシステムおよび方法に関する。

本発明は、複数のドライバまたはデータ・マネージャが協働してＩ／Ｏ要求を満たすモデルを基本とすることができる。ドライバまたはデータ・マネージャは、層状関係を有することができ、各ドライバまたはデータ・マネージャがＩ／Ｏ要求の特定部分を処理する任務を負う。全ての層が協働してＩ／Ｏ要求を完全に満たすように、層間で情報を互いに受け渡すことができる。

本発明では、ファイルおよびディレクトリは、典型的に、２つの広いカテゴリのコンポーネント即ち「属性」を有することを認識する。属性のカテゴリの一方は、典型的に、ユーザ制御情報を格納するために用いる。このユーザ属性カテゴリは、ファイルのデータ部分を含み、ユーザまたはその他のクライアント・プロセスが所望の情報を格納するところである。属性の他のグループは、典型的に、Ｉ／Ｏシステムによる主な使用または排他的な使用のために除外しておく。これらのシステム属性は、アクセス制御情報を含む。これは、どのユーザまたはクライアント・プロセスが当該ファイルを、そしてどのように（例えば、リード・オンリ・アクセス、リード・ライト・アクセス等）アクセスすることができるのか確認する。Ｉ／Ｏシステムによる主なアクセスまたは排他的なアクセスのために確保してある他の属性には、ローカル記憶媒体上のどこに主データ属性を格納してあるかファイル・システムに確認させる情報を含むことも可能である。本発明は、リモート・ストレージ属性(remote storage attribute)と呼ぶ、追加のシステム属性を加える。このリモート・ストレージ属性は、Ｉ／Ｏシステムが、リモートに格納してあるファイルまたはディレクトリの属性をどこで見つけることができるのか確認させるのに十分な情報を含む。

本発明の最も一般的な観点では、ファイル属性のいずれでもまたは全てをリモートに格納することが可能である。この柔軟度により、使用頻度の高い情報をローカルに保持しておき、使用頻度の低い情報をリモートに格納することが可能となる。ローカル／リモート格納の判断は、属性毎に下すことができる。しかしながら、Ｉ／Ｏシステムに、どの属性をリモートに格納し、リモートに格納した属性がどこに位置するのかを確認させるには、十分な情報をローカル・ストレージに残しておかなければならない。

本発明の一実施形態では、前述の層状ドライバ・モデルを利用して本発明を実施する。このような実現例は、例えば、ローカル記憶媒体上に格納してある情報にアクセスすることができる１つ以上のファイル・システム・ドライバを備えることができる。ファイル・システム・ドライバの内少なくとも１つは、ファイルのリモート・ストレージ属性が存在する場合、それを識別するように適合化してある。したがって、このファイル・システム・ドライバは、リモート・ストレージ属性に格納してあるあらゆる情報を抽出し、その情報を階層ストレージ・マネージャに渡すことができる。すると、階層ストレージ・マネージャは、Ｉ／Ｏ要求を完了する責務を引き受けることができる。場合によっては、階層ストレージ・マネージャは、それ自体でＩ／Ｏ要求を完全に処理することが可能なこともあり、あるいはリモート・ストレージ属性またはローカル記憶媒体に格納してある情報を用いてＩ／Ｏ要求を処理することができることもある。このような場合、階層ストレージ・マネージャは、リモートに格納してある属性をリコールする必要がない。

階層ストレージ・マネージャが、リモートに格納してある属性をリコールせずにはＩ／Ｏ要求を処理することができない場合、階層ストレージ・マネージャはリコール情報を発生し、これを適切なドライバまたはコンポーネントに渡すことによって、必要な情報をリコールすることができる。人の介入なく検索できるように情報を格納してある場合、このようなリコール手順は、Ｉ／Ｏ要求をドライバまたはその他のデータ・マネージャに発行することに関係する場合がある。その際、ドライバまたはその他のデータ・マネージャはリコール手順を起動し、一旦データを検索したなら、適切な情報を階層ストレージ・マネージャに渡す。代替案として、階層ストレージ・マネージャは、オペレータまたはその他の個人に適切な媒体を検索しロードするように警告することによって、情報にアクセスすることができる。本発明の構造全体は、広範囲にわたる記憶モデルおよび記憶階層を支援する際の高い柔軟性を提供する。

以上の要約から、多種多様の階層ストレージ・マネージャを実施し、既存のシステムに組み込むことができ、しかもリモートに格納した属性を有さないファイルまたはディレクトリにアクセスするＩ／Ｏ要求には全くオーバーヘッドの追加を招かないことが明白であろう。その理由は、このようなＩ／Ｏ要求は、階層ストレージ・マネージャを必要とすることなく処理するからである。ファイル・システム・ドライバは、ファイルがリモート格納属性(remotely stored attribute)を必要とせず、従来通りにＩ／Ｏ要求を満たす(fill)ように進めることを絶対的に判断することができる。しかしながら、リモートに格納してある属性を有するファイルに遭遇した場合、ファイル・システム・ドライバは適切な情報を階層ストレージ・マネージャに渡し、階層ストレージ・マネージャはこのＩ／Ｏ要求を処理する責務を引き受ける。この実現例では、リモートに格納してあるデータに対する支援は、通常ではＩ／Ｏ処理に関与しないソフトウエア・コンポーネントに介入させＩ／Ｏ要求を処理するための制御を引き受けさせる機構による、通常の処理シーケンスの割込と見なすことができる。

一実施形態では、リモート・ストレージ属性は、タグおよびデータ値双方を有する。タグは、リモート・ストレージ属性の「オーナ」である階層ストレージ・マネージャを特定するために用いる。通常、リモート・ストレージ属性のオーナは、関連するファイルに関係するＩ／Ｏ要求の全てまたは一部を処理する責務を負う。データ値は、リモート・ストレージ属性のオーナがその中に格納したデータを含む。オーナは、リモート・ストレージ属性の値を用いて、関連するファイルに関係するＩ／Ｏ要求を適正に完了するために必要なまたは役立つあらゆる情報を格納することができる。例えば、殆どではないにしても多くの階層ストレージ・マネージャは、このようなデータ値を用いて、リモートに格納してある属性の位置を格納することが予期される。加えて、データ値は、どの属性をローカルに格納し、どの属性をリモートに格納するのかを格納するためにも用いることができる。

複数の層状ドライバを用いる際、ファイル・システム・ドライバがリモート・ストレージ属性を識別する場合、ドライバは、リモート・ストレージ属性のタグおよび値を抽出することができる。次いで、階層ストレージ・マネージャがそれ自体をリモート・ストレージ属性のオーナであると認識するまで、このタグおよび値を他の情報と共に、他の層状ドライバに渡すことができる。次に、リモート・ストレージ属性のオーナは、Ｉ／Ｏ要求を処理する制御を引き受けることができ、このＩ／Ｏ要求を完全に処理することができる。あるいは、他のドライバまたはコンポーネントを利用してＩ／Ｏ要求を完全に処理することも可能である。

このような実現例は、非常に柔軟なフレームワークをもたらし、多数の階層ストレージ・マネージャが単一システム内に共存することを可能にする。この場合、各階層ストレージ・マネージャは、それ自体の個々のリモート格納属性に関係するＩ／Ｏ要求を処理する。このような実現例は、高度のオーバーヘッド分離を達成するので、特定の形式のファイルを処理するためにシステムに追加の階層ストレージ・マネージャを加入しても、リモート格納属性を有するファイルまたはディレクトリに関係するＩ／Ｏ要求に伴うオーバーヘッドが大幅に追加されることはない。

本発明の更に別の利点は、以下の説明に明記してあり、部分的にその説明から自明であり、あるいは本発明の実施によって習得することができよう。本発明の利点は、添付の請求の範囲に特定して指摘してある手段(instrument)および組み合わせによって、実現し獲得することができる。本発明のこれらおよびその他の特徴は、以下の説明および添付の請求の範囲から一層明白となり、以下に明記する本発明の実施によって習得することができよう。

本発明の前述の利点およびその他の利点を得る態様について、添付図面に図示した具体的な実施形態を参照しながら先に端的に記載した本発明を更に特定して説明する。これらの図面は本発明の典型的な実施形態を図示するに過ぎず、したがってその範囲の限定と見なすべきでないことを理解の上、添付図面の使用により、更に具体的かつ詳細に本発明の記載および説明を行う。

以下、本発明のシステムおよび方法を実施するために用いる実施形態の構造または処理を例示する図を用いて、本発明の説明を行う。このように図を用いて本発明を提示することは、その範囲の限定と見なすべきではない。本発明は、データのリモート格納を実施する方法およびシステム双方を、ファイル・システムのネーティブ・コンポーネントとして考える。本発明の実施形態は、１つ以上の中央演算装置（ＣＰＵ）またはコンピュータ実行可能命令を実行するその他の処理手段、実行可能な命令を格納するコンピュータ読取可能媒体、ディスプレイあるいは情報を表示または出力するその他の出力手段、キーボードあるいは情報を入力するその他の入力手段等の標準的なコンピュータ・ハードウエアを備えた、特殊目的用コンピュータまたは汎用コンピュータで構成することができる。

本発明は、記憶デバイスの階層がシステムに使用可能であることを想定する。このような記憶デバイスの階層は、あらゆる数または形式の記憶媒体を備えることができ、それらには、ハイエンド・高スループット磁気ディスク、１つ以上の通常のディスク、光ディスク、光ディスクのジュークボックス、テープ・サイロおよび／またはオフラインで格納するテープの集合体を含み、なおもこれらに限定する訳ではない。一般的には、しかしながら、種々の記憶デバイスは２つの基本的なカテゴリに分類することができる。第１のカテゴリは、コンピュータ・システムにローカルに使用可能な情報を収容するローカル・ストレージ (local storage)である。第２のカテゴリは、コンピュータ・システムにローカルにアクセスすることができない情報を収容するあらゆる形式の記憶デバイスを含む、リモート・ストレージ (remote storage)である。これら２つデバイス・カテゴリ間の線は明確に定義することはできないが、一般的に、ローカル・ストレージは、比較的アクセス時間が素早く、頻繁にアクセスするデータを格納するために用いる。一方リモート・ストレージは、アクセス時間がかなり長く、頻繁にはアクセスしないデータを格納するために用いる。また、リモート・ストレージの容量は、典型的に、ローカル・ストレージの容量よりも１桁大きい。

また、本発明の範囲内の実施形態は、実行可能な命令またはデータ・フィールドを格納してある、コンピュータ読取可能媒体も含む。このようなコンピュータ読取可能媒体は、汎用コンピュータまたは特殊目的用コンピュータによってアクセス可能なあらゆる入手可能な媒体とすることができる。限定ではない一例として、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク・ストレージ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の実行可能命令またはデータ・フィールドを格納するために使用することができ、かつ汎用コンピュータまたは特殊目的用コンピュータによってアクセス可能なその他のあらゆる媒体を含むことができる。また、これらの組み合わせも、コンピュータ読取可能媒体の範囲内に含まれて当然である。実行可能な命令は、例えば、汎用コンピュータ、特殊目的用コンピュータ、または特殊目的処理装置にある種の機能または機能群を実行させる命令およびデータから成る。

本発明の実施形態には、Ｉ／Ｏ処理を行うために複数のドライバ手段を用いるシステムにおいて実施するとよいものがある。これらの実施形態の状況(context)を一層よく理解するために、図１を参照する。図１は、クライアント・プロセスと、Ｉ／Ｏ処理を行うための複数のドライバ手段を用いるＩ／Ｏシステムを有するオペレーティング・システムとの間の双方向処理の簡略化した図を示す。この図は、例えば、Microsoft Windows NT (R)オペレーティング・システムを表わす。図１は、Ｉ／Ｏ処理を行うために複数のドライバ手段を用いるあらゆるオペレーティング・システムを表わす図と考えることもできる。図１において、クライアント・プロセス２０は、オペレーティング・システム・サービス２２を利用してＩ／Ｏ要求を行う。これを行うには、典型的に、オペレーティング・システムが提供するアプリケーション・プログラム・インターフェース（ＡＰＩ）機能に対して、クライアント・プロセス２０がコールする。適切なＡＰＩ機能をコールすることにより、結果的にオペレーティング・システム・サービス２２へのコールが得られる。このようなコールを矢印２４で示す。

図１では、クライアント・プロセス２０は、「ユーザ」モードで動作するように示してあり、オペレーティング・システム・サービスは、「カーネル」モードで動作するように示してある。最近のオペレーティング・システムは、典型的に、種々のアプリケーション・プログラムや直感的ユーザ・インターフェースにロバストな環境を提供する。このようなオペレーティング・システムは、通常、当該オペレーティング・システムの精巧さのレベルや、オペレーティング・システムが実施するセキュリティ機能(security feature)に応じて、異なるオペレーティング・レベルまたは「モード」を有する。通常のアプリケーション・プログラムは、典型的には最も低い優先度で走り、セキュリティ・デバイスの完全な補体(full complement)を適所に有し、他のアプリケーションまたはオペレーティング・システムのその他の層との干渉を禁止する。オペレーティング・システムが提供するハードウエアおよびその他のサービスは、インターフェースまたは機構を制御することによってのみアクセスされ、ユーザ・アプリケーションまたはその他のユーザ・モードのプロセスがシステムを「クラッシュ」する可能性を抑制する。典型的に、最低優先度モードをユーザ・モードと呼び、これは殆どのコンピュータ・ユーザが精通しているモードである。ドライバとそれらに関連するハードウエアの緊密な統合化のため、および多くのドライバが実行するタスクの時間厳格性(time critical nature)のため、ドライバは典型的にオペレーティング・システム・モードで走る。これは、優先度がかなり高く、セキュリティ保護はかなり低い。このモードを一般に「カーネル」モードと呼ぶ。ドライバおよび他のオペレーティング・システム・サービスをカーネル・モードに置くことにより、オペレーティング・システムはより高い優先度で走り、ユーザ・モードからでは不可能な多くの機能を実行することが可能となる。

クライアント・プロセス２０がオペレーティング・システム・サービス２２をコールしてＩ／Ｏ要求を実行する場合、Ｉ／Ｏ要求を第１ドライバ手段に渡し、Ｉ／Ｏ処理を実行する。図１では、ファイル・システム・ドライバ２６およびデバイス・ドライバ２８が、Ｉ／Ｏ処理を実行するドライバ手段の例を表わす。Ｉ／Ｏ要求の第１ドライバ手段への受け渡しは、図１では、例えば矢印３０で示してある。すると、ファイル・システム・ドライバ２６はＩ／Ｏ要求を取り込み、次のドライバにＩ／Ｏ要求を渡す前に、このＩ／Ｏ要求の部分的処理を概略的に実行する。

一例として、クライアント・プロセス２０がハードウエア・デバイス３６上で特定のファイルを開いて、そのファイルから情報を検索または格納したいと仮定する。Ｉ／Ｏ要求は、クライアント・プロセス２０からオペレーティング・システム・サービス２２に移り、次いでファイル・システム・ドライバ２６に達する。次に、ファイル・システム・ドライバ２６は、Ｉ／Ｏ要求をファイル名からハードウエア・デバイス３６上の特定位置に変換する。この変換プロセスは、その特定位置においてハードウエア・デバイスから読み取るべきまたはハードウエア・デバイスに書き込むべきデータ・ブロックの数を含むとよい。この情報は、次に、次のドライバ、例えば、デバイス・ドライバ２８に渡すことができる。デバイス・ドライバ２８が要求する情報を受け渡すプロセスは、図１では矢印３２および３４で示している。デバイス・ドライバ２８は、読み出しまたは書き込みを行う位置およびデータ・ブロック数を取り込み、これらを適切な制御信号に変換し、所望の情報をハードウエア・デバイス３６から検索するか、あるいは所望の情報をハードウエア・デバイス３６に格納する。検索したデータは、次に、デバイス・ドライバ２８からファイル・システム・ドライバ２６に渡し、最終的には、戻り矢印３８で示すように、クライアント・プロセス２０に戻すことができる。ステータス情報も同様に戻すことができる。

図１において、Ｉ／Ｏ要求は、ファイル・システム・ドライバ２６とデバイス・ドライバ２８との間で直接受け渡すことはしない。代わりに、Ｉ／Ｏ要求は、Ｉ／Ｏマネージャ４０を介して、ドライバ間で受け渡しする。しかしながら、全ての実現例においてＩ／Ｏマネージャを有することが必要という訳ではない。Ｉ／Ｏ要求を直接あるドライバから別のドライバに渡し、Ｉ／Ｏマネージャによって転送を調整しなくてもよい実施形態も存在する。

次に図２を参照し、ファイルのある属性をリモートに格納し、ファイルの別の属性をローカルに格納するプロセスを一般化した図を示す。図２に示すように、全体的に４２で示すファイルは、システム属性４４およびユーザ属性４６で構成することができる。以下で更に詳細に論ずるが、システム属性とは、オペレーティング・システムおよびＩ／Ｏシステムが主にまたは排他的に用いて、当該オペレーティング・システムおよびＩ／Ｏシステムがそれらの種々のタスクを実行可能とするのに必要または有用な情報を格納するための属性である。システム属性の一例は、ファイルまたはディレクトリに対するセキュリティ情報またはアクセス制御情報である。ユーザ属性とは、ユーザまたはその他のクライアント・プロセスがそれ自体の目的のために用いる属性である。ファイルのデータ属性が、ユーザ属性のよい例である。システム属性およびユーザ属性については、以下で更に詳しく論ずる。

リモート格納処理ブロック４８によってファイル４２を検査する。リモート格納処理ブロック４８は、ファイル４２のどの属性をリモートに格納し、リモートに格納する属性をどこに格納するのかを決定する責務を担う。これらの決定を下す際に、リモート格納処理ブロック４８は、多数のファクタを検討することができる。このようなファクタには、例えば、これまでに当該属性をアクセスした頻度を含むことができる。一般に、長時間データがアクセスされないでいる場合、近い将来においてそれにアクセスする可能性は低いという理論から、アクセス頻度が非常に低いデータは、リモート・ストレージに移動させるとよい。リモート格納処理ブロック４８が考慮するとよい別のファクタにサイズがある。ある属性が費やすローカル記憶空間が非常に少ない場合、この属性をリモート・ストレージに移動させても、得るものは多くない。一方、大量のローカル記憶空間を費やす属性の場合、この属性をリモート・ストレージに移動させると、大量のローカル・ストレージが空くので、ローカル・ストレージの空間が貴重な場合、このような移動は有効である。

どの属性をリモートに格納し、どこにその属性を格納するのかについて決定する際に、多数の他のファクタも影響する場合がある。このようなファクタには、例えば、リモート記憶媒体にアクセスする時間が含まれる場合がある。例えば、属性をローカル・ストレージから光ジュークボックスに移動させる場合、アクセス時間が大幅に増大しないと思われる。恐らく、適正な光ディスクを選択し装填して、そこから情報を検索するために必要な時間はさほど多くないであろう。一方、属性をオフライン・テープ・ストレージに移動させた場合、オペレータの手作業によって検索しロードしなければならないので、検索時間が多大となる可能性がある。一般に、どの属性をリモートに格納し、このような属性をどこに格納すべきかについて決定する場合、リモート格納処理ブロック４８は、ストレージの総合的費用効率性や、異なるクラスのアプリケーションに対するＩ／Ｏの応答時間のような異なるパラメータを最適化する。どの属性をリモートに格納し、このような属性をどこに格納すべきかについて選択するために利用する正確な方法論は、本発明では規定しない。本発明を用いると、いかなるリモート格納の目標を所望する場合でも、それを達成することができる。

本発明の範囲内の実施形態は、様々な方法で、リモート格納処理ブロック４８と関連付けて記載する総合的な処理を実施することができる。以下で更に詳しく説明するが、リモート格納処理ブロック４８の機能は、Ｉ／Ｏ処理を実行するドライバ手段によって実施することができる。このようなドライバ手段は、Ｉ／Ｏシステム内の他のあらゆるドライバ手段からも分離することができる。代替案では、リモート格納処理ブロック４８の機能は、Ｉ／Ｏシステム内で用いられる多目的ドライバ手段または単一目的ドライバ手段に組み込むことも可能である。以下の説明で一層明白になるであろうが、本発明にとって重要なのは、リモート格納処理ブロック４８の機能をＩ／Ｏシステム内に組み込み、Ｉ／Ｏシステムがリモート・ストレージに対するネーティブな支援に対処し、従来技術に記載したような非統合コンポーネントに頼る必要性をなくすことが全てである。

リモート格納処理ブロック４８が、ファイル４２の属性のどれをリモートに格納し、このような属性をどこに格納すべきか決定した後、リモート格納処理ブロック４８は、適切なフォーマットに属性を組み立て、これらの属性をリモート・ストレージに転送するステップを開始する。図２では、この手順は、概略的に、リモート格納属性５０、読み出し／書き込みデータ処理ブロック５２、およびリモート・ストレージ５４によって示している。複数のリモート格納属性５０、読み出し／書き込みデータ処理ブロック５２、およびリモート・ストレージ５４を示すのは、特定のファイルからのリモート格納属性は、同じ場所に格納したり、同じ形式のリモート記憶デバイスに格納することさえも不要であることを強調するためである。図２では、５０で示す各ブロックが、リモートに格納する１つ以上の属性を収容することができる。本発明の固有の柔軟性のために、リモート格納処理ブロック４９は、属性１つ毎に決定を下すことができるので、個々の属性を最も適切な場所に格納することが可能となる。このような柔軟性は、特定のファイルの属性全てを同じ場所に格納可能であることを当然含むものである。

リモート格納属性５０、読み出し／書き込みデータ処理ブロック５２、およびリモート・ストレージ５４は、特定のリモート記憶デバイスにアクセスするために存在するいかなる機構を用いても、適切なデータを転送し、適切なリモート記憶デバイス上に格納することを単に必要とする概念的なデータ・フロー経路を示す。より詳細な例によって以下に例示するように、読み出し／書き込みデータ処理ブロック５２は、対応するリモート記憶デバイスが、リモート格納処理ブロック４８が位置するシステムによって直接アクセス可能である場合、Ｉ／Ｏ処理を実行するためには単一のドライバ手段を用いて実施することができ、あるいはネットワークまたは多数のコンピュータ・システム間で通信するその他の手段を通じた多数のコンピュータ上で走るＩ／Ｏ処理を実行するためには、数個のドライバ手段とすることも可能である。必要なのは、適切なデータを適切なリモート記憶デバイスに渡し、そこに格納するだけである。一般的に、読み出し／書き込みデータ処理ブロック５２を実施するために用いる機構は、本発明を実施するために用いる具体的な動作環境、ならびにリモート記憶デバイス５４とリモート格納処理ブロック４８が位置するシステムとの間のデータ・フロー経路を備えるのに必要な特定のハードウエアおよび／またはソフトウエアによって、かなり左右される。

リモート格納処理ブロック４８が、どの属性をリモートに格納するか決定し、リモート格納属性５０のように、適切なデータ・フォーマットの属性を組み立てた後、ファイル４２から属性を安全に除去することができる。実施形態によっては、リモート格納属性５０をリモート・ストレージ上に安全に格納するまで、これらをファイル４２から除去する前に待つ方が望ましい場合もある。リモート格納属性５０の除去は、図２では、破線エリア５６および５８で示す。これらのエリアは、システム属性およびユーザ属性双方共、本発明にしたがってリモートに格納できることを示す。加えて、リモート格納処理ブロック４８は、リモート・ストレージ属性６０をファイル４２のシステム属性に追加する。

リモート・ストレージ属性６０については以下で更に詳しく論ずるが、リモート・ストレージ属性６０は、通常、リモート格納処理ブロック４８が、リモート格納属性５０がどこに位置するのか確認するために必要なあらゆる情報を格納するために用いられる。加えて、リモート・ストレージ属性６０は、リモート格納処理ブロック４８の個々の実施にしたがって、多種多様のその他の情報を含むことができる。例えば、リモート・ストレージ属性６０内でどの属性をリモートに格納してあるかを格納することが望ましい場合がある。別の場合には、ファイル４２は、どの属性をリモートに格納してあるかについてのアイデンティティを、他の機構によって判定可能とするような構造である場合も恐らくあるであろう。同様に、他の情報もリモート・ストレージ属性６０に格納することも可能である。例えば、リモート格納処理ブロック４８は、リモート・ストレージ５４内に格納してあるデータの保全性(integrity)を全面的に信頼してはいない場合も恐らくあるであろう。このような場合、リモート格納処理ブロック４８は、リモート格納属性上でディジタル指紋またはサインを計算し、この指紋またはサインをリモート・ストレージ属性６０にセーブすることができる。この場合、リモート属性を検索すると、リモート属性に対して第２サインを計算し、計算したサインを、リモート・ストレージ属性６０に格納してあるサインと比較することができる。このような手順により、リモート格納処理ブロック４８は、リモート格納属性をリモート・ストレージ５４から検出する際に、それらに生じたあらゆる変化を検出することが可能になる。

以上の説明から明らかなように、リモート格納処理ブロック４８が必要とするまたは所望するあらゆる数または形式のデータでも、リモート・ストレージ属性６０に格納することができる。リモート・ストレージ属性６０の重要な特徴は、これがファイル４２の状態の固有部分を形成するので、Ｉ／Ｏシステムはこれを追跡しファイルの他の属性全てと同様に一元管理することにある。これが意味するのは、ファイル・システムは、ファイル内の他のあらゆる属性と全く同様に、リモート・ストレージ属性を検出し、操作し、またはその他の方法で処理可能であるということである。したがって、ファイルを扱うユーティリティは、リモート・ストレージ属性上で具体的に動作する機能性を組み込むことができる。例えば、ディレクトリのリストは、リモート・ストレージ属性６０を検査し、ローカル・ストレージ空間の割合、および使用可能なファイルが占めるリモート・ストレージ空間の割合を確認することができる。加えて、あるリモート格納データにアクセスするために必要な検索時間を推定するユーティリティを開発することも可能である。このようなユーティリティによって、システム・マネージャは、変化する状態またはその他の基準に基づいて、リモート格納処理ブロックの動作を微調整(fine-tune)即ち修正することが可能となる。この情報全ては、単に、ローカルに格納してある情報を検査するだけでコンパイル可能であることを注記しておく。また、本発明は、従来技術のシステムでは得られない他の利点も広く提供する。

図２では、ファイル４２のシステム属性部分に追加するものとして、リモート・ストレージ属性６０を示している。以下で一層明らかとなる理由のために、リモート・ストレージ属性６０をユーザの変更から保護することが考えられる。リモート・ストレージ属性６０は、リモート格納処理ブロック４８がその様々な機能を実行するために必要な情報を格納するために用いるので、ユーザの変更や干渉から保護して当然である。しかしながら、リモート・ストレージ属性６０に格納する情報の少なくとも一部は、場合によっては、ユーザやその他のクライアント・プロセスに関心があることも考えられる。適切な状況において、このような情報をユーザまたはクライアント・プロセスに使用可能にしてもよい。また、システム・マネージャが使用するために設計したユーティリティのような特殊化したクライアント・プロセスに、リモート・ストレージ属性６０内の情報を変更させることが必要となることも、稀にあり得る。このような特殊化ユーティリティによる特別な場合のアクセスは、リモート・ストレージ属性６０をシステム属性グループの外側に置くものとして解釈すべきでない。リモート・ストレージ属性６０の主な使用は、Ｉ／Ｏシステム自体が、そのリモート格納機能を実施するため、および本発明のリモート格納機能性をファイル・システム自体に統合するためである。

一旦リモート・ストレージ属性６０をファイルに追加し、リモート格納属性をファイルから除去したなら、そのファイルをローカル・ストレージに格納することができる。このプロセスは、図２において、読み出し／書き込みデータ処理ブロック６２およびローカル・ストレージ６４によって示してある。読み出し／書き込み処理ブロック６２およびローカル・ストレージ６４は、リモート格納処理ブロック４８からローカル・ストレージ６４までの概念的なデータ・フロー経路を表わそうとしたものである。正確な実施の詳細は、本発明を実施するために選択する個々の動作環境によって異なる。以下で更に詳しく説明するが、読み出し／書き込みデータ処理ブロック６２は、Ｉ／Ｏ処理を実行するための別個のドライバ手段によって実施してもよく、あるいはリモート格納処理ブロック４８と纏めて、Ｉ／Ｏ処理を実行するためのより大きなモノリシック・ドライバ手段(monolithic, driver means)を形成してもよい。

図２に提示する例は、リモート格納処理ブロック４８が検査する特定のファイル、およびどの属性をローカルに格納し、どの属性をリモートに格納し、リモートに格納する属性をどこに配置するかについて行う決定を示す。このような手順は、システムに適切な機構であればいずれによっても行えることを注記しておく。例えば、ローカル・ストレージ６４において、リモート・ストレージに移動させるべき情報を検査するために周期的にユーティリティを走らせるようにスケジューリングを行うことも可能である。あるいは、アクセスする毎に各ファイルを検査するように、システムを設定することも可能である。更に別の例として、恐らくこのような手順は、ユーザまたはシステム・マネージャの要求によってのみ起動する。本質的に、本発明は、このような手順をいつ利用するかについては定義せず、単に情報をローカル・ストレージからリモート・ストレージに移動させる機構について記載するに止まる。

これまでの説明は具体的に本発明がファイルに対してどのような処理を行うのかということを対象にしてきたが、本発明の概念は、排他的にまたは主にシステムが用いるために設計した属性の集合を有する、あらゆるローカルに格納したエンティティとでも使用可能である。したがって、ファイルの例は、あらゆる観点においても例示として見なし、本発明の範囲をいずれの特定のエンティティにも限定して捕らえてはならない。

次に図３を参照し、リモート格納属性を有するファイルに関係するＩ／Ｏ要求の処理を表わす上位ブロック図を示す。本発明の関連においては、Ｉ／Ｏ要求は、本発明を実施するＩ／Ｏシステムが実行することができるあらゆる動作であるとする。したがって、Ｉ／Ｏ要求の定義は、単なるファイル・データの読み書きを遥かに越えるものである。状況によっては、特定のファイルをアクセスした場合にある電話番号に通話するというように、Ｉ／Ｏ要求が、従来のＩ／Ｏ動作と関連のない他のアクションをトリガする場合もある。本発明の状況においては、この用語は広く解釈することを想定する。

Ｉ／Ｏ要求が、リモート格納属性を有するファイルまたはその他のエンティティに関係する場合、読み出し／書き込みデータ処理ブロック６２は、リモート格納属性が関与することを確認することができる。これは、リモート・ストレージ属性６０の存在によるものである。このような属性を検出した場合、リモート・ストレージ属性６０内の情報をリモート格納処理ブロック４８に渡すことができる。すると、リモート格納処理ブロック４８は、Ｉ／Ｏ要求を処理するために何をする必要があるかについて判定を行うことができる。種々の実施形態が、種々の形式の情報をリモート格納処理ブロック４８に渡すことができる。例えば、リモート・ストレージ属性６０内の情報を単にリモート格納処理ブロック４８に渡すことも可能である。次に、リモート格納処理ブロック４８がローカル・ストレージ６４からの他の情報を必要とする場合、リモート格納処理ブロック４８は、読み出し／書き込みデータ処理ブロック６２が所望の情報を検索することを要求することができる。あるいは、当初からより多くの情報をリモート格納処理ブロック４８に渡してもよい。このような詳細は、本発明にはさほど重要ではない設計上の選択事項と見なす。図３では、ローカル・ストレージ６４からリモート格納処理ブロック４８へ検索情報を渡す処理は、ファイル６６によって示しており、このファイルをリモート格納処理ブロック４８に渡す。

一旦リモート格納処理ブロック４８がリモート・ストレージ属性６０およびその他のあらゆる必要な情報を受け取ったならば、リモート格納処理ブロック４８は、Ｉ／Ｏ要求はローカルに格納してある情報を用いて処理することができるか、またはＩ／Ｏ要求を処理するには、リモート・ストレージ５４から情報を検索することが必要であるかについて判定を行うことができる。リモート・ストレージ５４から情報を検索することなくＩ／Ｏ要求を処理できるか否かに関する問題は、個々のＩ／Ｏ要求およびリモートに格納してある属性によって異なる。

特定的な例として、システムにアクセス可能な情報のコンテンツ・インデックス付け(content indexing)を実施するＩ／Ｏシステムについて検討する。このようなシステムでは、ユーザは、ローカルまたはリモート記憶デバイス上の個々のアドレスによってではなく、キー・ワードまたはその他のコンテンツ情報によって、情報を検索することができる。例えば、ユーザは、ある個人が著した文書全て、特定のトピックに関する文書全て、または特定の単語または文章を有する文書全てを要求することができる。このようなコンテンツ・インデックス付け方式の場合、情報を検査し、種々のコンテンツ・キーを格納する必要がある。実現例によっては、コンテンツ・キーを１つ以上のファイルの属性として格納することが可能な場合もある。その際、ファイルのデータをリモートに格納する場合であっても、コンテンツ・キーはローカルに保持するとよい。このような状況では、ユーザが、あるコンテンツ・キーを含む全ファイルのリストを要求する場合、コンテンツ・キーをローカルに保持してあれば、単にローカル・ストレージ６４から情報を読み出すことによって、この要求を満たすことができる。このような状況では、リモート格納処理ブロック４８は、単にローカル・ストレージ６４上で適切な情報を検査し、応答６８で例示するように、適切な応答を発生する。

しかしながら、リモートに格納してある情報にユーザがアクセスしたい場合、このような情報はリモート・ストレージ５４から検索する必要がある。このような状況では、リモート格納処理ブロック４８は、要求された情報を検索するステップを起動すればよい。これを、図３において、属性リコール７０で示す。図３では、属性リコール７０は、読み出し／書き込みデータ処理ブロック５２が処理するものとして示す。リモート・ストレージ５４が、オペレータの介入なく、読み出し／書き込みデータ処理ブロック５２によるアクセスが可能な場合、読み出し／書き込みデータ処理ブロック５２は単にリモート・ストレージ５４から、要求された属性を検索し、リモート格納属性７２で示すように、リモート格納処理ブロック４８にこれらを返せばよい。しかしながら、オペレータの介入が必要な場合、恐らく読み出し／書き込みデータ処理ブロック５２、またはその他の処理ブロックは、要求された情報を検索するために必要な適切なリモート記憶媒体をロードするか、またはその他の方法でアクセス可能にするように、オペレータに警告する必要がある場合もあり得る。次に、一旦適切な媒体が使用可能になったなら、要求された情報を検索し、リモート格納処理ブロック４８に返すことができる。いずれの場合でも、例えば、応答６８のような適切な応答を戻すことができる。

次に図４を参照し、本発明と共に用いるのに適したファイルの属性を表わす図を示す。これらの属性は、Microsoft Windows NT(R)に特定して開発したＮＴＦＳファイル・システムが用いる属性の修正リストを表わす。ＮＴＦＳファイル・システムについては、Microsoft Press（マイクロソフト・プレス社）が発行したHelen Custer（ヘレン・カスター）によるInside the Windows NT file System（Windows NTファイル・システムの内側）により詳細に記載されており、この言及により本願にも含まれるものとする。図４では、ファイルを構成する属性は、２つの基本的グループに分割することができる。第１グループはシステム属性を含み、第２グループはユーザ属性を含む。一般的に、システム属性は、システムがその種々の機能を実行するために必要なまたは要求される情報を格納するために用いられる。このようなシステム属性は、通常、ロバストなファイル・システムの実施を可能にする。システム属性の正確な数および形式は、概して、個々のオペレーティング・システムまたは利用する個々のファイル・システムに全面的に依存する。一方、ユーザ属性は、ユーザが制御するデータを格納するために用いられる。これは、ユーザがある状況の下では１つ以上のシステム属性へのアクセスを得られないということではない。しかしながら、ユーザ属性は、ユーザまたはクライアント・プログラムが対象のデータをプログラムに格納することができる格納場所を定義する。図４では、システム属性は全体的に７４で示し、ユーザ属性は全体的に７６で示している。

システム属性は、例えば、標準情報属性７８、属性リスト８０、名称属性８２、セキュリティ記述子属性８４、およびリモート・ストレージ属性８６で構成することができる。標準情報属性７８は、読み出しのみ、読み出し／書き込み、隠れ(hidden)等のような標準的な"MS-DOS"属性を表す。属性リスト８０は、ファイルがマスタ・ファイル・テーブル内において２つ以上の記憶レコードを占有する場合に、ファイルを構成する追加の属性の場所を識別するためにＮＴＦＳが使用する属性である。マスタ・ファイル・テーブルは、ファイルまたはディレクトリの常駐属性全てを格納する場所である。名称属性８２は、ファイルの名称である。ＮＴＦＳでは、ファイルは多数の名称属性、例えば、長い名称、短いMS-DOS名称等を有する場合がある。セキュリティ記述子属性８４は、ファイルを所有するのが誰で、それにアクセスすることができるのは誰かを指定するために、Windows NT (R)が用いるデータ構造を含む。これらの属性については、先に言及して本願にも含まれるものとした、Inside the Windows NT File Systemに更に詳細に記載されている。

リモート・ストレージ属性８６は、本発明が追加する新たな属性である。リモート・ストレージ属性８６は、特定のファイルを、リモート格納属性を有するものとして識別する。リモート・ストレージ属性は、リモート格納属性の場所を識別できるのに十分な情報を収容することが好ましい。全ての属性は、全体として捕らえた場合、特定のファイルのどの属性がリモート格納であり、どの属性がローカル格納か識別可能でなければならない。このような情報は、リモート・ストレージ属性８６に含めることができ、あるいはこのような情報は、ファイルの他の属性を検査することによって得ることも可能である。例えば、各属性が特定の長さである場合、または特定の属性の長さを属性と共に格納する場合、単純に予測長を実際にローカル・ストレージ上に格納してある長さと比較することによって、どの属性がリモート格納であるのか識別することが可能となる。例えば、あるデータ属性が１００Ｋバイト長であると予想し、実際に格納してある情報量がかなり少ない場合、このデータ属性はリモート格納と推定することができる。あるいは、このような情報は、単純にリモート・ストレージ属性８６に組み込むことも可能である。一実施形態では、リモート・ストレージ属性は、次のように構成する。

以下で更に詳しく説明するように、本発明の実施形態のあるものは、Ｉ／Ｏ処理を実行するために複数のドライバ手段を利用し、リモート・データ格納処理を実施する場合がある。例えば、図２または図３のリモート格納処理ブロック４８は、Ｉ／Ｏ処理を実行するための１つのドライバ手段に実施することができ、読み出し／書き込みデータ処理ブロック６２は、Ｉ／Ｏ処理を実行するための他のドライバ手段を用いて実施することができる。この場合、これら２つのドライバ手段は、これらの間で情報をやりとりすることにより、本発明の目的を達成するように調整することができる。実際には、リモート格納処理の機能を実施するＩ／Ｏ処理を実行するためのドライバ手段は、単純に、Ｉ／Ｏシステム内の種々の目的のために用いる複数のドライバ手段の内の１つとしてもよい。このような実施形態について、以下に論ずる。このような状況では、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を処理する責務を引き受けるのは、どのドライバであるのか確認する必要がある場合もある。本発明の範囲内の実施形態は、Ｉ／Ｏ要求の少なくとも一部を処理すべきドライバとして、特定のドライバ手段を特定する手段を備えることができる。特定のドライバをリモート・ストレージ属性のオーナとして特定する機構であれば、いずれでもこのような手段に用いることができる。リモート・ストレージ属性が、先のテーブルに示す構造を有する場合、このような手段は、例えば、タグ値を備えることができる。この例では、タグは、リモート・ストレージ属性のオーナのＩＤを含むデータ・ワードである。このような機構により、単一システム内に複数の階層ストレージ・マネージャが存在することが可能となり、各階層ストレージ・マネージャは、異なる形式のファイルまたは異なる形式のリモート記憶デバイスに関係するＩ／Ｏ要求を処理するように適合化してある。

ドライバをどのシステム上にインストールするかには係わらず、同じタグを常に同じオーナ・ドライバに関連付けるように、タグを割り当てることが好ましい。言い換えると、タグ値を特定のドライバに割り当てる何らかの機構が存在することが好ましい。例えば、タグ値のブロックを種々のドライバ製造者に割り当てる中央レポジトリまたはクリアリング・ハウスがあるとよい。こうすると、ドライバ製造者は、タグを特定のドライバに割り当てることができる。タグ値を多くとも１つのドライバに関連付けさせる他のいずれの機構も、使用可能である。このようにタグ値を割り当てることにより、どのシステムにインストールしたかには係わらず、同じオーナ・ドライバが同じリモート格納要求を処理することが可能となる。あるいは、状況によっては、ローカル・タグ値を動的な方法で割り当て、インストール中にシステムによってタグ値を割り当てるようにすることも可能となる。しかしながら、このような方法ではいくつかの問題も存在する場合があるので、一般的には好ましくない。

先のテーブルに示したリモート・ストレージ属性では、任意のリモート格納フラグを示した。先程リモート格納フラグを示したのは、リモート格納属性を有するファイルの識別を可能にする機構が存在しなければならないことを示すためである。このような指示を与えるには、例えば、リモート格納属性を有するファイルを示すリモート格納フラグを用いることができる。あるいは、他の機構を用いることも可能である。例えば、リモートに格納可能な各属性毎に、フラグを保持することも可能である。属性をリモートに格納する場合、フラグをセットすることができる。このような機構は、リモート格納属性が存在するという事実の確認だけでなく、どの属性をリモートに格納してあるかという確認も可能にする。更に別の例として、各属性の予想長を、ローカルに格納してあるデータの実際の長さと比較してもよい。更に別の例として、１つ以上のタグ値を、ファイルがリモート格納属性を全く有していないことを示すために確保することも可能である。このような機構を用いることにより、例えば、ファイルがリモート格納属性を全く有していないことを示すためにタグ０を確保することも可能となろう。ファイルが少なくとも１つのリモート格納属性を有する場合、他のいずれかのタグ値がこれを示すことになる。

先に示したリモート・ストレージ属性によって、オーナが制御するデータの格納が可能となる。したがって、本発明の実施形態は、ドライバ手段がリモート格納属性を管理するために用いる情報を格納する手段を備える。一例として、限定ではなく、このような手段はオーナ制御データ・フィールドを備えるとよい。オーナ制御データ・フィールドは、リモート・ストレージ属性のオーナが、リモート格納属性を適正に管理するために必要なあらゆる形式のデータでも置くことができる場所を表わす。例えば、リモート格納属性の場所は、リモート・ストレージ属性のデータ・フィールドに格納することができる。他の例も既に示した。更に他の例として、階層ストレージ・マネージャの一部が、オーナ制御データ・フィールド内に、リモート格納属性のアイデンティティを格納できるようにするとよい。これは、階層ストレージ・マネージャが、どの属性をローカルに格納し、どの属性をリモートに格納したのかを素早く確認することを可能にする機構にもなる。このデータ・フィールドには、他のあらゆる形式のデータでも格納可能である。

先に示したリモート・ストレージ属性では、データ・フィールドの前にデータ長指示子がある。この記憶フォーマットでは、データ・フィールドの長さを格納し、データ・フィールドを完成するために読み出さなければならないデータ量を確認する。あるいは、実施形態によっては、固定長のデータ・フィールド、あるいはポインタまたはリンクによって互いに連鎖した情報のブロックを利用するデータ・フィールドを格納する方が一層効率的な場合もあり得る。本質的に、データ・フィールドを完成するために読み出さなければならないデータ量を確認するあらゆる機構が利用可能である。オーナ・ドライバによって格納する必要があり得るデータ量についても考慮すべきであろう。このような考慮は、データ・フィールドをどのように格納するか、およびデータ・フィールドの最大可能長に影響を与える。

次に図４を参照し、ファイルのユーザ属性を表わすグループ７６について検討する。先に説明したように、ユーザ属性は、ユーザまたはクライアント・プロセス情報を格納するためにユーザまたはその他のクライアント・プロセスが用いる属性を表わす。ＮＴＦＳファイルは、典型的に、図４にデータ１属性８８およびデータ２属性９０として示す、１つ以上のデータ属性を有する。従来のファイル・システムの殆どは、単一のデータ属性に対応するに過ぎない。データ属性は、ユーザ制御データを格納可能な場所と基本的には全く同様である。例えば、ワード・プロセッシング文書では、典型的に、ファイルのデータ属性に文書を格納する。ＮＴＦＳファイル・システムでは、ファイルは多数のデータ属性を有することができる。１つのデータ属性を「無名」属性(unnamed attribute)と呼び、他の属性は各々関連する名称を有する名称付き属性である。データ属性の各々は、異なる形式のユーザ制御データを格納できる格納場所を表わす。本発明と組み合わせた場合、このようなファイル構造は、データ属性のいずれかまたは全てをローカルまたはリモートのいずれにも格納することが可能となる。これは、従来技術のシステムに対する有意義な利点を表わすことができる。従来技術のシステムでは、ファイル内のデータは、全てローカルに格納するか、あるいは全てリモートに格納するかのいずれかであった。データの一部分をローカルに、そしてデータの一部分をリモートに格納するという概念はなかった。ＮＴＦＳファイル・システムの多数のデータ属性を用いることにより、あるデータをローカルに格納し、他のデータをリモートに格納することが可能となる。したがって、あるファイルが、規則的にアクセスされるある種のデータ、および稀にしかアクセスされなかった他のデータを含む場合、稀にしかアクセスされなかったデータをリモート・ストレージに移動させることができ、一方頻繁にアクセスされたデータをローカル・ストレージに維持することができる。

１つ以上のデータ属性に加えて、ファイルは、他の属性９２で示すように、他のユーザ定義属性も有することができる。このような属性は、ユーザが定義し、ファイルと共に格納するその他のあらゆる属性を表わす。このようなユーザ定義属性は、ユーザが所望するあらゆる目的のために作成し用いることが可能である。

これまでの説明は、特定のファイル形式に関して多少詳細に入り込んだものであったが、これは例示に過ぎず、本発明の範囲を限定するものと解釈すべきではない。本発明は、既存のファイルの属性にリモート・ストレージ属性を追加したあらゆる形式のファイルまたはその他のエンティティとでも作用する。代替物では、既存のシステム属性を共に選択(co-opt)即ち利用することにより、リモート格納情報を格納し、したがって、ファイル内の既存のシステム属性数を増大させることなく、リモート・ストレージ属性を含ませる方法を同等に備えることも可能な場合もあり得る。

次に図５に移り、本発明の一実施形態の全体的な構造を示す。図５は、Ｉ／Ｏ処理を実行するためのドライバ手段を複数個利用するＩ／Ｏシステムを示す、上位概念図を表わす。クライアント・プロセス９４は、Ｉ／Ｏ要求を作成し、矢印９８で示すように、オペレーティング・システム・サービス９６に最終的に送出する。図５に示すＩ／Ｏシステムは、複数のＩ／Ｏ処理を実行するドライバ手段を備えている。一例として、限定ではなく、図５では、このような手段は、層１ドライバ１００、層２ドライバ１０２、および層Ｎドライバ１０４で示してある。

このようなＩ／Ｏ要求はドライバ間でやりとりされるので、本発明の範囲内の実施形態は、ドライバ手段間でＩ／Ｏ要求を受け渡す手段を備えることができる。一例として、図５では、１つのドライバから他のドライバに直接受け渡すＩ／Ｏ要求を示す矢印１０６および１０８によって、このような手段を示している。このような手段は、ドライバ間のＩ／Ｏ要求の転送を扱うＩ／Ｏマネージャを備えることも可能である。このようなＩ／Ｏマネージャは、図５のＩ／Ｏマネージャ１１０とすることができる。

図５において、Ｉ／Ｏマネージャ１１０は、クライアント・プロセッサ９４から受け取ったＩ／Ｏ要求を層１ドライバ１００に送出する。このようなＩ／Ｏ要求は、Ｉ／Ｏマネージャがコールした関数またはサービスの形態、あるいは、適切な情報を適切なドライバに転送する他のあらゆる機構とすることができる。例えば、Microsoft Windows NT (R)では、メッセージ・ドリブン機構(message driven mechanism)を用いてＩ／Ｏシステムの種々のドライバ間で通信を行う。このシステムでは、Ｉ／Ｏ要求の結果、Ｉ／ＯマネージャがＩ／Ｏ要求パケット（ＩＲＰ：I/O Request Packet）を作成し、ＩＲＰを適切なドライバに送る。Ｉ／Ｏ要求を処理し別のドライバに送出する際、ＩＲＰに情報を添付し、ＩＲＰを次のドライバに渡す。加えて、新たなＩＲＰを作成し次のドライバに送ることも可能である。状況によっては、ＩＲＰを次のドライバに渡す前に、修正するまたは「変身させる」(transmogrify)ことも可能である。Microsoft Windows NT (R)では、Ｉ／Ｏマネージャがドライバ間でＩＲＰを転送する責務を負う。他のシステムでは、他の機構を用いることができる。このような実施の詳細は、設計上の選択事項であり、本発明には重要ではない。

ここで図５に戻り、Ｉ／Ｏ要求は、矢印１０６で示すように、種々のドライバを通過し、各ドライバはあらゆる要求された処理を実行してから、Ｉ／Ｏ要求を次のドライバに送出する。尚、図５は各ドライバがＩ／Ｏ要求を順番に受け取ることを示すが、実施形態によっては、あるドライバを飛ばし、Ｉ／Ｏ要求を処理する必要のあるドライバのみが実際にＩ／Ｏ要求を扱うようにすることが望ましい場合もあり得る。

本発明の一実施形態では、複数のドライバを用いてＩ／Ｏ処理を実行する場合、リモート・ストレージ属性を有するファイルに遭遇した場合、通常の処理シーケンスを中断する機構が存在する。この場合、制御を他のドライバに渡し、どのようにＩ／Ｏ要求を処理すべきかについて判断を下す。したがって、本発明の範囲内の実施形態は、Ｉ／Ｏ要求の処理を中断する手段を備えることができる。図５では、このような手段は、例えば、層Ｎドライバ１０４に組み込むことができる。本発明のこの実施形態では、リモート格納属性を有するファイルに遭遇した場合、通常の処理シーケンスを中断する。このようなファイルは、例えば、リモート・ストレージ属性の存在によって、あるいはリモート・ストレージ属性および／または先に説明した他の属性の検査によって識別することができる。

リモート格納属性を有するファイルを認識した場合、Ｉ／Ｏ要求の通常の処理シーケンスを保留とし、Ｉ／Ｏ要求の処理を完了するステップを行う。これらのステップは、Ｉ／Ｏ要求を処理する制御を別のドライバに転送し、リモート格納属性を有するファイルに対するＩ／Ｏ要求の処理にこのドライバを参加させることを伴う。したがって、本発明の範囲内の実施形態は、Ｉ／Ｏ要求を処理する制御をドライバ間で転送する手段を備えることができる。Ｉ／Ｏ要求の処理を途中で中断する場合、Ｉ／Ｏ要求を処理するドライバから別のドライバに制御を移管するいずれの機構でも利用可能である。例えば、図５では、このような機構は矢印１１２で示している。これは、Ｉ／Ｏ要求の処理中にリモート格納属性を有するファイルに遭遇した際に、層Ｎドライバ１０４から層１ドライバ１００にＩ／Ｏ要求を処理する制御を移管することを示す。以下で更に詳しく説明するが、制御をドライバ間で移管する機構は、制御を引き受けるドライバが適正にＩ／Ｏ要求を処理することができるように、ある情報を転送しなければならない場合もあり得る。したがって、本発明の範囲内の実施形態は、リモート格納情報をドライバに渡す手段も備えることができる。

一旦層Ｎドライバ１０４から層１ドライバ１００に制御を移管したなら、層１ドライバ１００は適正にＩ／Ｏ要求を処理しなければならない。ある状況および実施形態では、制御を引き受けたドライバは、制御を移管したときに供給した情報によって、またはローカル・ストレージから追加情報を得ることによって、Ｉ／Ｏ要求を完全に処理できる場合もある。ドライバが追加情報を検索することなくＩ／Ｏ要求を処理することができる場合、矢印１０８および１１４で示すように、結果をクライアント・プロセッサに戻せばよい。

ローカル・ストレージからまたはリモート・ストレージからの追加情報の検索なしではＩ／Ｏ要求を完全に処理することができない場合、ドライバは１つ以上の追加Ｉ／Ｏ要求を作成し、適切な情報を検索することが必要になる場合もある。したがって、本発明の範囲内の実施形態は、第２のＩ／Ｏ要求を作成する手段を含むことができる。図５では、このような作成手段は、ドライバを介してＩ／Ｏ要求を返送し、ローカル・ストレージ１１８から情報を得ることを表わす矢印１１６、またはリモート・ストレージ１２２から情報を検索するために送る要求を示す矢印１２０で表わしている。

第２のＩ／Ｏ要求を作成するためには、所望の情報を検索するために必要なあらゆる機構を利用することができる。例えば、Microsoft Windows NT (R)では、このような手段は、新たなＩＲＰを作成するか、または既存のＩＲＰを変身させ、このＩＲＰを適切なドライバに渡すことによって、実施することができる。以下で更に詳細に説明するが、ローカル・ストレージまたはリモート・ストレージから情報を検索する場合、他のコンピュータ・システムが処理を要求する場合もあり得る。したがって、第２のＩ／Ｏ要求を作成するためのこのような手段は、Ｉ／Ｏ要求を他のコンピュータにも転送する場合もある。しかしながら、いずれの場合でも、一旦適切な情報を検索すれば、矢印１０８および１１４で示すように、適切な応答をクライアント・プロセス９４に返送することができる。

要約すると、本発明のある実施形態は、Ｉ／Ｏ要求の通常処理シーケンスを中断し、階層ストレージ管理の責務を負うドライバに、リモート格納属性を有するファイルまたはその他のエンティティに関係するＩ／Ｏ要求の処理に介入および関与させるシステムおよび方法を提供する。図５は複数の層状ドライバを示すが、複数のドライバの機能性を１つ以上のモノリシック・ドライバに組み込んでもよいことは明白であろう。このようなシステムでは、ドライバ間通信の必要性が軽減する。しかしながら、層状ドライバを有するＩ／Ｏシステムの様々な利点は得られない。本発明を複数の層状ドライバに実施するかまたは数個の層状ドライバの機能性を組み込んだ１つ以上のモノリシック・ドライバに実施するかの選択は、設計上の選択事項であり、本発明には重要ではない。しかしながら、種々の機能エレメントが本質的に図示した態様で協働することが好ましい。言い換えると、１つ以上のリモート格納属性を有するファイルに遭遇した場合、このようなファイルに関係するＩ／Ｏ要求を処理する責務を負う処理ブロックに制御を渡す。適切な機能性については、既に説明した。

次に図６に移り、Ｉ／Ｏ処理を実行する複数のドライバ手段を備えたＩ／Ｏシステムの更に詳細な図を提示する。図６におけるＩ／Ｏシステムは、Microsoft Windows (R)が利用するようなＩ／Ｏシステムとすればよい。Ｉ／Ｏ要求を処理する複数のドライバ手段を使用するその他のオペレーティング・システムも、同様の構造を有する場合もあり得る。同様に、図６との関連で論ずる概念は、複数のドライバまたは単一のモノリシック・ドライバを用いるあらゆるＩ／Ｏシステムを用いても、適切な機能性を適切なドライバに組み込むまたは組み合わせることによって実施することができる。したがって、図６に示す構造の使用は、あらゆる観点においても本発明の限定と見なすべきではなく、可能な実現例の１つに過ぎないと見なすべきである。

図６に示す実施形態は、Ｉ／Ｏ処理を実行する複数のドライバ手段を備えている。既に説明したように、Ｉ／Ｏ処理およびＩ／Ｏ要求という用語は、広く解釈し、Ｉ／Ｏシステムが実行可能なあらゆる機能および動作を含むすることを意図している。一例として、限定ではなく、図６では、このようなドライバ手段は、全体的に１２４で示すドライバＡ、および全体的に１２６で示すドライバＢによって例示してある。また、本発明の範囲内の実施形態は、ドライバ手段間でＩ／Ｏ要求を受け渡す手段も備えることができる。一例として、図６では、このような手段はＩ／Ｏマネージャ１２８によって示している。Ｉ／Ｏマネージャ１２８は、例えば、Ｉ／Ｏシステムが用いる複数のドライバ間でＩ／Ｏ要求を移管する責務を負うＩ／Ｏマネージャを表わす。先に論じたように、実施形態によっては、Ｉ／Ｏマネージャを利用しない場合もあり、更に種々のドライバ間の直接通信に頼る場合もある。このような実施形態では、ドライバ間でＩ／Ｏ処理要求を受け渡す手段は、一方のドライバがＩ／Ｏ要求を直接別のドライバに渡すために用いる機構となる。１つ以上のドライバの機能性をモノリシック・ドライバに組み込んだ更に別の実施形態では、ドライバ間でＩ／Ｏ要求を受け渡しする手段を必要としない場合もあり、あるいは単にモノリシック・ドライバ自体の内部に位置する場合もある。

図６に示すように、ドライバＡ１２４およびドライバＢ１２６は、Ｉ／Ｏマネージャ１２８が種々の機能を行うためにアクセス可能な１組のサービスまたはルーチンを備えている。図６に示すルーチンは、Microsoft Windows NT (R)の下で動作するドライバが有することができる可能なルーチンの一部分を表わす。種々のルーチンに関する詳細は、Microsoft Press（マイクロソフト・プレス社）が発行したHelen Custer（ヘレン・カスター）によるInside the Windows NT file System（Windows NTファイル・システムの内側）の第８章に見ることができ、この言及により本願にも含まれるものとする。

ある種のルーチンは、ドライバＡ１２４およびドライバＢ１２６双方に同様の機能を実行する。ルーチンの正確な詳細は非常に異なる場合もあるが、ルーチンの総合的な目的は同一である。ドライバＡ１２４およびドライバＢ１２６双方に同様の機能を実行するルーチンは、初期化ルーチン１３０、開始Ｉ／Ｏルーチン１３２、割込サービス・ルーチン１３４、延期手順コール・ルーチン１３６、キャンセルＩ／Ｏルーチン１３８、およびアンロード・ルーチン１４０を含む。これらのルーチンは、Microsoft Windows NT (R)のようなオペレーティング・システムの下でのドライバの動作には重要であるが、これらは本発明の目的上は総じて重要ではない。しかしながら、これらのルーチンの機能について以下に手短かに纏めておく。

ドライバＡ１２４およびドライバＢ１２６双方は、初期化ルーチン１３０を有する。初期化ルーチンは各ドライバ毎に異なる場合もあるが、初期化ルーチンは、Ｉ／Ｏマネージャがドライバをオペレーティング・システムにロードするときに、Ｉ／Ｏマネージャが実行する。このルーチンは、Ｉ／Ｏマネージャにドライバを使用させかつアクセスさせるために必要なあらゆる初期化を実行する。開始Ｉ／Ｏルーチン１３２は、デバイスへのデータ転送またはデバイスからのデータ転送を起動するために用いる。割込サービス・ルーチン１３４は、デバイスが特定のドライバに割込を送る際にコールする。Windows NT (R)の下では、割込サービス・ルーチンにおける処理は、絶対少数に維持し、下位の割込を不必要に阻害することを回避している。延期手順コール・ルーチン１３６は、割込サービス・ルーチンを実行した後に、デバイスの割込を処理する際に必要な処理の殆どを実行する。キャンセルＩ／Ｏルーチン１３８は、Ｉ／Ｏ動作を取り消す場合にコールする。アンロード・ルーチン１４０は、Ｉ／Ｏマネージャがドライブをメモリから除去することができるように、システム資源を解放する。

Microsoft Windows NT (R)の下にあるドライバは、ドライバＡ１２４のディスパッチ・ルーチン１４２やドライバＢ１２６のディスパッチ・ルーチン１４４のような、１組のディスパッチ・ルーチンを含む。ディスパッチ・ルーチンは、デバイス・ドライバが備える主要な機能である。その例には、読み出しまたは書き込み機能およびその他のあらゆるデバイスの機能(capability)、ファイル・システム、またはドライバが対応するネットワークがある。ドライバＡ１２４を用いてリモート格納機能を実行する場合、ディスパッチ・ルーチン１４２は、適切な機能性を発揮する(expose)ルーチンを含む。Ｉ／Ｏ動作をドライバによって処理する場合、Ｉ／Ｏマネージャ１２８はＩ／Ｏ要求パケット（ＩＲＰ）を発生し、ドライバのディスパッチ・ルーチンの１つを通じて、ドライバをコールする。このように、図６では、Ｉ／Ｏ要求は、ドライバ間またはＩ／Ｏマネージャとドライバとの間で受け渡しされるＩＲＰによって表わすことができる。

多数のドライバが協働して種々の機能を実行する場合、１つのドライバが、Ｉ／Ｏ要求を後続のドライバに受け渡す前に、このＩ／Ｏ要求の部分的な処理を実行することも可能である。このような処理は、図６において、ＩＲＰ１４６をドライバＡ１２４に渡し、ＩＲＰ処理ブロック１４８で示すようにドライバＡ１２４によって部分的に処理し、更にＩＲＰ１５０を介してドライバＢ１２６に渡すことによって示している。ＩＲＰ１４６およびＩＲＰ１５０は、同じＩＲＰであることに注意されたい。しかしながら、ＩＲＰがどのようにドライバ間を流れることができるのかを明確に確認するために、図６ではこれらに別個の番号を付してある。また、ＩＲＰ１４６およびＩＲＰ１５０とは異なるように、新たなＩＲＰを作成する実施形態を有することも可能な場合もある。

Ｉ／Ｏ要求がリモート格納属性を有するファイルまたはその他のエンティティに関係しない場合、ドライバは通常の方法でＩ／Ｏ要求を処理し、通常の方法でＩ／Ｏ要求に関連する情報を戻す。したがって、１つ以上の階層ストレージ・マネージャをインストールしているシステムは、リモート格納属性を有するファイルに関係するＩ／Ｏ要求に遭遇する前に、階層ストレージ・マネージャからは殆どまたは全く処理オーバーヘッドを受けることはない。例えば、図６では、ドライバＢ１２６がＩＲＰ１５０を受け取った場合、ＩＲＰ処理ブロック１５２がこれを通常の方法で処理することができる。処理の結果は、ＩＲＰ１５４に戻すことができる。図６には示さないが、ＩＲＰ１５４は、ドライバＢ１２６による処理の後、ドライバＡ１２４に戻すことができる。これは、通常のＩ／Ｏ処理の全部分であり、先に言及によって本願にも含まれるものとした、Inside Windows NTに更に詳細に説明されている。

図５との関連で既に説明したように、複数のドライバ手段を利用して本発明の機能性を実施する実施形態では、リモート格納属性を有するファイルに関係するＩ／Ｏ要求に遭遇した場合、Ｉ／Ｏ要求の正常な処理を中断し、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を扱うように特定して適合化したドライバに制御を移管する。このプロセスを遂行するために、本発明の範囲内の実施形態は、Ｉ／Ｏ要求の処理を中断する手段を備えている。このような手段は、Ｉ／Ｏ要求がリモート格納属性を有するファイルに関係し、Ｉ／Ｏ要求の処理を途中で終了し制御を他のドライバに移管できるようにすることをドライバが認識する機構であれば、そのいずれでもよい。図６では、このような手段は、例えば、リモート格納検出ブロック１５６で示している。

リモート格納属性を有するファイルの検出は、種々の方法で実施することができる。これらの殆どについては、リモート・ストレージ属性の可能な１実現例との関連で既に論じてある。リモート・ストレージ属性の正確な内容および個々の実現例によっては、リモート・ストレージ属性の内容を単に検査することによって、リモート格納属性を有するファイルを識別することが可能なこともあり得る。既に論じたように、このようなリモート・ストレージ属性は、当該リモート・ストレージ属性がリモート格納属性に関する情報を含むときを特定する、フラグまたはその他の手段を備えることができる。あるいは、単にファイル自体の中の情報を検査することによって、リモート格納属性を有するファイルを識別することが可能な場合もあり得る。例えば、１つ以上の属性の予想長を、ローカル・ストレージ上に格納してある属性の実際の長さと比較することにより、リモート格納属性を有するファイルを識別することが可能な場合もある。更に第３の代替物では、リモート格納属性を有するファイルの識別は、ある実施形態では、リモート・ストレージ属性に格納してある情報およびファイルに格納してあるその他の情報双方を検査することによって遂行することも可能である。一旦リモート・ストレージ属性の正確な実現例およびファイル構造を識別したなら、リモート格納属性を有するファイルを検出するために使用可能な種々の選択肢は明らかとなろう。

リモート格納検出ブロック１５６が、あるＩ／Ｏ要求がリモート格納属性を有するファイルに関係することを確認した場合、Ｉ／Ｏ要求の通常の処理を終了し、Ｉ／Ｏ要求を処理する責務を他のドライバに移管するためのステップを実行する。図６では、これらのステップはリモート格納処理ブロック１５８によって実行する。

リモート格納処理ブロック１５８は、現ドライバから、Ｉ／Ｏ要求を処理する責務を引き受けるドライバに制御を移管するのに必要なあらゆる事前処理を実行する。例えば、リモート・ストレージ属性が既に論じたようにタグおよびデータ・フィールドを含む場合、リモート格納処理ブロック１５８は、リモート・ストレージ属性からタグおよびデータ・フィールドを抽出し、リモート・ストレージ属性のオーナへの移管のためにこれらを準備する。このように、本発明の範囲内の実施形態は、リモート格納情報をドライバに渡す手段を備えることができる。一例として、限定ではなく、図６ではリモート格納データ１６０によってこのような手段を示している。リモート格納データ１６０は、単に、リモート格納処理ブロック１５８が抽出したリモート格納情報を表わす。実施形態によっては、リモート・ストレージ属性からリモート格納情報を抽出し、図６に示すようにそれをＩ／Ｏマネージャ１２８を介して渡すのではなく、これを直接リモート・ストレージ属性のオーナに渡すことができる場合もある。本質的に、リモート格納情報のオーナに、リモート・ストレージ属性内に格納してある情報にアクセスさせる機構であれば、そのいずれでも、リモート格納情報をドライバに渡す手段として利用することができる。これは、リモート格納情報を格納してある場所またはリモート・ストレージ属性自体にポインタを渡すことを含む。一実施形態では、リモート格納データ１６０は、ＩＲＰに含まれており、別のドライバに渡される。

リモート格納属性を有するファイルに関係するＩ／Ｏ要求を識別した場合、このＩ／Ｏ要求を処理する責務をドライバ間で移管する。したがって、本発明の範囲内の実施形態は、Ｉ／Ｏ要求を処理する制御をドライバ間で移管する手段を備えている。図６に示す実施形態では、このような手段は、例えば、完了ルーチン１６２を備えることができる。Windows NT (R)オペレーティング・システムのために書かれたドライバは、下位ドライバがＩＲＰを処理し終えた後に、Ｉ／Ｏマネージャがコールする１つ以上の完了ルーチンを備えることができる。例えば、ファイル・システム・ドライバおよびデバイス・ドライバを有する実施形態では、Ｉ／Ｏマネージャは、デバイス・ドライバがデータをファイルにまたはファイルから転送し終えた後に、ファイル・システム・ドライバの完了ルーチンをコールすることができる。完了ルーチンは、動作の成功、失敗、または取消についてファイル・システム・ドライバに通知することができ、ファイル・システムにクリーンアップ動作(cleanup operation)を実行させる。このように、通常の処理の間、ドライバＢ１２６がＩＲＰ１５０を受け取り、完全にこれを処理し、ＩＲＰ１５４を戻した場合、Ｉ／Ｏマネージャ１２８はブロック１６２における完了ルーチンをコールすることができ、これがドライバＡ１２４にＩ／Ｏ動作の成功または失敗を通知し、ドライバＡ１２４にあらゆるクリーンアップ処理を実行させる。

Ｉ／Ｏマネージャ１２８は、下位ドライバがその処理を完了したときに完了ルーチンをコールするので、このような完了ルーチンは、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を処理する制御の移管を検出する機構を配置する理想的な場所を形成する。したがって、完了ルーチン１６２は、リモート格納データ１６０を検査し、ドライバＡ１２４がリモート・ストレージ属性のオーナであり、Ｉ／Ｏ要求を処理する責務を引き受けなければならないか否か確認することができる。

しかしながら、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を処理する責務をドライバが引き受ける前に、当該ドライバは、自分がリモート・ストレージ属性のオーナであるか否かについて確認しなければならない。これまでの説明によって、複数の階層ストレージ・マネージャまたはその他の特殊化ドライバを特定のシステム内に組み込み可能であることは明白であろう。したがって、ドライバの各々は、何らかの形式の特殊化処理を実行するように適合化することができる。前述のようなリモート・ストレージ属性を用いて、ドライバの各々に一意のタグ値を割り当てる。下位ドライバがリモート・ストレージ属性を有するファイルに遭遇した場合、下位ドライバは、タグおよびリモート・ストレージ属性の値を抽出し、これを上位のドライバまで受け戻す。すると、上位のドライバの各々は、タグ値を検査し、それ自体がリモート・ストレージ属性のオーナであり、Ｉ／Ｏ要求を処理する責務を引き受けなければならないか否か確認する。このように、個々のシステム内に異なるドライバ記憶マネージャが存在し、協働して、記憶の階層的管理を達成することができる。リモート格納または他の形式の特殊化処理のいずれかに使用可能な、これらの原理を採用し一般化した機構が、"FILE SYSTEM PRIMITIVE ALLOWING REPROCESSING OF I/O REQUESTS BY MULTIPLE DRIVERS IN A LAYERED DRIVER I/O SYSTEM"（層状ドライバＩ／Ｏシステムにおける多数のドライバによってＩ／Ｏ要求の再処理を可能にするファイル・システム・プリミティブ）と題する、同時係属中の米国特許出願番号第０８／８６２，０２５号に開示されており（以下「再解析点」出願）、この言及により本願にも含まれるものとする。

多層環境では、本発明の範囲内の実施形態は、特定のドライバが受け取ったリモート格納情報が、当該ドライバが所有するものであるか否かについて確認する手段を備えることができる。一例として、限定ではなく、図６ではリモート格納検出ブロック１６４によってこのような手段を示している。リモート格納検出ブロック１６４は、リモート格納データ１６０を検査し、ドライバＡ１２４がリモート格納情報のオーナであるか否かについて確認する。ドライバＡ１２４がリモート格納情報のオーナでない場合、ドライバＡ１２４は、完了処理ブロック１６６によって示す、必要な通常の完了処理を全て実行し、別のドライバに転送するためにリモート格納データ１６０をＩ／Ｏマネージャ１２８に渡すことができる。

一方、リモート格納検出ブロック１６４が、ドライバＡ１２４をリモート格納情報のオーナとして特定した場合、制御はリモート格納処理ブロック１６８に移り、Ｉ／Ｏ要求の処理を更に進める。Ｉ／Ｏ要求を処理する制御を引き受けること以外に、ドライバがそれ自体をリモート格納情報のオーナとして特定した場合に発生することは、本発明では定義しない。しかしながら、通常、ドライバはＩ／Ｏ要求を処理する責務を引き受け、更にＩ／Ｏ要求を完了するステップを実行する。例えば、リモート格納処理ブロック１６８は、Ｉ／Ｏ要求の完了のために更に図２または図３に関連して既に説明した機能のいずれでも実行することができる。これは、リモート格納処理ブロック１６８が、リモート格納データ１６０内で受け取った情報を用いてＩ／Ｏ要求を完全に処理し終えることができるという状況を含む。このような状況では、ドライバがＩ／Ｏ要求を処理し終えた後に、通常の完了手順が続く。Microsoft Windows NT (R)の場合、これは、ＩＲＰ内の必要なあらゆる情報をＩ／Ｏマネージャに返送し、更に転送することを含む。また、これは、いずれかの上位ドライバの完了ルーチンをコールし、必要なあらゆるクリーンアップ処理をそれらに実行させるか、あるいはＩ／Ｏ要求のステータスをそれらに知らせることも含む場合がある。

状況によっては、リモート格納情報のオーナであるドライバは、それ自体でＩ／Ｏ要求の残りを完全に処理できない場合もあり得る。このような状況では、リモート格納処理ブロック１６９はＩＲＰを発生し、これを他のドライバに渡すことによって、Ｉ／Ｏ要求を更に処理することを可能にする。あるいは、以下で図８との関連で論ずるように、Ｉ／Ｏ要求を発生し、他のコンピュータに渡して、更に処理を進めることも可能である。したがって、本発明の範囲以内の実施形態は、第２のＩ／Ｏ要求を作成し、元のＩ／Ｏ要求の処理を継続する手段を備えることができる。このような手段には、この特定の実施形態が利用して他のドライバまたはシステムのヘルプをリストに纏めＩ／Ｏ要求を完了する機構であれば、そのいずれでも利用することができる。例えば、図６では、第２のＩ／Ｏ要求を作成する手段は、リモート格納処理ブロック１６８およびＩＲＰ１７０によって示している。次いで、ＩＲＰ１７０は、例えば、ドライバＢ１２６のような他のドライバ、または図６に示すようなリモート・ストレージ・ドライバに渡すことができる。ＩＲＰ１７０を受け取ったドライバは、次に、他のあらゆるＩＲＰと同様にこれを処理する。例えば、ＩＲＰ１７０をドライバＢ１２６に送り、元のＩ／Ｏ要求を完全に処理するために必要な情報を更にローカル・ストレージから検索することができる。あるいは、ＩＲＰ１７０は、リモート格納属性のリコール要求を発行する機構とすることも可能である。したがって、起動してリモート・ストレージから必要な情報をリコールするリモート・ストレージ・ドライバまたはその他のデバイスに、ＩＲＰ１７０を渡すことができる。

リモート格納処理ブロック１６８がＩＲＰ１７０を作成するとき、当該ＩＲＰを最初から作成することも、既存のＩＲＰを取り込み当該ＩＲＰを「変身させる」ことも可能である。変身のプロセスは、既存のＩＲＰを取り込み、ＩＲＰ内の情報を変更して修正ＩＲＰ即ち新たなＩＲＰを作成する。第２のＩ／Ｏ要求を作成する手段は、異なるシステムにおいて別個に実施することも可能である。例えば、１つのドライバが直接別のドライバをコールするシステムでは、第２のＩ／Ｏ要求を作成する手段は、情報を組み立て、直接コール機構を介してその他のドライバに渡す機構とすることができる。本質的に、第２のＩ／Ｏ要求を作成する手段を実施するために必要な全ては、Ｉ／Ｏ要求を作成または修正し、次いで更に処理するために他のドライバまたはエンティティに渡すことができる機能を有することである。

これより図７を参照し、これを用いて、多数のドライバがいかに協働して階層的記憶管理を実施することができるのかについて明確化するために、具体例を提示する。図７では、クライアント・プロセス１７２がＩ／Ｏ要求をＩ／Ｏシステムに作成する。Ｉ／Ｏシステムは、Ｉ／Ｏ処理を実行する複数のドライバ手段を備えている。クライアント・プロセス１７２は、矢印１７６で示すように、オペレーティング・システム・サービス１７４にコールを行う。Ｉ／Ｏマネージャ１７８は、Ｉ／Ｏ要求を受け取り、Ｉ／Ｏシステムの種々のドライバ手段間で、Ｉ／Ｏ要求の転送を調整する。

図７では、Ｉ／Ｏ処理を実行する複数のドライバ手段を示す。このようなドライバ手段は、階層ストレージ・マネージャ１８０、ファイル・システム・ドライバ１８２、ディスク・ドライバ１８４、およびリモート・ストレージ・ドライバ１８６を備えている。階層ストレージ・マネージャ１８０は、ファイルまたはその他のエンティティのリモート格納属性を管理する責務を負う。階層ストレージ・マネージャ１８０は、稀にしかアクセスされないファイルまたはその他のエンティティから属性を除去し、リモート・ストレージ１８８のような、リモート位置にこれらを格納する。また、階層ストレージ・マネージャ１８０は、必要に応じて、適切な属性のリコールを調整する。本質的に、階層ストレージ・マネージャ１８０は、図２および図３との関連で先に論じた上位機能性を組み込む。ファイル・システム・ドライバ１８２は、ファイルまたはディレクトリに対するアクセス要求を、ローカル・ストレージ１９０上の物理的な場所に変換する責務を負う。ディスク・ドライバ１８４は、ローカル・ストレージ１９０から情報を検索しかつローカル・ストレージ１９０に情報を入力する責務を負う。リモート・ストレージ・ドライバ１８６は、リモート・ストレージ１８８との双方向情報転送を調整および管理する責務を負う。リモート・ストレージ・ドライバ１８６は、多くの中間ドライバまたはシステムを介して動作し、リモート・ストレージ１８８に情報を格納したり、あるいはリモート・ストレージ１８８から情報を検索してもよいことを注記しておく。図７のＩ／Ｏシステムは、このように複数のドライバを用い、その各々が特定の機能または機能群を担当することにより、ロバストなＩ／Ｏ環境を備えている。

矢印１７６で示すように、クライアント・プロセス１７２がＩ／Ｏ要求を行うと、Ｉ／Ｏマネージャ１７８はＩＲＰ１９２を作成し、Ｉ／Ｏシステム内の種々のドライバ間でＩＲＰ１９２の転送を調整する。この例では、連続する各ドライバを介してＩＲＰ１９２を受け渡す。各ドライバは、ディスク・ドライバ１８４に到達するまで、下位ドライバの機能をイネーブルするために必要なあらゆる予備処理を実行する。次に、ディスク・ドライバ１８４は、ローカル・ストレージ１９０から所望の情報を検索し、このような情報をＩＲＰ１９４を介してファイル・システム・ドライバ１８２に戻す。Ｉ／Ｏ要求がリモート格納属性を有するファイルに関係する場合、ファイル・システム・ドライバ１８２は、ＩＲＰ１９４内において情報が戻されたときに、これを認識する。ファイル・システム・ドライバ１８２は、既に論じた種々の機構を用いて、個々のＩ／Ｏ動作が、リモート格納属性を有するファイルに関係するか否かについて検出することができる。図７では、リモート格納データ１９６のファイル・システム・ドライバ１８２への返送によって、これを具体的に示す。しかしながら、リモート格納データ１９６は、例えば、ＩＲＰ１９４のようなＩＲＰ内で戻してもよいことを思い出されたい。同様に、個々の実現例によっては、ＩＲＰ１９４はＩＲＰ１９２と同じＩＲＰとしてもよい場合もある。

ファイル・システム・ドライバ１８２が、Ｉ／Ｏ動作がリモート格納属性を有するファイルに関係することを認識した場合、ファイル・システム・ドライバ１８２は、最小限、リモート・ストレージ属性内の情報を抽出し、その情報を上位ドライバに渡すことによって、上位ドライバの１つがそれ自体をリモート・ストレージ属性のオーナであることを認識し、Ｉ／Ｏ要求を処理する責務を引き受けるようにする。図７では、これは、ファイル・システム・ドライバ１８２がリモート格納データ１９６を階層ストレージ・マネージャ１８０に渡すことによって示している。これは、図６との関連で既に説明したように、Ｉ／Ｏマネージャが階層ストレージ・マネージャ１８０の完了ルーチンにコールすることによって遂行することができる。他の機構も適宜用いることができる。

階層ストレージ・マネージャ１８０がリモート格納データ１９６を受け取った場合、階層ストレージ・マネージャ１８０はリモート・ストレージ属性においてその情報を検査し、それがリモート・ストレージ属性を所有し、Ｉ／Ｏ要求を処理する制御を引き受けるべきか否かについて確認する。この例では、階層ストレージ・マネージャ１８０は、それ自体をリモート・ストレージ属性のオーナとして認識し、Ｉ／Ｏ要求を処理する責務を引き受ける。

一旦階層ストレージ・マネージャ１８０がそれ自体をオーナとして認識し、Ｉ／Ｏ要求を処理する責務を引き受けたなら、階層ストレージ・マネージャ１８０は次にＩ／Ｏ要求の処理を更に進めるためにすべきことを確認する。一般に、３つの潜在的に可能な状況設定の１つを想定することができる。階層ストレージ・マネージャ１８０は、単にファイル・システム・ドライバ１８２から階層ストレージ・マネージャ１８０に渡された情報を用いることによって、Ｉ／Ｏ要求を完全に処理できる場合もある。このような情報は、リモート・ストレージ属性内の情報を含み得るだけでなく、他の属性からの他の情報も含み得ることを思い出されたい。ファイル・システム・ドライバ１８２から階層ストレージ・マネージャ１８０に渡される正確な情報は、個々の実現例によって異なる。階層ストレージ・マネージャ１８０が、それが有する情報によってＩ／Ｏ要求を完全に処理することができる場合、次にＩＲＰ１９８および矢印２００によって、適切な結果をクライアント・プロセス１８２に戻すことができる。

しかしながら、階層ストレージ・マネージャ１８０が、それが使用可能な情報のみを用いて、Ｉ／Ｏ要求を完全に処理することができない場合、階層ストレージ・マネージャ１８０は、Ｉ／Ｏ要求を処理するために必要な情報を検索するためのステップを実行することができる。Ｉ／Ｏ要求および正確な状況にしたがって、必要な情報は、ローカル・ストレージ、またはリモート・ストレージ、あるいは双方から検索しなければならない場合もある。ローカル・ストレージ１９０からの検索は、図７では、ファイル・システム・ドライバ１８２およびディスク・ドライバ１８４に渡すＩＲＰ２０２、および要求された情報を戻すために用いるＩＲＰ２０４で示す。リモート・ストレージ１８８からの検索は、図７では、リモート・ストレージ・ドライバ１８６に転送され、必要に応じてリモート・ストレージ１８８への情報転送またはリモート・ストレージ１８８からの情報転送を開始するＩＲＰ２０６、およびあらゆる適切な情報を階層ストレージ・マネージャ１８０に戻すＩＲＰ２０８で示す。階層ストレージ・マネージャ１８０がリモート・ストレージ１９０またはリモート・ストレージ１８８あるいは双方から適切な情報を検索した後、階層ストレージ・マネージャ１８０はＩ／Ｏ要求の処理を完了し、図示のように、ＩＲＰ１９８および矢印２００によって適切な応答を返すことができる。Ｉ／Ｏ要求を完了するためにローカル・ストレージ１９０またはリモート・ストレージ１８８に情報を書き込む必要がある場合、多少変更した形態で同じ状況設定を用いる。

次に図８を参照し、リモート格納属性を有するファイルに遭遇した場合に、特定の形式の階層ストレージ・マネージャが別個の計算機システムを利用してＩ／Ｏ要求を処理するという例を提示する。図８に示す実施形態では、クライアント・プロセス２１０は、ローカル・コンピュータ２１２上で実行している。ローカル・コンピュータ２１２は、コンピュータを相互接続するネットワーク手段を通じて、リモート・コンピュータ２１４に接続してある。図８では、このようなネットワーク手段は、ネットワーク・カード２１６および接続部２１８によって示している。ローカル・コンピュータ２１２のＩ／Ｏシステム２２０は、Ｉ／Ｏ処理を実行するための複数のドライバ手段を備えている。図８では、このようなドライバ手段は、例えば、暗号化ファイル・マネージャ２２２、ファイル・システム・ドライバ２２４、およびディスク・ドライバ２２６によって示している。また、Ｉ／Ｏシステム２２０は、オペレーティグ・システム・サービス２２８およびＩ／Ｏマネージャ２３０も備えている。図７におけると同様、クライアント・プロセス２１０は、オペレーティング・システム・サービス２２８にコールを行う。Ｉ／Ｏマネージャ２３０はＩ／Ｏ要求を受け取り、Ｉ／Ｏシステムの種々のドライバ手段間でのＩ／Ｏ要求の転送を調整する。あるいは、Ｉ／Ｏシステムの種々のドライバ手段は、Ｉ／Ｏマネージャや情報の転送を調整するその他のデバイスを用いずに、互いに直接通信することも可能である。

このシステムでは、ある種のファイル属性を暗号化してリモート・コンピュータ２１４に送り、アクセスを制限した安全な環境でこれらを格納する。したがって、暗号化しリモート・コンピュータ２１４に格納したファイルに関係するあらゆるＩ／Ｏ要求は、暗号化せずにローカルに格納した他のファイルとは別個に処理しなければならない。この例では、クライアント・プロセス２１０は、リモート・コンピュータ２１４上に格納してある暗号化ファイルに関係するＩ／Ｏ要求を行うと想定する。このような要求を行うには、例えば、矢印２３２で示すように、クライアント・プロセス２１０がオペレーティング・システム・サービス２２８をコールする。Ｉ／Ｏ要求をファイル・システム・ドライバ２２４に渡し、ディスク・ドライバ２２６を利用して適切な情報を検索する。ディスク・ドライバ２２６は、ディスク・コントローラ２３４を利用し、ローカル・ストレージ２３６から情報を検索する。暗号化ファイルにアクセスする試みが行われた場合、ファイル・システム・ドライバ２２４は、そのファイルがリモート格納属性であることを認める。次に、リモート・ストレージ属性内の情報を、暗号化ファイル・マネージャ２２２に渡し、暗号化ファイルを、リモート・コンピュータ２１４上に格納してあるものとして確認する。次に、暗号化ファイル・マネージャ２２２は、適切なファイルを検索するステップを実行する。

適切なファイルを検索するステップは、Ｉ／Ｏ要求をリモート・コンピュータ２１４に送ることに関係する場合がある。Ｉ／Ｏ要求を暗号化ファイル・マネージャ２２２からリモート・コンピュータ２１４に転送するあらゆる機構が利用可能である。図８では、このようなＩ／Ｏ要求は、リディレクタ(redirector)２３８およびネットワーク・トランスポート・ドライバ２４０を介して送ることができる。リディレクタ２３８は、ローカル・コンピュータ２１２がネットワークを通じて他の機械にある資源にアクセスするために必要な利器 (facility)を備える。ネットワーク・トランスポート・ドライバ２４０は、ネットワーク・カード２１６および接続部２１８を通じてローカル・コンピュータ２１２からリモート・コンピュータ２１４に情報を転送する機構を備える。他の機構も使用可能であり、図８に示すコンポーネントは、あらゆる観点においても例示と見なして当然である。このような機構は、一般に、専用リンク、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、電話回線、ワイヤレス接続等のような、あらゆる形式の接続を２つのコンピュータ間に含むことができる。これらの通信機構に対応するために、種々の形式のソフトウエア・ドライバまたはコンポーネントが必要となる場合もあり得る。

暗号化ファイル・マネージャ２２２からの要求は、リディレクタ２３８に送られ、リディレクタ２３８はネットワーク・トランスポート・ドライバ２４０を用いて、ネットワーク・カード２１６および接続部２１８を通じてＩ／Ｏ要求をリモート・コンピュータ２１４に転送する。この特定例では、Ｉ／Ｏ要求は、暗号化しリモート・コンピュータ２１４上に格納してある属性を検索するためのものとする。このようなＩ／Ｏ要求は、ネットワーク・カード２１６、ネットワーク・トランスポート・ドライバ２４２、およびサーバ・ファイル・システム２４４を通じて、リモート・コンピュータ２１４が受信する。サーバ・ファイル・システム２４４は、リディレクタ２３８と通信し、リモート・コンピュータ２１４に送られて来たあらゆるＩ／Ｏ要求を処理しこれを満たす。暗号化属性を検索するＩ／Ｏ要求を満たすために、サーバ・ファイル・システム２４４は、ファイル・システム・ドライバ２４６やディスク・コントローラ２４８のような、リモート・コンピュータ２１４のドライバおよびハードウエアを利用することができる。本例では、サーバ・ファイル・システム２４４は、ファイル・システム・ドライバ２４６を利用して、ディスク２５０から適切な暗号化属性を検索する。次に、暗号化ファイル・マネージャ２２２に暗号化属性を返す。暗号化ファイル・マネージャ２２２が暗号化属性を受け取ったなら、暗号化ファイル・マネージャ２２２は、情報を解読するステップを実行し、次いでその情報をクライアント・プロセス２１０に戻すことができる。

図５ないし図８に与えた例は、複数の異なるドライバを層状ドライバ・モデルで使用して階層ストレージ管理を実施した実施形態について説明した。このような層状ドライバ・モデルを用いて本発明を実施した場合、階層ストレージ・マネージャを作成するために必要なステップは、以下に示すように纏めることができる。

最初のステップは、具体的な階層ストレージ・マネージャを特定するタグを定義することである。前述のように、このタグは、所与のシステム上において既存のタグ全てと異なるようにする必要がある。先に言及して本願にも含まれるものとした同時係属中の再解析点特許出願は、本出願に開示されている機構と同様の一般的な機構を、あらゆる形式の特殊化したドライバ（階層ストレージ・マネージャを含む）が、どのようにしてＩ／Ｏ要求の処理に介入するために用いることができるかについて説明している。そこに記載されている機構も、タグ値を有する属性を用いていた。このようなシステムでは、多数のドライバが存在する場合があるので、階層ストレージ・マネージャに割り当てるタグは、システム内の既存のあらゆる他のタグとも異なるものでなければならない。既に説明したように、何らかの集中割り当て機構を用いてタグを予め関連付けることも可能であり、あるいはインストール時に動的に割り当てることも可能である。

次のステップは、リモート・ストレージを記述する情報を設計することである。この情報は、リモート・ストレージ属性に置き、階層ストレージ・マネージャが用いるものである。このような情報は、リモート・ストレージ内のデータの完全な識別を可能にしなければならない。既に説明したように、このデータは、システム内に存在する各階層ストレージ・マネージャ毎に専用(private)であるので、あらゆる情報を含むことができ、あるいは階層ストレージ・マネージャが所望するあらゆるフォーマットを有することができる。オペレーティング環境を破壊する階層ストレージ・マネージャについては、リモート・ストレージ属性は適切な痕跡を含み、階層ストレージ・マネージャが、データをローカル・ストレージまたはリモート・ストレージに保持していた間に、データに何らかの変更があったか否かについて認識できるようにすることも可能である。

次のステップは、リモート・ストレージ属性内に格納するデータを処理し、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を処理するために、層状階層ストレージ・マネージャを構築することである。一旦層状階層ストレージ・マネージャを作成しシステム内にインストールしたなら、階層ストレージ・マネージャは、図５ないし図８との関連で既に論じたように、リモート格納属性を有するファイルに関係するＩ／Ｏ要求を処理する。既に論じたように、Ｉ／Ｏ要求を処理する場合、階層ストレージ・マネージャは、元のＩ／Ｏ要求と共に到来した情報にアクセスし、当該Ｉ／Ｏ要求を処理するために取るべきアクションを決定することができる。追加の情報にアクセスすることなく解決するアクションもあるが、ローカル・ストレージから情報を読み出したり、ローカル・ストレージに情報を書き込む必要のあるアクションもあり、更に、リモート・ストレージから情報を読み出したり、リモート・ストレージに情報を書き込む必要のある更に別のアクションもある。

図５ないし図８に与えた例は、複数の異なるドライバを用いて階層的記憶管理を実施する実施形態を強調したが、これらのドライバのいずれの機能性も、組み合わせることにより一層高度な機能性を有する更に別のモノリシック・ドライバも得られることは明白であろう。このような事項は、設計上の選択事項であり、本発明の実現例には重要ではない。本発明は、階層ストレージ管理の既存のＩ／Ｏシステム内への密接な統合に関するものである。本発明の目標の１つは、Ｉ／Ｏシステム内に、種々の属性をリモートに格納するためにネーティブな支援を与えることである。これは、ファイル・システムに、リモート格納属性を有するファイルを検出し確認させることを含む。ここに記載した発明は非常に柔軟性があるので、ファイルまたはその他のエンティティの属性のいずれかまたは全てを、ローカルまたはリモートに格納することを可能にする。ローカル・ストレージ上に残す必要があるのは、どこにリモート格納属性が位置するかを階層ストレージ・マネージャに確認させるために十分な情報だけでよい。その結果、リモート格納情報の状態をファイル・システムの一体部分として追跡し保持することを可能にするＩ／Ｏシステムが得られた。

本発明は、その精神または本質的な特徴から逸脱することなく、他の特定形態にも具体化が可能である。記載した実施形態は、あらゆる観点においても、限定的ではなく、例示として見なすべきである。したがって、本発明の範囲は、前述の記載ではなく、添付の請求の範囲によって示すものとする。請求の範囲の均等の意味および範囲に該当する全ての変更は、その範囲内に含まれるものとする。

図１は、層状ドライバを用いたＩ／Ｏシステムを示す図である。 図２は、リモートに属性を格納するプロセスを示す図である。 図３は、リモートに格納してある属性に関係するＩ／Ｏ要求の処理を示す図である。 図４は、本発明と共に用いるのに適したファイルの属性を示す図である。 図５は、リモート・ストレージ属性に遭遇した場合の、ある層状ドライバから別の層状ドライバへの制御移管を示す図である。 図６は、２つの層状ドライバが提供するサービスを示し、本発明によるドライバへの全体的な機能性の組み込みを示す図である。 図７は、リモートに格納してあるデータに関係するＩ／Ｏ要求を処理するために、本発明をどのように利用することができるかについて示す一例である。 図８は、別のコンピュータを用いてＩ／Ｏ要求を完了する例を示す図である。

Claims (21)

1. ローカルおよびリモートの記憶媒体双方へのアクセスを有するＩ／Ｏシステムにおいて実行するＩ／Ｏ要求処理方法であって、前記Ｉ／Ｏシステムが、Ｉ／Ｏ処理を実行するための複数のドライバを有し、かつＩ／Ｏ要求の処理にファイルが関係し、該ファイルはファイルのコンポーネントとしての複数の属性を含み、前記Ｉ／Ｏ要求処理方法が、
   ファイルの前記複数の属性のうちのリモートに格納すべき少なくとも１つの属性を、前記複数のドライバの１つによって識別するステップと、
   前記少なくとも１つの属性を前記リモート記憶媒体に格納し、前記ファイルの前記複数の属性のうちの前記少なくとも１つの属性以外の属性を前記ローカル記憶媒体に格納するステップであって、前記少なくとも１つの属性が前記リモート記憶媒体に格納されていることを前記Ｉ／Ｏシステムに示すリモート・ストレージ属性が前記少なくとも１つの属性以外の属性に含まれる、前記のステップと、
   を備え、前記リモート・ストレージ属性が、
   前記複数のドライバのうちの特定のドライバを、前記ファイルに関係した前記Ｉ／Ｏ要求を処理する制御を引き受けることができるドライバとして特定するタグと、
   前記少なくとも１つの属性を格納してある、前記リモート記憶媒体内の場所を表わす情報と、
   を含むことを特徴とするＩ／Ｏ要求処理方法。
2. 請求項１記載の方法において、前記少なくとも１つの属性を格納することは、前記特定のドライバによって実行することを特徴とするＩ／Ｏ要求処理方法。
3. 請求項１記載の方法であって、更に、前記ファイルの属性をローカル記憶媒体から読み出したとき、前記少なくとも１つの属性がリモートに格納されていると判定するステップを含むことを特徴とするＩ／Ｏ要求処理方法。
4. 請求項１記載の方法において、前記少なくとも１つの属性を格納することは、前記特定のドライバによって実行し、かつ（１）リモートに格納すべき情報を抽出するステップと、（２）前記抽出した情報を、前記複数のドライバに含まれる他のドライバに送るステップと、を少なくとも含むことを特徴とするＩ／Ｏ要求処理方法。
5. ローカルおよびリモートの記憶媒体双方へのアクセスを有するＩ／Ｏシステムにおいて実行するＩ／Ｏ要求処理方法であって、前記Ｉ／Ｏシステムが、Ｉ／Ｏ処理を実行するための複数のドライバを有し、かつＩ／Ｏ要求の処理にファイルが関係し、該ファイルはファイルのコンポーネントとしての複数の属性を含み、前記Ｉ／Ｏ要求処理方法が、
   ファイルへのアクセスを要求するＩ／Ｏ要求を受け取るステップであって、前記ファイルの前記複数の属性のうちの少なくとも１つの属性が前記リモート記憶媒体に格納してあり、前記ファイルの前記複数の属性のうちの前記少なくとも１つの属性以外の属性が、前記ローカル記憶媒体上に格納してあるリモート・ストレージ属性を含む、ステップと、
   前記リモート記憶媒体に格納してある前記少なくとも１つの属性を前記ファイルが有することを確認するため、前記ローカル記憶媒体から前記リモート・ストレージ属性を読み出すステップであって、
   前記リモート・ストレージ属性に含まれるタグを読み出すステップであって、該タグが、前記Ｉ／Ｏ要求を処理する制御を引き受けることができる前記複数のドライバのうちの特定のドライバを特定する、前記のステップと、
   前記リモート・ストレージ属性に含まれる情報を読み出すステップであって、該情報が、前記少なくとも１つの属性を格納してある前記リモート記憶媒体内の場所を表わす、前記のステップと、
   を含む、前記のリモート・ストレージ属性を読み出すステップと、
   前記特定のドライバによって、前記リモート記憶媒体に格納してある前記少なくとも１つの属性へのアクセスなしで、現在入手可能な情報によって前記Ｉ／Ｏ要求を満たすことができるか否かについて判定を行うステップと、
   前記少なくとも１つの属性へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができる場合、前記ローカル記憶媒体内の必要なあらゆる情報にアクセスすることによって前記Ｉ／Ｏ要求を満たすステップと、
   前記少なくとも１つの属性へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができない場合、前記特定のドライバによって前記リモート記憶媒体内の前記少なくとも１つの属性にアクセスすることにより前記Ｉ／Ｏ要求を満たすステップと、
   を備えたＩ／Ｏ要求処理方法。
6. 請求項５記載の方法において、前記ローカル記憶媒体から前記リモート・ストレージ属性を読み出す前記ステップを、前記複数のドライバに含まれ、前記特定のドライバとは異なる他のドライバによって実行することを特徴とするＩ／Ｏ要求処理方法。
7. 請求項６記載の方法であって、更に、
   前記他のドライバによって前記タグを抽出するステップと、
   前記特定のドライバに制御を移管して、該特定のドライバが、前記Ｉ／Ｏ要求を処理する制御を引き受けることができるようにするステップと、
   を含むことを特徴とするＩ／Ｏ要求処理方法。
8. 請求項７記載の方法であって、前記特定のドライバは第１階層ストレージ・マネージャであり、前記複数のドライバは第２階層ストレージ・マネージャを含み、制御を移管する前記ステップは、
   前記タグを前記第２階層ストレージ・マネージャに渡し、前記第２階層ストレージ・マネージャが前記タグに応答しないステップと、次に、
   前記タグを前記特定のドライバに渡し、このとき前記タグに基づいて、前記特定のドライバがそれ自身を、前記Ｉ／Ｏ要求を処理する制御を引き受けることができるドライバとして認識するステップと、
   を含むことを特徴とするＩ／Ｏ要求処理方法。
9. Ｉ／Ｏシステムにおいて実行するＩ／Ｏ要求処理方法であって、前記Ｉ／ＯシステムがＩ／Ｏ処理を実行するための複数のドライバ手段を用い、前記Ｉ／Ｏ要求処理方法が、
   Ｉ／Ｏ処理を実行する第１ドライバ手段によって、Ｉ／Ｏ要求を受け取るステップであって、前記Ｉ／Ｏ要求の処理には、ファイルおよびディレクトリのうちの少なくとも１つが関係する、前記のステップと、
   前記第１ドライバ手段によって、前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート・ストレージ属性を含むことを判定することによって、前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート格納属性を有することを判定するステップであって、前記リモート・ストレージ属性が、ローカルに格納されており、前記リモート・ストレージ属性が、
   Ｉ／Ｏ処理を実行する第２ドライバ手段を、前記Ｉ／Ｏ要求を処理する制御を引き受けることができるドライバ手段として特定するタグと、
   前記リモート格納属性を格納したリモート記憶媒体内の場所を表わす場所情報と、
   を含む、前記のステップと、
   前記第１ドライバ手段によって、前記リモート・ストレージ属性から前記タグおよび前記場所情報を抽出するステップと、
   前記タグおよび前記場所情報を前記第２ドライバ手段に渡し、このとき前記第２ドライバ手段が、前記Ｉ／Ｏ要求を処理する制御を引き受けるステップと、
   を備えたＩ／Ｏ要求処理方法。
10. 請求項９記載の方法において、前記タグおよび前記場所情報を前記第２ドライバ手段に渡す前記ステップは、前記第２ドライバ手段が、前記タグに基づいてそれ自身を、前記Ｉ／Ｏ要求を処理する制御を引き受けることができる前記ドライバ手段として認識するステップを含むことを特徴とするＩ／Ｏ要求処理方法。
11. 請求項１０記載の方法において、前記第２ドライバ手段は、少なくとも以下のステップ、即ち、
    リモート格納属性へのアクセスなしで現在入手可能な情報によって前記Ｉ／Ｏ要求を満たすことができるか否かについて判定を行うステップと、
    前記リモート格納属性へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができる場合、ローカル記憶媒体内の必要なあらゆる情報にアクセスすることによって前記Ｉ／Ｏ要求を満たすステップと、
    前記リモート格納属性へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができない場合、前記リモート記憶媒体内の前記リモート格納属性にアクセスすることによって前記Ｉ／Ｏ要求を満たすステップと、
    を実行することにより前記Ｉ／Ｏ要求を処理することを特徴とするＩ／Ｏ要求処理方法。
12. コンピュータ実行可能命令を有するコンピュータ読取可能媒体であって、前記コンピュータ実行可能命令が、
    Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第１ドライバ手段であって、前記Ｉ／ＯシステムがＩ／Ｏ要求を受け取ったときに、ファイルおよびディレクトリのうちの少なくとも１つに関係したリモート・ストレージ属性を読み取る手段を備え、前記Ｉ／Ｏ要求の処理には前記ファイルおよび前記ディレクトリのうちの少なくとも１つが関係し、前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート格納属性を有し、前記リモート・ストレージ属性がローカルに格納され、前記リモート・ストレージ属性が、
    前記Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第２ドライバ手段を、前記Ｉ／Ｏ要求の制御を引き受けるドライバ手段として識別するタグと、
    前記リモート格納属性を格納したリモート記憶媒体内の場所を表わす場所情報と、
    を含む、前記の第１ドライバ手段と、
    前記Ｉ／Ｏ要求の制御を引き受けるように適合させた前記第２ドライバ手段と、
    前記読み取る手段が前記リモート・ストレージ属性を読み取ったことに応答して、前記第１ドライバ手段が実行しているＩ／Ｏ処理を中断する手段と、
    前記Ｉ／Ｏ要求を処理する制御を、前記第１ドライバ手段から前記第２ドライバ手段に移管して、前記タグに応答して前記Ｉ／Ｏ要求の処理の制御を前記第２ドライバ手段が引き受けるようにする手段と、
    を備えることを特徴とするコンピュータ読取可能媒体。
13. 請求項１２記載のコンピュータ実行可能命令を有するコンピュータ読取可能媒体において、前記第１ドライバ手段は、前記場所情報を前記第２ドライバ手段に渡す手段を備えることを特徴とするコンピュータ読取可能媒体。
14. 請求項１２記載のコンピュータ実行可能命令を有するコンピュータ読取可能媒体において、前記第２ドライバ手段は、前記タグに応答して、前記Ｉ／Ｏ要求を処理する制御を前記第２ドライバ手段それ自身が引き受けることができると判定する手段を備えることを特徴とするコンピュータ読取可能媒体。
15. 請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可能媒体において、
    前記第２ドライバ手段は、第１階層ストレージ・マネージャであり、第１指定値を有するタグを前記第１ドライバ手段が前記リモート・ストレージ属性から読み出したときに、前記第２ドライバ手段は前記Ｉ／Ｏ要求を処理する制御を引き受け、
    前記コンピュータ実行可能命令は、更に、第２指定値を有するタグを前記第１ドライバ手段が前記リモート・ストレージ属性から読み出したときに、前記Ｉ／Ｏ要求を処理する制御を引き受ける第２階層ストレージ・マネージャを備えること、
    を特徴とするコンピュータ読取可能媒体。
16. 請求項１記載の方法において、前記タグは、複数のドライバを、前記Ｉ／Ｏ要求を処理する制御を引き受けることができるドライバとして特定することを特徴とするＩ／Ｏ要求処理方法。
17. 請求項１記載の方法において、前記少なくとも１つの属性を前記リモート記憶媒体に格納することは、更に、前記少なくとも１つの属性にデジタル指紋およびサインのうちの１つを格納し、その後に、前記デジタル指紋またはサインを使用して、前記少なくとも１つの属性に対し、これが後の時点で検索されたとき変更がなされたかどうか検出すること、を含むことを特徴とするＩ／Ｏ要求処理方法。
18. 請求項９記載の方法において、前記第１ドライバ手段によって前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート格納属性を有することを判定するステップは、複数の属性のどれがリモートに格納されているかを、前記ファイルに関連した前記複数の属性の長さに少なくとも部分的に基づいて判定すること、を含むことを特徴とするＩ／Ｏ要求処理方法。
19. ローカルおよびリモートの記憶媒体双方へのアクセスを有するＩ／Ｏシステムであって、前記Ｉ／Ｏシステムが、Ｉ／Ｏ処理を実行するための複数の処理手段を有し、かつＩ／Ｏ要求の処理にファイルが関係し、該ファイルはファイルのコンポーネントとしての複数のカテゴリの情報を含み、前記Ｉ／Ｏシステムが、
    ファイルの前記複数のカテゴリの情報のうちのリモートに格納すべき少なくとも１つのカテゴリの情報を識別する前記複数の処理手段のうちの１つの処理手段と、
    前記少なくとも１つのカテゴリの情報を前記リモート記憶媒体に格納し、前記ファイルの前記複数のカテゴリの情報のうちの前記少なくとも１つのカテゴリの情報以外のカテゴリの情報を前記ローカル記憶媒体に格納する手段であって、前記少なくとも１つのカテゴリの情報が前記リモート記憶媒体に格納されていることを前記Ｉ／Ｏシステムに示すリモート・ストレージ情報が前記少なくとも１つのカテゴリの情報以外のカテゴリの情報に含まれる、前記の手段と、
    を備え、前記リモート・ストレージ情報が、
    前記複数の処理手段のうちの特定の処理手段を、前記ファイルに関係した前記Ｉ／Ｏ要求を処理する制御を引き受けることができる処理手段として特定するタグと、
    前記少なくとも１つのカテゴリの情報を格納してある、前記リモート記憶媒体内の場所を表わす場所情報と、
    を含むことを特徴とするＩ／Ｏシステム。
20. ローカルおよびリモートの記憶媒体双方へのアクセスを有するＩ／Ｏシステムであって、前記Ｉ／Ｏシステムが、Ｉ／Ｏ処理を実行するための複数の処理手段を有し、かつＩ／Ｏ要求の処理にファイルが関係し、該ファイルはファイルのコンポーネントとしての複数のカテゴリの情報を含み、前記Ｉ／Ｏシステムが、
    ファイルへのアクセスを要求するＩ／Ｏ要求を受け取る手段であって、前記ファイルの前記複数のカテゴリの情報のうちの少なくとも１つのカテゴリの情報が前記リモート記憶媒体に格納してあり、前記ファイルの前記複数のカテゴリの情報のうちの前記少なくとも１つのカテゴリの情報以外のカテゴリの情報が、前記ローカル記憶媒体上に格納してあるリモート・ストレージ情報を含む、前記の手段と、
    前記リモート記憶媒体に格納してある前記少なくとも１つのカテゴリの情報を前記ファイルが有することを確認するため、前記ローカル記憶媒体から前記リモート・ストレージ情報を読み出す手段であって、前記リモート・ストレージ情報が、
    前記Ｉ／Ｏ要求を処理する制御を引き受けることができる前記複数の処理手段のうちの特定の処理手段を特定するタグと、
    前記少なくとも１つのカテゴリの情報を格納してある前記リモート記憶媒体内の場所を表わす場所情報と、
    を含む、前記のリモート・ストレージ情報を読み出す手段と、
    前記リモート記憶媒体に格納してある前記少なくとも１つのカテゴリの情報へのアクセスなしで、現在入手可能な情報によって前記Ｉ／Ｏ要求を満たすことができるか否かについて判定を行う前記特定の処理手段と、
    前記少なくとも１つのカテゴリの情報へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができる場合、前記ローカル記憶媒体内の必要なあらゆる情報にアクセスすることによって前記Ｉ／Ｏ要求を満たす手段と、
    前記少なくとも１つのカテゴリの情報へのアクセスなしで前記Ｉ／Ｏ要求を満たすことができない場合、前記リモート記憶媒体内の前記少なくとも１つのカテゴリの情報にアクセスすることによって前記Ｉ／Ｏ要求を満たす前記特定の処理手段と、
    を備えたＩ／Ｏシステム。
21. Ｉ／Ｏ処理を実行する複数の処理手段を用いるＩ／Ｏシステムであって、
    ａ）Ｉ／Ｏ処理を実行する第１処理手段であって、該第１処理手段が、
    ｉ．Ｉ／Ｏ要求を受け取り、前記Ｉ／Ｏ要求の処理には、ファイルおよびディレクトリのうちの少なくとも１つが関係し、
    ｉｉ．前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート・ストレージ情報を含むことを判定することによって、前記ファイルおよび前記ディレクトリのうちの前記少なくとも１つがリモート格納情報を有することを判定し、前記リモート・ストレージ情報が、ローカルに格納されており、前記リモート・ストレージ情報が、
    Ｉ／Ｏ処理を実行する第２処理手段を、前記Ｉ／Ｏ要求を処理する制御を引き受けることができる処理手段として特定するタグと、
    前記リモート格納情報を格納したリモート記憶媒体内の場所を表わす場所情報と、
    を含み、
    ｉｉｉ．前記リモート・ストレージ情報から前記タグおよび前記場所情報を抽出する
    前記の第１処理手段と、
    ｂ）前記タグおよび前記場所情報を前記第１処理手段から受ける前記第２処理手段であって、このとき前記第２処理手段が、前記Ｉ／Ｏ要求を処理する制御を引き受ける、前記の第２処理手段と、
    を備えたＩ／Ｏシステム。
    

Images