JP5824519B2 - 分散型メタデータキャッシュ - Google Patents

Description

［関連出願］
本出願は、２０１０年１１月１３日出願の米国仮出願61/382,411号の優先権を主張するものであり、前記出願の内容は、参照により本明細書に組み込まれる。

従来のネットワークファイルシステム（ＮＦＳ）アーキテクチャは、ＮＦＳサーバ及び１つの又は複数のＮＦＳクライアントを備える。ＮＦＳクライアントは、メモリ及び／又は固体素子（ＳＳＤ）に、データ及び／又はメタデータを格納してもよい。ＮＦＳサーバは、ファイル及びメタデータ両方の中央リポジトリである。メタデータは、例えば、これに限定されないが、ファイルアクセス時間、ファイル所有者、ファイル更新時間及びファイル許可を含むファイルに関する情報であってもよい。ＮＦＳクライアントは、ＮＦＳサーバからファイルを取得して、当該ファイルのローカルコピーとメタデータをＮＦＳクライアントメモリに格納してもよい。そして、アプリケーションは、ネットワークを介してＮＦＳサーバに格納されたファイルのコピーに対して作業を行うのではなく、ファイルのローカルコピー及びメタデータを使用してもよい。ＮＦＳクライアント及びファイルがそれぞれ１つのみ存在し、１つのアプリケーションのみがそのファイルに対して作業を行う場合には、ファイルのローカルコピー及びメタデータのローカルコピーの格納は、大きな問題にならない。

しかしながら、１つのＮＦＳサーバは、ファイル及びメタデータのローカルコピーを格納することを望む多数のＮＦＳクライアントとやりとりをする場合がある。そして、１つのＮＦＳクライアントに存在する多くのアプリケーションが、ファイル及びメタデータのローカルコピーにアクセスを望む場合がある。複数のクライアントが、複数のアプリケーションによって操作される複数のローカルコピーを格納する場合、キャッシュコヒーレンシの問題が発生するが、これは、ＮＦＳサーバ及び／又はＮＦＳクライアントにおいてメタデータが期限切れとなった場合を考えると想像し易い。例えば、２つの異なるＮＦＳクライアントにおける２つのアプリケーションが、ファイル及びメタデータのそれぞれのローカルコピーに、実質的に同時に、異なる操作を行うことが可能である。

従来では、ＮＦＳは、ＮＦＳクライアントにメタデータに影響がある動作についてＮＦＳサーバに通知させ、ＮＦＳクライアントに周期的に（例えば、３０秒毎に）メタデータを"リタイア"させることによって、ファイル及びメタデータの制御を中央に集めて、この問題に対処していた。メタデータをリタイアさせた後に、ＮＦＳクライアントは、ＮＦＳサーバにメタデータの新たなコピーを問い合わせてもよい。新たなコピーを要求するＮＦＳクライアントの数が少ない場合には、このリタイア／リフレッシュプロトコルは、負担の大きい動作ではない。しかしながら、ＮＦＳクライアントの数が多い場合、中央化されたメタデータ制御プロセス及びリタイア／リフレッシュプロトコルにより、ＮＦＳサーバがボトルネックになってしまう可能性がある。また、１つのみのＮＦＳクライアントがファイル及び／又はメタデータにアクセスする場合には、リタイア／リフレッシュプロトコルは必要ない。

図１には、従来のＮＦＳクライアント／サーバ環境が例示されている。第１アプリケーション１１０は、ＮＦＳクライアント１１２を使用して、ＮＦＳサーバ１３０と通信を行う。同様に、第２アプリケーション１２０は、別のＮＦＳクライアント１２２を使用して、ＮＦＳサーバ１３０と通信を行う。第１アプリケーション１１０及び第１ＮＦＳクライアント１１２が第１コンピュータで実行されるのと同時に、第２アプリケーション１２０及び第２ＮＦＳクライアント１２２が第２コンピュータで実行をされてもよい。第１アプリケーション１１０及び第１ＮＦＳクライアント１１２は、メモリ１１４に格納されているローカルファイル１１８及びローカルメタデータ１１９とのやりとりを行ってもよい。同様に、第２アプリケーション１２０及び第２ＮＦＳクライアント１２２は、メモリ１２４に格納されているローカルファイル１２８及びローカルメタデータ１２９とやりとりを行ってもよい。

このような従来の環境では、メタデータ制御が、ＮＦＳサーバ１３０に集約される。メタデータリクエストが、ＮＦＳサーバ１３０へと流される。メタデータに関して、ＮＦＳクライアント１１２とＮＦＳクライアント１２２との間のピア・ツー・ピア通信は存在しない。アプリケーション及び／又はＮＦＳクライアントの数が一定の限界を超えて大きくなると、ＮＦＳサーバ１３０は、不要なボトルネックとなる可能性がある。

一実施形態において、装置は、分散型ピア・ツー・ピアメタデータキャッシュ環境で動作するよう構成される。そして、プロセッサと、メモリと、一連のロジックと、プロセッサ、メモリ及び一連のロジックとを接続するインターフェースとを備える。一連のロジックは、ファイルのローカルコピーと関連付けられたメタデータを格納する第１ロジックと、ファイルのローカルコピーの最新のメタデータを格納するのを容易にするデータを、ピア・ツー・ピアメタデータキャッシュ環境に格納する第２ロジックと、ピア・ツー・ピアメタデータキャッシュ環境内で、ファイルのローカルコピーの最新のメタデータの場所を特定するのを容易にするデータを格納する第３ロジックと、ファイルのローカルコピーの最新のメタデータを取得する第４ロジックとを含む。

一実施形態において、ファイルのローカルコピーの最新のメタデータを、ピア・ツー・ピアメタデータキャッシュ環境に格納するのを容易にするべく、第２ロジックによって格納されるデータは、ピア・ツー・ピアメタデータキャッシュ環境内のどのメンバが、ファイルのローカルの最新のメタデータを有するかを知る役割、及び、ファイルのローカルコピーの最新のメタデータのコピーを格納する役割のうちの１以上を担う、ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定するデータを含む。

一実施形態では、第３ロジックは、ファイルとクライアントとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、ファイルのローカルコピーの最新のメタデータを有するピア・ツー・ピアメタデータキャッシュ環境のメンバを特定し、ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有するピア・ツー・ピアメタデータキャッシュ環境のメンバを一意的に特定する。

一実施形態では、第３ロジックは、ファイルのローカルコピーのファイル識別子にハッシュ関数を適用することにより生成されたハッシュ値を利用して、ファイルのローカルコピーの最新のメタデータを有するピア・ツー・ピアキャッシュ環境のメンバを特定できるピア・ツー・ピアキャッシュ環境のメンバを特定し、ハッシュ関数は、ファイル識別子の入力を受けてハッシュ値を出力し、ハッシュ値は、クライアント識別子、及び、クライアント識別子のリポジトリからクライアント識別子を特定する値、のうちの１つであり、クライアント識別子は、ピア・ツー・ピアメタデータキャッシュ環境のメンバを一意的に特定する。

一実施形態において、上記装置は、最新のメタデータを有するピア・ツー・ピアメタデータキャッシュ環境のメンバを、新規のメタデータで更新する第５ロジックを更に備える。

一実施形態では、上記装置は、最新のメタデータを有するピア・ツー・ピアメタデータキャッシュ環境のメンバを特定可能なピア・ツー・ピアメタデータキャッシュ環境のメンバを、新しいクライアント識別子で更新する第５ロジックを備える。

一実施形態において、上記装置は、ファイルのローカルコピーと関連付けられたメタデータ、及び、ファイルのローカルコピーのうちの１以上を、サーバに選択的に伝送する第６ロジックを更に備える。

一実施形態において、ピア・ツー・ピアメタデータキャッシュ環境は、ＮＦＳファイルサーバ及び一連のＮＦＳクライアントを含む。

一実施形態において、方法は、ピア・ツー・ピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからの、ＮＦＳサーバに対するメタデータリクエストをインターセプトする段階と、複数のピアからなるセットのメンバと通信を行って、複数のピアからなるセットによって維持される分散型メタデータキャッシュからのメタデータリクエストを満たす段階とを備える。

一実施形態において、方法は、メタデータを取得するリクエストを満たすこと、及び／又は、メタデータを更新するリクエストを満たすことを含む。

一実施形態において、メタデータリクエストを満たすべく、メタデータリクエストと関連付けられたファイル識別子に少なくとも一部基づいて、複数のピアのセット内の通信を行うメンバを特定する段階を備える。

方法の一実施形態は、複数のピアからなるセットの通信を行うメンバを特定する段階は、ピア識別子を取得可能なデータを取得するべく、メタデータリクエストと関連付けられたファイル識別子にハッシュ関数を適用することを含む。

一実施形態では、ファイルサーバから取得されたファイルのローカルコピーを格納するローカルメモリと、ファイルと関連付けられたメタデータのローカルコピーを格納するネットワーク接続ストレージと、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加するように装置を制御するプロセッサとを備え、ファイルのローカルコピーと関連付けられたメタデータリクエストは、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングを使用して満たされる。

従来のＮＦＳクライアント／サーバ環境を例示した図である。 分散型メタデータキャッシュ環境を例示した図である。 ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加するように構成された装置を例示した図である。 ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに関連する方法を例示した図である。 ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加するように構成された装置を例示した図である。 ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに関するハッシュ関数及びファイル単位データ構造を例示した図である。

本明細書に組み込まれその一部を構成する添付の図面には、様々なシステム、方法、及び、本開示のその他の実施形態が例示されている。図面に例示された要素の境界（例えば、ボックス、複数のボックスからなるグループ、又は、その他の形状）、一例に過ぎない。当業者であれば、ある例では、１つの要素が複数の要素として設計されたり、複数の要素が１つの要素として設計されたりしてもよいことが理解できる。また、別の要素の内部構成要素として示されている要素が、外部構成要素として実装されてもよいし、その反対であってもよい。更に、図面に示されている複数の要素は、必ずしも同じ縮尺で示されていない。

以下、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに関連する装置、方法及びその他の実施形態の例が記載される。装置及び方法の例は、分散型メタデータキャッシングを提供するのに役立つＮＦＳクライアント間のピア・ツー・ピア通信を提供する。分散型メタデータキャッシングは、従来の集中型制御及びリタイア／リフレッシュプロトコルによって生じる問題を緩和する。

装置及び方法の例では、ＮＦＳクライアントとやりとりを行う及び／又はＮＦＳクライアントを更新することができ、それにより、ＮＦＳクライアントは、メタデータに影響を与えるファイル操作毎に又はファイルにタッチする毎に、ＮＦＳサーバと自動的に通信を行う必要がなくなる。自動的にＮＦＳサーバへと通信を行うのではなく、ＮＦＳクライアントは、最初に、自身のキャッシュを調べる、及び／又は、ピアと通信を行って、存在する場合は、ＮＦＳクライアント自身を含め、どのピアがファイルの最新のメタデータを持っているかを発見する。発見したＮＦＳクライントが最新のメタデータを有し、最新のメタデータを有する役割を担っている場合には、別のＮＦＳクライアント又はＮＦＳサーバと通信を行う必要はない。ＮＦＳクライアントが、最新のメタデータを有しているが、別のＮＦＳクライアントが最新のメタデータを有する担当になっている場合、ＮＦＳクライアントは、別のＮＦＳクライアントに更新を行わせる必要がある場合がある。

一実施形態において、少なくとも１つのＮＦＳクライアントが、最新のメタデータを格納する役割を担う。別の実施形態では、２つ以上のＮＦＳクライアントが、最新のメタデータを格納する役割を担ってもよい。この場合、メタデータが重複して格納されることになる。一実施形態では、同様に、少なくとも１つのＮＦＳクライアントが、存在する場合には、どのＮＦＳクライアントがファイルの最新のメタデータを有するかを知る役割を担ってもよい。別の実施形態では、２つ以上のＮＦＳクライアントが、存在する場合には、どのＮＦＳクライアントがファイルについて最新のメタデータを有するかを知る役割を担ってもよい。この場合、最新のメタデータをどこで見つけることができるかについての情報の格納において、メタデータキャッシングが重複することとなる。従来では、ＮＦＳサーバのみが、どのメタデータが更新されたかを知っており、ＮＦＳサーバのみが最新のメタデータを有していた。最新のメタデータを格納する役割を分散させることにより、ＮＦＳサーバの負荷を低減させることができる。同様に、どのＮＦＳクライアントが最新のメタデータを有するかを知る役割を分散させることにより、ＮＦＳサーバの負荷を大幅に低減させることができる。しかしながら、これらの役割が、好適な数のＮＦＳクライアント間に適切に分散されない場合、負荷が、ＮＦＳサーバからＮＦＳクライアントに移動しただけになってしまう。

装置及び方法の例では、複数の参加ＮＦＳクライアント間の役割の分散のバランスをとることを試みてもよい。メタデータの格納の役割及び／又はどのクライアントが最新のメタデータを有しているかを知る役割を分散させるバランスをとる１つの方法として、ハッシュ関数を利用する方法がある。ハッシュ関数は、複数の参加ＮＦＳクライアント間で、ファイルについての役割の良好な（例えば、均一な、ガウス分布の）分散を生成するように設計されている。ハッシュ関数は、ＮＦＳサーバ及び複数のＮＦＳクライアントに知らされていてもよい。ファイル又はそのメタデータに影響を与える操作が実行されると、ファイル識別子がハッシュ関数に提供されてもよい。そして、ハッシュ関数は、メタデータを有するＮＦＳクライアント、及び／又は、どのクライアントがメタデータを有するか知る役割を担っているかを特定するのに使用可能な値を戻す。一実施形態において、この値は、ＮＦＳクライアント特定情報のリポジトリ（例えば、テーブル、アレイ）におけるインデックスとして使用されてもよい。別の実施形態では、この値は、ＮＦＳクライアント識別子であってもよい。

十分に多い数のファイル及び良好に設計されたハッシュ関数の場合には、役割の相対的に分散が均一になると考えられる。しかしながら、複数の参加ＮＦＳクライアントからなるセットに、ＮＦＳクライアントが追加される又は削除されると、ハッシュ関数及び／又はハッシュ値と利用可能なＮＦＳクライアント間のつながりを、更新する必要がある。したがって、別の実施形態では、役割分散のバランスをとる別の方法として、現在の分散の情報に基づいて役割を割り当て、ファイル毎のテーブルに役割のデータを格納する。ファイルがリクエストされると、ＮＦＳサーバ又は別のエンティティは、参加ＮＦＳクライアントにおける現在の役割分散を特定し、このファイルに関しての役割を選択されたＮＦＳクライアントに割り当てる。このような技術により、ＮＦＳクライアントにおけるファイルアクセスの都度にハッシュ関数を計算する手間を省けるが、固有のファイル毎のベースで分散させるアクションを実行させる新たな役割を導入する必要がある。

クライアント識別子を生成するのにハッシュ関数を使用すると、ファイル毎又はクライアント毎に情報を格納する付加メモリが必要なくなることを意味する。また、インデックス値を生成するのにハッシュ関数を使用すると、識別子とＮＦＳクライアントとを関連付けるＮＦＳクライアントそれぞれにつき１つのエントリを有するのに十分な付加ストレージが使用されることを意味する。ハッシュ関数を使用せずに、ファイル毎のベースで情報が格納される場合、各ＮＦＳクライアントは、自身が知るファイルについて、当該ファイルとＮＦＳクライアント間の相互関係を格納する。この方法は、メモリを多く使用するが、ファイル操作毎に、ハッシュ関数を実行する必要がなくなる。

図６には、異なる実施形態において、ロジック１４０が利用可能な、ハッシュ関数６１０とファイル単位データ構造（per file data structure）６２０の両方が示されている。ハッシュ関数６１０は、ファイルハンドルの入力を受け、クライアント識別子を出力することができる。一例では、ハッシュ関数６１０は、ファイルハンドルの入力を受け、クライアント識別子でポピュレートされたアレイのインデックスを出力する。ファイル単位データ構造６２０は、ファイル識別子及びクライアント識別子を格納してもよい。ロジック１４０がメタデータリクエストをインターセプトすると、ハッシュ関数６１０又はファイル単位データ構造６２０は、メタデータリクエストと関連付けられたファイルを特定し、メタデータリクエストに応えることが可能なピアについての情報を提供してもよい。

図２には、常にＮＦＳサーバ１３０と通信を行うのではなく、複数のＮＦＳクライアントが互いに通信を行って、メタデータに関する負荷の少なくとも一部を負担する分散型メタデータキャシュ環境が例示されている。図２には、ＮＦＳクライアント１１２が、ピア・ツー・ピア分散型メタデータキャッシュロジック１４０とやりとりをしている様子が示されており、ＮＦＳクライアント１２２がピア・ツー・ピア分散型メタデータキャッシュロジック１５０とやりとりをしている様子が示されている。図１では、メタデータリクエストが、ＮＦＳサーバ１３０に流される。図２では、メタデータリクエストが、ピア・ツー・ピア分散型メタデータキャッシュロジック１４０と、ピア・ツー・ピア分散型メタデータキャッシュロジック１５０との間に流される。

ピア・ツー・ピア通信メタデータキャッシュロジック１４０は、これに限定されないが、メタデータの格納、どこにメタデータを発見することができるかについての情報の格納、ＮＦＳサーバ１３０ではなく別のピアからのメタデータのリクエスト、ＮＦＳサーバ１３０以外でどこにメタデータを発見できるかについての情報の別のピアからのリクエスト、別のクライアントの別のロジックにそのロジックに格納されているメタデータを更新させる、別のクライアントの別のロジックにどこに最新のメタデータを発見できるかについての情報を更新させる等のアクションを含む、様々なアクションを行ってもよい。

図３には、分散型メタデータキャッシュ環境で動作し、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加するように構成された装置３００が例示されている。分散型メタデータキャッシングでは、複数のピアからなるセット内のメンバは、サーバから複数のピアのセットのメンバであるクライアントへとコピーされたファイルに対するメタデータを格納する負荷を分担する。メタデータは、複数のピアからなるセット内の１以上のメンバにキャッシュされていてもよい。メタデータがどこにキャッシュされているかについての情報は、ピアのセットの１以上のメンバに格納されていてもよい。最新のメタデータ及びこの最新のメタデータをどこに見つけることができるかについての情報をピアのメンバにおいて格納することは、ＮＦＳサーバとの通信の低減につながる。

装置３００は、プロセッサ３１０及びメモリ３２０を備え、更に、プロセッサ３１０、メモリ３２０及び一連のロジックを接続するインターフェース３３０を備える。一連のロジックとして、第１ロジック３４０、第２ロジック３４５、第３ロジック３５０、第４ロジック３５５、第５ロジック３６０、第６ロジック３６５及び第７ロジック３７０を含んでもよい。異なる実施形態では、ロジックは、分散型メタデータキャッシングをサポートする又は情報をやりとりすることに関連する異なるアクションを実行するよう構成されていてもよい。７個のロジックが図示されているが、これより多い数及び／又は少ない数のロジックを使用して、７個のロジックによって実行されるアクションを実行してもよい。一実施形態では、装置３００は、ＮＦＳサーバと情報をやりとりするＮＦＳクライアントであってもよい。ＮＦＳクライアント及びＮＦＳサーバについて説明がなされるが、以下に説明される分散型メタデータキャッシングは、その他のネットワークベースのファイルシステムに採用されてもよい。

一実施形態において、第１ロジック３４０は、メタデータを格納するように構成される。メタデータは、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加する複数のクライアントからなるセットと協働するサーバから取得されたファイルのローカルコピーに関連付けられている。複数のクライアントからなるセットは、ピアのセットとも称される。メタデータは、メモリ３２０、固体素子デバイス（ＳＳＤ）、及び／又は、装置３００が知り得る利用可能なその他のロケーションに格納されてもよい。メタデータは、装置３００によって格納されてもよいし、複数のクライアントのセット内の別の装置によって重複して格納されてもよい。一実施形態において、ファイルのローカルコピーは第１ロケーション（例えば、メモリ３２０）に格納され、メタデータは第２ロケーション（例えば、ＳＳＤ）に格納されてもよい。一般的に、第１ロジック３４０は、ファイルのローカルコピーと関連付けられたメタデータを格納し、第２ロジック３４５は、ピア・ツー・ピアメタデータキャッシュ環境におけるファイルのローカルコピーの最新のメタデータを格納するのを助けるデータを格納し、第３ロジック３５０は、ピア・ツー・ピアメタデータキャッシュ環境において、ファイルのローカルコピーの最新のメタデータの場所を特定するのに役立つデータを格納するように構成される。

第２ロジック３４５は、どのピアがファイルのローカルコピーの最新のメタデータを有するかを知る役割を担うメンバを、複数クライアントからなるセット内から特定するデータを格納するように構成されてもよい。第２ロジック３４５はまた、どのピアがファイルのローカルコピーの最新のメタデータのコピーを格納する役割を担うメンバを、複数クライアントからなるセット内から特定するデータを格納するように構成されてもよい。この場合、第２ロジック３４５は、どこに最新のメタデータが位置しているかについての情報を格納してもよく、及び／又は、どのクライアントが最新のメタデータの場所を知っているかについての情報を格納してもよい。このような情報を格納することにより、メタデータリクエストがなされた時に、ＮＦＳサーバに問い合わせる必要がなくなる。先に記したように、従来のシステムにおいては、このようなＮＦＳサーバとの通信は、ボトルネックとなる。

第３ロジック３５０は、ファイルのローカルコピーに対する最新のメタデータを有するメンバを、複数のクライアントからなるセット内から特定するように構成されてもよい。特定は、第２ロジック３４５が格納するデータからなされてもよい。第３ロジック３５０は、ファイルのローカルコピーに対する最新のメタデータを有するメンバを複数のクライアントからなるセット内から特定することができるメンバを特定するように構成されてもよい。特定は、第２ロジック３４５が格納するデータからなされてもよい。第３ロジック３５０は、様々な方法でクライアントを特定可能であってもよく、これに限定されないが、例えば、メタデータが属するファイルと関連付けられたファイル識別子にハッシュ関数を適用し、クライアント識別子のレポジトリ（例えば、アレイ、テーブル、ファイル）からクライアント識別子を取得してもよい。

第４ロジック３５５は、ファイルのローカルコピーに対する最新のメタデータを取得するように構成されてもよい。第４ロジック３５５は、第３ロジック３５０によって実行される上記の特定を利用して、最新のメタデータを取得してもよい。一例では、装置３００自身が、最新のメタデータを有する役割を担う場合には、第４ロジック３５５は、装置３００から最新のメタデータを取得してもよい。別の例では、異なるクライアントが、最新のメタデータを有する役割を担う場合には、第４ロジック３５５は、複数のクライアントからなるセットのメンバからメタデータを取得するリクエストを送信する必要がある場合がある。しかしながら、第４ロジック３５５は、直接情報をリクエストすることができず、最初に、最新のメタデータを有する役割を担うクライアントを特定する必要がある場合がある。

一実施形態において、第３ロジック３５０は、ファイルのローカルコピーの最新のメタデータを有するメンバをクライアントのセットから、ハッシュ関数をファイルのローカルコピーのファイル識別子に適用することによって生成されるハッシュ値の関数として特定するように構成されてもよい。ハッシュ値は、例えば、クライアント識別子であってもよく、クライアント識別子のレポジトリからクライアント識別子の位置を特定するのに使用されてもよい。レポジトリは、１エントリにつき、１以上のクライアント識別子を格納してもよく、また、ハッシュ値を使用してインデックスを付与してもよい。一例では、ハッシュ値が、クライアント識別子が発見されない空のエントリを指す場合には、装置３００は、所望の情報を取得するべくＮＦＳサーバに戻ってもよい。上記では、ハッシュ関数について記載されたが、その他の数学的又はアルゴリズム的方法を採用して、ファイル識別子からクライアントを特定してもよい。

別の実施形態では、第３ロジック３５０は、ファイルとクライアントを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、ファイルのローカルコピーの最新のメタデータを有するメンバを、クライアントのセットから特定するように構成されてもよい。一例では、ファイルについて責任を有する複数クライアントからなるセットのメンバとして、ファイル単位データ構造がポピュレートされてもよい。別の例では、ファイル単位データ構造は、ＮＦＳサーバによってポピュレートされてもよい。ファイル単位データ構造は、負荷のバランスをとるように操作されてもよい。

一実施形態では、第３ロジック３５０は、ファイルのローカルコピーの最新のメタデータを有するメンバをクライアントのセットから特定可能なメンバを、ファイルのローカルコピーのファイル識別子にハッシュ関数を適用することによって生成されたハッシュ値の関数として、特定するよう構成されてもよい。ここで、ハッシュ値は、クライアント識別子であってもよいし、クライアント識別子のレポジトリからクライアント識別子を特定するのに使用されてもよい。

図６には、ハッシュ関数６１０、及び、ピア・ツー・ピア分散型メタデータキャッシュロジック１４０と情報のやりとりを行うファイル単位データ構造６２０が例示されている。第３ロジック３５０は、ハッシュ関数６１０及びファイル単位データ構造を同様に採用してもよい。第３ロジック３５０は、様々な方法でクライアントを特定可能であってもよく、これに限定されないが、例えば、メタデータが属するファイルと関連付けられたファイル識別子にハッシュ関数を適用し、クライアント識別子のレポジトリ（例えば、アレイ、テーブル、ファイル）からクライアント識別子を取得し、クライントとファイルとを相関付けている情報を格納するファイル単位データ構造にアクセスすることによって、クライアントを特定してもよい。ファイル単位データ構造は、ファイル識別子及びクライアント識別子を格納してもよい。

一実施形態において、第５ロジック３６０は、複数のクライアントからなるセット内の最新のメタデータを有するメンバを、新規のメタデータで更新するよう構成される。装置３００が最新のメタデータを有するが、複数のクライアントからなるセット内の別のメンバが、最新のメタデータを有することになっている、又は、どのメンバが最新のメタデータを有するか知っているべきである、と判断された場合には、第５ロジック３６０は、そのメンバにメタデータを提供してもよい。更に及び／又はこれに替えて、第５ロジック３６０は、複数のクライアントからなるセットから最新のメタデータを有するメンバを特定することができるメンバを、装置３００を特定するのに十分な新規のクライアント識別子で更新するよう構成されてもよい。

一実施形態において、第６ロジック３６５は、選択的にサーバと通信するよう構成されてもよい。第６ロジック３６５は、ファイルのローカルコピーと関連付けられたメタデータを伝達するように構成されていてもよい。この構成は、ピア・ツー・ピアネットワークの応答時間が所望の閾値を下回る場合に採用されてもよい。一定期間が経過した後で、分散型メタデータキャッシングに何が起こったかをＮＦＳサーバに知らせるのが適切である場合、上記の構成をバックアップ又は安全策として採用してもよい。最新のメタデータ及び最新のファイルを有する最終的な責任はＮＦＳサーバにあるので、第６ロジック３６５は、ファイルのローカルコピーをＮＦＳサーバに伝達してもよい。

一実施形態において、第７ロジック３７０は、サーバに宛てられたＮＦＳ ＧｅｔＡｔｔｒコールを傍受すると、サーバではなく、複数のクライアントからなるセットのうちの一メンバと選択的に通信を行う。ＮＦＳ ＧｅｔＡｔｔｒコールは、前に取得されたファイルハンドルによって特定されたファイルのファイル属性をリクエストする機能である。キャッシングメタデータは、ＮＦＳ ＧｅｔＡｔｔｒコールをローカルに傍受することを可能とし、ＮＦＳサーバまで戻って問い合わせることなく、ファイルの属性を提供可能とする。第７ロジック３７０は、サーバに宛てられたＮＦＳ ＳｅｔＡｔｔｒコールを傍受すると、サーバではなく、複数のクライアントからなるセットのうちの一メンバと選択的に通信を行うように構成されてもよい。ＮＦＳ ＳｅｔＡｔｔｒコールは、前に取得されたファイルハンドルによって特定されたファイルのファイル属性を更新する機能である。そして、メタデータをキャッシングすることにより、ＮＦＳ ＳｅｔＡｔｔｒコールをローカルにインターセプトすることを可能とし、ＮＦＳサーバまで戻ることなく、ファイル属性を更新することが可能となる。したがって、一実施形態では、第７ロジック３７０は、ＮＦＳクライアントとＮＦＳサーバとの間に物理的及び／又は論理的に挿入されていてもよい。このようにすることで、既存の構成に、上記の分散型メタデータキャッシングを組み込むことが容易になる。

図４には、ピア・ツー・ピア通信ベースの分散型メタデータキャッシングと関連付けられた方法４００が示されている。方法４００は、４１０において、複数のピアからなるセットと共に、ピア・ツー・ピア分散型メタデータキャッシングに参加するＮＦＳクライアントを制御して、ＮＦＳサーバ宛のメタデータリクエストをインターセプトする段階を備える。メタデータリクエストは、最新のメタデータを要求するものであってもよいし、更新されたメタデータについての情報を提供するものであってもよい。

方法４００は、４２０において、メタデータリクエストを満たすべく通信を行う、複数のピアからなるセットのメンバを特定する段階を備える。メンバは、少なくとも一部、メタデータリクエストと関連付けられたファイル識別子に基づいて特定されてもよい。一実施形態において、複数のピアからなるセット内から、通信を行うメンバを特定する段階は、メタデータリクエストに関連付けられたファイル識別子にハッシュ関数を適用して、ピア識別子を取得可能なデータを取得することを伴う。別の実施形態では、複数のピアからなるセット内から、通信を行うメンバを特定する段階は、ファイルとこれらファイルの担当になっているクライアントとを相関付ける情報を格納しているファイル単位データ構造への問い合わせを伴ってもよい。

方法４００はまた、段階４３０において、複数のピアからなるセットによって維持される分散型メタデータキャッシュからのメタデータリクエストを満たすべく、ＮＦＳクライアントを制御する段階を備える。メタデータリクエストは、ＮＦＳサーバに送信されず、複数のピアからなるセット内のメンバと通信を行うことによってリクエストが満たされる。一実施形態において、メタデータリクエストを満たす段階は、メタデータを取得するリクエストを満たすことを含む。更に及び／又はこれに替えて、メタデータリクエストを満たす段階は、メタデータを更新するリクエストを満たすことを含んでよい。

一実施形態において、方法４００はまた、複数のピアからなるセット内の異なるメンバにおいて格納されているファイルのローカルコピーに対する現在のメタデータを格納するべく、ＮＦＳクライアントを制御する段階を備える。これは、方法４００を実装する装置が、ファイルの最新のメタデータを維持する役割を担当している場合に生じると考えられる。方法４００はまた、複数のピアからなるセット内の異なるメンバにおいて格納されているファイルのローカルコピーの現在のメタデータを有するメンバを特定するのに十分なデータを格納するべく、ＮＦＳクライアントを制御する段階を備える。これは、方法４００を実行する装置が、最新のメタデータを有し、別の装置が、どの装置が最新のメタデータを有するかを知る役割になっている場合に考えられる。

図５には、ピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０に参加するよう構成された装置５００が例示されている。装置５００は、ピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０に参加するべく、装置５００を制御するよう構成されプロセッサ５１０を備える。分散型メタデータキャッシングは、自動的にメタデータ情報をサーバに取りに行くのではなく、ピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０を利用して、ファイルのローカルコピーと関連付けられたメタデータリクエストを扱うことを伴う。

装置５００はまた、ファイルサーバから取得されたファイルのローカルコピーを格納するよう構成されたローカルメモリ５２０を備える。装置５００はまた、ファイルと関連付けられたメタデータのローカルコピーを格納するよう構成されたネットワーク接続ストレージ（ＮＡＳ）５３０を備える。上記では、ファイルのローカルコピーを格納するのにローカルメモリ５２０が記載されたが、ローカルコピーは、装置５００が利用可能なその他の記憶装置に格納されてもよいことは明らかである。同様に、メタデータを格納するのにＮＡＳ５３０が説明されたが、メタデータは、装置５００が利用可能なその他の記憶装置に格納されてもよいことは明らかである。

一実施形態において、プロセッサ５１０は、ファイルのローカルコピーの現在のメタデータを格納するように構成される。プロセッサ５１０は、ローカルメモリ５２０及び／又はＮＡＳ５３０に、現在のメタデータを格納してもよい。プロセッサ５１０はまた、ピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０に参加する異なる装置に格納された異なるファイルのローカルコピーに対する現在のメタデータを格納するように構成されてもよい。プロセッサ５１０は、ローカルメモリ５２０及び／又はＮＡＳ５３０に、現在のメタデータを格納してもよい。プロセッサ５２０は、ファイルのローカルコピーに対する現在のメタデータを有するピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０に参加する装置を特定するのに十分な情報を格納するように構成されてもよい。プロセッサ５１０は、ローカルメモリ５２０及び／又はＮＡＳ５３０に情報を格納してもよい。プロセッサ５２０は、ピア・ツー・ピア通信ベースの分散型メタデータキャッシング５３０に参加する異なる装置に格納されている異なるファイルのローカルコピーの現在のメタデータを有する装置を特定するのに十分な情報を格納するように構成されてもよい。また、プロセッサ５１０は、この情報を、ローカルメモリ５２０及び／又はＮＡＳ５３０に格納してもよい。

以下に、本明細書で使用された用語の定義について記す。定義は、言葉の範囲内に含まれ、実装に使用されてもよい様々な例及び／又は形態を含む。例は、以下に列挙するものに限定されない。また、用語の単数形及び複数形は、定義の内に含まれる。

"一実施形態"、"ある実施形態"、"一例"、"ある例"等の言葉は、記載される実施形態又は例が、特定の特徴、構造、性質又は特性を含むことを示唆するが、必ずしも全ての実施形態又は例が、これら特定の特徴、構造、性質又は特性を含むことを意味しない。また、"一実施形態では"という言葉が繰り返し使用されるが、これは必ずしも、同じ実施形態を指してるわけではない。

本明細書で使用される"ロジック"という言葉は、これに限定されないが、ハードウェア、ファームウェア、非一時的媒体に格納される命令又は機械で実行される命令、及び／又は、別のロジック、方法及び／又はシステムからの機能又は動作を引き起こす及び／又は機能又は動作を実行するこれらの組み合わせを含む。ロジックは、ソフトウェア制御マイクロプロセッサ、ディスクリートロジック（例えば、ＡＳＩＣ）、アナログ回路、デジタル回路、プログラムされたロジックデバイス、命令を含むメモリデバイス等を含む。ロジックは、１以上のゲート、ゲートの組み合わせ、そのほかの回路構成要素を含んでもよい。複数のロジックについて記載される場合であっても、複数のロジックを１つの物理的ロジックに組み込むことが可能である。同様に、１つのロジックが記載されている場合であっても、１つのロジックを、物理的に複数のロジック間で分担させることが可能である。本明細書に記載された構成要素及び機能の１以上が、ロジック要素の１以上を使用して実装されてもよい。

説明を単純にするために、例示の方法は、一連のブロック図で示されている。方法は、ブロックの順番に限定されず、一部のブロックが、説明されたのとは、異なる順番で発生してもよい及び／又はその他のブロックと同時に発生してもよい。更に、例示された複数のブロックの全てよりも少ないブロックを使用して、例示した方法が実装されてもよい。複数のブロックが、組み合わせられてもよいし、複数の構成要素に分割されてもよい。また、更なる及び／又は代替の方法では、図示されていないブロックを更に採用してもよい。

詳細な説明又は特許請求の範囲で使用されている"含む（includes or including）"という言葉は、特許請求の範囲を記載する際に使用される移行句"備える（comprising）"と同様な態様で、要素を包括することを意図して使用されている。

システム及び方法等の例が、複数の例を挙げて、数多くの詳細事項と共に説明されたが、本願は、このような詳細事項によって、添付の特許請求の範囲が制限されることを意図していない。無論、本明細書に記載するシステム、方法等を説明する目的で、構成要素又は方法の考え得る全ての組み合わせを記載するのは不可能である。したがって、本開示は、特定の詳細事項に限定されず、図示及び説明された代表的装置及び例に限定されない。したがって、本願は、添付の特許請求の範囲内において、変更、改良及び変形を含むことを意図している。

Claims (31)

1. ピア・ツー・ピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからのネットワークファイルシステム（ＮＦＳ）サーバに対するメタデータリクエストを、コンピュータでインターセプトする段階と、
   ファイルと前記複数のピアからなる前記セットの１以上のメンバとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記メタデータリクエストを満たすべく、前記複数のピアからなる前記セットの通信を行う対象の前記メンバを特定するように前記コンピュータを制御する段階と、
   前記複数のピアからなる前記セットの特定されたメンバと通信を行って、前記複数のピアからなる前記セットによって維持される分散型メタデータキャッシュからの前記メタデータリクエストを満たす段階とを備え、
   前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
   前記関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有する前記複数のピアからなる前記セットの前記メンバを一意的に特定する
   方法。
2. 前記複数のピアからなる前記セットの前記特定されたメンバと通信を行って、前記メタデータリクエストを満たす段階は、
   メタデータを取得するリクエストを満たすこと、及び、メタデータを更新するリクエストを満たすことのうちの１以上を含む請求項１に記載の方法。
3. 前記メタデータリクエストを満たすべく、前記メタデータリクエストと関連付けられたファイル識別子に少なくとも一部基づいて、前記複数のピアからなる前記セットの通信を行う対象のメンバを特定する段階を備える請求項１に記載の方法。
4. 前記複数のピアからなる前記セットの前記通信を行う対象のメンバを特定する段階は、
   ピア識別子を取得可能なデータを取得するべく、前記メタデータリクエストと関連付けられた前記ファイル識別子にハッシュ関数を適用することを含む請求項３に記載の方法。
5. 前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータ、及び、前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータを有する前記複数のピアからなる前記セットのメンバを特定するのに十分な情報のうちの１以上を格納するように、前記コンピュータを制御する段階を備える請求項１から４の何れか一項に記載の方法。
6. 前記複数のピアからなる前記セットのメンバの現在の役割を特定し、
   前記複数のピアからなる前記セットのメンバから第２のメンバを選択し、
   選択されたファイルに対する役割を前記第２のメンバに割り当てる
   段階を更に備える請求項１に記載の方法。
7. 分散型ピア・ツー・ピアメタデータキャッシュ環境で動作する装置であって、
   プロセッサと、
   メモリと、
   一連のロジックと、
   前記プロセッサ、前記メモリ及び前記一連のロジックとを接続するインターフェースとを備え、
   前記一連のロジックは、
   ファイルのローカルコピーと関連付けられたメタデータを格納する第１ロジックと、
   前記ピア・ツー・ピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの最新のメタデータを格納するのを容易にするデータを格納する第２ロジックと、
   前記ピア・ツー・ピアメタデータキャッシュ環境内における前記ファイルの前記ローカルコピーの前記最新のメタデータの場所を特定するのを容易にするデータを格納する第３ロジックと、
   前記ファイルの前記ローカルコピーの前記最新のメタデータを取得する第４ロジックとを含み、
   前記第３ロジックは、ファイルとクライアントとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定し、
   前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
   前記関連するクライアント識別子は、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境の前記メンバを一意的に特定する装置。
8. 前記ピア・ツー・ピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの前記最新のメタデータを格納するのを容易にするべく、前記第２ロジックによって格納される前記データは、
   前記ピア・ツー・ピアメタデータキャッシュ環境内のどのメンバが、前記ファイルの前記ローカルコピーの前記最新のメタデータを有するかを知る役割、及び、前記ファイルの前記ローカルコピーの前記最新のメタデータのコピーを格納する役割のうちの１以上を担う、前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定するデータを含む請求項７に記載の装置。
9. 前記ピア・ツー・ピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの前記最新のメタデータの場所を特定するのを容易にするべく、前記第３ロジックによって格納される前記データは、
   前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバ、及び、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境の前記メンバを特定可能な前記ピア・ツー・ピアメタデータキャッシュ環境のメンバのうちの１以上を特定するデータを含む請求項７又は８に記載の装置。
10. 前記第３ロジックは、前記ファイルの前記ローカルコピーのファイル識別子にハッシュ関数を適用することにより生成されたハッシュ値を利用して、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定し、
    前記ハッシュ関数は、前記ファイル識別子の入力を受けて前記ハッシュ値を出力し、
    前記ハッシュ値は、クライアント識別子、及び、クライアント識別子のリポジトリからクライアント識別子を特定する値、のうちの１つであり、
    前記クライアント識別子は、前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを一意的に特定する請求項７に記載の装置。
11. 前記第３ロジックは、ファイル識別子にハッシュ関数を適用することにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定し、
    前記ハッシュ関数は、クライアント識別子のアレイのインデックスを算出し、
    前記クライアント識別子のアレイは、前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを一意的に特定する識別子を格納する請求項８に記載の装置。
12. 前記第３ロジックは、前記ファイルの前記ローカルコピーのファイル識別子にハッシュ関数を適用することにより生成されたハッシュ値を利用して、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定できる前記ピア・ツー・ピアメタデータキャッシュ環境の前記メンバを特定し、
    前記ハッシュ関数は、前記ファイル識別子の入力を受けて前記ハッシュ値を出力し、
    前記ハッシュ値は、クライアント識別子、及び、クライアント識別子のリポジトリからクライアント識別子を特定する値、のうちの１つであり、
    前記クライアント識別子は、前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを一意的に特定する請求項７に記載の装置。
13. 前記第３ロジックは、ファイル識別子にハッシュ関数を適用することにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定できる前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定し、
    前記ハッシュ関数は、クライアント識別子のアレイのインデックスを算出し、
    前記クライアント識別子のアレイは、前記ピア・ツー・ピアメタデータキャッシュ環境の複数のメンバを一意的に特定する識別子を格納する請求項７に記載の装置。
14. 前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを、新しいメタデータで更新する第５ロジックを更に備える請求項７から１３の何れか一項に記載の装置。
15. 前記最新のメタデータを有する前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを特定可能な前記ピア・ツー・ピアメタデータキャッシュ環境のメンバを、新しいクライアント識別子で更新する第５ロジックを更に備える請求項７から１３の何れか一項に記載の装置。
16. 前記ファイルの前記ローカルコピーと関連付けられたメタデータ、及び、前記ファイルの前記ローカルコピーのうちの１以上を、サーバに選択的に伝送する第６ロジックを更に備える請求項７から１５の何れか一項に記載の装置。
17. サーバは、ＮＦＳファイルサーバであり、
    一連のクライアントは、ＮＦＳクライアントである請求項７から１６の何れか一項に記載の装置。
18. サーバ宛のＮＦＳ ＧｅｔＡｔｔｒコール、及び、前記サーバ宛のＮＦＳ ＳｅｔＡｔｔｒコールのうちの１以上をインターセプトした場合に、
    前記サーバではなく、前記ピア・ツー・ピアメタデータキャッシュ環境のメンバと選択的に通信を行う第７ロジックを更に備える請求項７から１７の何れか一項に記載の装置。
19. 前記ピア・ツー・ピアメタデータキャッシュ環境のメンバの現在の役割を特定し、
    前記ピア・ツー・ピアメタデータキャッシュ環境のメンバから第２のメンバを選択し、
    選択されたファイルに対する役割を前記第２のメンバに割り当てる
    第８ロジックを更に備える請求項７から１８の何れか一項に記載の装置。
20. ファイルサーバから取得されたファイルのローカルコピーを格納するローカルメモリと、
    前記ファイルと関連付けられたメタデータのローカルコピーを格納するネットワーク接続ストレージと、
    ピア・ツー・ピア通信ベースの分散型メタデータキャッシングに参加するように装置を制御するプロセッサとを備え、
    前記ファイルの前記ローカルコピーと関連付けられたメタデータリクエストは、前記ピア・ツー・ピア通信ベースの分散型メタデータキャッシングを使用して満たされ、
    前記プロセッサは、ファイルとクライアントとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する複数のピアからなるセットのメンバを特定し、
    前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
    前記関連するクライアント識別子は、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記複数のピアからなる前記セットのメンバを一意的に特定する
    装置。
21. 前記プロセッサは、前記複数のピアからなる前記セットのメンバの現在の役割を特定し、
    前記複数のピアからなる前記セットのメンバから第２のメンバを選択し、
    選択されたファイルに対する役割を前記第２のメンバに割り当てる
    請求項２０に記載の装置。
22. コンピュータを、
    ピア・ツー・ピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからのネットワークファイルシステム（ＮＦＳ）サーバに対するメタデータリクエストを、コンピュータでインターセプトする段階と、
    ファイルと前記複数のピアからなる前記セットの１以上のメンバとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記メタデータリクエストを満たすべく、前記複数のピアからなる前記セットの通信を行う対象の前記メンバを特定するように前記コンピュータを制御する段階と、
    前記複数のピアからなる前記セットの特定されたメンバと通信を行って、前記複数のピアからなる前記セットによって維持される分散型メタデータキャッシュからの前記メタデータリクエストを満たす段階とを備え、
    前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
    前記関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有する前記複数のピアからなる前記セットの前記メンバを一意的に特定する
    ように機能させるためのプログラム。
23. 前記複数のピアからなる前記セットの前記特定されたメンバと通信を行って、前記メタデータリクエストを満たす段階は、
    メタデータを取得するリクエストを満たすこと、及び、メタデータを更新するリクエストを満たすことのうちの１以上を含む請求項２２に記載のプログラム。
24. 前記メタデータリクエストを満たすべく、前記メタデータリクエストと関連付けられたファイル識別子に少なくとも一部基づいて、前記複数のピアからなる前記セットの通信を行う対象のメンバを特定するように機能させるための請求項２２に記載のプログラム。
25. 前記複数のピアからなる前記セットの前記通信を行う対象のメンバを特定する段階は、
    ピア識別子を取得可能なデータを取得するべく、前記メタデータリクエストと関連付けられた前記ファイル識別子にハッシュ関数を適用することを含む請求項２４に記載のプログラム。
26. 前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータ、及び、前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータを有する前記複数のピアからなる前記セットのメンバを特定するのに十分な情報のうちの１以上を格納するように機能させるための請求項２２に記載のプログラム。
27. ピア・ツー・ピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからのネットワークファイルシステム（ＮＦＳ）サーバに対するメタデータリクエストを、コンピュータでインターセプトする段階と、
    ファイルと前記複数のピアからなる前記セットの１以上のメンバとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記メタデータリクエストを満たすべく、前記複数のピアからなる前記セットの通信を行う対象の前記メンバを特定するように前記コンピュータを制御する段階と、
    前記複数のピアからなる前記セットの特定されたメンバと通信を行って、前記複数のピアからなる前記セットによって維持される分散型メタデータキャッシュからの前記メタデータリクエストを満たす段階とを備え、
    前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
    前記関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有する前記複数のピアからなる前記セットの前記メンバを一意的に特定し、
    前記複数のピアからなる前記セットの前記特定されたメンバと通信を行って、前記メタデータリクエストを満たす段階は、メタデータを取得するリクエストを満たすこと、及び、メタデータを更新するリクエストを満たすことのうちの１以上を含む
    システム。
28. 前記メタデータリクエストを満たすべく、前記メタデータリクエストと関連付けられたファイル識別子に少なくとも一部基づいて、前記複数のピアからなる前記セットの通信を行う対象のメンバを特定する段階を備える請求項２７に記載のシステム。
29. 前記複数のピアからなる前記セットの前記通信を行う対象のメンバを特定する段階は、
    ピア識別子を取得可能なデータを取得するべく、前記メタデータリクエストと関連付けられた前記ファイル識別子にハッシュ関数を適用することを含む請求項２８に記載のシステム。
30. 前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータ、及び、前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータを有する前記複数のピアからなる前記セットのメンバを特定するのに十分な情報のうちの１以上を格納するように、前記コンピュータを制御する段階を備える請求項２７に記載のシステム。
31. ピア・ツー・ピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからのネットワークファイルシステム（ＮＦＳ）サーバに対するメタデータリクエストを、コンピュータでインターセプトするよう構成されたインターセプトロジックと、
    ファイルと前記複数のピアからなる前記セットの１以上のメンバとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記メタデータリクエストを満たすべく、前記複数のピアからなる前記セットの通信を行う対象の前記メンバを特定するように前記コンピュータを制御し、前記複数のピアからなる前記セットの特定されたメンバと通信を行って、前記複数のピアからなる前記セットによって維持される分散型メタデータキャッシュからの前記メタデータリクエストを満たすよう構成された通信ロジックと、
    を備え、
    前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、
    前記関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有する前記複数のピアからなる前記セットの前記メンバを一意的に特定する
    システム。

Images