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

Abstract

(57)【要約】 大量のデータを格納する全体的なコストを削減するために、第１ローカル・ディスク（１１８）からアーカイブ・オフライン・ストレージ（１２２）までの記憶デバイスの階層を用いるシステムを開発した。このような記憶デバイス（１１８，１２２）は、階層状に管理することができ、稀にしかアクセスされないデータをアーカイブ・ストレージ（１２２）に移動させることができる。本発明は、階層ストレージ・マネージャ（１１０）のＩ／Ｏシステムへの緊密な統合化に基づき、リモート格納属性（１１２）を識別し、他のあらゆる属性と丁度同じようにＩ／Ｏシステム内部で追跡することを可能にする。本発明の実現例は、層状ドライバ・モデル上で中継することができ、下位ドライバ（１０４）がリモート格納属性（１１２）を有するファイルの存在を検出し、次いでリモート格納属性（１１２）を有するファイルを伴うＩ／Ｏ要求を処理する制御を、上位ドライバ（１００）に移管する。次いで、上位ドライバ（１００）は、Ｉ／Ｏ要求の処理を終了する制御を引き受ける。

Description

【発明の詳細な説明】 リモート・ストレージに対してファイル・システム にネーティブな支援を与える ファイル・システム・プリミティブ 発明の背景 １．発明の分野 本発明は、ファイル・システムにおいてリモート・ストレージに対する支援を 与えるシステムおよび方法に関する。更に特定すれば、本発明は、ファイル・シ ステムがリモート・ストレージに対してネーティブな支援(native support)を与 えられるようにすることにより、一部分をリモートに格納してあるファイルまた はその他のエンティティにおいて、当該ファイル・システムが、ファイルまたは その他のエンティティを伴うＩ／Ｏ要求を本質的に識別しかつ処理することを可 能とするものである。２．従来の技術的現状 コンピュータのハードウエアおよびソフトウエアにおいては多くの発展がなさ れたが、一般的原理の一部は不変のままである。メモリやデータ・ストレージの コストは減少し続け、所与のサイズのデバイスの記憶容量は増大し続けているが 、データを格納するために用いる媒体や、データのアクセス性(accessibility) というようないくつかの要因によって、引き続きデータ格納コストには差がある 。例えば、一般的に、１データ・ワードをキャッシュ・メモリに格納する方がシ ステムＲＡＭに格納するよりも高価である。一方、システムＲＡＭは、磁気ディ スク・ストレージよりも１ワード当たりの格納は高価である。磁気ディスク・ス トレージは、アーカイブ・ストレージよりも１ワード当たりの格納は高価である 。このように、用いないデータまたは使用頻度の低いデータ程安価なストレージ に移動させようという考えに進みつつある。加えて、これまで以上に増大しつつ あるデ ータ量にアクセスする要望が、データを価格効率的に格納しながらも、同時に所 望のデータに対する適度なアクセス速度を得ようとする動機付けになっている。 従来技術におけるデータのリモート・ストレージの開発および実施は、別個の 非統合階層型記憶システムを有するメインフレーム計算機モデルに基づくもので ある。階層型記憶システムは、データセットと呼ぶ記憶単位の、記憶デバイスの 階層における配置を管理する。記憶デバイスの階層は、ハイエンド高スループッ ト磁気ディスク、通常のディスク群、ジュータボックス型光ディスク(jukeboxes of optical disks)、テープ・サイロ(tape silo)、オフ・ラインで格納するテ ープ群のように、広範囲のデバイスを含むことができる。種々のデータセットを どこに格納すべきか決定する場合、階層型記憶システムは、典型的に、格納のコ スト、検索時間、アクセス頻度等のような種々の検討項目間のバランスを取る。 ファイルは、典型的に、ユーザまたはその他のソフトウエア・エンティティが データを格納可能なデータ部分、名称部分、およびファイルへのアクセス制御と いうようなことに用いることができる種々のフラグのような、種々のコンポーネ ントを有する。従来技術のシステムでは、主ストレージから除去しリモート・ス トレージに移動させるファイルは、多くの場合「スタブ・ファイル」で置換する 。スタブ・ファイルとは、階層型記憶システムが、当該ファイル内のデータがど こに格納されているか判断可能にする情報を含むファイルである。しかしながら 、このような手法には、いくつかの問題がある。 スタブ・ファイルは、ファイルのデータ部分においてリモート格納ファイルの 位置を記述する情報を格納する。旧来のファイル・システムは、通常、ファイル ・システムがファイルのデータ部分の内容を判定できるように構成されていない 。したがって、従来技術のシステムは、非統合的な階層ストレージ・マネージャ を頼りに、スタブ・ファイルのデータ部分を読み出し、リモート格納ファイルが どこに位置するのか判断している。このような非統合的な手法では、階層型記憶 システムは、スタブ・ファイルと同じ外観を有するファイルに向けて送られるあ らゆるＩ／Ｏ動作を傍受することが必要となる。言い換えると、ファイルを見た だけでは、それがスタブ・ファイルか、または単にスタブ・ファイルと同じ外観 を偶然有するに過ぎない非スタブ・ファイルか判断することは不可能である。例 え ば、スタブ・ファイルは多くの場合固定長を有する。しかしながら、固定長以外 には、スタブ・ファイルを、スタブ・ファイルと同じ長さを偶然有する通常のフ ァイルから区別するものは、外部には何もない。全てのスタブ・ファイルを識別 するためには、典型的に、スタブ・ファイルと同じ長さを有するファイルに向け られる全てのコールを傍受するように、階層ストレージ・マネージャを設定する 。一旦コールを傍受したなら、次にファイルを検査し、これが本当にスタブ・フ ァイルなのか、または偶然長さが同じなだけの通常のファイルなのか判定するこ とができる。 以上の検討から、階層ストレージ・マネージャによって非スタブ・ファイルを 検査する可能性が確かにあることは明白である。この結果は望ましいものではな い。何故なら、通常のファイルへのアクセスが遅れ、不要な処理オーバーヘッド が余分に生ずるからである。従来技術のシステムには、異なる方法を用いて、同 じデータ・バイト数を有するが通常のデータ・ファイルであるユーザ・ファイル からスタブ・ファイルを差別化することによって、このオーバーヘッドを解消し ようとしたものがある。これら種々の手法は、エラーの確率を低下させることが できるが、完全にそれを解消することはできない。したがって、通常のデータ・ ファイルと、リモート格納データを有するデータ・ファイルとの間で明確に差別 化することが可能な階層ストレージ・マネージャを提供することができれば、当 技術分野における発展となろう。また、このようなリモート格納ファイルが実際 にＩ／Ｏシステムが処理するＩ／Ｏ動作に関与する場合にのみ、リモート格納フ ァイルに伴う余分なオーバーヘッドが発生する階層ストレージ・マネージャを有 することができれば、当技術分野における発展となろう。 従来技術の階層ストレージ・マネージャには、当該階層ストレージ・マネージ ャの非統合的本質により、既存のファイル・システムに殆どまたは全く影響を与 えることなく、システム内に階層型記憶を実施することができるという１つの利 点がある。このような階層ストレージ・マネージャは、各コールを検査して、そ れがスタブ・ファイルを伴うか否かについて判定を行うことができる。コールが スタブ・ファイルを伴う場合、階層ストレージ・マネージャはこのコールを傍受 し、このコールを処理することができる。しかしながら、このコールがスタブ・ ファイルを伴わない場合、階層ストレージ・マネージャはこのコールを正規のフ ァイル・システムに渡すことができる。したがって、ファイル・システムは、階 層ストレージ・マネージャが存在することを知る必要がない。残念なことに、こ のような手法では、コールがスタブ・ファイルを伴わない場合でも、コールが行 われる毎に余分なオーバーヘッドが生じてしまう。これは、階層ストレージ・マ ネージャが各コールを検査しなければならないからである。システムが多数の階 層ストレージ・マネージャを使用する場合、オーバーヘッドは急速に増加する虞 れがある。したがって、既存のファイル・システムに殆どまたは全く変更が生じ ないという利点を維持しつつ、同時にリモート格納データのないファイルに対す るあらゆるオーバーヘッドを極力抑えるかあるいは解消するような階層ストレー ジ・マネージャを提供することが望ましい。言い換えると、リモート格納データ のないファイルに対しては既存のアクセス速度を維持し、リモート格納データの あるファイルについてのみ追加のオーバーヘッドを発生する、階層型記憶の手法 を有することができれば非常に有利であろう。また、単一のシステムに複数の階 層ストレージ・マネージャを用いる場合においてもこれらの特性全てを維持する ことができれば、非常に有利であろう。 従来技術の階層ストレージ管理方法には、これらの基準となるモデルが新たな 記憶要件への組み込みや適応化に容易に対応できないという別の欠点がある。例 えば、従来技術のリモート・データ格納方法は、通常のファイルをスタブ・ファ イルと置換することを必要とした。このようなスタブ・ファイルは、事実上通常 のファイルの全コンポーネントをスタブ・ファイルのコンポーネントと置換する 。したがって、何らかの動作が通常のファイルを伴う場合、典型的に、要求を満 たすためにリモート・ストレージからこれを検索しなければならない。特定のフ ァイルに関連する情報の内どれがリモートに格納されているのか判定する際に高 い自由度を可能とし、実行する頻度が高いと考えられる動作は、リモート・スト レージからファイル全体を呼び出すことなく処理可能とすることができれば、非 常に有利であろう。 発明の概要 本発明は、従東の技術的現状における前述の問題を効果的に克服するものであ り、ファイル・システムにおいてリモート・データ格納に対するネーティブな支 援を与えつつ、同時にこのようなネーティブな機能を組み込むために既存のファ イル・システムに必要ないかなる変更も最小に抑えるシステムおよび方法に関す る。 本発明は、複数のドライバまたはデータ・マネージャが協働してＩ／Ｏ要求を 満たすモデルを基本とすることができる。ドライバまたはデータ・マネージャは 、層状関係を有することができ、各ドライバまたはデータ・マネージャがＩ／Ｏ 要求の特定部分を処理する任務を負う。全ての層が協働してＩ／Ｏ要求を完全に 満たすように、層間で情報を互いに受け渡すことができる。 本発明では、ファイルおよびディレクトリは、典型的に、２つの広いカテゴリ のコンポーネント即ち「属性」を有することを認識する。属性のカテゴリの一方 は、典型的に、ユーザ制御情報を格納するために用いる。このユーザ属性カテゴ リは、ファイルのデータ部分を含み、ユーザまたはその他のクライアント・プロ セスが所望の情報を格納するところである。属性の他のグループは、典型的に、 Ｉ／Ｏシステムによる主な使用または排他的な使用のために除外しておく。これ らのシステム属性は、アクセス制御情報を含む。これは、どのユーザまたはクラ イアント・プロセスが当該ファイルを、そしてどのように（例えば、リード・オ ンリ・アクセス、リード・ライト・アクセス等）アクセスすることができるのか 確認する。Ｉ／Ｏシステムによる主なアクセスまたは排他的なアクセスのために 確保してある他の属性には、ローカル記憶媒体上のどこに主データ属性を格納し てあるかファイル・システムに確認させる情報を含むことも可能である。本発明 は、リモート・ストレージ属性(remote storage attribute)と呼ぶ、追加のシス テム属性を加える。このリモート・ストレージ属性は、Ｉ／Ｏシステムが、リモ ートに格納してあるファイルまたはディレクトリの属性をどこで見つけることが できるのか確認させるのに十分な情報を収容する。 本発明の最も一般的な観点では、ファイル属性のいずれでもまたは全てをリモ ートに格納することが可能である。この柔軟度により、使用頻度の高い情報をロ ーカルに保持しておき、使用頻度の低い情報をリモートに格納することが可能と なる。ローカル／リモート格納の判断は、属性毎に下すことができる。しかしな がら、Ｉ／Ｏシステムに、どの属性をリモートに格納し、リモートに格納した属 性がどこに位置するのかを確認させるには、十分な情報をローカル・ストレージ に残しておかなければならない。 本発明の一実施形態では、前述の層状ドライバ・モデルを利用して本発明を実 施する。このような実現例は、例えば、ローカル記憶媒体上に格納してある情報 にアクセスすることができる１つ以上のファイル・システム・ドライバを備える ことができる。ファイル・システム・ドライバの内少なくとも１つは、ファイル のリモート・ストレージ属性が存在する場合、それを識別するように適合化して ある。したがって、このファイル・システム・ドライバは、リモート・ストレー ジ属性に格納してあるあらゆる情報を抽出し、その情報を階層ストレージ・マネ ージャに渡すことができる。すると、階層ストレージ・マネージャは、Ｉ／Ｏ要 求を完了する責務を引き受けることができる。場合によっては、階層ストレージ ・マネージャは、それ自体でＩ／Ｏ要求を完全に処理することが可能なこともあ り、あるいはリモート・ストレージ属性またはローカル記憶媒体に格納してある 情報を用いてＩ／Ｏ要求を処理することができることもある。このような場合、 階層ストレージ・マネージャは、リモートに格納してある属性をリコールする必 要がない。 階層ストレージ・マネージャが、リモートに格納してある属性をリコールせず にはＩ／Ｏ要求を処理することができない場合、階層ストレージ・マネージャは リコール情報を発生し、これを適切なドライバまたはコンポーネントに渡すこと によって、必要な情報をリコールすることができる。人の介入なく検索できるよ うに情報を格納してある場合、このようなリコール手順は、Ｉ／Ｏ要求をドライ バまたはその他のデータ・マネージャに発行することを伴う場合がある。その際 、ドライバまたはその他のデータ・マネージャはリコール手順を起動し、一旦デ ータを検索したなら、適切な情報を階層ストレージ・マネージャに渡す。代替案 として、階層ストレージ・マネージャは、オペレータまたはその他の個人に適切 な媒体を検索しロードするように警告することによって、情報にアクセスするこ とができる。本発明の構造全体は、広範囲にわたる記憶モデルおよび記憶階層に 対 応する高い柔軟性を提供する。 以上の要約から、多種多様の階層ストレージ・マネージャを実施し、既存のシ ステムに組み込むことができ、しかもリモートに格納した属性を有さないファイ ルまたはディレクトリにアクセスするＩ／Ｏ要求には全くオーバーヘッドの追加 を招かないことが明白であろう。その理由は、このようなＩ／Ｏ要求は、階層ス トレージ・マネージャを必要とすることなく処理するからである。ファイル・シ ステム・ドライバは、ファイルがリモート格納属性(remotely stored attribute )を必要とせず、従来通りにＩ／Ｏ要求を満たす(fill)ように進めることを絶対 的に判断することができる。しかしながら、リモートに格納してある属性を有す るファイルに遭遇した場合、ファイル・システム・ドライバは適切な情報を階層 ストレージ・マネージャに渡し、階層ストレージ・マネージャはこのＩ／Ｏ要求 を処理する責務を引き受ける。この実現例では、リモートに格納してあるデータ に対する対応は、通常ではＩ／Ｏ処理に関与しないソフトウエア・コンポーネン トに介入させＩ／Ｏ要求を処理するための制御を引き受けさせる機構による、通 常の処理シーケンスの割込と見なすことができる。 一実施形態では、リモート・ストレージ属性は、タグおよびデータ値双方を有 する。タグは、リモート・ストレージ属性の「オーナ」である階層ストレージ・ マネージャを特定するために用いる。通常、リモート・ストレージ属性のオーナ は、関連するファイルを伴うＩ／Ｏ要求の全てまたは一部を処理する責務を負う 。データ値は、リモート・ストレージ属性のオーナがその中に格納したデータを 収容する。オーナは、リモート・ストレージ属性の値を用いて、関連するファイ ルを伴うＩ／Ｏ要求を適正に完了するために必要なまたは役立つあらゆる情報を 格納することができる。例えば、殆どではないにしても多くの階層ストレージ・ マネージャは、このようなデータ値を用いて、リモートに格納してある属性の位 置を格納することが予期される。加えて、データ値は、どの属性をローカルに格 納し、どの属性をリモートに格納するのかを格納するためにも用いることができ る。 複数の層状ドライバを用いる際、ファイル・システム・ドライバがリモート・ ストレージ属性を識別する場合、ドライバは、リモート・ストレージ属性のタグ および値を抽出することができる。次いで、階層ストレージ・マネージャがそれ 自体をリモート・ストレージ属性のオーナであると認識するまで、このタグおよ び値を他の情報と共に、他の層状ドライバに渡すことができる。次に、リモート ・ストレージ属性のオーナは、Ｉ／Ｏ要求を処理する制御を引き受けることがで き、このＩ／Ｏ要求を完全に処理することができる。あるいは、他のドライバま たはコンポーネントを利用してＩ／Ｏ要求を完全に処理することも可能である。 このような実現例は、非常に柔軟なフレームワークをもたらし、多数の階層ス トレージ・マネージャが単一システム内に共存することを可能にする。この場合 、各階層ストレージ・マネージャは、それ自体の個々のリモート格納属性に関係 するＩ／Ｏ要求を処理する。このような実現例は、高度のオーバーヘッド分離を 達成するので、特定の形式のファイルを処理するためにシステムに追加の階層ス トレージ・マネージャを加入しても、リモート格納属性を有するファイルまたは ディレクトリに関係するＩ／Ｏ要求に伴うオーバーヘッドが大幅に追加されるこ とはない。 本発明の更に別の利点は、以下の説明に明記してあり、部分的にその説明から 自明であり、あるいは本発明の実施によって習得することができよう。本発明の 利点は、添付の請求の範囲に特定して指摘してある手段(instrument)および組み 合わせによって、実現し獲得することができる。本発明のこれらおよびその他の 特徴は、以下の説明および添付の請求の範囲から一層明白となり、以下に明記す る本発明の実施によって習得することができよう。 図面の簡単な説明 本発明の前述の利点およびその他の利点を得る態様について、添付図面に図示 した具体的な実施形態を参照しながら先に端的に記載した本発明を更に特定して 説明する。これらの図面は本発明の典型的な実施形態を図示するに過ぎず、した がってその範囲の限定と見なすべきでないことを理解の上、添付図面の使用によ り、更に具体的かつ詳細に本発明の記載および説明を行う。 図１は、層状ドライバを用いたＩ／Ｏシステムを示す図である。 図２は、リモートに属性を格納するプロセスを示す図である。 図３は、リモートに格納してある属性を伴うＩ／Ｏ要求の処理を示す図である 。 図４は、本発明と共に用いるのに適したファイルの属性を示す図である。 図５は、リモート・ストレージ属性に遭遇した場合の、ある層状ドライバから 別の層状ドライバへの制御移管を示す図である。 図６は、２つの層状ドライバが提供するサービスを示し、本発明によるドライ バへの全体的な機能性の組み込みを示す図である。 図７は、リモートに格納してあるデータを伴うＩ／Ｏ要求を処理するために、 本発明をどのように利用することができるかについて示す一例である。 図８は、別のコンピュータを用いてＩ／Ｏ要求を完了する例を示す図である。 好適な実施形態の詳細な説明 以下、本発明のシステムおよび方法を実施するために用いる実施形態の構造ま たは処理を例示する図を用いて、本発明の説明を行う。このように図を用いて本 発明を提示することは、その範囲の限定と見なすべきではない。本発明は、デー タのリモート格納を実施する方法およびシステム双方を、ファイル・システムの ネーティブ・コンポーネントとして考える。本発明の実施形態は、１つ以上の中 央演算装置（ＣＰＵ）またはコンピュータ実行可能命令を実行するその他の処理 手段、実行可能な命令を格納するコンピュータ読取可能媒体、ディスプレイある いは情報を表示または出力するその他の出力手段、キーボードあるいは情報を入 力するその他の入力手段等の標準的なコンピュータ・ハードウエアを備えた、特 殊目的用コンピュータまたは汎用コンピュータで構成することができる。 本発明は、記憶デバイスの階層がシステムに使用可能であることを想定する。 このような記憶デバイスの階層は、あらゆる数または形式の記憶媒体を備えるこ とができ、それらには、ハイエンド・高スループット磁気ディスク、１つ以上の 通常のディスク、光ディスク、光ディスクのジュークボックス、テープ・サイロ および／またはオフラインで格納するテープの集合体を含み、なおもこれらに限 定する訳ではない。一般的には、しかしながら、種々の記憶デバイスは２つの基 本的なカテゴリに分類することができる。第１のカテゴリは、コンピュータ・シ ステムにローカルに使用可能な情報を収容するローカル・ストレージ(local sto rage)である。第２のカテゴリは、コンピュータ・システムにローカルにアク セスすることができない情報を収容するあらゆる形式の記憶デバイスを含む、リ モート・ストレージ(remote storage)である。これら２つデバイス・カテゴリ間 の線は明確に定義することはできないが、一般的に、ローカル・ストレージは、 比較的アクセス時間が素早く、頻繁にアクセスするデータを格納するために用い る。一方リモート・ストレージは、アクセス時間がかなり長く、頻繁にはアクセ スしないデータを格納するために用いる。また、リモート・ストレージの容量は 、典型的に、ローカル・ストレージの容量よりも１桁大きい。 また、本発明の範囲内の実施形態は、実行可能な命令またはデータ・フィール ドを格納してある、コンピュータ読取可能媒体も含む。このようなコンピュータ 読取可能媒体は、汎用コンピュータまたは特殊目的用コンピュータによってアク セス可能なあらゆる入手可能な媒体とすることができる。限定ではない一例とし て、このようなコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、 ＣＤ−ＲＯＭまたはその他の光ディスク・ストレージ、磁気ディスク・ストレー ジまたはその他の磁気記憶デバイス、あるいは所望の実行可能命令またはデータ ・フィールドを格納するために使用することができ、かつ汎用コンピュータまた は特殊目的用コンピュータによってアクセス可能なその他のあらゆる媒体を含む ことができる。また、これらの組み合わせも、コンピュータ読取可能媒体の範囲 内に含まれて当然である。実行可能な命令は、例えば、汎用コンピュータ、特殊 目的用コンピュータ、または特殊目的処理装置にある種の機能または機能群を実 行させる命令およびデータから成る。 本発明の実施形態には、Ｉ／Ｏ処理を行うために複数のドライバ手段を用いる システムにおいて実施するとよいものがある。これらの実施形態の状況(context )を一層よく理解するために、図１を参照する。図１は、クライアント・プロセ スと、Ｉ／Ｏ処理を行うための複数のドライバ手段を用いるＩ／Ｏシステムを有 するオペレーティング・システムとの間の双方向処理の簡略化した図を示す。こ の 図１は、Ｉ／Ｏ処理を行うために複数のドライバ手段を用いるあらゆるオペレー ティング・システムを表わす図と考えることもできる。図１において、クライア ント・プロセス２０は、オペレーティング・システム・サービス２２を利用して Ｉ／Ｏ要求を行う。これを行うには、典型的に、オペレーティング・システムが 提供するアプリケーション・プログラム・インターフェース（ＡＰＩ）機能に対 して、クライアント・プロセス２０がコールする。適切なＡＰＩ機能をコールす ることにより、結果的にオペレーティング・システム・サービス２２へのコール が得られる。このようなコールを矢印２４で示す。 図１では、クライアント・プロセス２０は、「ユーザ」モードで動作するよう に示してあり、オペレーティング・システム・サービスは、「カーネル」モード で動作するように示してある。最近のオペレーティング・システムは、典型的に 、種々のアプリケーション・プログラムや直感的ユーザ・インターフェースにロ バストな環境を提供する。このようなオペレーティング・システムは、通常、当 該オペレーティング・システムの精巧さのレベルや、オペレーティング・システ ムが実施するセキュリティ機能(security feature)に応じて、異なるオペレーテ ィング・レベルまたは「モード」を有する。通常のアプリケーション・プログラ ムは、典型的には最も低い優先度で走り、セキュリティ・デバイスの完全な補体 (full complement)を適所に有し、他のアプリケーションまたはオペレーティン グ・システムのその他の層との干渉を禁止する。オペレーティング・システムが 提供するハードウエアおよびその他のサービスは、インターフェースまたは機構 を制御することによってのみアクセスされ、ユーザ・アプリケーションまたはそ の他のユーザ・モードのプロセスがシステムを「クラッシュ」する可能性を抑制 する。典型的に、最低優先度モードをユーザ・モードと呼び、これは殆どのコン ピュータ・ユーザが精通しているモードである。ドライバとそれらに関連するハ ードウエアの緊密な統合化のため、および多くのドライバが実行するタスタの時 間厳格性(time critical nature)のため、ドライバは典型的にオペレーティング ・システム・モードで走る。これは、優先度がかなり高く、セキュリティ保護は かなり低い。このモードを一般に「カーネル」モードと呼ぶ。ドライバおよび他 のオペレーティング・システム・サービスをカーネル・モードに置くことにより 、オペレーティング・システムはより高い優先度で走り、ユーザ・モードからで は不可能な多くの機能を実行することが可能となる。 クライアント・プロセス２０がオペレーティング・システム・サービス２２を コールしてＩ／Ｏ要求を実行する場合、Ｉ／Ｏ要求を第１ドライバ手段に渡し、 Ｉ／Ｏ処理を実行する。図１では、ファイル・システム・ドライバ２６およびデ バイス・ドライバ２８が、Ｉ／Ｏ処理を実行するドライバ手段の例を表わす。Ｉ ／Ｏ要求の第１ドライバ手段への受け渡しは、図１では、例えば矢印３０で示し てある。すると、ファイル・システム・ドライバ２６はＩ／Ｏ要求を取り込み、 次のドライバにＩ／Ｏ要求を渡す前に、このＩ／Ｏ要求の部分的処理を概略的に 実行する。 一例として、クライアント・プロセス２０がハードウエア・デバイス３６上で 特定のファイルを開いて、そのファイルから情報を検索または格納したいと仮定 する。Ｉ／Ｏ要求は、クライアント・プロセス２０からオペレーティング・シス テム・サービス２２に移り、次いでファイル・システム・ドライバ２６に達する 。次に、ファイル・システム・ドライバ２６は、Ｉ／Ｏ要求をファイル名からハ ードウエア・デバイス３６上の特定位置に変換する。この変換プロセスは、その 特定位置においてハードウエア・デバイスから読み取るべきまたはハードウエア ・デバイスに書き込むべきデータ・ブロックの数を含むとよい。この情報は、次 に、次のドライバ、例えば、デバイス・ドライバ２８に渡すことができる。デバ イス・ドライバ２８が要求する情報を受け渡すプロセスは、図１では矢印３２お よび３４で示している。デバイス・ドライバ２８は、読み出しまたは書き込みを 行う位置およびデータ・ブロック数を取り込み、これらを適切な制御信号に変換 し、所望の情報をハードウエア・デバイス３６から検索するか、あるいは所望の 情報をハードウエア・デバイス３６に格納する。検索したデータは、次に、デバ イス・ドライバ２８からファイル・システム・ドライバ２６に渡し、最終的には 、戻り矢印３８で示すように、クライアント・プロセス２０に戻すことができる 。ステータス情報も同様に戻すことができる。 図１において、Ｉ／Ｏ要求は、ファイル・システム・ドライバ２６とデバイス・ ドライバ２８との間で直接受け渡すことはしない。代わりに、Ｉ／Ｏ要求は、Ｉ ／Ｏマネージャ４０を介して、ドライバ間で受け渡しする。しかしながら、全て の実現例においてＩ／Ｏマネージャを有することが必要という訳ではない。Ｉ／ Ｏ要求を直接あるドライバから別のドライバに渡し、Ｉ／Ｏマネージャによって 転送を調整しなくてもよい実施形態も存在する。 次に図２を参照し、ファイルのある属性をリモートに格納し、ファイルの別の 属性をローカルに格納するプロセスを一般化した図を示す。図２に示すように、 全体的に４２で示すファイルは、システム属性４４およびユーザ属性４６で構成 することができる。以下で更に詳細に論ずるが、システム属性とは、オペレーテ ィング・システムおよびＩ／Ｏシステムが主にまたは排他的に用いて、当該オペ レーティング・システムおよびＩ／Ｏシステムがそれらの種々のタスクを実行可 能とするのに必要または有用な情報を格納するための属性である。システム属性 の一例は、ファイルまたはディレクトリに対するセキュリティ情報またはアクセ ス制御情報である。ユーザ属性とは、ユーザまたはその他のクライアント・プロ セスがそれ自体の目的のために用いる属性である。ファイルのデータ属性が、ユ ーザ属性のよい例である。システム属性およびユーザ属性については、以下で更 に詳しく論ずる。 リモート格納処理ブロック４８によってファイル４２を検査する。リモート格 納処理ブロック４８は、ファイル４２のどの属性をリモートに格納し、リモート に格納する属性をどこに格納するのかを決定する責務を担う。これらの決定を下 す際に、リモート格納処理ブロック４８は、多数のファクタを検討することがで きる。このようなファクタには、例えば、これまでに当該属性をアクセスした頻 度を含むことができる。一般に、長時間データがアクセスされないでいる場合、 近い将来においてそれにアクセスする可能性は低いという理論から、アクセス頻 度が非常に低いデータは、リモート・ストレージに移動させるとよい。リモート 格納処理ブロック４８が考慮するとよい別のファクタにサイズがある。ある属性 が費やすローカル記憶空間が非常に少ない場合、この属性をリモート・ストレー ジに移動させても、得るものは多くない。一方、大量のローカル記憶空間を費や す属性の場合、この属性をリモート・ストレージに移動させると、大量のローカ ル・ストレージが空くので、ローカル・ストレージの空間が貴重な場合、このよ うな移動は有効である。 どの属性をリモートに格納し、どこにその属性を格納するのかについて決定す る際に、多数の他のファクタも影響する場合がある。このようなファクタには、 例えば、リモート記憶媒体にアクセスする時間が含まれる場合がある。例えば、 属性をローカル・ストレージから光ジュークボックスに移動させる場合、アクセ ス時間が大幅に増大しないと思われる。恐らく、適正な光ディスクを選択し装填 して、そこから情報を検索するために必要な時間はさほど多くないであろう。一 方、属性をオフライン・テープ・ストレージに移動させた場合、オペレータの手 作業によって検索しロードしなければならないので、検索時間が多大となる可能 性がある。一般に、どの属性をリモートに格納し、このような属性をどこに格納 すべきかについて決定する場合、リモート格納処理ブロック４８は、ストレージ の総合的費用効率性や、異なるタラスのアプリケーションに対するＩ／Ｏの応答 時間のような異なるパラメータを最適化する。どの属性をリモートに格納し、こ のような属性をどこに格納すべきかについて選択するために利用する正確な方法 論は、本発明では規定しない。本発明を用いると、いかなるリモート格納の目標 を所望する場合でも、それを達成することができる。 本発明の範囲内の実施形態は、様々な方法で、リモート格納処理ブロック４８ と関連付けて記載する総合的な処理を実施することができる。以下で更に詳しく 説明するが、リモート格納処理ブロック４８の機能は、Ｉ／Ｏ処理を実行するド ライバ手段によって実施することができる。このようなドライバ手段は、Ｉ／Ｏ システム内の他のあらゆるドライバ手段からも分離することができる。代替案で は、リモート格納処理ブロック４８の機能は、Ｉ／Ｏシステム内で用いられる多 目的ドライバ手段または単一目的ドライバ手段に組み込むことも可能である。以 下の説明で一層明白になるであろうが、本発明にとって重要なのは、リモート格 納処理ブロック４８の機能をＩ／Ｏシステム内に組み込み、Ｉ／Ｏシステムがリ モート・ストレージに対するネーティブな支援に対処し、従来技術に記載したよ うな非統合コンポーネントに頼る必要性をなくすことが全てである。 リモート格納処理ブロック４８が、ファイル４２の属性のどれをリモートに格 納し、このような属性をどこに格納すべきか決定した後、リモート格納処理ブロ ック４８は、適切なフォーマットに属性を組み立て、これらの属性をリモート・ ストレージに転送するステップを開始する。図２では、この手順は、概略的に、 リモート格納属性５０、読み出し／書き込みデータ処理ブロック５２、およびリ モート・ストレージ５４によって示している。複数のリモート格納属性５０、読 み出し／書き込みデータ処理ブロック５２、およびリモート・ストレージ５４を 示すのは、特定のファイルからのリモート格納属性は、同じ場所に格納したり、 同じ形式のリモート記憶デバイスに格納することさえも不要であることを強調す るためである。図２では、５０で示す各ブロックが、リモートに格納する１つ以 上の属性を収容することができる。本発明の固有の柔軟性のために、リモート格 納処理ブロック４９は、属性１つ毎に決定を下すことができるので、個々の属性 を最も適切な場所に格納することが可能となる。このような柔軟性は、特定のフ ァイルの属性全てを同じ場所に格納可能であることを当然含むものである。 リモート格納属性５０、読み出し／書き込みデータ処理ブロック５２、および リモート・ストレージ５４は、特定のリモート記憶デバイスにアクセスするため に存在するいかなる機構を用いても、適切なデータを転送し、適切なリモート記 憶デバイス上に格納することを単に必要とする概念的なデータ・フロー経路を示 す。より詳細な例によって以下に例示するように、読み出し／書き込みデータ処 理ブロック５２は、対応するリモート記憶デバイスが、リモート格納処理ブロッ ク４８が位置するシステムによって直接アクセス可能である場合、Ｉ／Ｏ処理を 実行するためには単一のドライバ手段を用いて実施することができ、あるいはネ ットワークまたは多数のコンピュータ・システム間で通信するその他の手段を通 じた多数のコンピュータ上で走るＩ／Ｏ処理を実行するためには、数個のドライ バ手段とすることも可能である。必要なのは、適切なデータを適切なリモート記 憶デバイスに渡し、そこに格納するだけである。一般的に、読み出し／書き込み データ処理ブロック５２を実施するために用いる機構は、本発明を実施するため に用いる具体的な動作環境、ならびにリモート記憶デバイス５４とリモート格納 処理ブロック４８が位置するシステムとの間のデータ・フロー経路を備えるのに 必要な特定のハードウエアおよび／またはソフトウエアによって、かなり左右さ れる。 リモート格納処理ブロック４８が、どの属性をリモートに格納するか決定し、 リモート格納属性５０のように、適切なデータ・フォーマットの属性を組み立て た後、ファイル４２から属性を安全に除去することができる。実施形態によって は、リモート格納属性５０をリモート・ストレージ上に安全に格納するまで、こ れらをファイル４２から除去する前に待つ方が望ましい場合もある。リモート格 納属性５０の除去は、図２では、破線エリア５６および５８で示す。これらのエ リアは、システム属性およびユーザ属性双方共、本発明にしたがってリモートに 格納できることを示す。加えて、リモート格納処理ブロック４８は、リモート・ ストレージ属性６０をファイル４２のシステム属性に追加する。 リモート・ストレージ属性６０については以下で更に詳しく論ずるが、リモー ト・ストレージ属性６０は、通常、リモート格納処理ブロック４８が、リモート 格納属性５０がどこに位置するのか確認するために必要なあらゆる情報を格納す るために用いられる。加えて、リモート・ストレージ属性６０は、リモート格納 処理ブロック４８の個々の実施にしたがって、多種多様のその他の情報を収容す ることができる。例えば、リモート・ストレージ属性６０内でどの属性をリモー トに格納してあるかを格納することが望ましい場合がある。別の場合には、ファ イル４２は、どの属性をリモートに格納してあるかについてのアイデンティティ を、他の機構によって判定可能とするような構造である場合も恐らくあるであろ う。同様に、他の情報もリモート・ストレージ属性６０に格納することも可能で ある。例えば、リモート格納処理ブロック４８は、リモート・ストレージ５４内 に格納してあるデータの保全性(integrity)を全面的に信頼してはいない場合も 恐らくあるであろう。このような場合、リモート格納処理ブロック４８は、リモ ート格納属性上でディジタル指紋またはサインを計算し、この指紋またはサイン をリモート・ストレージ属性６０にセーブすることができる。この場合、リモー ト属性を検索すると、リモート属性に対して第２サインを計算し、計算したサイ ンを、リモート・ストレージ属性６０に格納してあるサインと比較することがで きる。このような手順により、リモート格納処理ブロック４８は、リモート格納 属性をリモート・ストレージ５４から検出する際に、それらに生じたあらゆる変 化を検出することが可能になる。 以上の説明から明らかなように、リモート格納処理ブロック４８が必要とする または所望するあらゆる数または形式のデータでも、リモート・ストレージ属性 ６０に格納することができる。リモート・ストレージ属性６０の重要な特徴は、 これがファイル４２の状態の固有部分を形成するので、Ｉ／Ｏシステムはこれを 追跡しファイルの他の属性全てと同様に一元管理することにある。これが意味す るのは、ファイル・システムは、ファイル内の他のあらゆる属性と全く同様に、 リモート・ストレージ属性を検出し、操作し、またはその他の方法で処理可能で あるということである。したがって、ファイルを扱うユーティリテイは、リモー ト・ストレージ属性上で具体的に動作する機能性を組み込むことができる。例え ば、ディレクトリのリストは、リモート・ストレージ属性６０を検査し、ローカ ル・ストレージ空間の割合、および使用可能なファイルが占めるリモート・スト レージ空間の割合を確認することができる。加えて、あるリモート格納データに アクセスするために必要な検索時間を推定するユーティリティを開発することも 可能である。このようなユーティリティによって、システム・マネージャは、変 化する状態またはその他の基準に基づいて、リモート格納処理ブロックの動作を 微調整(fine-tune)即ち修正することが可能となる。この情報全ては、単に、ロ ーカルに格納してある情報を検査するだけでコンパイル可能であることを注記し ておく。また、本発明は、従来技術のシステムでは得られない他の利点も広く提 供する。 図２では、ファイル４２のシステム属性部分に追加するものとして、リモート ・ストレージ属性６０を示している。以下で一層明らかとなる理由のために、リ モート・ストレージ属性６０をユーザの変更から保護することが考えられる。リ モート・ストレージ属性６０は、リモート格納処理ブロック４８がその様々な機 能を実行するために必要な情報を格納するために用いるので、ユーザの変更や干 渉から保護して当然である。しかしながら、リモート・ストレージ属性６０に格 納する情報の少なくとも一部は、場合によっては、ユーザやその他のクライアン ト・プロセスに関心があることも考えられる。適切な状況において、このような 情報をユーザまたはクライアント・プロセスに使用可能にしてもよい。また、シ ステム・マネージャが使用するために設計したユーティリティのような特殊化し たクライアント・プロセスに、リモート・ストレージ属性６０内の情報を変更さ せることが必要となることも、稀にあり得る。このような特殊化ユーティリティ による特別な場合のアクセスは、リモート・ストレージ属性６０をシステム属性 グル ープの外側に置くものとして解釈すべきでない。リモート・ストレージ属性６０ の主な使用は、Ｉ／Ｏシステム自体が、そのリモート格納機能を実施するため、 および本発明のリモート格納機能性をファイル・システム自体に統合するためで ある。 一旦リモート・ストレージ属性６０をファイルに追加し、リモート格納属性を ファイルから除去したなら、そのファイルをローカル・ストレージに格納するこ とができる。このプロセスは、図２において、読み出し／書き込みデータ処理ブ ロック６２およびローカル・ストレージ６４によって示してある。読み出し／書 き込み処理ブロック６２およびローカル・ストレージ６４は、リモート格納処理 ブロック４８からローカル・ストレージ６４までの概念的なデータ・フロー経路 を表わそうとしたものである。正確な実施の詳細は、本発明を実施するために選 択する個々の動作環境によって異なる。以下で更に詳しく説明するが、読み出し ／書き込みデータ処理ブロック６２は、Ｉ／Ｏ処理を実行するための別個のドラ イバ手段によって実施してもよく、あるいはリモート格納処理ブロック４８と纏 めて、Ｉ／Ｏ処理を実行するためのより大きなモノリシック・ドライバ手段(mon olithic,driver means)を形成してもよい。 図２に提示する例は、リモート格納処理ブロック４８が検査する特定のファイ ル、およびどの属性をローカルに格納し、どの属性をリモートに格納し、リモー トに格納する属性をどこに配置するかについて行う決定を示す。このような手順 は、システムに適切な機構であればいずれによっても行えることを注記しておく 。例えば、ローカル・ストレージ６４において、リモート・ストレージに移動さ せるべき情報を検査するために周期的にユーティリティを走らせるようにスケジ ューリングを行うことも可能である。あるいは、アクセスする毎に各ファイルを 検査するように、システムを設定することも可能である。更に別の例として、恐 らくこのような手順は、ユーザまたはシステム・マネージャの要求によってのみ 起動する。本質的に、本発明は、このような手順をいつ利用するかについては定 義せず、単に情報をローカル・ストレージからリモート・ストレージに移動させ る機構について記載するに止まる。 これまでの説明は具体的に本発明がファイルに対してどのような処理を行うの かということを対象にしてきたが、本発明の概念は、排他的にまたは主にシステ ムが用いるために設計した属性の集合を有する、あらゆるローカルに格納したエ ンティティとでも使用可能である。したがって、ファイルの例は、あらゆる観点 においても例示として見なし、本発明の範囲をいずれの特定のエンティティにも 限定して捕らてはならない。 次に図３を参照し、リモート格納属性を有するファイルを伴うＩ／Ｏ要求の処 理を表わす上位ブロック図を示す。本発明の関連においては、Ｉ／Ｏ要求は、本 発明を実施するＩ／Ｏシステムが実行することができるあらゆる動作であるとす る。したがって、Ｉ／Ｏ要求の定義は、単なるファイル・データの読み書きを遥 かに越えるものである。状況によっては、特定のファイルをアクセスした場合に ある電話番号に通話するというように、Ｉ／Ｏ要求が、従来のＩ／Ｏ動作と関連 のない他のアクションをトリガする場合もある。本発明の状況においては、この 用語は広く解釈することを想定する。 Ｉ／Ｏ要求が、リモート格納属性を有するファイルまたはその他のエンティテ ィを伴う場合、読み出し／書き込みデータ処理ブロック６２は、リモート格納属 性が関与することを確認することができる。これは、リモート・ストレージ属性 ６０の存在によるものである。このような属性を検出した場合、リモート・スト レージ属性６０内の情報をリモート格納処理ブロック４８に渡すことができる。 すると、リモート格納処理ブロック４８は、Ｉ／Ｏ要求を処理するために何をす る必要があるかについて判定を行うことができる。種々の実施形態が、種々の形 式の情報をリモート格納処理ブロック４８に渡すことができる。例えば、リモー ト・ストレージ属性６０内の情報を単にリモート格納処理ブロック４８に渡すこ とも可能である。次に、リモート格納処理ブロック４８がローカル・ストレージ ６４からの他の情報を必要とする場合、リモート格納処理ブロック４８は、読み 出し／書き込みデータ処理ブロック６２が所望の情報を検索することを要求する ことができる。あるいは、当初からより多くの情報をリモート格納処理ブロック ４８に渡してもよい。このような詳細は、本発明にはさほど重要ではない設計上 の選択事項と見なす。図３では、ローカル・ストレージ６４からリモート格納処 理ブロック４８へ検索情報を渡す処理は、ファイル６６によって示しており、こ のファイルをリモート格納処理ブロック４８に渡す。 一旦リモート格納処理ブロック４８がリモート・ストレージ属性６０およびそ の他のあらゆる必要な情報を受け取ったならば、リモート格納処理ブロック４８ は、Ｉ／Ｏ要求はローカルに格納してある情報を用いて処理することができるか 、またはＩ／Ｏ要求を処理するには、リモート・ストレージ５４から情報を検索 することが必要であるかについて判定を行うことができる。リモート・ストレー ジ５４から情報を検索することなくＩ／Ｏ要求を処理できるか否かに関する問題 は、個々のＩ／Ｏ要求およびリモートに格納してある属性によって異なる。 特定的な例として、システムにアクセス可能な情報のコンテンツ・インデック ス付け(content indexing)を実施するＩ／Ｏシステムについて検討する。このよ うなシステムでは、ユーザは、ローカルまたはリモート記憶デバイス上の個々の アドレスによってではなく、キー・ワードまたはその他のコンテンツ情報によっ て、情報を検索することができる。例えば、ユーザは、ある個人が著した文書全 て、特定のトピックに関する文書全て、または特定の単語または文章を有する文 書全てを要求することができる。このようなコンテンツ・インデックス付け方式 の場合、情報を検査し、種々のコンテンツ・キーを格納する必要がある。実現例 によっては、コンテンツ・キーを１つ以上のファイルの属性として格納すること が可能な場合もある。その際、ファイルのデータをリモートに格納する場合であ っても、コンテンツ・キーはローカルに保持するとよい。このような状況では、 ユーザが、あるコンテンツ・キーを収容する全ファイルのリストを要求する場合 、コンテンツ・キーをローカルに保持してあれば、単にローカル・ストレージ６ ４から情報を読み出すことによって、この要求を満たすことができる。このよう な状況では、リモート格納処理ブロック４８は、単にローカル・ストレージ６４ 上で適切な情報を検査し、応答６８で例示するように、適切な応答を発生する。 しかしながら、リモートに格納してある情報にユーザがアクセスしたい場合、 このような情報はリモート・ストレージ５４から検索する必要がある。このよう な状況では、リモート格納処理ブロック４８は、要求された情報を検索するステ ップを起動すればよい。これを、図３において、属性リコール７０で示す。図３ では、属性リコール７０は、読み出し／書き込みデータ処理ブロック５２が処理 するものとして示す。リモート・ストレージ５４が、オペレータの介入なく、読 み出し／書き込みデータ処理ブロック５２によるアクセスが可能な場合、読み出 し／書き込みデータ処理ブロック５２は単にリモート・ストレージ５４から、要 求された属性を検索し、リモート格納属性７２で示すように、リモート格納処理 ブロック４８にこれらを返せばよい。しかしながら、オペレータの介入が必要な 場合、恐らく読み出し／書き込みデータ処理ブロック５２、またはその他の処理 ブロックは、要求された情報を検索するために必要な適切なリモート記憶媒体を ロードするか、またはその他の方法でアクセス可能にするように、オペレータに 警告する必要がある場合もあり得る。次に、一旦適切な媒体が使用可能になった なら、要求された情報を検索し、リモート格納処理ブロック４８に返すことがで きる。いずれの場合でも、例えば、応答６８のような適切な応答を戻すことがで きる。 次に図４を参照し、本発明と共に用いるのに適したファイルの属性を表わす図 ファイル・システムが用いる属性の修正リストを表わす。ＮＴＦＳファイル・シ ステムについては、Microsoft Press（マイクロソフト・プレス社）が発行したH elen Custer（ヘレン・カスター）によるInside the Windows NT file System（ Windows NTファイル・システムの内側）により詳細に記載されており、この言及 により本願にも含まれるものとする。図４では、ファイルを構成する属性は、２ つの基本的グループに分割することができる。第１グループはシステム属性を収 容し、第２グループはユーザ属性を収容する。一般的に、システム属性は、シス テムがその種々の機能を実行するために必要なまたは要求される情報を格納する ために用いられる。このようなシステム属性は、通常、ロバストなファイル・シ ステムの実施を可能にする。システム属性の正確な数および形式は、概して、個 々のオペレーティング・システムまたは利用する個々のファイル・システムに全 面的に依存する。一方、ユーザ属性は、ユーザが制御するデータを格納するため に用いられる。これは、ユーザがある状況の下では１つ以上のシステム属性への アクセスを得られないということではない。しかしながら、ユーザ属性は、ユー ザまたはクライアント・プログラムが対象のデータをプログラムに格納するこ とができる格納場所を定義する。図４では、システム属性は全体的に７４で示し 、ユーザ属性は全体的に７６で示している。 システム属性は、例えば、標準情報属性７８、属性リスト８０、名称属性８２ 、セキュリティ記述子属性８４、およびリモート・ストレージ属性８６で構成す ることができる。標準情報属性７８は、読み出しのみ、読み出し／書き込み、隠 れ(hidden)等のような標準的な"MS-DOS"属性を表す。属性リスト８０は、ファイ ルがマスタ・ファイル・テーブル内において２つ以上の記憶レコードを占有する 場合に、ファイルを構成する追加の属性の場所を識別するためにＮＴＦＳが使用 する属性である。マスタ・ファイル・テーブルは、ファイルまたはディレクトリ の常駐属性全てを格納する場所である。名称属性８２は、ファイルの名称である 。ＮＴＦＳでは、ファイルは多数の名称属性、例えば、長い名称、短いMS-DOS名 称等を有する場合がある。セキュリティ記述子属性８４は、ファイルを所有する のが誰で、それにアクセスすることができるのは誰かを指定するために、 言及して本願にも含まれるものとした、Inside the Windows NT File Systemに 更に詳細に記載されている。 リモート・ストレージ属性８６は、本発明が追加する新たな属性である。リモ ート・ストレージ属性８６は、特定のファイルを、リモート格納属性を有するも のとして識別する。リモート・ストレージ属性は、リモート格納属性の場所を識 別できるのに十分な情報を収容することが好ましい。全ての属性は、全体として 捕らえた場合、特定のファイルのどの属性がリモート格納であり、どの属性がロ ーカル格納か識別可能でなければならない。このような情報は、リモート・スト レージ属性８６に収容することができ、あるいはこのような情報は、ファイルの 他の属性を検査することによって得ることも可能である。例えば、各属性が特定 の長さである場合、または特定の属性の長さを属性と共に格納する場合、単純に 予測長を実際にローカル・ストレージ上に格納してある長さと比較することによ って、どの属性がリモート格納であるのか識別することが可能となる。例えば、 あるデータ属性が１００Ｋバイト長であると予想し、実際に格納してある情報量 がかなり少ない場合、このデータ属性はリモート格納と推定することができる。 あるいは、このような情報は、単純にリモート・ストレージ属性８６に組み込む ことも可能である。一実施形態では、リモート・ストレージ属性は、次のように 構成する。 以下で更に詳しく説明するように、本発明の実施形態のあるものは、Ｉ／Ｏ処 理を実行するために複数のドライバ手段を利用し、リモート・データ格納処理を 実施する場合がある。例えば、図２または図３のリモート格納処理ブロック４８ は、Ｉ／Ｏ処理を実行するための１つのドライバ手段に実施することができ、読 み出し／書き込みデータ処理ブロック６２は、Ｉ／Ｏ処理を実行するための他の ドライバ手段を用いて実施することができる。この場合、これら２つのドライバ 手段は、これらの間で情報をやりとりすることにより、本発明の目的を達成する ように調整することができる。実際には、リモート格納処理の機能を実施するＩ ／Ｏ処理を実行するためのドライバ手段は、単純に、Ｉ／Ｏシステム内の種々の 目的のために用いる複数のドライバ手段の内の１つとしてもよい。このような実 施形態について、以下に論ずる。このような状況では、リモート格納属性を有す るファイルを伴うＩ／Ｏ要求を処理する責務を引き受けるのは、どのドライバで あるのか確認する必要がある場合もある。本発明の範囲内の実施形態は、Ｉ／Ｏ 要求の少なくとも一部を処理すべきドライバとして、特定のドライバ手段を特定 する手段を備えることができる。特定のドライバをリモート・ストレージ属性の オーナとして特定する機構であれば、いずれでもこのような手段に用いることが できる。リモート・ストレージ属性が、先のテーブルに示す構造を有する場合、 このような手段は、例えば、タグ値を備えることができる。この例では、タグは 、リモート・ストレージ属性のオーナのＩＤを収容するデータ・ワードである。 このような機構により、単一システム内に複数の階層ストレージ・マネージャが 存在することが可能となり、各階層ストレージ・マネージャは、異なる形式のフ ァイルまたは異なる形式のリモート記憶デバイスを伴うＩ／Ｏ要求を処理するよ う に適合化してある。 ドライバをどのシステム上にインストールするかには係わらず、同じタグを常 に同じオーナ・ドライバに関連付けるように、タグを割り当てることが好ましい 。言い換えると、タグ値を特定のドライバに割り当てる何らかの機構が存在する ことが好ましい。例えば、タグ値のブロックを種々のドライバ製造者に割り当て る中央レポジトリまたはクリアリング・ハウスがあるとよい。こうすると、ドラ イバ製造者は、タグを特定のドライバに割り当てることができる。タグ値を多く とも１つのドライバに関連付けさせる他のいずれの機構も、使用可能である。こ のようにタグ値を割り当てることにより、どのシステムにインストールしたかに は係わらず、同じオーナ・ドライバが同じリモート格納要求を処理することが可 能となる。あるいは、状況によっては、ローカル・タグ値を動的な方法で割り当 て、インストール中にシステムによってタグ値を割り当てるようにすることも可 能となる。しかしながら、このような方法ではいくつかの問題も存在する場合が あるので、一般的には好ましくない。 先のテーブルに示したリモート・ストレージ属性では、任意のリモート格納フ ラグを示した。先程リモート格納フラグを示したのは、リモート格納属性を有す るファイルの識別を可能にする機構が存在しなければならないことを示すためで ある。このような指示を与えるには、例えば、リモート格納属性を有するファイ ルを示すリモート格納フラグを用いることができる。あるいは、他の機構を用い ることも可能である。例えば、リモートに格納可能な各属性毎に、フラグを保持 することも可能である。属性をリモートに格納する場合、フラグをセットするこ とができる。このような機構は、リモート格納属性が存在するという事実の確認 だけでなく、どの属性をリモートに格納してあるかという確認も可能にする。更 に別の例として、各属性の予想長を、ローカルに格納してあるデータの実際の長 さと比較してもよい。更に別の例として、１つ以上のタグ値を、ファイルがリモ ート格納属性を全く有していないことを示すために確保することも可能である。 このような機構を用いることにより、例えば、ファイルがリモート格納属性を全 く有していないことを示すためにタグ０を確保することも可能となろう。ファイ ルが少なくとも１つのリモート格納属性を有する場合、他のいずれかのタグ値が これを示すことになる。 先に示したリモート・ストレージ属性によって、オーナが制御するデータの格 納が可能となる。したがって、本発明の実施形態は、ドライバ手段がリモート格 納属性を管理するために用いる情報を格納する手段を備える。一例として、限定 ではなく、このような手段はオーナ制御データ・フィールドを備えるとよい。オ ーナ制御データ・フィールドは、リモート・ストレージ属性のオーナが、リモー ト格納属性を適正に管理するために必要なあらゆる形式のデータでも置くことが できる場所を表わす。例えば、リモート格納属性の場所は、リモート・ストレー ジ属性のデータ・フィールドに格納することができる。他の例も既に示した。更 に他の例として、階層ストレージ・マネージャの一部が、オーナ制御データ・フ ィールド内に、リモート格納属性のアイデンティティを格納できるようにすると よい。これは、階層ストレージ・マネージャが、どの属性をローカルに格納し、 どの属性をリモートに格納したのかを素早く確認することを可能にする機構にも なる。このデータ・フィールドには、他のあらゆる形式のデータでも格納可能で ある。 先に示したリモート・ストレージ属性では、データ・フィールドの前にデータ 長指示子がある。この記憶フォーマットでは、データ・フィールドの長さを格納 し、データ・フィールドを完成するために読み出さなければならないデータ量を 確認する。あるいは、実施形態によっては、固定長のデータ・フィールド、ある いはポインタまたはリンクによって互いに連鎖した情報のブロックを利用するデ ータ・フィールドを格納する方が一層効率的な場合もあり得る。本質的に、デー タ・フィールドを完成するために読み出さなければならないデータ量を確認する あらゆる機構が利用可能である。オーナ・ドライバによって格納する必要があり 得るデータ量についても考慮すべきであろう。このような考慮は、データ・フィ ールドをどのように格納するか、およびデータ・フィールドの最大可能長に影響 を与える。 次に図４を参照し、ファイルのユーザ属性を表わすグループ７６について検討 する。先に説明したように、ユーザ属性は、ユーザまたはクライアント・プロセ ス情報を格納するためにユーザまたはその他のクライアント・プロセスが用いる 属性を表わす。ＮＴＦＳファイルは、典型的に、図４にデータ１属性８８および データ２属性９０として示す、１つ以上のデータ属性を有する。従来のファイル ・システムの殆どは、単一のデータ属性に対応するに過ぎない。データ属性は、 ユーザ制御データを格納可能な場所と基本的には全く同様である。例えば、ワー ド・プロセッシング文書では、典型的に、ファイルのデータ属性に文書を格納す る。ＮＴＦＳファイル・システムでは、ファイルは多数のデータ属性を有するこ とができる。１つのデータ属性を「無名」属性(unnamed attribute)と呼び、他 の属性は各々関連する名称を有する名称付き属性である。データ属性の各々は、 異なる形式のユーザ制御データを格納できる格納場所を表わす。本発明と組み合 わせた場合、このようなファイル構造は、データ属性のいずれかまたは全てをロ ーカルまたはリモートのいずれにも格納することが可能となる。これは、従来技 術のシステムに対する有意義な利点を表わすことができる。従来技術のシステム では、ファイル内のデータは、全てローカルに格納するか、あるいは全てリモー トに格納するかのいずれかであった。データの一部分をローカルに、そしてデー タの一部分をリモートに格納するという概念はなかった。ＮＴＦＳファイル・シ ステムの多数のデータ属性を用いることにより、あるデータをローカルに格納し 、他のデータをリモートに格納することが可能となる。したがって、あるファイ ルが、規則的にアクセスされるある種のデータ、および稀にしかアクセスされな かった他のデータを収容する場合、稀にしかアクセスされなかったデータをリモ ート・ストレージに移動させることができ、一方頻繁にアクセスされたデータを ローカル・ストレージに維持することができる。 １つ以上のデータ属性に加えて、ファイルは、他の属性９２で示すように、他 のユーザ定義属性も有することができる。このような属性は、ユーザが定義し、 ファイルと共に格納するその他のあらゆる属性を表わす。このようなユーザ定義 属性は、ユーザが所望するあらゆる目的のために作成し用いることが可能である 。 これまでの説明は、特定のファイル形式に関して多少詳細に入り込んだもので あったが、これは例示に過ぎず、本発明の範囲を限定するものと解釈すべきでは ない。本発明は、既存のファイルの属性にリモート・ストレージ属性を追加した あらゆる形式のファイルまたはその他のエンティティとでも作用する。代替物で は、既存のシステム属性を共に選択(co-opt)即ち利用することにより、リモート 格納情報を格納し、したがって、ファイル内の既存のシステム属性数を増大させ ることなく、リモート・ストレージ属性を含ませる方法を同等に備えることも可 能な場合もあり得る。 次に図５に移り、本発明の一実施形態の全体的な構造を示す。図５は、Ｉ／Ｏ 処理を実行するためのドライバ手段を複数個利用するＩ／Ｏシステムを示す、上 位概念図を表わす。クライアント・プロセス９４は、Ｉ／Ｏ要求を作成し、矢印 ９８で示すように、オペレーティング・システム・サービス９６に最終的に送出 する。図５に示すＩ／Ｏシステムは、複数のＩ／Ｏ処理を実行するドライバ手段 を備えている。一例として、限定ではなく、図５では、このような手段は、層１ ドライバ１００、層２ドライバ１０２、および層Ｎドライバ１０４で示してある 。 このようなＩ／Ｏ要求はドライバ間でやりとりされるので、本発明の範囲内の 実施形態は、ドライバ手段間でＩ／Ｏ要求を受け渡す手段を備えることができる 。一例として、図５では、１つのドライバから他のドライバに直接受け渡すＩ／ Ｏ要求を示す矢印１０６および１０８によって、このような手段を示している。 このような手段は、ドライバ間のＩ／Ｏ要求の転送を扱うＩ／Ｏマネージャを備 えることも可能である。このようなＩ／Ｏマネージャは、図５のＩ／Ｏマネージ ャ１１０とすることができる。 図５において、Ｉ／Ｏマネージャ１１０は、クライアント・プロセッサ９４か ら受け取ったＩ／Ｏ要求を層１ドライバ１００に送出する。このようなＩ／Ｏ要 求は、Ｉ／Ｏマネージャがコールした関数またはサービスの形態、あるいは、適 切な情報を適切なドライバに転送する他のあらゆる機構とすることができる。例 mechanism)を用いてＩ／Ｏシステムの種々のドライバ間で通信を行う。このシス テムでは、Ｉ／Ｏ要求の結果、Ｉ／ＯマネージャがＩ／Ｏ要求パケット（ＩＲＰ ：I/O Request Packet）を作成し、ＩＲＰを適切なドライバに送る。Ｉ／Ｏ要求 を処理し別のドライバに送出する際、ＩＲＰに情報を添付し、ＩＲＰを次のドラ イバに渡す。加えて、新たなＩＲＰを作成し次のドライバに送ることも可能であ る。状況によっては、ＩＲＰを次のドライバに渡す前に、修正するまたは「変 ／Ｏマネージャがドライバ間でＩＲＰを転送する責務を負う。他のシステムでは 、他の機構を用いることができる。このような実施の詳細は、設計上の選択事項 であり、本発明には重要ではない。 ここで図５に戻り、Ｉ／Ｏ要求は、矢印１０６で示すように、種々のドライバ を通過し、各ドライバはあらゆる要求された処理を実行してから、Ｉ／Ｏ要求を 次のドライバに送出する。尚、図５は各ドライバがＩ／Ｏ要求を順番に受け取る ことを示すが、実施形態によっては、あるドライバを飛ばし、Ｉ／Ｏ要求を処理 する必要のあるドライバのみが実際にＩ／Ｏ要求を扱うようにすることが望まし い場合もあり得る。 本発明の一実施形態では、複数のドライバを用いてＩ／Ｏ処理を実行する場合 、リモート・ストレージ属性を有するファイルに遭遇した場合、通常の処理シー ケンスを中断する機構が存在する。この場合、制御を他のドライバに渡し、どの ようにＩ／Ｏ要求を処理すべきかについて判断を下す。したがって、本発明の範 囲内の実施形態は、Ｉ／Ｏ要求の処理を中断する手段を備えることができる。図 ５では、このような手段は、例えば、層Ｎドライバ１０４に組み込むことができ る。本発明のこの実施形態では、リモート格納属性を有するファイルに遭遇した 場合、通常の処理シーケンスを中断する。このようなファイルは、例えば、リモ ート・ストレージ属性の存在によって、あるいはリモート・ストレージ属性およ び／または先に説明した他の属性の検査によって識別することができる。 リモート格納属性を有するファイルを認識した場合、Ｉ／Ｏ要求の通常の処理 シーケンスを保留とし、Ｉ／Ｏ要求の処理を完了するステップを行う。これらの ステップは、Ｉ／Ｏ要求を処理する制御を別のドライバに転送し、リモート格納 属性を有するファイルに対するＩ／Ｏ要求の処理にこのドライバを参加させるこ とを伴う。したがって、本発明の範囲内の実施形態は、Ｉ／Ｏ要求を処理する制 御をドライバ間で転送する手段を備えることができる。Ｉ／Ｏ要求の処理を途中 で中断する場合、Ｉ／Ｏ要求を処理するドライバから別のドライバに制御を移管 するいずれの機構でも利用可能である。例えば、図５では、このような機構は矢 印１１２で示している。これは、Ｉ／Ｏ要求の処理中にリモート格納属性を有す るファイルに遭遇した際に、層Ｎドライバ１０４から層１ドライバ１００にＩ／ Ｏ要求を処理する制御を移管することを示す。以下で更に詳しく説明するが、制 御をドライバ間で移管する機構は、制御を引き受けるドライバが適正にＩ／Ｏ要 求を処理することができるように、ある情報を転送しなければならない場合もあ り得る。したがって、本発明の範囲内の実施形態は、リモート格納情報をドライ バに渡す手段も備えることができる。 一旦層Ｎドライバ１０４から層１ドライバ１００に制御を移管したなら、層１ ドライバ１００は適正にＩ／Ｏ要求を処理しなければならない。ある状況および 実施形態では、制御を引き受けたドライバは、制御を移管したときに供給した情 報によって、またはローカル・ストレージから追加情報を得ることによって、Ｉ ／Ｏ要求を完全に処理できる場合もある。ドライバが追加情報を検索することな くＩ／Ｏ要求を処理することができる場合、矢印１０８および１１４で示すよう に、結果をクライアント・プロセッサに戻せばよい。 ローカル・ストレージからまたはリモート・ストレージからの追加情報の検索 なしではＩ／Ｏ要求を完全に処理することができない場合、ドライバは１つ以上 の追加Ｉ／Ｏ要求を作成し、適切な情報を検索することが必要になる場合もある 。したがって、本発明の範囲内の実施形態は、第２のＩ／Ｏ要求を作成する手段 を含むことができる。図５では、このような作成手段は、ドライバを介してＩ／ Ｏ要求を返送し、ローカル・ストレージ１１８から情報を得ることを表わす矢印 １１６、またはリモート・ストレージ１２２から情報を検索するために送る要求 を示す矢印１２０で表わしている。 第２のＩ／Ｏ要求を作成するためには、所望の情報を検索するために必要なあ このような手段は、新たなＩＲＰを作成するか、または既存のＩＲＰを変身させ 、このＩＲＰを適切なドライバに渡すことによって、実施することができる。以 下で更に詳細に説明するが、ローカル・ストレージまたはリモート・ストレージ から情報を検索する場合、他のコンピュータ・システムが処理を要求する場合も あり得る。したがって、第２のＩ／Ｏ要求を作成するためのこのような手段は、 Ｉ／Ｏ要求を他のコンピュータにも転送する場合もある。しかしながら、いずれ の 場合でも、一旦適切な情報を検索すれば、矢印１０８および１１４で示すように 、適切な応答をクライアント・プロセス９４に返送することができる。 要約すると、本発明のある実施形態は、Ｉ／Ｏ要求の通常処理シーケンスを中 断し、階層ストレージ管理の責務を負うドライバに、リモート格納属性を有する ファイルまたはその他のエンティティを伴うＩ／Ｏ要求の処理に介入および関与 させるシステムおよび方法を提供する。図５は複数の層状ドライバを示すが、複 数のドライバの機能性を１つ以上のモノリシック・ドライバに組み込んでもよい ことは明白であろう。このようなシステムでは、ドライバ間通信の必要性が軽減 する。しかしながら、層状ドライバを有するＩ／Ｏシステムの様々な利点は得ら れない。本発明を複数の層状ドライバに実施するかまたは数個の層状ドライバの 機能性を組み込んだ１つ以上のモノリシック・ドライバに実施するかの選択は、 設計上の選択事項であり、本発明には重要ではない。しかしながら、種々の機能 エレメントが本質的に図示した態様で協働することが好ましい。言い換えると、 １つ以上のリモート格納属性を有するファイルに遭遇した場合、このようなファ イルを伴うＩ／Ｏ要求を処理する責務を負う処理ブロックに制御を渡す。適切な 機能性については、既に説明した。 次に図６に移り、Ｉ／Ｏ処理を実行する複数のドライバ手段を備えたＩ／Ｏシ ステムの更に詳細な図を提示する。図６におけるＩ／Ｏシステムは、Microsoft る複数のドライバ手段を使用するその他のオペレーティング・システムも、同様 の構造を有する場合もあり得る。同様に、図６との関連で論ずる概念は、複数の ドライバまたは単一のモノリシック・ドライバを用いるあらゆるＩ／Ｏシステム を用いても、適切な機能性を適切なドライバに組み込むまたは組み合わせること によって実施することができる。したがって、図６に示す構造の使用は、あらゆ る観点においても本発明の限定と見なすべきではなく、可能な実現例の１つに過 ぎないと見なすべきである。 図６に示す実施形態は、Ｉ／Ｏ処理を実行する複数のドライバ手段を備えてい る。既に説明したように、Ｉ／Ｏ処理およびＩ／Ｏ要求という用語は、広く解釈 し、Ｉ／Ｏシステムが実行可能なあらゆる機能および動作を含むすることを意図 している。一例として、限定ではなく、図６では、このようなドライバ手段は、 全体的に１２４で示すドライバＡ、および全体的に１２６で示すドライバＢによ って例示してある。また、本発明の範囲内の実施形態は、ドライバ手段間でＩ／ Ｏ要求を受け渡す手段も備えることができる。一例として、図６では、このよう な手段はＩ／Ｏマネージャ１２８によって示している。Ｉ／Ｏマネージャ１２８ は、例えば、Ｉ／Ｏシステムが用いる複数のドライバ間でＩ／Ｏ要求を移管する 責務を負うＩ／Ｏマネージャを表わす。先に論じたように、実施形態によっては 、Ｉ／Ｏマネージャを利用しない場合もあり、更に種々のドライバ間の直接通信 に頼る場合もある。このような実施形態では、ドライバ間でＩ／Ｏ処理要求を受 け渡す手段は、一方のドライバがＩ／Ｏ要求を直接別のドライバに渡すために用 いる機構となる。１つ以上のドライバの機能性をモノリシック・ドライバに組み 込んだ更に別の実施形態では、ドライバ間でＩ／Ｏ要求を受け渡しする手段を必 要としない場合もあり、あるいは単にモノリシック・ドライバ自体の内部に位置 する場合もある。 図６に示すように、ドライバＡ１２４およびドライバＢ１２６は、Ｉ／Ｏマネ ージャ１２８が種々の機能を行うためにアクセス可能な１組のサービスまたはル 動作するドライバが有することができる可能なルーチンの一部分を表わす。種々 のルーチンに関する詳細は、Microsoft Press（マイクロソフト・プレス社）が 発行したHelen Custer（ヘレン・カスター）によるInside the Windows NT file System（Windows NTファイル・システムの内側）の第８章に見ることができ、 この言及により本願にも含まれるものとする。 ある種のルーチンは、ドライバＡ１２４およびドライバＢ１２６双方に同様の 機能を実行する。ルーチンの正確な詳細は非常に異なる場合もあるが、ルーチン の総合的な目的は同一である。ドライバＡ１２４およびドライバＢ１２６双方に 同様の機能を実行するルーチンは、初期化ルーチン１３０、開始Ｉ／Ｏルーチン １３２、割込サービス・ルーチン１３４、延期手順コール・ルーチン１３６、キ ャンセルＩ／Ｏルーチン１３８、およびアンロード・ルーチン１４０を含む。こ テムの下でのドライバの動作には重要であるが、これらは本発明の目的上は総じ て重要ではない。しかしながら、これらのルーチンの機能について以下に手短か に纏めておく。 ドライバＡ１２４およびドライバＢ１２６双方は、初期化ルーチン１３０を有 する。初期化ルーチンは各ドライバ毎に異なる場合もあるが、初期化ルーチンは 、Ｉ／Ｏマネージャがドライバをオペレーティング・システムにロードするとき に、Ｉ／Ｏマネージャが実行する。このルーチンは、Ｉ／Ｏマネージャにドライ バを使用させかつアクセスさせるために必要なあらゆる初期化を実行する。開始 Ｉ／Ｏルーチン１３２は、デバイスへのデータ転送またはデバイスからのデータ 転送を起動するために用いる。割込サービス・ルーチン１３４は、デバイスが特 定の ルーチンにおける処理は、絶対少数に維持し、下位の割込を不必要に阻害するこ とを回避している。延期手順コール・ルーチン１３６は、割込サービス・ルーチ ンを実行した後に、デバイスの割込を処理する際に必要な処理の殆どを実行する 。キャンセルＩ／Ｏルーチン１３８は、Ｉ／Ｏ動作を取り消す場合にコールする 。アンロード・ルーチン１４０は、Ｉ／Ｏマネージャがドライブをメモリから除 去することができるように、システム資源を解放する。 パッチ・ルーチン１４２やドライバＢ１２６のディスパッチ・ルーチン１４４の ような、１組のディスパッチ・ルーチンを含む。ディスパッチ・ルーチンは、デ バイス・ドライバが備える主要な機能である。その例には、読み出しまたは書き 込み機能およびその他のあらゆるデバイスの機能(capability)、ファイル・シス テム、またはドライバが対応するネットワークがある。ドライバＡ１２４を用い てリモート格納機能を実行する場合、ディスパッチ・ルーチン１４２は、適切な 機能性を発揮する(expose)ルーチンを含む。Ｉ／Ｏ動作をドライバによって処理 する場合、Ｉ／Ｏマネージャ１２８はＩ／Ｏ要求パケット（ＩＲＰ）を発生し、 ドライバのディスパッチ・ルーチンの１つを通じて、ドライバをコールする。こ のように、図６では、Ｉ／Ｏ要求は、ドライバ間またはＩ／Ｏマネージャとドラ イバとの間で受け渡しされるＩＲＰによって表わすことができる。 多数のドライバが協働して種々の機能を実行する場合、１つのドライバが、Ｉ ／Ｏ要求を後続のドライバに受け渡す前に、このＩ／Ｏ要求の部分的な処理を実 行することも可能である。このような処理は、図６において、ＩＲＰ１４６をド ライバＡ１２４に渡し、ＩＲＰ処理ブロック１４８で示すようにドライバＡ１２ ４によって部分的に処理し、更にＩＲＰ１５０を介してドライバＢ１２６に渡す ことによって示している。ＩＲＰ１４６およびＩＲＰ１５０は、同じＩＲＰであ ることに注意されたい。しかしながら、ＩＲＰがどのようにドライバ間を流れる ことができるのかを明確に確認するために、図６ではこれらに別個の番号を付し てある。また、ＩＲＰ１４６およびＩＲＰ１５０とは異なるように、新たなＩＲ Ｐを作成する実施形態を有することも可能な場合もある。 Ｉ／Ｏ要求がリモート格納属性を有するファイルまたはその他のエンティティ を伴わない場合、ドライバは通常の方法でＩ／Ｏ要求を処理し、通常の方法でＩ ／Ｏ要求に関連する情報を戻す。したがって、１つ以上の階層ストレージ・マネ ージャをインストールしているシステムは、リモート格納属性を有するファイル を伴うＩ／Ｏ要求に遭遇する前に、階層ストレージ・マネージャからは殆どまた は全く処理オーバーヘッドを受けることはない。例えば、図６では、ドライバＢ １２６がＩＲＰ１５０を受け取った場合、ＩＲＰ処理ブロック１５２がこれを通 常の方法で処理することができる。処理の結果は、ＩＲＰ１５４に戻すことがで きる。図６には示さないが、ＩＲＰ１５４は、ドライバＢ１２６による処理の後 、ドライバＡ１２４に戻すことができる。これは、通常のＩ／Ｏ処理の全部分で あり、先に言及によって本願にも含まれるものとした、Inside Windows NTに更 に詳細に説明されている。 図５との関連で既に説明したように、複数のドライバ手段を利用して本発明の 機能性を実施する実施形態では、リモート格納属性を有するファイルを伴うＩ／ Ｏ要求に遭遇した場合、Ｉ／Ｏ要求の正常な処理を中断し、リモート格納属性を 有するファイルを伴うＩ／Ｏ要求を扱うように特定して適合化したドライバに制 御を移管する。このプロセスを遂行するために、本発明の範囲内の実施形態は、 Ｉ／Ｏ要求の処理を中断する手段を備えている。このような手段は、Ｉ／Ｏ要求 がリモート格納属性を有するファイルを伴い、Ｉ／Ｏ要求の処理を途中で終了し 制御を他のドライバに移管できるようにすることをドライバが認識する機構であ れば、そのいずれでもよい。図６では、このような手段は、例えば、リモート格 納検出ブロック１５６で示している。 リモート格納属性を有するファイルの検出は、種々の方法で実施することがで きる。これらの殆どについては、リモート・ストレージ属性の可能な１実現例と の関連で既に論じてある。リモート・ストレージ属性の正確な内容および個々の 実現例によっては、リモート・ストレージ属性の内容を単に検査することによっ て、リモート格納属性を有するファイルを識別することが可能なこともあり得る 。既に論じたように、このようなリモート・ストレージ属性は、当該リモート・ ストレージ属性がリモート格納属性に関する情報を収容したときを特定する、フ ラグまたはその他の手段を備えることができる。あるいは、単にファイル自体の 中の情報を検査することによって、リモート格納属性を有するファイルを識別す ることが可能な場合もあり得る。例えば、１つ以上の属性の予想長を、ローカル ・ストレージ上に格納してある属性の実際の長さと比較することにより、リモー ト格納属性を有するファイルを識別することが可能な場合もある。更に第３の代 替物では、リモート格納属性を有するファイルの識別は、ある実施形態では、リ モート・ストレージ属性に格納してある情報およびファイルに格納してあるその 他の情報双方を検査することによって遂行することも可能である。一旦リモート ・ストレージ属性の正確な実現例およびファイル構造を識別したなら、リモート 格納属性を有するファイルを検出するために使用可能な種々の選択肢は明らかと なろう。 リモート格納検出ブロック１５６が、あるＩ／Ｏ要求がリモート格納属性を有 するファイルを伴うことを確認した場合、Ｉ／Ｏ要求の通常の処理を終了し、Ｉ ／Ｏ要求を処理する責務を他のドライバに移管するためのステップを実行する。 図６では、これらのステップはリモート格納処理ブロック１５８によって実行す る。 リモート格納処理ブロック１５８は、現ドライバから、Ｉ／Ｏ要求を処理する 責務を引き受けるドライバに制御を移管するのに必要なあらゆる事前処理を実行 する。例えば、リモート・ストレージ属性が既に論じたようにタグおよびデータ ・ フィールドを収容する場合、リモート格納処理ブロック１５８は、リモート・ス トレージ属性からタグおよびデータ・フィールドを抽出し、リモート・ストレー ジ属性のオーナへの移管のためにこれらを準備する。このように、本発明の範囲 内の実施形態は、リモート格納情報をドライバに渡す手段を備えることができる 。一例として、限定ではなく、図６ではリモート格納データ１６０によってこの ような手段を示している。リモート格納データ１６０は、単に、リモート格納処 理ブロック１５８が抽出したリモート格納情報を表わす。実施形態によっては、 リモート・ストレージ属性からリモート格納情報を抽出し、図６に示すようにそ れをＩ／Ｏマネージャ１２８を介して渡すのではなく、これを直接リモート・ス トレージ属性のオーナに渡すことができる場合もある。本質的に、リモート格納 情報のオーナに、リモート・ストレージ属性内に格納してある情報にアクセスさ せる機構であれば、そのいずれでも、リモート格納情報をドライバに渡す手段と して利用することができる。これは、リモート格納情報を格納してある場所また はリモート・ストレージ属性自体にポインタを渡すことを含む。一実施形態では 、リモート格納データ１６０は、ＩＲＰに含まれており、別のドライバに渡され る。 リモート格納属性を有するファイルを伴うＩ／Ｏ要求を識別した場合、このＩ ／Ｏ要求を処理する責務をドライバ間で移管する。したがって、本発明の範囲内 の実施形態は、Ｉ／Ｏ要求を処理する制御をドライバ間で移管する手段を備えて いる。図６に示す実施形態では、このような手段は、例えば、完了ルーチン１６ 書かれたドライバは、下位ドライバがＩＲＰを処理し終えた後に、Ｉ／Ｏマネー ジャがコールする１つ以上の完了ルーチンを備えることができる。例えば、ファ イル・システム・ドライバおよびデバイス・ドライバを有する実施形態では、Ｉ ／Ｏマネージャは、デバイス・ドライバがデータをファイルにまたはファイルか ら転送し終えた後に、ファイル・システム・ドライバの完了ルーチンをコールす ることができる。完了ルーチンは、動作の成功、失敗、または取消についてファ イル・システム・ドライバに通知することができ、ファイル・システムにクリー ンアップ動作(cleanup operation)を実行させる。このように、通常の処理の間 、ドライバＢ１２６がＩＲＰ１５０を受け取り、完全にこれを処理し、ＩＲＰ１ ５ ４を戻した場合、Ｉ／Ｏマネージャ１２８はブロック１６２における完了ルーチ ンをコールすることができ、これがドライバＡ１２４にＩ／Ｏ動作の成功または 失敗を通知し、ドライバＡ１２４にあらゆるクリーンアップ処理を実行させる。 Ｉ／Ｏマネージャ１２８は、下位ドライバがその処理を完了したときに完了ル ーチンをコールするので、このような完了ルーチンは、リモート格納属性を有す るファイルを伴うＩ／Ｏ要求を処理する制御の移管を検出する機構を配置する理 想的な場所を形成する。したがって、完了ルーチン１６２は、リモート格納デー タ１６０を検査し、ドライバＡ１２４がリモート・ストレージ属性のオーナであ り、Ｉ／Ｏ要求を処理する責務を引き受けなければならないか否か確認すること ができる。 しかしながら、リモート格納属性を有するファイルを伴うＩ／Ｏ要求を処理す る責務をドライバが引き受ける前に、当該ドライバは、自分がリモート・ストレ ージ属性のオーナであるか否かについて確認しなければならない。これまでの説 明によって、複数の階層ストレージ・マネージャまたはその他の特殊化ドライバ を特定のシステム内に組み込み可能であることは明白であろう。したがって、ド ライバの各々は、何らかの形式の特殊化処理を実行するように適合化することが できる。前述のようなリモート・ストレージ属性を用いて、ドライバの各々に一 意のタグ値を割り当てる。下位ドライバがリモート・ストレージ属性を有するフ ァイルに遭遇した場合、下位ドライバは、タグおよびリモート・ストレージ属性 の値を抽出し、これを上位のドライバまで受け戻す。すると、上位のドライバの 各々は、タグ値を検査し、それ自体がリモート・ストレージ属性のオーナであり 、Ｉ／Ｏ要求を処理する責務を引き受けなければならないか否か確認する。この ように、個々のシステム内に異なるドライバ記憶マネージャが存在し、協働して 、記憶の階層的管理を達成することができる。リモート格納または他の形式の特 殊化処理のいずれかに使用可能な、これらの原理を採用し一般化した機構が、"F ILE SYSTEM PRIMITIVE ALLOWING REPROCESSING OF I/O REQUESTS BY MULTIPLE D RIVERS IN ALAYERED DRIVER I/O SYSTEM"（層状ドライバＩ／Ｏシステムにおけ る多数のドライバによってＩ／Ｏ要求の再処理を可能にするファイル・システム ・プリミティブ）と題する、同時係属中の米国特許出願番 号第０８／８６２，０２５号に開示されており（以下「再解析点」出願）、この 言及により本願にも含まれるものとする。 多層環境では、本発明の範囲内の実施形態は、特定のドライバが受け取ったリ モート格納情報が、当該ドライバが所有するものであるか否かについて確認する 手段を備えることができる。一例として、限定ではなく、図６ではリモート格納 検出ブロック１６４によってこのような手段を示している。リモート格納検出ブ ロック１６４は、リモート格納データ１６０を検査し、ドライバＡ１２４がリモ ート格納情報のオーナであるか否かについて確認する。ドライバＡ１２４がリモ ート格納情報のオーナでない場合、ドライバＡ１２４は、完了処理ブロック１６ ６によって示す、必要な通常の完了処理を全て実行し、別のドライバに転送する ためにリモート格納データ１６０をＩ／Ｏマネージャ１２８に渡すことができる 。 一方、リモート格納検出ブロック１６４が、ドライバＡ１２４をリモート格納 情報のオーナとして特定した場合、制御はリモート格納処理ブロック１６８に移 り、Ｉ／Ｏ要求の処理を更に進める。Ｉ／Ｏ要求を処理する制御を引き受けるこ と以外に、ドライバがそれ自体をリモート格納情報のオーナとして特定した場合 に発生することは、本発明では定義しない。しかしながら、通常、ドライバはＩ ／Ｏ要求を処理する責務を引き受け、更にＩ／Ｏ要求を完了するステップを実行 する。例えば、リモート格納処理ブロック１６８は、Ｉ／Ｏ要求の完了のために 更に図２または図３に関連して既に説明した機能のいずれでも実行することがで きる。これは、リモート格納処理ブロック１６８が、リモート格納データ１６０ 内で受け取った情報を用いてＩ／Ｏ要求を完全に処理し終えることができるとい う状況を含む。このような状況では、ドライバがＩ／Ｏ要求を処理し終えた後に 、 必要なあらゆる情報をＩ／Ｏマネージャに返送し、更に転送することを含む。ま た、これは、いずれかの上位ドライバの完了ルーチンをコールし、必要なあらゆ るクリーンアップ処理をそれらに実行させるか、あるいはＩ／Ｏ要求のステータ スをそれらに知らせることも含む場合がある。 状況によっては、リモート格納情報のオーナであるドライバは、それ自体でＩ ／Ｏ要求の残りを完全に処理できない場合もあり得る。このような状況では、リ モート格納処理ブロック１６９はＩＲＰを発生し、これを他のドライバに渡すこ とによって、Ｉ／Ｏ要求を更に処理することを可能にする。あるいは、以下で図 ８との関連で論ずるように、Ｉ／Ｏ要求を発生し、他のコンピュータに渡して、 更に処理を進めることも可能である。したがって、本発明の範囲以内の実施形態 は、第２のＩ／Ｏ要求を作成し、元のＩ／Ｏ要求の処理を継続する手段を備える ことができる。このような手段には、この特定の実施形態が利用して他のドライ バまたはシステムのヘルプをリストに纏めＩ／Ｏ要求を完了する機構であれば、 そのいずれでも利用することができる。例えば、図６では、第２のＩ／Ｏ要求を 作成する手段は、リモート格納処理ブロック１６８およびＩＲＰ１７０によって 示している。次いで、ＩＲＰ１７０は、例えば、ドライバＢ１２６のような他の ドライバ、または図６に示すようなリモート・ストレージ・ドライバに渡すこと ができる。ＩＲＰ１７０を受け取ったドライバは、次に、他のあらゆるＩＲＰと 同様にこれを処理する。例えば、ＩＲＰ１７０をドライバＢ１２６に送り、元の Ｉ／Ｏ要求を完全に処理するために必要な情報を更にローカル・ストレージから 検索することができる。あるいは、ＩＲＰ１７０は、リモート格納属性のリコー ル要求を発行する機構とすることも可能である。したがって、起動してリモート ・ストレージから必要な情報をリコールするリモート・ストレージ・ドライバま たはその他のデバイスに、ＩＲＰ１７０を渡すことができる。 リモート格納処理ブロック１６８がＩＲＰ１７０を作成するとき、当該ＩＲＰ を最初から作成することも、既存のＩＲＰを取り込み当該ＩＲＰを「変身させる 」ことも可能である。変身のプロセスは、既存のＩＲＰを取り込み、ＩＲＰ内の 情報を変更して修正ＩＲＰ即ち新たなＩＲＰを作成する。第２のＩ／Ｏ要求を作 成する手段は、異なるシステムにおいて別個に実施することも可能である。例え ば、１つのドライバが直接別のドライバをコールするシステムでは、第２のＩ／ Ｏ要求を作成する手段は、情報を組み立て、直接コール機構を介してその他のド ライバに渡す機構とすることができる。本質的に、第２のＩ／Ｏ要求を作成する 手段を実施するために必要な全ては、Ｉ／Ｏ要求を作成または修正し、次いで更 に処理するために他のドライバまたはエンティティに渡すことができる機能を有 することである。 これより図７を参照し、これを用いて、多数のドライバがいかに協働して階層 的記憶管理を実施することができるのかについて明確化するために、具体例を提 示する。図７では、クライアント・プロセス１７２がＩ／Ｏ要求をＩ／Ｏシステ ムに作成する。Ｉ／Ｏシステムは、Ｉ／Ｏ処理を実行する複数のドライバ手段を 備えている。クライアント・プロセス１７２は、矢印１７６で示すように、オペ レーティング・システム・サービス１７４にコールを行う。Ｉ／Ｏマネージャ１ ７８は、Ｉ／Ｏ要求を受け取り、Ｉ／Ｏシステムの種々のドライバ手段間で、Ｉ ／Ｏ要求の転送を調整する。 図７では、Ｉ／Ｏ処理を実行する複数のドライバ手段を示す。このようなドラ イバ手段は、階層ストレージ・マネージャ１８０、ファイル・システム・ドライ バ１８２、ディスク・ドライバ１８４、およびリモート・ストレージ・ドライバ １８６を備えている。階層ストレージ・マネージャ１８０は、ファイルまたはそ の他のエンティティのリモート格納属性を管理する責務を負う。階層ストレージ ・マネージャ１８０は、稀にしかアクセスされないファイルまたはその他のエン ティティから属性を除去し、リモート・ストレージ１８８のような、リモート位 置にこれらを格納する。また、階層ストレージ・マネージャ１８０は、必要に応 じて、適切な属性のリコールを調整する。本質的に、階層ストレージ・マネージ ャ１８０は、図２および図３との関連で先に論じた上位機能性を組み込む。ファ イル・システム・ドライバ１８２は、ファイルまたはディレクトリに対するアク セス要求を、ローカル・ストレージ１９０上の物理的な場所に変換する責務を負 う。ディスク・ドライバ１８４は、ローカル・ストレージ１９０から情報を検索 しかつローカル・ストレージ１９０に情報を入力する責務を負う。リモート・ス トレージ・ドライバ１８６は、リモート・ストレージ１８８との双方向情報転送 を調整および管理する責務を負う。リモート・ストレージ・ドライバ１８６は、 多くの中間ドライバまたはシステムを介して動作し、リモート・ストレージ１８ ８に情報を格納したり、あるいはリモート・ストレージ１８８から情報を検索し てもよいことを注記しておく。図７のＩ／Ｏシステムは、このように複数のドラ イバを用い、その各々が特定の機能または機能群を担当することにより、ロバス トなＩ／Ｏ環境を備えている。 矢印１７６で示すように、クライアント・プロセス１７２がＩ／Ｏ要求を行う と、Ｉ／Ｏマネージャ１７８はＩＲＰ１９２を作成し、Ｉ／Ｏシステム内の種々 のドライバ間でＩＲＰ１９２の転送を調整する。この例では、連続する各ドライ バを介してＩＲＰ１９２を受け渡す。各ドライバは、ディスク・ドライバ１８４ に到達するまで、下位ドライバの機能をイネーブルするために必要なあらゆる予 備処理を実行する。次に、ディスク・ドライバ１８４は、ローカル・ストレージ １９０から所望の情報を検索し、このような情報をＩＲＰ１９４を介してファイ ル・システム・ドライバ１８２に戻す。Ｉ／Ｏ要求がリモート格納属性を有する ファイルを伴う場合、ファイル・システム・ドライバ１８２は、ＩＲＰ１９４内 において情報が戻されたときに、これを認識する。ファイル・システム・ドライ バ１８２は、既に論じた種々の機構を用いて、個々のＩ／Ｏ動作が、リモート格 納属性を有するファイルを伴うか否かについて検出することができる。図７では 、リモート格納データ１９６のファイル・システム・ドライバ１８２への返送に よって、これを具体的に示す。しかしながら、リモート格納データ１９６は、例 えば、ＩＲＰ１９４のようなＩＲＰ内で戻してもよいことを思い出されたい。同 様に、個々の実現例によっては、ＩＲＰ１９４はＩＲＰ１９２と同じＩＲＰとし てもよい場合もある。 ファイル・システム・ドライバ１８２が、Ｉ／Ｏ動作がリモート格納属性を有 するファイルを伴うことを認識した場合、ファイル・システム・ドライバ１８２ は、最小限、リモート・ストレージ属性内の情報を抽出し、その情報を上位ドラ イバに渡すことによって、上位ドライバの１つがそれ自体をリモート・ストレー ジ属性のオーナであることを認識し、Ｉ／Ｏ要求を処理する責務を引き受けるよ うにする。図７では、これは、ファイル・システム・ドライバ１８２がリモート 格納データ１９６を階層ストレージ・マネージャ１８０に渡すことによって示し ている。これは、図６との関連で既に説明したように、Ｉ／Ｏマネージャが階層 ストレージ・マネージャ１８０の完了ルーチンにコールすることによって遂行す ることができる。他の機構も適宜用いることができる。 階層ストレージ・マネージャ１８０がリモート格納データ１９６を受け取った 場合、階層ストレージ・マネージャ１８０はリモート・ストレージ属性において その情報を検査し、それがリモート・ストレージ属性を所有し、Ｉ／Ｏ要求を処 理する制御を引き受けるべきか否かについて確認する。この例では、階層ストレ ージ・マネージャ１８０は、それ自体をリモート・ストレージ属性のオーナとし て認識し、Ｉ／Ｏ要求を処理する責務を引き受ける。 一旦階層ストレージ・マネージャ１８０がそれ自体をオーナとして認識し、Ｉ ／Ｏ要求を処理する責務を引き受けたなら、階層ストレージ・マネージャ１８０ は次にＩ／Ｏ要求の処理を更に進めるためにすべきことを確認する。一般に、３ つの潜在的に可能な状況設定の１つを想定することができる。階層ストレージ・ マネージャ１８０は、単にファイル・システム・ドライバ１８２から階層ストレ ージ・マネージャ１８０に渡された情報を用いることによって、Ｉ／Ｏ要求を完 全に処理できる場合もある。このような情報は、リモート・ストレージ属性内の 情報を含み得るだけでなく、他の属性からの他の情報も含み得ることを思い出さ れたい。ファイル・システム・ドライバ１８２から階層ストレージ・マネージャ １８０に渡される正確な情報は、個々の実現例によって異なる。階層ストレージ ・マネージャ１８０が、それが有する情報によってＩ／Ｏ要求を完全に処理する ことができる場合、次にＩＲＰ１９８および矢印２００によって、適切な結果を クライアント・プロセス１８２に戻すことができる。 しかしながら、階層ストレージ・マネージャ１８０が、それが使用可能な情報 のみを用いて、Ｉ／Ｏ要求を完全に処理することができない場合、階層ストレー ジ・マネージャ１８０は、Ｉ／Ｏ要求を処理するために必要な情報を検索するた めのステップを実行することができる。Ｉ／Ｏ要求および正確な状況にしたがっ て、必要な情報は、ローカル・ストレージ、またはリモート・ストレージ、ある いは双方から検索しなければならない場合もある。ローカル・ストレージ１９０ からの検索は、図７では、ファイル・システム・ドライバ１８２およびディスク ・ドライバ１８４に渡すＩＲＰ２０２、および要求された情報を戻すために用い るＩＲＰ２０４で示す。リモート・ストレージ１８８からの検索は、図７では、 リモート・ストレージ・ドライバ１８６に転送され、必要に応じてリモート・ス トレージ１８８への情報転送またはリモート・ストレージ１８８からの情報転送 を開始するＩＲＰ２０６、およびあらゆる適切な情報を階層ストレージ・マネー ジ ャ１８０に戻すＩＲＰ２０８で示す。階層ストレージ・マネージャ１８０がリモ ート・ストレージ１９０またはリモート・ストレージ１８８あるいは双方から適 切な情報を検索した後、階層ストレージ・マネージャ１８０はＩ／Ｏ要求の処理 を完了し、図示のように、ＩＲＰ１９８および矢印２００によって適切な応答を 返すことができる。Ｉ／Ｏ要求を完了するためにローカル・ストレージ１９０ま たはリモート・ストレージ１８８に情報を書き込む必要がある場合、多少変更し た形態で同じ状況設定を用いる。 次に図８を参照し、リモート格納属性を有するファイルに遭遇した場合に、特 定の形式の階層ストレージ・マネージャが別個の計算機システムを利用してＩ／ Ｏ要求を処理するという例を提示する。図８に示す実施形態では、クライアント ・プロセス２１０は、ローカル・コンピュータ２１２上で実行している。ローカ ル・コンピュータ２１２は、コンピュータを相互接続するネットワーク手段を通 じて、リモート・コンピュータ２１４に接続してある。図８では、このようなネ ットワーク手段は、ネットワーク・カード２１６および接続部２１８によって示 している。ローカル・コンピュータ２１２のＩ／Ｏシステム２２０は、Ｉ／Ｏ処 理を実行するための複数のドライバ手段を備えている。図８では、このようなド ライバ手段は、例えば、暗号化ファイル・マネージャ２２２、ファイル・システ ム・ドライバ２２４、およびディスク・ドライバ２２６によって示している。ま た、Ｉ／Ｏシステム２２０は、オペレーティグ・システム・サービス２２８およ びＩ／Ｏマネージャ２３０も備えている。図７におけると同様、クライアント・ プロセス２１０は、オペレーティング・システム・サービス２２８にコールを行 う。Ｉ／Ｏマネージャ２３０はＩ／Ｏ要求を受け取り、Ｉ／Ｏシステムの種々の ドライバ手段間でのＩ／Ｏ要求の転送を調整する。あるいは、Ｉ／Ｏシステムの 種々のドライバ手段は、Ｉ／Ｏマネージャや情報の転送を調整するその他のデバ イスを用いずに、互いに直接通信することも可能である。 このシステムでは、ある種のファイル属性を暗号化してリモート・コンピュー タ２１４に送り、アクセスを制限した安全な環境でこれらを格納する。したがっ て、暗号化しリモート・コンピュータ２１４に格納したファイルを伴うあらゆる Ｉ／Ｏ要求は、暗号化せずにローカルに格納した他のファイルとは別個に処理し なければならない。この例では、クライアント・プロセス２１０は、リモート・ コンピュータ２１４上に格納してある暗号化ファイルを伴うＩ／Ｏ要求を行うと 想定する。このような要求を行うには、例えば、矢印２３２で示すように、クラ イアント・プロセス２１０がオペレーティング・システム・サービス２２８をコ ールする。Ｉ／Ｏ要求をファイル・システム・ドライバ２２４に渡し、ディスタ ・ドライバ２２６を利用して適切な情報を検索する。ディスク・ドライバ２２６ は、ディスク・コントローラ２３４を利用し、ローカル・ストレージ２３６から 情報を検索する。暗号化ファイルにアクセスする試みが行われた場合、ファイル ・システム・ドライバ２２４は、そのファイルがリモート格納属性であることを 認める。次に、リモート・ストレージ属性内の情報を、暗号化ファイル・マネー ジャ２２２に渡し、暗号化ファイルを、リモート・コンピュータ２１４上に格納 してあるものとして確認する。次に、暗号化ファイル・マネージャ２２２は、適 切なファイルを検索するステップを実行する。 適切なファイルを検索するステップは、Ｉ／Ｏ要求をリモート・コンピュータ ２１４に送ることを伴う場合がある。Ｉ／Ｏ要求を暗号化ファイル・マネージャ ２２２からリモート・コンピュータ２１４に転送するあらゆる機構が利用可能で ある。図８では、このようなＩ／Ｏ要求は、リディレクタ(redirector)２３８お よびネットワーク・トランスポート・ドライバ２４０を介して送ることができる 。リディレクタ２３８は、ローカル・コンピュータ２１２がネットワークを通じ て他の機械にある資源にアクセスするために必要な利器(facility)を備える。ネ ットワーク・トランスポート・ドライバ２４０は、ネットワーク・カード２１６ および接続部２１８を通じてローカル・コンピュータ２１２からリモート・コン ピュータ２１４に情報を転送する機構を備える。他の機構も使用可能であり、図 ８に示すコンポーネントは、あらゆる観点においても例示と見なして当然である 。このような機構は、一般に、専用リンク、ローカル・エリア・ネットワーク（ ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、電話回線、ワイヤレス接 続等のような、あらゆる形式の接続を２つのコンピュータ間に含むことができる 。これらの通信機構に対応するために、種々の形式のソフトウエア・ドライバま たはコンポーネントが必要となる場合もあり得る。 暗号化ファイル・マネージャ２２２からの要求は、リディレクタ２３８に送ら れ、リディレクタ２３８はネットワーク・トランスポート・ドライバ２４０を用 いて、ネットワーク・カード２１６および接続部２１８を通じてＩ／Ｏ要求をリ モート・コンピュータ２１４に転送する。この特定例では、Ｉ／Ｏ要求は、暗号 化しリモート・コンピュータ２１４上に格納してある属性を検索するためのもの とする。このようなＩ／Ｏ要求は、ネットワーク・カード２１６、ネットワーク ・トランスポート・ドライバ２４２、およびサーバ・ファイル・システム２４４ を通じて、リモート・コンピュータ２１４が受信する。サーバ・ファイル・シス テム２４４は、リディレクタ２３８と通信し、リモート・コンピュータ２１４に 送られて来たあらゆるＩ／Ｏ要求を処理しこれを満たす。暗号化属性を検索する Ｉ／Ｏ要求を満たすために、サーバ・ファイル・システム２４４は、ファイル・ システム・ドライバ２４６やディスク・コントローラ２４８のような、リモート ・コンピュータ２１４のドライバおよびハードウエアを利用することができる。 本例では、サーバ・ファイル・システム２４４は、ファイル・システム・ドライ バ２４６を利用して、ディスク２５０から適切な暗号化属性を検索する。次に、 暗号化ファイル・マネージャ２２２に暗号化属性を返す。暗号化ファイル・マネ ージャ２２２が暗号化属性を受け取ったなら、暗号化ファイル・マネージャ２２ ２は、情報を解読するステップを実行し、次いでその情報をクライアント・プロ セス２１０に戻すことができる。 図５ないし図８に与えた例は、複数の異なるドライバを層状ドライバ・モデル で使用して階層ストレージ管理を実施した実施形態について説明した。このよう な層状ドライバ・モデルを用いて本発明を実施した場合、階層ストレージ・マネ ージャを作成するために必要なステップは、以下に示すように纏めることができ る。 最初のステップは、具体的な階層ストレージ・マネージャを特定するタグを定 義することである。前述のように、このタグは、所与のシステム上において既存 のタグ全てと異なるようにする必要がある。先に言及して本願にも含まれるもの とした同時係属中の再解析点特許出願は、本出願に開示されている機構と同様の 一般的な機構を、あらゆる形式の特殊化したドライバ（階層ストレージ・マネー ジャを含む）が、どのようにしてＩ／Ｏ要求の処理に介入するために用いること ができるかについて説明している。そこに記載されている機構も、タグ値を有す る属性を用いていた。このようなシステムでは、多数のドライバが存在する場合 があるので、階層ストレージ・マネージャに割り当てるタグは、システム内の既 存のあらゆる他のタグとも異なるものでなければならない。既に説明したように 、何らかの集中割り当て機構を用いてタグを予め関連付けることも可能であり、 あるいはインストール時に動的に割り当てることも可能である。 次のステップは、リモート・ストレージを記述する情報を設計することである 。この情報は、リモート・ストレージ属性に置き、階層ストレージ・マネージャ が用いるものである。このような情報は、リモート・ストレージ内のデータの完 全な識別を可能にしなければならない。既に説明したように、このデータは、シ ステム内に存在する各階層ストレージ・マネージャ毎に専用(private)であるの で、あらゆる情報を収容することができ、あるいは階層ストレージ・マネージャ が所望するあらゆるフォーマットを有することができる。オペレーティング環境 を破壊する階層ストレージ・マネージャについては、リモート・ストレージ属性 は適切な痕跡を含み、階層ストレージ・マネージャが、データをローカル・スト レージまたはリモート・ストレージに保持していた間に、データに何らかの変更 があったか否かについて認識できるようにすることも可能である。 次のステップは、リモート・ストレージ属性内に格納するデータを処理し、リ モート格納属性を有するファイルを伴うＩ／Ｏ要求を処理するために、層状階層 ストレージ・マネージャを構築することである。一旦層状階層ストレージ・マネ ージャを作成しシステム内にインストールしたなら、階層ストレージ・マネージ ャは、図５ないし図８との関連で既に論じたように、リモート格納属性を有する ファイルを伴うＩ／Ｏ要求を処理する。既に論じたように、Ｉ／Ｏ要求を処理す る場合、階層ストレージ・マネージャは、元のＩ／Ｏ要求と共に到来した情報に アクセスし、当該Ｉ／Ｏ要求を処理するために取るべきアクションを決定するこ とができる。追加の情報にアクセスすることなく解決するアクションもあるが、 ローカル・ストレージから情報を読み出したり、ローカル・ストレージに情報を 書き込む必要のあるアクションもあり、更に、リモート・ストレージから情報を 読み出したり、リモート・ストレージに情報を書き込む必要のある更に別のアク ションもある。 図５ないし図８に与えた例は、複数の異なるドライバを用いて階層的記憶管理 を実施する実施形態を強調したが、これらのドライバのいずれの機能性も、組み 合わせることにより一層高度な機能性を有する更に別のモノリシック・ドライバ も得られることは明白であろう。このような事項は、設計上の選択事項であり、 本発明の実現例には重要ではない。本発明は、階層ストレージ管理の既存のＩ／ Ｏシステム内への密接な統合に関するものである。本発明の目標の１つは、Ｉ／ Ｏシステム内に、種々の属性をリモートに格納するためにネーティブな支援を与 えることである。これは、ファイル・システムに、リモート格納属性を有するフ ァイルを検出し確認させることを含む。ここに記載した発明は非常に柔軟性があ るので、ファイルまたはその他のエンティティの属性のいずれかまたは全てを、 ローカルまたはリモートに格納することを可能にする。ローカル・ストレージ上 に残す必要があるのは、どこにリモート格納属性が位置するかを階層ストレージ ・マネージャに確認させるために十分な情報だけでよい。その結果、リモート格 納情報の状態をファイル・システムの一体部分として追跡し保持することを可能 にするＩ／Ｏシステムが得られた。 本発明は、その精神または本質的な特徴から逸脱することなく、他の特定形態 にも具体化が可能である。記載した実施形態は、あらゆる観点においても、限定 的ではなく、例示として見なすべきである。したがって、本発明の範囲は、前述 の記載ではなく、添付の請求の範囲によって示すものとする。請求の範囲の均等 の意味および範囲に該当する全ての変更は、その範囲内に含まれるものとする。

【手続補正書】特許法第１８４条の８第１項 【提出日】平成１１年１０月１４日（１９９９．１０．１４） 【補正内容】 請求の範囲 １．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステム の一体部分としてリモート・ファイル格納を実施する方法であって、前記Ｉ／Ｏ システムが、複数の層状ドライバを有し、かつ複数の属性から成るファイルを伴 うＩ／Ｏ要求を処理し、前記属性の第１部分がユーザ制御データを格納するため に適合化してあり、前記属性の第２部分が前記Ｉ／Ｏシステムによる使用のため に適合化してあり、前記方法が、 前記複数の層状ドライバの特定の１つによって、リモートに格納すべきファイ ルの前記第１部分または前記第２部分のいずれかに格納してある少なくとも１つ の属性を識別するステップと、 前記少なくとも１つの属性を前記リモート記憶媒体に格納するステップと、 前記ローカル記憶媒体内に前記第２部分の一部として、前記少なくとも１つの 属性が前記リモート記憶媒体に格納されていることを前記Ｉ／Ｏシステムに示す リモート・ストレージ属性を格納するステップと、 から成り、前記リモート・ストレージ属性が、 前記特定の層状ドライバを、前記ファイルを伴うＩ／Ｏ要求を処理する制御を 引き受けることができるドライバとして特定するタグと、 前記少なくとも１つの属性を格納してある、前記リモート記憶媒体内の場所を 表わす情報と、 を含むことを特徴とする方法。 ２．請求項１記載のリモート・ファイル格納を実施する方法において、前記リモ ート・ストレージ属性が、更に、前記リモート記憶媒体内の場所を表わす前記情 報に加えて、前記少なくとも１つの属性を識別するために前記特定の層状ドライ バが望むあらゆる情報を含むことを特徴とする方法。 ３．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記少なくとも１つの属性を格納する前記ステップを、 前記特定の層状ドライバによって実行することを特徴とする方法。 ４．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、前記ファイルの属性をローカル・ストレージから 読み出し、前記少なくとも１つの属性をリモートに格納すべきと判定するために 、十分な情報を入手可能とするステップを含むことを特徴とする方法。 ５．請求項１記載のリモート・ファイル記憶を実施する方法において、前記少な くとも１つの属性を格納する前記ステップを、前記特定の層状ドライバによって 実行し、（１）リモートに格納すべき情報を抽出するステップと、（２）前記抽 出した情報を、前記複数の層状ドライバ内に含まれる他の層状ドライバに送るス テップとを含むことを特徴とする方法。 ６．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステム の一体部分としてリモート・ファイル格納を実施する方法であって、前記Ｉ／Ｏ システムが、複数の層状ドライバを有し、かつ複数の属性から成るファイルを伴 うＩ／Ｏ要求を処理し、前記属性の第１部分がユーザ制御データを格納するため に適合化してあり、前記属性の第２部分が前記Ｉ／Ｏシステムによる使用のため に適合化してあり、前記方法が、 ファイルへのアクセスを要求するＩ／Ｏ要求を受け取るステップであって、前 記ファイルの少なくとも１つの属性が前記リモート記憶媒体に格納してあり、前 記ファイルの複数の属性の前記第２部分が、前記ローカル記憶媒体上に格納して あるリモート・ストレージ属性を含む、ステップと、 前記ローカル記憶媒体から前記リモート・ストレージ属性を読み出し、前記フ ァイルが、前記リモート記憶媒体に格納してある少なくとも１つの属性を有する ことを確認するステップと、 から成り、前記読み出すステップが、 前記リモート・ストレージ属性内に含まれるタグを読み出すステップであって 、 該タグが前記Ｉ／Ｏ要求を処理する制御を引き受けることができる、前記複数の 層状ドライバの特定の１つを特定する、ステップと、 前記少なくとも１つの属性を格納してある、前記リモート記憶媒体内の場所を 表わす、前記リモート・ストレージ属性内に含まれる情報を読み出すステップと を含み、 前記特定の層状ドライバによって、前記リモート記憶媒体内に格納してある前 記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことができ るか否かについて判定を行うステップと、 前記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことが できる場合、前記ローカル記憶媒体から必要なあらゆる情報にアクセスすること によって、前記Ｉ／Ｏ要求を満たすステップと、 前記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことが できない場合、前記特定の層状ドライバによって、前記リモート記憶媒体から前 記少なくとも１つの属性にアクセスすることによって、前記Ｉ／Ｏ要求を満たす ステップと、 から成ることを特徴とする方法。 ７．請求項６記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記ローカル記憶媒体から前記リモート・ストレージ属 性を読み出す前記ステップを、前記複数の層状ドライバに含まれ、前記特定の層 状ドライバとは異なる別の層状ドライバによって実行することを特徴とする方法 。 ８．請求項７記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、 前記他の層状ドライバによって前記タグを抽出するステップと、 前記特定の層状ドライバに制御を移管し、該特定の層状ドライバが、前記Ｉ／ Ｏ要求を処理する制御を引き受けることができるようにするステップと、 を含むことを特徴とする方法。 ９．請求項８記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、前記特定の層状ドライバが第１階層ストレージ・マネー ジャであり、前記複数の層状ドライバが第２階層ストレージ・マネージャを含み 、制御を移管する前記ステップが、 前記タグを前記第２階層ストレージ・マネージャに渡し、前記第２階層ストレ ージ・マネージャが前記タグに応答しないステップと、順番に、 前記タグを前記特定の層状ドライバに渡し、前記タグに基づいて、前記特定の 層状ドライバがそれ自体を、前記Ｉ／Ｏ要求を処理する責務を引き受けることが できる層状ドライバとして認識するステップと、 を含むことを特徴とする方法。 １０．Ｉ／Ｏ処理を実行する複数の層状ドライバ手段を用いるＩ／Ｏシステムに おいて、Ｉ／Ｏシステム・プリミティブとしてリモート・ファイル格納を実施す る方法であって、 Ｉ／Ｏ処理を実行する第１層状ドライバ手段によって、Ｉ／Ｏ要求を受け取り 、少なくとも１つのファイルまたはディレクトリを伴う、指定されたＩ／Ｏ動作 を実行するステップと、 前記少なくとも１つのファイルまたはディレクトリのいずれかが、ローカルに かつ当該少なくとも１つのファイルまたはディレクトリのいずれのユーザ制御デ ータ属性からも離れて格納してあるリモート・ストレージ属性を収容することを 判定することによって、前記少なくとも１つのファイルまたはディレクトリが、 リモート格納属性を有することを前記第１ドライバ手段によって判定するステッ プであって、前記リモート・ストレージ属性が、 Ｉ／Ｏ処理を実行する第２層状ドライバ手段を、前記少なくとも１つのファイ ルおよびディレクトリを伴うＩ／Ｏ要求を処理する制御を引き受けることができ る層状ドライバ手段として特定するタグと、 前記リモート格納属性を格納する、リモート記憶媒体内の場所を表わすリモー ト格納情報と、 を含む、前記のステップと、 前記第１層状ドライバ手段によって、前記リモート・ストレージ属性から前記 タグおよび前記リモート格納情報を抽出するステップと、 前記タグおよび前記リモート格納情報を前記第２層状ドライバ手段に渡し、前 記第２層状ドライバ手段が、前記指定したＩ／Ｏ要求を処理する制御を引き受け るステップと、 から成ることを特徴とする方法。 １１．請求項１０記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法において、前記タグおよび前記リモート格納情報を前記第 ２層状ドライバ手段に渡す前記ステップが、前記第２層状ドライバ手段が、前記 タグに基づいて、前記少なくとも１つのファイルおよびディレクトリを伴うＩ／ Ｏ要求を処理する制御を引き受けることができる層状ドライバ手段としてそれ自 体を認識するステップを含むことを特徴とする方法。 １２．請求項１１記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法において、前記第２ドライバ手段が、以下のステップ、即 ち、 リモート格納情報へのアクセスなく、前記指定のＩ／Ｏ要求を満たすことがで きるか否かについて判定を行うステップと、 前記リモート格納属性へのアクセスなく、前記指定のＩ／Ｏ要求を満たすこと ができる場合、ローカル記憶媒体から必要なあらゆる情報にアクセスすることに よって、前記Ｉ／Ｏ要求を満たすステップと、 前記リモート格納属性へのアクセスなく、前記指定のＩ／Ｏ要求を満たすこと ができない場合、前記リモート記憶媒体から前記リモート格納属性にアクセスす ることによって、前記Ｉ／Ｏ要求を満たすステップと、 を実行することにより前記Ｉ／Ｏ要求を処理することを特徴とする方法。 １３．コンピュータ実行可能命令を有するコンピュータ読取可能媒体であって、 Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第１層状ドライバ手段であって 、 前記Ｉ／Ｏシステムが少なくとも１つのファイルまたはディレクトリを受け取っ たときに、リモート格納属性を有する前記少なくとも１つのファイルまたはディ レクトリに関連する、ローカルに格納してあるリモート・ストレージ属性を読み 込む手段を備え、前記リモート・ストレージ属性が、 前記Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第２層状ドライバ手段を、 前記Ｉ／Ｏ要求の制御を引き受ける層状ドライバ手段として特定するタグと、 前記リモート格納属性を格納してあるリモート記憶媒体内の位置を表わすリモ ート格納情報と、 を含む第１層状ドライバ手段と、 前記第２層状ドライバ手段であって、前記Ｉ／Ｏ要求の制御を引き受けるよう に適合化してある、第２層状ドライバ手段と、 前記読取手段が前記リモート・ストレージ属性を読み取ったことに応答して、 前記第１層状ドライバ手段が実行しているＩ／Ｏ処理を中断する手段と、 前記Ｉ／Ｏ要求を処理する制御を、前記第１層状ドライバ手段から前記第２層 状ドライバ手段に移管し、前記タグに応答して前記Ｉ／Ｏ要求の処理の制御を前 記第２層状ドライバ手段が引き受けるようにする手段と、 を備えることを特徴とするコンピュータ読取可能媒体。 １４．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第１層状ドライバ手段が、前記リモート格納情報を前記第 ２層状ドライバ手段に渡す手段を備えることを特徴とするコンピュータ読取可能 媒体。 １５．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第２層状ドライバ手段が、前記タグに応答して、前記第２ 層状ドライバ手段自体が前記Ｉ／Ｏ要求を処理する制御を引き受けることができ ると判断する手段を備えることを特徴とするコンピュータ読取可能媒体。 １６．請求項１４記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、 前記第２層状ドライバ手段が、第１階層ストレージ・マネージャであり、前記 第１層状ドライバ手段が第１指定値を有するタグをリモート・ストレージ属性か ら読み出したときに、前記第２層状ドライバ手段がＩ／Ｏ要求を処理する制御を 引き受け、 前記コンピュータ実行可能命令が、更に、前記第１層状ドライバ手段が第２指 定値を有するタグをリモート・ストレージ属性から読み出したときに、Ｉ／Ｏ要 求を処理する制御を引き受ける第２階層ストレージ・マネージャを備える、 ことを特徴とするコンピュータ読取可能媒体。 １７．複数のデータ・フィールドを格納してあり、データ構造を表わすコンピュ ータ読取可能媒体であって、 前記データ構造を格納するために割り当てた記憶アドレスの範囲の第１領域内 に格納してある第１データ・フィールド集合であって、該第１データ・フィール ド集合がユーザ属性を格納し、ユーザが前記ユーザ属性を検索するためにアクセ ス可能な、第１データ・フィールド集合と、 前記データ構造を格納するために割り当てた記憶アドレスの前記範囲の第２領 域内に格納してある第２データ・フィールド集合であって、前記第２データ・フ ィールド集合が、前記データ構造のＩ／Ｏシステム属性を格納し、前記Ｉ／Ｏシ ステム属性が、Ｉ／Ｏシステム内に含まれる複数の層状ドライバの１つ以上によ るアクセスに適合化してある、第２データ・フィールド集合と、 を備え、 前記第２データ・フィールド集合が、 リモート・ストレージ属性を格納可能なリモート・ストレージ属性データ・フ ィールドを備え、 前記リモート・ストレージ属性が、 前記複数の層状ドライバの１つを、他のリモート・コンピュータ読取可能媒体 上に格納すべき、前記データ構造の部分を選択可能な指定ドライバとして特定す るタグと、 前記部分を格納すべき、前記他のリモート・コンピュータ読取可能媒体内の位 置を表わす情報を格納する手段と、 を備えること、を特徴とするコンピュータ読取可能媒体。 １８．請求項１７記載のコンピュータ読取可能媒体において、前記情報が、前記 指定ドライバに、必要な場合に、前記データ構造の前記部分を突き止めかつ検索 することを可能にすることを特徴とするコンピュータ読取可能媒体。 １９．請求項１８記載のコンピュータ読取可能媒体において、情報を格納する前 記手段が、前記他のリモート記憶媒体上に格納してある前記データ構造の前記部 分を識別する情報を備えることを特徴とするコンピュータ読取可能媒体。 【手続補正書】 【提出日】平成１２年１１月２日（２０００．１１．２） 【補正内容】 （１）特許請求の範囲の記載を以下の通りに補正します。 『１．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステ ムの一体部分としてリモート・ファイル格納を実施する方法であって、前記Ｉ／ Ｏシステムが、複数の層状ドライバを有し、かつ複数の属性から成るファイルを 伴うＩ／Ｏ要求を処理し、前記属性の第１部分がユーザ制御データを格納するた めに適合化してあり、前記属性の第２部分が前記Ｉ／Ｏシステムによる使用のた めに適合化してあり、前記方法が、 前記複数の層状ドライバの特定の１つによって、リモートに格納すべきファイ ルの前記第１部分または前記第２部分のいずれかに格納してある少なくとも１つ の属性を識別するステップと、 前記少なくとも１つの属性を前記リモート記憶媒体に格納するステップと、 前記ローカル記憶媒体内に前記第２部分の一部として、前記少なくとも１つの 属性が前記リモート記憶媒体に格納されていることを前記Ｉ／Ｏシステムに示す リモート・ストレージ属性を格納するステップと、 から成り、前記リモート・ストレージ属性が、 前記特定の層状ドライバを、前記ファイルを伴うＩ／Ｏ要求を処理する制御を 引き受けることができるドライバとして特定するタグと、 前記少なくとも１つの属性を格納してある、前記リモート記憶媒体内の場所を 表わす情報と、 を含むことを特徴とする方法。 ２．請求項１記載のリモート・ファイル格納を実施する方法において、前記リモ ート・ストレージ属性が、更に、前記リモート記憶媒体内の場所を表わす前記情 報に加えて、前記少なくとも１つの属性を識別するために前記特定の層状ドライ バが望むあらゆる情報を含むことを特徴とする方法。 ３．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記少なくとも１つの属性を格納する前記ステップを、 前記特定の層状ドライバによって実行することを特徴とする方法。 ４．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、前記ファイルの属性をローカル・ストレージから 読み出して、前記少なくとも１つの属性をリモートに格納すべきと判定するため に、十分な情報を入手可能とするステップを含むことを特徴とする方法。 ５．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル記憶を 実施する方法において、前記少なくとも１つの属性を格納する前記ステップを、 前記特定の層状ドライバによって実行し、かつ（１）リモートに格納すべき情報 を抽出するステップと、（２）前記抽出した情報を、前記複数の層状ドライバ内 に含まれる他の層状ドライバに送るステップとを少なくとも含むことを特徴とす る方法。 ６．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステム の一体部分としてリモート・ファイル格納を実施する方法であって、前記Ｉ／Ｏ システムが、複数の層状ドライバを有し、かつ複数の属性から成るファイルを伴 うＩ／Ｏ要求を処理し、前記属性の第１部分がユーザ制御データを格納するため に適合化してあり、前記属性の第２部分が前記Ｉ／Ｏシステムによる使用のため に適合化してあり、前記方法が、 ファイルへのアクセスを要求するＩ／Ｏ要求を受け取るステップであって、前 記ファイルの少なくとも１つの属性が前記リモート記憶媒体に格納してあり、前 記ファイルの複数の属性の前記第２部分が、前記ローカル記憶媒体上に格納して あるリモート・ストレージ属性を含む、ステップと、 前記ローカル記憶媒体から前記リモート・ストレージ属性を読み出して、前記 ファイルが、前記リモート記憶媒体に格納してある少なくとも１つの属性を有す ることを確認するステップと、 から成り、前記読み出すステップが、 前記リモート・ストレージ属性内に含まれるタグを読み出すステップであって 、 該タグが前記Ｉ／Ｏ要求を処理する制御を引き受けることができる、前記複数の 層状ドライバの特定の１つを特定する、ステップと、 前記少なくとも１つの属性を格納してある、前記リモート記憶媒体内の場所を 表わす、前記リモート・ストレージ属性内に含まれる情報を読み出すステップと を含み、 前記特定の層状ドライバによって、前記リモート記憶媒体内に格納してある前 記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことができ るか否かについて判定を行うステップと、 前記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことが できる場合、前記ローカル記憶媒体から必要なあらゆる情報にアクセスすること によって、前記Ｉ／Ｏ要求を満たすステップと、 前記少なくとも１つの属性へのアクセスなく、前記Ｉ／Ｏ要求を満たすことが できない場合、前記特定の層状ドライバによって、前記リモート記憶媒体から前 記少なくとも１つの属性にアクセスすることによって、前記Ｉ／Ｏ要求を満たす ステップと、 から成ることを特徴とする方法。 ７．請求項６記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記ローカル記憶媒体から前記リモート・ストレージ属 性を読み出す前記ステップを、前記複数の層状ドライバに含まれ、前記特定の層 状ドライバとは異なる別の層状ドライバによって実行することを特徴とする方法 。 ８．請求項７記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、 前記他の層状ドライバによって前記タグを抽出するステップと、 前記特定の層状ドライバに制御を移管して、該特定の層状ドライバが、前記Ｉ ／Ｏ要求を処理する制御を引き受けることができるようにするステップと、 を含むことを特徴とする方法。 ９．請求項８記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、前記特定の層状ドライバが第１階層ストレージ・マネー ジャであり、前記複数の層状ドライバが第２階層ストレージ・マネージャを含み 、制御を移管する前記ステップが、 前記タグを前記第２階層ストレージ・マネージャに渡し、前記第２階層ストレ ージ・マネージャが前記タグに応答しないステップと、順番に、 前記タグを前記特定の層状ドライバに渡し、前記タグに基づいて、前記特定の 層状ドライバがそれ自体を、前記Ｉ／Ｏ要求を処理する責務を引き受けることが できる層状ドライバとして認識するステップと、 を含むことを特徴とする方法。 １０．Ｉ／Ｏ処理を実行する複数の層状ドライバ手段を用いるＩ／Ｏシステムに おいて、Ｉ／Ｏシステム・プリミティブとしてリモート・ファイル格納を実施す る方法であって、 Ｉ／Ｏ処理を実行する第１層状ドライバ手段によって、Ｉ／Ｏ要求を受け取っ て、１つのファイルまたは１つのディレクトリの内の少なくとも１つを伴う、指 定されたＩ／Ｏ動作を実行するステップと、 前記ファイルまたは前記ディレクトリのいずれかの前記少なくとも１つが、ロ ーカルにかつ前記ファイルまたは前記ディレクトリの内の前記少なくとも１つの ユーザ制御データ属性からも離れて格納してあるリモート・ストレージ属性を収 容することを判定することによって、前記ファイルおよび前記ディレクトリの内 の前記少なくとも１つが、リモート格納属性を有することを前記第１ドライバ手 段によって判定するステップであって、前記リモート・ストレージ属性が、 Ｉ／Ｏ処理を実行する第２層状ドライバ手段を、前記ファイルおよび前記ディ レクトリの内の前記少なくとも１つを伴うＩ／Ｏ要求を処理する制御を引き受け ることができる層状ドライバ手段として特定するタグと、 前記リモート格納属性を格納する、リモート記憶媒体内の場所を表わすリモー ト格納情報と、 を含む、前記のステップと、 前記第１層状ドライバ手段によって、前記リモート・ストレージ属性から前記 タグおよび前記リモート格納情報を抽出するステップと、 前記タグおよび前記リモート格納情報を前記第２層状ドライバ手段に渡し、前 記第２層状ドライバ手段が、前記指定したＩ／Ｏ要求を処理する制御を引き受け るステップと、 から成ることを特徴とする方法。 １１．請求項１０記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法において、前記タグおよび前記リモート格納情報を前記第 ２層状ドライバ手段に渡す前記ステップが、前記第２層状ドライバ手段が、前記 タグに基づいて、前記ファイルおよび前記ディレクトリの内の少なくとも１つを 伴うＩ／Ｏ要求を処理する制御を引き受けることができる層状ドライバ手段とし てそれ自体を認識するステップを含むことを特徴とする方法。 １２．請求項１１記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法において、前記第２ドライバ手段が、少なくとも以下のス テップ、即ち、 リモート格納情報へのアクセスなく、前記指定のＩ／Ｏ要求を満たすことがで きるか否かについて判定を行うステップと、 前記リモート格納属性へのアクセスなく、前記指定のＩ／Ｏ要求を満たすこと ができる場合、ローカル記憶媒体からの必要なあらゆる情報にアクセスすること によって、前記指定のＩ／Ｏ要求を満たすステップと、 前記リモート格納属性へのアクセスなく、前記指定のＩ／Ｏ要求を満たすこと ができない場合、前記リモート記憶媒体から前記リモート格納属性にアクセスす ることによって、前記指定のＩ／Ｏ要求を満たすステップと、 を実行することにより前記Ｉ／Ｏ要求を処理することを特徴とする方法。 １３．コンピュータ実行可能命令を有するコンピュータ読取可能媒体であって、 Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第１層状ドライバ手段であって 、 前記Ｉ／Ｏシステムが１つのファイルまたは１つのディレクトリの内の少なくと も１つを伴うＩ／Ｏ要求を受け取ったときに、リモート格納属性を有する前記フ ァイルまたは前記ディレクトリの内の前記少なくとも１つに関連する、ローカル に格納してあるリモート・ストレージ属性を読み込む手段を備え、前記リモート ・ストレージ属性が、 前記Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第２層状ドライバ手段を、 前記Ｉ／Ｏ要求の制御を引き受ける層状ドライバ手段として特定するタグと、 前記リモート格納属性を格納してあるリモート記憶媒体内の位置を表わすリモ ート格納情報と、 を含む第１層状ドライバ手段と、 前記第２層状ドライバ手段であって、前記Ｉ／Ｏ要求の制御を引き受けるよう に適合化してある、第２層状ドライバ手段と、 前記読取手段が前記リモート・ストレージ属性を読み取ったことに応答して、 前記第１層状ドライバ手段が実行しているＩ／Ｏ処理を中断する手段と、 前記Ｉ／Ｏ要求を処理する制御を、前記第１層状ドライバ手段から前記第２層 状ドライバ手段に移管して、前記タグに応答して前記Ｉ／Ｏ要求の処理の制御を 前記第２層状ドライバ手段が引き受けるようにする手段と、 を備えることを特徴とするコンピュータ読取可能媒体。 １４．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第１層状ドライバ手段が、前記リモート格納情報を前記第 ２層状ドライバ手段に渡す手段を備えることを特徴とするコンピュータ読取可能 媒体。 １５．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第２層状ドライバ手段が、前記タグに応答して、前記第２ 層状ドライバ手段自体が前記Ｉ／Ｏ要求を処理する制御を引き受けることができ ると判定する手段を備えることを特徴とするコンピュータ読取可能媒体。 １６．請求項１４記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、 前記第２層状ドライバ手段が、第１階層ストレージ・マネージャであり、前記 第１層状ドライバ手段が第１指定値を有するタグをリモート・ストレージ属性か ら読み出したときに、前記第２層状ドライバ手段がＩ／Ｏ要求を処理する制御を 引き受け、 前記コンピュータ実行可能命令が、更に、前記第１層状ドライバ手段が第２指 定値を有するタグをリモート・ストレージ属性から読み出したときに、Ｉ／Ｏ要 求を処理する制御を引き受ける第２階層ストレージ・マネージャを備える、 ことを特徴とするコンピュータ読取可能媒体。 １７．複数のデータ・フィールドを格納してあり、データ構造を表わすコンピュ ータ読取可能媒体であって、 前記データ構造を格納するために割り当てた記憶アドレスの範囲の第１領域内 に格納してある第１データ・フィールド集合であって、該第１データ・フィール ド集合がユーザ属性を格納し、ユーザが前記ユーザ属性を検索するためにアクセ ス可能な、第１データ・フィールド集合と、 前記データ構造を格納するために割り当てた記憶アドレスの前記範囲の第２領 域内に格納してある第２データ・フィールド集合であって、前記第２データ・フ ィールド集合が、前記データ構造のＩ／Ｏシステム属性を格納し、前記Ｉ／Ｏシ ステム属性が、Ｉ／Ｏシステム内に含まれる複数の層状ドライバの１つ以上によ るアクセスに適合化してある、第２データ・フィールド集合と、 を備え、 前記第２データ・フィールド集合が、 リモート・ストレージ属性を格納可能なリモート・ストレージ属性データ・フ ィールドを備え、 前記リモート・ストレージ属性が、 前記複数の層状ドライバの１つを、他のリモート・コンピュータ読取可能媒体 上に格納すべき、前記データ構造の部分を選択可能な指定ドライバとして特定す るタグと、 前記部分を格納すべき、前記他のリモート・コンピュータ読取可能媒体内の位 置を表わす情報を格納する手段と、 を備えること、を特徴とするコンピュータ読取可能媒体。 １８．請求項１７記載のコンピュータ読取可能媒体において、前記情報が、前記 指定ドライバに、必要な場合に、前記データ構造の前記部分を突き止めかつ検索 することを可能にすることを特徴とするコンピュータ読取可能媒体。 １９．請求項１８記載のコンピュータ読取可能媒体において、情報を格納する前 記手段が、前記他のリモート記憶媒体上に格納してある前記データ構造の前記部 分を識別する情報を備えることを特徴とするコンピュータ読取可能媒体。』

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ， ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，Ｌ Ｓ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ， ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，Ｅ Ｅ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，Ｍ Ｄ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ， ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 ミラー，トーマス・ジェイ アメリカ合衆国ワシントン州98004，ベル ビュー，ノース・イースト・フォーティセ ヴンス・ストリート 9015 (72)発明者 アンドリュー，ブライアン・ディー アメリカ合衆国ワシントン州98052，レッ ドモンド，ワンハンドレッドフォーティシ ックスス・アベニュー・ノース・イースト 7706

Claims (1)

1. 【特許請求の範囲】 １．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステム の一体部分として、リモート・ファイル格納を実施する方法であって、前記Ｉ／ Ｏシステムが、複数の属性から成るファイルを伴うＩ／Ｏ要求を処理し、前記属 性の第１部分がユーザ制御データを格納するために適合化してあり、前記属性の 第２部分が前記Ｉ／Ｏシステムによる使用のために適合化してあり、前記方法が 、 リモートに格納すべきファイルの前記第１部分または前記第２部分のいずれか に格納してある少なくとも１つの属性を識別するステップと、 前記Ｉ／Ｏシステムにアクセス可能な前記リモート記憶媒体に、前記識別した 属性の少なくとも一部を格納するステップと、 前記Ｉ／Ｏシステムが前記リモート格納属性の位置を突き止めることを可能に する情報を前記第２部分に格納し、前記Ｉ／Ｏシステムが、前記第２部分を検査 することによって、リモート格納属性を直接識別し、その位置を突き止めること を可能にするステップと、 から成ることを特徴とする方法。 ２．請求項１記載のリモート・ファイル格納を実施する方法において、前記Ｉ／ Ｏシステムが前記リモート格納属性の位置を突き止めることを可能にする情報を 前記第２部分に格納する前記ステップが、少なくとも、 前記第２部分に、リモートに格納すべき少なくとも１つの属性を識別する前記 ステップを実行する責務を負う、複数の層状ドライバの１つを特定する手段を格 納するステップと、 前記リモートに格納すべき少なくとも１つの属性と、該少なくとも１つの属性 を格納する前記リモート記憶媒体内の場所とを識別するために、前記第２部分に 、前記複数の層状ドライバの前記１つが所望するあらゆる情報を格納する手段を 格納するステップと、 を実行することによって、遂行することを特徴とする方法。 ３．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、少なくとも１つの属性を識別する前記ステップと、前記 識別した属性の少なくとも一部を格納する前記ステップを、前記Ｉ／Ｏシステム の一体部分を形成する複数の層状ドライバの少なくとも１つによって実行するこ とを特徴とする方法。 ４．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、ローカル・ストレージから前記ファイルの属性を 読み出し、１つ以上の属性をリモートに格納すべきか判定するために、十分な情 報を使用可能とするステップを含むことを特徴とする方法。 ５．請求項１記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記識別した属性の少なくとも一部を格納する前記ステ ップは、Ｉ／Ｏ処理を実行する第１ドライバ手段によって実行し、該第１ドライ バ手段は、少なくとも（１）リモートに格納すべき情報を抽出するステップと、 （２）前記抽出した情報を、Ｉ／Ｏ処理を実行する第２ドライバ手段に送るステ ップとを実行することによって、前記識別した属性の少なくとも一部を格納する 前記ステップを実行することを特徴とする方法。 ６．ローカルおよびリモート記憶媒体双方へのアクセスを有するＩ／Ｏシステム の一体部分として、リモート・ファイル格納を実施する方法であって、前記Ｉ／ Ｏシステムが、複数の属性から成るファイルを伴うＩ／Ｏ要求を処理し、前記属 性の第１部分が、ユーザ制御データを格納するために適合化してあり、前記属性 の第２部分が、前記Ｉ／Ｏシステムによる使用のために適合化してあり、前記方 法が、 前記ローカル記憶媒体上に少なくとも一部が格納されているファイルへのアク セスを要求するＩ／Ｏ要求を受け取るステップと、 前記ローカル記憶媒体から、前記ファイルの属性の前記第２部分から少なくと も１つの属性を読み出し、前記ファイルが、前記リモート記憶媒体に格納した属 性を有するか否か確認するステップと、 前記ファイルが、前記リモート記憶媒体に格納した属性を有する場合、少なく とも以下のステップ、即ち、 前記Ｉ／Ｏ要求は、前記リモート・ストレージ内に格納した属性へのアクセス なく、満たすことができるか否かについて判定を行うステップと、 前記リモート・ストレージ内に格納した属性へのアクセスなく、前記Ｉ／Ｏ要 求を満たすことができる場合、前記ローカル記憶媒体からあらゆる必要な情報を 読み出し、前記ローカル記憶媒体にあらゆる必要な情報を書き込むことによって 前記Ｉ／Ｏ要求を満たし、次いで前記方法を終了するステップと、 前記リモート・ストレージ内に格納した属性へのアクセスなく、前記Ｉ／Ｏ要 求を満たすことができない場合、前記リモート記憶媒体からあらゆる必要な情報 を読み出し、前記リモート記憶媒体にあらゆる必要な情報を書き込むことによっ て前記Ｉ／Ｏ要求を満たすステップと、 を実行するステップと、 から成ることを特徴とする方法。 ７．請求項６記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、前記ローカル記憶媒体から少なくとも１つの属性を読み 出す前記ステップは、Ｉ／Ｏ処理を実行する第１ドライバ手段によって実行し、 前記Ｉ／Ｏ要求は、前記リモート・ストレージ内に格納した属性へのアクセスな く、満たすことができるか否かについて判定を行う前記ステップは、Ｉ／Ｏ処理 を実行する第２ドライバ手段によって実行することを特徴とする方法。 ８．請求項７記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法であって、更に、 前記第２ドライバ手段を前記Ｉ／Ｏ要求を処理すべきドライバ手段として特定 する、前記ファイルの属性の前記第２部分に格納してある情報を、前記第１ドラ イバ手段によって抽出するステップと、 前記第２ドライバ手段が前記Ｉ／Ｏ要求の処理を続けることができるように、 前記第２ドライバ手段に制御を移管するステップと、 を含むことを特徴とする方法。 ９．請求項８記載のＩ／Ｏシステムの一体部分としてリモート・ファイル格納を 実施する方法において、制御を移管する前記ステップが、前記第２ドライバ手段 がそれ自体を、前記Ｉ／Ｏ要求を処理する責務を引き受けるべきドライバ手段と して認識するまで、複数のドライバ手段の各々に、前記抽出した情報を順に受け 渡すステップから成ることを特徴とする方法。 １０．Ｉ／Ｏ処理を実行する複数のドライバ手段を用いるＩ／Ｏシステムにおい て、Ｉ／Ｏシステム・プリミティブとして、リモート・ファイル格納を実施する 方法であって、 Ｉ／Ｏ処理を実行する第１ドライバ手段が、Ｉ／Ｏ要求を受け取り、少なくと も１つのファイルまたはディレクトリのいずれかを伴う、指定されたＩ／Ｏ動作 を実行するステップと、 前記第１ドライバ手段が、前記少なくとも１つのファイルまたはディレクトリ のいずれかが、あらゆるユーザ制御データとは別個に格納してあるリモート・ス トレージ属性を、前記少なくとも１つのファイルまたはディレクトリのいずれか に収容しているか否か確認することによって、前記少なくとも１つのファイルま たはディレクトリのいずれかが、リモート格納情報を有するか否か確認し、 前記少なくとも１つのファイルまたはディレクトリのいずれかが、リモート格 納情報を収容している場合、前記第１ドライバが、少なくとも以下のステップ、 即ち、 前記リモート格納属性からリモート格納情報を抽出するステップと、 前記抽出したリモート格納情報を、処理のために第２ドライバに渡すステップ と、 を実行すること、 を特徴とする方法。 １１．請求項１０記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法であって、更に、Ｉ／Ｏ処理を実行する第２ドライバ手段 が、抽出したリモート格納情報を受け取り、前記Ｉ／Ｏ要求を処理する責務を引 き受けるステップを含むことを特徴とする方法。 １２．請求項１１記載のＩ／Ｏシステム・プリミティブとしてリモート・ファイ ル格納を実施する方法において、前記第２ドライバ手段が、少なくとも以下のス テップ、即ち、 前記Ｉ／Ｏ要求は、リモート格納情報へのアクセスなく、満たすことができる か否かについて判定を行うステップと、 リモート格納情報へのアクセスなく、前記Ｉ／Ｏ要求を満たすことができる場 合、前記Ｉ／Ｏシステムにアクセス可能なローカル記憶媒体からあらゆる必要な 情報を読み出し、前記ローカル記憶媒体にあらゆる必要な情報を書き込むことに よって前記Ｉ／Ｏ要求を満たし、次いで前記方法を終了するステップと、 リモート格納情報へのアクセスなく、前記Ｉ／Ｏ要求を満たすことができない 場合、前記リモート格納情報が位置するリモート記憶媒体からあらゆる必要な情 報を読み出し、前記リモート記憶媒体にあらゆる必要な情報を書き込むことによ って前記Ｉ／Ｏ要求を満たすステップと、 を実行することにより、前記Ｉ／Ｏ要求を処理することを特徴とする方法。 １３．コンピュータ実行可能命令を有するコンピュータ読取可能媒体であって、 Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第１ドライバ手段であって、リ モート格納属性を有する少なくとも１つのファイルまたはディレクトリのいずれ かを伴うＩ／Ｏ要求の少なくとも部分的な処理を実行するように適合化してある 、第１ドライバ手段と、 前記Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第２ドライバ手段と、 前記第２ドライバ手段が備え、Ｉ／Ｏ要求が前記少なくとも１つのファイルま たはディレクトリを伴う場合、前記第２ドライバ手段が前記要求のＩ／Ｏ処理を 完全に完了する前に、前記第２ドライバ手段によって前記要求のＩ／Ｏ処理を中 断する手段と、 前記Ｉ／Ｏ要求を処理する制御を、前記第２ドライバ手段から前記第１ドライ バ手段に移管し、前記第１ドライバ手段に前記Ｉ／Ｏ要求を処理させ続ける手段 と、 を備えることを特徴とするコンピュータ読取可能媒体。 １４．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体であって、更に、前記第１ドライバ手段と前記第２ドライバ手段との間で Ｉ／Ｏ処理要求を受け渡す手段を備えることを特徴とするコンピュータ読取可能 媒体。 １５．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第２ドライバ手段が、前記少なくとも１つのファイルまた はディレクトリのいずれかに関連するリモート格納情報を前記第１ドライバ手段 に渡す手段を備えることを特徴とするコンピュータ読取可能媒体。 １６．請求項１５記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記リモート格納情報がタグと値とから成り、前記タグが前記 リモート格納情報を所有するドライバ手段のＩＤを示し、前記値がリモート格納 属性を突き止めるために前記オーナが必要とするデータから成ることを特徴とす るコンピュータ読取可能媒体。 １７．請求項１３記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第１ドライバ手段が、前記第１ドライバ手段が受信するリ モート格納情報は当該第１ドライバ手段が所有することを確認する手段を備える ことを特徴とするコンピュータ読取可能媒体。 １８．請求項１７記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記確認する手段が、前記リモート格納情報のタグを検査し、 前記第１ドライバ手段が前記リモート格納情報を所有するか否か確認することを 特徴とするコンピュータ読取可能媒体。 １９．コンピュータ実行可能命令を有するコンピュータ読取可能媒体であって、 Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第１ドライバ手段であって、リ モート格納属性を有する少なくとも１つのファイルまたはディレクトリのいずれ かを伴うＩ／Ｏ要求の少なくとも部分的な処理を実行するように適合化してある 、第１ドライバ手段と、 前記Ｉ／ＯシステムにおいてＩ／Ｏ処理を実行する第２ドライバ手段と、 前記第１ドライバ手段と前記第２ドライバ手段との間でＩ／Ｏ処理要求を受け 渡す手段と、 前記第２ドライバ手段が備え、Ｉ／Ｏ要求が前記少なくとも１つのファイルま たはディレクトリを伴う場合、前記第２ドライバ手段が前記要求のＩ／Ｏ処理を 完全に完了する前に、前記第２ドライバ手段によって前記要求のＩ／Ｏ処理を中 断する手段と、 前記Ｉ／Ｏ要求を処理する制御を、前記第２ドライバ手段から前記第１ドライ バ手段に移管し、前記第１ドライバ手段に前記Ｉ／Ｏ要求を処理させ続ける手段 と、 を備えることを特徴とするコンピュータ読取可能媒体。 ２０．請求項１９記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第２ドライバ手段が、前記少なくとも１つのファイルまた はディレクトリに関連するリモート格納情報を、前記第１ドライバ手段に渡す手 段を備えることを特徴とするコンピュータ読取可能媒体。 ２１．請求項２０記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記第１ドライバ手段が、前記第１ドライバ手段が受信するリ モート格納情報は当該第１ドライバ手段が所有することを確認する手段を備える ことを特徴とするコンピュータ読取可能媒体。 ２２．請求項２１記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記リモート格納情報がタグと値とから成り、前記タグが前記 リモート格納情報を所有するドライバ手段のＩＤを示し、前記値がリモート格納 属性を突き止めるために前記オーナが必要とするデータから成ることを特徴とす るコンピュータ読取可能媒体。 ２３．請求項２２記載のコンピュータ実行可能命令を有するコンピュータ読取可 能媒体において、前記確認する手段が、前記タグを検査し、前記第１ドライバ手 段が前記リモート格納情報を所有するか否か確認することを特徴とするコンピュ ータ読取可能媒体。 ２４．複数のデータ・フィールドを記憶し、データ構造を表わすコンピュータ読 取可能媒体であって、 前記データ構造を格納するために割り当てた記憶アドレスの範囲の第１領域内 に格納してある第１データ・フィールド集合であって、ユーザ・データを格納す るために使用可能であり、ユーが内部に格納してあるデータを検索するためにア クセス可能な第１データ・フィールド集合であって、 前記ユーザによって内部に格納したデータを収容する、前記第１領域内に格納 した第１データ・フィールド、 を備える、第１データ・フィールド集合と、 前記データ構造を格納するために割り当てた記憶アドレスの前記範囲の第２領 域内に格納してある第２データ・フィールド集合であって、前記データ構造の種 々の属性を格納するために使用可能であり、前記属性はドライバ手段が前記デー タ構造に関連するＩ／Ｏ要求を処理するためのアクセスに適合化してある、該第 ２データ・フィールド集合であって、 リモート・ストレージ属性を表わすデータを収容する、前記第２領域内に格納 した第３データ・フィールド、 を備える第２データ・フィールド集合と、 を備え、 前記第３データ・フィールドが、 リモート格納データを管理するドライバ手段を特定する手段と、 前記ドライバ手段が前記データ構造のリモート格納データ・フィールドを管理 するために用いる情報を格納する手段と、 を備えること、を特徴とするコンピュータ読取可能媒体。 ２５．請求項２４記載のコンピュータ読取可能媒体において、前記情報を格納す る手段が、各リモート格納データ・フィールドがどこに格納されているのか確認 し、前記ドライバ手段が、必要なときに、前記リモート格納データ・フィールド を突き止めかつこれを検索可能とする情報を備えることを特徴とするコンピュー タ読取可能媒体。 ２６．請求項２５記載のコンピュータ読取可能媒体において、前記情報を格納す る手段が、前記データ構造の前記データ・フィールドの内どれをリモートに格納 してあるのかを確認する情報を備えることを特徴とするコンピュータ読取可能媒 体。