JP4617297B2 - ファイル・システムのオブジェクトへのアクセスを管理する方法、システム及び記憶媒体 - Google Patents

Description

本発明は、一般には、コンピューティング環境内部での処理に関し、より詳細には、コンピューティング環境のオブジェクトへのアクセスを管理することに関する。

あるコンピューティング環境の、ファイル、ディレクトリなど、様々なオブジェクトへのアクセスは、セキュリティを提供し、データ完全性を保つために制御される。多くのコンピューティング環境では、この制御にロッキング・プロトコルを使用する。たとえば、分散ファイル・システムでは、ファイル・システム・オブジェクトへのアクセスの管理は、複数のロックによって行われる。例として、ロックには、ファイル・システムの内容のキャッシュの協調に使用されるものもあり、異なるクライアントによるファイル・システム・オブジェクトへのアクセスの協調に使用されるものもある。

システムのパフォーマンスを高めるために、１つ又は複数のロックのキャッシュが、１つ又は複数のクライアント・キャッシュ内で行われる。したがって、キャッシュされるロックが、使用の時点で有効であるようにすることが重要である。キャッシング・プロトコルが存在しているとはいえ、キャッシュされるロック、又は他のキャッシュされるエンティティをさらに管理する機能がやはり必要とされている。

従来技術の欠点に対する取り組み及び付加的な利点の提供が、コンピューティング環境のオブジェクトへのアクセスを管理する方法の提供によって行われる。

本発明の一態様では、たとえば、前記コンピューティング環境のオブジェクトへのアクセスの禁止を前記オブジェクトに対応するキャッシュ済みエンティティを介して行うこと、及び、前記オブジェクトへのアクセスの許可を前記オブジェクトに対応する別のキャッシュ済みエンティティを介して行うことを含み、前記キャッシュ済みエンティティ及び前記別のキャッシュ済みエンティティが、一定の時間、コンカレントに維持される方法が提供される。

本発明のさらなる一態様では、ファイル・システムのオブジェクトへのアクセスを管理する方法であって、たとえば、前記ファイル・システムのサーバが、前記ファイル・システムのオブジェクトに対応するエンティティの一貫性のない状態を提供することを容易にすること、前記ファイル・システムのクライアントが、前記オブジェクトの１つ又は複数の既存のオープンの無効化を、前記一貫性のない状態に応答して行うこと、及び、前記クライアントが、前記オブジェクトの１つ又は複数の他のオープンの許可を、前記サーバから提供中のオブジェクトに対応する別のエンティティに応答して行うことを含み、少なくとも１つの無効化された既存のオープン及び少なくとも１つの他のオープンが、一定の時間、コンカレントにオープンの状態にある方法が提供される。

本発明の別の一態様では、コンピューティング環境のオブジェクトへのアクセスを管理する方法であって、たとえば、前記コンピューティング環境のサーバが、前記コンピューティング環境のオブジェクトに関連付けられているエンティティの一貫性のない状態の提供を容易にすること、及び、前記サーバが、前記オブジェクトに関連づけられている別のエンティティを提供することを含み、前記一貫性のないエンティティ及び前記別のエンティティが、前記オブジェクトへのアクセスの管理のために、一定の時間、コンカレントにアクセス可能である方法が提供される。

上で要約した方法に対応するシステム及びコンピュータ・プログラム製品に対しても、本明細書では説明及び特許請求を行う。

さらなる機能及び利点が、本発明の技法を通して実現される。本発明の他の実施形態及び態様は、本明細書中で詳細に説明を行い、特許請求を行う発明の一部と見なす。

本発明と見なされる主題（subject matter）は、特に指摘を行い、本明細書に添付の特許請求の範囲で明確に特許請求を行う。本発明の以上及び他の目的、特徴、及び利点は、添付の図面と合わせて解釈する以下の詳細な説明から明らかである。

概要
本発明の一態様によれば、コンピューティング環境のオブジェクトへのアクセスを管理するための機能が提供される。オブジェクトへのアクセスの禁止は、そのオブジェクトに対応するあるキャッシュ済みエンティティを介して行うが、そのオブジェクトへのアクセスの許可は、別のキャッシュ済みエンティティを介して行う。このあるキャッシュ済みエンティティ及びこの別のキャッシュ済みエンティティは、少なくともある時間の間、コンカレントに維持される。ある例では、キャッシュ済みエンティティは、オブジェクトへのアクセスを制御するロックに相当する。たとえば、ファイル・システムでは、ファイル・システム・オブジェクトの１つ又は複数の既存のオープンの無効化を、一貫性のなくなるファイル・システム・オブジェクトに関連付けられているキャッシュ済みエンティティ（たとえば、ロック）に応答して行う。しかし、少なくとも１つの無効化された既存のオープンを、無効であるがオープンの状態で維持する一方で、ファイル・システム・オブジェクトの１つ又は複数の新しいオープンを、そのオブジェクトを代表する別のキャッシュ済みエンティティを使用することによって進めることを許可している。

詳細な説明
本発明の１つ又は複数の態様を組み込み使用するためのコンピューティング環境のある実施形態を、図１を参照して説明する。コンピューティング環境１００は、たとえば、接続１０６を介して別のコンピューティング・ユニット１０４へと結合されるコンピューティング・ユニット１０２を含む。コンピューティング・ユニットは、たとえば、パーソナル・コンピュータ、ラップトップ、ワークステーション、メインフレーム、ミニ・コンピュータ、又は他のどのようなタイプのコンピューティング・ユニットも含む。コンピューティング・ユニット１０２は、コンピューティング・ユニット１０４と同じタイプのユニットであってもなくてもよい。ユニットを結合する接続は、有線接続、又は、ＬＡＮ（local area network、構内通信網）、ＷＡＮ（wide area network、広域通信網）、トークン・リング、イーサネット（Ｒ）接続、インターネット接続などの任意のタイプのネットワーク接続である。

ある例では、コンピューティング・ユニットが、それぞれ、オペレーティング・システム１０８を実行しており、これは、たとえば、ニューヨーク州アーモンク（Armonk, New York）にあるインターナショナル・ビジネス・マシーンズ・コーポレーション（InternationalBusiness Machines Corporation、IBMはIBM Corporationの商標）の提供するｚ／ＯＳオペレーティング・システム、ＵＮＩＸ（Ｒ：OpenGroupの米国およびその他の国における商標）オペレーティング・システム、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ（Ｒ：Microsoft Corporationの米国およびその他の国における商標）、又は他のオペレーティング・システムなどである。あるコンピューティング・ユニットのオペレーティング・システムは、別のコンピューティング・ユニットと同じでも異なっていてもよい。さらに、他の例では、コンピューティング・ユニットのうちの１つ又は複数はオペレーティング・システムを含んでいなくてもよい。

ある実施形態では、コンピューティング・ユニット１０２は、コンピューティング・ユニット１０４上の（サーバとしても知られる）サーバ・アプリケーション１１２に結合される（クライアントとしても知られる）クライアント・アプリケーション１１０を含む。クライアント１１０のサーバ１１２との通信は、たとえば、アプリケーションを結合するＴＣＰ／ＩＰリンク上のＮＦＳ（Network File System）プロトコルを介して行われる。さらに、少なくとも１つのコンピューティング・ユニット上で、１つ又は複数のユーザ・アプリケーション１１４が実行中である。

ある特定の実施形態では、環境は、分散ファイル・システムなどのファイル・システム（図２）を含み、そこでは、ＳＡＮ（storage area network、ストレージ・エリア・ネットワーク）１１６が、１つ又は複数のクライアント１１０及び１つ又は複数のサーバ１１２が１つ又は複数のストレージ装置１１８への高速リンクを介したアクセスを容易にするために使用されている。ＳＡＮの使用により、高性能分散ファイル・システムの提供が可能になり、これにより、クライアントは、データのアクセスを、読み書きをそれ自体のために行うサーバを通して行うのではなく、データをストレージ装置から直接に得ることが可能になる。しかし、クライアント・アクセスの協調が、１つ又は複数のサーバを介して行われる。

分散ファイル・システムでは、たとえば、ユーザ・アプリケーション、クライアント・アプリケーションなどを含むクライアント・コンピューティング・ユニット上で動作するアプリケーションで、たとえば、１つ又は複数のコンピューティング・ユニットにわたって分散するファイル・システム名前空間へのアクセスが行われる。名前空間は、アプリケーションによってアクセス可能な１つ又は複数のファイル・システム・オブジェクトを含む。ある例では、名前空間はツリー構造として整理され、たとえば、クライアントにアクセス可能なデータを含むファイル、他のオブジェクトの整理に使用するディレクトリ、オブジェクトの名前ルックアップのリダイレクトが行われるツリー内の点であるシンボリック・リンクなど、様々なタイプのオブジェクトを含む。

ファイル・システム・オブジェクトには、たとえば、ファイル・システム・オブジェクトへのアクセスを容易にするのに使用するエンティティが関連付けられている。こうしたエンティティは、クライアント常駐キャッシュ１２０内で、より高速なアクセスのためにキャッシュされる。ある実施形態では、１つ又は複数のアプリケーション（たとえば、ユーザ・アプリケーション、クライアント・アプリケーション）が、キャッシュ済みエンティティへのアクセス権をもつ。

キャッシュ済みエンティティには、これに関連付けられている複数の属性があるが、それには、たとえば、何個のアプリケーションがそのエンティティに対するハンドルを有するかを示す参照カウント、そのキャッシュ済みエンティティが有効であるかどうかを指定する有効性インジケータがある。キャッシュ済みエンティティは、一例としてはリンク・リスト（linked list）２００（図３）などのデータ構造の形で互いに結合されている。

ファイル・システム・オブジェクトへのアクセスは、セキュリティ及びデータ完全性を維持するために制御される。ファイル・システム・オブジェクトへのアクセスを管理することに関連付けられている論理のある実施形態を下で説明する。

まず図５を参照すると、アプリケーションが、（ファイルなど）ファイル・システム・オブジェクトのオープンを要求する（ステップ３００）。ある例では、このアプリケーションは、クライアント・コンピューティング・ユニット上で実行中であり、このオープンは、そのクライアントのキャッシュ内で要求されたファイル・システム・オブジェクトに関連付けられているエンティティに対する検索を実行することを含む（ステップ３０２）。このエンティティは、そのファイル・システム・オブジェクトへのアクセスを容易にする際に使用され、例示の目的で、本明細書ではエンティティＸと呼ぶ。関連付けられているエンティティがキャッシュ内にない場合（問い合わせ３０４）、そのエンティティのインスタンスを作成し、キャッシュに追加する（ステップ３０６）。これは、たとえば、２０２で示すように（図４）、エンティティＸをキャッシュ済みエンティティのリンク・リストの最後に追加する（appending）ことを含む。図５に戻って、この後、このキャッシュ済みエンティティの参照カウントをインクリメントし（ステップ３０８）、このエンティティに対するハンドルを計算する（ステップ３１０）。ある例では、このことは、ハンドル（たとえば、ハンドルＨｘ）として返されるキャッシュ済みエンティティのアドレスを決定することを含む（ステップ３１２）。

戻って問い合わせ３０４を参照すると、キャッシュ検索が万一成功した場合は、キャッシュ済みエンティティの参照カウントをインクリメントし（ステップ３０８）、処理では続いてエンティティのハンドルの計算を行う（ステップ３１０）。これでオープンの処理が終わる。

クライアント・コンピューティング・ユニット上で実行中の１つ又は複数のアプリケーションは、同一のファイル・システム・オブジェクトのオープンを要求することができる。そのような場合、アプリケーションのそれぞれが、図６に示すように、クライアントから同じハンドルを得ることができる。ここに示すように、アプリケーション１〜４は、それぞれ、処理のため、ハンドルＨｘを受け取り使用している。

アプリケーションの処理の間、読み取り又は書き込みの操作などの操作の要求が、このオープンされたファイル・システム・オブジェクトに対して行われる。この処理の一部として、ファイル・システム・オブジェクトへのアクセスを容易にする際に使用する、キャッシュ済みエンティティの有効性に関する検査を行う。この検査に関連付けられている論理のある実施形態を、図７を参照して説明する。有効性に関して検査すべきキャッシュ済みエンティティは、オープンで返されたオブジェクト・ハンドルに対応するエンティティである（ステップ５００）。ある例では、この検査は、キャッシュ済みエンティティの有効性インジケータを検査することを含む。エンティティが無効状態にある場合（問い合わせ５０２）、エラーが返される（ステップ５０４）。そうでない場合、成功の標示が返される（ステップ５０６）。

ある時点で、キャッシュ済みエンティティの一貫性がなくなることがあるかもしれない。キャッシュ済みエンティティに一貫性が万一なくなった場合には、図８を参照して説明するように、これをシャドウ・エンティティへと変換する。キャッシュ済みエンティティに一貫性がなくなるのに応答して（ステップ６００）、キャッシュ内でキャッシュ済みエンティティ、たとえばエンティティＸに関する検索を行う（ステップ６０２）。そのキャッシュ済みエンティティを、エンティティのリンク・リストから削除する（ステップ６０４）。しかし、そのエンティティはキャッシュ内にシャドウ・エンティティ（すなわち、スタンド・アロンのエンティティ）として残る（ステップ６０６）。たとえば、そのエンティティはキャッシュの別の部分へと移動され、シャドウ・エンティティとマークされる。このことの一例を図９に示してあり、そこではキャッシュ７００にはシャドウ・エンティティ７０２がある。この後、キャッシュの統計量を更新する（ステップ６０８）（図８）。たとえば、このキャッシュに対するエンティティ・カウントをデクリメントする。

本発明の一態様によれば、古いオープンはどれも、オープンの際に受け取ったハンドルを使用しているエンティティを依然として参照するが、新しいオープンはどれも、そのエンティティがもはやメインのエンティティ・ハッシュ・テーブル・リスト（たとえば、リンク・リスト）内にないため、キャッシュ・ミスを引き起こすことになる。このため、そのエンティティがキャッシュへと持ち込まれ、新しいハンドルを持つことになる。したがって、図９の例に示すように、アプリケーション１〜４ではまだハンドルＨｘを使用しており、このためエラーが返されることになるが（７０４）、アプリケーション５は、新しいハンドルＮＨｘを受け取り、このためアクセスの成功が可能になる（７０６）。したがって、アプリケーション１〜４に関連付けられているオープンは無効化されるが、アプリケーション５に関連付けられているオープンは許可される。無効化されたオープン及び許可されたオープンは、一定の時間（たとえば、一貫性のないキャッシュ・エンティティがクローズされるまで）、コンカレントにオープンの状態のまま残る。アプリケーション１〜４がこのエンティティをクローズした後、このエンティティはなくなり、これらのアプリケーションではもはやこのエンティティに関してオープンの状態ではなくなる。

キャッシュ済みエンティティをクローズすることに関連付けられている論理のある実施形態を、図１０を参照して説明する。オープンで返されたハンドルをもつエンティティ上のクローズが行われる（ステップ８００）。キャッシュ済みエンティティの参照カウントをデクリメントする（ステップ８０２）。参照カウントが０でない場合（問い合わせ８０４）、クローズの処理は完了する。しかし、参照カウントが０の場合、それがシャドウ・エンティティであるかどうかに関して判断を行う（問い合わせ８０６）。そうである場合、そのエンティティの割り当てを解除する（deallocated）（ステップ８０８）。そうでない場合、そのエンティティをキャッシュから削除する（ステップ８１０）。これでクローズの処理が終わる。

上で説明したのは、オブジェクトの新しいオープンが許可されるが、古いオープンに対する動作が禁止される機能である。この機能を使用するある特定の例が、分散ファイル・システム用のロッキング機構の場合にある。たとえば、ファイル・システムでは、本明細書中ではセッション・ロックと呼ぶ、分散ロックを使用して、ファイル・システムの異なるクライアントの間でのファイル・システム・オブジェクトへのアクセスを制御している。ある例では、クライアントにはそれぞれ、ファイル・システム・オブジェクトごとにセッション・ロックが１つあるが、このロックは、そのクライアントに関連付けられている２つ以上のアプリケーションのために働いている可能性がある。たとえば、クライアント１が、ファイル「Ｆｏｏ」というファイル・システム・オブジェクト用の、エンティティＸというセッション・ロックを得る。このクライアントの１つ又は複数のアプリケーションでは、このロックを、ファイルにアクセスする（たとえば、読み取り、書き込み、作成、検索（find））際に使用する（通常、暗黙にであるが、他の実施形態では明示的にも可能である）。このことは、さらに下で図１１〜１２を参照して説明する。

アプリケーションがファイル・システム・オブジェクトのオープンを要求すると（ステップ９００）、オープン要求がそのアプリケーションからクライアントへと（たとえば、プラットフォーム独立であるＣＳＭ（Client State Manager）へ、プラットフォーム依存であるＩＦＳ（Installable File System）を介して）送られる（ステップ９０２）。クライアントでは、ファイル・システム・オブジェクトに対するセッション・ロックがあるかどうか、そのキャッシュの検査を行う（ステップ９０４）。キャッシュ・ヒットのある場合（問い合わせ９０６）、成功がクライアントへと返される（ステップ９０８）。そうでない場合、クライアントは要求をサーバに送り、サーバがその要求を処理する（ステップ９１０）。許可が成功しない場合（問い合わせ９１２）、エラーが返される（ステップ９１４）。そうでない場合、サーバからの成功の応答により、ファイル・システム・オブジェクトに対するセッション・ロックが要求されたクライアントに対して許可される（ステップ９１６）。クライアントはセッション・ロックをキャッシュし（ステップ９１７）、したがって、後続のオープンでは、クライアントは成功をローカルに返す。同一のファイル・システム・オブジェクトに対して動作しているあるクライアントに関連付けられている異なるアプリケーションには、異なるファイル記述子があっても、セッション・ロックが１つしかない可能性がある。

クライアントは、キャッシュしたセッション・ロックのハンドル（たとえば、アドレス）を、オープンを要求しているアプリケーションに提供する（ステップ９１８）。このハンドルは、この後、さらなる処理で使用される。

たとえば、成功したオープンに応答して、オープンされたファイル・システム・オブジェクトに対する１つ又は複数の操作（たとえば、読み取り、書き込み、検索（find）、又は他の操作）が開始される（ステップ９２０）（図１２）。操作ごとに、セッション・ロックの有効性に関して検査を行う（問い合わせ９２２）。ある例では、セッション・ロックが、そのロックに関連付けられているリースが期限切れとなるときに無効となる可能性がある。たとえば、リースは、クライアントとサーバの間の契約であり、その中で、サーバは、クライアントのキャッシュ内のデータの正確さを、そのリースに指定された特定の期間保証する。リースは、期限切れになる前に更新することができる。しかし、リースが（たとえば、接続切断（disconnect）、サーバのクラッシュ、又は他の何らかの理由で）更新されない場合、リース期間の終わりに、リースの間に得たロックは無効化される。したがって、クライアントは、有効なロックがないときには、キャッシュされたデータに対して操作を行うことができない。このため、操作を続けるためには、クライアントはサーバに対して認証をやり直して、新しいリースを開始し、無効なロックの再アサートを試みる（ステップ９２４）。成功した場合、ロックの無効状態はクライアントによって有効に変わり、操作が続く（ステップ９２８）。同様に、セッション・ロックが有効である場合（問い合わせ９２２）、処理は続行される。

しかし、再アサートが成功しなかった場合（問い合わせ９２６）、セッション・ロックは一貫性のない状態にある（ステップ９３０）。このため、様々な動作を行う（ステップ９３２）。たとえば、ファイル・システム・オブジェクトのオープンのインスタンスはどれも無効化される。オープンのインスタンスを無効化するには、キャッシュされているセッション・ロックをシャドウ・エンティティにするために、クライアントは、それをシャドウ・エンティティとマークし、キャッシュ・リストから取り除き、スタンド・アロンのエンティティとしてキャッシュに残す。ロックはキャッシュ・リストから取り除かれているため、セッション・ロックへの既存の参照は（たとえば、そのシャドウの状態が理由で）エラーを受け取り、これにより、それらの参照に関連付けられているオープンが無効化されることになる。ロックがスタンド・アロンのエンティティとしてキャッシュ内で維持されるのは、そのオブジェクトへの既存の参照が途絶える（dropped）までである。この後、このエンティティはクローズされる。しかし、そのシャドウ・エンティティに対応するファイルへの新しいアクセス（たとえば、オープン）により、新しいキャッシュ済みエンティティ（たとえば、新しいセッション・ロック）が作成され、新しいアクセスは正常に続けられることが可能になる。つまり、クライアントから見ると、これはそのロックに初めてアクセスするようなものである。したがって、クライアントは、セッション・ロック要求をサーバへと送り、新しいセッション・ロックを返してもらう。このセッション・ロックへの新しい参照は正しく働くが、古いロックへの参照はエラーを受け取る。

利点
ファイル・システム・オブジェクトへのアクセスを管理するための機能を、上で詳細に説明した。ファイル・システム・オブジェクトの１つ又は複数の既存のオープンが無効化される可能性がある一方で、１つ又は複数の新しいオープンが許可される。ある例では、これは、キャッシュ済みエンティティ、特にシャドウ・エンティティを介して達成される。シャドウ・エンティティの使用により、所望の管理の利益が既存の設計又はコードあるいはその両方における最小限の変更で、有利に提供される。さらに、これにより、システムのパフォーマンスの改善が、１つ又は複数の古いオープンがまだクローズされていなくても、ファイル・システム・オブジェクトにアクセスできるようにすることによって行われる。またさらに、キャッシュ済みエンティティをこのように維持することによって、クライアント・キャッシュを不必要に大きくし維持を困難にするはずの、オープンごとにセッション・ロックのインスタンスを１つ有する必要がない。

代替実施形態
本明細書では好ましい実施形態を詳細に示し説明してきたが、様々な修正、追加、代用などを本発明の趣旨から逸脱することなく行え、したがってこれらは、以下の特許請求の範囲の定める、本発明の範囲内にあると見なされることが当業者には明らかであろう。

たとえば、上で説明したある実施形態では、１つのクライアントが１つのサーバに結合されているが、他の実施形態では、１つ又は複数のクライアントが１つ又は複数のサーバに結合され、あるいは、その任意の組み合わせの可能性がある。この１つ又は複数のクライアントは、１つ又は複数のコンピューティング・ユニット上にある可能性がある。同様に、この１つ又は複数のサーバは、１つ又は複数のコンピューティング・ユニット上にある可能性がある。さらに、この１つ又は複数のクライアント及び１つ又は複数のサーバは、１つのコンピューティング・ユニット上にある可能性がある。

さらに、コンピューティング環境の例を与えているが、これらは例に過ぎない。他の環境を使用してもよい。たとえば、本明細書ではファイル・システムに関して一例を説明したが、これは１つの例に過ぎない。本発明の１つ又は複数の態様は、他の環境に適用可能である。またさらに、本明細書では、セッション・ロックに関して一例を説明したが、他のタイプのロック又は他のタイプの資源を説明することもできる。キャッシュ済みエンティティは、ロッキング以外のためでもよく、他の理由で使用することが可能である。一例としては、キャッシュ済みエンティティは、あるオブジェクトのインスタンス自体であってもよい。

しかも、上で説明した諸実施形態では、キャッシュ・エンティティに一貫性がなくなるのは、期限切れのリースに応答してであるが、キャッシュ済みエンティティに一貫性がなくなる他の様々な理由があってもよい。これらはすべて、特許請求を行う発明の一部と見なされる。さらに、エンティティのキャッシュしたリストは、リンク・リスト以外のデータ構造内にあるとすることができる。

またさらに、ファイル・システム・オブジェクトへのアクセスを要求するアプリケーションは、ユーザ・アプリケーション、クライアント・アプリケーション、又は他などのようなタイプのアプリケーションも含むがこれに限定されない様々なアプリケーションとすることができる。

本明細書で示した流れ図は、単なる例である。これらの図及び又はそこに説明したステップ（又は操作）には、本発明の趣旨を逸脱することなく、多くの変種があってよい。たとえば、ステップは異なる順序で行ってもよく、又はステップを追加、削除、又は変更してもよい。こうした変種のすべては、特許請求を行う発明の一部と見なされる。

本発明は、たとえば、コンピュータ可用媒体を有する製造物（たとえば、１つ又は複数のコンピュータ・プログラム製品）に含めることが可能である。この媒体には、その中に、たとえば、本発明の諸機能を提供し容易にするコンピュータ可読プログラム・コード手段又は論理（たとえば、命令、コード、コマンドなど）がある。製造物は、コンピュータ・システムの一部として含めることも、別々に販売することも可能である。

さらに、機械で読み取り可能であり、本発明の諸機能を行うためにその機械で実行可能な命令からなる少なくなくとも１つのプログラムを実施する少なくとも１つのプログラム・ストレージ装置を提供することが可能である。

本開示の範囲は、本明細書に開示するどのような新規な特徴又は諸特徴の組み合わせも含む。出願者は、ここに、新しい特許請求の範囲をそのような特徴又は諸特徴の組み合わせに対して述べることを、この出願又はこれから派生するさらなるどのような出願に対する審査手続（prosecution）中に行えることを告知する。特に、後続の特許請求の範囲に関しては、従属請求項からの特徴は、独立請求項の特徴と組み合わせることができ、それぞれの独立請求項からの特徴は、どのような適切なやり方でも、単に特許請求の範囲に列挙した特定の組み合わせでなく組み合わせることができる。

疑念を避けるために、本明細書で説明及び特許請求の範囲を通して使用する「含む」（comprising）という用語は、「だけからなる」（consistingonly of）を意味するものと解釈すべきではない。

本発明の１つ又は複数の態様を組み込み使用するためのコンピューティング環境のある実施形態を示す図である。 本発明の１つ又は複数の態様を組み込み使用するためのファイル・システムを示す図である。 本発明の一態様による、図２のクライアント・キャッシュの例を示す図である。 本発明の一態様による、図２のクライアント・キャッシュの例を示す図である。 本発明の一態様による、ファイル・システム・オブジェクトをオープンすることに関連付けられている論理のある実施形態を示す図である。 本発明の一態様による、そのハンドルに対応するファイル・システム・オブジェクトへのアクセスに使用される同一のハンドルを有する複数のアプリケーションを示す図である。 本発明の一態様による、キャッシュ済みエンティティの有効性を検査することに関連付けられている論理のある実施形態を示す図である。 本発明の一態様による、キャッシュ済みエンティティをシャドウ・エンティティへと変換することに関連付けられている論理のある実施形態を示す図である。 本発明の一態様による、古いエンティティ・ハンドルを使用しエラーを受け取るアプリケーションの一例を、新しいエンティティ・ハンドルを使用する別のアプリケーションの処理が成功する一方で示す図である。 本発明の一態様による、キャッシュ済みエンティティをクローズすることに関連付けられている論理のある実施形態を示す図である。 本発明の一態様を使用する特定の例に関連付けられている論理のある実施形態を示す図である。 本発明の一態様を使用する特定の例に関連付けられている論理のある実施形態を示す図である。

Claims (16)

1. クライアント及びサーバーを含むファイル・システムのオブジェクトへのアクセスを管理する方法であって、
   前記クライアント内のキャッシュのリンク・リスト内にあり且つ前記ファイル・システムのオブジェクトに対応する第１セッション・ロックがリースが期限切れになり新しいリースの開始が成功しなかった場合に応答して生じる状態である一貫性がない状態にあることを前記クライアントが見出すステップと、
   前記ファイル・システムのクライアントが、前記第１セッション・ロックが前記一貫性がない状態にあることに応答して、前記第１セッション・ロックを前記リンク・リストからはずして前記キャッシュ内に残すことによりシャドウの状態にするステップと、
   前記第１セッション・ロックを前記シャドウの状態にした後に、前記クライアントのアプリケーションが前記ファイル・システムの同じオブジェクトをオープンしたことに応答して、前記クライアントが、前記ファイル・システムの前記同じオブジェクトに対応する新たな第２セッション・ロックを前記キャッシュのリンク・リストに追加するステップとを含み、
   前記シャドウの状態にされた前記第１セッション・ロックがクローズされるまでの時間、前記シャドウの状態にされた前記第１セッション・ロック及び前記第２セッション・ロックが、前記キャッシュ内にコンカレントに維持される、方法。
2. 前記シャドウ状態にされた前記第１セッション・ロックを介する前記オブジェクトへのアクセスが前記クライアントにより禁止され、前記第２セッション・ロックを介する前記同じオブジェクトへのアクセスが前記クライアントにより許可される、請求項１に記載の方法。
3. 前記一貫性がない状態にあることを前記ファイル・システムが見出すステップの前に、
   前記クライアントの第１アプリケーションが前記ファイル・システムのオブジェクトをオープンしたことに応答して、前記クライアントが、前記ファイル・システムの前記オブジェクトに対応する前記第１セッション・ロックを前記キャッシュのリンク・リストに追加するステップを行い、
   前記ファイル・システムの同じオブジェクトをオープンした前記クライアントのアプリケーションが第２アプリケーションである、請求項１に記載の方法。
4. 前記第１セッション・ロックを前記キャッシュのリンク・リストに追加するステップの後に、
   前記クライアントが前記第１セッション・ロックのハンドルを前記第１アプリケーションに与えるステップが行われる、請求項３に記載の方法。
5. 前記第２セッション・ロックを前記キャッシュのリンク・リストに追加するステップの後に、前記クライアントにより前記第２セッション・ロックのハンドルが前記第２アプリケーションに与えられる、請求項３又請求項４に記載の方法。
6. 前記第１セッション・ロックを前記リンク・リストからはずして前記キャッシュ内に維持することによりシャドウの状態にした後に行われる、前記第１セッション・ロックのハンドルを使用する前記第１アプリケーションの前記オブジェクトへのアクセスが前記クライアントにより禁止され、
   前記第２セッション・ロックのハンドルを使用する前記第２アプリケーションの前記オブジェクトへのアクセスが前記クライアントにより許可される、請求項４又は請求項５に記載の方法。
7. 前記シャドウの状態にされた前記第１セッション・ロックがクローズされた後に、前記クライアントが前記シャドウ状態にある前記第１セッション・ロックを前記キャッシュから削除する、請求項１に記載の方法。
8. 前記第１セッション・ロックは、何個のアプリケーションが前記第１セッション・ロックに対するハンドルを有するかを示す参照カウントを有し、前記シャドウの状態にされた前記第１セッション・ロックがクローズされるまでの時間は、前記シャドウの状態にある前記第１セッション・ロックの参照カウントがゼロになるまでの時間である、請求項１に記載の方法。
9. クライアント及びサーバーを含むファイル・システムのオブジェクトへのアクセスを管理するシステムであって、
   前記クライアント内のキャッシュのリンク・リスト内にあり且つ前記ファイル・システムのオブジェクトに対応する第１セッション・ロックがリースが期限切れになり新しいリースの開始が成功しなかった場合に応答して生じる状態である一貫性がない状態にあることを前記クライアントが見出し、
   前記ファイル・システムのクライアントが、前記第１セッション・ロックが前記一貫性がない状態にあることに応答して、前記第１セッション・ロックを前記リンク・リストからはずして前記キャッシュ内に残すことによりシャドウの状態にし、
   前記第１セッション・ロックを前記シャドウの状態にした後に、前記クライアントのアプリケーションが前記ファイル・システムの同じオブジェクトをオープンしたことに応答して、前記クライアントが、前記ファイル・システムの前記同じオブジェクトに対応する新たな第２セッション・ロックを前記キャッシュのリンク・リストに追加し、
   前記シャドウの状態にされた前記第１セッション・ロックがクローズされるまでの時間、前記シャドウの状態にされた前記第１セッション・ロック及び前記第２セッション・ロックが、前記キャッシュ内にコンカレントに維持される、システム。
10. 前記シャドウ状態にされた前記第１セッション・ロックを介する前記オブジェクトへのアクセスが前記クライアントにより禁止され、前記第２セッション・ロックを介する前記同じオブジェクトへのアクセスが前記クライアントにより許可される、請求項９に記載のシステム。
11. 前記一貫性がない状態にあることを前記ファイル・システムが見出す前に、
    前記クライアントの第１アプリケーションが前記ファイル・システムのオブジェクトをオープンしたことに応答して、前記クライアントが、前記ファイル・システムの前記オブジェクトに対応する前記第１セッション・ロックを前記キャッシュのリンク・リストに追加し
    前記ファイル・システムの同じオブジェクトをオープンした前記クライアントのアプリケーションが第２アプリケーションである、請求項９に記載のシステム。
12. 前記第１セッション・ロックを前記キャッシュのリンク・リストに追加した後に、前記クライアントが前記第１セッション・ロックのハンドルを前記第１アプリケーションに与える、請求項１１に記載のシステム。
13. 前記第２セッション・ロックを前記キャッシュのリンク・リストに追加した後に、前記クライアントにより前記第２セッション・ロックのハンドルが前記第２アプリケーションに与えられる、請求項１１又請求項１２に記載のシステム。
14. 前記第１セッション・ロックを前記リンク・リストからはずして前記キャッシュ内に維持することによりシャドウの状態にした後に行われる、前記第１セッション・ロックのハンドルを使用する前記第１アプリケーションの前記オブジェクトへのアクセスが前記クライアントにより禁止され、
    前記第２セッション・ロックのハンドルを使用する前記第２アプリケーションの前記オブジェクトへのアクセスが前記クライアントにより許可される、請求項１２又は請求項１３に記載のシステム。
15. 前記シャドウの状態にされた前記第１セッション・ロックがクローズされた後に、前記クライアントが前記シャドウ状態にある前記第１セッション・ロックを前記キャッシュから削除する、請求項９に記載のシステム。
16. 前記第１セッション・ロックは、何個のアプリケーションが前記第１セッション・ロックに対するハンドルを有するかを示す参照カウントを有し、前記シャドウの状態にされた前記第１セッション・ロックがクローズされるまでの時間は、前記シャドウの状態にある前記第１セッション・ロックの参照カウントがゼロになるまでの時間である、請求項９に記載のシステム。

Images