ピアツーピア分散型メタデータキャッシングに参加する複数のピアからなるセットのメンバからのネットワークファイルシステムNFSサーバに対するメタデータリクエストを、コンピュータでインターセプトする段階と、前記複数のピアからなる前記セットのメンバと通信を行って、前記複数のピアからなる前記セットによって維持される分散型メタデータキャッシュからの前記メタデータリクエストを満たす段階とを備える方法。前記メタデータリクエストを満たす段階は、メタデータを取得するリクエストを満たすこと、及び、メタデータを更新するリクエストを満たすことのうちの1以上を含む請求項1に記載の方法。前記メタデータリクエストを満たすべく、前記メタデータリクエストと関連付けられたファイル識別子に少なくとも一部基づいて、前記複数のピアからなる前記セットの通信を行う対象のメンバを特定する段階を備える請求項1に記載の方法。前記複数のピアからなる前記セットの前記通信を行う対象のメンバを特定する段階は、ピア識別子を取得可能なデータを取得するべく、前記メタデータリクエストと関連付けられた前記ファイル識別子にハッシュ関数を適用することを含む請求項3に記載の方法。前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータ、及び、前記複数のピアからなる前記セットの異なるメンバに格納されているファイルのローカルコピーの現在のメタデータを有する前記複数のピアからなる前記セットのメンバを特定するのに十分な情報のうちの1以上を格納するように、前記コンピュータを制御する段階を備える請求項1から4の何れか一項に記載の方法。ファイルと前記複数のピアからなる前記セットの1以上のメンバとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記メタデータリクエストを満たすべく、前記複数のピアからなる前記セットの通信を行う対象の前記メンバを特定するように前記コンピュータを制御する段階を備え、前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、前記関連するクライアント識別子は、ファイルのローカルコピーの最新のメタデータを有する前記複数のピアからなる前記セットの前記メンバを一意的に特定する請求項1から4の何れか一項に記載の方法。分散型ピアツーピアメタデータキャッシュ環境で動作する装置であって、プロセッサと、メモリと、一連のロジックと、前記プロセッサ、前記メモリ及び前記一連のロジックとを接続するインターフェースとを備え、前記一連のロジックは、ファイルのローカルコピーと関連付けられたメタデータを格納する第1ロジックと、前記ピアツーピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの最新のメタデータを格納するのを容易にするデータを格納する第2ロジックと、前記ピアツーピアメタデータキャッシュ環境内における前記ファイルの前記ローカルコピーの前記最新のメタデータの場所を特定するのを容易にするデータを格納する第3ロジックと、前記ファイルの前記ローカルコピーの前記最新のメタデータを取得する第4ロジックとを含む装置。前記ピアツーピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの前記最新のメタデータを格納するのを容易にするべく、前記第2ロジックによって格納される前記データは、前記ピアツーピアメタデータキャッシュ環境内のどのメンバが、前記ファイルの前記ローカルコピーの前記最新のメタデータを有するかを知る役割、及び、前記ファイルの前記ローカルコピーの前記最新のメタデータのコピーを格納する役割のうちの1以上を担う、前記ピアツーピアメタデータキャッシュ環境のメンバを特定するデータを含む請求項7に記載の装置。前記ピアツーピアメタデータキャッシュ環境における前記ファイルの前記ローカルコピーの前記最新のメタデータの場所を特定するのを容易にするべく、前記第3ロジックによって格納される前記データは、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバ、及び、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境の前記メンバを特定可能な前記ピアツーピアメタデータキャッシュ環境のメンバのうちの1以上を特定するデータを含む請求項7又は8に記載の装置。前記第3ロジックは、前記ファイルの前記ローカルコピーのファイル識別子にハッシュ関数を適用することにより生成されたハッシュ値を利用して、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定し、前記ハッシュ関数は、前記ファイル識別子の入力を受けて前記ハッシュ値を出力し、前記ハッシュ値は、クライアント識別子、及び、クライアント識別子のリポジトリからクライアント識別子を特定する値、のうちの1つであり、前記クライアント識別子は、前記ピアツーピアメタデータキャッシュ環境のメンバを一意的に特定する請求項7に記載の装置。前記第3ロジックは、ファイル識別子にハッシュ関数を適用することにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定し、前記ハッシュ関数は、クライアント識別子のアレイのインデックスを算出し、前記クライアント識別子のアレイは、前記ピアツーピアメタデータキャッシュ環境のメンバを一意的に特定する識別子を格納する請求項8に記載の装置。前記第3ロジックは、ファイルとクライアントとを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定し、前記ファイル単位データ構造は、ファイル識別子及び関連するクライアント識別子を格納し、前記関連するクライアント識別子は、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境の前記メンバを一意的に特定する請求項7又は8に記載の装置。前記第3ロジックは、前記ファイルの前記ローカルコピーのファイル識別子にハッシュ関数を適用することにより生成されたハッシュ値を利用して、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定できる前記ピアツーピアメタデータキャッシュ環境の前記メンバを特定し、前記ハッシュ関数は、前記ファイル識別子の入力を受けて前記ハッシュ値を出力し、前記ハッシュ値は、クライアント識別子、及び、クライアント識別子のリポジトリからクライアント識別子を特定する値、のうちの1つであり、前記クライアント識別子は、前記ピアツーピアメタデータキャッシュ環境のメンバを一意的に特定する請求項7に記載の装置。前記第3ロジックは、ファイル識別子にハッシュ関数を適用することにより、前記ファイルの前記ローカルコピーの前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定できる前記ピアツーピアメタデータキャッシュ環境のメンバを特定し、前記ハッシュ関数は、クライアント識別子のアレイのインデックスを算出し、前記クライアント識別子のアレイは、前記ピアツーピアメタデータキャッシュ環境の複数のメンバを一意的に特定する識別子を格納する請求項7に記載の装置。前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを、新しいメタデータで更新する第5ロジックを更に備える請求項7から14の何れか1項に記載の装置。前記最新のメタデータを有する前記ピアツーピアメタデータキャッシュ環境のメンバを特定可能な前記ピアツーピアメタデータキャッシュ環境のメンバを、新しいクライアント識別子で更新する第5ロジックを更に備える請求項7から14の何れか一項に記載の装置。前記ファイルの前記ローカルコピーと関連付けられたメタデータ、及び、前記ファイルの前記ローカルコピーのうちの1以上を、サーバに選択的に伝送する第6ロジックを更に備える請求項7から16の何れか一項に記載の装置。サーバは、NFSファイルサーバであり、一連のクライアントは、NFSクライアントである請求項7から17の何れか一項に記載の装置。サーバ宛のNFSGetAttrコール、及び、前記サーバ宛のNFSSetAttrコールのうちの1以上をインターセプトした場合に、前記サーバではなく、前記ピアツーピアメタデータキャッシュ環境のメンバと選択的に通信を行う第7ロジックを更に備える請求項7から18の何れか一項に記載の装置。ファイルサーバから取得されたファイルのローカルコピーを格納するローカルメモリと、前記ファイルと関連付けられたメタデータのローカルコピーを格納するネットワーク接続ストレージと、ピアツーピア通信ベースの分散型メタデータキャッシングに参加するように装置を制御するプロセッサとを備え、前記ファイルの前記ローカルコピーと関連付けられたメタデータリクエストは、前記ピアツーピア通信ベースの分散型メタデータキャッシングを使用して満たされる装置。本明細書に組み込まれその一部を構成する添付の図面には、様々なシステム、方法、及び、本開示のその他の実施形態が例示されている。図面に例示された要素の境界例えば、ボックス、複数のボックスからなるグループ、又は、その他の形状、一例に過ぎない。当業者であれば、ある例では、1つの要素が複数の要素として設計されたり、複数の要素が1つの要素として設計されたりしてもよいことが理解できる。また、別の要素の内部構成要素として示されている要素が、外部構成要素として実装されてもよいし、その反対であってもよい。更に、図面に示されている複数の要素は、必ずしも同じ縮尺で示されていない。以下、ピアツーピア通信ベースの分散型メタデータキャッシングに関連する装置、方法及びその他の実施形態の例が記載される。装置及び方法の例は、分散型メタデータキャッシングを提供するのに役立つNFSクライアント間のピアツーピア通信を提供する。分散型メタデータキャッシングは、従来の集中型制御及びリタイア/リフレッシュプロトコルによって生じる問題を緩和する。装置及び方法の例では、NFSクライアントとやりとりを行う及び/又はNFSクライアントを更新することができ、それにより、NFSクライアントは、メタデータに影響を与えるファイル操作毎に又はファイルにタッチする毎に、NFSサーバと自動的に通信を行う必要がなくなる。自動的にNFSサーバへと通信を行うのではなく、NFSクライアントは、最初に、自身のキャッシュを調べる、及び/又は、ピアと通信を行って、存在する場合は、NFSクライアント自身を含め、どのピアがファイルの最新のメタデータを持っているかを発見する。発見したNFSクライントが最新のメタデータを有し、最新のメタデータを有する役割を担っている場合には、別のNFSクライアント又はNFSサーバと通信を行う必要はない。NFSクライアントが、最新のメタデータを有しているが、別のNFSクライアントが最新のメタデータを有する担当になっている場合、NFSクライアントは、別のNFSクライアントに更新を行わせる必要がある場合がある。一実施形態において、少なくとも1つのNFSクライアントが、最新のメタデータを格納する役割を担う。別の実施形態では、2つ以上のNFSクライアントが、最新のメタデータを格納する役割を担ってもよい。この場合、メタデータが重複して格納されることになる。一実施形態では、同様に、少なくとも1つのNFSクライアントが、存在する場合には、どのNFSクライアントがファイルの最新のメタデータを有するかを知る役割を担ってもよい。別の実施形態では、2つ以上のNFSクライアントが、存在する場合には、どのNFSクライアントがファイルについて最新のメタデータを有するかを知る役割を担ってもよい。この場合、最新のメタデータをどこで見つけることができるかについての情報の格納において、メタデータキャッシングが重複することとなる。従来では、NFSサーバのみが、どのメタデータが更新されたかを知っており、NFSサーバのみが最新のメタデータを有していた。最新のメタデータを格納する役割を分散させることにより、NFSサーバの負荷を低減させることができる。同様に、どのNFSクライアントが最新のメタデータを有するかを知る役割を分散させることにより、NFSサーバの負荷を大幅に低減させることができる。しかしながら、これらの役割が、好適な数のNFSクライアント間に適切に分散されない場合、負荷が、NFSサーバからNFSクライアントに移動しただけになってしまう。装置及び方法の例では、複数の参加NFSクライアント間の役割の分散のバランスをとることを試みてもよい。メタデータの格納の役割及び/又はどのクライアントが最新のメタデータを有しているかを知る役割を分散させるバランスをとる1つの方法として、ハッシュ関数を利用する方法がある。ハッシュ関数は、複数の参加NFSクライアント間で、ファイルについての役割の良好な例えば、均一な、ガウス分布の分散を生成するように設計されている。ハッシュ関数は、NFSサーバ及び複数のNFSクライアントに知らされていてもよい。ファイル又はそのメタデータに影響を与える操作が実行されると、ファイル識別子がハッシュ関数に提供されてもよい。そして、ハッシュ関数は、メタデータを有するNFSクライアント、及び/又は、どのクライアントがメタデータを有するか知る役割を担っているかを特定するのに使用可能な値を戻す。一実施形態において、この値は、NFSクライアント特定情報のリポジトリ例えば、テーブル、アレイにおけるインデックスとして使用されてもよい。別の実施形態では、この値は、NFSクライアント識別子であってもよい。十分に多い数のファイル及び良好に設計されたハッシュ関数の場合には、役割の相対的に分散が均一になると考えられる。しかしながら、複数の参加NFSクライアントからなるセットに、NFSクライアントが追加される又は削除されると、ハッシュ関数及び/又はハッシュ値と利用可能なNFSクライアント間のつながりを、更新する必要がある。したがって、別の実施形態では、役割分散のバランスをとる別の方法として、現在の分散の情報に基づいて役割を割り当て、ファイル毎のテーブルに役割のデータを格納する。ファイルがリクエストされると、NFSサーバ又は別のエンティティは、参加NFSクライアントにおける現在の役割分散を特定し、このファイルに関しての役割を選択されたNFSクライアントに割り当てる。このような技術により、NFSクライアントにおけるファイルアクセスの都度にハッシュ関数を計算する手間を省けるが、固有のファイル毎のベースで分散させるアクションを実行させる新たな役割を導入する必要がある。クライアント識別子を生成するのにハッシュ関数を使用すると、ファイル毎又はクライアント毎に情報を格納する付加メモリが必要なくなることを意味する。また、インデックス値を生成するのにハッシュ関数を使用すると、識別子とNFSクライアントとを関連付けるNFSクライアントそれぞれにつき1つのエントリを有するのに十分な付加ストレージが使用されることを意味する。ハッシュ関数を使用せずに、ファイル毎のベースで情報が格納される場合、各NFSクライアントは、自身が知るファイルについて、当該ファイルとNFSクライアント間の相互関係を格納する。この方法は、メモリを多く使用するが、ファイル操作毎に、ハッシュ関数を実行する必要がなくなる。図6には、異なる実施形態において、ロジック140が利用可能な、ハッシュ関数610とファイル単位データ構造perfiledatastructure620の両方が示されている。ハッシュ関数610は、ファイルハンドルの入力を受け、クライアント識別子を出力することができる。一例では、ハッシュ関数610は、ファイルハンドルの入力を受け、クライアント識別子でポピュレートされたアレイのインデックスを出力する。ファイル単位データ構造620は、ファイル識別子及びクライアント識別子を格納してもよい。ロジック140がメタデータリクエストをインターセプトすると、ハッシュ関数610又はファイル単位データ構造620は、メタデータリクエストと関連付けられたファイルを特定し、メタデータリクエストに応えることが可能なピアについての情報を提供してもよい。図2には、常にNFSサーバ130と通信を行うのではなく、複数のNFSクライアントが互いに通信を行って、メタデータに関する負荷の少なくとも一部を負担する分散型メタデータキャシュ環境が例示されている。図2には、NFSクライアント112が、ピアツーピア分散型メタデータキャッシュロジック140とやりとりをしてる様子が示されており、NFSクライアント122がピアツーピア分散型メタデータキャッシュロジック150とやりとりをしてる様子が示されている。図1では、メタデータリクエストが、NFSサーバ130に流される。図2では、メタデータリクエストが、ピアツーピア分散型メタデータキャッシュロジック140と、ピアツーピア分散型メタデータキャッシュロジック150との間に流される。ピアツーピア通信メタデータキャッシュロジック140は、これに限定されないが、メタデータの格納、どこにメタデータを発見することができるかについての情報の格納、NFSサーバ130ではなく別のピアからのメタデータのリクエスト、NFSサーバ130以外でどこにメタデータを発見できるかについての情報の別のピアからのリクエスト、別のクライアントの別のロジックにそのロジックに格納されているメタデータを更新させる、別のクライアントの別のロジックにどこに最新のメタデータを発見できるかについての情報を更新させる等のアクションを含む、様々なアクションを行ってもよい。図3には、分散型メタデータキャッシュ環境で動作し、ピアツーピア通信ベースの分散型メタデータキャッシングに参加するように構成された装置300が例示されている。分散型メタデータキャッシングでは、複数のピアからなるセット内のメンバは、サーバから複数のピアのセットのメンバであるクライアントへとコピーされたファイルに対するメタデータを格納する負荷を分担する。メタデータは、複数のピアからなるセット内の1以上のメンバにキャッシュされていてもよい。メタデータがどこにキャッシュされているかについての情報は、ピアのセットの1以上のメンバに格納されててもよい。最新のメタデータ及びこの最新のメタデータをどこに見つけることができるかについての情報をピアのメンバにおいて格納することは、NFSサーバとの通信の低減につながる。装置300は、プロセッサ310及びメモリ320を備え、更に、プロセッサ310、メモリ320及び一連のロジックを接続するインターフェース330を備える。一連のロジックとして、第1ロジック340、第2ロジック345、第3ロジック350、第4ロジック355、第5ロジック360、第6ロジック365及び第7ロジック370を含んでもよい。異なる実施形態では、ロジックは、分散型メタデータキャッシングをサポートする又は情報をやりとりすることに関連する異なるアクションを実行するよう構成されていてもよい。7個のロジックが図示されているが、これより多い数及び/又は少ない数のロジックを使用して、7個のロジックによって実行されるアクションを実行してもよい。一実施形態では、装置300は、NFSサーバと情報をやりとりするNFSクライアントであってもよい。NFSクライアント及びNFSサーバについて説明がなされるが、以下に説明される分散型メタデータキャッシングは、その他のネットワークベースのファイルシステムに採用されてもよい。一実施形態において、第1ロジック340は、メタデータを格納するように構成される。メタデータは、ピアツーピア通信ベースの分散型メタデータキャッシングに参加する複数のクライアントからなるセットと協働するサーバから取得されたファイルのローカルコピーに関連付けられている。複数のクライアントからなるセットは、ピアのセットとも称される。メタデータは、メモリ320、固体素子デバイスSSD、及び/又は、装置300が知り得る利用可能なその他のロケーションに格納されてもよい。メタデータは、装置300によって格納されてもよいし、複数のクライアントのセット内の別の装置によって重複して格納されてもよい。一実施形態において、ファイルのローカルコピーは第1ロケーション例えば、メモリ320に格納され、メタデータは第2ロケーション例えば、SSDに格納されてもよい。一般的に、第1ロジック340は、ファイルのローカルコピーと関連付けられたメタデータを格納し、第2ロジック345は、ピアツーピアメタデータキャッシュ環境におけるファイルのローカルコピーの最新のメタデータを格納するのを助けるデータを格納し、第3ロジック350は、ピアツーピアメタデータキャッシュ環境において、ファイルのローカルコピーの最新のメタデータの場所を特定するのに役立つデータを格納するように構成される。第2ロジック345は、どのピアがファイルのローカルコピーの最新のメタデータを有するかを知る役割を担うメンバを、複数クライアントからなるセット内から特定するデータを格納するように構成されてもよい。第2ロジック345はまた、どのピアがファイルのローカルコピーの最新のメタデータのコピーを格納する役割を担うメンバを、複数クライアントからなるセット内から特定するデータを格納するように構成されてもよい。この場合、第2ロジック345は、どこに最新のメタデータが位置しているかについての情報を格納してもよく、及び/又は、どのクライアントが最新のメタデータの場所を知っているかについての情報を格納してもよい。このような情報を格納することにより、メタデータリクエストがなされた時に、NFSサーバに問い合わせる必要がなくなる。先に記したように、従来のシステムにおいては、このようなNFSサーバとの通信は、ボトルネックとなる。第3ロジック350は、ファイルのローカルコピーに対する最新のメタデータを有するメンバを、複数のクライアントからなるセット内から特定するように構成されてもよい。特定は、第2ロジック345が格納するデータからなされてもよい。第3ロジック350は、ファイルのローカルコピーに対する最新のメタデータを有するメンバを複数のクライアントからなるセット内から特定することができるメンバを特定するように構成されてもよい。特定は、第2ロジック345が格納するデータからなされてもよい。第3ロジック350は、様々な方法でクライアントを特定可能であってもよく、これに限定されないが、例えば、メタデータが属するファイルと関連付けられたファイル識別子にハッシュ関数を適用し、クライアント識別子のレポジトリ例えば、アレイ、テーブル、ファイルからクライアント識別子を取得してもよい。第4ロジック355は、ファイルのローカルコピーに対する最新のメタデータを取得するように構成されてもよい。第4ロジック355は、第3ロジック350によって実行される上記の特定を利用して、最新のメタデータを取得してもよい。一例では、装置300自身が、最新のメタデータを有する役割を担う場合には、第4ロジック355は、装置300から最新のメタデータを取得してもよい。別の例では、異なるクライアントが、最新のメタデータを有する役割を担う場合には、第4ロジック355は、複数のクライアントからなるセットのメンバからメタデータを取得するリクエストを送信する必要がある場合がある。しかしながら、第4ロジック355は、直接情報をリクエストすることができず、最初に、最新のメタデータを有する役割を担うクライアントを特定する必要がある場合がある。一実施形態において、第3ロジック350は、ファイルのローカルコピーの最新のメタデータを有するメンバをクライアントのセットから、ハッシュ関数をファイルのローカルコピーのファイル識別子に適用することによって生成されるハッシュ値の関数として特定するように構成されてもよい。ハッシュ値は、例えば、クライアント識別子であってもよく、クライアント識別子のレポジトリからクライアント識別子の位置を特定するのに使用されてもよい。レポジトリは、1エントリにつき、1以上のクライアント識別子を格納してもよく、また、ハッシュ値を使用してインデックスを付与してもよい。一例では、ハッシュ値が、クライアント識別子が発見されない空のエントリを指す場合には、装置300は、所望の情報を取得するべくNFSサーバに戻ってもよい。上記では、ハッシュ関数について記載されたが、その他の数学的又はアルゴリズム的方法を採用して、ファイル識別子からクライアントを特定してもよい。別の実施形態では、第3ロジック350は、ファイルとクライアントを相関付ける情報を格納するファイル単位データ構造にアクセスすることにより、ファイルのローカルコピーの最新のメタデータを有するメンバを、クライアントのセットから特定するように構成されてもよい。一例では、ファイルについて責任を有する複数クライアントからなるセットのメンバとして、ファイル単位データ構造がポピュレートされてもよい。別の例では、ファイル単位データ構造は、NFSサーバによってポピュレートされてもよい。ファイル単位データ構造は、負荷のバランスをとるように操作されてもよい。一実施形態では、第3ロジック350は、ファイルのローカルコピーの最新のメタデータを有するメンバをクライアントのセットから特定可能なメンバを、ファイルのローカルコピーのファイル識別子にハッシュ関数を適用することによって生成されたハッシュ値の関数として、特定するよう構成されてもよい。ここで、ハッシュ値は、クライアント識別子であってもよいし、クライアント識別子のレポジトリからクライアント識別子を特定するのに使用されてもよい。図6には、ハッシュ関数610、及び、ピアツーピア分散型メタデータキャッシュロジック140と情報のやりとりを行うファイル単位データ構造620が例示されている。第3ロジック350は、ハッシュ関数610及びファイル単位データ構造を同様に採用してもよい。第3ロジック350は、様々な方法でクライアントを特定可能であってもよく、これに限定されないが、例えば、メタデータが属するファイルと関連付けられたファイル識別子にハッシュ関数を適用し、クライアント識別子のレポジトリ例えば、アレイ、テーブル、ファイルからクライアント識別子を取得し、クライントとファイルとを相関付けている情報を格納するファイル単位データ構造にアクセスすることによって、クライアントを特定してもよい。ファイル単位データ構造は、ファイル識別子及びクライアント識別子を格納してもよい。一実施形態において、第5ロジック360は、複数のクライアントからなるセット内の最新のメタデータを有するメンバを、新規のメタデータで更新するよう構成される。装置300が最新のメタデータを有するが、複数のクライアントからなるセット内の別のメンバが、最新のメタデータを有することになっている、又は、どのメンバが最新のメタデータを有するか知っているべきである、と判断された場合には、第5ロジック360は、そのメンバにメタデータを提供してもよい。更に及び/又はこれに替えて、第5ロジック360は、複数のクライアントからなるセットから最新のメタデータを有するメンバを特定することができるメンバを、装置300を特定するのに十分な新規のクライアント識別子で更新するよう構成されてもよい。一実施形態において、第6ロジック365は、選択的にサーバと通信するよう構成されてもよい。第6ロジック365は、ファイルのローカルコピーと関連付けられたメタデータを伝達するように構成されていてもよい。この構成は、ピアツーピアネットワークの応答時間が所望の閾値を下回る場合に採用されてもよい。一定期間が経過した後で、分散型メタデータキャッシングに何が起こったかをNFSサーバに知らせるのが適切である場合、上記の構成をバックアップ又は安全策として採用してもよい。最新のメタデータ及び最新のファイルを有する最終的な責任はNFSサーバにあるので、第6ロジック365は、ファイルのローカルコピーをNFSサーバに伝達してもよい。一実施形態において、第7ロジック370は、サーバに宛てられたNFSGetAttrコールを傍受すると、サーバではなく、複数のクライアントからなるセットのうちの一メンバと選択的に通信を行う。NFSGetAttrコールは、前に取得されたファイルハンドルによって特定されたファイルのファイル属性をリクエストする機能である。キャッシングメタデータは、NFSGetAttrコールをローカルに傍受することを可能とし、NFSサーバまで戻って問い合わせることなく、ファイルの属性を提供可能とする。第7ロジック370は、サーバに宛てられたNFSSetAttrコールを傍受すると、サーバではなく、複数のクライアントからなるセットのうちの一メンバと選択的に通信を行うように構成されてもよい。NFSSetAttrコールは、前に取得されたファイルハンドルによって特定されたファイルのファイル属性を更新する機能である。そして、メタデータをキャッシングすることにより、NFSSetAttrコールをローカルにインターセプトすることを可能とし、NFSサーバまで戻ることなく、ファイル属性を更新することが可能となる。したがって、一実施形態では、第7ロジック370は、NFSクライアントとNFSサーバとの間に物理的及び/又は論理的に挿入されていてもよい。このようにすることで、既存の構成に、上記の分散型メタデータキャッシングを組み込むことが容易になる。図4には、ピアツーピア通信ベースの分散型メタデータキャッシングと関連付けられた方法400が示されている。方法400は、410において、複数のピアからなるセットと共に、ピアツーピア分散型メタデータキャッシングに参加するNFSクライアントを制御して、NFSサーバ宛のメタデータリクエストをインターセプトする段階を備える。メタデータリクエストは、最新のメタデータを要求するものであってもよいし、更新されたメタデータについての情報を提供するものであってもよい。方法400は、420において、メタデータリクエストを満たすべく通信を行う、複数のピアからなるセットのメンバを特定する段階を備える。メンバは、少なくとも一部、メタデータリクエストと関連付けられたファイル識別子に基づいて特定されてもよい。一実施形態において、複数のピアからなるセット内から、通信を行うメンバを特定する段階は、メタデータリクエストに関連付けられたファイル識別子にハッシュ関数を適用して、ピア識別子を取得可能なデータを取得することを伴う。別の実施形態では、複数のピアからなるセット内から、通信を行うメンバを特定する段階は、ファイルとこれらファイルの担当になっているクライアントとを相関付ける情報を格納しているファイル単位データ構造への問い合わせを伴ってもよい。方法400はまた、段階430において、複数のピアからなるセットによって維持される分散型メタデータキャッシュからのメタデータリクエストを満たすべく、NFSクライアントを制御する段階を備える。メタデータリクエストは、NFSサーバに送信されず、複数のピアからなるセット内のメンバと通信を行うことによってリクエストが満たされる。一実施形態において、メタデータリクエストを満たす段階は、メタデータを取得するリクエストを満たすことを含む。更に及び/又はこれに替えて、メタデータリクエストを満たす段階は、メタデータを更新するリクエストを満たすことを含んでよい。一実施形態において、方法400はまた、複数のピアからなるセット内の異なるメンバにおいて格納されているファイルのローカルコピーに対する現在のメタデータを格納するべく、NFSクライアントを制御する段階を備える。これは、方法400を実装する装置が、ファイルの最新のメタデータを維持する役割を担当している場合に生じると考えられる。方法400はまた、複数のピアからなるセット内の異なるメンバにおいて格納されているファイルのローカルコピーの現在のメタデータを有するメンバを特定するのに十分なデータを格納するべく、NFSクライアントを制御する段階を備える。これは、方法400を実行する装置が、最新のメタデータを有し、別の装置が、どの装置が最新のメタデータを有するかを知る役割になっている場合に考えられる。図5には、ピアツーピア通信ベースの分散型メタデータキャッシング530に参加するよう構成された装置500が例示されている。装置500は、ピアツーピア通信ベースの分散型メタデータキャッシング530に参加するべく、装置500を制御するよう構成されプロセッサ510を備える。分散型メタデータキャッシングは、自動的にメタデータ情報をサーバに取りに行くのではなく、ピアツーピア通信ベースの分散型メタデータキャッシング530を利用して、ファイルのローカルコピーと関連付けられたメタデータリクエストを扱うことを伴う。装置500はまた、ファイルサーバから取得されたファイルのローカルコピーを格納するよう構成されたローカルメモリ520を備える。装置500はまた、ファイルと関連付けられたメタデータのローカルコピーを格納するよう構成されたネットワーク接続ストレージNAS530を備える。上記では、ファイルのローカルコピーを格納するのにローカルメモリ520が記載されたが、ローカルコピーは、装置500が利用可能なその他の記憶装置に格納されてもよいことは明らかである。同様に、メタデータを格納するのにNAS530が説明されたが、メタデータは、装置500が利用可能なその他の記憶装置に格納されてもよいことは明らかである。一実施形態において、プロセッサ510は、ファイルのローカルコピーの現在のメタデータを格納するように構成される。プロセッサ510は、ローカルメモリ520及び/又はNAS530に、現在のメタデータを格納してもよい。プロセッサ510はまた、ピアツーピア通信ベースの分散型メタデータキャッシング530に参加する異なる装置に格納された異なるファイルのローカルコピーに対する現在のメタデータを格納するように構成されてもよい。プロセッサ510は、ローカルメモリ520及び/又はNAS530に、現在のメタデータを格納してもよい。プロセッサ520は、ファイルのローカルコピーに対する現在のメタデータを有するピアツーピア通信ベースの分散型メタデータキャッシング530に参加する装置を特定するのに十分な情報を格納するように構成されてもよい。プロセッサ510は、ローカルメモリ520及び/又はNAS530に情報を格納してもよい。プロセッサ520は、ピアツーピア通信ベースの分散型メタデータキャッシング530に参加する異なる装置に格納されている異なるファイルのローカルコピーの現在のメタデータを有する装置を特定するのに十分な情報を格納するように構成されてもよい。また、プロセッサ510は、この情報を、ローカルメモリ520及び/又はNAS530に格納してもよい。以下に、本明細書で使用された用語の定義について記す。定義は、言葉の範囲内に含まれ、実装に使用されてもよい様々な例及び/又は形態を含む。例は、以下に列挙するものに限定されない。また、用語の単数形及び複数形は、定義の内に含まれる。一実施形態、ある実施形態、一例、ある例等の言葉は、記載される実施形態又は例が、特定の特徴、構造、性質又は特性を含むことを示唆するが、必ずしも全ての実施形態又は例が、これら特定の特徴、構造、性質又は特性を含むことを意味しない。また、一実施形態ではという言葉が繰り返し使用されるが、これは必ずしも、同じ実施形態を指してるわけではない。本明細書で使用されるロジックという言葉は、これに限定されないが、ハードウェア、ファームウェア、非一時的媒体に格納される命令又は機械で実行される命令、及び/又は、別のロジック、方法及び/又はシステムからの機能又は動作を引き起こす及び/又は機能又は動作を実行するこれらの組み合わせを含む。ロジックは、ソフトウェア制御マイクロプロセッサ、ディスクリートロジック例えば、ASIC、アナログ回路、デジタル回路、プログラムされたロジックデバイス、命令を含むメモリデバイス等を含む。ロジックは、1以上のゲート、ゲートの組み合わせ、そのほかの回路構成要素を含んでもよい。複数のロジックについて記載される場合であっても、複数のロジックを1つの物理的ロジックに組み込むことが可能である。同様に、1つのロジックが記載されている場合であっても、1つのロジックを、物理的に複数のロジック間で分担させることが可能である。本明細書に記載された構成要素及び機能の1以上が、ロジック要素の1以上を使用して実装されてもよい。説明を単純にするために、例示の方法は、一連のブロック図で示されている。方法は、ブロックの順番に限定されず、一部のブロックが、説明されたのとは、異なる順番で発生してもよい及び/又はその他のブロックと同時に発生してもよい。更に、例示された複数のブロックの全てよりも少ないブロックを使用して、例示した方法が実装されてもよい。複数のブロックが、組み合わせられてもよいし、複数の構成要素に分割されてもよい。また、更なる及び/又は代替の方法では、図示されていないブロックを更に採用してもよい。詳細な説明又は特許請求の範囲で使用されている含むincludesorincludingという言葉は、特許請求の範囲を記載する際に使用される移行句備えるcomprisingと同様な態様で、要素を包括することを意図して使用されている。システム及び方法等の例が、複数の例を挙げて、数多くの詳細事項と共に説明されたが、本願は、このような詳細事項によって、添付の特許請求の範囲が制限されることを意図していない。無論、本明細書に記載するシステム、方法等を説明する目的で、構成要素又は方法の考え得る全ての組み合わせを記載するのは不可能である。したがって、本開示は、特定の詳細事項に限定されず、図示及び説明された代表的装置及び例に限定されない。したがって、本願は、添付の特許請求の範囲内において、変更、改良及び変形を含むことを意図している。