(57)【特許請求の範囲】
【請求項１】
データファイルオブジェクト（１３４〜１３６）へのアクセス方法であって、
クライアント装置（１０４〜１０６）上に提供されたファイルシステムインタフェースは、前記クライアント装置（１０４〜１０６）上で動作するアプリケーションが前記データファイルオブジェクト（１３４〜１３６）にアクセスするために、ファイルシステムコールを実行可能にすることであって、前記ファイルシステムインタフェースは更に、前記クライアント装置のカーネルアドレス空間に仮想ファイルシステムを有することと；
前記クライアント装置（１０４〜１０６）上に提供されたウェブサービスインタフェースは、前記ファイルシステムインタフェースを通じて前記データファイルオブジェクト（１３４〜１３６）がアクセスされている際に、前記アプリケーションがウェブを使用して前記データファイルオブジェクト（１３４〜１３６）にアクセスすることを可能にすることと；
前記仮想ファイルシステムは、前記データファイルオブジェクトを管理するように前記クライアント装置のユーザアドレス空間に設けられたレイアウトマネージャに、カーネルメモリアドレス空間とユーザメモリアドレス空間との間のブリッジを使用してアクセスすることと
を備え、
前記方法はさらに、格納システムでの複数のファイルを管理するために、前記格納システムでの少なくとも一つのメタデータ位置サーバを提供することであって、前記格納システムは、互いに接続されつつ独立の複数のサーバを有し、前記メタデータ位置サーバは複数のファイルＩＤを伴うテーブルを有し、それぞれ前記ファイルＩＤは、メタデータサーバに格納されるメタデータファイルオブジェクトへのポインタを有するとともに、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むことと；
ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトを含む前記メタデータサーバにアクセスするために、少なくとも１つの前記メタデータ位置サーバから情報を得ることによって、ファイルのうちの特定の１つにアクセスすることであって、前記同期および非同期ミラーは、前記メタデータ位置サーバに対して独立なデータサーバに提供され、前記メタデータサーバは、前記メタデータ位置サーバに対して独立でありかつ前記データサーバに対して独立であることと
を有することを特徴とする、データファイルオブジェクトへのアクセス方法。
【請求項２】
前記ウェブサービスインタフェースは、ＳＯＡＰインタフェースとＲＥＳＴインタフェースとのうちの少なくとも一つを備える、
請求項１記載のアクセス方法。
【請求項３】
前記アクセス方法は更に、前記クライアント装置（１０４〜１０６）上に提供されたダイレクトファイルオブジェクトインタフェースが、前記ウェブサービスインタフェースと前記ファイルシステムインタフェースによって前記データファイルオブジェクト（１３４〜１３６）がアクセスされているのと同時に、前記アプリケーションが前記データファイルオブジェクト（１３４〜１３６）に直接アクセスすることを可能にすることを備える、
請求項１記載のアクセス方法。
【請求項４】
前記アクセス方法は更に、ファイル名をファイルオブジェクトＩＤに変換すべく提供されたファイル名サービスが、前記ファイルシステムインタフェースと前記ウェブサービスインタフェースとのうちの少なくとも１つによってアクセスされること可能にすることを備える、
請求項１記載のアクセス方法。
【請求項５】
ファイルオブジェクト（１３４〜１３６）にアクセスするクライアント装置であって、前記クライアント装置は、
前記クライアント装置上で動作するアプリケーションによってファイルシステムが、データファイルオブジェクトにアクセスするためにファイルシステムコールすることを実行可能にするファイルシステムインタフェースであって、前記ファイルシステムインタフェースは、前記クライアント装置のカーネルアドレス空間に仮想ファイルシステムを有することと；
前記ファイルオブジェクトが前記ファイルシステムインタフェースを介してアクセスされている際に、前記アプリケーションがウェブを使用して前記ファイルオブジェクトにアクセスすることを実行可能にするウェブサービスインタフェースと；
前記ファイルシステムインタフェースと前記ウェブサービスインタフェースとに連結される通信インタフェースであって、前記通信インタフェースは、前記クライアント装置と複数のサーバとの間で、前記ファイルオブジェクトを有するファイルオブジェクトデータを交換することと；
前記ファイルオブジェクトを管理するレイアウトマネージャであって、前記レイアウトマネージャは前記クライアント装置のユーザアドレス空間に設けられ、前記仮想ファイルシステムは、カーネルメモリアドレス空間とユーザメモリアドレス空間との間のブリッジを使用して、前記レイアウトマネージャにアクセスすることと
を備え、
前記クライアント装置はさらに、格納システムでの複数のファイルを管理するために、前記格納システムでの少なくとも一つのメタデータ位置サーバを提供することであって、前記格納システムは、互いに接続されつつ独立の複数のサーバを有し、前記メタデータ位置サーバは複数のファイルＩＤを伴うテーブルを有し、それぞれ前記ファイルＩＤは、メタデータサーバに格納されるメタデータファイルオブジェクトへのポインタを有するとともに、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むことと；
ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトを含む前記メタデータサーバにアクセスするために、少なくとも１つの前記メタデータ位置サーバから情報を得ることによって、ファイルのうちの特定の１つにアクセスすることであって、前記同期および非同期ミラーは、前記メタデータ位置サーバに対して独立なデータサーバに提供され、前記メタデータサーバは、前記メタデータ
位置サーバに対して独立でありかつ前記データサーバに対して独立であることと
を実行するように構成されることを特徴とする、クライアント装置。
【請求項６】
前記クライアント装置は更に、ダイレクトファイルオブジェクトインタフェースを備え、
前記ダイレクトファイルオブジェクトインタフェースは、前記ウェブサービスインタフェースと前記ファイルシステムインタフェースとによって前記ファイルオブジェクトがアクセスされているのと同時に、前記アプリケーションが前記ファイルオブジェクトに直接アクセスすることを可能にする、
請求項５記載のクライアント装置。
【請求項７】
前記クライアント装置は更に、ファイル名をファイルオブジェクトＩＤに変換するファイル名サービス装置を備え、
前記ファイル名サービス装置は、前記ファイルシステムインタフェースと前記ウェブサービスインタフェースとのうちの少なくとも１つによってアクセスされる、
請求項５記載のクライアント装置。
【請求項８】
コンピュータに以下の手順を実行させるためのプログラムであって、前記プログラムは、
クライアント装置（１０４〜１０６）上で動作するアプリケーションが、ファイルシステムインタフェースを使用してデータファイルオブジェクト（１３４〜１３６）にアクセスするためにファイルシステムコールすることを実行可能にする手順であって、前記ファイルシステムインタフェースは、前記クライアント装置のカーネルアドレス空間に仮想ファイルシステムを有することと；
前記ファイルシステムインタフェースを通じて前記データファイルオブジェクト（１３４〜１３６）がアクセスされている際に、前記アプリケーションがウェブを使用して前記データファイルオブジェクト（１３４〜１３６）にアクセスすることを可能にする手順と；
前記クライアント装置のユーザアドレス空間に設けられるレイアウトマネージャが、前記データファイルオブジェクトを管理し、カーネルメモリアドレス空間とユーザメモリアドレス空間との間のブリッジを使用して、前記レイアウトマネージャはアクセスされることを可能にする手順と；
格納システムでの複数のファイルを管理するために、前記格納システムでの少なくとも一つのメタデータ位置サーバを提供する手順であって、前記格納システムは、互いに接続されつつ独立の複数のサーバを有し、前記メタデータ位置サーバは複数のファイルＩＤを伴うテーブルを有し、それぞれ前記ファイルＩＤは、メタデータサーバに格納されるメタデータファイルオブジェクトへのポインタを有するとともに、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含む手順と；
ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトを含む前記メタデータサーバにアクセスするために、少なくとも１つの前記メタデータ位置サーバから情報を得ることによって、ファイルのうちの特定の１つにアクセスする手順であって、前記同期および非同期ミラーは、前記メタデータ位置サーバに対して独立なデータサーバに提供され、前記メタデータサーバは、前記メタデータ位置サーバに対して独立でありかつ前記データサーバに対して独立である手順とをコンピュータに実行させることを特徴とする、プログラム。
【請求項９】
前記プログラムは更に、前記ウェブと前記ファイルシステムコールとによって前記データファイルオブジェクト（１３４〜１３６）がアクセスされているのと同時に、前記アプリケーションが前記データファイルオブジェクト（１３４〜１３６）に直接アクセスすることを可能にする手順をコンピュータに実行させる、
請求項８記載のプログラム。
【請求項１０】
前記プログラムは更に、ファイル名をファイルオブジェクトＩＤに変換する手順をコンピュータに実行させる、請求項８記載のプログラム。
【請求項１１】
ファイルシステムインタフェースとウェブサービスインタフェースとを使用して、複数のファイルオブジェクト（１３４〜１３６）に同時にアクセスすることを実行可能にするシステムであって、前記システムは、
前記ファイルオブジェクトを有する複数のサーバと；
前記サーバに連結される少なくとも一つのクライアント装置と
を備え、前記クライアント装置は、
前記クライアント装置上で動作するアプリケーションによってファイルシステムが、データファイルオブジェクトにアクセスするためにファイルシステムコールすることを実行可能にする前記ファイルシステムインタフェースであって、前記ファイルシステムインタフェースは、前記クライアント装置のカーネルアドレス空間に仮想ファイルシステムを有することと；
前記ファイルオブジェクトが前記ファイルシステムインタフェースを介してアクセスされている際に、前記アプリケーションがウェブを使用して前記ファイルオブジェクトにアクセスすることを実行可能にする前記ウェブサービスインタフェースと；
前記ファイルシステムインタフェースと前記ウェブサービスインタフェースとに連結される通信インタフェースであって、前記通信インタフェースは、前記クライアント装置と複数のサーバとの間で、前記ファイルオブジェクトを有するファイルオブジェクトデータを交換することと；
前記ファイルオブジェクトを管理するレイアウトマネージャであって、前記レイアウトマネージャは前記クライアント装置のユーザアドレス空間に設けられ、前記仮想ファイルシステムは、カーネルメモリアドレス空間とユーザメモリアドレス空間との間のブリッジを使用して、前記レイアウトマネージャにアクセスすることと
を備え、
前記システムはさらに、格納システムでの複数のファイルを管理するために、前記格納システムでの少なくとも一つのメタデータ位置サーバを提供することであって、前記格納システムは、互いに接続されつつ独立の複数のサーバを有し、前記メタデータ位置サーバは複数のファイルＩＤを伴うテーブルを有し、それぞれ前記ファイルＩＤは、メタデータサーバに格納されるメタデータファイルオブジェクトへのポインタを有するとともに、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むことと；
ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトを含む前記メタデータサーバにアクセスするために、少なくとも１つの前記メタデータ位置サーバから情報を得ることによって、ファイルのうちの特定の１つにアクセスすることであって、前記同期および非同期ミラーは、前記メタデータ位置サーバに対して独立なデータサーバに提供され、前記メタデータサーバは、前記メタデータ位置サーバに対して独立でありかつ前記データサーバに対して独立であることと
を実行するように構成されることを特徴とする、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、データを格納する分野に関し、特に拡張性のある高容量システムにおけるデータ格納サービスの分野に関する。
【背景技術】
【０００２】
２００６年に作成され、キャプチャされ、複製されたデジタル情報の量は、１６１エクサバイトまたは１６１０億ギガバイトであったと推測されており、それは今まで書かれたすべての本の情報の約３００万倍である。２００６年〜２０１０年の間、デジタル宇宙モデルに毎年加えられる情報は、１６１エクサバイトから９８８エクサバイトまで６倍以上に増加するであろうと予測されている。この圧倒的な成長の要因になっている情報のタイプは、豊富なデジタル媒体および非体系的なビジネスコンテンツである。更にアナログからデジタル形式への進行中の変換もある（フィルムからのデジタル画像キャプチャ、アナログからのデジタル音声、およびアナログからのデジタルテレビ）。
【０００３】
豊富なデジタル媒体および非体系的なビジネスコンテンツは、構造化したデータタイプ（たとえばデータベースのレコード）とは異なる固有の特徴およびストレージ要求を有する（今日の格納システムの多くは、そのために特別に設計されている）。多くの従来の格納システムは、小さな塊のデータに対する高機能Ｉ／Ｏを実現させるために高度に最適化されている。更にこれらのシステムは、ギガバイトおよびテラバイトサイズの情報格納をサポートするように設計されている。
【０００４】
これに対して、豊富なデジタル媒体および非体系的なビジネスコンテンツは、より大きな容量要件（ペタバイト対ギガバイト／テラバイトサイズのシステム）、より小さい予測可能な拡張およびより少ないアクセスパターン、大きなファイルサイズ、何十億ものオブジェクト、高処理能力要件、単一のライタ、複数のリーダアクセスパターン、およびマルチプラットフォームアクセシビリティの必要性を有する。従来の格納システムは、必要なレベルの性能および信頼性を達成するために、専用のハードウェアプラットフォームを使用してこれらの必要性の一部を満たしてきた。不運にも、専用ハードウェアの使用は、より高いクライアント価格に帰着し、容量要件が大きくなると共に（豊富なデジタル媒体および非体系的なビジネスコンテンツの分化する特徴）、量的経済性をサポートしないことがある。
【０００５】
コスト問題のうちの幾つかは、層状のストレージによって対処されており、それは単一の高コストな格納層上にすべての情報を維持することに関連した資本的コストおよび運転コストを低減することを試みている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第６，８８９，３０９号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、層状ストレージは、判断環境技術、データ耐久性、機能、および格納ベンダなどの複雑な組合せを伴う。層状ストレージの解決策は、データ量の増加と共に拘束される非零の運転コストおよび管理要件を有する無関係なプラットフォーム、技術、およびソフトウェアタイトルを導入することがある。
【０００８】
加えて、層状ストレージは、データの複製を矛盾させることがあり、それはストレージの層に亘って存在する情報の複数のコピーをバラバラにする。たとえばデータのバックアップおよび回復を扱う格納管理ソフトウェアは、各格納層の情報セットの複数のコピーを作ることが可能である（たとえばスナップショット、バックアップのセットなど）。或る層から別の層への情報移動を扱う情報ライフサイクル管理（ＩＬＭ）ソフトウェアは、データの付加的な、そして多くの場合、重複したコピーを作成することがある。複製ソフトウェアは、アクセスするアプリケーションに対する性能を増大させるために、特定層内に情報セットの余分なコピーを作ることがある。これらの機能のそれぞれは、典型的には、１つの機能から別の機能へと自主的に動作する。そのソフトウェアは、同一の情報セットの複数の複製の利点を実現および／または利用することが可能である。
【０００９】
加えて、大規模の非体系的な情報格納に対して、システムを維持し、コンポーネントが故障したときに環境を管理するのは難しいことがある。たとえば２ペタバイトの情報格納は、８０００個の２５０ギガバイトのディスクドライブで構成可能である。ディスク障害は、この規模のシステムにおける異なる方法で扱われるべきであり、その結果、本システムは、１つまたは少数だけのディスクドライブが故障する都度、比較的滑らかに動作し続ける。
【００１０】
従って、高コストの専用ハードウェア、格納層、および障害管理に関する困難に対処する格納システムを提供することが望ましい。
【課題を解決するための手段】
【００１１】
ここで記述される本システムによれば、ファイルを管理することは、新規ファイルに対する複数のポリシーを受信することであって、互いに異なるポリシーが所定条件によって適用されることがあることと；新規ファイルを作成する要求を受信することと；所定条件にかかる新規ファイルに対する適切ポリシーを選択することと；十分なリソースが適切ポリシーによって利用可能であるか否か判断することと；ファイルオブジェクトを、それらが適切ポリシーにかかる十分なリソースであることに応じてファイルを作成するために、得ることとを含む。ポリシーは、ユーザ管理インタフェースを介して受信可能である。所定条件は、ファイルを作成するクライアントの識別情報を含むことが可能である。適切ポリシーは、ファイルに対するミラーに関する情報を含むことが可能である。適切ポリシーは、ミラー間の最小の地理的距離を示すことが可能である。十分なリソースが利用可能であるか否か判断することは、リソースマネージャに尋ねることを含むことが可能である。リソースマネージャは、システムリソースに関する情報を受信し、それを示すテーブルを維持する。システムリソースは、データ格納領域を備えることが可能である。
【００１２】
更にここで記述される本システムによれば、コンピュータ読取可能媒体に提供されるコンピュータソフトウェアは、ファイルを管理する。本ソフトウェアは、新規ファイルに対する複数のポリシーを受信する実行可能なコードであって、互いに異なるポリシーが所定条件によって適用されることがあることと、新規ファイルを作成する要求を受信する実行可能なコードと；所定条件にかかる新規ファイルに対する適切ポリシーを選択する実行可能なコードと；十分なリソースが適切ポリシーによって利用可能であるか否か判断する実行可能なコードと；ファイルオブジェクトを、それらが適切ポリシーにかかる十分なリソースであることに応じてファイルを作成するために、得る実行可能なコードとを含む。ポリシーは、ユーザ管理インタフェースを介して受信可能である。所定条件は、ファイルを作成するクライアントの識別情報を含むことが可能である。適切ポリシーは、ファイルに対するミラーに関する情報を含むことが可能である。適切ポリシーは、ミラー間の最小の地理的距離を示すことが可能である。十分なリソースが利用可能であるか否か判断する実行可能なコードは、リソースマネージャに尋ねる実行可能なコードを含むことが可能であ
る。リソースマネージャは、システムリソースに関する情報を受信し、それを示すテーブルを維持する実行可能なコードを含むことが可能である。システムリソースは、データ格納領域を備えることが可能である。
【００１３】
更にここで記述される本システムによれば、データ格納システムは、ファイルにアクセスする複数のクライアントを備える。またデータ格納システムは、クライアントに結合された複数の相互接続したサーバと；新規ファイルに対する複数のポリシーを受信するサーバのサブセットであって、互いに異なるポリシーが所定条件によって適用されることがあることと；新規ファイルを作成する要求を受信するサーバのサブセットと；所定条件にかかる新規ファイルに対する適切ポリシーを選択するサーバのサブセットと；十分なリソースが適切ポリシーによって利用可能であるか否か判断するサーバのサブセットと；ファイルオブジェクトを、それらが適切ポリシーにかかる十分なリソースであることに応じてファイルを作成するために、得るサーバのサブセットとを備えている。ポリシーは、ユーザ管理インタフェースを介して受信可能である。所定条件は、ファイルを作成するクライアントの識別情報を含むことが可能である。適切ポリシーは、ファイルに対するミラーに関する情報を含むことが可能である。サーバは、十分なリソースが利用可能であるか否か判断するために尋ねられるサーバのサブセットを含む。十分なリソースが利用可能であるか否か判断するために尋ねられるサーバのサブセットは、システムリソースに関する情報を受信し、それを示すテーブルを維持する。システムリソースは、データ格納領域を備えることが可能である。
【００１４】
更にここで記述される本システムによれば、ファイルオブジェクトを管理することは、ファイルオブジェクトに対する複数のポリシーを受信することであって、互いに異なるポリシーが所定条件によって適用されることがあることと；新規ファイルオブジェクトを得るための要求を受信することと；所定条件にかかる新規ファイルオブジェクトに適切ポリシーを選択することと；十分なリソースが適切ポリシーによって利用可能であるか否か判断することと；およびファイルオブジェクトを、それらが適切ポリシーにかかる十分なリソースであることに応じて、得ることとを含む。
【００１５】
更にここで記述される本システムによれば、データ格納システムは、ファイルオブジェクトにアクセスする複数のクライアントを備える。またデータ格納システムは、クライアントに結合された複数の相互接続したサーバと；新規ファイルオブジェクトに対する複数のポリシーを受信するサーバのサブセットであって、互いに異なるポリシーが所定条件によって適用されることがあることと；新規ファイルオブジェクトを得るための要求を受信するサーバのサブセットと；所定条件にかかる新規ファイルオブジェクトに対する適切ポリシーを選択するサーバのサブセットと；十分なリソースが適切ポリシーによって利用可能であるか否か判断するサーバのサブセットと；ファイルオブジェクトを、それらが適切ポリシーにかかる十分なリソースであることに応じて、得るサーバのサブセットとを備えている。
【００１６】
更にここで記述される本システムによれば、複数のファイルを管理することは、複数のファイルＩＤを持つテーブルを有する少なくとも１つのサーバを提供することを含む。ファイルＩＤのそれぞれは、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクト（ＬＳＯ）を含むメタデータファイルオブジェクトへのポインタを含む。ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトにアクセスするために、少なくとも１つのサーバから情報を得ることによって、ファイルのうちの特定１つにアクセスすることを含む。各レイアウト格納オブジェクトは、ツリーとして提供可能である。ツリーの葉が、対応するファイルの論理アドレスを、データ格納位置にマッピングすることが可能である。ツリーのうちの少なくとも１つの内部ノードは、その少なくとも１つの葉ノードがその他の葉ノードのミラーである
ことを示すことが可能である。データ書込と、第１葉ノードが第２葉ノードの非同期ミラーであることを示す内部ノードとに応じて、データは、第１葉ノードに書込まれることが可能である。更新メッセージは、少なくとも１つのサーバに提供可能である。
【００１７】
更に複数のファイルを管理することは、少なくとも１つのサーバが、メッセージに対応するキューに関する情報を配置し、第２葉ノードにデータを書込むためのキューのサービスを提供することを含むことが可能である。データ書込と、第１葉ノードが第２葉ノードの同期ミラーであることを示す内部ノードとに応じて、データは、第１葉ノードおよび第２葉ノードに書込まれることが可能である。データへのアクセスが成功しなかったことに応じて、ミラーは、アクセス可能である。レイアウト格納オブジェクトは、対応するファイルに対する論理アドレス空間を、物理的なデータストレージに対応するデータ格納空間にマッピングするデータファイルオブジェクトへのポインタを備えることが可能である。各データファイルオブジェクトは、データファイルオブジェクトが最新、別のデータオブジェクトの未更新のミラー、不変、および無効のうちの１つであることを示す状態を有することが可能である。不変であるデータファイルオブジェクトへの書込の試行に応じて、新しい格納空間が割付けられることが可能である。データは、新しい格納空間に書込まれることが可能である。無効であるデータファイルオブジェクトの読出の試行に応じて、零が返されることが可能である。
【００１８】
更にここで記述される本システムによれば、コンピュータ読取可能媒体に提供されるコンピュータソフトウェアは、複数のファイルを管理する。本ソフトウェアは、複数のファイルＩＤを有するテーブルを管理する少なくとも１つのサーバに提供される実行可能なコードを含む。ファイルＩＤのそれぞれは、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むメタデータファイルオブジェクトへのポインタを含む。本ソフトウェアは、ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトにアクセスするために、少なくとも１つのサーバから情報を得ることによって、ファイルのうちの特定１つにアクセスする実行可能なコードを含む。各レイアウト格納オブジェクトは、ツリーとして提供可能である。ツリーの葉は、対応するファイルの論理アドレスを、データ格納位置にマッピングすることが可能である。ツリーのうちの少なくとも１つの内部ノードは、少なくとも１つの葉ノードがその他の葉ノードのミラーであることを示すことが可能である。データ書込と、第１葉ノードが第２葉ノードの非同期ミラーであることを示す内部ノードとに応じて、実行可能なコードは、データを第１葉ノードに書込ませ、更新メッセージを少なくとも１つのサーバに提供することが可能である。
【００１９】
少なくとも１つのサーバの実行可能なコードは、メッセージに対応するキューに関する情報を配置し、第２葉ノードにデータを書込むためのキューのサービスを提供することが可能である。データ書込と、第１葉ノードが第２葉ノードの同期ミラーであることを示す内部ノードとに応じて、実行可能なコードは、第１葉ノードおよび第２葉ノードにデータを書込むことが可能である。更にコンピュータソフトウェアは、データへのアクセスが成功しなかったことに応じて、ミラーにアクセスする実行可能なコードを含むことが可能である。レイアウト格納オブジェクトは、対応するファイルに対する論理アドレス空間を、物理的なデータストレージに対応するデータ格納空間にマッピングするデータファイルオブジェクトへのポインタを含むことが可能である。各データファイルオブジェクトは、データファイルオブジェクトが最新、別のデータオブジェクトの未更新のミラー、不変、および無効のうちの１つであることを示す状態を有することが可能である。更にコンピュータソフトウェアは、新しい格納空間を割付け、不変であるデータファイルオブジェクトへの書込の試行に応じて、データを新しい格納空間に書込む実行可能なコードを含むことが可能である。更にコンピュータソフトウェアは、無効であるデータファイルオブジェクトの読出の試行に応じて、零を返す実行可能なコードを含むことが可能である。
【００２０】
更にここで記述される本システムによれば、複数のファイルを管理することは、複数のファイルＩＤを有する少なくとも１つのサーバを提供することを含む。ファイルＩＤのそれぞれは、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むメタデータファイルオブジェクトへのポインタを含む。本システムは、どのようにファイルに対するデータが格納および取出されるか判断する特定ファイルに対応するレイアウト格納オブジェクトにアクセスする少なくとも１つのサーバから得た情報によってファイルのうちの特定１つにアクセスすることを含む。
【００２１】
更にここで記述される本システムによれば、データ格納システムは、複数のサーバを備える。少なくとも１つのサーバは、複数のファイルＩＤを有するテーブルを有する。ファイルＩＤのそれぞれは、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むメタデータファイルオブジェクトへのポインタを含む。本システムは、ファイルに対する同期および非同期ミラーを判断すべく特定ファイルに対応するレイアウト格納オブジェクトにアクセスするために、少なくとも１つのサーバから情報を得ることによって、ファイルのうちの特定１つにアクセスする複数のクライアントを備えている。
【００２２】
更にここで記述される本システムによれば、データ格納システムは、複数のサーバを備える。少なくとも１つのサーバは、複数のファイルＩＤを有する。ファイルＩＤのそれぞれは、対応するファイルに対する格納パラメータを示すレイアウト格納オブジェクトを含むメタデータファイルオブジェクトへのポインタを含む。本システムは、どのようにファイルに対するデータが格納および取出されるか判断する特定ファイルに対応するレイアウト格納オブジェクトにアクセスするために、少なくとも１つのサーバから得た情報によってファイルのうちの特定１つにアクセスする複数のクライアントを備えている。
【００２３】
更にここで記述される本システムによれば、データ格納システムにおいてファイルオブジェクトを管理することは、複数のメタデータサーバを提供することを含む。各メタデータサーバは、格納システムにおけるファイルオブジェクトのサブセットのみに対する情報を有する。メタデータサーバのそれぞれに対する各サブセットは、本システムに対するファイルオブジェクトの総数未満である。また本システムは、少なくとも１つのメタデータ位置サーバを提供することを含む。本システムの特定ファイルオブジェクトにアクセスするエンティティ（実体）は、どのメタデータサーバが少なくとも１つのメタデータ位置サーバにまずアクセスすることによって、特定ファイルオブジェクトに対するデータを含むか判断する。ファイルオブジェクトのサブセットに対する情報は、ファイルＩＤおよびメタデータ位置情報を有するテーブルを含むことが可能である。メタデータ位置情報は、ファイルに対するメタデータオブジェクトに対してのデータストレージを指すことが可能である。更にテーブルは、ファイルオブジェクトに対する読出許可を有するエンティティおよびファイルオブジェクトへの書込許可を有するエンティティを示すリース情報を含むことが可能である。ファイルオブジェクトは、固有のオブジェクトＩＤを含むことが可能である。少なくとも１つのメタデータ位置サーバは、ファイルオブジェクトに対するオブジェクト識別値にかかるファイルオブジェクトに使用するのに適切なメタデータサーバを判断することが可能である。メタデータサーバのうちの少なくとも幾つかは、オブジェクト識別値のサブセットをファイルオブジェクトに相関させるテーブルを維持することが可能である。メタデータサーバのうちの少なくとも幾つかは、新規ファイルオブジェクトに割当てるためのオブジェクト識別値の固有のサブセットを含むことが可能である。
【００２４】
更にここで記述される本システムによれば、コンピュータ読取可能媒体に提供されるコンピュータソフトウェアは、データ格納システムにおいてファイルオブジェクトを管理する。本ソフトウェアは、複数のメタデータサーバ上に提供され、格納システムにおけるフ
ァイルオブジェクトのサブセットのみに対する情報を維持する実行可能なコードを含む。メタデータサーバのそれぞれに対する各サブセットは、本システムに対するファイルオブジェクトの総数未満である。また本ソフトウェアは、少なくとも１つのメタデータ位置サーバ上に提供され、どのメタデータサーバが特定ファイルオブジェクトに対するデータを含むかの表示を、少なくとも１つのメタデータサーバに提供された要求に応じて提供する実行可能なコードを含む。ファイルオブジェクトのサブセットに対する情報は、ファイルＩＤおよびメタデータ位置情報を有するテーブルを含むことが可能である。メタデータ位置情報は、ファイルに対するメタデータオブジェクトに対してのデータストレージを指すことが可能である。更にテーブルは、ファイルオブジェクトに対する読出許可を有するエンティティおよびファイルオブジェクトへの書込許可を有するエンティティを示すリース情報を含むことが可能である。ファイルオブジェクトは、固有のオブジェクトＩＤを備えることが可能である。少なくとも１つのメタデータ位置サーバは、ファイルオブジェクトに対するオブジェクト識別値にかかるファイルオブジェクトに使用するのに適切なメタデータサーバを判断する実行可能なコードを含むことが可能である。メタデータサーバのうちの少なくとも幾つかは、オブジェクト識別値のサブセットをファイルオブジェクトに相関させるテーブルを維持することが可能である。メタデータサーバのうちの少なくとも幾つかは、新規ファイルオブジェクトに割当てるためのオブジェクト識別値の固有のサブセットを備えることが可能である。
【００２５】
更にここで記述される本システムによれば、データ格納システムは、格納システムのファイルオブジェクトにアクセスする複数のクライアントと、該クライアントに結合された複数の相互接続したサーバとを備える。該サーバは、複数のメタデータサーバを備える。各メタデータサーバは、格納システムにおけるファイルオブジェクトのサブセットのみに対する情報を有する。メタデータサーバのそれぞれに対する各サブセットは、本システムに対するファイルオブジェクトの総数未満である。更にサーバは、少なくとも１つのメタデータ位置サーバを備える。本システムの特定ファイルオブジェクトにアクセスするクライアントは、少なくとも１つのメタデータ位置サーバにまずアクセスすることによって、どのメタデータサーバが特定ファイルオブジェクトに対するデータを含むか判断する。ファイルオブジェクトのサブセットに対する情報は、ファイルＩＤおよびメタデータ位置情報を有するテーブルを含むことが可能である。メタデータ位置情報は、ファイルに対するメタデータオブジェクトに対してのデータストレージを指すことが可能である。ファイルオブジェクトは、固有のオブジェクトＩＤを備えることが可能である。少なくとも１つのメタデータ位置サーバは、ファイルに対するファイルオブジェクトに対してのオブジェクト識別値にかかるファイルオブジェクトに使用するのに適切なメタデータサーバを判断することが可能である。メタデータサーバのうちの少なくとも幾つかは、オブジェクト識別値のサブセットをファイルオブジェクトに相関させるテーブルを維持することが可能である。メタデータサーバのうちの少なくとも幾つかは、新規ファイルオブジェクトに割当てるためのオブジェクト識別値の固有のサブセットを備えることが可能である。
【００２６】
更にここで記述される本システムによれば、データ格納システムにおいてファイルオブジェクトを管理することは、複数の第１タイプのサーバを提供することを含む。そのそれぞれは、格納システムにおけるファイルオブジェクトのサブセットのみに対する情報を有する。また本システムは、第２タイプの少なくとも１つのサーバにまずアクセスすることによって、どの第１タイプのサーバが特定ファイルオブジェクトに対するデータを含むかを示す情報を提供する第２タイプのサーバのうちの少なくとも１つを提供することを含む。
【００２７】
更にここで記述される本システムによれば、データ格納システムは、格納システムのファイルオブジェクトにアクセスする複数のクライアントを備える。また本システムは、クライアントに結合された複数の相互接続したサーバを備える。該サーバは、複数のメタデ
ータサーバを備える。各メタデータサーバは、格納システムにおけるファイルオブジェクトのサブセットのみに対する情報を有する。メタデータサーバのそれぞれに対する各サブセットは、本システムに対するファイルオブジェクトの総数未満である。更にサーバは、少なくとも１つのメタデータ位置サーバを含む。本システムの特定ファイルにアクセスするクライアントは、少なくとも１つのメタデータ位置サーバにまずアクセスすることによって、どのメタデータサーバが特定ファイルオブジェクトに対するデータを含むか判断する。
【００２８】
更にここで記述される本システムによれば、トラッキング格納リソースは、格納リソースと共に能力および状態を含むテーブルを提供することと；格納リソースの状態の変化に応じてテーブルを更新することと；格納リソースの能力の変化に応じてテーブルを更新することと；および特定能力を有する格納リソースに対する問合せに応じて、特定能力を有する格納リソースに対するテーブルを探索することとを含む。更にトラッキング格納リソースは、本システムに加えられる新しいリソースに応じて、テーブルに要素を加えることを含むことが可能である。能力は、ＲＡＩＤストリッピング、データ複製、および省電力動作を含むことが可能である。状態は、オンライン、オフライン、フルのうちの１つであることが可能である。格納リソースは、ディスクドライブであることが可能である。ディスクドライブは、ディスクドライブのためのオンスクリーンディスプレイインタフェースを提示するデータ格納サーバによって管理可能である。テーブルは、他のサーバから格納リソースに関する情報を受信するリソースマネージャサーバによって維持可能である。
【００２９】
更にここで記述される本システムによれば、コンピュータ読取可能な記憶媒体に提供されるコンピュータソフトウェアは、格納リソースを追跡する。ソフトウェアは、能力および状態と共に格納リソースを含むテーブルを備え、格納リソースの状態の変化に応じてテーブルを更新する実行可能なコードと；格納リソースの能力の変化に応じてテーブルを更新する実行可能なコードと；特定能力を有する格納リソースに対する問合せに応じて、特定能力を有する格納リソースに対するテーブルを探索する実行可能なコードとを備えている。更にソフトウェアは、本システムに加えられる新しいリソースに応じてテーブルに要素を加える実行可能なコードを含むことが可能である。能力は、ＲＡＩＤストリッピング、データ複製、および省電力動作を含むことが可能である。状態は、オンライン、オフライン、フルのうちの１つであることが可能である。格納リソースは、ディスクドライブであることが可能である。ディスクドライブは、ディスクドライブのためのオンスクリーンディスプレイインタフェースを提示するデータ格納サーバによって管理可能である。テーブルは、他のサーバから格納リソースに関する情報を受信するリソースマネージャサーバによって維持可能である。
【００３０】
更にここで記述される本システムによれば、格納システムに対する格納リソースを管理するリソースマネージャは、処理装置と該処理装置に結合されたコンピュータ読取可能メモリを備える。該コンピュータ読取可能メモリは、データ構造に提供されたテーブルを有し、能力および状態と共に格納リソースを含む。更にコンピュータ読取可能メモリは、格納リソースの状態の変化に応じてテーブルを更新する実行可能なコードと；格納リソースの能力の変化に応じてテーブルを更新する実行可能なコードと；特定能力を有する格納リソースに対する問合せに応じて特定能力を有する格納リソースに対するテーブルを探索する実行可能なコードとを有する。更にコンピュータ読取可能メモリは、本システムに加えられる新しいリソースに応じてテーブルに要素を加える実行可能なコードを含むことが可能である。能力は、ＲＡＩＤストリッピング、データ複製、および省電力動作を含むことが可能である。状態は、オンライン、オフライン、フルのうちの１つであることが可能である。格納リソースは、ディスクドライブであることが可能である。ディスクドライブは、ディスクドライブのためのオンスクリーンディスプレイインタフェースを提示するデータ格納サーバによって管理可能である。
【００３１】
更にここで記述される本システムによれば、データ格納システムは、複数のクライアントと、該クライアントに結合された複数のサーバとを備える。サーバのサブセットは、能力および状態と共に格納リソースを含むテーブルを使用して格納リソースを管理する。サブセットは、格納リソースの状態の変化に応じてテーブルを更新し；格納リソースの能力の変化に応じてテーブルを更新し；特定能力を有する格納リソースに対する問合せに応じて特定能力を有する格納リソースに対するテーブルを探索する。サーバのサブセットは、本システムに加えられる新しいリソースに応じてテーブルに要素を加えることが可能である。格納リソースは、ディスクドライブであることが可能である。
【００３２】
更にここで記述される本システムによれば、データ格納システムのリソースマネージャに情報を提供することは、格納リソースの能力の変化に応じてリソースマネージャに情報を提供することと；格納リソースの状態の変化に応じてリソースマネージャに情報を提供することと；新しい格納リソースを加えることに応じてリソースマネージャに情報を提供することとを含む。格納リソースは、ディスクドライブであることが可能である。
【００３３】
更にここで記述される本システムによれば、データファイルオブジェクトにアクセスすることは、少なくとも１つのクライアント上にファイルシステムインタフェースを提供することを含む。該ファイルシステムインタフェースは、少なくとも１つのクライアント上で動作するアプリケーションがデータファイルオブジェクトにアクセスするためにファイルシステムにコールさせることを可能にする。またデータファイルオブジェクトにアクセスすることは、少なくとも１つのクライアント上にウェブサービスインタフェースを提供することを含む。該ウェブインタフェースは、ファイルオブジェクトがファイルシステムインタフェースを通じてアクセスされるのと同時に、ウェブ使用してアプリケーションがファイルオブジェクトにアクセスすることを可能にする。ウェブサービスインタフェースは、ＳＯＡＰインタフェースおよび／またはＲＥＳＴインタフェースであることが可能である。更にデータファイルオブジェクトにアクセスすることは、少なくとも１つのクライアント上にダイレクトファイルオブジェクトインタフェースを提供することを含むことが可能である。該ダイレクトファイルオブジェクトインタフェースは、ファイルオブジェクトがウェブサービスインタフェースを使用し、且つファイルシステムインタフェースを使用してアクセスされているのと同時に、ファイルオブジェクトに直接アクセスすることを可能にする。
【００３４】
更にデータファイルオブジェクトにアクセスすることは、ファイル名をファイルオブジェクトＩＤに変換するファイル名サービスを提供することを含むことが可能である。該ファイル名サービスは、ファイルシステムインタフェースおよび／またはウェブサービスインタフェースによってアクセスされる。ファイルシステムインタフェースを提供することは、少なくとも１つのクライアントのカーネルアドレス空間において仮想ファイルシステムを提供することを含むことが可能である。更にデータファイルオブジェクトにアクセスすることは、ファイルオブジェクトを管理するレイアウトマネージャを提供することを含むことが可能である。レイアウトマネージャは、少なくとも１つのクライアントのカーネルアドレス空間に提供可能である。レイアウトマネージャは、少なくとも１つのクライアントのユーザアドレス空間に提供される。仮想ファイルシステムは、カーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジを使用してレイアウトマネージャにアクセスすることが可能である。
【００３５】
更にここで記述される本システムによれば、複数のファイルオブジェクトにアクセスするクライアントは、少なくとも１つのクライアント上で動作するアプリケーションがファイルシステムをデータファイルオブジェクトにアクセスさせるためにコール可能にするファイルシステムインタフェースと；ファイルオブジェクトがファイルシステムインタフェ
ースを通じてアクセスされるのと同時に、アプリケーションがウェブを使用してファイルオブジェクトにアクセスすることを可能にするウェブサービスインタフェースと；ファイルシステムインタフェースおよびウェブサービスインタフェースに結合され、クライアントとファイルオブジェクトを含む複数のサーバとの間のファイルオブジェクトデータを交換する通信インタフェースとを備えている。更にクライアントは、ファイルオブジェクトがウェブサービスインタフェースを使用し、且つファイルシステムインタフェースを使用してアクセスされるのと同時に、アプリケーションがファイルオブジェクトに直接アクセスすることを可能にするダイレクトファイルオブジェクトインタフェースを備えることが可能である。更にクライアントは、ファイル名をファイルオブジェクトＩＤに変換するファイル名サービスを備えることが可能である。該ファイル名サービスは、ファイルシステムインタフェースおよび／またはウェブサービスインタフェースによってアクセスされる。ファイルシステムインタフェースは、少なくとも１つのクライアントのカーネルアドレス空間における仮想ファイルシステムを備えることが可能である。更にクライアントは、ファイルオブジェクトを管理するレイアウトマネージャを備えることが可能である。該レイアウトマネージャは、少なくとも１つのクライアントのカーネルアドレス空間に提供可能である。レイアウトマネージャは、少なくとも１つのクライアントのユーザアドレス空間に提供可能である。仮想ファイルシステムは、カーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジを使用してレイアウトマネージャにアクセスすることが可能である。
【００３６】
更にここで記述される本システムによれば、コンピュータ読取可能な記憶媒体に提供されるコンピュータソフトウェアは、少なくとも１つのクライアント上で動作するアプリケーションがファイルシステムに、データファイルオブジェクトにアクセスするためにコールさせることを可能にする実行可能なコードを含む。またファイルオブジェクトがファイルシステムインタフェースを通じてアクセスされるのと同時に、アプリケーションがウェブを使用してファイルオブジェクトにアクセスすることを可能にする実行可能なコードを含む。更にコンピュータソフトウェアは、ファイルオブジェクトがウェブを使用し、且つファイルシステムコールを使用してアクセスされるのと同時に、アプリケーションがファイルオブジェクトに直接アクセスすることを可能にする実行可能なコードを含むことが可能である。更にコンピュータソフトウェアは、ファイル名をファイルオブジェクトＩＤに変換する実行可能なコードを含むことが可能である。
【００３７】
更にここで記述される本システムによれば、システムは、ファイルシステムインタフェースおよびウェブサービスインタフェースを使用して複数のファイルオブジェクトにアクセスすることを同時に可能にする。本システムは、ファイルオブジェクトを含む複数のサーバと；サーバに結合された少なくとも１つのクライアントとを備えている。クライアントは、少なくとも１つのクライアント上で動作するアプリケーションがデータファイルオブジェクトにアクセスするためにファイルシステムにコールさせることを可能にするファイルシステムインタフェースと；ファイルオブジェクトがファイルシステムインタフェースを通じてアクセスされるのと同時に、アプリケーションがウェブを使用してファイルオブジェクトにアクセスすることを可能にするウェブサービスインタフェースと；ファイルシステムインタフェースおよびウェブサービスインタフェースに結合され、クライアントとファイルオブジェクトを含む複数のサーバとの間のファイルオブジェクトデータを交換する通信インタフェースとを備えている。ファイルシステムインタフェースは、クライアントのカーネルアドレス空間における仮想ファイルシステムを備えることが可能である。
【００３８】
更にここで記述される本システムによれば、データファイルに対するオブジェクトを管理することは、ファイルに対するメタデータオブジェクトを得ることと；データファイルの一部が同期ミラーを含むことをメタデータオブジェクトが示すか否か判断することと；およびデータファイルへの新しいデータの書込に応じて、各同期ミラーに新しいデータを
書込むこととを含む。データファイルのデータオブジェクトは、最新、古い、空、および不変の４つの状態のうちの１つであることが可能である。読出動作および対応するデータオブジェクトが古い状態であることに応じて、データは、最新状態である対応する同期ミラーに対して読出可能である。
【図面の簡単な説明】
【００３９】
【図１】本システムの実施形態にかかる、サーバおよびクライアントの図。
【図２Ａ】本実施形態の、サーバと他のネットワークに結合されたクライアントの図。
【図２Ｂ】本実施形態の、サーバと他のネットワークに結合されたクライアントの図。
【図３】本実施形態の、サーバ動作ソフトウェア、クライアントソフトウェア、およびそれらの間の複数のインタフェースを有するクライアントの図。
【図４】本実施形態の、メタデータファイルオブジェクトおよび複数のデータファイルオブジェクトを有するファイルの図。
【図５】本実施形態の、ファイルに対するメタデータファイルオブジェクトの図。
【図６】本実施形態の、ファイルに対するレイアウト格納オブジェクトツリーの例の図。
【図７】本実施形態の、ファイルに対する複数のマップを有するレイアウト格納オブジェクトツリーの例の図。
【図８】本実施形態の、ファイルに対する複数のマップおよび複製ノードを有するレイアウト格納オブジェクトツリーの別例の図。
【図９】本実施形態の、ファイルに対するリースを得て、該ファイル上で動作するクライアントを示すフローチャート。
【図１０】本実施形態の、ファイルからデータを読出すクライアントを示すフローチャート。
【図１１】本実施形態の、ファイルにデータを書込むクライアントを示すフローチャート。
【図１２】本実施形態の、データの代替コピーを見つけることに関連してクライアントによって実行されるステップを示すフローチャート。
【図１３】本実施形態の、データに対する同期ミラーに書込むクライアントを示すフローチャート。
【図１４】本実施形態の、ファイル名をオブジェクトＩＤに変換するクライアントを示すフローチャート。
【図１５】本実施形態の、ユーザメモリアドレス空間においてアプリケーションを有し；カーネルメモリアドレス空間において仮想ファイルシステム（ＶＦＳ）、ファイル名サービス、カーネルＩ／Ｏドライバ、レイアウトマネージャ、および通信インタフェースを有するクライアントの図。
【図１６】本実施形態の、クライアントでの仮想ファイルシステムの動作を示すフローチャート。
【図１７】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において通信インタフェースを有するクライアントの図。
【図１８】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ファイルプレゼンテーションレイヤ、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において仮想ファイルシステム、通信インタフェース、およびカーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジを有するクライアントの図。
【図１９】本実施形態の、ユーザメモリアドレス空間においてアプリケーションを有し；カーネルアドレス空間においてファイル名サービス、カーネルＩ／Ｏドライバ、レイアウトマネージャ、および通信インタフェースを有するクライアントの図。
【図２０】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において通信インタフェースを有するクライアントの図。
【図２１】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において通信インタフェースと、カーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジとを有するクライアントの図。
【図２２】本実施形態の、ユーザメモリアドレス空間においてアプリケーションを有し；カーネルメモリアドレス空間においてウェブサービスモジュール、カーネルＩ／Ｏドライバ、レイアウトマネージャ、および通信インタフェースを有するクライアントの図。
【図２３】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ウェブサービス層、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において通信インタフェースを有するクライアントの図。
【図２４】本実施形態の、ユーザメモリアドレス空間においてアプリケーション、ウェブサービス層、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において通信インタフェースと、カーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジとを有するクライアントの図。
【図２５】本実施形態の、ユーザメモリアドレス空間において複数のアプリケーション、ウェブサービス層、ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有し；カーネルメモリアドレス空間において仮想ファイルシステム、通信インタフェース、およびカーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジを有するクライアントの図。
【図２６】本実施形態の、互いに異なるタイプのサーバおよびユーザ管理インタフェースの図。
【図２７】本実施形態の、ポリシーマネージャサーバを使用する資格を得るためにセキュリティマネージャサーバを使用することに関連して実行されるステップを示すフローチャート。
【図２８】本実施形態の、リソースマネージャテーブルの図。
【図２９】本実施形態の、リソーステーブルを更新するためにリソース情報を処理することに関連して実行されるステップを示すフローチャート。
【図３０】本実施形態の、所望の能力を有するリソースを見つけることに関連して実行されるステップを示すフローチャート。
【図３１】本実施形態の、リース要求のサービスを提供するメタデータサーバに関連して実行されるステップを示すフローチャート。
【図３２】本実施形態の、期限切れのリースを監視および再コールすることに関連して実行されるステップを示すフローチャート。
【図３３】本実施形態の、リース再コール処理に関連して実行されるステップを示すフローチャート。
【図３４】本実施形態の、メタデータサーバによって扱われるファイルに対して維持されるデータを示すテーブル。
【図３５】本実施形態の、メタデータサーバによって扱われるファイルリースのためのリンクリスト。
【図３６】本実施形態の、オブジェクトＩＤおよびデータ格納位置を相関連させるためにメタデータサーバによって維持されるデータを示すテーブル。
【図３７】本実施形態の、オブジェクトＩＤレンジおよびメタデータサーバを相関させるメタデータ位置サーバでのテーブルを示す。
【図３８】本実施形態の、特定メタデータサーバを返すことに関連してメタデータ位置サーバによって実行される処理を示すフローチャート。
【図３９】本実施形態の、ファイルを削除することに関連してメタデータサーバによって実行される処理を示すフローチャート。
【図４０】本実施形態の、ファイルを作成することに関連してメタデータサーバによって実行される処理を示すフローチャート。
【図４１】本実施形態の、障害データ書込動作に応答することに関連してメタデータサーバによって実行される処理を示すフローチャート。
【図４２】本実施形態の、古いミラー更新メッセージに応答することに関連してメタデータサーバによって実行される処理を示すフローチャート。
【図４３】本実施形態の、非同期複製ジョブをキューに加えることに関連してメタデータサーバによって実行される処理を示すフローチャート。
【図４４】本実施形態の、非同期複製ジョブのサービスを提供することに関連してメタデータサーバによって実行される処理を示すフローチャート。
【発明を実施するための形態】
【００４０】
図１は、複数のクライアント１０４〜１０６に結合されたサーバ１０２を示す。クライアント１０４〜１０６のそれぞれは、ファイルサービスをサーバ１０２から受ける一または複数の処理装置を表わす。クライアント１０４〜１０６のそれぞれは、クライアント１０４〜１０６の他のものから独立していても独立していなくてもよい。クライアント１０４〜１０６のうちの一または複数は、多重処理／マルチユーザシステムであることが可能であり、複数の独立したユーザを有する可能性がある。クライアント１０４〜１０６は、任意の数のクライアントを代表することを意味している。
【００４１】
サーバ１０２によって提供されるファイルサービスは、データ格納および取出し、更には、データミラーリングおよびクローニングなどの関連動作を含むことが可能である。サーバ１０２は、相互接続した処理および／または格納装置によって提供される複数のサービス（および／またはＳＡＮコンポーネントを含む相互接続したファイルサーバ）を利用して実施可能である。本実施形態では、クライアント１０４〜１０６のそれぞれは、恐らくローカルのＴＣＰ／ＩＰ接続と共に、ウェブを使用してサーバ１０２に結合可能である。しかし、ここで記述される機能を提供するために任意の他の適切な通信機構および／またはその組合せを使用して、クライアント１０４〜１０６のうちの一または複数をサーバ１０２に結合することができる。
【００４２】
図２Ａに示すように、クライアント１０４は、サーバ１０２および一または複数の他のネットワークに結合されているものとして示されている。他のネットワークは、ローカルエリアネットワーク（ＬＡＮ）を含むことが可能である。従って、クライアント１０４は、サーバ１０２と一または複数の他の装置（図示せず）が結合されることもあるＬＡＮとの間のゲートウェイであることが可能である。クライアント１０４は、サーバ１０２から一または複数の他の装置にデータを提供することによって、ＬＡＮに結合された一または複数の他の装置へのローカルファイルサーバとして作用することが可能である。勿論、一または複数の他のクライアントが同一のまたは異なる他のネットワークへのゲートウェイとして同時に作用することも可能である。一般に、ここでの議論のために、クライアント１０４〜１０６のうちの特定１つへの参照は、あえて示されない限り、サーバ１０２に結合されたクライアント１０４〜１０６のうちの何れかまたはすべてへの参照を含むと理解可能である。
【００４３】
図２Ｂに示すように、本図は、図２Ａに示したものとは異なる構成において、サーバ１０２および一または複数の他のネットワーク（たとえばＬＡＮ）に結合されたクライアント１０４を示す。図２Ｂの構成では、ルータ１０８は、サーバ１０２とクライアント１０４の間に結合される。ルータ１０８は、クライアント１０４によってアクセスされることがある任意の従来のルータであることが可能である。図２Ｂの構成では、クライアント１０４は、両方のサーバ１０２および他のネットワークへの単一の接続ポイントのみを使用
する。図２Ｂの構成では、クライアント１０４は、サーバ１０２と他のネットワークに結合された一または複数の他の装置（図示せず）との間のローカルファイルサーバおよびゲートウェイとして作用することが可能である。勿論、任意の他の適切な接続構成が、サーバ１０２および／または他のネットワークに結合されたクライアント１０４〜１０６のうちの何れかによって使用されることも可能である。
【００４４】
図３に示すように、クライアント１０４は、サーバ動作ソフトウェア１２２（図２の下部。図２に番号無し）、クライアントソフトウェア１２４、およびサーバ動作ソフトウェア１２２とクライアントソフトウェア１２４の間の複数のインタフェース１２６〜１２８を備えたインタフェース層１２５を有して、より詳細に示されている。サーバ動作ソフトウェア１２２は、ここで記述される機能を提供するために、クライアント１０４とサーバ１０２の間の情報／データの交換を容易にする。サーバ動作ソフトウェア１２２は、より詳細に別記される。クライアントソフトウェア１２４は、クライアント１０４上で動作することが可能な任意のソフトウェアを表わしており、サーバ動作ソフトウェア１２２またはインタフェース層１２５の一部ではないアプリケーションソフトウェア、オペレーティングシステムソフトウェア、ウェブサーバソフトウェアなどを含む。より詳細に別記されるように、クライアントソフトウェア１２４にインタフェース１２６〜１２８のうちの互いに異なるものを通じてサーバ１０２と同時に相互作用させることも可能である。
【００４５】
ここで記述されるファイルサービスは、１組のファイルオブジェクトを使用してサーバ１０２によって実施可能である。クライアントソフトウェアによってアクセスされるファイルは、ファイルに対するデータを含む一または複数のデータファイルオブジェクトを指すメタデータファイルオブジェクトを含む。ファイルにアクセスすることは、ファイルに対する対応するデータファイルオブジェクトを見つけるために、まずメタデータファイルオブジェクトにアクセスすることを含む。これをすることは、より詳細に別記される。なおしかし、任意の適切なファイルオブジェクト機構が、ここで記述される本システムに使用可能である。
【００４６】
図４に示すように、ファイル１３０は、メタデータファイルオブジェクト１３２および複数のデータファイルオブジェクトを含むものとして示されている。メタデータファイルオブジェクト１３２は、データファイルオブジェクト１３４〜１３６のそれぞれを指す情報を含む。ファイルにアクセスすることは、まずメタデータファイルオブジェクト１３２にアクセスし、次に、対応するデータファイルオブジェクト１３４〜１３６のうちの適切な一または複数のものを見つけるために、それへの情報を使用することを含む。
【００４７】
図５に示すように、メタデータファイルオブジェクト１３２は、オブジェクト属性セクション１４４およびレイアウト格納オブジェクト（ＬＳＯ）ツリーセクション１４２を含むものとして、より詳細に示されている。オブジェクト属性セクション１４４は、所有者ＩＤ、グループＩＤ、アクセス制御リスト、最終修正時刻、最終アクセス時刻、最終変更時刻、生成時刻、ファイルサイズ、およびリンク数などの従来のファイルタイプ属性を含む。属性の多くは自明である。最終修正時刻は、データファイルオブジェクト１３４〜１３６に対するデータが修正された最終時刻に対応する一方、最終変更時刻は、オブジェクトメタデータが最後に変更された時刻に対応している。リンク数は、特定ファイルを参照する他のオブジェクトの数を示す（たとえば同一ファイルを指すエイリアス）。本実施形態では、ファイルおよびそれに関連するオブジェクトは、リンク数が零までデクリメントされたときに削除される。
【００４８】
レイアウト格納オブジェクトツリーセクション１４４は、特定データファイルオブジェクトにファイルの論理空間をマッピングする一または複数のマップを含むデータ構造を備えている。更にレイアウト格納オブジェクトツリーセクション１４４は、データに対する
任意のミラー、およびミラーが同期または非同期であるかを示すことが可能である。レイアウト格納オブジェクトツリーおよびミラーは、より詳細に別記される。
【００４９】
図６に示すように、単純なレイアウト格納オブジェクトツリー１６０は、レイアウト格納オブジェクトルートノード１６２および単一のマップ１６４を含むものとして示されている。レイアウト格納オブジェクトルートノード１６２は、レイアウト格納オブジェクトツリー１６０を識別するために使用され、レイアウト格納オブジェクトツリー１６０に対応するファイルに関連して使用される一または複数のマップへのリンクを含む。マップ１６４は、ファイル内の論理位置を実際のデータ格納位置にマッピングする。レイアウト格納オブジェクトツリー１６０によって表わされるファイルの論理格納空間にアクセスする処理は、まずマップ１６４を見つけるためにレイアウト格納オブジェクトルートノード１６２を使用し、次に、ファイル内の論理アドレスを実際のデータ格納位置に変換するためにマップ１６４を使用する。
【００５０】
図７に示すように、レイアウト格納オブジェクトツリー１７０は、レイアウト格納オブジェクトルートノード１７２および複数のマップ１７４〜１７６を含むものとして示されている。マップ１７４〜１７６のそれぞれは、レイアウト格納オブジェクトツリー１７０に対応するファイル内の互いに異なる範囲の論理オフセットを表わすことが可能である。たとえばマップ１７４は、ファイル中の論理オフセットの第１範囲に対応することが可能である。マップ１７４は、第１範囲中の論理位置を実際の第１格納装置にマッピングすることが可能である。マップ１７５は、第１範囲とは異なる、ファイル中の第２範囲の論理オフセットに対応することが可能であり、それは互いに異なる実際の格納装置にマッピングされるか、またはマップ１７４と同一の実際の格納装置にマッピング可能である。同様に、マップ１７６は、第１範囲および第２範囲とは異なる、ファイル中の第３範囲の論理オフセットに対応することが可能であり、それは互いに異なる実際の格納装置にマッピングされるか、またはマップ１７４および／またはマップ１７５と同一の実際の格納装置にマッピング可能である。
【００５１】
図８に示すように、レイアウト格納オブジェクトツリー１８０は、レイアウト格納オブジェクトルートノード１８１および一対の複製ノード１８２ａ，１８２ｂを含むものとして示され、それは基礎データがミラーリングされる（複製される）ことを示し、またミラーが同期または非同期であるかを示す。同時および非同期ミラーは、より詳細に別で議論する。ノード１８２ａは、互いに関連づけられた複数の子マップ１８３〜１８５を有する一方、ノード１８２ｂは、互いに関連づけられた複数の子マップ１８６〜１８８を有する。複製ノード１８２ａ，１８２ｂは、マップ１８３〜１８５に対応するデータがマップ１８６〜１８８に対応するデータのミラーであることを示す。幾つかの実施形態では、ノード１８２ａ，１８２ｂは、複製を示すために単一のノード１８９を使用して実施可能である。
【００５２】
レイアウト格納オブジェクトツリー１８０を有するファイルにアクセスする処理は、ツリー１８０を横断し、データがミラーリングされていることを判断する。より詳細に別で議論するように、ミラーリングのタイプに依存して、レイアウト格納オブジェクトツリー１８０にアクセスする処理は、ノード１８２ａ，１８２ｂの両方の子にデータを書込むか、または非同期ミラーリングを実行する別の処理／サーバ（たとえばサーバ１０２）にメッセージを提供する。ミラーリングは、より詳細に別で議論する。
【００５３】
ここで記述される本システムでは、ファイルオブジェクトは、まずサーバ１０２からリースを要求し、それを得ることによって、クライアント１０４〜１０６のうちの１つによってアクセスされる。リースは、アクセスされる特定ファイルに対するファイルオブジェクト、およびアクセスのタイプに対応している。リースは、書込、読出、および／または
更には他の動作（たとえばファイル属性を変更すること）であることが可能である。本実施形態では、任意の特定ファイルに対応するオブジェクトに対して、サーバ１０２は、クライアント１０４〜１０６のうちの何れかに一度に１つのみの書込リースを出すことが可能であるが、複数の読出リースを同時に出し、書込リースを出すのと同時に読出リースを出すことも可能である。しかし、幾つかの実施形態では、ファイルの指定された論理範囲に対する、その範囲のみに対する動作のためのリースを得ることが可能である。このようにたとえば第１クライアントは、ファイルの第１論理範囲に書込むためのリースを得る一方、第２クライアントは、独立して同一ファイルの第２および個別の論理範囲に書込むためのリースを得ることが可能である。互いに異なる論理範囲に対する２つの書込リースは、本システムが同一のデータに対する重複した書込リースを出すことがないという原則を破ることはないが、いずれ重複することがある。
【００５４】
サーバ１０２からクライアント１０４〜１０６に提供されるリースは、クライアントがデータへの適切なアクセスを可能にするセキュリティ情報（セキュリティトークン）を含む。セキュリティトークンは、或る時間後に期限切れになることがある。本実施形態では、クライアントは、データに対する適切なセキュリティトークンのほか、クライアントユーザ／所有者情報を提供することによってデータにアクセスする。このようにたとえばデータにアクセスしたいユーザは、まずリースを得て、次に、データにアクセスする所有者（クライアント）を識別するセキュリティトークンおよび情報と共にサーバ１０２にアクセス要求を提供する。その後、サーバ１０２は、クライアントによって要求されたアクセスが許容可能であるか否か判断する。リースが期限切れになった後（セキュリティトークンは期限切れになる）、ユーザは、再びリースを要求する。データセキュリティは、従来のデータセキュリティ機構を使用して実施可能である。
【００５５】
ファイルにアクセスするためのリースを得た後、クライアントは、レイアウト格納オブジェクトツリーを含む対応するメタデータをクライアントのローカルストレージにキャッシュすることが可能である。その後、クライアントは、メタデータのローカルにキャッシュしたバージョンを使用および操作し、データにアクセスするためにメタデータを使用することが可能である。より詳細に別記されるように、クライアントは、サーバ１０２によって格納されたメタデータを直接修正はしないが、代わりに、ファイルに対するメタデータがサーバ１０２によって修正される必要があるという信号を送るためにサーバ１０２に更新メッセージを送る。
【００５６】
図９に示すように、フローチャート２００は、クライアント上で動作を実行するためにファイル（ファイルに関連づけたオブジェクト）に対するリースを要求することに関連してクライアントによって実行されるステップを示す。処理は、最初のステップＳ２０２で始まり、クライアントが、ファイルに対するリースを要求する。より詳細に別で議論するように、リースを要求するクライアントは、アクセスのタイプ（たとえば読出、書込など）を指定することを含む。ステップＳ２０２に続くのは検査ステップＳ２０４であり、要求が与えられているか否かが判断される。ＮＯの場合、制御は、検査ステップＳ２０４からステップＳ２０６に移行し、処理が、クライアントに与えられていないリースに関連して実行される。ステップＳ２０６で実行される特定処理は、たとえばリースに対応するファイルへのアクセスを要求するクライアント処理にエラーメッセージを提供すること、および／または或る時間待機し、次に、要求を再試行することを含むことが可能である。なおかつて利用可能ではなかった特定ファイルに対するリースは、その後の別の時に利用可能である。なぜならば、たとえばリースが、第１要求と第２要求の間で別のクライアントによって解除されるからである。いずれにしても、任意の適切な処理が、ステップＳ２０６で実行されることが可能である。ステップＳ２０６に続いて処理は終了する。
【００５７】
ステップＳ２０２で要求されたリースが与えられたと検査ステップＳ２０４で判断した
場合、制御は、検査ステップＳ２０４からステップＳ２０８に移行し、リースが与えられたファイルを使用してクライアントが動作を実行する。ステップＳ２０８で実行される動作は、データを読出すこと、および／またはデータを書込むことを含む。ステップＳ２０８で実行されることが可能である互いに異なるタイプの処理は、より詳細に別記される。
【００５８】
ステップＳ２０８に続くのは検査ステップＳ２１２であり、ステップＳ２０８で実行された動作が更新を要求するか否か判断する。幾つかの例では、クライアントは、リースを得て、ファイルまたは下層のファイルオブジェクトに影響しない動作を実行可能である。たとえばクライアントは、ファイルを読出すためのリースを取得することが可能であり、ステップＳ２０８で実行される動作は、クライアントがファイルを読出すことを含むことが可能である。そのような場合、ファイルおよび対応するファイルオブジェクト（メタデータ、データオブジェクトなど）は変更されていないので、更新は必要ではないことがある。一方、クライアントがデータを書込むためのリースを得た場合、ステップＳ２０８で実行されるファイルおよび動作は、ファイルにデータを書込むことを含む。次に、下層のファイルオブジェクトが変更され、更新メッセージがサーバ１０２に送られる必要がある。更新が必要であると検査ステップＳ２１２で判断した場合、制御は、検査ステップＳ２１２からステップＳ２１４に移行し、更新メッセージがクライアントによってサーバ１０２に送られる。
【００５９】
ステップＳ２１４に続いて、または更新が必要ではない場合にステップＳ２１２に続いて、制御は、検査ステップＳ２１６に移行し、クライアントがファイルを終えたか否か判断する。幾つかの例では、クライアントは、ファイル上で少数の動作を実行可能であり、その後、クライアントは、ステップＳ２１６でファイルを終える。他の場合では、クライアントは、一連の動作を実行可能であるが、すべての動作を完了しているとは限らない。
【００６０】
クライアントがファイルを終えていないと検査ステップＳ２１６で判断した場合、制御は、検査ステップＳ２１６から検査ステップＳ２１８に移行し、ファイルに対するリースが期限切れか否か判断する。なおリースは、特定期限および／または関連するセキュリティトークンが期限切れになることがあると共に、サーバ１０２によってクライアントに提供可能である。加えて、サーバ１０２は、或る状況下でクライアントに提供されるリースを再コールすることが可能である。いずれの場合も、リースは、もはや有効ではないことがある。従って、リースが期限切れになった（および／またはサーバ１０２によって再コールされた）とステップＳ２１８で判断した場合、制御は、検査ステップＳ２１８からステップＳ２０２に戻り、再びリースを要求する。一方、リースが期限切れではない場合、制御は、検査ステップＳ２１８からステップＳ２０８に戻り、別の反復を実行する。
【００６１】
クライアントがファイルを終えたと検査ステップＳ２１６で判断した場合、制御は、検査ステップＳ２１６からステップＳ２２２に移行し、クライアントは、クライアントがもはやリースを必要としないことを示すメッセージをサーバ１０２に送ることによってリースを解除する。一旦クライアントがリースを解除すれば、それは他のクライアントに利用可能になることが可能である。ステップＳ２２２に続いて処理は終了する。
【００６２】
本実施形態では、データファイルオブジェクトは、最新、古い、不変、または空の４つの可能な状態のうちの１つを有するものとして示されることがある。最新状態は、データオブジェクトが更新されており、最新であることを示す。古い状態は、データが有効ではないが、代わりに、恐らく或る他の処理によって更新することを要求することを示す。幾つかの例では、古い状態は、データのミラーコピーに関連してのみ使用可能である（より詳細に別記する）。データは、古いことがある。なぜならば、それは最近書込まれたが、まだコピーされていない他のデータのミラーであるからである。不変状態は、恐らく前のクローン（スナップショット）動作に関連して、対応するデータが書込禁止であることを
示す。空状態は、実際の格納空間がデータにまだ割付けられていないことを示す。
【００６３】
図１０に示すように、フローチャート２４０は、ファイルに対する読出リースを得た後、読出動作を実行することに関連してクライアントによって実行されるステップを示す。処理は、最初の検査ステップＳ２４２で始まり、読出されたデータオブジェクトが最新状態であるか否か判断する。ＮＯの場合、制御は、検査ステップＳ２４２からステップＳ２４４に移行し、読出されたデータオブジェクトが不変状態であるか否か判断する。読出されたデータオブジェクトが不変状態であるとステップＳ２４４で判断した場合、または読出されたデータオブジェクトが最新状態であると検査ステップＳ２４２で判断した場合、制御は、ステップＳ２４６に移行し、読出動作が実行される。クライアントは、サーバ１０２に適切なデータファイルオブジェクトＩＤを提供すると共に、適切なセキュリティ資格を提供することによって、ファイルデータを読出す。従って、ステップＳ２４６で実行される読出動作は、クライアントがサーバ１０２に適切な要求を送り、それからの結果を待機することを含む。
【００６４】
ステップＳ２４６に続くのは検査ステップＳ２４８であり、データファイルオブジェクトが利用可能ではないことを示す結果をサーバ１０２が返したか否か判断する。幾つかの場合、ＮＯの場合には最新または不変であるデータファイルオブジェクトは、それにも拘らず利用可能でなくなることがある。たとえばデータファイルオブジェクトを保持する物理格納空間は、一時的に切断されるか、および／または一時的に或る他の動作を行なっていてビジーである。データファイルオブジェクトが利用可能であると検査ステップＳ２４８で判断した場合、制御は、検査ステップＳ２４８から検査ステップＳ２５２に移行し、読出動作が成功したか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ２５２からステップＳ２５４に移行し、読出動作の結果が、読出動作を行なったクライアントでの処理に返される。その結果は、読出されたデータおよび状態インジケータを含むことが可能である。ステップＳ２５４に続いて処理は終了する。
【００６５】
ステップＳ２４６で実行された読出動作が成功しなかったと検査ステップＳ２５２で判断した場合、制御は、検査ステップＳ２５２からステップＳ２５６に移行し、エラー処理が実行される。ステップＳ２５６で実行される特定エラー処理は、処理系に依存し、たとえばコール処理にエラーを報告すること、および／または恐らく読出動作を指定回数再試行することを含むことが可能である。ステップＳ２５６に続いて処理は終了する。
【００６６】
読出されたデータオブジェクトが不変状態ではないと検査ステップＳ２４４で判断した場合、制御は、検査ステップＳ２４４から検査ステップＳ２５８に移行し、データオブジェクトが古い状態であるか否か判断する。ＮＯの場合、検査ステップＳ２４２，２４４，２５８および除去処理によって、データオブジェクトは空状態になる。本実施形態では、空状態のデータオブジェクトを読出すことは、零をコール処理に返させる。従って、データオブジェクトが古い状態ではないと検査ステップＳ２５８で判断した場合、制御は、検査ステップＳ２５８からステップＳ２６２に移行し、読出動作に応じて零が返される。ステップＳ２６２に続いて処理は終了する。
【００６７】
データファイルオブジェクトが古い状態であると検査ステップＳ２５８で判断した場合、またはデータファイルオブジェクトが利用可能ではないと検査ステップＳ２４８で判断した場合、制御は、検査ステップＳ２６４に移行し、データファイルオブジェクトの代替バージョンが読出可能であるか否か判断する。より詳細に別で議論するように、ミラーリングによって同時に存在する同一のデータファイルオブジェクトのマルチバージョンがあることがある。従って、読出されたデータファイルオブジェクトが古い状態であるか、またはそうでなければ利用可能ではない場合、最新状態であることがあるデータファイルオブジェクトのミラーコピーを読出すことが可能である。ステップＳ２６４で実行される検
査は、より詳細に別記される。
【００６８】
データファイルオブジェクトの代替バージョンが利用可能であると検査ステップＳ２６４で判断した場合、制御は、検査ステップＳ２６４からステップＳ２６６に移行し、データファイルオブジェクトの代替バージョンが使用のために選択される。ステップＳ２６６に続いて、制御は、代替データファイルオブジェクトでの別の反復のために検査ステップＳ２４２に戻る。
【００６９】
データファイルオブジェクトの代替バージョンが利用可能ではないと検査ステップＳ２６４で判断した場合、制御は、検査ステップＳ２６４からステップＳ２６８に移行し、クライアント処理は待機する。本実施形態では、データファイルオブジェクトが最新および／または利用可能になるまで待機することが望ましい。ステップＳ２６８に続いて、制御は、別の反復のためにステップＳ２４２に戻る。なおステップＳ２６８で待機する代わりに、処理は、ステップＳ２６４からステップＳ２５６に移行し、利用可能な代替データファイルオブジェクトがない場合に、エラー処理を実行することも可能である。他の実施形態では、ステップＳ２６８を或る回数実行可能であり、その後、データファイルオブジェクトがまだ利用可能ではない場合、または古い状態であり、代替データファイルオブジェクトがない場合に、ステップＳ２５６でエラー処理を実行する。
【００７０】
図１１に示すように、フローチャート２８０は、ファイルへの書込リースを得た後で、書込動作を実行することに関連してクライアントによって実行されるステップを示す。処理は、最初の検査ステップＳ２８２で始まり、書込が実行されているデータファイルオブジェクトが不変状態であるか否か判断する。ＹＥＳの場合、制御は、ステップＳ２８２からステップＳ２８４に移行し、データファイルオブジェクトが不変データを上書きしないようにするために新しい実際の格納空間が割付けられる。データオブジェクトに新しい格納空間を割付けることは、サーバ１０２に適切な要求を提供することを含むことが可能である。ステップＳ２８４に続いて、制御は、ステップＳ２８２に戻り、再び書込動作のための処理を始める。
【００７１】
書込が実行されているデータファイルオブジェクトが不変状態ではないとステップＳ２８２で判断した場合、制御は、ステップＳ２８２からステップＳ２８６に移行し、書込が実行されているデータファイルオブジェクトが古い状態であるか否か判断する。ＮＯの場合、制御は、検査ステップＳ２８６から検査ステップＳ２８８に移行し、書込が実行されているデータファイルオブジェクトが空状態であるか否か判断する。ＹＥＳの場合、制御は、上で議論したステップＳ２８８からステップＳ２８４に移行し、新しい物理格納空間が割付けられる。ステップＳ２８４に続いて、制御は、ステップＳ２８２に戻り、再び書込動作のための処理を始める。
【００７２】
書込が実行されているデータファイルオブジェクトが空状態ではないとステップＳ２８８で判断した場合、制御は、検査ステップＳ２８８からステップＳ２９２に移行し、書込動作が実行される。なお書込動作が実行されているデータファイルオブジェクトが不変状態ではなく、古い状態ではなく、そして空状態ではない場合（従って、最新状態である）、ステップＳ２９２に到達する。クライアントは、サーバ１０２に適切なデータファイルオブジェクト位置ＩＤを提供するほか、適切なセキュリティ資格を提供することによって、ファイルデータを書込む。従って、ステップＳ２９２で実行される書込動作は、クライアントがサーバ１０２に適切な要求を送り、その結果を待機することを含む。
【００７３】
ステップＳ２９２に続くのは検査ステップＳ２９４であり、ステップＳ２９２で実行された書込動作が成功したか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ２９４から検査ステップＳ２９６に移行し、書込が実行されているデータファイルオブジェクト
の同期ミラーがあるか否か判断する。ステップＳ２９６で実行される検査は、たとえばファイルレイアウト格納オブジェクトツリーのデータファイルオブジェクトの親ノードが複製を示すか否か判断することを含むことが可能である。ＮＯの場合、制御は、検査ステップＳ２９６からステップＳ２９８に移行し、書込が実行されたことを示す更新（メッセージ）がサーバ１０２に送られる。ステップＳ２９８に続いて処理は終了する。
【００７４】
書込が実行されているデータファイルオブジェクトの同期ミラーがあると検査ステップＳ２９６で判断した場合、制御は、検査ステップＳ２９６からステップＳ３０２に移行し、ステップＳ２９２で書込まれたデータも同期ミラーに書込まれる。ステップＳ３０２で実行される処理は、より詳細に別で議論する。ステップＳ３０２に続いて、制御は、上で議論したステップＳ２９８に移行し、更新（メッセージ）がサーバ１０２に送られる。ステップＳ２９８に続いて処理は終了する。
【００７５】
ステップＳ２９２で実行された書込動作が成功しなかったと検査ステップＳ２９４で判断した場合、または書込動作が実行されたデータファイルオブジェクトが古い状態であると検査ステップＳ２８６で判断した場合、制御は、ステップＳ３０４に移行し、書込が試行されているデータファイルオブジェクトが、レイアウト格納オブジェクトツリーのクライアントのローカルコピーから取り除かれる。フローチャート２８０によって示された書込動作の終わりに、クライアントは、必要に応じて、データオブジェクトに書込む際の困難さを（ステップＳ２９８で）サーバ１０２に通知することが可能であり、その結果、サーバ１０２が適切な処置を講じることができる。
【００７６】
ステップＳ３０４に続くのは検査ステップＳ３０６であり、データの代替バージョンが利用可能であるか否か判断する。より詳細に別で議論するように、ミラーリングによって同時に存在する同一のデータファイルオブジェクトのマルチバージョンが存在することがある。従って、書込動作が実行されているデータファイルオブジェクトが古いか、または他の方法で書込むことができない場合、データのミラーコピーに書込むことが可能である。ステップＳ３０６で実行される検査は、ステップＳ２６４で実行される検査と同様であり、より詳細に別記される。データファイルオブジェクトに対応するデータの代替バージョンが利用可能であると検査ステップＳ３０６で判断した場合、制御は、検査ステップＳ３０６からステップＳ３０８に移行し、代替バージョンが書込のために選択される。ステップＳ３０８に続いて、制御は、代替データファイルオブジェクトを伴う別の反復のために検査ステップＳ２８２に戻る。
【００７７】
データファイルオブジェクトに対応するデータの代替バージョンが利用可能ではないと検査ステップＳ３０６で判断した場合、制御は、検査ステップＳ３０６からステップＳ３１２に移行し、利用可能な選択肢がない場合、エラー処理を実行する。ステップＳ３１２で実行される特定エラー処理は処理系に依存し、たとえばコール処理にエラーを報告すること、および／または恐らくエラーを報告する前に書込動作を指定回数再試行することを含むことが可能である。ステップＳ３１２に続いて、制御は、上で議論したステップＳ２９８に移行し、サーバ１０２に更新情報を送る。ステップＳ２９８に続いて処理は終了する。
【００７８】
図１２に示すように、フローチャート３２０は、図１０の代替の利用可能な検査ステップＳ２６４および／または図１１の代替の利用可能な検査ステップＳ３０６に関連して実行される、より詳細なステップを示す。処理は、最初の検査ステップＳ３２２で始まり、ファイルが如何なるミラーデータファイルオブジェクトも有していないか否か判断する。幾つかの例では、ファイルはミラーを使用しないことがあり、その場合、利用可能な代替コピーはない。従って、ファイルがミラーデータファイルオブジェクトを有していないと検査ステップＳ３２２で判断した場合、制御は、検査ステップＳ３２２からステップＳ３
２４に移行し、代替コピーが利用可能ではないことを示す値が返される。ステップＳ３２４に続いて処理は終了する。
【００７９】
ミラーコピーが利用可能であると検査ステップＳ３２２で判断した場合、制御は、検査ステップＳ３２２からステップＳ３２６に移行し、ポインタが最初のミラーデータファイルオブジェクトを指すようにされる。ここで議論される処理に対して、ポインタは、使用可能なデータファイルオブジェクトを見つけるべくミラーデータファイルオブジェクトを通じて繰返すために、使用可能である。ステップＳ３２６に続くのは検査ステップＳ３２８であり、ポインタが、ミラーデータファイルオブジェクトのリストの終端を過ぎたか（ミラーデータファイルオブジェクトをすべて通じて繰返したか）否か判断する。ＹＥＳの場合、制御は、上で議論した検査ステップＳ３２８からステップＳ３２４に移行し、代案が利用可能ではないことを示す値を返す。
【００８０】
ポインタがミラーデータファイルオブジェクトのリストの終端を過ぎていないと検査ステップＳ３２８で判断した場合、制御は、検査ステップＳ３２８から検査ステップＳ３３２に移行し、ポインタが古い状態のデータファイルオブジェクトを指しているか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ３３２からステップＳ３３４に移行し、ポインタが、検査される次のデータファイルオブジェクトを指すようにされる。ステップＳ３３４に続いて、制御は、別の反復のために上で議論したステップＳ３２８に戻る。ポインタが古い状態のデータファイルオブジェクトを指していないと検査ステップＳ３３２で判断した場合、制御は、検査ステップＳ３３２からステップＳ３３６に移行し、ポインタによって指されるデータファイルオブジェクトがコール処理によって使用されることがある代替データファイルオブジェクトとして返される。ステップＳ３３６に続いて処理は終了する。
【００８１】
図１３に示すように、フローチャート３５０は、図１１のフローチャート２８０のステップＳ３０２に関連して実行されるより詳細な動作を示し、書込まれたデータは、多数の同期ミラー（ミラーデータファイルオブジェクト）にコピーされる。処理は、最初のステップＳ３５２で始まり、ミラーデータファイルオブジェクトを通じて繰返すために使用されるポインタは、ミラーデータファイルオブジェクトの最初の１つを指すように設定される。ステップＳ３５２に続くのは検査ステップＳ３５４であり、ミラーデータファイルオブジェクトポイントを通じて繰返すために使用されるポインタが終端を過ぎて指しているか否か（つまりミラーデータファイルオブジェクトのすべてが処理されたか否か）を判断する。ＹＥＳの場合、処理は終了する。ＮＯの場合、制御は、検査ステップＳ３５４から検査ステップＳ３５６に移行し、ポインタによって示されるミラーデータファイルオブジェクトの状態が、ミラーデータファイルオブジェクトが最新であることを示すか否か判断する。ＮＯの場合、制御は、検査ステップＳ３５６から検査ステップＳ３５８に移行し、ポインタによって指されるミラーデータファイルオブジェクトの状態が、ミラーデータファイルオブジェクトが古い状態であることを示すか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ３５８からステップＳ３６２に移行し、ミラーデータファイルオブジェクトが、レイアウト格納オブジェクトツリーのクライアントのローカルコピーから取り除かれる。本実施形態では、同期ミラーデータファイルオブジェクトは、古い状態であるべきではなく、もしそれが生じる場合、それはエラー状態を示すことが可能である。従って、ステップＳ３６２に続くのはステップＳ３６４であり、古いミラーに関する情報がサーバ１０２に送られ、それに対する応答で回復処理を実行可能である。
【００８２】
なおミラーデータファイルオブジェクトが古い状態でも最新状態でもない場合、ミラーデータファイルオブジェクトは、空状態または不変状態である。いずれの場合も、データが書込まれるデータファイルオブジェクトに対して新しい空間を割付けることが必要であることがある。従って、データファイルオブジェクトが古い状態ではないと検査ステップ
Ｓ３５８で判断した場合、制御は、検査ステップＳ３５８からステップＳ３６６に移行し、新しい空間がミラーデータファイルオブジェクトに割付けられる。ステップＳ３６６に続くのはステップＳ３６８であり、同期ミラーデータファイルオブジェクトに亘ってコピーされるデータが、ミラーデータファイルオブジェクトを通じて繰返すために使用されるポインタによって指されたミラーデータファイルオブジェクトに書込まれる。なおステップＳ３６８は、ミラーデータファイルオブジェクトが最新であると判断した場合に検査ステップＳ３５６から到達することも可能である。ステップＳ３６８に続くのはステップＳ３７２であり、ミラーデータファイルオブジェクトを通じて繰返すために使用されるポインタが次のものを指すようにされる。なおステップＳ３７２はステップＳ３６４からも到達する。ステップＳ３７２に続いて、制御は、別の反復のために検査ステップＳ３５４に戻る。
【００８３】
ここで記述される本システムは、オブジェクトＩＤを使用してファイルオブジェクトにアクセスすることが可能である。本実施形態では、サーバ１０２間で格納される各ファイルオブジェクトは、各ファイルオブジェクトを識別し、本システムにおいて各ファイルオブジェクトと他のファイルオブジェクトとを識別する固有のオブジェクトＩＤを割当てられることが可能である。しかし、多くのアプリケーションが、ファイルおよびその中のデータにアクセスするためにファイル名付け構造および／または階層的ディレクトリを使用する。たとえばファイル名「Ｃ：￥ＡＢＣ￥ＤＥＦ￥ＧＨｌ．ｄｏｃ」は、ルートボリューム「Ｃ」に置かれた別のディレクトリ「ＡＢＣ」に格納されるサブディレクトリ「ＤＥＦ」に格納された「ＧＨＩ．ｄｏｃ」と呼ばれるファイルを示す。ネスト化したディレクトリ構造は、他のディレクトリに格納される特定ファイルとしてディレクトリを実施することによって提供可能である。上に挙げた例では、サブディレクトリ「ＤＥＦ」は、ディレクトリ「ＡＢＣ」に格納されたファイルとして実施可能である。
【００８４】
ここで記述される本システムは、従来のファイル名をファイルオブジェクトＩＤに変換することによってアプリケーションに従来のファイル名およびディレクトリ階層を提示することが可能である。そのような変換サービスは、ファイル動作に関連して他のサービスによって利用可能である。本実施形態では、各ディレクトリは、ファイル名およびサブディレクトリ名をファイルオブジェクトＩＤに相関させるテーブルを備えることが可能である。本システムは、一度に１つのディレクトリを検査し、目標ファイルに到達するまでサブディレクトリを横断することが可能である。
【００８５】
図１４に示すように、フローチャート３８０は、従来の階層的ファイル名をファイルオブジェクトＩＤに変換するファイル名変換サービス（ファイル名サービス）を提供することに関連して実行されるステップを示す。ファイル名サービスは、入力として従来の階層的ファイル名を受信し、オブジェクトＩＤ（または幾つかのケースではエラー）を返すことが可能である。処理は、最初のステップＳ３８２で始まり、ファイル名サービスが従来の階層的ファイル名のようなファイル名を受信する。ステップＳ３８２に続くのは検査ステップＳ３８４であり、ファイル名のシンタックスがＯＫであるか否か判断する。階層的ファイル名のシンタックスを確認することは、公知であり、たとえば適切な文字だけが使用されていることを確認することを含む。シンタックスがＯＫではないと検査ステップＳ３８４で判断した場合、制御は、検査ステップＳ３８４からステップＳ３８６に移行し、エラーインジケータ（エラーメッセージ）がコール処理に返される。ステップＳ３８６に続いて処理は終了する。
【００８６】
提供された名前のシンタックスがＯＫであると検査ステップＳ３８４で判断した場合、制御は、検査ステップＳ３８４からステップＳ３８８に移行し、ルートディレクトリが読出される。本実施形態では、すべてのファイル名のパスは、サーバ１０２に格納されたすべてのファイルオブジェクトに使用される単一の共通ルートディレクトリで始まる。他の
実施形態では、複数のルートディレクトリがある場合があり、特定ルートディレクトリの仕様が、ボリュームＩＤを使用するなどの任意の適切なリソース（特に特定ルートディレクトリを選択するなど）によって提供可能である。
【００８７】
ステップＳ３８８に続くのは検査ステップＳ３９２であり、目標ファイル（またはファイル名のパスの一部であるサブディレクトリ）が、読出されたディレクトリにあるか否か判断する。ＮＯの場合、制御は、上で議論した検査ステップＳ３９２からステップＳ３８６に移行し、エラーが返される。幾つかの実施形態では、ステップＳ３９２での検査に起因するファイル未発見エラーは、ステップＳ３８４での検査に起因するシンタックスエラーとは異なることがある。
【００８８】
ファイル名のパスの一部である目標ファイルまたはサブディレクトリがちょうど読出されたディレクトリにあると判断した場合、制御は、検査ステップＳ３９２から検査ステップＳ３９４に移行し、ちょうど読出されたディレクトリが目標ファイルを含むか否か判断する（ファイル名のパスの一部であるサブディレクトリを含むのとは対照的に）。ＹＥＳの場合、制御は、検査ステップＳ３９４からステップＳ３９６に移行し、目標ファイルオブジェクトのオブジェクトＩＤがコール処理に返される。ステップＳ３９６に続いて処理は終了する。
【００８９】
ちょうど読出されたディレクトリがファイル名のパスの一部であるサブディレクトリを含むと検査ステップＳ３９４で判断した場合、制御は、検査ステップＳ３９４からステップＳ３９８に移行し、サブディレクトリが読出され、その結果、サブディレクトリが検査されるディレクトリになる。実際には、ステップＳ３９８での処理は、いずれ目標ファイルに到着するために一連のサブディレクトリを横断する。ステップＳ３９８に続いて、制御は、次の反復のために上で議論したステップＳ３９２に戻る。
【００９０】
図１５に示すように、本図は、クライアント１０４がユーザアドレスメモリ空間およびカーネルアドレスメモリ空間を含むものとして示す。本実施形態では、ユーザアドレスメモリ空間は、ユーザアプリケーションおよび関連処理によって一般に使用されるメモリ空間である一方、カーネルアドレスメモリ空間は、オペレーティングシステムカーネルおよび関連処理などのシステム処理によってのみ一般にアクセス可能なメモリ空間である。ここでより詳細に議論するように、ここで記述する本システムの互いに異なる部分を、ユーザメモリ空間および／またはカーネルメモリ空間に備えさせ、動作させることが可能である。加えて、クライアント１０４は、サーバでのファイルオブジェクトにアクセスするための複数の互いに異なるインタフェースを有することが可能である。
【００９１】
図１５では、クライアント１０４は、ユーザメモリアドレス空間にアプリケーション、ならびにカーネルメモリアドレス空間に仮想ファイルシステム（ＶＦＳ）、ファイル名サービス、カーネルＩ／Ｏドライバ、レイアウトマネージャ、および通信インタフェースを含むものとして示されている。仮想ファイルシステムは、より具体的なファイルシステム上の抽象層である。仮想ファイルシステムの目的は、クライアントアプリケーションが一定の方法で互いに異なるタイプの具体的なファイルシステムにアクセスすることを可能にすることである。仮想ファイルシステムは、アプリケーションが下層のファイルシステムの詳細を理解する必要なしに、クライアント１０４上で動作するアプリケーションがサーバ１０２上のファイルオブジェクトにアクセスすることを可能にする。仮想ファイルシステムは、アプリケーションによってファイルシステムコールをファイルオブジェクト操作に、またこれとは逆に変換することによって、従来の方法で実施可能である。たとえば仮想ファイルシステムは、開く、読出す、書込む、閉じるなどのファイルシステムコールを、オブジェクトを作成、オブジェクトを削除するなどのファイルオブジェクトコールに変換することが可能である。
【００９２】
仮想ファイルシステムは、ファイル名をオブジェクトＩＤに変換するために、別記されるファイル名サービスを使用することが可能である。カーネルＩ／Ｏドライバは、低レベルのオブジェクトレベルＩ／Ｏ動作にインタフェースを提供する。カーネルＩ／Ｏドライバは、リナックス（登録商標）Ｉ／Ｏドライバを手本にし、それと同様であることが可能である。レイアウトマネージャは、より詳細に別で議論するように、ファイルに対応するレイアウト格納オブジェクトツリーの処理のうちの幾つかを実行可能である。通信インタフェースは、クライアント１０４とサーバ１０２の間の通信を提供する。通信インタフェースは、任意の適切な通信機構を使用して実施可能である。たとえばクライアント１０４がインターネット接続を介してサーバ１０２に通信する場合、通信インタフェースは、サーバ１０２とクライアント１０４の間の通信を容易にするためにＴＣＰ／ＩＰを使用することが可能である。
【００９３】
図１５のアプリケーションは、図３のクライアントソフトウェア１２４に対応することが可能である。図１５の仮想ファイルシステムは、図３のインタフェース１２６〜１２８のうちの１つに対応することが可能である。図１５のファイル名サービス、カーネルＩ／Ｏドライバ、レイアウトマネージャ、および通信インタフェースは、図３のサーバ動作ソフトウェア１２２に対応することが可能である。図３および他の図のコンポーネント間の同様の相関を見出すことも可能である。
【００９４】
図１６に示すように、フローチャート４１０は、クライアント１０４上で動作するアプリケーションに関連してファイルサービスを提供するために仮想ファイルシステムを通じて実行されるステップを示す。処理は、最初のステップＳ４１２で始まり、アプリケーションによって要求されたファイルシステムオペレーションは、一または複数のオブジェクト動作に変換可能である。たとえば読出のためにファイルを開くファイル動作は、他で議論するように、読出のためにオブジェクトリースを得ることを含むオブジェクト動作に変換可能である。ステップＳ４１２に続くのはステップＳ４１４であり、仮想ファイルシステムは、図１４に関連して上で議論したファイル名サービスを使用してファイル名をオブジェクトＩＤに変換する。これに続く動作は、ステップＳ４１４で得られたオブジェクトＩＤを使用して実行されることが可能である。
【００９５】
ステップＳ４１４に続くのは検査ステップＳ４１６であり、要求動作がレイアウト格納オブジェクトツリー（ＬＳＯツリー）を要求するか否か判断する。他で議論するように、読出、書込などの動作は、ファイルオブジェクトに対応するレイアウト格納オブジェクトツリーを使用する。しかし、幾つかの可能なファイル動作は、対応するレイアウト格納オブジェクトツリーにアクセスすることを要求しないことがある。レイアウト格納オブジェクトツリーが必要であると検査ステップＳ４１６で判断した場合、制御は、検査ステップＳ４１６からステップＳ４１８に移行し、仮想ファイルシステムは、必要な動作を実行するためにレイアウト格納オブジェクトマネージャ（ＬＳＯマネージャ）にアクセスする。たとえば読出動作に対して、レイアウト格納オブジェクトマネージャは、図１０のフローチャート２４０において示されたような処理を実行可能である。ステップＳ４１８に続くのは、またはレイアウト格納オブジェクトが必要ではない場合にステップＳ４１６に続くのは、ステップＳ４２２であり、動作は、低レベルのカーネルＩ／Ｏドライバに（たとえば一または複数の適切なＡＰＩ（アプリケーションプログラムインタフェース）を介して）伝えられる。カーネルＩ／Ｏドライバは、要求動作を実行することに関連してクライアント１０４とサーバ１０２の間で通信するために通信モジュールを使用する。クライアント１０４上で動作するアプリケーションが要求データおよび／またはサーバ１０２からの他の情報を有する例では、データおよび／または情報は、通信インタフェース、カーネルＩ／Ｏドライバなどを通じて、仮想ファイルシステムに、そして最終的にはアプリケーションに戻すことが可能である。
【００９６】
図１７に示すように、クライアント１０４は、すべてユーザメモリアドレス空間において提供されたアプリケーション、ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有するものとして示されている。図１５に示された上述の仮想ファイルシステムの機能は、アプリケーションにリンクされたライブラリルーチンによって代わりに実行され、したがって、アプリケーションの一部である。これらのルーチンは、図１６に関連して上で議論したような機能を提供する。従って、それはファイル名サービスを使用し、ユーザレベルＩ／Ｏドライバ（カーネルＩ／Ｏドライバのような）およびレイアウトマネージャにコールさせるアプリケーションである。通信インタフェースは、カーネルメモリアドレス空間で依然として維持されている。
【００９７】
なお図１５の構成に対して、修正がシステム処理（オペレーティングシステム）を修正することによって提供されるが、それは多くの理由で不利である。たとえばクライアント１０４がマルチユーザコンピューティングシステムである場合、オペレーティングシステムを修正することは、本システム全体を再度開始させることを含む。従って、すべてのユーザを分裂させることがある。これに対して図１７の構成は有利である。なぜならば、それはアプリケーション／ユーザメモリアドレス空間における本システムの修正を可能にするからであり、その結果、クライアント１０４のオペレーティングシステムは、修正される必要がない。しかし、図１７の構成は、仮想ファイルシステムを使用せず、従って、図１５における仮想ファイルシステムを通じて提供されるファイルシステムからアプリケーションの有利な分離を得ることはない。
【００９８】
図１８に示すように、クライアント１０４は、図１５に示したようなカーネルメモリアドレス空間における仮想ファイルシステムを通じてファイルオブジェクトにアクセスするユーザメモリアドレス空間におけるアプリケーションを有するものとして示されている。しかし、ファイル名サービス、Ｉ／Ｏドライバ、およびレイアウトマネージャは、すべて図１７に示した本システムのようなユーザメモリアドレス空間に存在する。仮想ファイルシステムは、ＦＵＳＥ（または同様の）インタフェースのような、カーネルメモリアドレス空間とユーザメモリアドレス空間の間のブリッジを通じて、ユーザメモリアドレス空間のコンポーネントに通信する。ブリッジは、ファイルシステムコンポーネントがカーネルアドレスメモリ空間の代わりにユーザメモリ空間において提供されることを可能にする一方、カーネルアドレスメモリ空間において仮想ファイルシステムを依然として維持する。このように図１８によって示された構成は、図１７の構成に示したようにユーザアドレスメモリ空間においてファイルシステムコンポーネントを有するという利点に加えて、図１５の構成に示したように仮想ファイルシステムを使用するという利点を備えている。
【００９９】
幾つかの例では、クライアント１０４のユーザメモリアドレス空間におけるアプリケーションおよび／または他の処理を、ユーザとのリンクが可能なライブラリ（たとえば図１７に示した構成）によって提供される仮想ファイルシステムおよび／または等価の機能のようなファイルサービス層を通じてではなく、ファイルオブジェクトに直接アクセスさせることが可能である。ファイルオブジェクトに直接アクセスすることは、オブジェクトを作成する、オブジェクトを読出す、オブジェクトを修正する、オブジェクトを削除するなどのルーチンを呼出すことを含むことが可能である。そのような場合、アプリケーションは、どのようにオブジェクトデータを変換および／または操作するかを知る必要があり、それは必ずしも望ましいとは限らない。たとえば仮想ファイルシステムを通じてファイルオブジェクトにアクセスするアプリケーションは、レイアウト格納オブジェクトツリーの構造を考慮に入れる（またはそれについて知ることさえ）必要がないことがある一方、オブジェクトに直接アクセスするアプリケーションは、レイアウト格納オブジェクトツリーを使用する必要がある。一方、ファイルサービス層の削除は、そうでなければ利用可能ではない最適化の機会を提供することが可能である。なおサーバ１０２がクライアント１０
４〜１０６とオブジェクト情報／動作を交換するので、サーバ１０２は、ファイルシステムインタフェース（仮想ファイルシステムのようなファイルサービス）を使用するクライアント１０４〜１０６上のアプリケーションと、それを使用しないものとを識別する必要がないか、または識別することが可能である。
【０１００】
図１９に示すように、クライアント１０４は、ユーザメモリアドレス空間にアプリケーションを、そしてカーネルメモリアドレス空間にカーネルＩ／Ｏドライバ、レイアウトマネージャ、およびファイル名サービスを含むものとして示されている。図１９に示した構成は、仮想ファイルシステムが使用されない以外は、図１５に示したものと同様である。図１９に示した構成では、アプリケーションは、ファイル名サービス、カーネルＩ／Ｏドライバ、およびレイアウトマネージャに直接アクセスすることができる。カーネルメモリアドレス空間における通信インタフェースは、ちょうど他の構成のように、サーバ１０２に通信する。図１９に示した直接アクセスは、アプリケーションがファイルオブジェクトを（たとえば適切なＡＰＩ（（アプリケーションプログラムインタフェース））を介して）操作可能にする一方、仮想ファイルシステム（または同様のもの）を介したアクセスは、アプリケーションが仮想ファイルシステムへのファイルシステムコールを通じて間接的にファイルオブジェクトにアクセスすることを可能にする。
【０１０１】
図２０に示すように、クライアント１０４は、すべてユーザメモリアドレス空間において提供されるアプリケーション、ユーザレベルＩ／Ｏドライバ、レイアウトマネージャ、およびファイル名サービスを有するものとして示されている。図２０に示した構成は、図１７に示したものと同様である。しかし、上述したように、図１７の構成は、アプリケーションにリンクされ、従って、その一部であるファイルサービスライブラリを含む。これに対して、図２０の構成では、アプリケーションは、広範囲なファイルサービスを有するライブラリにリンクされていない。代わりに、図１９に示した構成のアプリケーションのように、図２０の構成におけるアプリケーションは、最小のファイルサービスを利用し、代わりに、ファイルオブジェクトがユーザレベルＩ／Ｏドライバ、レイアウトマネージャを直接使用する、またファイル名変換が必要な場合は、ファイル名サービスを直接使用する際に使用および動作する。
【０１０２】
図２１に示すように、クライアント１０４は、ユーザメモリアドレス空間においてアプリケーションを有し、カーネルメモリアドレス空間においてブリッジを有するものとして示されている。ファイル名サービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャは、ユーザメモリアドレス空間に提供される。しかし、図２０の構成とは異なり、本アプリケーションは、ユーザメモリアドレス空間におけるファイルシステムコンポーネントへの直通コールを行なわない。代わりに、アプリケーションは、ブリッジを通じて間接的にファイルシステムコンポーネントをコールする。ちょうど図１８に示した構成のように、図２１の構成は、ユーザメモリアドレス空間にファイルシステムコンポーネントを有利に配置し、同時に、アプリケーションとファイルシステムコンポーネントの間にカーネルメモリアドレス空間層を提供する。
【０１０３】
図２２に示すように、クライアント１０４は、ユーザメモリアドレス空間においてアプリケーションを、カーネルメモリアドレス空間においてウェブサービスモジュールを有するものとして示されている。アプリケーションは、ウェブサーバアプリケーションまたはウェブとの通信を扱う任意のアプリケーションであることが可能である。本実施形態では、アプリケーションは、クライアント１０４との通信を可能にし、それはウェブ接続を通じてクライアント１０４にアクセスする他の演算装置（図示せず）へのウェブサーバとして作用する。
【０１０４】
図２２に示した構成は、同様の方法で、他の構成によって提供されるファイルサービス
および／またはファイルオブジェクトアクセスにウェブサービスを提供する。しかし、ウェブサービスは、ＨＴＭＬなどのウェブデータプロトコルを介して要求／データを受信し、更にウェブデータプロトコルにおける応答／データを提供し、それは要求／データに使用されるプロトコルと同一または該プロトコルとは異なることがある。ウェブサービスによって扱われる動作は、オブジェクトを作成する、オブジェクトを削除する、オブジェクトを読出す、オブジェクトを修正する、オブジェクトメタデータを修正するなどのオブジェクトレベルの動作を含むことが可能である。更にウェブサービスによって、別記されるファイルサービスの機能のうちの少なくとも幾つかを含むことによって、ファイルを開くこと、ファイルからデータを読出すことなどをするウェブサービスを介してより多くのファイルシステムレベルの動作を提供することが可能である。ウェブサービスは、ＲＥＳＴまたはＳＯＡＰなどの従来の周知のウェブサービスプロトコルを他の演算装置に提示することが可能であるか、または任意の他の適切なプロトコルを提供することが可能である。
【０１０５】
図２３に示すように、クライアント１０４は、ユーザメモリアドレス空間においてアプリケーション、ウェブサービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有するものとして示されている。アプリケーションは、クライアント１０４との通信を可能にするウェブ接続を含むことが可能であり、それはウェブ接続を通じてクライアント１０４にアクセスする他の演算装置（図示せず）に対するウェブサーバとして作用する。図２３の構成は、図１７および図２０のものと同様である。図２２に示した構成に対する図２３に示した構成の利点は、概して、図２３に示した構成への変更がカーネルメモリアドレス空間処理を再構成することを要求しないということである。
【０１０６】
図２４に示すように、１０４は、ユーザメモリアドレス空間においてアプリケーション、ウェブサービス、ユーザレベルＩ／Ｏドライバ、およびレイアウトマネージャを有するものとして示されている。そのアプリケーションは、クライアント１０４との通信を可能にするウェブ接続を含むことが可能であり、それはウェブ接続を通じてクライアント１０４にアクセスする他の演算装置（図示せず）へのウェブサーバとして作用する。ブリッジは、カーネルメモリアドレス空間に提供される。図２４の構成は、図２３に示した構成と同様の長所を持つだけでなく、他で議論するように、ブリッジを提供することによって利点を提供する。
【０１０７】
図２５に示すように、クライアント１０４は、ユーザメモリアドレス空間において複数のアプリケーションを有するものとして示されており、そのそれぞれは、サーバ１０２のファイルオブジェクトにアクセスする互いに異なるインタフェースを使用することが可能である。図２５に示したアプリケーションのそれぞれは、一または複数のアプリケーションを表わすためのものである。従って、第１アプリケーションＡＰＰ１は、ウェブサービスインタフェースを使用してサーバ１０２でのファイルオブジェクトにアクセスする一または複数のアプリケーションを提示することが可能である。第１アプリケーションＡＰＰ１は、クライアント１０４との通信を可能にするウェブ接続を含むことが可能であり、それはウェブ接続を通じてクライアント１０４にアクセスする他の演算装置（図示せず）に対するウェブサーバとして作用する。第２アプリケーションＡＰＰ２は、仮想ファイルシステムを使用してサーバ１０２でのファイルオブジェクトにアクセスする一または複数のアプリケーションを表わすことが可能である。第３アプリケーションＡＰＰ３は、サーバ１０２でのファイルオブジェクト上で直接動作する一または複数のアプリケーションを表わすことが可能である。互いに異なるインタフェースが、クライアント１０４で同時に動作することが可能である。
【０１０８】
なおクライアント１０４がそのアプリケーションに互いに異なるインタフェースを同時に提示するなどの、図示の構成を含む、構成の他の組合せが可能である。たとえば図１５、図１９、および図２２に示した構成を組み合わせること、および／または図１７、図２
０、および図２３の構成を組み合わせることが可能である。２つの図示の構成だけの組合せを含む他の組合せも可能である。サーバ１０２は、次のものを提供されるクライアント１０４にファイルオブジェクトを提供する：１）要求しているクライアントは、ファイルオブジェクトに対して要求される如何なる動作のための適切な権限を有する；および２）任意の前の要求との矛盾はない。たとえば１つのクライアントだけがいつでもオブジェクトに書込むことを許されるシステムでは、サーバ１０２は、クライアント１０４〜１０６のうちの１つが特定オブジェクトを修正可能にしない一方、クライアント１０４〜１０６のうちの別の１つがオブジェクトを修正する。
【０１０９】
図２６に示すように、サーバ１０２は、一または複数のポリシーマネージャサーバ４０２、一または複数のセキュリティマネージャサーバ４０３、一または複数の監査サーバ４０４、一または複数のメタデータサーバ４０５、一または複数のリソースマネージャサーバ４０６、一または複数のデータ格納サーバ４０７、および一または複数のメタデータ位置サーバ４０８を含むものとして、より詳細に示されている。サーバ４０２〜４０８のそれぞれは、ここで記述される機能を提供することができる一または複数の単位処理装置として実施可能である。ここでの議論に対して、サーバへの参照は、一または複数のサーバへの参照として理解されるべきである。サーバ４０２〜４０８は、ＴＣＰ／ＩＰなどの任意の適切なデータ通信システムを使用して相互接続され、ＴＣＰ／ＩＰなどの任意の適切なデータ通信システムを使用してクライアント１０４〜１０６（図２６においては図示せず）に結合可能である。
【０１１０】
サーバ１０２は、システム管理を容易にするユーザ管理インタフェース４１２を備えることが可能である。ユーザ管理インタフェース４１２は、どのようにサーバ１０２がクライアント１０４〜１０６および対応するユーザに相互作用するかに影響するために、ポリシー管理サーバ４０２、セキュリティ管理サーバ４０３、および監査サーバ４０４とデータを交換する。データは、従来の相互作用型コンピュータスクリーン入力およびデータファイル入力（たとえばユーザ管理コマンドを有するテキストファイル）を含む多数の方法のうちの任意の１つでユーザ管理インタフェース４１２を通じて提供可能である。データは、ユーザのクラス、サービスの質（ＱＯＳ）、ＲＡＩＤ保護レベル、ミラーの個数および地理的位置などの格納パラメータを相関させる情報を含むことが可能である。たとえば管理者は、ユーザ管理インタフェース４１２を通じて、特定タイプのユーザ（特定グループに属するユーザ）が特定ＲＡＩＤレベル保護を有する格納装置上にデータファイルオブジェクトを格納することを指定することが可能である。
【０１１１】
更にサーバ１０２は、データ格納サーバ４０７に結合された物理ストレージ４１４を含む。物理ストレージ４１４は、図２６において単一の要素として示されているが、地理的に分散可能な個別の任意の数の物理格納ユニットであることが可能である。加えて、互いに異なる能力を有する互いに異なるタイプの物理格納ユニットがある場合がある。従って、より詳細に下に説明されるように、物理ストレージ４１４は、データ格納サーバ４０７によって管理される本システムに対する物理的なデータストレージの一または複数の例を包括的に表わす。
【０１１２】
メタデータファイルオブジェクトおよび／または該メタデータファイルオブジェクトの取扱い／生成に影響するポリシーの修正を含むデータ修正は、適切なセキュリティ資格を要求する。従って、セキュリティマネージャサーバ４０３は、ユーザのクラスに対するポリシーを修正および／または作成するために、或る管理者（ユーザ）の能力を制限／禁止することが可能である。
【０１１３】
図２７に示すように、フローチャート４３０は、ポリシーマネージャサーバ４０２にアクセスするためのセキュリティ資格を得て使用するために、ユーザ管理インタフェース４
１２によって実行されるステップを示す。処理は、最初のステップＳ４３２で始まり、ユーザ管理インタフェース４１２は、ユーザ管理インタフェース４１２によって実行される動作のためのトークン（または他の適切なセキュリティ資格）を得るために、セキュリティマネージャサーバ４０３に要求を送る。ステップＳ４３２に続くのは検査ステップＳ４３４であり、トークンが与えられているか（提供されているか）否か判断する。幾つかの例では、セキュリティマネージャサーバ４０３は、セキュリティトークンを全く出さないことがある。たとえば管理者（ユーザ）は、所望の機能を実行するための十分な権利がない場合である。
【０１１４】
セキュリティトークンが与えられない場合、制御は、ステップＳ４３４からステップＳ４３６に移行し、処理が、与えられていないセキュリティトークンに関連して実行される。ステップＳ４３６で実行される動作は、管理者が所望の動作を実行するための十分な権利を有していないことを示すメッセージを、セキュリティ管理インタフェース４１２を通じて管理者（ユーザ）に提供することを含むことが可能である。ステップＳ４３６に続いて処理は終了する。
【０１１５】
セキュリティトークンがセキュリティマネージャサーバ４０３によって与えられた（提供された）と検査ステップＳ４３４で判断した場合、制御は、検査ステップＳ４３４からステップＳ４３８に移行し、ユーザ管理インタフェース４１２がポリシーマネージャサーバ４０２にユーザＩＤ情報およびセキュリティトークンを提供する。勿論、所望の動作／修正を示す情報がステップＳ４３８で提供されることも可能である。ステップＳ４３８に続くのは検査ステップＳ４４２であり、ポリシーマネージャサーバ４０２は、要求動作を可能にしたか否か判断する。なお幾つかの例では、たとえセキュリティマネージャサーバ４０３がセキュリティトークンを提供したとしても、ポリシーマネージャサーバ４０２は、特定動作を可能にしないことがある。たとえばユーザＩＤと、セキュリティトークンによって示されたユーザとが一致しない場合、および／または要求動作と、セキュリティトークンによって示された動作とが一致しない場合である。
【０１１６】
要求動作が可能にされないと検査ステップＳ４４２で判断した場合、制御は、上述した検査ステップＳ４４２からステップＳ４３６に移行し、処理が、セキュリティ問題があることを示すために実行される。ステップＳ４３６で実行される処理は、不十分なセキュリティ権限のために動作を実行することができないことを示すメッセージを管理者（ユーザ）に提供することを含むことが可能である。ステップＳ４４２からステップＳ４３６に到達するときに提供されるメッセージは、ステップＳ４３４からステップＳ４３６に到達するときに提供されるメッセージとは異なることが可能である。
【０１１７】
要求動作が可能にされたと検査ステップＳ４４２で判断した場合、制御は、検査ステップＳ４４２からステップＳ４４４に移行し、その動作が実行される。より詳細に別記されるように、ステップＳ４４４で動作を実行することは、ポリシーデータを修正することを含むことが可能である。ステップＳ４４４に続いて処理は終了する。
【０１１８】
このようにポリシーマネージャサーバ４０２にアクセスする管理者（ユーザ）は、まずセキュリティトークン（恐らく期限を有する）を返す識別情報をセキュリティマネージャサーバ４０３に提供する。管理者は、ポリシーマネージャサーバ４０２にトークンおよび識別情報を提示し、それはトークンおよび識別情報に基づいてアクセスを与えるかまたは否定するか判断する。なお図２７のフローチャート４３０によって示されたセキュリティ機構は、サーバ４０２〜４０８のうちの何れかおよび／または他のデータにアクセスすることに関連して使用されるために拡張可能である。たとえばクライアント１０４〜１０６のうちの１つは、ファイルオブジェクトによる動作を含む動作を実行する前に、セキュリティマネージャサーバ４０３にセキュリティトークンをまず要求することによって、ファ
イルオブジェクトを得る／修正することができる。従って、ここでの議論のために、ファイルオブジェクト、サーバなどへのアクセスが図２７に示したもののような適切なセキュリティ手順を含むと仮定することができる。
【０１１９】
ポリシーマネージャサーバ４０２は、ファイルオブジェクトの配置および保護を扱う。管理者（ユーザ）は、ユーザ管理インタフェース４１２を通じて、クライアント１０４〜１０６の互いに異なるもの、互いに異なるユーザ、互いに異なるクラスのユーザ、または任意の他の適切なグループに割当てられることが可能な互いに異なるポリシーテンプレートを入力することが可能である。たとえばポリシーテンプレートは、特定グループのユーザに対して、新規ファイルが作成される都度、少なくとも或る距離だけ最初のデータセットから地理的に離れてミラーが作成されることを示すことが可能である。そのような場合、そのグループの最初のユーザがニューヨークで最初のデータセットを作成したとき、ミラーは、ロサンジェルスで自動的に作成可能である一方、第２ユーザがロサンジェルスで最初のデータセットを作成したときに、ミラーが、ニューヨークで作成可能である。
【０１２０】
監査サーバ４０４は、システム監査能力を提供するために使用可能である。ユーザは、ユーザ管理インタフェース４１２を通じて監査サーバ４０４に通信することが可能である。ユーザは、監査される（追跡される）情報のタイプを示すことが可能である。
【０１２１】
リソースマネージャサーバ４０６は、利用可能なシステムリソースを追跡する。幾つかの例では、リソースマネージャサーバ４０６は、ポリシーテンプレートを確立し、および／またはポリシーテンプレートを割当てることに関連してポリシーマネージャサーバ４０２に相互作用することが可能である。幾つかの場合には、ユーザが、グループに割当てられた場合に満足させることが不可能なポリシーテンプレートを構築することを試みることが可能である。たとえばすべての物理的なデータストレージが単一の地理的位置にある場合、新規ファイルが最初のデータセットから地理的に離れているミラーを含むべきであることを示すポリシーテンプレートを有することは適切ではない。
【０１２２】
リソースマネージャサーバ４０６は、どのリソースが利用可能であるかを追跡可能にするために、本システムの他のコンポーネントから情報を受信する。リソースが本システムに加えられる都度、リソースまたは別のコンポーネントは、その情報をリソースマネージャサーバ４０６に報告する。たとえば新しい物理ストレージが本システムに加えられる場合、その新しい物理ストレージ自体、またはデータ格納サーバ４０７の対応する１つは、リソースマネージャサーバ４０６にメッセージを送る。同様に、リソースがいっぱいになる（たとえば物理ディスクがいっぱいになる）か、または本システムから取り除かれる（計画された削除または計画されていないリソース障害）場合、情報は、リソースマネージャサーバ４０６に提供される。本実施形態では、システムリソースは、物理ストレージ４１４および／または該物理ストレージ４１４を管理するデータサーバ４０７の部分に対応することが可能である。
【０１２３】
図２８に示すように、リソーステーブル４６０は、複数のエントリ４６２〜４６４を含むものとして示されており、そのそれぞれは、特定格納リソースに対応している。３つのエントリだけが示されているが、テーブル４６０は、任意の数のエントリを含むことが可能である。テーブル４６０は、配列、リンクリストなどを含む任意の適切な技術を使用して実施可能である。
【０１２４】
エントリ４６２〜４６４のそれぞれは、エントリに対応する特定リソースを識別するリソースフィールドを含む。本実施形態では、エントリ４６２〜４６４のそれぞれは、データ格納サーバ４０７のうちの特定１つおよび／またはその一部に対応することが可能である。エントリ４６２〜４６４のそれぞれは、対応するリソースの状態に対応する状態フィ
ールドを含む。本実施形態では、状態フィールドは、リソースがオンラインであるか（利用可能か）またはオフラインであるか（利用可能ではないか）を示すことが可能である。更に状態フィールドは、リソースの使用空間のパーセンテージを示し、恐らく任意の性能劣化を示すことが可能である。
【０１２５】
更にエントリ４６２〜４６４のそれぞれは、対応するリソースの能力を示す能力フィールドを含むことが可能である。本実施形態では、リソースが格納領域を表わすとき、能力フィールドは、対応する格納領域の特定能力を示すことが可能である。特定能力は、リソースが環境にやさしいこと（たとえば使用しないときにディスクの回転を落とすことを通じた低エネルギ消費）、データ複製をすることができること（そうでなければ複製されるデータの単一のコピーだけを維持する）、様々なＲＡＩＤ構成ができること、などを含むことが可能である。能力フィールドは、任意の適切なデータストレージ能力を示すことが可能である。
【０１２６】
図２９に示すように、フローチャート４８０は、システムリソースに関する情報を維持することに関連したリソースマネージャサーバ４０６の動作を示す。処理は、最初のステップＳ４８２で始まり、リソースマネージャサーバ４０６がリソースに関する情報で初期化される。ステップＳ４８２で実行される初期化処理は、リソースマネージャサーバ４０６にシステムリソースなどをポーリングさせる、最初に利用可能なリソースの固定テーブルをロードすることを含む如何なる形態も取ることが可能である。
【０１２７】
ステップＳ４８２に続くのは検査ステップＳ４８４であり、リソースマネージャサーバ４０６は、新しい情報が提供されるまで待機する。本実施形態では、初期化後に、リソースマネージャサーバ４０６は、他のシステムコンポーネントから情報を受信するまで待機する。他の実施形態では、リソースマネージャサーバ４０６に、何かが変わったかを確かめるために、システムコンポーネントを周期的にポーリングさせることも可能である。新しい情報が利用可能ではないと検査ステップＳ４８４で判断した場合、制御ループは、ポーリングし続けるために検査ステップＳ４８４に戻る。
【０１２８】
一旦新しい情報が利用可能であると検査ステップＳ４８４で判断されると、制御は、検査ステップＳ４８４から検査ステップＳ４８６に移行し、新しい情報が本システムに加えられた新しいリソースに関するか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ４８６からステップＳ４８８に移行し、新しいエントリが、リソースマネージャサーバ４０６によって管理されるリソーステーブルに加えられる。ステップＳ４８８に続いて、制御は、ステップＳ４８４に戻り、新しい情報を待機し続ける。
【０１２９】
受信リソース情報が新しいリソースに関しない（従って既存のリソースの変更に関する）とステップＳ４８６で判断した場合、制御は、ステップＳ４８６からステップＳ４９２に移行し、既存のエントリがリソーステーブルに配置される。ステップＳ４９２に続くのは検査ステップＳ４９４であり、修正されたリソースに対して能力が変更されているか否か判断する。リソースの能力は、様々な状況の下で変わることがある。たとえばリソースは能力を低下させ失うことがある；リソースは能力を修正／増強され且つ獲得することが可能である；リソースのローカルマネージャは或る能力を利用可能／利用不可能にすることを判断することが可能であるなどである。
【０１３０】
リソースの能力が変更されたとステップＳ４９４で判断した場合、制御は、検査ステップＳ４９４からステップＳ４９６に移行し、修正されたリソースに対する能力フィールドを変更する。ＮＯの場合、制御は、検査ステップＳ４９４からステップＳ４９８に移行し、修正されたリソースの状態フィールドを変更する（たとえばリソースがいっぱいである；リソースがオフラインである；リソースがオンラインであるなど）。ステップＳ４９６
またはステップＳ４９８の何れかに続いて、制御は、別の反復のために上で議論したステップＳ４８４に戻る。
【０１３１】
なおリソースマネージャサーバ４０６は、本システムの全体に亘って分散可能な複数の個別の演算装置を表わすことが可能であることに注意する。更に個別の演算装置のそれぞれは、リソーステーブルの自分のコピーを維持することが可能である。リソースマネージャサーバ４０６を実施するために使用される個別の演算装置は、リソース情報を共有することも共有しないことも可能であり、また同一のリソース状態メッセージを受信することも受信しないことも可能である。情報の共有および／または状態メッセージの受信が完全ではない例では、演算装置のそれぞれは、リソーステーブルの多少異なるバージョンを有することがあり、リソーステーブルのどのバージョンも本システムのリソースのすべての正確な状態の完全に正確な状況を反映することは可能ではない。
【０１３２】
物理ストレージ４１４は、比較的安価な既製の大量生産された格納ハードウェアを使用して提供可能である。本実施形態では、物理ストレージ４１４のうちの少なくとも幾つかは、連続するＡＴＡ（アドバンストテクノロジーアタッチメント）ディスクドライブを使用して実施可能であり、それはシーゲート社（Ｓｅａｇａｔｅ）およびウェスタンデジタル社（Ｗｅｓｔｅｒｎ  Ｄｉｇｉｔａｌ）などの多くの製造メーカから入手可能である。他で議論するように、物理ストレージは、地理的に分散可能である。しかし、物理ストレージの各部分は、データ格納サーバ４０７のうちの少なくとも１つによって管理／制御可能であり、それは物理ストレージ４１４の対応する部分に対してローカルな従来の演算装置を使用して実施可能である。
【０１３３】
本実施形態では、データ格納サーバ４０７は、本システムにＯＳＤ（オンスクリーンディスプレイ）標準インタフェースを提示することが可能である。このようにサーバ１０２および／またはクライアント１０４〜１０６は、オンスクリーンディスプレイコールを使用してデータ格納サーバ４０７を通じて物理ストレージ４１４にアクセスすることが可能であり、オンスクリーンディスプレイプロトコルによって情報／データを受信することが可能である。加えて、データ格納サーバ４０７は、物理ストレージ４１４の互いに異なる部分の能力および状態を管理／提示することを扱うことが可能である。このようにたとえば物理ストレージ４１４の一部がデータ格納サーバ４０７の特定サーバによって管理されるときに、特定サーバは、新しい状態を示すメッセージをリソースマネージャサーバ４０６に送ることが可能である。
【０１３４】
図３０に示すように、フローチャート５１０は、特定能力を有するリソースに対する問合せのサービスを提供すること（つまり特定能力を有するリソースを見つけること）に関連してリソースマネージャサーバ４０６によって実行されるステップを示す。処理は、最初のステップＳ５１２で始まり、リソーステーブルの各エントリを通じて繰返すために使用されるポインタは、最初のエントリを指すように設定される。ステップＳ５１２に続くのは検査ステップＳ５１４であり、ポインタは、テーブルの終端を過ぎたところを指しているか（つまりすべてのエントリが検討されたか）否か判断する。ＹＥＳの場合、制御は、検査ステップＳ５１４からステップＳ５１６に移行し、要求能力に合致するものがないことを示す結果が、リソースマネージャサーバ４０６によって返される。ステップＳ５１６に続いて処理は終了する。
【０１３５】
エントリを通じて繰返すために使用されるポインタがテーブルの終端を過ぎたところを指していないと検査ステップＳ５１４で判断した場合、制御は、検査ステップＳ５１４から検査ステップＳ５１８に移行し、ポインタによって現在示されているエントリが、要求能力に合致するものであるか否か判断する。なおステップＳ５１８の検査は、リソースがオンラインであり、且ついっぱいではないか、そうでなければ使用不可能ではないことを
保証するために、リソースの状態を確認することを含むことが可能である。ポインタによって示されたリソースが要求能力を有するとステップＳ５１８で判断した場合、制御は、検査ステップＳ５１８からステップＳ５２２に移行し、リソースマネージャサーバ４０６は、合致するリソースを示すインジケータを返す。ステップＳ５２２に続いて処理は終了する。
【０１３６】
ポインタによって示されたリソースが要求能力を有していない（またはオフラインである、いっぱいであるなど）とステップＳ５１８で判断した場合、制御は、検査ステップＳ５１８からステップＳ５２４に移行し、ポインタがインクリメントされる。ステップＳ５２４に続いて、制御は、別の反復のために上で議論したステップＳ５１４に戻る。
【０１３７】
ファイルに対するメタデータオブジェクトの一部であるレイアウト格納オブジェクトツリーは、メタデータサーバ４０５によって作成され、維持され、操作される。メタデータサーバ２０５は、ファイルオブジェクトの操作に関連してクライアント１０４〜１０６からの更新を扱う（たとえば図９のフローチャート２００のステップＳ２１４、図１１のフローチャート２８０のステップＳ２９８など）。更にメタデータサーバ２０５は、レイアウト格納オブジェクトツリーの修正のほかにも、更新に関連して実行される必要がある任意の行為を扱うことが可能である。更にメタデータサーバ２０５は、ファイルオブジェクトに対して得られたリースを扱う。
【０１３８】
図３１に示すように、フローチャート５５０は、ファイルに対するリースの要求のサービスを提供することに関連してメタデータサーバ２０５によって実行されるステップを示す。他で議論するように、リースは、クライアント１０４〜１０６のうちの１つによって要求可能である。しかし、サーバ１０２のコンポーネントのうちの１つが、リースを要求することも可能である。メタデータサーバ４０５のうちの１つが、リースを要求することさえ可能である。より詳細に別記されるように、メタデータサーバ４０５のうちの１つは、ファイル維持（たとえばミラーの補修）に関連してリースを要求することが可能である。本実施形態では、リースは、そのリースを取得したエンティティ、リースのタイプ、（たとえば読出または書込）、および恐らく期限を示すテーブルにおいてメタデータサーバ４０５によって維持される。
【０１３９】
加えて、他で議論するように、ファイル中の論理アドレスの範囲に対するリース動作を実行可能であり、その結果、たとえば１組のリース動作がファイルに対する論理アドレスＡ〜Ｂ上で実行されることが可能である一方、別の組のリース動作が同一ファイルに対して論理アドレスＣ〜Ｄに独立して実行されることが可能であり、Ａ〜Ｂは、Ｃ〜Ｄとは重複しない。１つの書込リースだけが一度に出されるシステムでは、１つのエンティティがファイルのＡ〜Ｂ部分への書込リースを取得することは依然として可能である一方、別の独立したエンティティは、同一ファイルのＣ〜Ｄ部分への書込リースを同時に取得する。従って、ここでの議論のために、適切な例では、ファイル（複数可）への参照は、ファイル（複数可）の非重複部分を含むものと理解されるべきである。
【０１４０】
処理は、最初の検査ステップＳ５５２で始まり、要求されたリースが利用可能であるか否か判断する。ステップＳ５５２での検査は、要求者が適切なセキュリティ資格を有するか否か、対応するデータファイルが存在するか否かなどを判断する。更により詳細に別で議論するように、リースは、或る状況において故意に利用不可能とすることが可能である。リースが利用可能ではないと検査ステップＳ５５２で判断した場合、制御は、検査ステップＳ５５２からステップＳ５５４に移行し、障害インジケータが要求者に返される。障害インジケータは、障害に対する理由（たとえば不適切なセキュリティ資格、ファイルが存在しないなど）を含むことが可能である。ステップＳ５５４に続いて処理は終了する。
【０１４１】
要求されたリースが利用可能であると検査ステップＳ５５２で判断した場合、制御は、ステップＳ５５２から検査ステップＳ５５６に移行し、リース要求が、そのリースに対応するファイルにデータを書込むことに対してのものであるか否か判断する。本実施形態では、複数のユーザ（たとえばクライアント、サーバ）は、同一ファイルを同時に読出すことが可能である一方、１人のユーザだけが同一ファイルに書込むことも可能である。従って、ユーザが書込アクセスを要求していないと検査ステップＳ５５６で判断した場合、制御は、検査ステップＳ５５６からステップＳ５５８に移行し、メタデータサーバ４０５は、リースを返す（つまりリースを与えることに対応する適切なインジケータ／ＩＤを返す）。本実施形態では、リースに所定の期限を設けることも可能であり、その後でリースは有効ではなくなる。リース期限およびリース再コールは、より詳細に他で議論する。加えて、リースは、要求動作（たとえば読出のみ、読出および書込など）のみを可能にするセキュリティ資格（恐らくセキュリティマネージャサーバ４０３によって生成される）と共に提供可能である。更にセキュリティ資格は、リース期限を執行するためにリースが期限切れになるのと同時にまたはその前後で期限切れになることが可能である。ステップＳ５５８に続いて処理は終了する。
【０１４２】
ユーザが書込リースを要求していると検査ステップＳ５５６で判断した場合、制御は、検査ステップＳ５５８から検査ステップＳ５６２に移行し、別のユーザが同一ファイルへの書込リースを既に得ているか否か判断する。他で議論するように、１つの書込リースだけがファイルに対して一度に与えられる。別の書込リースが既に与えられたと検査ステップＳ５６２で判断した場合、制御は、検査ステップＳ５６２からステップＳ５６４に移行し、障害インジケータが返される。ちょうどステップＳ５５４でのように、ステップＳ５６４で返された障害インジケータは、障害の性質を識別する情報を含むことが可能である。ステップＳ５６４に続いて処理は終了する。別の書込リースが与えられていないと検査ステップＳ５６２で判断した場合、制御は、検査ステップＳ５６２からステップＳ５６６に移行し、メタデータサーバ４０５は、恐らく期限と共にリースを返す。ステップＳ５６６に続いて処理は終了する。
【０１４３】
他で議論するように、幾つかの例では、有効期限の日にちと共にリースを出すのが望ましい。本実施形態では、メタデータサーバ４０５のうちの特定１つは、特定ファイルおよび対応するファイルオブジェクトに関与することが可能である。メタデータサーバ４０５は、ファイルに対するリースおよび対応するファイルオブジェクトを出し、リース期限処理を扱う。リース情報は、メタデータサーバ４０５の関与する１つによって適切なデータ構造（たとえばテーブル、リンクリストなど）で格納可能である。加えて、複数のメタデータサーバ４０５を、特定ファイルまたは特定組のファイルに関与させることも可能であり、メタデータサーバ４０５のうちの１つは、プライマリサーバであり、他の関与するメタデータサーバは、第２サーバであり、適切な情報を維持するが、プライマリサーバに障害が発生しない限りサービスを提供しない。
【０１４４】
図３２に示すように、フローチャート５８０は、リース期限を監視することに関連してメタデータサーバ４０５の関与する１つによって実行されるステップを示す。処理は、最初のステップＳ５８２で始まり、サーバが関与するすべてのリース（ファイルおよびリースの組合せ）を通じて繰返すポインタが、最初のものを指すようにされる。ステップＳ５８２に続くのは検査ステップＳ５８４であり、リースが期限切れになったか否か判断する。ステップＳ５８４で実行される処理は、リース期限を現在の時刻と比較することを含む任意の適切な技術を使用することが可能である。リースが期限切れになったとステップＳ５８４で判断した場合、制御は、ステップＳ５８４からステップＳ５８６に移行し、リースが再コールされる。ステップＳ５８６でリースを再コールすることは、より詳細に別で議論する。
【０１４５】
ステップＳ５８６に続くのは、またはリースが期限切れではない場合のステップＳ５８４に続くのは、ステップＳ５８８であり、サーバが関与するファイルおよびリースを通じて繰返すポインタがインクリメントされる。ステップＳ５８８に続くのは検査ステップＳ５９２であり、ポインタが、終端を過ぎたところを指しているか（つまりすべてのファイルおよび対応するリースが処理されたか）否か判断する。ＹＥＳの場合、制御は、上で議論したステップＳ５８２にステップＳ５９２から移行し、ポインタが最初のものを指すようにリセットし、期限切れのリースを確認するために別のパスを始める。ポインタが終端を過ぎたところを指していないとステップＳ５９２で判断した場合、制御は、別の反復のために、上で議論した検査ステップＳ５９２からステップＳ５８４に移行する。
【０１４６】
本実施形態では、本システムは、ｃｌｏｓｅ−ｔｏ−ｏｐｅｎの一貫性を提供することが可能であり、エンティティが書込アクセスを解除した後のデータの一貫性が提供される。上記の如く異なって、エンティティがファイルに対するアクティブな書込リースを有していないときには、一貫性がファイルに提供される。反対に、任意のエンティティがアクティブな書込リースを有する一方で、データの状態が、データを読出す任意のエンティティに対して保証されなくてもよい。ここで記述される本システムでは、リースは、期限切れ後に再コール可能であるか、または他の理由で再コール可能である。リースの再コールは、他のエンティティによってアクセスされているデータの一貫性を改善することが可能である。
【０１４７】
図３３に示すように、フローチャート６１０は、リースを再コールするメタデータサーバ４０５のうちの特定１つに関連して実行されるステップを示す。処理は、最初のステップＳ６１２で始まり、メッセージは、リースを保持するエンティティ（たとえばクライアント１０４〜１０６のうちの１つ）に送信され、リースが再コールされているとエンティティに知らせる。他で議論するように、クライアント１０４〜１０６、他のサーバ、またはメタデータサーバ４０５のうちの１つでさえも含む任意の適切なエンティティは、リースを保持することが可能である。幾つかの実施形態では、ステップＳ６１２は、エンティティによってメッセージの受信を保証すること（たとえば肯定応答を待機すること）を含むことが可能である一方、他の実施形態では、メッセージが単に送られ、メッセージが任意の運用上の受信者によって受信されると仮定される。勿論、肯定応答を待機するシステムでは、タイムアウトおよび／または試行回数に対する制限がある場合がある。
【０１４８】
ステップＳ６１２に続くのはステップＳ６１４であり、適切なテーブルが、再コールされたリースがもはや未処理ではないことを反映するように調整される。リースと共に使用されるテーブルおよび他のデータ構造は、より詳細に別で議論する。ステップＳ６１４に続くのは検査ステップＳ６１６であり、再コールされたリースが書込リースであったか（データを書込むことを可能にするリース）否か判断する。他で議論するように、本システムは、ｃｌｏｓｅ−ｔｏ−ｏｐｅｎの一貫性を提供することが可能であり、その結果、書込リースが解除されるときにデータ読出が一貫性を持つようにされる。これは、書込リースが再コールされるときにすべての読出リースを再コールすることによって促進可能である。読出リースが再コールされるエンティティは、再コール後に読出リースを再び取得する前にそれらの内部バッファをフラッシュすることが可能である。なお書込リースが再コールされるエンティティは、再コール通知を受信するのに応じて（データ格納サーバ４０７を通じて）物理ストレージ４１４に、格納されていないデータを書込むことによってバッファをフラッシュすることも可能である。従って、幾つかの実施形態では、書込リースに対する再コールメッセージを受信するエンティティは、物理ストレージに任意の格納されていないデータを書込む或る時間量を持つことが可能である。この目的のために、書込リースと共に提供されるセキュリティ資格は、書込リースが期限切れになった後の所定の時間量の後で期限切れになるように設定可能である。
【０１４９】
再コールされているリースが書込リースではないとステップＳ６１６で判断した場合、処理は終了する。ＹＥＳの場合、制御は、検査ステップＳ６１６からステップＳ６１８に移行し、書込リースが再コールされているファイルに対するすべての未処理のリースを通じて繰返すために使用されるポインタが最初の未処理のリースを指すようにされる。ステップＳ６１８に続くのは検査ステップＳ６２２であり、ポインタが終端を過ぎたところを指すか（つまりすべての未処理のリースが再コールされたか）否か判断する。ＹＥＳの場合、処理は終了する。ＮＯの場合、制御は、検査ステップＳ６２２からステップＳ６２４に移行し、リースが再コールされる。リースは、フローチャート６１０によって示された処理をコールすることによって再コールされ、従って再帰的であることが可能である。ステップＳ６２４に続くのはステップＳ６２６であり、ファイルに対する未処理のリースを有するエンティティを通じて繰返すために使用されるポインタがインクリメントされる。ステップＳ６２６に続いて、制御は、別の反復のためにステップＳ６２２に戻る。
【０１５０】
図３４に示すように、テーブル６３０は、メタデータサーバ４０５のうちの特定１つが関与するファイルを追跡するために使用される複数のエントリを含むものとして示されている。勿論、他の適切なデータ構造が、リンクリスト、二重リンクリストなどのテーブル６３０の代わりに使用可能である。メタデータサーバ４０５の各一次サーバおよびメタデータサーバ４０５の任意の対応する二次サーバは、メタデータサーバ４０５の特定のものが関与する特定ファイルセットに対応するデータを含むことが可能である。このようにたとえばメタデータサーバ４０５の第１一次サーバは、メタデータサーバの第１一次サーバが関与するファイルの第１セットのためのテーブル６３０のバージョンを含むことが可能である一方、メタデータサーバ４０５の第２一次サーバは、メタデータサーバ４０５の第２一次サーバが関与するファイルの第２（異なる）セットのためのテーブル６３０の完全に異なるバージョンを含むことが可能である。
【０１５１】
テーブル６３０の各エントリは、エントリに対応するファイルを一意に識別するファイルＩＤフィールド（ＦＩＤフィールド）を含む。本実施形態では、ファイルＩＤフィールドは、ファイルに対するメタデータオブジェクト（たとえば図４の略図１３０におけるメタデータオブジェクト１３２）のオブジェクトＩＤであることが可能である。なお他で議論するように、ファイルに対するメタデータオブジェクトは、ファイルに対する他のデータオブジェクトのすべてを見つけるために使用可能である。
【０１５２】
ＭＤ  ＬＯＣフィールドは、ファイルに対するメタデータオブジェクトのデータ格納位置について記述することが可能である。本実施形態では、ＭＤ  ＬＯＣフィールドは、ファイルに対するメタデータオブジェクトを格納するデータ格納サーバ４０７のうちの１つに対するＩＤを含むことが可能である。更にＴＨＥ  ＭＤ  ＬＯＣフィールドは、データ格納サーバ４０７のうちの１つでのデータを検索および格納するために使用可能な（恐らくデータ格納サーバ４０７のうちの１つによって最初に割当てられた）固有のＩＤを含むことが可能である。
【０１５３】
リースリストフィールドは、対応するファイルに対して未処理のアクティブなリースを有するすべてのエンティティに関する情報を含むことが可能である。本実施形態では、リースリストフィールドは、未処理のリースを有するエンティティに対応する要素のリンクリストへのポインタを含むことが可能である。勿論、任意の他の適切なデータ構造（たとえば配列）が使用されることも可能である。
【０１５４】
図３５に示すように、略図６４０は、ファイルに対する未処理のアクティブなリースを有するエンティティを追跡するために使用可能なリンクリストを示す。リストの各要素は、リスト中の次の要素を指すネクストフィールドを含む。リストの終端の要素は、ｎｕｌｌインジケータを含む。このようにリストは、リースリストポインタによって要素が指さ
れることから始め、続いて、ネクストフィールドによって指される要素を指すことによって（たとえば図３２のフローチャート５８０に示した処理に関連して）、横断可能である。同様に、従来のリンクリスト動作は、要素を追加および削除するために使用可能である。
【０１５５】
更にリストの各要素は、リースのタイプ（たとえば読出または書込）を示すタイプフィールドを含み、また要素に対応するリースがいつ期限切れになるかを示す期限フィールドを含む。更に各要素は、対応するリースを保持するエンティティ（たとえばクライアント１０４〜１０６のうちの１つ、別のサーバなど）を示すエンティティフィールドを含む。
【０１５６】
リンクリストの操作は、かなり単純である。リースが与えられたときには、要素のフィールドは、リースに対応するタイプ、有効期限、およびエンティティを追加され、次に要素は、リストに加えられる。同様に、リースが再コールされるかまたは返されるときには、対応する要素は、リストから取り除かれる。勿論、他のデータ構造がリンクリストの代わりに使用されることも可能である。
【０１５７】
図３６に示すように、テーブル６５０は、オブジェクトＩＤを位置情報（ＬＯＣ）に相関させる複数のエントリを含むものとして示されている。本実施形態では、オブジェクトＩＤは、数値である。メタデータサーバ４０５のそれぞれは、使用／管理するためのオブジェクトＩＤの固有範囲を備えている。幾つかの実施形態では、オブジェクトＩＤは、再使用可能である一方で、他の実施形態では、オブジェクトＩＤは、再使用されない。勿論、オブジェクトＩＤが再使用されない例では、メタデータサーバ４０５のそれぞれは、十分な範囲の使用可能なオブジェクトＩＤを備えている必要がある。
【０１５８】
ＬＯＣフィールドは、テーブル６３０に対するＭＤ  ＬＯＣフィールドと同様である。ＬＯＣフィールドは、対応するオブジェクトのデータ格納位置について記述している。本実施形態では、ＬＯＣフィールドは、オブジェクトに対するデータを検索および格納するために使用可能な（恐らく、データ格納サーバ４０７のうちの１つに割当てられた）固有のＩＤとしてのオブジェクトを含む（扱っている）データ格納サーバ４０７のうちの１つのＩＤを含むことが可能である。このようにメタデータサーバ４０５のうちの１つが特定オブジェクトに対するテーブルエントリを有する場合、エンティティは、オブジェクトＩＤをメタデータサーバ４０５のうちの１つへ渡し、その代わりに対応するＬＯＣ情報を受信して、エンティティがデータ格納サーバ４０７のうちの適切な１つに直接アクセスすることを可能にすることができる。
【０１５９】
多数のメタデータサーバ４０５を有することは、ファイル動作の分配サービス（従って重要なスケーラビリティ）の提供を可能にすると共に、障害迂回／冗長能力を提供する。幾つかの例では、オブジェクトは、メタデータサーバ４０５のうちの１つから別のものに再び割当てられることが可能である。しかし、メタデータサーバ４０５のそれぞれがファイルのサブセットのみ（および対応するファイルオブジェクト）に対する情報を含むので、動作を実行することに関連してメタデータサーバ４０５のうちの適切な１つを見つけるシステムを提供することが必要である場合がある。
【０１６０】
メタデータ位置サーバ４０８は、特定ファイルに対する動作のためにメタデータサーバ４０５のうちの適切な１つを捜すエンティティに対する位置サービスを提供する。本実施形態では、メタデータ位置サーバ４０８のそれぞれは、オブジェクトＩＤを有するコールを受信し、特定オブジェクトを扱うメタデータサーバ４０５のうちの特定１つを返すことができる。加えて、より詳細に別で議論するように、メタデータ位置サーバ４０８は、コールするエンティティ（たとえばクライアント１０４〜１０６のうちの１つ）に、新しいオブジェクトに使用されるメタデータサーバ４０５のうちの特定１つを示すことによって
、新しいオブジェクトの生成に関連して支援することが可能である。メタデータサーバ４０８は、ウェブ上のドメインネームサーバのように動作することが可能であり、クライアント１０４〜１０６（および他のエンティティ）のそれぞれは、調べるべきメタデータ位置サーバ４０８の一次および二次サーバを備えることが可能である。
【０１６１】
図３７に示すように、テーブル６７０は、メタデータ位置サーバ４０８のうちの１つによる使用のためのエントリを含むものとして示されている。各エントリは、オブジェクトＩＤ範囲フィールドを含む。それはオブジェクトＩＤの範囲およびＭＤＳ  ＩＤフィールドを示し、メタデータサーバ４０５のうちの特定１つ、または恐らくメタデータサーバ４０５のグループを識別し、そのうちの１つは一次であり、残りは二次である。エンティティは、メタデータ位置サーバ４０８に特定オブジェクトＩＤを提供することが可能であり、その後、それはテーブル６７０を調べて、ＭＤＳ  ＩＤフィールドから対応する値を返すことが可能である。
【０１６２】
加えて、メタデータ位置サーバ４０８は、新しいオブジェクトの生成に関連してメタデータサーバ４０５のうちの特定１つを割当てることが可能である。割当は、上で議論したランダムな割当、地理的近接に基づいた割当、ロード平衡、および／またはユーザ管理インタフェース４１２を通じたユーザによるポリシーの入力を含む任意の適切な測定基準に基づくことが可能である。ポリシーは、たとえば特定クライアントによって作成された新しいオブジェクトが特定メタデータサーバ上に提供されることを示すことが可能である。
【０１６３】
図３８に示すように、フローチャート６８０は、新規ファイルオブジェクトの生成に関連してメタデータサーバのうちの特定１つを割当てるためのメタデータ位置サーバ４０８のうちの１つによる処理を示す。処理は、最初のステップＳ６８２で始まり、ポリシーが尋ねられることが可能である。他で議論するように、ユーザ管理インタフェース４１２を通じてポリシーを入力することも可能である。ポリシーは、どのメタデータサーバ４０５がどのクライアント１０４〜１０６に対して使用されるかについて（直接または間接的に）指示することが可能である。なお他のポリシーも可能である。たとえばポリシーは、どのメタデータサーバ４０５がその日の互いに異なる時刻に、またはロード、ユーザなどに基づいて使用されるか（クライアント１０４〜１０６とは無関係に）を示すことが可能である。ポリシー情報は、ユーザ管理インタフェース４１２に格納され、ステップＳ６８２に関連してアクセス可能であるか、または以前にそれを通った後でメタデータ位置サーバ４０８のうちの１つに格納可能である。ステップＳ６８２に続くのはステップＳ６８４であり、メタデータ位置サーバ４０５のうちの特定１つに対する識別情報が、コールするエンティティに返される。ステップＳ６８４に続いて処理は終了する。
【０１６４】
図３９に示すように、フローチャート７００は、メタデータサーバ４０５のうちの１つが関与するファイルを削除することに関連してメタデータサーバ４０５のうちの１つによって実行されるステップを示す。処理は、最初のステップＳ７０２で始まり、ファイルに対するすべてのリースが再コールされる（たとえば図３３のフローチャート６１０によって示されたように、リースリスト６４０を通じて繰返し、再コール処理を提供することによって）。ステップＳ７０２に続くのはステップＳ７０４であり、リースが、他の処理に対して利用不可能にされる（たとえばファイルに対する更なるリースを与えることを防止する適切なフラグをセットすることによって）。ステップＳ７０４に続くのはステップＳ７０６であり、ファイルに対するメタデータが得られる（たとえばファイルに対するメタデータオブジェクトを取出すことによって）。なお他で議論するように、ファイルに対するメタデータオブジェクトは、ファイルに関連して使用されるすべてのファイルオブジェクトの位置に関する情報を含む。
【０１６５】
ステップＳ７０６に続くのはステップＳ７０８であり、ファイルに関連して使用される
オブジェクトを通じて繰返すために使用されるポインタが、最初のオブジェクトを指すようにされる。ポインタおよび後の反復処理は、ファイルに対するオブジェクトを判断するためにステップＳ７０６で得られた情報を使用する。ステップＳ７０８に続くのは検査ステップＳ７１２であり、オブジェクトを通じて繰返すために使用されるポインタが終端を過ぎたところを指しているか（つまりファイルオブジェクトのすべてが処理されたか）否か判断する。ＹＥＳの場合、制御は、検査ステップＳ７１２からステップＳ７１４に移行し、ファイルに対応するテーブルエントリ（つまり図３４のテーブル６３０中のエントリ）が削除される（たとえばｎｕｌｌに設定する）。ステップＳ７１４に続いて処理は終了する。
【０１６６】
処理すべき更なるファイルオブジェクトがあるとステップＳ７１２で判断した場合、制御は、ステップＳ７１２からステップＳ７１６に移行し、ＬＯＣ情報がオブジェクトに対して得られる。ＬＯＣ情報は、上で議論した図３６のテーブル６５０に格納された情報と同様である。幾つかの例では、ＬＯＣ情報は、処理を実行するメタデータサーバ４０５のうちの１つに対してローカルになる。他の例では、オブジェクトに対する位置情報を得るためにメタデータ位置サーバ４０８のうちの１つにコールすることが必要である場合がある。ステップＳ７１６に続くのはステップＳ７１８であり、メッセージが、オブジェクトを削除させるために、データ格納サーバ４０７のうちの適切な１つ（つまりオブジェクトを扱うもの）に送られる。
【０１６７】
本実施形態では、互いに異なるファイルが同一のオブジェクト（たとえば複製、ファイルエイリアシングなど）を使用することが可能であり、その場合、データ格納サーバ４０７のうちの１つは、そのユーザの数を示すオブジェクトに対するカウンタを単にデクリメントする。カウンタが零までデクリメントされたときには、データ格納サーバは、オブジェクトに対応するデータを削除することが可能である。なおファイルに関連づけたオブジェクトは、非同期に削除可能である。ステップＳ７１８に続くのはステップＳ７２２であり、ファイルオブジェクトを通じて繰返すために使用されるポインタがインクリメントされる。ステップＳ７２２に続いて、制御は、別の反復のために、上で議論したステップＳ７１２に戻る。
【０１６８】
図４０に示すように、フローチャート７４０は、新規ファイルを作成することに関連してメタデータサーバ４０５のうちの１つによって実行されるステップを示す。なお図４０に示した処理を実行する前に、ファイルを作成するエンティティ（たとえばクライアント１０４〜１０６のうちの１つ）は、ファイルを作成するために使用するメタデータサーバ４０５のうちの適切な１つを判断するために、メタデータ位置サーバ４０８にまず尋ねることが可能である。
【０１６９】
処理は、最初のステップＳ７４２で始まり、ポリシーマネージャサーバ４０２が、新規ファイルに対するポリシー情報を得るために尋ねられる（たとえばクライアントＸに対する新規ファイルは、一次データセットから少なくとも或る距離だけ地理的に離れたミラーを有する）。ステップＳ７４２に続くのはステップＳ７４４であり、リソースマネージャサーバ４０６が、ステップＳ７４２で得られたポリシーのその指令を満足する利用可能なリソースを判断するために、尋ねられる。ステップＳ７４４に続くのは検査ステップＳ７４６であり、利用可能なリソースを与えられたポリシーの指令を満足することが可能であるか否か判断する。たとえばシステムにおける残りの物理ストレージのすべてが１つの地理的位置にある場合、地理的に分離したミラーを有するポリシーを満足させることは可能ではない。ポリシーを満足することが可能ではないと検査ステップＳ７４６で判断した場合、制御は、検査ステップＳ７４６からステップＳ７４８に移行し、代替処理が実行される。コールするエンティティにエラーインジケータを返すこと、次の最良の利用可能なリソースでファイルを作成することなどを含む任意の適切な処理が、ステップＳ７４８で実
行されることが可能である。ステップＳ７４８に続いて処理は終了する。
【０１７０】
利用可能なリソースを有するポリシーを満足することが可能であるとステップＳ７４６で判断した場合、制御は、検査ステップＳ７４６からステップＳ７５２に移行し、ファイルに対するメタデータオブジェクトが作成される。メタデータオブジェクトを作成することは、メタデータオブジェクトのデータフィールドを加えること、データ格納サーバ４０７のうちの適切な１つからストレージを得ることを含むことが可能である。本実施形態では、データ格納サーバ４０７は、プールであり、任意の他の特定要件が不在であることが可能であり、要求に応じて物理ストレージ４１４の任意の適切な部分に格納空間を提供することが可能である。ステップＳ７５２で作成されたメタデータオブジェクトは、ここで記述されるものと同様である。たとえば図４〜図８および対応する記述を参照する。ステップＳ７５２に続くのはステップＳ７５４であり、テーブルエントリが、新規ファイルに対するテーブル６３０に作られる。ステップＳ７５４に続くのはステップＳ７５６であり、ファイルに対するメタデータオブジェクトのオブジェクトＩＤがコールするエンティティに返される。ステップＳ７５６に続いて処理は終了する。
【０１７１】
他で議論するように、クライアントまたは他のエンティティが書込動作の試行に失敗したときには、メッセージ（更新）が、クライアントまたは他のエンティティによってサーバ１０２に送られる。同様に、メッセージ（更新）は、同期ミラーコピー（図１３のフローチャート３５０のステップＳ３５８を参照）に関連して古いミラーを見つけること、および／または非同期ミラーを有するデータに書込むことに関連してサーバ１０２に送られることも可能である。
【０１７２】
図４１に示すように、フローチャート７６０は、書込動作が失敗であったというメッセージを扱うことに関連して、メタデータサーバ４０５のうちの１つによって実行されるステップを示す。処理は、最初のステップＳ７６２で始まり、ファイルに対するリースのすべてが再コールされる。ステップＳ７６２に続くのはステップＳ７６４であり、ファイルに対するリースが利用不可能にされる。ステップＳ７６４に続くのはステップＳ７６６であり、新しい格納空間が、書込動作が失敗であった古い格納空間を交換するために割付けられる。ステップＳ７６６に続くのはステップＳ７６８であり、ファイルに対するメタデータオブジェクト中の適切な情報が調整される。ステップＳ７６８に続くのはステップＳ７７２であり、たとえばミラーのうちの１つからのデータを有する新しいデータ格納空間に再度加えるために、データコピー動作が始められる。データコピー動作が実行されている間、データは、ステップＳ７７２で古いと示すことが可能である。勿論、新しい格納空間に再度加えるために使用されることができるミラーまたは他のデータがない場合、ステップＳ７７２の処理は実行されない。ステップＳ７７２に続くのはステップＳ７７４であり、ファイルに対するリースが利用可能になる。ステップＳ７７４に続いて処理は終了する。
【０１７３】
図４２に示すように、フローチャート７８０は、同期ミラーが古かったことの表示を受信するメタデータサーバ４０５のうちの１つに関連して実行される処理を示す。処理は、最初の検査ステップＳ７８２で始まり、ミラーが、現在データを加えられる処理中であるか（恐らく前の悪い書込動作に関連して）否か判断する。ＹＥＳ（図４２のＮＯは誤記）の場合、データ追加動作が継続を許され、処理が終了する。ＮＯ（図４２のＹＥＳは誤記）の場合、制御は、検査ステップＳ７８２からステップＳ７８４に移行し、上で議論した図４１のフローチャート７６０に示したような処理が実行される。ステップＳ７８４に続いて処理は終了する。
【０１７４】
図４３に示すように、フローチャート７９０は、非同期コピーに対応するデータが書込まれ、それによって、非同期コピーの更新を必要とするというメッセージをサーバ１０２
が受信するのに関連して実行されるステップを示す。処理は、最初のステップＳ７９２で始まり、情報が、非同期データをコピーする必要があることを示すキュー（たとえばメタデータサーバ４０５のうちの影響を受けた１つに提供されるジョブキュー）に加えられる。更に他で議論するように、メタデータサーバ４０５のそれぞれでの処理は、対応するキューのサービスを提供する。ステップＳ７９２に続いて処理は終了する。
【０１７５】
図４４に示すように、フローチャート８００は、図４３のフローチャート７９０によって示された処理によって加えられる対応するキューのサービスを提供するメタデータサーバ４０５のそれぞれでの処理によって実行される処理を示す。処理は、最初の検査ステップＳ８０２で始まり、キューが空であるか否か判断する。ＹＥＳの場合、制御は、検査ステップＳ８０２に戻り、キューを獲得し続ける。キューが空ではない場合、制御は、検査ステップＳ８０２からステップＳ８０４に移行し、キューにおける次のエントリが取り除かれる。本実施形態では、キュー要素は、ファーストインファーストアウト方式で処理可能である。しかし、任意の順序でキューから要素を選択的に取り除くことも可能である。たとえばより高い優先順位を受信するファイルに関連した要素は、他の要素の前に（たとえばファイルに対するフラッシュ動作に関連して）削除可能である。別例として、要素が、（必要とされる書込動作の）サイズに応じて、または他の適切な基準に応じて削除されることも可能である。
【０１７６】
ステップＳ８０４に続くのはステップＳ８０６であり、影響を受けたファイルへの書込リースが再コールされる。ステップＳ８０６に続くのはステップＳ８０８であり、書込リースが得られる。ステップＳ８０８に続くのはステップＳ８１２であり、ミラーに非同期データを書込むために書込動作が実行される。ステップＳ８１２に続くのはステップＳ８１４であり、書込ロックが解除される。ステップＳ８１４に続いて、制御は、ステップＳ８０２に戻り、キューを獲得し続ける。
【０１７７】
ここで記述される本システムは、クライアントにファイルオブジェクトを提供することができる任意のサーバまたはサーバの任意のグループで使用可能である。ファイルオブジェクトの特定形態は、本発明の精神および範囲から逸脱することなく変えることが可能である。幾つかの例では、フローチャートのステップの順序は、適切な場合には修正可能である。ここで記述される本システムは、コンピュータ読取可能な記憶媒体に提供されるコンピュータプログラム製品／ソフトウェアを使用して実施可能である。
【０１７８】
本発明は様々な実施形態に関連して開示されているが、それへの修正は当業者にとっては容易に明白になる。従って、本発明の精神および範囲は、次の特許請求の範囲で述べられる。
【図１】
0005504165.tif 000002
【図２Ａ】
0005504165.tif 000003
【図２Ｂ】
0005504165.tif 000004
【図３】
0005504165.tif 000005
【図４】
0005504165.tif 000006
【図５】
0005504165.tif 000007
【図６】
0005504165.tif 000008
【図７】
0005504165.tif 000009
【図８】
0005504165.tif 000010
【図９】
0005504165.tif 000011
【図１０】
0005504165.tif 000012
【図１１】
0005504165.tif 000013
【図１２】
0005504165.tif 000014
【図１３】
0005504165.tif 000015
【図１４】
0005504165.tif 000016
【図１５】
0005504165.tif 000017
【図１６】
0005504165.tif 000018
【図１７】
0005504165.tif 000019
【図１８】
0005504165.tif 000020
【図１９】
0005504165.tif 000021
【図２０】
0005504165.tif 000022
【図２１】
0005504165.tif 000023
【図２２】
0005504165.tif 000024
【図２３】
0005504165.tif 000025
【図２４】
0005504165.tif 000026
【図２５】
0005504165.tif 000027
【図２６】
0005504165.tif 000028
【図２７】
0005504165.tif 000029
【図２８】
0005504165.tif 000030
【図２９】
0005504165.tif 000031
【図３０】
0005504165.tif 000032
【図３１】
0005504165.tif 000033
【図３２】
0005504165.tif 000034
【図３３】
0005504165.tif 000035
【図３４】
0005504165.tif 000036
【図３５】
0005504165.tif 000037
【図３６】
0005504165.tif 000038
【図３７】
0005504165.tif 000039
【図３８】
0005504165.tif 000040
【図３９】
0005504165.tif 000041
【図４０】
0005504165.tif 000042
【図４１】
0005504165.tif 000043
【図４２】
0005504165.tif 000044
【図４３】
0005504165.tif 000045
【図４４】
0005504165.tif 000046