(57)【特許請求の範囲】
【請求項１】
分散型ファイルシステムであって、
それぞれが少なくとも一つのプロセッサと少なくとも一つの記憶装置と少なくとも一つの実行可能なソフトウェアモジュールとを備えた複数の知的記憶ユニットと、
前記複数の知的記憶ユニットの２以上の第１のサブセットに分散された複数のデータブロックからなるデータファイルと、
前記複数のデータブロックのそれぞれのロケーションを含み、前記データファイルに関連するメタデータと、
を備え、
前記メタデータは、前記複数のデータブロックのそれぞれとは異なる知的記憶ユニットであって前記複数の知的記憶ユニットのうちの一つの知的記憶ユニットに存在し、
前記複数の知的記憶ユニットのそれぞれの前記少なくとも一つの実行可能なソフトウェアモジュールは、
前記分散ファイルシステムのコンポーネントから前記データファイルに関連するリクエストを受け取り、
前記メタデータをリクエストして、前記異なる知的記憶ユニットから前記メタデータを受け取り、
前記リクエストに応答して少なくとも前記複数のデータブロックのサブセットについてのリードオペレーションまたはライトオペレーションを実行するように構成され、
前記複数のデータブロックのサブセットの１又は２以上は、他の知的記憶ユニットの記憶装置上に配置された分散型ファイルシステム。
【請求項２】
第２のデータファイルを更に備え、前記メタデータは、更に、反復および冗長情報を含み、前記少なくとも一つの実行可能なソフトウェアモジュールは、前記第２のデータファイルとは異なる第１の前記データファイルについての冗長性および反復の異なるレベルを提供するように更に構成された請求項１記載の分散型ファイルシステム。
【請求項３】
前記反復情報はパリティ情報を備えた請求項２記載の分散型ファイルシステム。
【請求項４】
前記複数の知的記憶装置の２以上のサブセットに分散された複数の誤り訂正ブロックからなる誤り訂正データを更に含み、前記パリティ情報は、前記複数の誤り訂正ブロックのそれぞれのロケーションを含む請求項３記載の分散型ファイルシステム。
【請求項５】
前記少なくとも一つの実行可能なソフトウェアモジュールは、前記複数のデータブロックの反復または冗長性の前記レベルを変更し、前記メタデータの前記反復および冗長情報をアップデートするように更に構成された請求項１記載の分散型ファイルシステム。
【請求項６】
前記反復または冗長性のレベルの変更は、前記データファイルのコピーであって複数のミラーデータブロックからなるコピーをリアルタイムに生成するステップと、前記複数のミラーデータブロックのそれぞれのロケーションを更に含むように前記メタデータをアップデートするステップとを含み、前記ミラーデータブロックは、前記複数の知的記憶ユニットの２以上のサブセットに分散された請求項５記載の分散型ファイルシステム。
【請求項７】
前記少なくとも一つの実行可能なソフトウェアモジュールは、前記複数のデータブロックをリアルタイムに移動し、前記メタデータにおける前記複数のデータブロックのそれぞれのロケーションをアップデートするように更に構成された請求項１記載の分散型ファイルシステム。
【請求項８】
前記少なくとも一つの実行可能なソフトウェアモジュールは、前記複数のデータブロックをリアルタイムに反復し、前記複数の反復されたデータブロックのそれぞれのロケーションを更に含むように前記メタデータをアップデートするように構成された請求項１記載の分散型ファイルシステム。
【請求項９】
前記少なくとも一つの実行可能なソフトウェアモジュールは、前記複数のデータブロックのサブセットについてのリクエストの高容量(high volume)に応じて少なくとも前記複数のデータブロックのサブセットを反復するように更に構成された請求項８記載の分散型ファイルシステム。
【請求項１０】
前記少なくとも一つの実行可能なソフトウェアモジュールは、前記複数のデータブロックのサブセットを記憶するハードウェアの高利用(high utilization)に応じて少なくとも前記複数のデータブロックのサブセットを反復するように更に構成された請求項８記載の分散型ファイルシステム。
【請求項１１】
前記少なくとも一つの実行可能なソフトウェアモジュールは、ライトリクエストよりも多くのリードリクエストを処理するように更に構成された請求項１記載の分散型ファイルシステム。
【請求項１２】
前記少なくとも一つの実行可能なソフトウェアモジュールは、ブロックトランザクションを処理するように更に構成された請求項１記載の分散型ファイルシステム。
【請求項１３】
複数のモジュラー記憶装置間でデータファイルを記憶するためのバーチャルファイルシステムであって、
分散型メッセージングシステムと、
複数の記憶ユニットを備え、
前記記憶ユニットのそれぞれは、
前記分散型メッセージングシステムを通じて他の複数の記憶ユニットのそれぞれと通信し、
データブロックを記憶し、
複数のデータブロックからなるデータファイルであって、前記複数のデータブロックが、前記記憶ユニット上に記憶された前記複数のデータブロックの０又は１以上からなる、前記複数のデータブロックのローカルサブセットと、１又は２以上のリモート記憶ユニット上に記憶された前記複数のデータブロックの１又は２以上からなる、前記複数のデータブロックのリモートサブセットとを備えて構成された前記データファイルについてのリードリクエストを、当該バーチャルファイルシステムのコンポーネントから前記記憶ユニットで受信し、
前記複数のデータブロックの前記ローカルサブセット及び前記リモートサブセットのそれぞれのロケーションを含むメタデータを、前記複数のデータブロックの前記リモートサブセットを記憶する前記１又は２以上のリモート記憶ユニットのうちの少なくとも一つから読み出して、前記複数のデータブロックの前記リモートサブセットを記憶する前記１又は２以上のリモート記憶ユニットのうちの、全てではない、少なくとも一つに存在させ、
前記複数のデータブロックのローカルサブセットを読み出し、
前記１又は２以上のリモート記憶ユニットからの前記複数のデータブロックの前記リモートサブセットを、前記分散型メッセージングシステムを通じてリクエストし、
前記１又は２以上のリモート記憶ユニットからの前記複数のデータブロックの前記リモートサブセットのコピーを、前記分散型メッセージングシステムを通じて受信し、
前記リクエストされたデータファイルの前記複数のデータブロックの全てを戻すように構成されたバーチャルファイルシステム。
【請求項１４】
前記複数の記憶ユニットは、記憶装置および処理モジュールを備え、前記複数のデータブロックの前記ローカルサブセットは、前記記憶装置上に記憶され、且つ前記処理モジュールは、前記記憶装置から前記複数のデータブロックの前記ローカルサブセットを読み出す請求項１３記載のバーチャルファイルシステム。
【請求項１５】
前記複数の記憶ユニットのそれぞれと通信する負荷バランシングスイッチを更に備え、前記複数の記憶ユニットのそれぞれは、複数のデータブロックからなるデータファイルについてのライトリクエストを受信すると共に、前記ライトリクエストに応答して前記複数のデータブロックを記憶すべき前記複数の記憶ユニットの２以上のサブセットを決定するように更に構成された請求項１３記載のバーチャルファイルシステム。
【請求項１６】
前記複数の記憶ユニットのそれぞれは、１又は２以上のリモート記憶ユニットから受信された統計に基づいて前記ライトリクエストに応答して前記複数のデータブロックを分散するように更に構成された請求項１５記載のバーチャルファイルシステム。
【請求項１７】
前記ライトリクエストは、ミラー保護情報を備えた請求項１６記載のバーチャルファイルシステム。
【請求項１８】
前記複数の記憶ユニットのそれぞれは、前記複数の記憶ユニットの２以上のサブユニットに前記複数のデータブロックのコピーを分散し、前記コピーの分散が、前記ミラー保護情報に適合するように更に構成された請求項１７記載のバーチャルファイルシステム。
【請求項１９】
前記ライトリクエストはパリティ保護情報を備えた請求項１６記載のバーチャルファイルシステム。
【請求項２０】
前記複数の記憶ユニットのそれぞれは、パリティデータを生成し、前記複数の記憶ユニットの２以上のサブユニットに前記パリティデータを分散し、前記パリティデータの生成と分散が前記パリティ保護情報に適合するように更に構成された請求項１９記載のバーチャルファイルシステム。
【請求項２１】
分散ファイル記憶を提供するために複数のモジュラー記憶ユニットと通信するように構成されたモジュラー記憶ユニットであって、
データブロックを記憶するように構成された記憶モジュールと、
処理モジュールとを備え、
前記処理モジュールは、
ローカルに記憶されたデータブロックとリモートに記憶されたデータブロックを含む複数のデータブロックからなるデータファイルについてのリクエストを、転送コンポーネントから前記モジュラー記憶ユニットで受信し、
前記リクエストされたデータファイルに対応するファイルロケーションデータ構造を読み出し、
前記記憶モジュールから前記ローカルに記憶されたデータブロックを読み出し、
少なくとも二つの前記複数のモジュラー記憶ユニットからリモートに記憶されたデータブロックをリクエストし、
前記リクエストされリモートに記憶されたデータブロックを受信し、
前記リクエストされたデータファイルを戻すように構成され、
前記ファイルロケーションデータ構造は、前記ローカルに記憶されたデータブロックおよび前記リモートに記憶されたデータブロックのロケーションのリストを備え、前記リモートに記憶されたデータブロックが存在する前記複数のモジュラー記憶ユニットのうちの、全てではない、少なくとも一つに存在するモジュラー記憶ユニット。
【請求項２２】
前記データブロックは少なくとも二つの異なるサイズのものである請求項２１記載のモジュラー記憶ユニット。
【請求項２３】
前記データブロックは同一サイズである請求項２１記載のモジュラー記憶ユニット。
【請求項２４】
前記記憶モジュールは、不揮発性メモリ装置および揮発性メモリ装置を備えた請求項２１記載のモジュラー記憶ユニット。
【請求項２５】
前記処理モジュールは、
前記リクエストされローカルに記憶されたデータブロックについて前記揮発性メモリ装置に問い合わせるステップと、
もし、前記リクエストされたデータブロックが見つからなければ、前記リクエストされローカルに記憶されたブロックについて前記不揮発性メモリ装置に問い合わせるステップとにより、
前記ローカルに記憶されたデータブロックを読み出すように更に構成された請求項２４記載のモジュラー記憶ユニット。
【請求項２６】
前記処理モジュールは、前記読み出されたローカルに記憶されたデータブロックを、前記揮発性メモリ装置に記憶するように更に構成された請求項２５記載のモジュラー記憶ユニット。
【請求項２７】
前記処理モジュールは、前記読み出されたローカルに記憶されたデータブロックおよび前記受信されたリモートに記憶されたデータブロックを結合して前記リクエストされたデータファイルを構成するように更に構成された請求項２５記載のモジュラー記憶ユニット。
【請求項２８】
前記処理モジュールは、前記記憶モジュールに記憶するためのデータのブロックを受信するように更に構成された請求項２２記載のモジュラー記憶ユニット。
【請求項２９】
分散型ファイルシステムであって、
相互に通信する複数の記憶ユニットと、
変化する冗長およびパリティ保護パラメータを使用するデータファイルおよびディレクトリであって２以上の複数の記憶ユニットのサブセットに記憶された複数のデータブロックからなる前記データファイルおよび前記ディレクトリについての情報を記憶するためのロケーションデータ構造であって、前記複数のデータブロックが記憶された前記複数の記憶ユニットの２以上のサブセットのうちの、全てではない、少なくとも一つに記憶された前記ロケーションデータ構造とを備え、
前記ロケーションデータ構造は、
前記対応するデータファイル又は前記対応するデータディレクトリについての冗長およびパリティ保護情報を備えるメタデータ部分と、
前記対応するディレクトリの子についてのロケーションデータ構造情報または前記対応するデータファイルの前記データファイルブロックについてのロケーション情報を備えるコンテンツ部分と
を備えた分散型ファイルシステム。
【請求項３０】
前記ロケーションデータ構造の前記メタデータ部分は、少なくとも、ネーム、アドレス、タイプ、サイズ、セキュリティ情報、ミラーリング情報、パリティ情報、データサイズ、ブロックサイズ、およびロケーション情報アドレスのうちの一つを備えた請求項２９記載の分散型ファイルシステム。
【請求項３１】
前記ロケーションデータ構造はディレクトリについての情報を備え、且つ前記ロケーションデータ構造の前記メタデータ部分は、ミラーリングパラメータおよびパリティパラメータを備えた請求項２９記載の分散型ファイルシステム。
【請求項３２】
前記ミラーリングパラメータは、少なくとも、前記ディレクトリの任意の子孫のミラーリングパラメータから決定される請求項３１記載の分散型ファイルシステム。
【請求項３３】
前記ミラーリングパラメータは、少なくとも、前記ディレクトリの任意の子孫の最大ミラーリングと適合(match)する請求項３２記載の分散型ファイルシステム。
【請求項３４】
前記パリティパラメータは、前記ディレクトリの任意の子孫のパリティパラメータから決定される請求項３１記載の分散型ファイルシステム。
【請求項３５】
前記パリティパラメータは、少なくとも、前記ディレクトリの任意の子孫の最大パリティ保護と適合(match)する請求項３４記載の分散型ファイルシステム。
【請求項３６】
前記ロケーションデータ構造の前記コンテンツ部分は、前記ディレクトリの前記子孫に対応するロケーションデータ構造のロケーションを備えた請求項３１記載の分散型ファイルシステム。
【請求項３７】
前記ロケーションデータ構造はデータファイルについての情報を記憶する請求項２９記載の分散型ファイルシステム。
【請求項３８】
前記ロケーションデータ構造の前記コンテンツ部分は、前記データファイルブロックのそれぞれの前記ロケーションを備えた請求項３７記載の分散型ファイルシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明のシステムおよび方法は、概して、分散型ファイル記憶の分野に関し、特に知的分散ファイル管理に関する。
【背景技術】
【０００２】
インターネットの爆発的な成長は、情報が常に交換されアクセスされる新たな領域において先導してきた。この成長に応答して、共有されるデータのサイズが増加している。ユーザは、標準のＨＴＭＬドキュメントの要求にとどまらず、オーディオデータ、ビデオデータ、イメージデータ、およびプログラミングデータに対するアクセスを求めている。従って、大きなデータのセットを収容することができながら、同時にデータに対する高速且つ信頼性のあるアクセスを提供することができるデータ記憶に対する要請がある。
【０００３】
ひとつの回答は、大量のデータを記憶するが、ハイスループットレートを提供することの困難性を有する単一の記憶装置を利用してきた。データ容量が増加するにつれ、データをアクセスするのに要する時間量が同様に増加する。処理速度とパワーは改善されたが、ディスクＩ／Ｏ（入力／出力）動作性能は、特に大きなデータファイルについては、Ｉ／Ｏ動作を非効率的にする同一のレートでは改善されない。
【０００４】
他の回答は、ＳＡＮｓ(Storage Area Network solution)のようなアーキテクチャを用いて、共有ディスクに複数のサーバがアクセスすることを可能にするが、このようなシステムは高価であり、データの完全性を制御しセットアップするための複雑な技術を必要とする。さらに、大量のデータリクエストを取り扱うためには高速のアダプタを必要とする。
【０００５】
従来のアプローチについての一つの問題は、それらが拡張性に制限があることである。従って、データ量が増加するにつれ、システムは、成長することが要求されるが、拡張が高額で著しく分裂的である。
【０００６】
渋滞のアプローチについての他の共通問題は、それらが柔軟性に制限があることである。システムは、所定のエラー訂正制御を使用するためによく構成される。例えば、ＲＡＩＤシステムは、データがどこに記憶されるべき場所または使用されるべき冗長パラメータのタイプを決定することにおいて管理者に柔軟性をほとんど与えないかまたは全く与えない物理ディスクレベルで、データファイルのミラーリング(mirroring)および冗長性(redundancy)を提供するために使用され得る。
【発明の開示】
【課題を解決するための手段】
【０００７】
知的分散型ファイルシステムは、シングルファイルシステムとしてアクセスされるスマート記憶ユニットのセット間でファイルデータの記憶を有利に可能にする。知的分散ファイルシステムは、例えば、ファイルのデータブロックのブロックロケーションおよび装置を含む各ファイルについての詳細な情報を管理し且つ追跡するためのメタデータのデータ構造を有利に利用して、シングルファイルシステム内の冗長性(redundancy)および／または反復(replication)の異なるレベルを許容し、冗長パラメータの変更を容易化し、リアルタイムでデータを移動し且つ反復する。等々。
【０００８】
この要約の目的のため、本発明のいくつかの態様、利点、および新規な特徴が本明細書に記述されている。全てのこのような利点は必ずしも本発明の特定の実施形態に従って達成さるとは限らないことが理解されるべきである。従って、例えば、当業者であれば、本発明は、本明細書で教示または示唆される他の利点を必ずしも達成することなく、本明細書で教示されるような一つの利点または利点のグループを達成する方法で具現または実施されるということを認識するであろう。
【発明を実施するための最良の形態】
【０００９】
本発明の一実施形態および適用例を表すシステムおよび方法は、ここで図面を参照して述べられるであろう。他の実施形態を表す本システムおよび方法の変形例もまた述べられるであろう。
【００１０】
説明のため、いくつかの実施形態は、ウェブホスティングおよびインターネットコンテンツ配信のコンテキストで説明される。本発明者は、本発明がシステムおよび方法が使用される環境のタイプによって制限されず、且つ本システムおよび方法が、例えばインターネット、ワールドワイドウェブ(World Wide Web)、病院用の私設ネットワーク、政府機関用のブロードキャスト、集団経営の内部ネットワーク、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク等々のような他の環境においても使用され得ることを意図する。しかしながら、数値および説明は、環境がインターネットコンテンツ配信およびウェブホスティングの環境であるところの本発明の実施形態に関する。他の環境において、本システムおよび方法が、シングルモジュールとして実施され、および／または他のモジュールその他の同種のものとつないで実施されてもよいことも認識される。さらに、本明細書で述べられる特定の実施は、本発明を例示するためであり、本発明を限定するためではない。本発明の適用範囲は、添付の請求項によって定められる。
【００１１】
これらおよび他の特徴は、ここで上記に要約された図面を参照して述べられるであろう。図面および関連する記載は、実施形態を説明するために提供されるものであって、本発明の範囲を制限するものではない。図面の全体を通して、参照番号は参照される要素間で対応するものを示す。加えて、各参照番号の最初の数字は、概して要素が最初に現れた図を示す。
【００１２】
Ｉ．概要
本発明のシステムおよび方法は、シングルファイルシステムとしてアクセスされるスマート記憶ユニット(smart storage units)のセット間でデータの記憶を可能とする知的分散型ファイルシステムを提供する。知的分散型ファイルシステムは、各ファイルについて詳細なメタデータを追跡(track)し管理(manage)する。メタデータは、例えば、装置およびブロックロケーション情報の双方を含むファイルのデータブロックのロケーション、メタデータ及び／又はデータブロック（もしあれば）の冗長なコピーのロケーション、エラー訂正情報、アクセス情報、ファイルのネーム、ファイルのサイズ、ファイルのタイプ、等々のようなファイルに関する及び／又は上記ファイルを記述する任意のデータを含む。加えて、知的分散型ファイルシステムは、ファイルシステムによって管理される異なるファイル及び／又はデータブロックについて反復及び／又は冗長の異なるレベルを可能にし、システムがアクティブの間に冗長パラメータの変更を容易化し、そしてメタデータのリアルタイムな反復及び／又は移動を可能にする。さらに、各スマート記憶ユニットは、スマート記憶ユニットからファイルのデータを見つけ出し且つ収集することによりファイルリクエストに応じる。
【００１３】
知的分散型ファイルシステムは、特にライト(WRITE)リクエストの数に比例して多くのリード(READ)リクエストが存在する状況においてデータへのアクセスを有利に提供する。これは、一貫性を確保するための個々のスマート記憶ユニットに関するジャーナル処理と同様に、スマート記憶ユニットの知的グループを連続追跡することの追加の複雑さのためである。さらに、知的分散型ファイルシステムは、大きなデータブロックに対するリクエストが一般的であるブロックトランザクション(block transaction)を有利に処理する。
【００１４】
いくつかの実施形態の一つの便益は、ファイルおよびディレクトリについてのメタデータが知的分散型ファイルシステムによって管理され且つアクセスされることである。メタデータは、同様にシステムに関するパリティまたは他のエラー訂正情報がどこに記憶されているかを示すのみならず、ディレクトリ又はファイルがどこに位置しているか、コンテンツデータがどこに記憶されているか、メタデータ及び／又はコンテンツデータのミラードコピー(mirrored copies)がどこに記憶されているかを示すものであってもよい。データロケーション情報は、例えば、装置およびブロックロケーション情報を用いて記憶される。従って、知的分散型ファイルシステムは、双方がスマート記憶ユニットのセット間に分散され且つ記憶されるメタデータを用いて、リクエストされたコンテンツデータを探し出し且つ読み出す。加えて、知的分散型ファイルシステムはメタデータへのアクセスを備えるので、知的分散型ファイルシステムは、スマート記憶ユニットを混乱させることなく、リクエストに応じてデータを移動し、反復し、及び／又は変更し、且つデータが記憶されるべき場所を選択するために使用できる。
【００１５】
いくつかの実施形態の他の便益は、各ファイルについてのデータが多くのスマート記憶ユニットにわたって記憶され、且つタイムリーにアクセスされることである。各ファイルについてのデータブロックは、データアクセスタイムは減少されるようなスマート記憶ユニットのサブセットの間に分散されてもよい。さらに、異なるファイルは、スマート記憶ユニットの異なるセットにわたるのみならず、スマート記憶ユニットの異なる数にわたって分散されてもよい。このアーキテクチャは、知的分散型ファイルシステムが、有効な記憶容量、ＣＰＵ稼働率、および各スマート記憶ユニットのネットワーク稼働率のみならず、ファイルのサイズ、重要度、予期されるアクセスレートのような要因に基づき、データブロックを知的に記憶することを可能にする。
【００１６】
いくつかの実施形態の追加の便益は、スマート記憶ユニット間に記憶された異なるデータブロック又はファイルが異なるタイプの保護を備えるようなファイルベースまたはデータブロックに関し、エラー訂正、冗長性、およびミラーリングのような種々の保護スキームを提供するために本システムおよび方法が使用されてもよいことである。例えば、あるディレクトリまたはファイルはミラーされてもよく、他のものは、種々のエラーまたはロス訂正スキームを用いてエラー及び／又はロス訂正データで保護されてもよく、そして重要度の低い他のものは何ら保護スキームを使用しなくてもよい。
【００１７】
いくつかの実施形態の更なる便益は、本システムおよび方法が、現行のデータリクエストを中断または割り込みすることなく、リアルタイムなスマート記憶ユニットの付加、削除、及び／又は修正を可能にすることである。従って、より多くの記憶が要求されるほど、追加のスマート記憶ユニットが、ファイルリクエストに割り込むことなく且つ既存のスマート記憶ユニットをオフラインにすることなく、リアルタイムで知的分散型ファイルシステムに組み込まれ且つスマート記憶ユニットのセットに付け加えられてもよい。既存のスマート記憶ユニットは、既存または新たなファイルが現在新たなスマート記憶ユニットを含むスマート記憶ユニットのセットにわたって知的分散型ファイルシステムによって分散されているときに、ファイルについてのリクエストを処理してもよい。
【００１８】
いくつかの実施形態の他の便益は、本システムおよび方法が、一つまたはそれ以上のスマート記憶ユニット上のデータブロックを反復し、ゆえに任意の個々のデータブロックについて多数のアクセスポイントを生成することにより、それらのブロックの記憶に対してリアルタイムの修正を実施してもよいことである。この反復は、頻繁なアクセスパターンが観測されるファイルのグループまたはファイルのための個々のスマート記憶ユニットに対するＣＰＵの稼働率およびネットワーク資源の必要条件を低減するのに役立つ。これらのアクセスは、スマート記憶ユニットによってモニタされ、そして知的分散型ファイルシステムは、知的分散型ファイルシステムがまだ動作中にこのようなデータ反復をさせるための柔軟性をスマート記憶ユニットに柔軟性を与える。
【００１９】
ＩＩ．動作例
説明のため、ここで知的分散型ファイルシステムが動作において使用されるシナリオの例を検討する。このシナリオの例において、知的分散型ファイルシステムは、インターネットウェブサイトを介して映画ダウンロードを提供するカンパニーによって使用される。このカンパニーは、ウェブサイトを介して顧客によってアクセスされる顧客情報、広告、映画予告のみならず、ダウンロード可能な映画のコピーを記憶し且つ管理するために知的分散型ファイルシステムを使用してもよい。データは、種々のレベルの保護で記憶され且つ高速アクセス用の多数のスマート記憶ユニットにわたって記憶されてもよい。
【００２０】
例えば、カンパニーは、電子メールに対する高速なアクセスを提供するために、知的分散型ファイルシステムにおいて多くのスマート記憶ユニットにわたって顧客概観電子メール(customer survey emails)を記憶することを欲する。しかしながら、このカンパニーは、全ての電子メールのバックアップテープを保持し、そして顧客概観の迅速な回復を可能にすることは重要ではないと思うかもしれない。カンパニーは、顧客概観電子メールに関してエラー訂正またはミラーリング保護を使用しないように知的分散型ファイルシステムに指示するかもしれない。従って、一つまたはそれ以上のスマート記憶ユニットがアクセス不能になると、コンパニーは、それらのスマート記憶ユニット上の顧客概観電子メールへのアクセスが、その電子メールがバックアップテープからリストアされ得るまで遅延されることが容認できると思うかもしれない。
【００２１】
広告については、カンパニーは、もし一つまたはそれ以上のスマート記憶ユニットが故障すると、知的分散型ファイルシステムが広告表示に割り込むことなくデータを回復できるというような高エラー訂正パラメータを使用することを知的分散型ファイルシステムに指示してもよい。例えば、カンパニーは、特定ファイルにどの程度の保護が与えられるべきかを決定することにおいて支援するための種々の耐故障性計量(fault tolerance measurement)に頼る。重要な情報について、カンパニーは、Ｘの耐故障性のレベルを確保することを欲し、そしてさほど重要ではない情報については、カンパニーはＹの耐故障性のレベルを確保することを欲する。ここでＸ＞Ｙである。耐故障性に加え、または耐故障性に代えて、他の計量が使用されてもよく、且つ耐故障性が信頼性の一つの計量を示すために使用されることは認識されている。従って、カンパニーは、広告が一つまたはそれ以上のスマート記憶ユニットが故障したとしても、信頼性のある基準で利用可能であることをその広告主に請け合うことができる。
【００２２】
トップ映画のダウンロードについて、カンパニーは、より多くの顧客がデータにアクセスし、且つ、もし一つまたはそれ以上のスマート記憶ユニットが故障すれば、失われたデータが再生成され又は他の場所から読み出されることを保証するために、映画の多くのコピーを自動的に記憶するように知的分散型ファイルシステムを有利にセットアップしてもよい。さらに、もしリクエストの数が増加し、及び／又は、もし一つまたはそれ以上のスマート記憶ユニットがそのスマート記憶ユニットに存在するデータに対するリクエストで殺到するようになり始めれば、トップ映画のダウンロードの追加のコピーが生成されてスマート記憶ユニット間に記憶されてもよい。
【００２３】
カンパニーは、人気のない他の映画を提供することを選択し、そして低い要求に応じて少ないコピーを記憶することを知的分散型ファイルシステムに指示してもよい。さらに、“トップのダウンロード映画”の人気が少なくくなるにつれ、カンパニーは、その映画が記憶されたスマート記憶ユニットから映画の余分なコピーを削除し、そして“人気がなくなった”映画を低性能のスマート記憶ユニット（例えば、利用可能なディスクスペースが少ないスマート記憶ユニット）に移動するように知的分散型ファイルシステム有利にセットアップしてもよい。知的分散型ファイルシステムは、スマート記憶ユニットを用いてこれらのタスクを自動的に管理する。
【００２４】
加えて、カンパニーがより多くの映画を入手すれば、カンパニーは、知的分散型ファイルシステムに追加のスマート記憶ユニットを付け足してもよい。カンパニーは、それから、より多くの映画を記憶するため、既存の映画のより多くのコピーを記憶するため、及び／又は、応答時間を改善するために既存の映画データを分散させるため、新たなスマート記憶ユニットを使用してもよい。知的分散型ファイルシステムが多数のスマート記憶ユニットのセット間でデータを記憶する管理し且つ記憶するにもかかわらず、知的分散型ファイルシステムがシングルファイルシステムとして見えるように、追加のスマート記憶ユニットが知的分散型ファイルシステムに組み込まれる。
【００２５】
この例では、知的分散型ファイルシステムは、トップ映画ダウンロードへの信頼性があり且つ高速なアクセス、人気の少ない映画への高速なアクセス、そして顧客概観電子メールを提供するための能力をカンパニーに提供する。各ファイルについて、カンパニーは、エラー及び／又はロス訂正パラメータを設定し、そしてどれ程多くのファイルの追加コピーが記憶されるべきかを選択してもよい。或る状況において、カンパニーは、手動で、どれ程多くのデータのコピーが記憶されるべきかを選択し、そしてそのデータがどこに記憶されるかを決定してもよい。他の状況においては、カンパニーは、どれ程多くのデータのコピーが記憶されるべきか、使用されるべきエラー及び／又はロス訂正スキーム（もし、あれば）、及び／又はデータがどこに記憶されるべきかを選択するために知的分散型ファイルシステムの特徴に頼ってもよい。従って、カンパニーは、記憶スペースを効率的に使用して、ユーザに対してより良く応答することができる。記憶スペースは、まばらなリクエストファイルについても浪費されず、そしてエラー訂正情報は生成されず、重要でないファイルのために記憶される。
【００２６】
上述の例はダウンロードのための映画を提供するカンパニーを含むが、この例は、知的分散型ファイルシステムの一実施形態の特徴を示すためのみに使用されることが認識される。さらに、知的分散型ファイルシステムは、他の環境においても使用でき、且つ、例えば、サウンドファイル、オーディオファイル、グラフィックファイル、マルチメディアファイル、デジタルフォトグラフ、実行可能ファイル、等々を含むデータの組み合わせ及び／又は他のタイプのデータと共に使用できる。
【００２７】
ＩＩＩ．知的分散型ファイルシステム
図１は、リモートファイルアクセスを提供するネットワークサーバ１２０と通信する知的分散型ファイルシステム１１０の一実施形態を図解する。知的分散型ファイルシステム１１０は、例えばＮＦＳまたはＣＩＦＳのような種々のプロトコルを用いてネットワークサーバ１２０と通信してもよい。ユーザ１３０は、知的分散型ファイルシステム１１０によって管理されるファイルをリクエストするために、インターネット１４５のような通信媒体１４０を介してネットワークサーバ１２０と対話する。代表的な知的分散型ファイルシステム１１０は、スマート記憶ユニット１１４のセットおよびネットワークサーバ１２０と通信するスイッチコンポーネント１２５を利用する。知的分散型ファイルシステム１１０は、個々のファイルのデータブロックが多数のスマート記憶ユニット１１４に散らばることを可能にする。データが単一の装置に記憶されている場合よりも、このデータへのアクセスがより高いスループットを提供するように、データが記憶される。加えて、知的分散型ファイルシステム１１０は、種々の保護スキームを用いて記憶された種々のデータファイルを記憶するために使用されてもよい。
【００２８】
代表的な知的分散型ファイルシステム１１０は、スマート記憶ユニット１１４のセット間でデータを記憶する。スマート記憶ユニット１１４についての更に詳細な説明については、“スマート記憶ユニット”と題された後述のセクションを参照されたい。
【００２９】
代表的な知的分散型ファイルシステムは、リクエストされたデータのタイプを処理することができるアプリケーションサーバにリクエストを方向づける負荷バランシングスイッチ(load balancing switch)のようなスイッチコンポーネント１２５を利用する。入ってくるリクエストは、データの完全性を確保するための遅延を最小化するために高速技術を用いて適切なアプリケーションサーバに転送される。
【００３０】
例えば、標準のイーサネット（登録商標）スイッチまたは負荷バランシングスイッチのみならず、１０００Ｂａｓｅ−Ｔ（銅）ギガビット負荷バランシングイーサネット（登録商標）スイッチ、Ｅｘｔｒｅｍｅ  Ｎｅｔｗｏｒｋ  Ｓｕｍｍｉｔ  ７Ｉ、Ｆｏｕｎｄｒｙ  Ｆａｓｔ  Ｉｒｏｎ  ＩＩ、Ｎｏｒｔｅｌ  Ｎｅｔｗｏｒｋｓ  Ａｌｔｅｒｏｎ  ＡＣＥｓｗｉｔｃｈ  １８０、Ｆ５  Ｂｉｇ−Ｉｐのような、種々の負荷バランシングスイッチ１２５が使用できることが認識される。知的分散型ファイルシステムは、例えば“ｊｕｍｂｏ”イーサネット（登録商標）フレームのような大きなフレームをサポートするスイッチを利用する。加えて、負荷バランシングスイッチ１２５は、他の市販品及び／又は独自仕様の製品のみならず、Ｆｏｕｎｄｒｙ  ＮｅｔｗｏｒｋのＳｅｒｖｅｒＩｒｏｎ  ｓｗｉｔｃｈｅ、ＡｓａｎｔｅのＩｎｓｔｒａＳｗｉｔｃｈ  ６２００  ｓｗｉｔｃｈｓ、ＡｓａｎｔｅのＨｏｔＳｔａｃｋ、ＣｉｓｃｏのＣａｔａｌｙｓｔ  ｓｗｉｔｃｈｓを用いて実施されてもよい。しかしながら、当業者であれば、広範囲のスイッチコンポーネント１２５が使用でき、または他の技術が使用できることを認識するであろう。さらに、スイッチコンポーネント１２５は、種々のネットワークフレームサイズを伝送するように構成されてもよいことが認識される。
【００３１】
重要度の高いファイルは、一つまたはそれ以上のスマート記憶ユニットへのアクセスを妨げる、ディスク、マザーボード、ＣＰＵ、オペレーティングシステム、または他のハードウェアまたはソフトウェアの故障が生じた場合に高い回復レートをデータに提供する高度のエラー訂正パラメータで記憶されてもよい。もし、何らかのデータが欠落し又は失われれば、スマート記憶ユニット１１４は、他の場所からデータを得るため、またはデータを再生成するために、メタデータにおけるミラーリング情報または冗長情報を使用してもよい。高度に需要があるファイルは、一様に高いスループットを提供するために追加のスマート記憶ユニット１１４にわたってリアルタイムでミラーされてもよい。
【００３２】
本知的分散型ファイルシステム１１０の一実施形態において、メタデータのデータ構造は、そのメタデータのデータ構造に対応するディレクトリの任意の子孫を含んでそれが参照するデータと少なくとも同じ保護を備える。メタデータのデータ構造におけるデータの紛失(loss)は、そのメタデータのデータ構造なしでデータを取得することは困難であるので、知的分散型ファイルシステムを阻害する。知的分散型ファイルシステム１１０において、メタデータのデータ構造の代わりのコピーは、必要な保護を提供するのに要するのと同じくらいの多くのロケーションにおいてミラーされてもよい。従って、パリティ保護を備えるファイルは、少なくとも同一またはより大きなパリティ保護で記憶され、そして２回ミラーされたファイルは、少なくとも２箇所のロケーションでミラーされたそのメタデータ構造を備えてもよい。
【００３３】
図１は、知的分散型ファイルシステム１１０の一実施形態を図解するが、他の実施形態が使用されてもよいことが認識される。例えば、アプリケーションサーバのような追加のサーバが、スイッチコンポーネント１２５と通信してもよい。これらのアプリケーションサーバは、例えば、オーディオストリームサーバ、ビデオストリームサーバ、イメージプロセッシングサーバ、データベースサーバ、等々を含んでもよい。さらに、スイッチコンポーネント１２５と通信する、ワークステーションのような追加の装置が存在してもよい。加えて、図１は、４つのスマート記憶ユニット１１４と共に動作する知的分散型ファイルシステム１１０を図解するが、その知的分散型ファイルシステム１１０は、異なる数のスマート記憶ユニット１１４と動作してもよい。
【００３４】
用語“リモート”は、装置、コンポーネント、及び／又はローカルに記憶されないモジュールをも含み、それはローカルバスを介してアクセスできないことが認識される。従って、リモート装置は、物理的に同一のルームに位置されると共にスイッチまたはローカルエリアネットワークを介して接続された装置を含んでもよい。他の状況において、リモート装置は、また、例えば異なるロケーション、カントリー、等々の地理的に離れた地域に位置されてもよい。
【００３５】
また、種々のタイプのデータが知的分散型ファイルシステム１１０を用いて記憶されてもよいことが認識される。例えば、知的分散型ファイルシステム１１０は、例えば、ビデオオンデマンド、オンラインミュージックシステム、ウェブサイトミラーリング、大きなデータベース、大きなグラフィックスファイル、ＣＡＤ／ＣＡＭデザイン、ソフトウェアアップデート、企業プレゼンテーション、保険金請求ファイル、医療用画像ファイル、企業ドキュメント記憶、等々のような、大きなファイルアプリケーションで使用されてもよい。
【００３６】
図２は、ウェブサイトユーザ１３０がオンデマンドデジタルビデオを見るためにリクエストをサブミットした環境の例を図解する。イベントＡにおいてユーザ１３０は、インターネット１４５を介して、映画のコピー、mymovie.movieを見ることを要求するウェブサイトにリクエストを送信する。このリクエストは、ウェブサイトのサーバ１２０によって受信され、そしてサーバ１２０は、ファイルが、/movies/comedy/mymovie.movieに位置されていると決定する。イベントＢにおいて、知的分散型ファイルシステム１１０のスイッチコンポーネント１２５は、知的分散型ファイルシステム１１０に接続するためのリクエストを見つけ、そして、標準の負荷バランシング技術を用いて、スマート記憶ユニット０のような利用可能なスマート記憶ユニット１１４にこのリクエストを転送する。イベントＣにおいて、スマート記憶ユニット０は、ファイル/DFSR/movies/comedy/mymovie.movieについてのリクエストを受信し、そして、サブディレクトリmoviesについてのメタデータのデータ構造がスマート記憶ユニット２で記憶されていることを、そのルートメタデータのデータ構造（ルートディレクトリ/DFSR）から決定する。イベントＤにおいて、スマート記憶ユニット０は、サブディレクトリcomedyについてメタデータのデータ構造のロケーションを要求するスマート記憶ユニット２にリクエストを送信する。イベントＧにおいて、スマート記憶ユニット０は、ファイルmymovie.movieについてのメタデータのデータ構造がスマート記憶ユニット０で記憶されている情報を受信する。スマート記憶ユニット０は、それから、ローカル記憶からファイルmymovie.movieについてのメタデータのデータ構造を取得する。このメタデータのデータ構造から、スマート記憶ユニット０は、ファイルにおけるデータの各ブロックのロケーションを記憶するmymovie.movieについてのデータロケーションテーブルを取得する。スマート記憶ユニット０は、それから、データロケーションテーブル情報を使用して、ローカルに記憶されたブロックを取得し且つ他のスマート記憶ユニットで記憶されたデータについてのリクエストを送信することを開始する。
【００３７】
ファイルのデータまたはデータの一部が取得された後に、そのファイルデータは、リクエストするサーバ１２０に送信されて、リクエストするユーザ１３０に転送される。一つの例において、ファイルデータは、データがいつどのようにユーザ１３０に送信されるかを統制するビデオストリーミングサーバに送られてもよい。いくつかの実施形態において、リクエストの待ち時間(latency)を低減するためにリクエストされたときにより多くのデータを取得する先見読み出し技術(read ahead techniques)を利用することは有利であろうことが認識される。
【００３８】
ＩＶ．知的ファイルシステム構造
表１は、物理的記憶装置をアクセスするためにファイルリクエストが処理されるファイルシステムレイヤのセット例の一実施形態を例示する。代表的なファイルシステムレイヤは、ユーザレイヤ、バーチャルファイルシステムレイヤ、ローカルファイルシステムレイヤ、ローカルファイル記憶レイヤ、および記憶装置レイヤを含む。
【００３９】
【表１】
0004504677.tif 000002
【００４０】
ファイルリクエストの一つのタイプにおいて、リクエストは、例えば、マイクロソフトウィンドウズ（登録商標）ファイルシェアリングサーバプロトコルを実装するユニックス上で使用されるＳＭＢＤ、または、ＦＴＰＤＤ、ＨＴＴＰ（アパッチウェブサーバ）のような、ファイルシェアリングのためのユーザレベルのプロトコルアプリケーションを介して受信される。ユーザレベルプロトコルアプリケーションは、例えば、libc,Ｃランタイムライブラリファンクションコールに対してファンクションコールさせることによるような、カーネルレベルオープン、リード、シーク、ライト、またはクローズシステムコールを実施する。
【００４１】
システムコールは、バーチャルファイルシステム（“ＶＦＳ”）に受け渡され、それはバッファキャッシュ(buffer cache)を保持する。バッファキャッシュは、例えば、下層のファイルシステムレイヤから受信されたメタデータのデータ構造またはデータを記憶するために使用されるキャッシュであって使用頻度が最も低いキャッシュ（“ＬＲＵ”）であってもよい。
【００４２】
次のレイヤは、ファイルシステムの階層的ネーミングシステムを保持するローカルファイルシステムレイヤである。ローカルファイルシステムレイヤは、メタデータのデータ構造検索および管理を処理する。例えば、ユニックスベースのファイルシステムのような或るシステムにおいては、メタデータのデータ構造は、ファイルアクセス許可、データブロックロケーション、およびリファレンスカウントについての情報を含むファイル抽象化(file abstraction)である。ファイルがそのネームによって一旦開かれると、他のファイルオペレーションは、特定のファイルについてメタデータ構造を確認するユニークな識別子によってファイルを参照する。このアプローチの便益は、単一ファイルが、多くの異なるネームを有し、単一ファイルが異なるパスを介してアクセスされ、そして新たなファイルが、例えば“ｍｖ”コマンドのような標準のユーザレベルのユーティリティによって実際のファイルデータを上書きすることなく、ＶＦＳネームスペースの古いファイルの上にコピーされ得ることである。これらの便益は、コンテンツ配信およびウェブホスティングのような環境においてはなおさら有益である。なぜなら、コンテンツは、現行のコンテンツの供給を混乱させることなく、適切にアップデートされ得るからである。メタデータのデータ構造内のリファレンスカウントは、システムが、一旦全てのオープンファイルハンドルが閉じられれば、データブロックを無効にすることのみを可能にする。
【００４３】
第４レイヤは、“バッファリクエストからブロックリクエスト”の翻訳(translation)を処理するローカルファイルストアレイヤ(Local File Store layer)であり、データバッファは管理(management)をリクエストする。例えば、ローカルファイルストアレイヤは、ブロック割り当てスキーム(block allocation schemes)を使用して、リーディングについての検索スキームをブロックするのみならず、ライトおよびリードについてのスループットを改善し且つ最小化する。
【００４４】
最後のレイヤは、ファイルシステムによって使用されるディスクハードウェアの特定のもののためのデバイスドライバを努める記憶装置レイヤである。例えば、もし物理的な記憶装置がＡＴＡディスクであれば、記憶装置レイヤはＡＴＡディスクドライバである。
【００４５】
Ｖ．スマート記憶ユニット
一実施形態において、スマート記憶ユニット１１４は、プラグアンドプレイの、高密度な、ラックに実装可能な装置であり、それは、高スループットデータ配信のために最適化されている。スマート記憶ユニットは、単一のバーチャルファイルシステムを提供するために他の種々のスマート記憶ユニットと通信するように構成されている。より多くの記憶スペースが必要とされるほど、または、もし一つまたはそれ以上のスマート記憶ユニットが故障すれば、システム全体をダウンさせる必要なく、またはサービスの中断を生じることなく、追加のスマート記憶ユニットがインストールされ得る。
【００４６】
本明細書で用いられるように、モジュールなる用語は、ハードウェアまたはファームウェアで具現されたロジックを指し、またはソフトウェア命令の集まりを指し、あるいは入力点(entry point)および出力点(exit point)を備え、例えば、ＣまたはＣ＋＋のようなプログラミング言語で記述されている。ソフトウェアモジュールは、実行可能ファイルに準拠しまたはリンクされ、動的リンクライブラリにインストールされ、またはＢＡＳＩＣ，ＰｅｒｌまたはＰｙｔｈｏｎのようなインタプリタ型のプログラミング言語で記述されてもよい。ソフトウェアモジュールは、他のモジュールまたはそれら自体からコール可能であってもよく、及び／又は検出されたイベントまたは割り込みに応答して呼び出されても良いことが評価されるであろう。ソフトウェア命令は、ＥＰＲＯＭのようなファームウェアに組み入れられても良い。ハードウェアモジュールは、ゲートおよびフリップフロップのような結合されたロジックユニットから構成されてもよく、及び／又はプログラマブルゲートアレイまたはプロセッサのようなプログラマブルユニットから構成されてもよい。モジュールは、本明細書では、好ましくは、ソフトウェアのジュールとして実施されるが、ハードウェアまたはファームウェアで表現されてもよい。
【００４７】
図３は、管理モジュール３２０、処理モジュール３３０、キャッシュ３４０、スタック３５０、および記憶装置３６０を備えるスマート記憶ユニット１１４の一実施形態を図解する。代表的なスマート記憶ユニット１１４は、図１に図解されるように送信および受信するためにスイッチコンポーネント１２５と通信するように構成されてもよい。
【００４８】
Ａ．管理モジュール
一実施形態において、スマート記憶ユニットは、例えば、インストール、パラメータ設定、知的分散型ファイルシステムのモニタリング、知的分散型ファイルシステム１１０上で発生するイベントのロギング(logging)、およびアップグレードのような管理タスクを実施するための管理モジュール３２０を備える。
【００４９】
Ｂ．処理モジュール
代表的な処理モジュール３３０は、データファイルに対するリクエストを受信し、上記リクエストされたデータについてのローカル(local)及び／又はリモート(remote)で記憶されたメタデータを読み出し、且つ上記リクエストされたデータファイルの上記ローカル及び／又はリモートで記憶されたデータブロックを読み出すように構成されてもよい。加えて、処理モジュール３３０は、また、一つまたはそれ以上のリクエストされたデータブロックが壊れ又は失われるイベントにおいてデータ回復(data recovery)およびエラー訂正を実施する。
【００５０】
一実施形態において、処理モジュール３３０は、ファイルリクエストに応答する５つのモジュール、ブロック割り当て管理モジュール３３１、ブロックキャッシュモジュール３３３、ローカルブロック管理モジュール３３５、リモートブロック管理モジュール３３７およびブロック装置モジュール３３９を備える。
【００５１】
１．ブロック割り当て管理モジュール
ブロック割り当て管理モジュール３３１は、ブロックをどこに割り当てるかを決定し、リードリクエストに応答してそのブロックの場所を見つけ、そして装置故障の復旧を実施する。そのブロックを割り付けるべき場所についての情報は、デフォルトパラメータとして設定されたポリシー(policy)、グラフィカルユーザインターフェイスまたはシェルインターフェイスシステム管理者によって設定されたポリシー、またはこれらの組み合わせによって決定されてもよい。一実施形態において、ブロック割り当て管理３３１は、ローカルファイルシステムレイヤに駐在し、そしてＴＣＰ／ＩＰおよびイーサネット（登録商標）のような、及び／又はバークレイソフトウェアデザインユニバーサルファイルシステム（“ＢＳＤ ＵＦＳ”）の代わりに、標準のネットワーキングソフトウェアレイヤとともに動作する。
代表的なブロック割り当て管理３３１は、３つのサブモジュールと４つの故障回復モジュールを備える。
【００５２】
ａ．ブロックリクエスト翻訳モジュール
ブロックリクエスト翻訳モジュールは、入り来るリードリクエストを受信し、ネーム検索(name lookup)を実施し、適切な装置を見つけ出し、そしてその装置から出を取り出して、そのリクエストをかなえる。もし、データが直接的に利用可能であれば、ブロックリクエスト翻訳モジュールは、データのブロックがローカル記憶装置または他のスマート記憶ユニットの記憶装置に記憶されているかどうかにより、ローカルブロック管理モジュールまたはリモートブロック管理モジュールに送信する。
【００５３】
一実施形態において、ブロックリクエスト翻訳モジュールは、“知的分散型ファイルシステム処理−ネーム検索の処理”と題されたセクションにおいて後述されるネーム検索処理を備える。
【００５４】
ブロックリクエスト翻訳モジュールは、また、装置故障に応答する。例えば、もし装置がダウンすると、ブロックリクエスト翻訳モジュールは、例えばパリティ情報を用いて、データを再構成するために使用されるローカルおよびリモートデータブロックをリクエストしてもよい。従って、そのデータは、たとえリードが実施されなくても、発生されてもよい。加えて、ブロックリクエスト翻訳モジュールは、故障回復モジュールが、パリティまたは他のエラー若しくはロス訂正データを用いてデータを再生成し、そして知的分散型ファイルシステムにおける自由スペースにわたってロス訂正データを再分散化(re-stripe)するように、故障回復モジュールと通信してもよい。他の実施形態において、ブロックリクエスト翻訳モジュールは、壊れた(corrupt)又は失われた(missing)データのコピーを一掃してもよい。
【００５５】
ｂ．フォワード割り当てモジュール
フォワード割り当てモジュールは、例えば冗長性、スペース、および性能のようなファクタに基づき、ライトリクエストについてどの装置のブロックが使用されるべきかを決定する。これらのパラメータは、システム管理者によって設定され、知的分散型ファイルシステム１１０に組み入れられた情報から導出され、知的分散型ファイルシステム１１０にロジックとして組み入れられてもよき、またはその組み合わせであってもよい。フォワード割り当てモジュール１１０は、知的分散型ファイルシステムを使用する他のスマート記憶ユニットから統計データ(statistics)を受信し、そしてそれらの統計データを、新たに入ってくるデータを置くのにどこが最良のロケーションであるかを決定するために使用する。統計データは、例えば、ＣＰＵ稼働率、ネットワーク稼働率、およびディスク稼働率の計量(measurement)を含んで集められる。
【００５６】
フォワード割り当てモジュールは、また、リモートスマート記憶ユニットの応答時間に基づきリモート風呂管理モジュールから待ち時間(latency)を受信する。もし、装置間の待ち時間は、他のスマート記憶ユニットに比較してハイレベルに達すれば、割り当てスキームは、できれば、冗長性の設定に基づき、遅いスマート記憶ユニットを十分に活用しない他のスマート記憶ユニットに有利に働くように調節されてもよい。一つの有利な例において、知的分散型ファイルシステムは、データのブロックを一つのスマート記憶ユニットから他のスマート記憶ユニットに移動させ、その結果、対応するメタデータ構造をアップデートする。待ち時間状況は、ロギングシステム(logging system)を通して記録され、そしてシステム管理者に報告される。遅いリンク状況は、例えば、悪いネットワークカード、間違った双方向の流通(incorrect duplex negotiation)、または比較的頻繁にリードまたはライトされる装置データである。
【００５７】
データを記憶する場所を決定するために種々の方策が用いられる。これらの方策は、システムの管理者によって設定されたパラメータとの整合性、選択された冗長性レベルの合致、及び／又は性能の改善のような、システムの目標値によって調整されてもよい。以下は、データを記憶するためにフォワード割り当てモジュールによって採用される少しばかりの方策例を提供する。多種多様の方策が、以下に述べられるものに加え、またはそれらと共に使用される。
【００５８】
フォワード割り当てモジュールは、複数のスマート記憶ユニットにわたるストライピングデータについて割り当てスキームを備えてもよい。ストライピングデータは、代表的にはハイエンドのＲＡＩＤ記憶装置で使用される共通技術であるが、マルチプルディスクと共にシングルユーザのワークステーションマシンにおいて採用されてもよい。ストライピングデータは、単に、ファイルのデータの異なる部分が、異なる記憶装置またはディスク上に存続(live)及び／又は記憶(store)されることを意味する。ストライピングデータの利点は、リードリクエストが複数のディスク上に位置されたブロックにまたがるとき、各ディスクはデータ読み出しの総スループットに関与することである。一般のシステムでは、データのストライピングは、ソフトウェア装置レイヤで行われる。即ち、ファイルシステムは、データのストライピングに関する情報を持たない。ファイルシステムの支配下にあるソフトウェアレイヤのみがこの構造を理解する。ハードウェアのある特殊なものでは、このストライピングは、実際のハードウェアレイヤでソフトウェア装置レイヤの下でも行われる。知的分散型ファイルシステム１１０、ファイルシステム自体がデータのストライピングを処理する。この実施は、より大きな柔軟性をストライピング構成に提供する。例として、代表的なＲＡＩＤ技術は、全てのディスクが同じサイズでなければならず、且つ同じ性能特性を有していなければならないという制限がある。これらの制約は、異なる装置に一様に分散されることを保証するために必要である。ＲＡＩＤについての更に詳細な説明については、「“The RAID book”, Paul Massiglia, 第６版(1997)を参照されたい。それは、引用することによりこの明細書に組み込まれる。
【００５９】
知的分散型ファイルシステム１１０について、異なるディスクおよびディスクサイズは、種々のスマート記憶ユニット１１４で使用されてもよく、そしてファイルストライピングに関与する。フォワード割り当てモジュールは、ディスク装置情報についてルートメタデータのデータ構造において検索し、そして性能メトリックまたはプリセットルールを用いてファイルデータが分散されるべきスマート記憶ユニットの数を計算する。フォワード割り当てモジュールは、それから、ファイルのデータブロックをスマート記憶ユニットのセットに割り当てる。
【００６０】
フォワード割り当てモジュールは、また、パリティまたは他のエラー若しくはロス訂正保護のために割り当てスキーム(allocation scheme)を備えてもよい。ほとんどのＲＡＩＤシステムにおいては、ファイルストライピングが使用されるとき、パリティ保護は、また、一つを除いて全てのディスクがデータ記憶のために用いられるように使用される。最後のディスクは、純粋にパリティ情報のために使用される。このパリティ情報は、代表的には、全てのデータディスクにわたってデータの各ブロックのビット単位のｏｒ（“ＸＯＲ”）をとることにより計算される。このパリティ情報は、ディスク故障が発生したときにデータ回復を実施するために使用される。失われたデータは、残りのディスクのデータブロックおよびパリティ情報のビット単位のＸＯＲをとることから再計算される。代表的なＲＡＩＤシステムにおいて、データは、失われたデータを再構築するために交換ディスクがアレイに挿入されるまでは回復できない。
【００６１】
知的分散型ファイルシステム１１０に関し、失われたデータは、再計算され、そして残りのスマート記憶ユニットの他の部分上の自由スペースに再書込みされる。なぜなら、パリティ保護は、ソフトウェア装置レイヤの代わりにファイルシステムレイヤで行われるからである。もし、データを再書込みするための十分な自由スペースが残されていなければ、パリティデータは、再計算されたデータで上書きされてもよく、そして冗長性が元のレベルよりも下に落ちたという事実が記録され、及び／又はシステム管理者に報告されてもよい。
【００６２】
フォワード割り当てモジュールは、また、データのミラーリングのための割り当てスキームを備え、それは、異なるスマート記憶ユニット上で利用可能なデータの複数のコピーを作成している。フォワード割り当てモジュールは、記憶スペース、ネットワーク稼働率、及び／又はＣＰＵ稼働率の観点から最も使用されないスマート記憶ユニットを用いてスマート記憶ユニットにわたってデータのブロックのロケーションを負荷バランス(load balance)するために割り当てスキームを使用してもよい。ミラーリングは、更なる性能および更なる耐故障性を提供する。もし、ミラーリングがコンテンツの或るものについてリクエストされると、フォワード割り当てモジュールは、ミラーされたデータのみならず、元のデータについてもスペースを割り当てる。もし、１より大きな耐故障性のレベルがリクエストされると、フォワード割り当ては、耐故障性カウントにより、スマート記憶ユニット、またはスマート記憶ユニットのサブセットをロジカルに分割し、そして分散化(striped)されたデータのミラーを作成する。例えば、もし、１０個のスマート記憶ユニット１１４が知的分散型ファイルシステム１１０に存在し，且つ２の耐故障性がリクエストされると、フォワード割り当て器は、知的分散型ファイルシステムを、それぞれが５個のスマート記憶ユニットの二つのセクションに分割し、各セクションにおいて４個のスマート記憶ユニットにわたってデータを分散化(stripe)し、そしてパリティディスクとして各セクションから５個目のスマート記憶ユニットを使用する。スマート記憶ユニットのこの分割は、アレイミラー分割(array mirror split)と称される。
【００６３】
ｃ．故障回復モジュール
故障回復モジュールは、装置故障のためにもはや利用できないデータを回復するために知的分散型ファイルシステム１１０をリアルタイムで再構成する。故障回復モジュールは、性能を維持しながらサービスを中断することなく再構成を実施し、そして短時間でデータを所望の冗長レベルに戻す。
【００６４】
上述したように、リモートブロック管理モジュール３３７は、故障を検出し、そしてこのような故障の通知を故障回復モジュールに受け渡す。初期の故障については、故障回復モジュールは、システム管理者によってリクエストされたとき、または知的分散型ファイルシステム１１０によって設定されたとき、冗長パラメータ(redundancy parameter)に合致しない任意のブロックを見つけ出す(locate)。
【００６５】
第１に、パリティ情報から再生成できるデータは再生成され、そしてリクエストが、新たなデータに対するスペースを割り当てるためにフォワード割り当てモジュールに送信される。フォワード割り当て器は、ＣＰＵおよびネットワーク稼働率をモニタし、そしてＣＰＵおよびネットワーク稼働率が所定の目標に到達すると積極的に作動を始める。この所定の目標は、システム管理者によって設定され、または、例えばコンピュータプロセッサのようなファクタに従ってプリセットされてもよい。一旦目標が達成されると、故障回復モジュールは、スマート記憶ユニットの性能への影響を低減するために、目標の時間に達成されるレートで有利にデータを再計算する。
【００６６】
もし、最近故障した装置がオンラインに復帰すると、故障回復モジュールは、データの完全性を確認し、且つ任意の不一致を修正するために、回復した装置のリモートブロック管理モジュール３３７と通信する。
【００６７】
知的分散型ファイルシステム１１０は、また、ホットスタンバイ装置の包含をサポートしてもよい。ホットスタンバイ装置は、目下のところ何のデータ記憶も行わない休止(idle)している記憶装置であるが、装置故障時に使用される。このような状況においては、故障回復モジュールは、ホットスタンバイ装置のリモート風呂管理モジュール３３７と通信することにより、ホットスタンバイ装置を用いて、失われたデータを再構築してもよい。
【００６８】
２．ブロックキャッシュモジュール
ブロックキャッシュモジュール３３３は、データブロックのキャッシング、ネーム検索、およびメタデータのデータ構造を管理する。一実施形態において、ブロックキャッシュモジュール３３は、ＢＳＤバーチャルファイルシステムのバッファキャッシュと共に又はその代わりに動作する。
【００６９】
ブロックキャッシュモジュール３３３は、使用頻度が最も低い(Least Recently Used)キャッシングアルゴリズムを用いてデータブロックおよびメタデータのデータブロックをキャッシュしてもよいが、例えばフリケンシーキャッシング(frequency cashing)のような種々のキャッシングアルゴリズムを使用してもよい。ブロックキャッシュモジュール３３は、どれが最もよく実行するかによってどのブロックキャッシングアルゴリズムを使用すべきかを決定してもよく、または一実施形態においては、アルゴリズムはデフォルトとして設定されてもよい。
【００７０】
最も使用頻度が低いキャッシング（“ＬＲＵ”）は、ほとんどのシステムで使用されている代表的なキャッシングスキームである。ＬＲＵは、一旦データがアクセスされると、それは再びアクセスされる可能性が最も高いという原理に基づいている。従って、データは、最も長い時間アクセスされなかったデータが捨てられるというような、その最近の使用順に記憶される。
【００７１】
フリケンシーキャッシングは、最も頻繁にアクセスされたデータを記憶する。ディスクのライトは、時間が集中した動作であるため、追加の性能(performance)は、メタデータのデータ構造におけるアクセス頻度を追跡し、且つアクセス頻度に基づきキャッシングすることにより得られる。
【００７２】
加えて、ブロックキャッシュモジュール３３３は、“オンデマンド(on demand)”プロトコルまたは“先読み(read ahead)”プロトコルを利用してもよい。ここで、より多くのデータがリクエストされるよりも必要とされる。ブロックキャッシュモジュール３３３は、データのセットについてのリクエストを送信してもよく、そしてまた、データのセットの前にある程度のデータをリクエストしてもよい。例えば、ブロックキャッシュモジュール３３は、１パケットの先読み、２パケットの先読み、１０パケットの先読み、２０パケットの先読み、等々といったような先読みを実施する。他の実施形態において、ブロックキャッシュモジュール３３３は、リクエストの待ち時間に基づき先読み技術を利用してもよい。例えば、ブロックキャッシュモジュール３３３は、Ｋパケットの先読みを実施してもよく、ここでＫはリンクの待ち時間およびリードレートを用いて計算されたものである。ブロックキャッシュモジュール３３３は、また、先読みデータのサイズを決定するためにＣＰＵおよびネットワークの稼働率に基づき他のアルゴリズムを使用してもよい。さらにまた、ブロックキャッシュモジュールは、セットキャッシングプロトコルを利用してもよく、またはシステムの性能レベルに応じるためにキャッシングプロトコルを変えても良い。
【００７３】
キャッシュ３４０は、キャッシュブロックサイズを異なる量に増やすために修正され、または、一般マルチユーザオペレーティングシステムに提供されるデフォルトサイズを用いて実施されるが、システム性能に大きな影響を与えることはない。このような修正は、例えば、記憶されるデータのタイプ、処理速度、知的分散型ファイルシステムにおけるスマート記憶ユニットの数、および使用される保護スキームのようなファクタによる種々の性能テスト決定されてもよい。
【００７４】
３．ローカルブロック管理モジュール
ローカルブロック管理モジュール３３５は、記憶装置３６０上にローカルに記憶されたデータブロックの検索(retrieval)、記憶(storage)、および割り当て(allocation)を管理する。ローカルブロック管理モジュール３３５は、例えば、ネットワークカードのような、記憶装置３６０の他の部分にデータをディスクから移動させるために、ゼロコピーファイルリードを実施し、これにより性能を改善する。ローカルブロック管理モジュール３３５は、また、性能を上げるために、使用される記憶装置３６０に基づく修正を実施する。一実施形態において、ローカルブロック管理モジュール３３５は、ローカルファイル記憶レイヤに駐在し、そしてフリーＢＳＤファストファイルシステムと共に及び／又はその代わりに動作してもよい。
【００７５】
４．リモートブロック管理モジュール
リモートブロック管理モジュール３３７は、例えばブロックリクエスト、ブロック応答、およびリモート装置故障の検出を含む装置間の通信を管理する。一実施形態において、リモートブロック管理モジュール３３７は、ローカルファイルシステムレイヤに駐在する。
【００７６】
一実施形態において、スマート記憶ユニット１１４は、リモートブロック管理モジュール３３７を介して知的分散型ファイルシステム１１０における他のスマート記憶ユニット１１４と接続され、及び／又はそれと通信してもよい。
【００７７】
リモートブロック管理モジュール３３７は、ＴＣＰのようなコネクションを介してスマート記憶ユニット１１４が互いにトークすることを可能にしてもよい。一実施形態において、各スマート記憶ユニット間には少なくとも２つのＴＣＰコネクションが存在し、一つはデータ伝送のためのものであり、もう一つはメッセージ伝送のためのものである。この二重チャンネルＴＣＰ通信アーキテクチャの利点は、データブロックがページサイズの倍単位で送信される限り、データは、ＤＭＡ転送により直接的にネットワークインターフェイスカードからシステムメモリに、そしてＤＭＡ転送によりシステムメモリからシステムの他の部分（あるいは再びネットワークインターフェイスカード）に、システムメモリの一部分から他の部分にデータがコピーされる必要なく、送信されてもよいことである。これは、ＣＰＵが、データパケットがデータヘッダを含んでいないのでそれらを分析することに関与する必要がなく、または、情報が制御チャンネル上で伝送されるのでこの情報を確認することに関与する必要がないからである。高性能サーバおよびオペレーションシステムにおいて、システムメモリの一部分から他の部分へのメモリコピーは、システム性能に関して重度の制限になる。
【００７８】
一実施形態において、リモートブロック管理モジュール３３７は、種々の他のタイプのメッセージのみならず、例えば、データブロックアクセスメッセージ（例えば、READ,READ_RESPONSE,WRITE,およびWRITE_RESPONSE）、メタデータアクセスメッセージ（例えば、GET_INODE,GET_INODE_RESPONSE,SET_ADDRESS,GET_ADDRESS,およびINVALIDATE_INODE）、ディレクトリメッセージ（例えば、ADD_DIRおよびREMOVE_DIR）、ステータスメッセージのようなメッセージを利用するメッセージング通信を用いて通信する。
【００７９】
二重チャンネルプロトコルを上述したが、他の通信プロトコルが、スマート記憶ユニット１１４間の通信を可能するために使用されてもよい。
【００８０】
５．ブロック装置モジュール
ブロック装置モジュール３３９は、ファイルシステムによって使用されるディスクハードウェアの特定の一部(piece)のためのデバイスドライバを務める。例えば、もし物理的記憶装置がＡＴＡディスクであれば、ブロックデバイスモジュール３３９はＡＴＡディスクドライバを務める。
【００８１】
Ｃ．キャッシュ
キャッシュメモリまたはキャッシュ３４０は、例えば、１Ｇ ＲＡＭキャッシュのような本技術分野で知られている種々のプロダクトを用いることにより実施されてもよい。図３において図解されているキャッシュ３４０は、一定時間内に最近アクセスされた又はアクセスされるデータのブロックを記憶してもよい。キャッシュ３４０は、種々の他のタイプの装置のみならず、スタティックＲＡＭ装置、ダイナミックＲＡＭ装置、内部キャッシュ、ディスクキャッシュのような高速記憶機構を用いて実施されてもよい。代表的には、データは、不揮発性記憶装置をアクセスするのに要する時間よりも速くキャッシュ３４０からアクセスされる。キャッシュ３４０はデータを記憶し、もしスマート記憶ユニット１１４が記憶装置３６０からデータをアクセスする必要があれば、データが既に読み出されたかを知るために最初にキャッシュ３４０がチェックされる。従って、キャッシュ３４０の使用は、データブロックの読み出しにおいてスマート記憶ユニットの性能を改善する。
【００８２】
Ｄ．ネットワークスタック
一実施形態において、スマート記憶ユニット３１０は、また、例えば、ＴＣＰ／ＩＰのようなプロトコルを用いて、入ってくるメッセージおよび出て行くメッセージトラヒックを処理するネットワークスタック３５０を備える。しかしながら、他のプロトコルまたはデータ構造がスタック３５０を実施するために使用されてもよいことが認識される。
【００８３】
Ｅ．記憶装置
記憶装置３６０は、データブロックを記憶するために使用される不揮発性記憶装置である。記憶装置３６０は、例えば、４ １．２５ＧＢ ＡＴＡ１００装置、ＳＣＳＩ装置等のような本技術分野において知られている種々のプロダクトを用いて実施されてもよい。加えて、記憶装置３６０のサイズは、知的分散型ファイルシステムにおける全てのスマート記憶ユニット１１４について同一であってもよく、またはそれは異なるスマート記憶ユニット１１４についてサイズを変えるものであってもよい。
【００８４】
Ｆ．システム情報
一実施形態において、スマート記憶ユニット１１４は、スマート記憶ユニット１１４が他のスマート記憶ユニット１１４と通信することを可能にするコンピュータ上で動作する。コンピュータは、例えば、ペンティアムプロセッサ、ペンティアムIIプロセッサ、ペンティアムプロプロセッサ、ペンティアムIVプロセッサ、ｘｘ８６プロセッサ、アルファプロセッサ等のような一つまたはそれ以上のマイクロプロセッサを用いた汎用のコンピュータであってもよい。
【００８５】
一実施形態において、プロセッサユニットは、オープンソースのＦｒｅｅＢＳＤオペレーティングシステムを稼動させ、そしてファイルのオープニング、ライティング、およびクロージングのような標準オペレーティングシステムファンクションを実施する。他のオペレーティングシステムは、例えば、マイクロソフト（登録商標）ウィンドウズ（登録商標）３．Ｘ、マイクロソフト（登録商標）ウィンドウズ（登録商標）ＮＴ、マイクロソフト（登録商標）ウィンドウズ（登録商標）ＣＥ、マイクロソフト（登録商標）ウィンドウズ（登録商標）ＭＥ、Palm Pilot OS、アップル（登録商標）ＭａｃＯＳ（登録商標）、ディスクオペレーティングシステム（ＤＯＳ）、ＵＮＩＸ（登録商標）、ＩＲＩＸ、Solaris、SunOS、FreeBSD、リナックス（登録商標）、ＩＢＭ（登録商標）ＯＳ／２オペレーティングシステムのようなものであってもよいことが認識される。
【００８６】
一実施形態において、コンピュータは、例えば、イーサネット（登録商標）（ＩＥＥＥ８０２．３）、トークンリング（ＩＥＥＥ  ８０２．５）、ファイバー分散データリンクインターフェイス（ＦＤＤＩ）、または非同期転送モード（ＡＴＭ）のようなネットワークの接続性を備える。さらに、コンピュータは、例えば、NFS v2/v3 over UDP/TCP、マイクロソフト（登録商標）ＣＩＦＳ、ＨＴＴＰ 1.0、ＨＴＴＰ 1.1、ＤＡＦＳ、ＦＴＰ等のような種々のネットワークプロトコルをサポートする。
【００８７】
一実施形態において、スマート記憶ユニット１１４は、ジャンボ９Ｋイーサネット（登録商標）フレームをサポートする１０００／１００ネットワークインターフェイスカードのみならず、シングルまたはデュアルＣＰＵ ２Ｕラック実装可能な構成、マルチプルＡＴＡ１００インターフェイスを備える。しかしながら、種々の構成が使用されてもよいことが認識される。
【００８８】
知的分散型ファイルシステムデータ構造
図４は、知的分散型ファイルシステムで使用されるディレクトリ構造の例を図解する。この例において、ROOTディレクトリは、“DFSR”と名づけられ、そしてサブディレクトリ
IMPORTANT、TEMP、およびUSERを備える。IMPORTANTサブディレクトリは、サブディレクトリPASSWORDSおよびCREDITCARDを備える。ファイルUSER.TXTおよびADMIN.TXTは、PASSWORDSサブディレクトリに記憶される。従って、USER.TXTファイルのアドレスは、
/DFSR/IMPORTANT/PASSWORDS/USER.TXT
である。
【００８９】
ディレクトリおよびファイルについての情報またはメタデータは、知的分散型ファイルシステム１１０によって記憶され且つ維持される。
【００９０】
Ａ．メタデータ構造
図５は、メタデータを記憶するためのデータ構造５１０の例を図解する。代表的なデータ構造５１０は、以下の情報を記憶する。
【００９１】
【表２】
0004504677.tif 000003
【００９２】
データ構造５１０の例は、メタデータを記憶するためのデータ構造５１０の一実施形態を図解することが認識され、そして種々の実施が本発明に従って使用されてもよい。例えば、データ構造５１０は、異なるフィールドを備えても良く、そのフィールドは異なるタイプでもよく、そのフィールドはグループ化されて別々に記憶される、等々である。
【００９３】
図６Ａ，６Ｂ，６Ｃおよび６Ｄは、データロケーションテーブルのいくつかのタイプについてデータロケーションテーブル構造の例を提供し、それはそれぞれタイプ０、タイプ１、タイプ２、およびタイプ３である。図６Ａにおいて、タイプ０データロケーションテーブルは、データロケーションテーブルにおけるエントリが、データブロックが記憶されたロケーションを示すデバイス／ブロックナンバーペアを備えることを意味する２４のダイレクトブロックエントリを備える。図６Ｂにおいて、タイプ１データロケーションテーブルは、１５のダイレクトブロックエントリ(direct block entry)、３つのシングルインダイレクトエントリ(single-indirect entry)、３つのダブルインダイレクトエントリ(double-indirect entry)、および３つのトリプルインダイレクトエントリ(triple-indirect entry)を備える。シングルインダイレクトエントリについてのエントリは、ダイレクトエントリの追加のデータロケーションテーブルが記憶されているロケーションを示す。ダブルインダイレクトエントリについてのエントリは、データロケーションテーブルが記憶されたロケーションを示し、ここでのデータロケーションテーブルは、シングルインダイレクトエントリを備える。トリプルインダイレクトエントリについてのエントリは、データロケーションテーブルが記憶されたロケーションを示し、ここでのデータロケーションテーブルは、ダブルインダイレクトエントリを備える。
【００９４】
任意のブロックが任意の数の装置にわたってミラーされてもよいので、メタデータのデータ構造５１０は、複数のロケーションを表現するのに十分柔軟性があり、そして一定のスペース内でのダイレクトな指標付け(indexing)によってもたらされる高速アクセスをさらに提供する。従って、タイプは、使用されるべきデータロケーションテーブルのタイプを示すためにメタデータのデータ構造５１０と有利に関連している。メタデータのデータ構造５１０の一実施形態において、例えば２４のポインタのような２４のデータエントリのための余地が存在してもよい。
【００９５】
タイプ０は、データファイルが小さいとき；データロケーションアドレスがダイレクトエントリとして記憶されているときに使用される。従って、タイプ０のメタデータのデータ構造は、２４のダイレクトエントリを備える。タイプ１は、２度までのミラー（３つのファイルコピー）および大きなファイルをサポートするために使用される。タイプ１は、１５のダイレクトエントリ、３つのシングルインダイレクトエントリ、３つのダブルインダイレクトエントリ、および３つのトリプルインダイレクトエントリを使用する。タイプ３のデータロケーションテーブルは、ディスクアドレスの全てがトリプルインダイレクトエントリとして記憶されるように、更なるミラーリングを可能にする。結果として、最大で２４までの完全なファイルが記憶されてもよい。
【００９６】
種々のデータロケーションテーブルが使用されることが認識され、そして図６Ａ，６Ｂ，６Ｃ，６Ｄは実施形態の例を図解する。他の実施形態において、例えば、データロケーションテーブルは、ダイレクトおよびインダイレクトエントリの異なる混合体を備えてもよい。さらに、他の実施形態において、データロケーションテーブルは、テーブルにおける各エントリについてエントリのタイプを指定するエントリフィールドを備えてもよい。タイプは、例えば、他のもの（例えば、クワドラプルインダイレクトなど）のみならず、上述したもの（例えば、ダイレクト、シングルインダイレクト、ダブルインダイレクト、トリプルインダイレクト）を含んでも良い。加えて、データロケーションテーブルは、Ｘレベルまでのデータロケーションテーブルのより深いネスティング(nesting)を備えてもよい。ここでＸは整数である。
【００９７】
１．ディレクトリメタデータ
図７Ａは、ディレクトリPASSWORDSについてのメタデータのサンプルセットを図解する。図７Ａにおいて、データ構造は、PASSWORDSディレクトリについての情報を記憶する。ディレクトリは、２度ミラーされる（合計３つのコピー）。ディレクトリ構造は比較的小さいので（例えば、とれはブロック内に収まる）、使用される３つのダイレクトポインタのみが存在し、各コピーについては一つである。メタデータのサンプルセットは、使用されないブロックエントリ７３０のみならず、デバイス／ブロックナンバーペアを用いてデータブロックのロケーションを示すダイレクトエントリ７２０を備えるデータロケーションテーブル７１０を備える。
【００９８】
２．ファイルメタデータ
図７Ｂは、ファイルUSER.TXTについてのメタデータのサンプルセットを図解する。図７Ｂにおいて、データ構造は、USER.TXTファイルについての情報を記憶する。USER.TXTファイルデータについてデータブロックのそれぞれの一つのコピーが存在し、そしてデータは、３＋１パリティスキームを用いて保護されている。USER.TXTについてのコンテンツデータは、サイズが４５Ｋであり且つブロックサイズが８Ｋであり、従って全く使用されない６番目のデータブロックと共に６個のデータブロックが存在する。データロケーションテーブル７１０は、６個のデータのブロックが記憶７２０されたロケーションを示し、ここでデータのブロックは装置ナンバーおよびブロックナンバーによって参照され、そこでは最初のエントリが最初のデータブロックに対応する。さらに、コンテンツデータのためのパリティ情報のロケーションはパリティマップ７４０に記憶され、そのロケーションは、“パリティマップポインタ”のようなデータ構造の最後のロケーションによって指定される。USER.TXTファイルは、このように３＋１パリティスキームを用いて記憶され、どの３個のデータのブロックについても、パリティデータのブロックが記憶される。この３＋１パリティスキームには６個のブロックが存在するので、２つのパリティデータのブロックが存在する（６を３で除算して、最も近い整数にまるめ）。パリティマップは、両方のパリティデータのブロックが記憶されたロケーションを示し、ここでパリティデータのブロックは、装置ナンバーおよびブロックナンバーによって参照され、そしてそこでは、最初のエントリが最初のパリティデータのブロックに対応する。
【００９９】
Ｂ．データロケーションテーブルデータ構造
知的分散型ファイルシステム１１０は、データがどのように記憶されるかについての柔軟性のみならず、多種多様なデータファイルについての記憶を提供してもよい。データファイルのミラーリングおよび冗長性は、知的分散型ファイルシステム１１０が異なるファイルのための冗長パラメータを変えることをサポートすることを可能にするファイルシステムレベルで実施される。例えば、いくつかのディレクトリは、ミラーされてもよく、保護されたパリティであってもよく、または全く保護されなくてもよい。
【０１００】
図８Ａ，８Ｂおよび８Ｃは、変化する保護タイプおよびレベルのデータファイルについてのデータロケーション情報を記憶するために使用されてもよい。図８Ａ，８Ｂおよび８Ｃは、種々のデータロケーションテーブルを図解するために示され、そして種々の異なるフォーマット及び／又は構造が使用されてもよいことが認識される。
【０１０１】
図８Ａは、対応するファイルのデータの各ブロックがどこに記憶されている場所を示すサンプルデータロケーションテーブル８１０を図解する。図７Ｂにおけるもののような、ファイルについての対応するメタデータは示されていないが、データロケーションテーブル８１０がメタデータのセットに対応することが認識される。代表的なデータロケーションテーブル８１０はダイレクトエントリおよびインダイレクトエントリの両方を備える。
【０１０２】
ダイレクトエントリは、装置ＩＤ／ブロックペアを含む。装置ＩＤは、データが記憶されるスマート記憶ユニットを示し、そしてオフセットまたはブロックアドレスは、データが記憶される記憶装置上のロケーションを示す。データロケーションテーブルにおける一つのサンプルエントリは、
エントリ  装置      ブロック
１        ７        １２７
【０１０３】
サンプルデータロケーションテーブル８１０は、また、データロケーションテーブルがより大きなデータのセットのためのデータロケーションを追跡することを可能にする追加のデータロケーションテーブルを指すインダイレクトエントリを備える。インダイレクトエントリのレベルが理論上は制限されない一方で、レベルは、スループットレートを改善するために有利に制限されてもよい。例えば、データロケーションテーブルは、多くてもダブルインダイレクトエントリまたはトリプルインダイレクトエントリを許容(allow)することに限られてもよい。代表的なデータロケーションテーブル８１０は、インダイレクトエントリの二つのレベルを図解する。
【０１０４】
さらに、データロケーションテーブルの最後のエントリは、パリティマップ（もしあれば）のアドレスを記憶するために取っておかれる。他の例において、パリティマップのアドレスは、例えば、メタデータのデータ構造におけるエントリのような他のロケーションに記憶されてもよい。もし、データのセットが、パリティ保護を備えなければ、アドレス値は、ＮＵＬＬのような標準値に設定されてもよい。
【０１０５】
図８Ｂは、二つの追加のロケーションにおけるミラーされたデータについてのデータロケーションテーブルを図解する。データロケーションテーブルは、データの各コピーについてブロックまたはオフセットアドレスおよび装置ＩＤを備える。本例において、データロケーションテーブル、ミラーされたロケーションは、ブロック毎のベース(block-by-block basis)で選択されている。例えば、特定のスマート記憶ユニットをミラーするために一つまたはそれ以上のスマート記憶ユニットを選択するような他のスキームが使用されてもよい。図８Ｂにおけるデータロケーションテーブルはダイレクトエントリのみを備えるが、インダイレクトエントリを使用してもよいことが認識される。
【０１０６】
一実施形態において、ファイルのためのミラーリング情報は、ファイルの対応するメタデータ構造に記憶されてもよい。この情報は、各コピーのためのデータロケーションテーブルのみならず、例えば、データのコピーの数を記憶してもよい。データロケーションテーブルがシングルデータ構造として記憶されてもよく、及び／又は、データロケーションテーブルの個々のコピーが異なるロケーションに記憶されてもよいことが認識される。
【０１０７】
ミラーされたデータを備える図８Ｂのサンプルデータロケーションテーブルは、パリティ保護を備えないが、データロケーションテーブルは、パリティ情報を備えても良い。
【０１０８】
図８Ｃは、パリティマップを備えたデータロケーションテーブルを図解する。代表的なデータロケーションテーブルにおいて、データは３＋１パリティスキームを用いて保護されており、即ちパリティデータのセットは３つのデータブロックのどれからも生成される。データを生成するための本技術分野で知られた技術が使用されてもよく、例えば、パリティブロックを生成するために、ビット毎、バイト毎、またはブロック毎のベースで、データのブロックを一緒にＸＯＲすることによるような技術がある。
【０１０９】
代表的なデータロケーションテーブルは、２１のデータブロック（ブロック０からブロック２０）からなるデータファイルについての情報を提供する。パリティスキームは３＋１であるため、パリティブロックは、３つのデータブロックの各セットについて生成される。表３は、図８Ｃに示されたいくつかのパリティブロックといくつかのデータブロックとの間の対応を図解している。
【０１１０】
【表３】
0004504677.tif 000004
【０１１１】
サンプルデータロケーションテーブルは、パリティマップまたはロケーションテーブルを備える。代表的なパリティマップにおいて、データおよびパリティマップを生成するために使用されるブロックエントリのセット間に１対１マッピングが存在する。他の実施形態において、パリティマップは、また、パリティマップは、また、装置故障のためにそのダイレクトロケーションのいずれにおいても利用できないイベントにおいて、データを再生成するためにどのブロックが一緒にＸＯＲされたパリティであるかを、装置およびブロックナンバーによって特定する可変サイズのエントリを備える。他の実施形態において、パリティ生成スキームは、プリセットされ、データを再生成するために一緒にＸＯＲされるべきブロックを特定することなく、パリティデータの一致およびロケーションが知的分散型ファイルシステム１１０によって決定されてもよい。
【０１１２】
一実施形態において、パリティマップは、例えば、メタデータのデータ構造に含まれるよりも、むしろメタデータのデータ構造の最後のエントリにおけるように、メタデータのデータ構造によって指示されてもよい。このマップは、メタデータ構造にダイレクトに含まれる代わりに指摘されてもよく、なぜならば、その使用は、故障したスマート記憶ユニット１１４のまれな場合に必要とされるのみだからである。パリティマップは、また、スマート記憶ユニット１１４が、データを再構成している間に一度パリティマップを横断(traverse)すること、および横断されるに従ってパリティマップを分析することを可能にするパリティ再結合ブロックを表すために可変サイズのエントリを使用してもよい。或る状況において、エントリを読み出し且つ分析するための計算およびＩ／Ｏ時間は、パリティ計算時間に比較すれば無視できる。
【０１１３】
パリティロケーション情報を備えた図８Ｃのサンプルデータロケーションテーブル８１０は、ミラーリング情報またはインダイレクトエントリを備えないが、一つまたは両方がパリティロケーション情報とともに使用されてもよい。さらに、他のデータ構造が使用されてもよいことが認識され、且つデータロケーションテーブルデータ構造は本発明の一実施形態を図解するためにのみ示される。
【０１１４】
Ｃ．サンプルデータ
図９は、サンプルデータロケーションテーブル９１０およびパリティマップ９２０、およびデータが記憶される対応する装置を図解する。図９の例は、同一のファイルからのデータについて、データが、装置上の変化するロケーションにどのように記憶され、データの“ストライプ(stripe)”が各装置上の異なるオフセットアドレスにわたって記憶され、そしてパリティデータが種々の装置に記憶されるかを示す。他の実施形態において、データは、各装置上の同一のオフセットアドレスに記憶されてもよい。
【０１１５】
例えば、最初のストライプについてのパリティデータは、ロケーション４００で装置３上に記憶され、そしてロケーション１００で装置０上に記憶されたデータブロック０、ロケーション２００で装置１上に記憶されたデータブロック１、ロケーション３００で装置２上に記憶されたデータブロック２に関係する。２番目のストライプについてのパリティデータは、ロケーション６００で装置２上に記憶され、そして、ロケーション３００で装置０上に記憶されたデータブロック３、ロケーション８００で装置４上に記憶されたデータブロック４、およびロケーション７００で装置１上に記憶されたデータブロック５に関係する。
【０１１６】
いくつかの実施形態において、個々の装置は、どこに、及び／又は、どのようにロケーションをディスク上の実際のロケーションにマッピングするかを決定する。例えば、もし、装置０が４つの物理的ハードウェアディスクを備え且つ各ディスクが１００ブロックのための記憶容量を備えるならば、装置０は、記憶のためにロケーション０からロケーション３９９までを許可する。ロケーションをどのようにブロックにマッピングするかを決定するために使用されるガイドラインの一つのサンプルセットは次のようである。
テ゛ィスクナンハ゛ー＝（ロケーション／テ゛ィスクごとのフ゛ロックナンハ゛ー）のフロア(floor)
テ゛ィスク上のフ゛ロック＝ロケーションＭＯＤテ゛ィスクごとのフ゛ロックナンハ゛ー
【０１１７】
ＭＯＤは割り算の余りをとるモジュラス演算子であることに注意されたい。上記のガイドラインは、ロケーションをディスクおよびディスクブロックにマッピングするために使用されるガイドラインの例にすぎず、そして多くの他のガイドラインまたはスキームが使用できることが理解される。例えば、一実施形態は、各ブロックを表すブロックレンジのリンクされたリクエストとを利用し、そして横断(traversal)を管理してもよい。リンクされたリクエストとは、マルチプルサイズのディスク(multiple sized disk)を可能にする利点がある。
【０１１８】
データおよびパリティ情報の記憶の柔軟性のために、新たなスマート記憶ユニットが付け加えられに従い、新たなデータが新たなスマート記憶ユニットに記憶され、及び／又は、システムを中断することなく、既存のデータが新たなスマート記憶ユニットに移動され（例えば、既存のユニット上のデータを削除する前にコピーを作成することにより）てもよい。加えて、データブロックまたは全体ファイルが、高いリクエスト量(high request volume)、ディスク故障、冗長性またはパリティパラメータにおける変化、等々に応答してリアルタイムに移動またはコピーされてもよい。
【０１１９】
ＶＩＩ．知的分散型ファイルシステム処理
Ａ．データの読み出し(Retrieving Data)
図１０は、データを読み出すためのフローチャート（“データ読み出し処理”）の一実施形態を図解する。例えば、ディレクトリメタデータ、ファイルメタデータ、コンテンツデータ等の種々のデータタイプが取得されてもよい。
【０１２０】
スタートステートから始めると、データ読み出し処理は、データが記憶されたロケーションを受信する（ブロック１０１０）。一実施形態において、ロケーションは、スマート記憶ユニットＩＤおよびオフセットまたはブロックアドレスを用いて指示されてもよい。他の実施形態において、記憶装置のＩＤが使用されてもよいのに対し、他の実施形態においては、テーブルは他のＩＤにマッピングする等々のために使用されてもよい。
【０１２１】
次に、データ読み出し処理は、データがローカルに記憶されているかどうかを決定する（ブロック１０２０）。もし、データがローカルに記憶されていれば、データ読み出し処理は、ローカル記憶からデータを読み出す（ブロック１０３０）。一実施形態において、データ読み出し処理は最初にキャッシュをチェックし、そしてもしデータがそこに存在しなければ、記憶装置をチェックする。他の実施形態において、データ読み出し処理は、記憶装置のみをチェックしてもよい。
【０１２２】
もし、データがローカルに記憶されていなければ、データ読み出し処理は、データについてのリクエストを、データが記憶されたスマート記憶ユニットに送信する（ブロック１０４０）。一実施形態において、リクエストは、図１に示されるスイッチコンポーネント１２５を介して送信される。そしてデータ受信処理はリクエストされたデータを受信する（ブロック１０５０）。
【０１２３】
データ読み出し処理は、リクエストされたデータを収集し、そしてそのデータを戻す（ブロック１０６０）。いくつかの実施形態において、データは、データの全セットが収集された後に戻される。他の実施形態において、データの一部分またはセットは、データがローカル記憶から読み出され、または他のスマート記憶ユニットから受信されるにつれて戻されてもよい。一部分は、ファイルロケーションテーブルに従って発生順(sequential order)に戻されてもよく、またはそれらは読み出されまたは受信されるにつれて戻されても良い。データが戻された後は、データ読み出し処理は終了ステートに進む。
【０１２４】
図１０は、データ読み出し処理の一実施形態を図解し、そして他の実施形態が使用され得ることが理解される。一実施形態において、例えば、並列処理、パイプラインまたは非同期Ｉ／Ｏのような技術または技術の組み合わせを用いてマルチプル読み出しデータ処理によってデータが読み出されるように、一つ以上のデータ読み出し処理が同時に使用されてもよい。
【０１２５】
Ｂ．ネーム検索処理
図１１は、ネーム検索のための処理（“ネーム検索処理”）の一実施形態を図解する。スタートステートから始めると、ネーム検索処置は、ファイルネームを受信し（ブロック１１１０）、ルートディレクトリのメタデータを読み出し、そしてそのルートメタデータのロケーションをCURRENTとして設定する（ブロック１１２０）。一実施形態において、ルートディレクトリのデータは、図５のデータ構造のようなデータ構造に記憶されるが、種々のデータ構造がルートディレクトリのメタデータを記憶するために使用されてもよい。さらにまた、いくつかの実施形態において、ルートディレクトリのメタデータは、各スマート記憶ユニット１１４がルートディレクトリのメタデータと同一または類似のコピーを備えるように、各スマート記憶ユニット１１４で記憶されてもよい。他の実施形態において、ルートディレクトリのメタデータは、知的分散型ファイルシステム１１０における他のロケーションに記憶されてもよく、またはファイルリクエストと共にスマート記憶ユニット１１４に送信されてもよい。例えば、ミューテックス(mutexes)及び／又はセマフォ(semaphores)等によってロックすることのような、データの複数コピーの完全性を保証するための公知の技術が使用されてもよい。
【０１２６】
そして、ネーム検索処置は、ファイルのネームの一部である次のトークン(token)を読み出しても良い（ブロック１１３０）。そして、ネーム検索処置は、CURRENTのためのデータを記憶するスマート記憶ユニット１１４からのトークンのメタデータのロケーションのアドレスをリクエストする（ブロック１１４０）。このリクエストはローカルまたはリモートであってもよい。そして、ネーム検索処理は、戻されたアドレスをCURRENTとして設定し（ブロック１１５０）、そして他のトークンが存在するかどうかを決定する（ブロック１１６０）。ここでトークンはディレクトリ階層における単一のレベルを表す。もし、他のトークンが存在しなければ、ネーム検索処理は、参照値をCURRENTに戻し（ブロック１１７０）、そしてエンドステートに進む。
【０１２７】
ネーム検索処理の他の実施が使用されてもよいことが認識される。例えば、ネーム検索処置は、ファイルのメタデータのデータを読み出しても良い。加えて、一旦リクエストされたデータが見つかると、ネーム検索処理は、データがローカルに記憶されているのか、他のスマート記憶ユニットで記憶されているのかを決定する。もし、データがローカルに記憶されていれば、ネーム検索処理は、リードリクエストをスマート記憶ユニット１１４のローカルブロック管理モジュール３３５に送信してもよく、もしデータが他のスマート記憶ユニット上に記憶されていれば、ネーム検索処理は、リモートスマート記憶ユニット１１４のリモートブロック管理モジュール３３７にリードリクエストを送信してもよい。
【０１２８】
Ｃ．ファイルリクエスト処理
図１２は、ファイルリクエストを処理するためのフローチャートの一実施形態を図解する（“ファイルリクエスト処置”）。スタートステートから始めると、ファイルリクエスト処理は、ファイルを読み出すためのリクエストを受信する（ブロック１２１０）。一実施形態において、ファイルは、ロケーションおよびファイルネームを含むファイルのフルパスネームを用いて指示される。他の実施形態において、パスは、相対パス及び／又は他のデータ構造であってもよく、及び／又は、テーブルのような他のデータ構造は、ファイルのアドレスについての情報を記憶するために使用されてもよい。次に、ファイルリクエストは、図１１に図解されるようなネーム検索処置を実施して（ブロック１２２０）、ファイルのメタデータのデータ構造のロケーションを決定する。
【０１２９】
そして、ファイルリクエスト処理は、上述した図１０に示されるようなファイル検索処理を用いてファイルのメタデータを読み出す（ブロック１２３０）。ただし、他のファイル読み出し処理が使用されてもよい。一実施形態において、ファイルのメタデータは、ファイルにおけるデータの各ブロックが知的分散型ファイルシステムの全体を通して記憶されるロケーションへのアクセスを提供するデータロケーションテーブルを備えてもよい。
【０１３０】
そして、ファイルにおけるデータの各ブロックについて（ブロック１２４０，１２７０）、ファイルリクエスト処理は、ファイルのメタデータにおいてそれを探すことによりデータブロックのロケーションを獲得し（ブロック１２６０）、上述した図１０に示されるようなファイル読み出し処理を用いてデータブロックを読み出す（ブロック１２６０）。ただし、他のファイル読み出し処理が使用されてもよい。
【０１３１】
そして、ファイルリクエスト処理は、ファイルデータを戻し（ブロック１２８０）、そしてエンドステートに進む。いくつかの実施形態において、ファイルは、データの全セットが収集された後に戻される。他の実施形態において、一つまたはそれ以上のデータのブロックは、データが読み出されるときに戻されても良い。一部分は、ファイルロケーションテーブルに従い発生順に戻されてもよく、または、それらは、それらが読み出しまたは受信されるときに戻されてもよい。一実施形態において、ファイルリクエスト処理は、ストリーミングサーバがデータブロックを順序付ける(order)ように、データブロックを順番及び／又は他のモジュールに置いてもよい。データが戻された後は、データ読み出し処理はエンドステートに進む。
【０１３２】
図１２は、ファイルリクエスト処理の一実施形態を図解し、そして他の実施形態が使用されてもよいことが認識される。例えば、ファイルリクエスト処理は、図１１に示されるものよりも異なるネーム検索処理を用いてファイルのロケーションを決定してもよい。他の実施形態において、一つよりも多くのデータ読み出し処理は同時に使用されて、例えば、並列処理、パイプライン、または非同期Ｉ／Ｏのような技術または技術の組み合わせを用いて並列にマルチプルデータ読み出し処理によってデータが読み出されることを可能にするデータブロックを読み出してもよい。
【０１３３】
Ｄ．パリティ発生処理
図１３は、パリティ情報を発生するためのフローチャートの一実施形態を図解する（“パリティ発生処理”）。スタートステートから始めると、パリティ発生処理は、データのセットに関係するパリティスキーム情報を受信する（ブロック１３１０）。データのセットは、ファイルデータ、ファイルメタデータ、ディレクトリメタデータ、ファイルのサブセットなどを表してもよい。パリティ発生処理は、データのセットに関係するデータロケーション情報を受信する（ブロック１３２０）。次に、パリティデータの各セットについて（ブロック１３３０，１３７０）、パリティ発生処置は、データのセットを読み出す（ブロック１３４０）。例えば、もし、パリティが３＋１であれば、パリティ発生処理は、図１０に示されるようなデータ読み出し処理を用いて、最初の３つのデータのブロックを読み出す。次に、パリティ発生処理は、ビット毎、バイト毎、ブロック毎のベースでデータのＸＯＲ演算を実施するようにして、データのセットについてパリティデータを発生する。（ブロック１３５０）。そして、パリティ発生処理は、バッファにデータを記憶し、そしてデータのセットについてのパリティ情報が発生されるとブロック１３３０に戻る。パリティ情報が発生された後、パリティ発生処理は、パリティデータを記憶すべき場所を決定する（ブロック１３８０）。パリティ発生処理は、輪番パリティスキーム(rotating parity scheme)を使用してもよい。ここで、データの一連の各ストリップは、その輪番(rotation)における次の装置上に記憶される。パリティ発生処理は、パリティ情報がデータ情報と同時に失われていないことを装置故障のイベントにおいて保証するために現在のストライプについてデータを保持している装置のいずれよりむしろ異なる装置上にパリティブロックを割り当てる。パリティ発生処理は、また、パリティ記憶を考慮されることからいくつかの装置をふるい落とすために、記憶容量、ＣＰＵ稼働率、およびネットワーク稼働率のような他のファクタを考慮に入れてもよい。そして、パリティ発生処理は、割り当てられたスペースにバッファされたデータを記憶し（ブロック１３９０）、パリティデータのロケーションをパリティマップに記録し（ブロック１３９５）、そしてエンドステートに戻る。
【０１３４】
図１３は、パリティ発生処理の一実施形態を図解し、そして他の実施形態が使用されてもよいことが認識される。例えば、パリティ発生は、データのブロックを並列に読み出してもよく、そして並列に又は公知のパイプライン或いは非同期Ｉ／Ｏ技術を用いてパリティ情報を発生してもよい。さらに、パリティ発生処理は、テンポラリバッファに書き込むことなくパリティ情報のロケーションおよびパリティ情報を記憶してもよく、または、パリティ発生処理は、パリティデータまたはポインタをパリティデータに戻してもよい。
【０１３５】
Ｅ．データ回復処理
図１４は、失われた又は壊れたデータを回復するためのフローチャートの一実施形態を図解する（“データ回復処理”）。スタートステートから始めると、データ回復処置は、使用されたパリティスキームに関する情報を受信する（ブロック１４１０）。そして、データ回復処理は、故障した又は壊れたディスク又はデータについての情報を受信する（ブロック１４２０）。次に、データ回復処理は、失われた又は壊れたデータが割り当てられたパリティブロックグループについてのアドレス情報を受信する（ブロック１４３０）。そして、データ回復処理は、利用可能なスマート記憶ユニットからデータブロックを読み出す（ブロック１４４０）。データは、図１０のようなデータ読み出し処理を用いて読み出されてもよい。データ回復処理は、パリティスキームに従ってブロックをＸＯＲしてその結果をバッファに記憶するようにして、エラー訂正を実施する（ブロック１４５０）。バッファにあるデータは失われたデータを表す。そして、データ回復処理は、バッファにあるデータを戻し（ブロック１４７０）、そしてエンドステートに進む。
【０１３６】
ＶＩＩＩ．結論
本発明のいくらかの実施形態が説明されたが、これらの実施形態は、単なる例の目的にすぎず、且つ本発明の適用範囲を制限することを意図するものではない。従って、本発明の広がりおよび適用範囲は、特許請求の範囲およびその均等物に従って規定されるべきである。
【図面の簡単な説明】
【０１３７】
【図１】本発明の一実施形態のハイレベルブロックダイアグラムを図解する図である。
【図２】図１に図解されたコンポーネント間でのデータフローの一例を図解する図である。
【図３】スマート記憶ユニットの一例のハイレベルブロックダイアグラムを図解する図である。
【図４】ファイルディレクトリの一例を図解する図である。
【図５】メタデータ構造の一実施形態を図解する図である。
【図６Ａ】データロケーションテーブル構造の一実施形態を図示する図である。
【図６Ｂ】データロケーションテーブル構造の追加の実施形態を図解する図である。
【図６Ｃ】データロケーションテーブル構造の追加の実施形態を図解する図である。
【図６Ｄ】データロケーションテーブル構造の追加の実施形態を図解する図である。
【図７Ａ】ディレクトリ用のメタデータ構造の一実施形態を図解する図である。
【図７Ｂ】ファイル用のメタデータ構造の一実施形態を図解する図である。
【図８Ａ】データロケーションテーブルの一実施形態を図解する図である。
【図８Ｂ】データロケーションテーブルの追加の一実施形態を図解する図である。
【図８Ｃ】データロケーションテーブルの追加の一実施形態を図解する図である。
【図９】対応するサンプルデータを有するファイルのメタデータ構造の一例を図解する図である。
【図１０】データを取得するためのフローチャートの一実施形態を図解する図である。
【図１１】ネームレゾリューションを実施するためのフローチャートの一実施形態を図解する図である。
【図１２】ファイルを取得するためのフローチャートの一実施形態を図解する図である。
【図１３】パリティ情報を生成するためのフローチャートの一実施形態を図解する図である。
【図１４】エラー訂正を実施するためのフローチャートの一実施形態を図解する図である。
【図１】
0004504677.tif 000005
【図２】
0004504677.tif 000006
【図３】
0004504677.tif 000007
【図４】
0004504677.tif 000008
【図５】
0004504677.tif 000009
【図６Ａ】
0004504677.tif 000010
【図６Ｂ】
0004504677.tif 000011
【図６Ｃ】
0004504677.tif 000012
【図６Ｄ】
0004504677.tif 000013
【図７Ａ】
0004504677.tif 000014
【図７Ｂ】
0004504677.tif 000015
【図８Ａ】
0004504677.tif 000016
【図８Ｂ】
0004504677.tif 000017
【図８Ｃ】
0004504677.tif 000018
【図９】
0004504677.tif 000019
【図１０】
0004504677.tif 000020
【図１１】
0004504677.tif 000021
【図１２】
0004504677.tif 000022
【図１３】
0004504677.tif 000023
【図１４】
0004504677.tif 000024