JP2013538407A - ディレクトリのリース - Google Patents

Abstract

分散ファイル・システムにアクセスするクライアントがディレクトリ・メタデータをローカルにキャッシュできるようにするための実施形態を説明する。クライアントは読取リースを要求することができる。当該読取リースにより、クライアントは、ディレクトリ・メタデータをローカルにキャッシュすることができ、当該キャッシュを用いて当該ディレクトリ・メタデータを初めに要求した同一のアプリケーションから受信した要求を処理することができる。さらに、クライアントはハンドル・リースを要求することもできる。当該ハンドル・リースにより、クライアントは、ディレクトリ・ハンドルを閉じるのを遅延させることができ、当該ハンドルを再利用して同一または別のアプリケーションからの後のディレクトリ・メタデータの要求を処理することができる。クライアントはまた書込みリースを要求することができる。当該書込みリースにより、クライアント上のアプリケーションは、例えばディレクトリ内の新たなファイルを生成もしくは削除するかまたはそれらの属性を変更することによって、ディレクトリ・メタデータを修正することができ、クライアントはそれらの変更をキャッシュすることができる。

Description

本発明は、分散ファイル・システムに関する。

クライアント上のアプリケーションが、分散ファイル・システムに格納したファイルにアクセスすることは一般的である。分散ファイル・システムは、リモートに格納したファイルへのアクセスを、クライアント上でローカルに実行されているアプリケーションに透過的に提供する。分散ファイル・システムは幾つかの機能を含むことができる。当該機能により、クライアントが何らかの情報をローカルにキャッシュすることができ、その結果、幾つかの要求がローカルの情報を用いて処理される。これは、情報をリモートから取り出すよりも効率的である。しかし、現在の分散ファイル・システムは、分散ファイル・システムにアクセスするクライアントの間で整合性および一貫性を提供する、メタデータ（例えば、ディレクトリ・メタデータ）のような情報をキャッシュするための機構は有していない。

これらおよび他の検討事項に関して、本発明の諸実施形態を構成した。また、比較的具体的な課題を論じたが、本発明の諸実施形態は、背景技術で特定した具体的な問題を解決することに限定されないことは理解されよう。

本概要は、選択した概念を簡潔な形で導入するために与えたものである。その概念は、下記の発明を実施するための形態においてさらに説明する。本概要は、特許請求する主題の主要な特徴または本質的な特徴を特定しようとするものではなく、特許請求する主題の範囲の決定を支援するものとして使用しようとするものでもない。

分散ファイル・システムにアクセスするクライアントがディレクトリ・メタデータをローカルにキャッシュできるようにするための諸実施形態を説明する。一実施形態では、クライアントはディレクトリ・データをキャッシュするためにファイル・サーバにリースを要求する。クライアントは読取リース（ｒｅａｄ ｌｅａｓｅ）を要求することができる。当該読取リースにより、クライアントは、ディレクトリ・メタデータをローカルにキャッシュすることができ、当該ディレクトリ・メタデータを初めに要求した同一のアプリケーションからの要求を処理することができる。さらに、クライアントはハンドル・リース（ｈａｎｄｌｅ ｌｅａｓｅ）を要求することもできる。当該ハンドル・リースにより、クライアントは、ディレクトリ・ハンドルを閉じるのを遅延させることができ、当該ハンドルを再利用して、クライアント上の同一または別のアプリケーションからの後のディレクトリ・メタデータの要求を処理することができる。幾つかの実施形態では、サーバは２つのリース鍵を利用して、クライアントのリースを追跡し続け、ディレクトリ・メタデータに関する読取リースを有するクライアントが当該ディレクトリ・メタデータを変更した結果、読取リースが失効（ｒｅｖｏｋｅ）することにならないことを保証する。他の実施形態では、クライアントは書込みリース（ｗｒｉｔｅ ｌｅａｓｅ）を要求することができる。当該書込みリースにより、クライアント上のアプリケーションは、例えばディレクトリ内のファイルを生成もしくは削除するかまたはそれらの属性を変更することによって、ディレクトリ・メタデータを修正することができ、クライアントはそれらの変更をキャッシュすることができる。別のクライアントがディレクトリ・メタデータを要求したときは、書込みリースは破棄され、当該変更がサーバにフラッシュされる。

諸実施形態をコンピュータ・プロセス、コンピューティング・システム、または、コンピュータ・プログラム製品もしくはコンピュータ読取可能媒体のような製品として実装してもよい。コンピュータ・プログラム製品は、コンピュータ・システムにより読取可能でありかつコンピュータ・プロセスを実行するための命令からなるコンピュータ・プログラムをエンコードする、コンピュータ記憶媒体であってもよい。当該コンピュータ・プログラム製品はまた、コンピューティング・システムにより読取可能でありかつコンピュータ・プロセスを実行するための命令からなるコンピュータ・プログラムをエンコードする、キャリア上の伝播信号であってもよい。

添付図面を参照して、非限定的で非包括的な諸実施形態を説明する。
幾つかの諸実施形態を実装するために使用できるシステムの一実施形態を示す図である。 幾つかの実施形態で使用できる、クライアントおよびサーバのブロック図である。 幾つかの実施形態と整合する、ディレクトリ・メタデータをローカルにキャッシュするための動作フローを示す図である。 幾つかの実施形態と整合する、ディレクトリ・メタデータに関するリースを保持するクライアントによりディレクトリ・メタデータを修正する要求を処理するための動作フローを示す図である。 幾つかの実施形態と整合する、ディレクトリ・データに関する読取リースの失効を受け取ったときに実施される動作フローを示す図である。 幾つかの実施形態と整合する、ディレクトリ・メタデータをローカルにキャッシュできるようにするための動作フローを示す図である。 諸実施形態を実装するのに適したコンピューティング環境のブロック図である。

添付図面を参照して様々な諸実施形態を以下でより完全に説明する。添付図面は本明細書の一部を構成し、本発明を実施するための具体的で例示的な諸実施形態を示す。しかし、諸実施形態を多数の様々な形態で実装してもよく、本明細書で説明した諸実施形態に限定されると解釈すべきではない。寧ろ、本開示が徹底的で完全であり、本発明の範囲を当業者に完全に伝達するように、これらの諸実施形態を提供するものである。諸実施形態を、方法、システム、または装置として実施してもよい。したがって、諸実施形態が、ハードウェア実装の形態、専らソフトウェア実装の形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実装の形態をとってもよい。したがって、以下の詳細な説明は限定的な意味で捉えるべきではない。

図１は、諸実施形態を実装する分散ファイル・システム１００の一実施形態を示す。システム１００は、ファイルおよびファイル情報へのアクセスを必要とする様々なアプリケーションを実行する、クライアント１０２および１０４を含む。ファイル・サーバ１０６はファイルおよびファイル情報を、例えばデータ・ストア１０８に格納する。クライアント１０２および１０４は、ネットワーク、例えばネットワーク１１０を介してファイル・サーバ１０６にアクセスすることができる。当業者が理解するように、ネットワーク１１０はＬＡＮ、ＷＡＮ（例えば、インターネット）、記憶領域ネットワーク、またはクライアント１０２および１０４がファイル・サーバ１０６と通信できるようにする他のネットワークであってもよい。

分散ファイル・システム１００は、クライアント１０２および１０４がファイル・サーバ１０６にアクセスできるようにするためのプロトコルを実装してもよい。プロトコルの幾つかの非限定的な例には、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）、ＳＭＢ２、およびＮＦＳがある。当業者が理解するように、ファイル・アクセス・プロトコルは、ファイル・サーバにファイルを要求するための様々なフォーマットをクライアントに提供する。諸実施形態はどの特定のファイル・アクセス・プロトコルにも限定されない。寧ろ、説明する諸実施形態の特徴を任意のファイル・アクセス・プロトコルを用いて実装してもよい。当該ファイル・アクセス・プロトコルには、上で列挙したものが含まれるがこれらに限らない。

一実施形態では、クライアント１０２および１０４がファイル・サーバ１０６にリースを要求してもよい。当該リースにより、クライアント１０２および１０４はディレクトリ・メタデータをローカルにキャッシュすることができる。当業者が理解できるように、ファイル・サーバ１０６が、実際のファイル・データを格納することに加えて、ディレクトリ内のファイルの特徴を記述するディレクトリ・メタデータを格納してもよい。例えば、ディレクトリ・メタデータとして、ディレクトリ内のファイルごとに、最終更新日付、作成日、ファイル・サイズ、ファイル・タイプ、および作成者名を含めてもよいがこれらに限らない。本実施形態を、リース機構を提供することによって実装することができる。

図１に示すように、幾つかの実施形態では、クライアント１０２のようなクライアントが、メタデータ・リース要求を有するパケット１１２をファイル・サーバ１０６に送信する。諸実施形態では、パケット１１２がリース要求に加えてメタデータの要求を含んでもよい。例えば、ブラウザ・アプリケーションのようなアプリケーションが、特定のディレクトリに対するディレクトリ・メタデータを要求してもよい。当該要求に応答して、クライアント１０２がパケット１１２を送信してもよい。当該パケット１１２は、特定のディレクトリのメタデータの要求ならびにメタデータ・リース要求を含む。

図１に示すように、パケット１１２が読取リース、書込みリース、および／またはハンドル・リースを指定してもよい。読取リースにより、クライアント１０２はディレクトリのメタデータをローカルのキャッシュに格納することができ、ブラウザ・アプリケーションがディレクトリ・メタデータを要求するたびにクライアントは当該要求をローカルのキャッシュから処理することができる。ハンドル・リースにより、クライアント１０２は、ディレクトリ・ハンドルを閉じるのを遅延させ、クライアント１０２がディレクトリ・ハンドルを使用して、ブラウザ・アプリケーションならびにディレクトリに対するディレクトリ・メタデータを要求できる他のアプリケーションからの後の要求を処理できるようにすることができる。書込みリースにより、クライアントはアプリケーションがディレクトリ・メタデータに対して行った変更をキャッシュすることができる。

図１に示す実施形態では、ファイル・サーバ１０６が応答パケット１１４を送信する。当該応答パケット１１４は、要求されたディレクトリ・メタデータ、および要求されたリースが与えられたかどうかの指示を含む。応答パケットに基づいて、クライアント１０２はリース要求が与えられた場合はディレクトリ・メタデータをキャッシュし、当該ディレクトリ・メタデータをブラウザ・アプリケーションに提供する。リースが与えられなかったと応答パケットが示す場合は、クライアント１０２はディレクトリ・メタデータをキャッシュせず、単に当該ディレクトリ・メタデータをブラウザ・アプリケーションに提供する。クライアント１０２にリースが与えられなかった場合は、ディレクトリ・メタデータに対するブラウザ・アプリケーションからの任意の後の要求により、クライアントはディレクトリ・メタデータをファイル・サーバ１０６に要求することとなる。

下記でさらに詳細に説明するように、リースをクライアントに与えることにより、アプリケーションからの要求を処理する効率性がもたらされ、クライアントが複数の要求をファイル・サーバ１０６に送信する必要性が減る。したがって、幾つかの実施形態では、ファイル・サーバ１０６は一般に、衝突するリースを別のクライアントが現在保持していない限り、リースをクライアントに与える。ディレクトリ・メタデータの一貫性を保証するために、ファイル・サーバ１０６は、特定のディレクトリ・メタデータに関して衝突するリースが別のクライアントに付与されないことを保証する。

図１の説明は幾つかの実施形態の幾つかの特徴を導入するために与えたにすぎない。下記でさらに詳細に説明するように、他の実施形態では追加の特徴を提供してもよい。図１の説明は、他の任意の実施形態の範囲を限定するために使用されるべきではない。

図２は、幾つかの実施形態で使用できるクライアントおよびサーバのブロック図を示す。上述のように、様々なファイル・アクセス・プロトコルを使用して、説明する実施形態の機能を実装することができる。以下の図２の説明のうち幾つかは、幾つかのＳＭＢ２の機能説明を含む。しかし、これは他の実施形態を限定するために使用されるべきではない。なぜならば、任意のファイル・アクセス・プロトコルを使用して、説明する機能を実装できるからである。ＳＭＢ２の使用は一例にすぎず、例示の目的にのみ使用される。

図２は、分散ファイル・システム２００の一部であるクライアント２０２およびファイル・サーバ２０４のブロック図を示す。幾つかの実施形態では、クライアント２０２をシステム１００（図１）においてクライアント１０２および１０４として実装してもよく、ファイル・サーバ２０４をシステム１００（図１）においてファイル・サーバ１０６として実装してもよい。

図２に示すように、クライアント２０２は、サーバ２０４のファイル・システム２０８に格納されたファイル・データおよびメタデータへのアクセスを要求する、幾つかのアプリケーション２０６Ａ乃至Ｃを含む。クライアント２０２はまた、リダイレクタ２１０を含む。一実施形態では、リダイレクタ２１０をＳＭＢ２リダイレクタとして構成してもよく、クライアント２０２およびサーバ２０４はＳＭＢ２プロトコルに従ってフォーマットされたパケットを用いて通信する。アプリケーション２０６Ａ乃至Ｃのうち１つがサーバ２０４上に置かれたファイルを要求すると、リダイレクタ２１０がその要求を処理する。リダイレクタ２１０は、ファイル・データおよびメタデータに対する要求を有する、ＳＭＢ２プロトコルに従ってフォーマットされたパケットを生成する。下記でさらに詳細に説明するように、諸実施形態では、ＳＭＢ２プロトコルを拡張して、クライアント２０２がディレクトリ・メタデータをクライアント２０２上のローカルのキャッシュ２１２に格納できるようにするリース機構を提供する。当該リース機構は、サーバ２０４が与えるリースに関連付けられたリース鍵（ディレクトリ鍵／ファイル鍵）を格納する、クライアント２０２上の検索テーブル２１４を利用する。サーバ２０４はまた、リースを要求し当該リースを与えられるクライアントに対してリース鍵を格納する。サーバ２０４は、リース・テーブル２１６を用いてリース鍵を格納する。

システム２００の動作の一例として、アプリケーション２０６Ａはファイル・システム２０８のディレクトリ、例えばディレクトリ１に格納されたファイルに関するメタデータを要求することができる。その結果、アプリケーション２０６Ａはリダイレクタ２１０が受け取る要求を発行する。当該要求を受け取ったことに応答して、リダイレクタ２１０は、ネゴシエート要求パケット２１８を送信することにより、サーバ２０４とのセッションを開始する。当業者が理解するように、ネゴシエート要求パケット２１８は、クライアントとサーバとの間でのセッションのネゴシエートを提供するＳＭＢ２プロトコルに従ってフォーマットされる。ネゴシエート要求パケット２１８は、クライアントがディレクトリ・メタデータのリースを処理できるか否かを示す情報を含む。一実施形態では、ディレクトリ・メタデータのリースを何らかのバージョンのＳＭＢ２プロトコルによってのみサポートしてもよく、ネゴシエート要求パケット２１８が、クライアントはメタデータのリースをサポートする或るバージョンのＳＭＢ２プロトコルをサポートしており、そのバージョンのＳＭＢ２プロトコルを用いてサーバと通信することを望むという指示を提供してもよい。

ネゴシエート要求パケット２１８に応答して、サーバ２０４はネゴシエート応答パケット２２０を送信する。当該ネゴシエート応答パケット２２０は、サーバが当該バージョンのＳＭＢ２プロトコルをサポートするか否かの指示を含むことができる。現在の例では、ネゴシエート応答パケット２２０は、ディレクトリ・メタデータのリースをサポートする或るバージョンのＳＭＢ２プロトコルを用いて通信することにサーバが同意したことを示す。

クライアント２０２とサーバ２０４との間のネゴシエーションが完了した後、リダイレクタ２１０は、アプリケーション２０６Ａが要求しているディレクトリ・メタデータを要求することができる。一実施形態では、リダイレクタ２１０は先ず、要求されているディレクトリ・メタデータに関連付けられたディレクトリ鍵、例えば、ディレクトリ２鍵を生成する。さらに、リダイレクタ２１０はまた、要求されているディレクトリ・メタデータを含む親ディレクトリ、この場合はディレクトリ１に対する鍵を生成する。これらの鍵を検索テーブル２１４に格納する。図２の実施形態で示すように、検索テーブル２１４はディレクトリ鍵を、ディレクトリ内に格納されたファイルに対する様々なファイル鍵ならびにディレクトリ内のサブディレクトリに対するディレクトリ鍵に関連付ける。リース鍵は幾つかの実施形態ではＧＵＩＤ（ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）である。しかし、当該リース鍵はＧＵＩＤには限定されない。

リダイレクタ２１０は次に、ディレクトリ２内のディレクトリ・メタデータに対する要求を含み、ディレクトリ２内のディレクトリ・メタデータに対するリースもまた要求する、パケット２２２を送信する。リース要求の一部として、リダイレクタ２１０は、生成したリース鍵（即ち、ディレクトリ１に対するディレクトリ鍵およびディレクトリ２に対するディレクトリ鍵）を含む。別の実施形態では、リダイレクタ２１０は何らディレクトリ鍵を生成しない。その代わり、パケット２２２が、サーバがリース鍵を生成すべきであるとリダイレクタ２１０が示すことを規定する。

サーバ２０４がディレクトリ・リース要求パケット２２２を受け取ると、サーバ２０４はディレクトリ・メタデータをディレクトリ２から取り出す。サーバ２０４はまた、サーバ２０４が要求されたリースをクライアント２０２に与えることができるか否かを判定する。具体的には、当該サーバは、自身が与えた他のリースに対するリース鍵（ディレクトリ鍵およびファイル鍵）を格納するリース・テーブル２１６を参照することができる。本例では、以前にディレクトリ２に対するリースを要求したクライアントは存在せず、その結果、サーバ２０４は、ディレクトリ１に対するディレクトリ鍵およびディレクトリ２に対するディレクトリ鍵をディレクトリ・リース要求パケット２２２からリース・テーブル２１６に格納する。

当該サーバは、ディレクトリ・メタデータ、および要求されたリースが与えられたことの指示を有する、ディレクトリ・リース応答パケット２２４を送信する。この場合、要求されたリースが読取リース、書込みリース、および／またはハンドル・リースを含んでもよい。リースが読取リースである場合、クライアント２０２はディレクトリ２のディレクトリ・メタデータに対するアプリケーション２０６Ａからの要求を、キャッシュ２１２から処理することができる。リースが書込みリースである場合は、ディレクトリ２のディレクトリ・メタデータに対する任意の変更をキャッシュ２１２に格納することができる。リースがハンドル・リースを含む場合は、クライアント２０２はアプリケーション２０６Ａがハンドルを閉じるときにディレクトリ２に対するハンドルを閉じるのを遅延させることができる。次いで当該ハンドルを再利用して、アプリケーション２０６Ａならびに他のアプリケーション２０６Ｂおよび２０６Ｃからの後の要求を処理することができる。リダイレクタ２１０はディレクトリ・メタデータをアプリケーション２０６Ａに提供し、また当該ディレクトリ・メタデータをキャッシュ２１２に格納する。

後の時点で、第２のクライアントがディレクトリ２に格納された同一のディレクトリ・メタデータに対するアクセスを要求した場合、サーバ２０４は、クライアント２０２に与えたハンドル・リースと非互換のアクセスを第２のクライアントが要求した場合にクライアント２０２からのハンドル・リースを失効することができる。サーバ２０４は、ハンドル・リースが失効されていることを示す失効通知２２６をクライアント２０２に送信する。失効の後、アプリケーション２０６Ａ、２０６Ｂ、および２０６Ｃからのディレクトリ・メタデータに対する任意の要求により、クライアント２０２は、新たなディレクトリ・ハンドルを直接サーバ２０４に要求する必要があるはずである。幾つかの実施形態では、リースの失効が同期的に発生し、クライアント２０２は、失効通知を受け取ったという受理（ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）２２８を送信しなければならない。後の時点で第２のクライアントがディレクトリ２に格納されたディレクトリ・メタデータを修正すると、サーバ２０４は、クライアント２０２からの読取リースを失効することができ、これによりキャッシュ２１２に格納されたデータが無効（ｉｎｖａｌｉｄ）になる。失効の後は、アプリケーション２０６Ａ、２０６Ｂ、および２０６Ｃからのディレクトリ・メタデータに対する任意の要求を、情報を直接サーバ２０４に要求することで処理しなければならない。

当業者が理解するように、クライアント２０２はキャッシュ２１２内の情報を、さらにディレクトリ・メタデータをアプリケーション２０６Ａ、２０６Ｂ、および２０６Ｃに提供する目的で使用することができる。一例として、ファイルがディレクトリに存在しない場合、アプリケーション２０６Ａ、２０６Ｂ、および２０６Ｃからの見当たらないファイルに対する要求を、サーバ２０４に当該要求をリダイレクトする必要なしに失敗させることができる。これにより、存在しないファイルを対象としたオープンな要求に関するネットワーク・トラフィックを削減することを支援する。

一実施形態では、上述のリース機能は過渡的である。即ち、リダイレクタ２１０はリースの取得と失効をローカルのアプリケーションに渡すことができる。次いで当該ローカルのアプリケーションを使用して他のリモート・クライアントを処理することができる。このように、リースの付与および失効は原則として最終的なピアに対して過渡的である。

図３乃至図６は、諸実施形態に従う動作フロー３００、４００、５００、および６００を示す。動作フロー３００、４００、５００、および６００を任意の適切なコンピューティング環境で実施してもよい。例えば、動作フローを、図１および図２に示すようなシステムにより実行してもよい。したがって、動作フロー３００、４００、５００、および６００の説明では、図１および図２のコンポーネントのうち少なくとも１つを参照することができる。しかし、図１および図２のコンポーネントに対する任意のかかる参照は説明の目的のためにすぎず、図１および図２の実装形態は動作フロー３００、４００、５００、および６００に関して非限定的な環境であることは理解されよう。

さらに、動作フロー３００、４００、５００、および６００を逐次的に特定の順序で例示および説明するが、他の実施形態では、当該動作を異なる順序で、複数回、および／または並行して実施してもよい。さらに、幾つかの実施形態では１つまたは複数の動作を省略または組み合わせてもよい。

図３は、幾つかの実施形態と整合する、ディレクトリ・メタデータをローカルにキャッシュするための動作フロー３００を示す。フロー３００は動作３０２で開始し、ディレクトリ・メタデータに対する要求（ディレクトリ・メタデータの一部を含む）をアプリケーションから受け取る。幾つかの実施形態では、動作３０２をクライアント上のリダイレクタが受け取る。当該リダイレクタは、システム１００（図１）またはシステム２００（図２）のような分散ファイル・システムの一部である。フロー３００は、どの特定のファイル・アクセス・プロトコルを用いて実装することにも限定されない。任意の適切なファイル・アクセス・プロトコルを用いてフロー３００の実施形態を実装してもよい。

フローは動作３０２から判定３０４に移り、要求されたメタデータがローカルのキャッシュ内に格納されているか否かを判定する。判定３０４で、要求されたメタデータがローカルのキャッシュに格納されていると判定した場合は、フローは動作３０６に移り、当該メタデータを当該ローカルのキャッシュから取り出す。動作３０８で、当該ローカルのキャッシュから取り出した当該メタデータをアプリケーションに提供する。フロー３００は３１０で終了する。

一方、動作３０４で、ディレクトリ・メタデータがローカルのキャッシュに格納されていないと判定した場合は、制御は判定３０４から動作３１２に移り、当該ディレクトリ・メタデータにより特定されたファイルに対するディレクトリ鍵を生成する。幾つかの実施形態では、ディレクトリ鍵は、リダイレクタがフロー３００を実行することにより生成したＧＵＩＤである。動作３１２の後、ディレクトリ・メタデータにより特定されたディレクトリの親ディレクトリに対するディレクトリ鍵を動作３１４で生成する。幾つかの実施形態では、動作３１４が当該ディレクトリの全ての先祖に対する鍵を生成することを含んでもよい。次いで当該鍵をローカルにキャッシュすることができる。

動作３１６で、要求をファイル・サーバに送信する。当該要求は、メタデータならびに、当該メタデータのローカルなキャッシュを可能とするリースに対するものである。動作３１８で、応答をファイル・サーバから受け取る。当該応答は、諸実施形態では、要求されたリースがファイル・サーバにより与えられたか否かの指示を含む。動作３１８からフローは動作３２０に移り、当該応答からのメタデータをアプリケーションに提供する。動作３２０に続いて、判定３２２で、サーバがディレクトリ・メタデータに関する要求されたリースを与えたか否かを判定する。判定３２２で、当該リースが承認されなかったと判定した場合は、メタデータをローカルにキャッシュすることはできず、フローは３１０で終了する。判定３２２で、リースがファイル・サーバにより承認されたと判定した場合は、動作３２４でメタデータをローカルのキャッシュに格納する。動作３２４の後、フローは３１０で終了する。

次に図４を参照すると、幾つかの実施形態と整合する、ディレクトリ・メタデータに関するハンドル・リースを保持する（分散ファイル・システムにアクセスする）クライアントによりディレクトリ・メタデータを修正する要求を処理するためのフロー４００が示されている。諸実施形態では、フロー４００を、フロー３００を実行した後に実行することができる。したがって、フロー４００は、ハンドル・リースがディレクトリ・メタデータをキャッシュするために与えられている諸実施形態において実施される。

フロー４００は動作４０２で開始し、ディレクトリ・メタデータを修正する要求を受け取る。当該要求は例えば、情報をファイルに書き込むための書込み要求であってもよく、これによりメタデータが変更される。非限定的な例では、当該メタデータには修正日、およびファイル・サイズが含まれる。ディレクトリ・メタデータをキャッシュするためのハンドル・リースを、ファイル・サーバがフロー４００を実行しているクライアントに予め与えている。

動作４０４で、当該要求からの情報、即ちディレクトリ・メタデータ、例えばファイルへ書き込むべきデータを修正している情報を有するパケットを生成する。リースが予め与えられているので、第１のディレクトリ鍵および当該リースに関連付けられた親のディレクトリ鍵が存在する。したがって、動作４０６でディレクトリ鍵を当該パケットに含め、動作４０８で当該ディレクトリ鍵をパケットに含める。次いで４１０で当該パケットをサーバに送信する。幾つかの実施形態では、クライアントが最初に当該要求においてディレクトリ鍵および親のディレクトリ鍵を、オープンのために送信する。次いでサーバは、当該オープンに関する全ての後の動作に対して、当該鍵を使用する。しかし、他の実施形態では、クライアントが動作ごとに当該ディレクトリ鍵および親のディレクトリ鍵を提供してもよい。

動作４１０の後、フローは動作４１２に移り、ローカルのキャッシュを更新して変更されたメタデータを反映する。換言すれば、ローカルのキャッシュを更新して、直近の修正日、ファイル・サイズ等の変更を反映する。フロー４００は４１４で終了する。

図５は、ディレクトリ・メタデータに関する読取リースを失効する通知を処理するためのフロー５００を示す。フロー５００を、クライアントに読取リースがサーバ２０４（図２）のようなサーバから与えられた後に実行することができる。フロー５００は動作５０２で開始し、ディレクトリ・メタデータに関して予め与えられた読取リースが失効していることを示す失効通知をサーバから受け取る。幾つかの実施形態では、キャッシュされたディレクトリ・メタデータ、例えば、ディレクトリ内のファイルの修正の一貫性に影響を及ぼす別のクライアントが実施した動作を理由として、失効通知をサーバが送信する。失効通知を受け取ったことに応答して、フロー５００は動作５０４に移り、任意のキャッシュしたディレクトリ・メタデータを無効にする。幾つかの実施形態では、動作５０４は、ディレクトリ・メタデータを要求したアプリケーションに当該ディレクトリ・メタデータを提供するためにキャッシュを使用することがもはやできないことを示すための、クライアントが実施する幾つかのステップを含む。

動作５０４の後、フローは動作５０６に移り、失効通知を成功裏に受け取ったという受理をサーバに送信する。幾つかの実施形態では、フロー５００が動作５０６を含まなくともよい。これらの実施形態では、クライアントは失効通知を受け取り、サーバに受理を送信しない。次いでフローは動作５０８に移り、ディレクトリ・メタデータに対する任意の要求を、ディレクトリ・メタデータをサーバに要求することにより処理する。次いでフロー５００は５１０で終了する。

図６は、幾つかの実施形態と整合する、ディレクトリ・メタデータをローカルにキャッシュできるようにするための動作フロー６００を示す。幾つかの実施形態では、フロー６００を、分散ファイル・システムの一部であるファイル・サーバにより実行することができる。

フロー６００は動作６０２で開始し、ディレクトリ・メタデータおよびリースに対する要求を受け取る。幾つかの実施形態では当該要求を、クライアント、または分散ファイル・システムの一部であるクライアント上のリダイレクタが送信する。動作６０２の後、フロー６００は判定６０４に移り、動作６０２で受け取った要求において要求されたようにリースを与えるか否かの判定を行う。判定６０４が幾つかの要因に基づいてもよい。当該要因には、例えばリースが当該ディレクトリ・メタデータに対して既に与えられたか否かが含まれる。判定６０４で、リースを与えないと判定した場合は、フローは動作６０６に移り、ディレクトリ・メタデータを有するパケットを送信する。当該パケットは、要求されたリースが与えられなかったという指示を含む。次いでフローは動作６０８で終了する。

判定６０４で、リースを与えることができると判定した場合、フロー６００は動作６１０に移り、ディレクトリ鍵および親のディレクトリ鍵を格納する。幾つかの実施形態では、ディレクトリ鍵および親のディレクトリ鍵は、クライアントに与えたリースを追跡し続けるためのリース鍵として使用されるＧＵＩＤである。幾つかの実施形態では、動作６０２で、ディレクトリ鍵および親のディレクトリ鍵を、ディレクトリ・メタデータおよびリース要求とともに受け取る。本実施形態では、ディレクトリ鍵および親のディレクトリ鍵は、動作６０２で要求を送信したクライアントが生成している。他の実施形態では、動作６１０で、ディレクトリ鍵および親のディレクトリ鍵を当該サーバが生成して、これらをリース・テーブルに格納してもよい。

幾つかの実施形態では、ディレクトリ鍵および親のディレクトリ鍵は２つ以上のオープンなハンドルの間のコンテナと子の関係を表現する。同じことがファイル鍵およびディレクトリ鍵に当てはまる。当該ファイル鍵は、ディレクトリ内のファイルに関連付けられている。例えば、２つのオープンなハンドルＨ１およびＨ２が存在すると仮定する。Ｈ１をファイル鍵＝Ｋ１およびディレクトリ鍵＝Ｄに関連付けてもよい。Ｈ２をファイル鍵＝Ｋ２およびディレクトリ鍵＝Ｄに関連付けてもよい。これらの鍵は、これらのハンドルが参照するファイルが同一のディレクトリ内に存在することを示す。

図６を再度参照すると、動作６１２で、要求されたディレクトリ・メタデータ、およびリースの承認の指示を有する応答パケットをクライアントに送信する。次いでクライアントは、与えられたリースと整合するディレクトリ・メタデータをローカルにキャッシュすることができる。

動作６１４で、ディレクトリ・メタデータを修正する要求を受け取る。当該要求は例えば、追加の情報をファイルに書き込むためのものであってもよい。これにより、例えば最終更新時刻、またはファイル・サイズを変更することでディレクトリ・メタデータが修正される。フローは動作６１４から判定６１６に移り、ディレクトリ・メタデータを修正する要求がリース保持者（ｌｅａｓｅ ｈｏｌｄｅｒ）からのものであるか否かを判定する。

一実施形態では、判定６１６で行う判定が、ディレクトリ・メタデータを修正する動作が行われたハンドルに関連付けられたリース鍵と、予めクライアントに提供されたハンドルに関連付けられたリース鍵とを比較することによって行われる。上述のように、幾つかの実施形態では、クライアントがファイル・ハンドル（またはディレクトリ・ハンドル）に関連付けられたリース鍵を生成し、したがって、各鍵は特定のクライアントに対して一意である。一例では、クライアントに提供されたハンドルＨ１はファイル鍵＝Ｋ１およびディレクトリ鍵＝Ｄに関連付けられる。後にサーバが、ハンドルＨ２に関連付けられたメタデータを修正する動作を受け取った場合、当該サーバはハンドルＨ２に関連付けられたリース鍵をハンドルＨ１に関連付けられたリース鍵と比較する。例えばＨ２がファイル鍵＝Ｋ２およびディレクトリ鍵＝Ｄに関連付けられている場合、当該サーバは、Ｈ１およびＨ２に対するディレクトリ鍵が同一であるため、ディレクトリＤに関するリースを有する同一のクライアントが当該修正を行い、したがって当該リースを失効する必要がないと判定する。一方、Ｈ２がファイル鍵＝Ｋ２およびディレクトリ鍵＝Ｄ１に関連付けられている場合は、サーバは、ハンドルＨ１およびとＨ２に関連付けられたディレクトリ鍵が異なるので、リースを失効しなければならないと判定する。

リース保持者がディレクトリ・メタデータに対する修正を行ったものであると判定した場合は、フローは動作６１８に移り、ファイル・システムを更新して修正されたディレクトリ・メタデータを反映する。次いでフロー６００は６０８で終了する。

動作６１６で、要求がリース保持者からのものでないと判定した場合は、フローは判定６２０に移り、要求された修正が、別のクライアントに与えたリースと不整合であるかどうかを判定する。当該要求が不整合でない場合は、フローは動作６１８に移り、６０８で終了する。

判定６２０で、要求がリースと不整合であると判定した場合は、フローは動作６２２に移り、ディレクトリ・メタデータに関するリースを現在保持しているクライアントに失効通知を送信する。当該失効は、当該ディレクトリ・メタデータにアクセスする全てのクライアントの間でディレクトリ・メタデータの一貫性を保持するために送信されるものである。動作６２４で失効通知の受理を受け取り、その後、フローは動作６１８に移り６０８で終了する。

図７は一般的なコンピュータ・システム７００を示す。当該コンピュータ・システム７００を使用して本明細書に記載の諸実施形態を実装することができる。コンピュータ・システム７００はコンピューティング環境の一例にすぎず、コンピュータおよびネットワーク・アーキテクチャの使用範囲または機能範囲に関して何ら限定を示唆しようとするものではない。また、コンピュータ・システム７００が、例示的なコンピュータ・システム７００で示したコンポーネントのどの１つまたは組合せに関してどのような依存性または要件も有すると解するべきではない。幾つかの実施形態では、システム７００を、図１および図２に関して上述したクライアントおよび／またはサーバとして使用してもよい。

その最も基本的な構成では、システム７００は一般に少なくとも１つの処理装置７０２およびメモリ７０４を備える。コンピューティング装置の厳密な構成および種類に応じて、メモリ７０４は（ＲＡＭのような）揮発性、（ＲＯＭ、フラッシュ・メモリ等のような）不揮発性、またはこれらの何らかの組合せであってもよい。この最も基本的な構成を図７で点線７０６により示す。システム・メモリ７０４は、システム７００上で実行されているアプリケーションを格納する。例えば、メモリ７０４は図２に関して上述したレポート検索テーブル２１４を格納してもよい。

本明細書で使用するコンピュータ読取可能媒体という用語には、コンピュータ記憶媒体を含めてもよい。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラム・モジュール、または他のデータのような情報を記憶するための任意の方法または技術で実装した、揮発性および不揮発性、取外し可能および取外し不能な媒体を含めてもよい。システム・メモリ７０４、取外し可能記憶装置および取外し不能記憶装置７０８は全て、コンピュータ記憶媒体の例である（即ち、メモリ記憶装置）。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、フラッシュ・メモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または情報の格納に使用できコンピューティング装置７００がアクセス可能な他の任意の媒体を含めてもよいが、これらに限らない。任意のかかるコンピュータ記憶媒体が装置７００の一部であってもよい。コンピューティング装置７００はまた、キーボード、マウス、ペン、音声入力装置、タッチ入力装置等のような入力装置（複数可）７１４を有してもよい。ディスプレイ、スピーカ、プリンタ等のような出力装置（複数可）７１６を含めてもよい。上述の装置は例であり、他のものを使用してもよい。

本明細書で使用するコンピュータ読取可能媒体という用語には、通信媒体を含めてもよい。通信媒体を、コンピュータ読取可能命令、データ構造、プログラム・モジュール、または、搬送波もしくは他の伝送機構のような変調データ信号における他のデータで具体化してもよく、また通信媒体には任意の情報伝達媒体を含む。「変調データ信号」という用語は、１つまたは複数の特性集合を有するかまたは当該信号内の情報をエンコードするように変化した信号を言い表すことができる。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続のような有線媒体、ならびに、音響、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）、赤外線、および他の無線媒体のような無線媒体を含んでもよい。

本明細書では「一実施形態」または「実施形態」と言及するが、これは、説明した具体的な機能、構造、または特徴が少なくとも１つの実施形態に含まれることを意味する。したがって、かかる語句を使用することで、単に１つの実施形態より多くの実施形態に言及することができる。さらに、説明した機能、構造、または特徴を１つまたは複数の実施形態において任意の適切な方法で組み合わせてもよい。

しかし、本発明を１つまたは複数の具体的な詳細なしに、または、他の方法、リソース、材料等を用いて実施してもよいことは当業者には理解されよう。他の事例では、公知の構造、リソース、または動作については詳細に図示も説明もしていないが、これは本発明の諸態様を不明瞭にするのを避けるためにすぎない。

例示的な諸実施形態および適用事例を例示および説明したが、本発明は上述の厳密な構成およびリソースに限定されないことは理解されよう。特許請求する発明の範囲から逸脱しない当業者に明らかな様々な修正、変更、および変形を、本明細書で開示した方法およびシステムの配置構成、動作、および詳細において行ってもよい。

Claims (10)

1. ディレクトリ・メタデータをローカルにキャッシュするコンピュータが実行する方法であって、
   ディレクトリ・メタデータに対する第１の要求をアプリケーションから受け取るステップと、
   前記第１の要求を受け取ったことに応答して、前記ディレクトリ・メタデータに対する第２の要求をサーバに送信するステップであって、前記第２の要求が、前記ディレクトリ・メタデータを含むディレクトリへのハンドルに対する要求を含み、さらにディレクトリ・メタデータをローカルにキャッシュするためのリースに対する要求をも含み、前記リースが、前記サーバが前記リースを失効するまでディレクトリ・メタデータのローカルなキャッシュを可能とする、ステップと、
   第１の応答を前記サーバから受け取るステップであって、前記第１の応答が、前記ディレクトリ・メタデータおよび前記リースに対する前記要求の承認の指示を含む、ステップと、
   前記ディレクトリ・メタデータをローカルのキャッシュに格納するステップと、
   前記ディレクトリ・メタデータを前記アプリケーションに提供するステップと
   を含むことを特徴とする方法。
2. 前記ディレクトリ・メタデータに対する第３の要求を第２のアプリケーションから受け取るステップと、
   前記第３の要求を受け取ったことに応答して、前記ディレクトリ・メタデータを前記ローカルのキャッシュから提供するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記第１の要求を受け取ったことに応答して、第１のディレクトリに関連付けられた第１のディレクトリ鍵、および前記第１のディレクトリを含む第２のディレクトリに関連付けられた第２のディレクトリ鍵を生成するステップと、
   前記第１のディレクトリ鍵および前記第２のディレクトリ鍵を、前記サーバに送信される前記第２の要求に含めるステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
4. 前記第２のディレクトリ内に格納されたファイルを修正するための第３の要求を第２のアプリケーションから受け取るステップと、
   前記第３の要求を受け取ったことに応答して、
   前記ファイルに関連付けられたファイル鍵を生成するステップと、
   前記第３の要求からのデータ、前記ファイルに関連付けられた前記ファイル鍵、および前記第２のディレクトリ鍵とともに、第４の要求を前記サーバに送信するステップと、
   をさらに含むことを特徴とする請求項３に記載の方法。
5. 前記サーバから、前記リースの失効の通知を受け取るステップと、
   前記失効の通知を受け取ったことに応答して、
   前記失効の通知の受け取りの受理を送信するステップと、
   前記ディレクトリ・メタデータを前記ローカルのキャッシュから除去するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
6. ディレクトリ・メタデータをローカルにキャッシュできるように構成されたコンピュータ・システムであって、
   少なくとも１つのプロセッサと、
   前記少なくとも１つのプロセッサにより実行されたときに、
   サーバにおいてディレクトリ・メタデータに対する第１の要求を第１のクライアントから受け取るステップであって、前記第１の要求が、前記ディレクトリ・メタデータを含むディレクトリへのハンドルに対する要求を含み、さらにディレクトリ・メタデータをローカルにキャッシュするためのリースに対する要求をも含み、前記リースが、前記サーバが前記リースを失効するまでディレクトリ・メタデータのローカルなキャッシュを可能とする、ステップと、
   第１の応答を送信するステップであって、前記第１の応答が、前記ディレクトリ・メタデータおよび前記リースに対する前記要求の承認の指示を含む、ステップと
   を含む方法を実施する実行可能命令を格納したコンピュータ読取可能記憶媒体と、
   を備えることを特徴とするコンピュータ・システム。
7. 前記方法が、
   第２の要求を受け取るステップと、
   前記第２の要求を第２のクライアントから受け取ったかどうかを判定するステップであって、前記第２の要求が前記ディレクトリ・メタデータを修正するステップと、
   をさらに含むことを特徴とする請求項６に記載のコンピュータ・システム。
8. 前記判定するステップが、
   前記第２の要求からのディレクトリ鍵を、予め格納されたディレクトリ鍵と比較するステップ
   を含むことを特徴とする請求項７に記載のコンピュータ・システム。
9. 前記方法が、
   前記第２の要求からの前記ディレクトリ鍵が予め受け取ったディレクトリ鍵と同一でないと判定したことに応答して、失効通知を前記第１のクライアントに送信して前記リースを失効するステップ
   をさらに含むことを特徴とする請求項８に記載のコンピュータ・システム。
10. 前記方法が、
    前記第１の要求を受け取ったことに応答して、前記ディレクトリに対する前記ハンドルに関連付けられたファイル鍵を生成し、前記ディレクトリの親ディレクトリに関連付けられたディレクトリ鍵を生成するステップと、
    前記ファイル鍵および前記ディレクトリ鍵を、前記サーバに送信される前記第１の応答に含めるステップと
    をさらに含むことを特徴とする請求項６に記載のコンピュータ・システム。

Images