(57)【要約】【課題】好適な分散ファイル・システムおよび方法を提供すること。【解決手段】分散ファイルシステムおよび方法が、それぞれが唯一のファイルシステムノードに所有されている複数の自己完結のボリュームを横断して、ファイルシステムオブジェクトを分散させる。ボリューム間でファイルシステムオブジェクトを参照するため、論理リンクが使用される。各ファイルシステムノードが、リロケーションディレクトリを含んでおり、このリロケーションディレクトリに、ローカルに保存され、論理リンクを使用して他のファイルシステムノードから参照されるファイルシステムオブジェクトへのハードリンクが保持される。複数のボリュームが関係する種々のファイルシステム操作が、書き込みロックを一度に２つ以上のボリュームに置くことなく実行される。【選択図】なし【特許請求の範囲】
【請求項１】
本明細書に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（技術分野および背景技術）
本発明は、コンピュータのファイル・システムに関し、とくにはファイル・システム・オブジェクトが複数のファイル・システム・ノード上の複数の自己完結ボリュームに分散されているファイル・システムに関する。
【発明の概要】
【課題を解決するための手段】
【０００２】
（発明の開示）
ネットワーク接続型ストレージ（ＮＡＳ）ノードのクラスタにおける分散ファイル・システムおよび方法は、ファイル・システム・オブジェクトを多数の自己完結ボリュームにわたって分散させており、各ボリュームが、固有のクラスタ・ノードに所有されている。ボリューム間でファイル・システム・オブジェクトを参照するため、論理リンクが使用される。各ファイル・システム・オブジェクトは、当該オブジェクトのコンテンツがどこに保存されているのかを複数の属性（長さ、および所有者情報など、を含む）とともに記述する「ｉ−ｎｏｄｅ」と呼ばれるメタデータ構造によって実装されている。各クラスタ・ノードは、リロケーション・ディレクトリを含んでおり、該リロケーション・ディレクトリが、ローカルに保存され、論理リンクを使用して他のクラスタ・ノードから参照されるファイル・システム・オブジェクトへのハード・リンクを保持している。複数のボリュームが関与するさまざまなファイル・システム操作が、一度に２つ以上のボリュームに書き込みロックを置く必要なく実行される。さまざまなキャッシュの仕組みが、種々のクラスタ・ノードがファイル・システム・オブジェクト・データおよびメタデータをキャッシュできるようにしている。
【０００３】
本発明の一実施の形態においては、それぞれが複数の論理ストレージ・ボリュームへのアクセスを有している複数のクラスタ・ノードを使用して、該ノードと通信するクライアントによる前記ボリューム上のデータへのアクセスを提供するための方法が提供される。この方法は、所与のストレージ・ボリュームのデータまたはメタデータのコンテントを変更する操作（本明細書では、広く「書き込み」と称する）を、該ボリュームを所有しているとみなされる唯一のクラスタ・ノードによってのみ実施可能にすること、および、第１のクラスタ・ノードに、該第１のクラスタ・ノードが所有する第１のボリュームへのファイル・システム・オブジェクトの保存を実行させ、さらに前記第１のボリュームと第２のクラスタ・ノードが所有する第２のボリュームとの間の論理リンクを、該論理リンクが前記第１のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成することによって、ファイル・システム・オブジェクトを複数のボリュームを横断して保持することを含んでいる。ファイル・システム・オブジェクトは、ファイルまたはディレクトリであってよい。
【０００４】
この方法は、記論理識別子を、前記第１のボリュームのリロケーション・ディレクトリであって、前記第１のボリューム以外のボリュームから論理的に参照される前記第１のボリューム内のすべてのファイル・システム・オブジェクトについての論理識別子を列挙しているリロケーション・ディレクトリに保存することを含むことができる。リロケーション・ディレクトリは、通常は、階層構造を有している。前記第１のクラスタ・ノードに前記ファイル・システム・オブジェクトの保存を実行させるプロセス、および前記論理リンクを生成するプロセスは、通常は、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ実行される。前記プロセスを実行する過程において、通常は、１つのクラスタ・ノードに、前記種々のボリュームのための書き込みロック・マネージャの役割が割り当てられる。書き込みロック・マネージャは、通常は、前記ノードに書き込みロック・マネージャの役割が、該ノードが前記複数のクラスタ・ノードに合流するときから該第１ノードが前記複数のクラスタ・ノードを離れるときまで割り当てられるよう、半静的なやり方で割り当てられる。
【０００５】
前記論理リンクの生成のプロセスは、通常は、少なくとも前記第１のボリュームにおいて唯一である識別子を前記論理識別子として割り当てることを含んでいる。前記唯一の識別子は、通常は、前記第１のボリューム内のファイル・システム・オブジェクトのためにすでに割り当てられた論理識別子のカウントにもとづいて割り当てられる。
【０００６】
ファイル・システム・オブジェクトへのアクセスが、所与のボリューム内で直接行なわれるか、あるいは論理リンクを通じて他のボリュームから行なわれるのかは、当該ＮＡＳクラスタとやり取りするクライアント・ソフトウェアから完全に隠されている。
【０００７】
さらに、この方法は、任意のノードによる所与のストレージ・ボリュームに対する読み出しを実行可能にすることを含むことができる。通常は、各ボリュームにボリューム・キャッシュが組み合わされ、通常は、各ノードにクラスタ・ノード・キャッシュが組み合わされている。さらにこの方法は、選択されたボリューム内のセクタを読み出すための要求であって、該選択されたボリュームとは別個のボリュームを所有している活動クラスタ・ノードによって受信された要求を、該活動クラスタ・ノードに、前記選択されたボリュームのオーナであるクラスタ・ノードへと、前記セクタに対する第１の読み出し要求であって、読み出しのみロックを有している読み出し要求の発行を実行させ、さらに前記選択されたボリュームへと、前記セクタに対する第２の読み出し要求の発行を実行させ、前記選択されたボリュームのオーナであるクラスタ・ノードに、自身が自身のキャッシュ内に前記セクタを有しているか否かを判断させ、有していない場合に、前記読み出しのみロックを認可して前記選択されたボリュームが前記要求を満足させるようにし、有しておりかつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントを前記選択されたボリュームを所有しているノードのキャッシュから前記活動ノードへと送信するとともに、前記要求に関する前記選択されたボリュームの通信を停止し、有しておりかつ前記セクタが書き込みロックされている場合、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開することによって処理することができる。前記読み出しのみロックの認可は、通常は。キャッシュ状態を追跡できるよう、前記活動クラスタ・ノードおよび前記セクタのアイデンティティを記録することを含んでいる。
【０００８】
さらにこの方法は、前記第２のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子への論理参照を保存することを含むことができる。論理参照は、通常は、前記論理識別子と、前記第１のボリュームの前記リロケーション・ディレクトリの前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値（ｅ−番号）を含んでいる。論理参照は、通常は、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子に対する唯一無二の論理参照であるように制限されている。
【０００９】
さらにこの方法は、前記第２のボリュームから前記論理参照を削除すること、および前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除することを含むことができる。
【００１０】
さらにこの方法は、前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、および前記第２のボリュームから前記論理参照を削除することを含むことができる。
【００１１】
さらにこの方法は、前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを、例えば前記論理参照を折々に調べて該論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して割り出すこと、および該論理参照を前記第２のボリュームから削除することを含むことができる。
【００１２】
さらにこの方法は、前記第１のボリュームの前記ファイル・システム・オブジェクトがもはや他のボリュームのいかなる論理参照によっても参照されていないことを、例えば前記リロケーション・ディレクトリを折々に調べて前記ファイル・システム・オブジェクトが他のボリュームの少なくとも１つの論理参照によって参照されているか否かを割り出すための清掃機プロセスを使用して割り出すこと、および該ファイル・システム・オブジェクトを前記第１のボリュームから削除することを含むことができる。清掃機プロセスは、通常は、当該操作に関係するボリュームの１つがシャットダウンまたはクラッシュしたときに修正された参照およびファイル・システム・オブジェクトについて動作する。
【００１３】
さらにこの方法は、前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることを含むことができる。これは、典型的には、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ディレクトリを実装するｉ−ｎｏｄｅに、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照を保存することを含むことができる。前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照は、前記第２のボリュームに関連付けられたボリューム識別子、および前記第２のボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子を含むことができる。前記第２のボリュームは、前記第１のボリュームのＩＤと、前記第１のボリューム内のディレクトリおよび前記第１のボリュームの目標ディレクトリを参照しているｉ−ｎｏｄｅの数を特定する固有の数字（ｅ−番号）とで作られる組の間のファイル−ベースのマッピング表を実装する。前記第１のボリューム内の或るディレクトリの「．．」エントリが、第２のボリュームにおいてそれを指し示しているディレクトリへと帰着させなければならない場合、前記第２のボリュームのマッピング表を通じて参照操作が実行され、所望の参照が得られる。このファイル−ベースのマッピング表は、前記第２のボリュームと他のボリュームのリロケーション・ディレクトリ内のエントリとの間に新たな論理リンクが生成されるたびに、更新されなければならない。このマッピング表は、第２のボリュームを走査することによって排他的に再構成できる。
【００１４】
あるいは、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含むことができる。前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、通常は、前記第１のボリュームに、前記第２のボリューム内の前記論理参照を含んでいる前記ディレクトリへの参照を含んでいる別個のファイルを保存することを含んでいる。しかしながら、これは、保存された参照内のいずれかのディレクトリが移動またはリネームされたとき、論理参照の広範囲にわたる書き直しを必要とする。
【００１５】
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除すること；新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存すること；および、前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること、によって論理的にリロケートすることを含むことができる。通常は、前記論理参照が、前記第２のボリュームの前記ディレクトリから削除される。
【００１６】
さらにこの方法は、第３のボリュームによる前記ファイル・システム・オブジェクトの参照を、新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存すること；および、前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること、によって行なうことを含むことができる。
【００１７】
前記第１のボリュームと前記第２のボリュームとの間の論理リンクの生成は、通常は、前記第１のボリュームのリロケーション・ディレクトリに、前記ファイル・システム・オブジェクトへのハード・リンクを生成すること；および前記第２のボリュームのディレクトリに前記ハード・リンクへの論理リンクを生成すること、を含んでおり、前記ハード・リンクおよび前記論理リンクが、前記複数のクラスタ・ノードのクライアントからは見えない物理名前空間であって、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ハード・リンクを含むハード・リンクによってファイル・システム・オブジェクトに接続される固有の内部階層をそれぞれ備えている前記複数のボリュームを通じて実装された物理名前空間；および、前記複数のクラスタ・ノードのクライアントから見える論理名前空間であって、前記ボリュームを横断して全ファイル・システムにわたって広がり、かつハード・リンクと論理リンクとの間の相違が前記クライアントから隠されるようにハード・リンクおよび論理リンクを介して接続されたファイル・システム・オブジェクトで作られている論理名前空間、を形成している。
【００１８】
さらにこの方法は、前記ファイル・システム・オブジェクトへの書き込みの要求を前記第２のクラスタ・ノードによって受信すること；該要求を前記第１のクラスタ・ノードへと前記第２のクラスタ・ノードによって転送すること；および、前記第１のクラスタ・ノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと、を含むことができる。
【００１９】
さらにこの方法は、前記ファイル・システム・オブジェクトへの書き込みの要求を前記第１のクラスタ・ノードによって受信すること；および、前記第１のクラスタ・ノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと、を含むことができる。
【００２０】
さらにこの方法は、第３のクラスタ・ノードによる前記ファイル・システム・オブジェクトの変更を、前記第３のクラスタ・ノードによって所有されている第３のボリュームへの変更済みファイル・システム・オブジェクトの保存を、前記第３のクラスタ・ノードに実行させること；および、前記第２のボリュームと前記第３のボリュームとの間の論理リンクを、該論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成すること、によって行なうことを含むことができる。
【００２１】
前記第１のボリュームと前記第２のボリュームとの間の論理リンクの生成は、前記論理リンクを生成するための要求を、前記第１のクラスタ・ノードによって前記第２のクラスタ・ノードへと送信すること；および、前記要求の受信をうけて、前記第２のクラスタ・ノードによって前記論理リンクを生成すること、を含むことができる。
【００２２】
前記第１のクラスタ・ノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることは、前記第２のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成するための要求を前記第１のクラスタ・ノードによって受信すること、を含むことができる。
【００２３】
前記第１のクラスタ・ノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることは、前記第２のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第２のクラスタ・ノードによって受信すること；および、前記第１のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成すべきであることを、前記第２のクラスタ・ノードによって判断すること、を含むことができる。
【００２４】
さらにこの方法は、前記第２のクラスタ・ノードに、前記第１のボリュームに関連付けられた固有のボリューム識別子を含んでいる前記ファイル・システム・オブジェクトのためのファイル・ハンドルの生成を実行させること、を含むことができる。
【００２５】
さらにこの方法は、前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノード以外のクラスタ・ノードで受信すること；該要求を前記第２のクラスタ・ノードへと向けること；および、前記ファイル・システム・オブジェクトを前記第２のクラスタ・ノードによって削除すること、を含むことができる。
【００２６】
さらにこの方法は、前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノードによって受信すること；前記論理リンクの前記第２のクラスタ・ノードからの除去を生じさせること；前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノードによって前記第１のクラスタ・ノードへと送信すること；および、前記ファイル・システム・オブジェクトを前記第１のクラスタ・ノードによって削除すること、を含むことができる。
【００２７】
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のボリュームへと自動的にリロケートすることを含むことができる。
【００２８】
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のクラスタ・ノードによって所有されている第３のボリュームへと、前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせること；前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を除去すること；前記第２のボリュームから、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への論理参照を除去すること；前記第２のボリュームと前記第３のボリュームとの間の新しい論理リンクを、該新しい論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための新しい論理識別子を前記第２のボリューム内にもたらすように生成すること；および、前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、によってリロケートすることを含むことができる。新しい論理識別子は、通常は、前記第３のボリュームのリロケーション・ディレクトリに保存される。さらに、この方法は、通常は、前記第３のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を、前記第２のボリュームのディレクトリに保存することを含んでいる。前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせることが、通常は、前記第１のボリュームから前記第３のボリュームへと、怠惰なコピー（ｌａｚｙ  ｃｏｐｙ）技法を使用して前記ファイル・システム・オブジェクトをコピーすることを含んでいる。
【００２９】
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから前記第２のボリュームへと、前記第１のボリュームから前記第２のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせること；前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を取り除くこと；および、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への前記論理参照を、前記第２のボリュームから取り除くこと、によってリロケートすることを含むことができる。
【００３０】
さらにこの方法は、前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持すること；前記ファイル・システム・オブジェクトに関する前記データを、前記第１のクラスタ・ノードによって変更すること；および、前記少なくとも１つの別のクラスタ・ノードに、前記ファイル・システム・オブジェクトに関する前記データの無効化を実行させること、を含むことができる。さらにこの方法は、通常は、前記少なくとも１つの別のクラスタ・ノードに、前記ファイル・システム・オブジェクトに関する前記データの前記第１のボリュームからの再取得を実行させることを含んでいる。前記少なくとも１つの別のクラスタ・ノードに前記ファイル・システム・オブジェクトの一部分のコピーの無効化を実行させることが、通常は、前記ファイル・システム・オブジェクトに関するデータのコピーを有している他のクラスタ・ノードのリストを、前記第１のクラスタ・ノードによって保持すること；および、前記他のクラスタ・ノードのそれぞれに、前記ファイル・システム・オブジェクトに関する前記データが変更された旨の告知を送信すること、を含んでいる。前記ファイル・システム・オブジェクトに関するデータは、メタデータを含むことができ、その場合、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、前記メタデータを保存するためのメタデータ・キャッシュであって、ファイル・システム・オブジェクト・データのコピーを保存するために使用されるあらゆる他のキャッシュから独立して動作するメタデータ・キャッシュを、前記少なくとも１つの別のクラスタ・ノードによって保持することを含んでいる。さらに、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、前記少なくとも１つの別のクラスタ・ノードに、前記第１のクラスタ・ノードから前記ファイル・システム・オブジェクトに関するメタデータを読み出す前に、前記第１のクラスタ・ノードから読み取りロックを取得するよう要求することを含んでいる。前記ファイル・システム・オブジェクトに関するデータは、ファイル・システム・オブジェクト・データおよびメタデータを含むことができ、その場合、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること；メタデータを保存するためのメタデータ・キャッシュを保持すること；および、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマッピングすること、を含んでいる。
【００３１】
前記ファイル・システム・オブジェクトを、それが前記第１のボリュームから第３のボリュームへとリロケートされたときに、リネームすることができる。
【００３２】
通常は、１つのクラスタ・ノードが、ファイル・システム・オブジェクトに影響する多ボリューム操作のためのコーディネータとして指定される。コーディネータは、通常は、前記多ボリューム操作に関係するボリュームのうちの１つのオーナである。
【００３３】
さらにこの方法は、各ボリュームについて、ファイル・システム・オブジェクトへの参照、およびボリュームから取り除かれて前記ファイル・システム・オブジェクトへの論理リンクまたは他の論理リンクで置き換えられた論理リンクを一時的に保存するためのローカル・ディレクトリを保持すること；および、対応するボリュームに影響する多ボリューム操作における故障からの回復のために、ローカル・ディレクトリを使用すること、を含むことができる。
【００３４】
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置が提供される。この装置は、固有のペアレント・ファイル・システム・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム；前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ；および、前記データ・ストレージ・ボリューム内にファイル・システム・オブジェクトを保存し、さらに当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照、および他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するためのオブジェクト・ストレージ・ロジック、を含んでいる。前記論理参照のそれぞれが、通常は、他のノードによって所有されているデータ・ストレージ・ボリュームに保存された対応するファイル・システム・オブジェクトにアクセスするための論理識別子を有し、前記ハード参照のそれぞれが、通常は、対応するペアレント・ノードによる対応するファイル・システム・オブジェクトへのアクセスのための論理識別子を有している。通常は、前記オブジェクト・ストレージ・ロジックが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、前記データ・ストレージ・ボリュームに前記ファイル・システム・オブジェクトを保存し、前記少なくとも１つのディレクトリに前記参照を保存する。このような操作を実行する過程において、前記オブジェクト・ストレージ・ロジックに前記種々のデータ・ストレージ・ボリュームのための書き込みロック・マネージャの役割を割り当てることができる。前記少なくとも１つのディレクトリが、通常は、前記ハード参照を保存するため、階層構造を有するリロケーション・ディレクトリを有している。通常は、前記オブジェクト・ストレージ・ロジックが、ハード参照のそれぞれについて前記論理識別子を、それら論理識別子のそれぞれが前記データ・ストレージ・ボリューム内において唯一であるように割り当てる。通常は、前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のファイル・システム・オブジェクトにすでに割り当てられた論理識別子のカウントにもとづいて固有の識別子を割り当てる。通常は、前記オブジェクト・ストレージ・ロジックが、前記ノードのいずれかによる前記データ・ストレージ・ボリュームの読み出しを実行可能にする。
【００３５】
この装置は、ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュを備えることができる。通常は、前記オブジェクト・ストレージ・ロジックが、他のノードによって所有されているデータ・ストレージ・ボリューム内のセクタを読み出すための要求を、前記セクタについて読み出しのみロックを有している第１の読み出し要求を前記他のノードへと発行し、前記セクタについて第２の読み出し要求を前記他のノードによって所有されている前記データ・ストレージ・ボリュームへと発行することによって処理する。通常は、前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のセクタについての読み出し要求であって、読み出しのみロックを有している読み出し要求を、前記セクタが前記ボリューム・キャッシュに保存されているか否かを判断すること；保存されていない場合に、前記読み出しのみロックを認可して前記要求を満足させること；保存されておりかつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントをキャッシュから送信すること；および、保存されておりかつ前記セクタが書き込みロックされている場合に、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開すること、によって処理する。通常は、前記オブジェクト・ストレージ・ロジックが、キャッシュ状態を追跡できるよう、前記読み出しのみロックの認可時に前記他のノードおよび前記セクタのアイデンティティを記録する。
【００３６】
通常は、論理参照のそれぞれが、他のノードのデータ・ストレージ・ボリュームのリロケーション・ディレクトリ内の対応するエントリを参照している。通常は、論理参照のそれぞれが、前記他のノードのデータ・ストレージ・ボリュームの前記リロケーション・ディレクトリ内の前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値を含んでいる。
【００３７】
通常は、前記オブジェクト・ストレージ・ロジックが、ディレクトリ（ファイルではなく）への論理参照のそれぞれについて、対応する仮想ペアレント・ノードへと戻る参照を保持する。前記対応する仮想ペアレント・ノードへと戻る参照は、前記仮想ペアレント・ノードが存在しているデータ・ストレージ・ボリュームに関連付けられたボリューム識別子を含むことができる。代案として、前記対応する仮想ペアレント・ノードへと戻る参照が、前記仮想ペアレント・ノードの前記データ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含むことができる。前記オブジェクト・ストレージ・ロジックは、前記対応する仮想ペアレント・ノードへと戻る参照を、論理的に参照されたファイル・システム・オブジェクトを実装するｉ−ｎｏｄｅ内に保存することができる。前記オブジェクト・ストレージ・ロジックは、＜参照されたボリュームＩＤ，参照されたｅ−番号＞の組と論理的に参照しているディレクトリのためのｉ−ｎｏｄｅ番号との間のマッピング表を、別個のファイル・システム・オブジェクトとして前記データ・ストレージ・ボリュームに保存することができる。マッピングは、参照しているボリュームの文脈において完全に実行され、ボリューム内の論理参照を走査し尽くすことにより、適当と認められるときに、外部アクセスへのいかなるアクセスも必要とせずにマッピング表を再構成することができる。
【００３８】
前記オブジェクト・ストレージ・ロジックは、新しいファイル・システム・オブジェクトを、新しいファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームに保存すること；前記新しいファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当てること；前記新しいファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること；および、前記新しいファイル・システム・オブジェクトへの論理参照を生成するため、他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームによって前記他のクラスタ・ノードに前記論理識別子を提供すること、によって生成できる。
【００３９】
前記オブジェクト・ストレージ・ロジックは、当該装置がオーナ・クラスタ・ノードであると考えられるボリュームから、外部のボリュームから参照されたファイル・システム・オブジェクトを、前記ファイル・システム・オブジェクトへのハード参照を前記少なくとも１つのディレクトリから削除することによって削除することができる。これは、前記ハード参照が当該ノードへの唯一の係属中のハード参照である場合、ファイル・システム・オブジェクトの実際の削除を生じさせることができる。前記オブジェクト・ストレージ・ロジックは、前記削除されたファイル・システム・オブジェクトへの論理参照を、前記対応する仮想ペアレント・ノードに削除させることができる。
【００４０】
前記オブジェクト・ストレージ・ロジックは、他のノードがペアレント・ノードであると考えられるファイル・システム・オブジェクトの削除を、削除されるファイル・システム・オブジェクトへの論理参照を前記少なくとも１つのディレクトリから削除することによって実行することができる。
【００４１】
通常は、前記オブジェクト・ストレージ・ロジックが、もはや前記データ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについてのハード参照を、例えば前記ハード参照を折々に調べてそれらが参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して、削除する。
【００４２】
通常は、前記オブジェクト・ストレージ・ロジックが、もはや他のノードのデータ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについての論理参照を、例えば前記論理参照を折々に調べてそれら参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して、削除する。
【００４３】
前記オブジェクト・ストレージ・ロジックは、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトの他のノードへのリロケートを、前記ファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当てること；前記ファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること；および、前記ファイル・システム・オブジェクトへの論理参照を生成するため、前記他のノードによって所有されているデータ・ストレージ・ボリュームによって前記他のノードに前記論理識別子を提供すること、によって行なうことができる。
【００４４】
前記オブジェクト・ストレージ・ロジックは、他のノードのデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを、前記他のノードから論理識別子を入手すること；および、該論理識別子を含んでいる論理参照を前記少なくとも１つのディレクトリに保存すること、によってリロケートすることができる。
【００４５】
この装置は、通常は、他のノードに保存されたファイル・システム・オブジェクトに関するデータのコピーを保存するため、少なくとも１つのキャッシュを有しており、通常は、前記オブジェクト・ストレージ・ロジックが、特定のファイル・システム・オブジェクトが該ファイル・システム・オブジェクトが保存されているノードによって変更されたことを知ったときに、該ファイル・システム・オブジェクトに関するデータのコピーを無効化する。前記オブジェクト・ストレージ・ロジックが、通常は、前記ファイル・システム・オブジェクトに関するデータを再取得する。前記少なくとも１つのキャッシュは、ファイル・システム・オブジェクトに関連付けられたメタデータのコピーを保存するためのメタデータ・キャッシュを備えることができ、その場合、前記オブジェクト・ストレージ・ロジックが、前記メタデータ・キャッシュをファイル・システム・オブジェクト・データのコピーを保存するために使用される他のあらゆるキャッシュから独立して動作させることができ、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトに関するメタデータを読み出す前に読み取りロックを取得するよう他のノードに要求することができる。前記少なくとも１つのキャッシュは、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュおよびメタデータを保存するためのメタデータ・キャッシュを備えることができ、その場合、前記オブジェクト・ストレージ・ロジックが、通常は、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマップする。
【００４６】
通常は、前記オブジェクト・ストレージが、前記データ・ストレージ・ボリュームに保存された各ファイル・システム・オブジェクトについて、該ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを保持し、特定のファイル・システム・オブジェクトが変更されたときに前記他のノードのそれぞれに通知を行なう。
【００４７】
前記少なくとも１つのディレクトリが、通常は、ローカル・アンドゥ・ディレクトリを含んでおり、前記オブジェクト・ストレージ・ロジックが、ファイル・システム・オブジェクトへの参照、および論理参照で置き換えられた論理参照または他の論理参照を、前記ローカル・アンドゥ・ディレクトリに一時的に保存し、前記データ・ストレージ・ボリュームに影響する多ボリューム操作における故障からの回復のために、前記ローカル・アンドゥ・ディレクトリを使用する。
【００４８】
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置が提供される。この装置は、固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム；前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ；ならびに、ファイル・システム・オブジェクトを複数のボリュームを横断して保持するための手段であって、他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するための手段；および当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を前記少なくとも１つのディレクトリに保存するための手段、を含んでいる手段、を備えている。
【００４９】
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトを生成するための手段を備えることができる。
【００５０】
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトを削除するための手段を備えることができる。
【００５１】
さらにこの装置は、１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするための手段を備えることができる。
【００５２】
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトをリネームするための手段を備えることができる。
【００５３】
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するための手段であって、他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうための手段；他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうための手段；当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するための手段；および、当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するための手段、を含んでいる手段を備えることができる。さらにこの装置は、他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするための手段、および、他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするための手段を備えることができる。
【００５４】
さらにこの装置は、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するための手段を備えることができる。
【００５５】
さらにこの装置は、複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段を備えることができる。
【００５６】
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタに関し、該ファイル・サーバ・クラスタのクラスタ・ノードを動作させるためのコンピュータ・プログラムを具現化してなるコンピュータで読み出し可能な媒体を有する装置が提供される。前記コンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを保持するためのプログラム・コード手段であって、前記クラスタ・ノードの少なくとも１つのディレクトリに、他のノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を保存するためのプログラム・コード手段；および、他のクラスタ・ノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するためのプログラム・コード手段、を含んでいるプログラム・コード手段を有している。
【００５７】
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを生成するためのプログラム・コード手段を有することができる。
【００５８】
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを削除するためのプログラム・コード手段を有することができる。
【００５９】
さらにこのコンピュータ・プログラムは、１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするためのプログラム・コード手段を有することができる。
【００６０】
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトをリネームするためのプログラム・コード手段を有することができる。
【００６１】
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するためのプログラム・コード手段であって、他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうためのプログラム・コード手段；他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうためのプログラム・コード手段；当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するためのプログラム・コード手段；および、当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するためのプログラム・コード手段、を含んでいるプログラム・コード手段を有することができる。さらにこのコンピュータ・プログラムは、他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするためのプログラム・コード手段、および他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするためのプログラム・コード手段を有することができる。
【００６２】
さらにこのコンピュータ・プログラムは、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するためのプログラム・コード手段を有することができる。
【００６３】
さらにコンピュータ・プログラムは、複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段プログラム・コード手段を含むことができる。
【００６４】
本発明の他の実施の形態においては、ファイル・システム・オブジェクトに関するメタデータを、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタのクラスタ・ノードによって保持するための方法が提供される。この方法は、各ノードについて、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること；各ボリュームについて、メタデータを保存するための別個のメタデータ・キャッシュを保持すること；各ノードについて、他のノードから得たファイル・システム・オブジェクトを前記データ・キャッシュに保存すること；および、各ボリュームについて、他のノードから得たメタデータを前記メタデータ・キャッシュに保存すること、を含んでいる。
【００６５】
さらにこの方法は、前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータにマップすることを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、或るノードによって他のノードから、前記他のノードに保存されたメタデータを読み出すための読み取りロックを要求することによってファイル・システム・オブジェクトに関連付けられたメタデータを取得すること、および、前記読み取りロックが認可されたのちにのみ、前記他のノードからメタデータを読み出すことを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、或るノードによって、該ノードが所有するファイル・システム・オブジェクトについての読み取りロックを有している他のあらゆるノードのリストを保持すること、および、該ノードによって前記ファイル・システム・オブジェクトに変更を、すべての読み取りロックを再取得させ、すべての読み取りロックが再取得されたのちにのみ前記ファイル・システム・オブジェクトを変更することによって加えることを含むことができる。
（項目１）
それぞれが複数の論理ストレージ・ボリュームへのアクセスを有している複数のクラスタ・ノードを使用して、該ノードと通信するクライアントによる前記ボリューム上のデータへのアクセスを提供するための方法であって、
・所与のボリュームへの書き込みを、該ボリュームを所有しているとみなされる唯一のノードによってのみ実施可能にすること、および
・第１のノードに、該第１のノードが所有する第１のボリュームへのファイル・システム・オブジェクトの保存を実行させ、さらに前記第１のボリュームと第２のノードが所有する第２のボリュームとの間の論理リンクを、該論理リンクが前記第１のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成することによって、ファイル・システム・オブジェクトを前記複数のボリュームを横断して保持すること
を含んでいる方法。
（項目２）
前記論理識別子を、前記第１のボリュームのリロケーション・ディレクトリであって、前記第１のボリューム以外のボリュームから参照される前記第１のボリューム内のすべてのファイル・システム・オブジェクトについての論理識別子を列挙しているリロケーション・ディレクトリに保存すること
をさらに含んでいる項目１に記載の方法。
（項目３）
前記第１のノードに前記ファイル・システム・オブジェクトの保存を実行させるプロセス、および前記論理リンクを生成するプロセスが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ実行される項目１に記載の方法。
（項目４）
前記プロセスを実行する過程において、前記第１のノードに前記第１および第２のボリュームのための書き込みロック・マネージャの役割を割り当てること
をさらに含んでいる項目３に記載の方法。
（項目５）
前記リロケーション・ディレクトリが階層構造を有している項目２に記載の方法。
（項目６）
前記論理リンクの生成が、少なくとも前記第１のボリュームにおいて唯一である識別子を前記論理識別子として割り当てることを含んでいる項目１に記載の方法。
（項目７）
唯一の識別子の割り当てが、前記第１のボリューム内のファイル・システム・オブジェクトのためにすでに割り当てられた論理識別子のカウントにもとづく数字を割り当てることを含んでいる項目６に記載の方法。
（項目８）
任意のノードによる所与のストレージ・ボリュームに対する読み出しを実行可能にすること
をさらに含んでいる項目１に記載の方法。
（項目９）
前記ボリュームのそれぞれにボリューム・キャッシュが組み合わされ、かつ前記ノードのそれぞれにノード・キャッシュが組み合わされており、
当該方法が、
選択されたボリューム内のセクタを読み出すための要求であって、該選択されたボリュームとは別個のボリュームを所有している活動ノードによって受信された要求を、
該活動ノードに、前記選択されたボリュームのオーナであるノードへと、前記セクタに対する第１の読み出し要求であって、読み出しのみロックを有している読み出し要求の発行を実行させ、さらに前記選択されたボリュームへと、前記セクタに対する第２の読み出し要求の発行を実行させ、
前記選択されたボリュームのオーナであるノードに、自身が自身のキャッシュ内に前記セクタを有しているか否かを判断させ、
・有していない場合に、前記読み出しのみロックを認可して前記選択されたボリュームが前記要求を満足させるようにし、
・有しており、かつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントを前記選択されたボリュームを所有しているノードのキャッシュから前記活動ノードへと送信し、前記要求に関する前記選択されたボリュームの通信を停止し、
・有しており、かつ前記セクタが書き込みロックされている場合、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開する
ことによって処理する
項目８に記載の方法。
（項目１０）
前記読み出しのみロックの認可が、キャッシュ状態を追跡できるよう、前記活動ノードおよび前記セクタのアイデンティティを記録することを含んでいる項目９に記載の方法。
（項目１１）
前記第２のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子への論理参照を保存すること
をさらに含んでいる項目２に記載の方法。
（項目１２）
前記論理参照が、
・前記論理識別子、および
・前記第１のボリュームの前記リロケーション・ディレクトリの前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値
を含んでいる項目１１に記載の方法。
（項目１３）
前記論理参照を、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子に対する唯一無二の論理参照であるように制限すること
をさらに含んでいる項目１１に記載の方法。
（項目１４）
前記第１のノードに前記別個および選択されたボリュームのための書き込みロック・マネージャの役割を割り当てることが、
前記第１のノードに前記第１および第２のボリュームのための書き込みロック・マネージャの役割を、書き込みロック・マネージャの役割が前記第１のノードに、該第１のノードが前記複数のクラスタ・ノードに合流するときから該第１ノードが前記複数のクラスタ・ノードを離れるときまで割り当てられるよう、半静的なやり方で割り当てること
を含んでいる項目４に記載の方法。
（項目１５）
前記第２のボリュームから前記論理参照を削除すること、および
前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除すること
をさらに含んでいる項目１１に記載の方法。
（項目１６）
前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、および
前記第２のボリュームから前記論理参照を削除すること
をさらに含んでいる項目１１に記載の方法。
（項目１７）
前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを割り出すこと、および
該論理参照を前記第２のボリュームから削除すること
をさらに含んでいる項目１１に記載の方法。
（項目１８）
前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを割り出すことが、
前記論理参照を折々に調べて該論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出す清掃機プロセスを、前記第２において実行すること
を含んでいる項目１７に記載の方法。
（項目１９）
前記第１のボリュームの前記ファイル・システム・オブジェクトが、もはや他のボリュームのいかなる論理参照によっても参照されていないことを割り出すこと、および
該ファイル・システム・オブジェクトを前記第１のボリュームから削除すること
をさらに含んでいる項目１１に記載の方法。
（項目２０）
前記第１のボリュームの前記ファイル・システム・オブジェクトがもはや他のボリュームのいかなる論理参照によっても参照されていないことを割り出すことが、
前記リロケーション・ディレクトリを折々に調べて前記ファイル・システム・オブジェクトが他のボリュームの少なくとも１つの論理参照によって参照されているか否かを割り出す清掃機プロセスを、前記第１のノードにおいて実行すること
を含んでいる項目１９に記載の方法。
（項目２１）
前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすること
をさらに含んでいる項目１１に記載の方法。
（項目２２）
前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、
前記第１のボリュームの前記リロケーション・ディレクトリに、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照を保存すること
を含んでいる項目２１に記載の方法。
（項目２３）
前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、
前記第２のボリュームに関連付けられたボリューム識別子、および
前記第２のボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子
を含んでいる項目２２に記載の方法。
（項目２４）
前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含んでいる項目２２に記載の方法。
（項目２５）
前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、
前記第１のボリュームに、前記第２のボリューム内の前記論理参照を含んでいる前記ディレクトリへの参照を含んでいる別個のファイルを保存すること
を含んでいる項目２１に記載の方法。
（項目２６）
前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、
・前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除し、
・新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存し、さらに
・前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること
によって、論理的にリロケートすること
をさらに含んでいる項目１１に記載の方法。
（項目２７）
前記論理参照を前記第２のボリュームの前記ディレクトリから削除すること
をさらに含んでいる項目２６に記載の方法。
（項目２８）
第３のボリュームによって前記ファイル・システム・オブジェクトを、
・新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存し、さらに
・前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること
によって参照すること
をさらに含んでいる項目１１に記載の方法。
（項目２９）
前記第１のボリュームと前記第２のボリュームとの間の論理リンクを生成することが、・前記第１のボリュームのリロケーション・ディレクトリに、前記ファイル・システム・オブジェクトへのハード・リンクを生成すること、および
・前記第２のボリュームのディレクトリに前記ハード・リンクへの論理リンクを生成すること
を含んでおり、
前記ハード・リンクおよび前記論理リンクが、
・前記複数のノードの前記クライアントからは見えない物理名前空間であって、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ハード・リンクを含むハード・リンクによってファイル・システム・オブジェクトに接続される固有の内部階層をそれぞれ備えている前記複数のボリュームを通じて実装された物理名前空間、および
・前記複数のノードの前記クライアントから見える論理名前空間であって、前記ボリュームを横断して全ファイル・システムにわたって広がり、かつハード・リンクと論理リンクとの間の相違が前記クライアントから隠されるようにハード・リンクおよび論理リンクを介して接続されたファイル・システム・オブジェクトで作られている論理名前空間
を形成している
項目１に記載の方法。
（項目３０）
前記ファイル・システム・オブジェクトへの書き込みの要求を、前記第２のノードによって受信すること、
該要求を前記第１のノードへと、前記第２のノードによって転送すること、および
前記第１のノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと
をさらに含んでいる項目１に記載の方法。
（項目３１）
前記ファイル・システム・オブジェクトへの書き込みの要求を、前記第１のノードによって受信すること、および
前記第１のノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと
をさらに含んでいる項目１に記載の方法。
（項目３２）
第３のノードによって前記ファイル・システム・オブジェクトを、
・前記第３のノードによって所有されている第３のボリュームへの変更済みファイル・システム・オブジェクトの保存を、前記第３のノードに実行させ、さらに
・前記第２のボリュームと前記第３のボリュームとの間の論理リンクを、該論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成すること
によって変更すること
をさらに含んでいる項目１に記載の方法。
（項目３３）
前記第１のボリュームと前記第２のボリュームとの間の論理リンクを生成することが、・前記論理リンクを生成するための要求を、前記第１のノードによって前記第２のノードへと送信すること、および
・前記要求の受信をうけて、前記第２のノードによって前記論理リンクを生成すること
を含んでいる項目１に記載の方法。
（項目３４）
前記第１のノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることが、
前記第２のノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第１のノードによって受信すること
を含んでいる項目１に記載の方法。
（項目３５）
前記第１のノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることが、
・前記第２のノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第２のノードによって受信すること、および
・前記第１のノードに前記ファイル・システム・オブジェクトを生成すべきであることを、前記第２のノードによって判断すること
を含んでいる項目１に記載の方法。
（項目３６）
各ボリュームが固有のボリューム識別子に関連付けられており、
当該方法が、
前記第２のノードに、前記第１のボリュームに関連付けられた前記ボリューム識別子を含んでいる前記ファイル・システム・オブジェクトのためのファイル・ハンドルの生成を実行させること
をさらに含んでいる項目１に記載の方法。
（項目３７）
前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノード以外のノードで受信すること、および
該要求を前記第２のノードへと向けること、ならびに
前記ファイル・システム・オブジェクトを前記第２のノードによって削除すること
をさらに含んでいる項目１に記載の方法。
（項目３８）
前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノードによって受信すること、
前記論理リンクの前記第２のノードからの除去を生じさせること、
前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノードによって前記第１のノードへと送信すること、および
前記ファイル・システム・オブジェクトを前記第１のノードによって削除すること
をさらに含んでいる項目１に記載の方法。
（項目３９）
前記ファイル・システム・オブジェクトが、
・ファイル、および
・ディレクトリ
のうちの１つを含んでいる項目１に記載の方法。
（項目４０）
前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと論理的にリロケートすることが、所定の条件のもとで自動的に実行される項目２６に記載の方法。
（項目４１）
前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、
・前記第１のボリュームから前記第３のボリュームへと、前記ファイル・システム・オブジェクトのコピーを生じさせ、
・前記第１のボリュームの前記リロケーション・ディレクトリから、前記論理識別子を除去し、
・前記第２のボリュームから、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への論理参照を除去し、
・前記第２のボリュームと前記第３のボリュームとの間の新しい論理リンクを、該新しい論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための新しい論理識別子を前記第２のボリューム内にもたらすように生成し、さらに
・前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること
によってリロケートすること
をさらに含んでいる項目１１に記載の方法。
（項目４２）
前記新しい論理識別子を、前記第３のボリュームのリロケーション・ディレクトリに保存すること
をさらに含んでいる項目４１に記載の方法。
（項目４３）
前記第３のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を、前記第２のボリュームのディレクトリに保存すること
をさらに含んでいる項目４２に記載の方法。
（項目４４）
前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせることが、
前記第１のボリュームから前記第３のボリュームへと、怠惰なコピー（ｌａｚｙ  ｃｏｐｙ）技法を使用して前記ファイル・システム・オブジェクトをコピーすること
を含んでいる項目４１に記載の方法。
（項目４５）
前記ファイル・システム・オブジェクトを、前記第１のボリュームから前記第２のボリュームへと、
・前記第１のボリュームから前記第２のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせ、
・前記第１のボリュームの前記リロケーション・ディレクトリから、前記論理識別子を取り除き、さらに
・前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への前記論理参照を、前記第２のボリュームから取り除くこと
によってリロケートすること
をさらに含んでいる項目１１に記載の方法。
（項目４６）
前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持すること、
前記ファイル・システム・オブジェクトに関する前記データを、前記第１のノードによって変更すること、および
前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトに関する前記データの無効化を実行させること
をさらに含んでいる項目１に記載の方法。
（項目４７）
前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトに関する前記データの前記第１のボリュームからの再取得を実行させること
をさらに含んでいる項目４６に記載の方法。
（項目４８）
前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトの一部分のコピーの無効化を実行させることが、
・前記ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを、前記第１のノードによって保持すること、および
・前記他のノードのそれぞれに、前記ファイル・システム・オブジェクトに関する前記データが変更された旨の告知を送信すること
を含んでいる項目４６に記載の方法。
（項目４９）
前記ファイル・システム・オブジェクトに関する前記データが、メタデータを含んでおり、
前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
前記メタデータを保存するためのメタデータ・キャッシュであって、ファイル・システム・オブジェクト・データのコピーを保存するために使用されるあらゆる他のキャッシュから独立して動作するメタデータ・キャッシュを、前記少なくとも１つの別のノードによって保持すること
を含んでいる項目４６に記載の方法。
（項目５０）
前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
前記少なくとも１つの別のノードに、前記第１のノードから前記ファイル・システム・オブジェクトに関するメタデータを読み出す前に、前記第１のノードから読み取りロックを取得するよう要求すること
をさらに含んでいる項目４９に記載の方法。
（項目５１）
前記ファイル・システム・オブジェクトに関するデータが、ファイル・システム・オブジェクト・データおよびメタデータを含んでおり、
前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
・ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること、
・メタデータを保存するためのメタデータ・キャッシュを保持すること、および
・前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータへとマッピングすること
を含んでいる項目４６に記載の方法。
（項目５２）
前記ファイル・システム・オブジェクトが、前記第１のボリューム内の第１の名前に関連付けられており、
前記ファイル・システム・オブジェクトを前記第１のボリュームから前記第３のボリュームへと論理的にリロケートすることが、
前記ファイル・システム・オブジェクトを、前記第３のボリューム内の第２の名前に関連付けること
をさらに含んでいる項目２６に記載の方法。
（項目５３）
１つのノードを、前記ファイル・システム・オブジェクトに作用する多ボリューム操作のためのコーディネータとして指定することをさらに含んでおり、
該コーディネータが、前記多ボリューム操作に関係するボリュームのうちの１つのオーナである項目１に記載の方法。
（項目５４）
各ボリュームについて、ファイル・システム・オブジェクトへの参照、およびボリュームから取り除かれて前記ファイル・システム・オブジェクトへの論理リンクまたは他の論理リンクで置き換えられた論理リンクを一時的に保存するためのローカル・ディレクトリを保持すること、および
対応するボリュームに影響する多ボリューム操作における故障からの回復のために、ローカル・ディレクトリを使用すること
をさらに含んでいる項目１に記載の方法。
（項目５５）
複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置であって、
・固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム、
・前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ、および
・前記データ・ストレージ・ボリューム内にファイル・システム・オブジェクトを保存し、さらに当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照、および他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するため、作用可能に組み合わされたオブジェクト・ストレージ・ロジック
を有している装置。
（項目５６）
前記論理参照のそれぞれが、他のノードによって所有されているデータ・ストレージ・ボリュームに保存された対応するファイル・システム・オブジェクトにアクセスするための論理識別子を有し、
前記ハード参照のそれぞれが、対応するペアレント・ノードによる対応するファイル・システム・オブジェクトへのアクセスのための論理識別子を有している
項目５５に記載の装置。
（項目５７）
前記オブジェクト・ストレージ・ロジックが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、前記データ・ストレージ・ボリュームに前記ファイル・システム・オブジェクトを保存し、前記少なくとも１つのディレクトリに前記参照を保存するため、作用可能に組み合わされている項目５５に記載の装置。
（項目５８）
前記操作を実行する過程において、前記オブジェクト・ストレージ・ロジックに前記種々のデータ・ストレージ・ボリュームのための書き込みロック・マネージャの役割が割り当てられる項目５７に記載の装置。
（項目５９）
前記少なくとも１つのディレクトリが、前記ハード参照を保存するため、階層構造を有するリロケーション・ディレクトリを有している項目５６に記載の装置。
（項目６０）
前記オブジェクト・ストレージ・ロジックが、ハード参照のそれぞれについて前記論理識別子を、それら論理識別子のそれぞれが前記データ・ストレージ・ボリューム内において唯一であるように割り当てるため、作用可能に組み合わされている項目５６に記載の装置。
（項目６１）
前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のファイル・システム・オブジェクトにすでに割り当てられた論理識別子のカウントにもとづいて固有の識別子を割り当てるため、作用可能に組み合わされている項目６０に記載の装置。
（項目６２）
前記オブジェクト・ストレージ・ロジックが、前記ノードのいずれかによる前記データ・ストレージ・ボリュームの読み出しを実行可能にするため、作用可能に組み合わされている項目５５に記載の装置。
（項目６３）
ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュをさらに有しており、
前記オブジェクト・ストレージ・ロジックが、他のノードによって所有されているデータ・ストレージ・ボリューム内のセクタを読み出すための要求を、
・前記セクタについての第１の読み出し要求であって、読み出しのみロックを有している読み出し要求を、前記他のノードへと発行し、前記セクタについての第２の読み出し要求を、前記他のノードによって所有されている前記データ・ストレージ・ボリュームへと発行すること
によって処理するため、作用可能に組み合わされている
項目６２に記載の装置。
（項目６４）
ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュをさらに有しており、
前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のセクタについての読み出し要求であって、読み出しのみロックを有している読み出し要求を、
・前記セクタが前記ボリューム・キャッシュに保存されているか否かを判断し、
・保存されていない場合に、前記読み出しのみロックを認可して前記要求を満足させ、
・保存されており、かつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントをキャッシュから送信し、
・保存されており、かつ前記セクタが書き込みロックされている場合に、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開する
ことによって処理するため、作用可能に組み合わされている項目６２に記載の装置。
（項目６５）
前記オブジェクト・ストレージ・ロジックが、キャッシュ状態を追跡できるよう前記読み出しのみロックの認可時に前記他のノードおよび前記セクタのアイデンティティを記録するため、作用可能に組み合わされている項目６４に記載の装置。
（項目６６）
論理参照のそれぞれが、他のノードのデータ・ストレージ・ボリュームのリロケーション・ディレクトリ内の対応するエントリを参照している項目５６に記載の装置。
（項目６７）
論理参照のそれぞれが、
前記他のノードのデータ・ストレージ・ボリュームの前記リロケーション・ディレクトリ内の前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値
をさらに有している項目６６に記載の装置。
（項目６８）
前記オブジェクト・ストレージ・ロジックが、各ハード参照について対応するペアレント・ノードへと戻る参照を保持するため、作用可能に組み合わされている項目５５に記載の装置。
（項目６９）
前記対応するペアレント・ノードへと戻る参照が、
・前記ペアレント・ノードのデータ・ストレージ・ボリュームに関連付けられたボリューム識別子、および
・前記ペアレント・ノードのデータ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子
を有している項目６８に記載の装置。
（項目７０）
前記対応するペアレント・ノードへと戻る参照が、
・前記ペアレント・ノードの前記データ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名
を有している項目６８に記載の装置。
（項目７１）
前記オブジェクト・ストレージ・ロジックが、前記対応するペアレント・ノードへと戻る参照を、前記少なくとも１つの内のハード参照とともに保存するため、作用可能に組み合わされている項目６８に記載の装置。
（項目７２）
前記オブジェクト・ストレージ・ロジックが、前記対応するペアレント・ノードへと戻る参照を、前記データ・ストレージ・ボリューム内の別個のファイル・システム・オブジェクトとして保存するため、作用可能に組み合わされている項目６８に記載の装置。
（項目７３）
前記オブジェクト・ストレージ・ロジックが、新しいファイル・システム・オブジェクトを、
・新しいファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームに保存すること、
・前記新しいファイル・システム・オブジェクトへのハード参照について、論理識別子を割り当てること、
・前記新しいファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること、および
・前記新しいファイル・システム・オブジェクトへの論理参照を、他のノードによって所有されているデータ・ストレージ・ボリュームによって生成するため、前記他のノードに前記論理識別子を提供することによって生成するため、作用可能に組み合わされている項目５５に記載の装置。
（項目７４）
前記オブジェクト・ストレージ・ロジックが、当該装置がペアレント・ノードであると考えられるファイル・システム・オブジェクトを、
・前記ファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームから削除すること、および
・前記ファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリから削除すること
によって削除するため、作用可能に組み合わされている項目５５に記載の装置。
（項目７５）
前記オブジェクト・ストレージ・ロジックが、前記削除されたファイル・システム・オブジェクトへの論理参照を前記対応するペアレント・ノードに削除させるため、作用可能に組み合わされている項目７４に記載の装置。
（項目７６）
前記オブジェクト・ストレージ・ロジックが、他のノードがペアレント・ノードであると考えられるファイル・システム・オブジェクトを、
・削除されるファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリから削除すること
によって削除するため、作用可能に組み合わされている項目５５に記載の装置。
（項目７７）
前記オブジェクト・ストレージ・ロジックが、もはや前記データ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについてのハード参照を削除するため、作用可能に組み合わされている項目５５に記載の装置。
（項目７８）
前記オブジェクト・ストレージ・ロジックが、前記ハード参照を折々に調べて該ハード参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを有している項目７７に記載の装置。
（項目７９）
前記オブジェクト・ストレージ・ロジックが、もはや他のノードのデータ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについての論理参照を削除するため、作用可能に組み合わされている項目５５に記載の装置。
（項目８０）
前記オブジェクト・ストレージ・ロジックが、前記論理参照を折々に調べて該論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを有している項目７９に記載の装置。
（項目８１）
前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを他のノードへと、
・前記ファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当て、
・前記ファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存し、さらに
・前記ファイル・システム・オブジェクトへの論理参照を、前記他のノードによって所有されているデータ・ストレージ・ボリュームによって生成するため、前記他のノードに前記論理識別子を提供すること
によってリロケートするため、作用可能に組み合わされている項目５５に記載の装置。
（項目８２）
前記オブジェクト・ストレージ・ロジックが、他のノードのデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを、
・前記他のノードから論理識別子を入手すること、および
・該論理識別子を含んでいる論理参照を前記少なくとも１つのディレクトリに保存すること
によってリロケートするため、作用可能に組み合わされている項目５５に記載の装置。
（項目８３）
他のノードに保存されたファイル・システム・オブジェクトに関するデータのコピーを保存するため、少なくとも１つのキャッシュをさらに有しており、
前記オブジェクト・ストレージ・ロジックが、特定のファイル・システム・オブジェクトが該ファイル・システム・オブジェクトが保存されているノードによって変更されたことを知ったときに、該ファイル・システム・オブジェクトに関するデータのコピーを無効化するよう、作用可能に組み合わされている項目５５に記載の装置。
（項目８４）
前記オブジェクト・ストレージ・ロジックが、前記ファイル・システム・オブジェクトに関するデータを再取得するよう、作用可能に組み合わされている項目８３に記載の装置。
（項目８５）
前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存された各ファイル・システム・オブジェクトについて、該ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを保持し、特定のファイル・システム・オブジェクトが変更されたときに前記他のノードのそれぞれに通知を行なうよう、作用可能に組み合わされている項目５５に記載の装置。
（項目８６）
前記少なくとも１つのキャッシュが、ファイル・システム・オブジェクトに関連付けられたメタデータのコピーを保存するためのメタデータ・キャッシュを有しており、
前記オブジェクト・ストレージ・ロジックが、前記メタデータ・キャッシュをファイル・システム・オブジェクト・データのコピーを保存するために使用される他のあらゆるキャッシュから独立して動作させるよう、作用可能に組み合わされている項目８３に記載の装置。
（項目８７）
前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトに関するメタデータを読み出す前に読み取りロックを取得するよう他のノードに要求するため、作用可能に組み合わされている項目８６に記載の装置。
（項目８８）
前記少なくとも１つのキャッシュが、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュおよびメタデータを保存するためのメタデータ・キャッシュを有しており、
前記オブジェクト・ストレージ・ロジックが、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマップするよう、作用可能に組み合わされている項目８３に記載の装置。
（項目８９）
前記少なくとも１つのディレクトリが、ローカル・アンドゥ・ディレクトリを含んでおり、
前記オブジェクト・ストレージ・ロジックが、ファイル・システム・オブジェクトへの参照、および論理参照で置き換えられた論理参照または他の論理参照を、前記ローカル・アンドゥ・ディレクトリに一時的に保存し、前記データ・ストレージ・ボリュームに影響する多ボリューム操作における故障からの回復のために、前記ローカル・アンドゥ・ディレクトリを使用するよう、作用可能に組み合わされている項目５５に記載の装置。
（項目９０）
複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置であって、
・固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム、
・前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ、
・ファイル・システム・オブジェクトを複数のボリュームを横断して保持するための手段であって、
他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するための手段、および
当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するための手段
を含んでいる手段
を有している装置。
（項目９１）
複数のボリュームを横断してファイル・システム・オブジェクトを生成するための手段をさらに有している項目９０に記載の装置。
（項目９２）
複数のボリュームを横断してファイル・システム・オブジェクトを削除するための手段をさらに有している項目９０に記載の装置。
（項目９３）
１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするための手段
をさらに有している項目９０に記載の装置。
（項目９４）
複数のボリュームを横断してファイル・システム・オブジェクトをリネームするための手段
をさらに有している項目９０に記載の装置。
（項目９５）
複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するための手段であって、
・他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうための手段、
・他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうための手段、
・当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するための手段、および
・当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するための手段
を含んでいる手段をさらに有している項目９０に記載の装置。
（項目９６）
他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするための手段、および
他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするための手段
をさらに有している項目９５に記載の装置。
（項目９７）
多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するための手段
をさらに有している項目９０に記載の装置。
（項目９８）
複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段
をさらに有している項目９０に記載の装置。
（項目９９）
複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタに関し、該ファイル・サーバ・クラスタのクラスタ・ノードを動作させるためのコンピュータ・プログラムを具現化してなるコンピュータで読み出し可能な媒体を有する装置であって、
前記コンピュータ・プログラムが、
・前記クラスタ・ノードの少なくとも１つのディレクトリに、他のノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を保存するためのプログラム・コード手段、および
・他のクラスタ・ノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するためのプログラム・コード手段
を含んでいる複数のボリュームを横断してファイル・システム・オブジェクトを保持するためのプログラム・コード手段
を有している装置。
（項目１００）
前記コンピュータ・プログラムが、
複数のボリュームを横断してファイル・システム・オブジェクトを生成するためのプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０１）
前記コンピュータ・プログラムが、
複数のボリュームを横断してファイル・システム・オブジェクトを削除するためのプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０２）
前記コンピュータ・プログラムが、
１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするためのプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０３）
前記コンピュータ・プログラムが、
複数のボリュームを横断してファイル・システム・オブジェクトをリネームするためのプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０４）
前記コンピュータ・プログラムが、
複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するためのプログラム・コード手段であって、
・他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうためのプログラム・コード手段、
・他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうためのプログラム・コード手段、
・当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するためのプログラム・コード手段、および
・当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するためのプログラム・コード手段
を含んでいるプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０５）
前記コンピュータ・プログラムが、
他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするためのプログラム・コード手段、および
他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするためのプログラム・コード手段
をさらに有している項目１０４に記載の装置。
（項目１０６）
前記コンピュータ・プログラムが、
多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するためのプログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０７）
前記コンピュータ・プログラムが、
複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段プログラム・コード手段
をさらに有している項目９９に記載の装置。
（項目１０８）
ファイル・システム・オブジェクトに関するメタデータを、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタのクラスタ・ノードによって保持するための方法であって、・各ノードについて、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること、
・各ボリュームについて、メタデータを保存するための別個のメタデータ・キャッシュを保持すること、
・各ノードについて、他のノードから得たファイル・システム・オブジェクトを前記データ・キャッシュに保存すること、
・各ボリュームについて、他のノードから得たメタデータを前記メタデータ・キャッシュに保存すること、および
・前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作すること
を含んでいる方法。
（項目１０９）
前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータにマップすること
を含んでいる項目１０８に記載の方法。
（項目１１０）
前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
・或るノードによって他のノードから、ファイル・システム・オブジェクトに関連付けられたメタデータを取得すること、
・前記他のノードに保存されたメタデータを読み出すための読み取りロックを要求すること、および
・前記読み取りロックが認可されたのちにのみ、前記他のノードからメタデータを読み出すこと
を含んでいる項目１０８に記載の方法。
（項目１１１）
前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
・或るノードによって、該ノードが所有するファイル・システム・オブジェクトについての読み取りロックを有している他のあらゆるノードのリストを保持すること、および
・該ノードによって前記ファイル・システム・オブジェクトに変更を、すべての読み取りロックを再取得させ、すべての読み取りロックが再取得されたのちにのみ前記ファイル・システム・オブジェクトを変更することによって加えること
を含んでいる項目１０８に記載の方法。
【図面の簡単な説明】
【００６６】
本発明の前記の特徴は、添付の図面を参照しつつ以下の詳細な説明を参照することによって、より容易に理解されるであろう。
【図１】図１は、本発明の種々の態様を適用することができるファイル・サーバの一実施の形態のブロック図である。
【図２】図２は、図１の実施の形態の実装例のブロック図である。
【図３】図３は、本発明の一実施の形態による複数のボリュームを横切ってサポートされたただ１つのファイル・システム・イメージを描いたダイアグラムである。
【図４】図４は、図３の論理階層に従いハード・リンクおよびスクイジー・リンクによって実装された論理名前空間を描いたダイアグラムである。
【図５】図５は、本発明の一実施の形態による外部書き込み要求の取り扱いを描いたダイアグラムであり、目標ボリュームを所有するノードへと転送されるときにローカル・キャッシュをバイパスしている。
【図６】図６は、本発明の一実施の形態による外部読み出し要求の取り扱いを描いたダイアグラムであり、ローカル・メタデータおよびローカル・セクタ・キャッシュの両方を使用している。
【図７】図７は、ローカル・ボリュームおよびリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが本発明の一実施の形態に従ってローカル・ボリュームによってリネームされる前の状態であり、ファイル・システム・オブジェクトが、リモート・ボリューム内の「通常の」ディレクトリ内のエントリによって指し示されている。
【図８】図８は、図７のローカル・ボリュームおよびリモート・ボリュームの状態を、本発明の一実施の形態によってファイル・システム・オブジェクトをリネームした後について描いたダイアグラムであり、ファイル・システム・オブジェクトが、リモート・ボリュームのＲＤ内のエントリによって指し示されており、ローカル・ボリュームが、前記リモート・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを含んでいる。
【図９】図９は、ローカル・ボリュームおよびリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが、ローカル・ボリュームのＲＤ内のエントリによって指し示されており、リモート・ボリュームが、前記ローカル・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを含んでおり、本発明の一実施の形態に従ってリモート・ボリュームからのスクイジー・リンクをリネームする前の状態である。
【図１０】図１０は、図９のローカル・ボリュームおよびリモート・ボリュームの状態を、本発明の一実施の形態によってスクイジー・リンクを既存のファイル・システム・オブジェクトと共存在となるようにリネームした後について描いたダイアグラムであり、ファイル・システム・オブジェクトが、ローカル・ボリューム内の「通常の」ディレクトリ内のエントリによって指し示されており、スクイジー・リンクがリモート・ボリュームから取り除かれている。
【図１１】図１１は、ローカル・ボリューム、第１のリモート・ボリューム、および第２のリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが、第１のリモート・ボリュームのＲＤ内のエントリによって指し示されており、第２の遠各ボリュームが、前記第１のリモート・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを有しており、本発明の一実施の形態に従って第２のリモート・ボリュームからスクイジー・リンクをリネームする前の状態である。
【図１２】図１２は、ローカル・ボリューム、第１のリモート・ボリューム、および第２のリモート・ボリュームの状態を、本発明の一実施の形態に従って前記スクイジー・リンクをファイル・システム・オブジェクトと共存在にならないようにリネームした後について描いたダイアグラムであり、前記スクイジー・リンクが第２のリモート・ボリュームから取り去られ、新しいスクイジー・リンクがローカルに生成されている。
【図１３】図１３は、本発明の一実施の形態による分散サービス／高可用性サブシステムと他の構成要素との間の関係を示している。
【図１４】図１４は、分散サービス／高可用性サブシステムの関連構成要素を示している。
【発明を実施するための形態】
【００６７】
（特定の実施形態の詳細な説明）
１  はじめに
本発明の実施の形態は、ファイル・システム・クラスタリングのソリューションを提供する。ファイル・システム・クラスタの鍵となる構成要素には、クラスタを実現すべく相互接続され、受信したクライアントの要求の処理を実行する個々のサーバ（ノード）、および１つのエンティティとして管理される個々のファイル・システム・パーティション（ボリューム）が含まれる。
【００６８】
１．１  用語の定義
本明細書および添付の図面において使用されるとき、以下の用語は、文脈上そのようでない場合を除き、以下に示す意味を有する。
【００６９】
ＣＤＭ  構成データベース・モジュール：複製された、クラスタ全体の、常時オンの構成データベース。
【００７０】
ＦＳＭ  ファイル・システム・モジュール：ファイル・システムＡＰＩ群およびデータ構造の管理に充てられたモジュール。
【００７１】
ＦＳＯ  ファイル・システム・オブジェクト：ファイル・システム内において個々に参照されうるあらゆるオブジェクト。
【００７２】
ＩＨＭ  相互接続ハードウェア・モジュール：保証なしおよび保証ありの両者のインオーダ・メッセージ配信を備える基本的なデータグラム機構をもたらすモジュール。
【００７３】
ＩＭＦ  ノード間メッセージング・ファシリティ：保証ありのメッセージ配信およびハートビートの送信を提供する。
【００７４】
ＬＵＤ  ローカル・アンドゥ・ディレクトリ：各ボリュームにて利用可能であって、クライアントからは見えない特別なディレクトリであり、新規スクイジー・リンク（下記参照）の生成によって置き換えられたファイル・システム・オブジェクトが、リカバリを容易にするため一時的に保存される。
【００７５】
ＭＭ  メッセージング・モジュール：ユニキャスト／マルチキャストな同期／非同期のメッセージング・プリミティブおよびイベント・ハンドリングを提供する。
【００７６】
ＮＩＭ  ネットワーク・インターフェイス・モジュール：ＴＣＰ／ＩＰフロントエンドのサポートを提供することによるネットワーク・インターフェイスの取り扱いに充てられたハードウェア・モジュール。
【００７７】
ＰＮ  物理ノード：クラスタ・コードを実行する物理的インフラストラクチャを提供するノードであって、仮想ノード（ＶＮ）アブストラクションをサポートするノード。ＰＮは、物理名および物理ＩＰアドレスを有している。ＰＮは、ＶＮへと「結び付け」られることによって、ＶＮに期待されるサービスを実行する。１つのＰＮを、複数のＶＮに結び付けることができる。
【００７８】
ＱＭ  クォーラム・モジュール：クラスタ・クォーラム機構、ならびにクラスタ結合／分離機構を提供する。実際のクラスタ・メンバーシップ情報は、ＩＭＦ内に保持される。
【００７９】
ＲＤ  リロケーション・ディレクトリ：すべてのボリューム中に存在し、クライアントからは隠されており、スクイジー・リンクを通じて参照されるＦＳＯを収容するために使用される特別なディレクトリ。
【００８０】
ＳＡＮ  ストレージ・エリア・ネットワーク。
【００８１】
ＳＩＭ  ストレージ・インターフェイス・モジュール：セクタ・キャッシュの管理およびＳＡＮバックエンドとのやり取りに充てられたハードウェア・モジュール。
【００８２】
ＳＬ  スクイジー・リンク：ハード・リンクとして機能するが、ファイル・システム・ボリュームを横断して指定することができるリンク。
【００８３】
ＶＮ  仮想ノード：仮想ＩＰアドレス、仮想ノード名、いくつかのリソース（主にストレージ・ボリューム）、およびおそらくはサービスの集合を包含する論理抽象概念。ＶＮはそれぞれＰＮに関連付けられ、複数のＶＮを同じＰＮに関連付けることができる。
【００８４】
ＶＰＤ  仮想ペアレント・ディレクトリ：別のボリュームのディレクトリへのＳＬを収容しているディレクトリ。別のボリュームの物理的なペアレントではないが、ペアレント・ディレクトリとして振る舞わなければならない。
【００８５】
ＷＦＳ  ＶＬＳＩファイル・システム：このモジュールは、ファイル・システム・サポート機能のＶＬＳＩ実装である。これは正確な頭文字ではなく、本来の頭文字ＶＦＳが、Ｕｎｉｘ（登録商標）システムのＶｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ  ｌａｙｅｒとの混同を避けるためＷＦＳに変更されたものである。
【００８６】
「データ・ストレージ・システム」は、任意の適切な大データ記憶構成であって、これらに限られるわけではないが、１つ以上の磁気または光磁気あるいは光ディスク・ドライブ、半導体記憶装置、および磁気テープからなるアレイが含まれる。便宜上、データ・ストレージ・システムを、「ディスク」または「ハードディスク」と称することもある。
【００８７】
「ハードウェア実装サブシステム」は、主要なサブシステム機能がソフトウェア・プログラムの直接制御の外で動作する専用のハードウェアによって実行されるサブシステムを意味する。そのようなサブシステムが、ソフトウェア制御下のプロセッサとやり取りできるが、サブシステムそのものはソフトウェアによる直接制御下にはないことに注意すべきである。「主要な」機能とは、最も頻繁に使用される機能である。
【００８８】
「ハードウェア・アクセラレーテッド・サブシステム」は、主要なサブシステム機能が専用のプロセッサおよび専用のメモリ、ならびにこれらに加え（あるいはこれらに代えて）特殊目的のハードウェアを使用して実行されるサブシステムサブシステムを意味し、ここで専用のプロセッサおよびメモリは、あらゆる中央演算ユニット（ＣＰＵ）およびＣＰＵに関連するメモリと別個である。
【００８９】
「ＴＣＰ／ＩＰ」は、とりわけ、ｗｗｗ．ｉｅｔｆ．ｏｒｇのＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅのウェブサイトで規定されたプロトコルであり、このウェブサイトは、ここでの言及によって本明細書に組み込まれたものとする。「ＩＰ」はインターネット・プロトコルであり、同じ場所で規定されている。
【００９０】
「ファイル」は、データの論理的連関である。
【００９１】
プロトコル「ヘッダ」は、当該プロトコルのユーザに関連付けられたデータの伝送のために当該プロトコルによって指定されたフォーマットの情報である。
【００９２】
「ＳＣＳＩ関連」プロトコルには、ＳＣＳＩ、ＳＣＳＩ−２、ＳＣＳＩ−３、Ｗｉｄｅ
ＳＣＳＩ、Ｆａｓｔ  ＳＣＳＩ、Ｆａｓｔ  Ｗｉｄｅ  ＳＣＳＩ、Ｕｌｔｒａ  ＳＣＳＩ、Ｕｌｔｒａ２  ＳＣＳＩ、Ｗｉｄｅ  Ｕｌｔｒａ２  ＳＣＳＩ、または任意の同様なプロトコル、あるいは任意の後継のプロトコルが含まれる。ＳＣＳＩとは、「Ｓｍａｌｌ
Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ」を指し、ｗｗｗ．ａｎｓｉ．ｏｒｇにウェブＵＲＬアドレスを有するＡｍｅｒｉｃａｎ  Ｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄ  Ｉｎｓｔｉｔｕｔｅ（ＡＮＳＩ）によるコンピュータ周辺機器のパラレル接続のための規格である。
【００９３】
「第３層および第４層」と称する場合、ＩＳＯ規格であるＯｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ（「ＯＳＩ」）の７階層モデルにおける第３層および第４層を意味する。ＩＳＯ（国際標準化機構）は、ｗｗｗ．ｉｓｏ．ｃｈにウェブＵＲＬアドレスを有する。
【００９４】
「メタデータ」は、実際のファイル・コンテント・データに対し、ファイル・オーバヘッド情報を意味する。
【００９５】
「ファイル・コンテント・データ」は、ファイル・オーバヘッド情報を除くファイル・データを指す。
【００９６】
「書き込み」は、所与のストレージ・ボリュームにおいて、データのコンテントまたはメタデータを変更する操作を指す。
【００９７】
１．２  参考文献
以下の参考文献は、そのすべてがここでの言及によって本明細書に組み込まれるものとするが、本明細書の全体を通じ、カッコ内の参照名を使用して引用される。
【００９８】
【数１】
2010108520.tif 000002
【００９９】
【数２】
2010108520.tif 000003
【０１００】
【数３】
2010108520.tif 000004
１．３  典型的なファイル・サーバ・アーキテクチャ
本明細書に記載の主題に、本件出願と所有者が同一であって同一日に出願されたＧｅｏｆｆｒｅｙ  Ｓ．  Ｂａｒｒａｌｌ、Ｓｉｍｏｎ  Ｌ．  Ｂｅｎｈａｍ、Ｔｒｅｖｏｒ  Ｅ．  Ｗｉｌｌｉｓ、およびＣｈｒｉｓｔｏｐｈｅｒ  Ｊ．  Ａｓｔｏｎによる「Ａｐｐａｒａｔｕｓ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｈａｒｄｗａｒｅ−Ｂａｓｅｄ  Ｆｉｌｅ  Ｓｙｓｔｅｍ」という名称の米国特許出願第１０／２８６，０１５号が関連し、この米国特許出願は、その全体がここでの言及によって本明細書に組み込まれたものとする。
【０１０１】
図１は、本発明の種々の態様を適用することができるファイル・サーバの実施の形態のブロック図である。この種のファイル・サーバは、２００１年４月１９日公開の「Ａｐｐａｒａｔｕｓ  Ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｈａｒｄｗａｒｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｏｒ  Ａｃｃｅｌｅｒａｔｉｏｎ  ｏｆ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｆｕｎｃｔｉｏｎｓ」という名称のＰＣＴ出願公開番号ＷＯ０１／３８１７９  Ａ２に記載されており、この文献は、本件発明の共同発明者がやはり共同発明者である発明を記載しており、個々での言及によって本明細書に組み込まれたものとする。この図１は、前記ＰＣＴ出願の図３におおむね相当するものである。ここで、図１のファイル・サーバ１２は、ネットワーク１１と通信するサービス・モジュール１３を含むいくつかの構成要素を有している。サービス・モジュール１３は、ネットワークを介してサービス要求を受信してこれに応答し、ストレージ・アクセスに関するサービス要求を関連のファイル・システム・プロトコルにとって適切なフォーマットへと変換する（さらに、そのようなフォーマットを、そのような要求への応答を生成すべく変換する）ファイル・システム・モジュール１４と通信する。次いで、ファイル・システム・モジュール１４が、ストレージ・モジュール１５と通信し、ストレージ・モジュール１５が、ファイル・システム・モジュール１４の出力を、ストレージ・モジュール１５が通信するストレージ・システムへのアクセスを許容するフォーマットへと変換する。ストレージ・モジュールは、ストレージから読み出され、あるいはストレージへと書き込まれるファイル・コンテント・データのためのキャッシュを有している。前記ＰＣＴ出願に記載のとおり、種々のモジュールのそれぞれを、ハードウェアに実装することができ、ハードウェア・アクセラレーテッドとすることができる。
【０１０２】
図２は、図１の実施の形態の実装例のブロック図である。この実装例においては、図１のサービス・モジュール１３、ファイル・システム・モジュール１４、およびストレージ・モジュール１５が、それぞれネットワーク・インターフェイス・ボード２１、ファイル・システム・ボード２２、およびストレージ・インターフェイス・ボード２３によって実装されている。ストレージ・インターフェイス・ボード２３が、この実施の形態において使用するストレージ・システムを構成しているストレージ装置２４と通信する。この実装例に関するさらなる詳細は、２００１年６月１２日出願の「Ａｐｐａｒａｔｕｓ  Ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｈａｒｄｗａｒｅ  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｏｒ  Ａｃｃｅｌｅｒａｔｉｏｎ  ｏｆ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｆｕｎｃｔｉｏｎｓ」という名称の米国特許出願第０９／８７９，７９８号に記載されており、この米国特許出願は、ここでの言及によって本明細書に組み込まれたものとする。
【０１０３】
１．４  クラスタの種類
一般的に言って、以下の２種類のクラスタが存在する。
【０１０４】
１．Ｎ＋１  ＨＡ（フェイルオーバ）クラスタ。これらの種類のクラスタにおいては、アプリケーションまたはサービス（ＮＡＳヘッドなどの特殊目的の装置に適用されるとき、用語「アプリケーション」は、以下では「サービス」の同義語として使用される）は、１つのノードにおいて「アクティブ」モードで実行され、他のノードにおいて「スタンバイ」モードで実行される傾向にある。この種類のクラスタは、可用性を提供するが、拡張性は提供しない（可用性と拡張性の間に明確な区別が常に存在するわけではないが）。
【０１０５】
２．パラレル・クラスタ。これらの種類のクラスタにおいては、アプリケーションまたはサービスが、２つ以上のクラスタ・ノードに分散されたやり方で実行される。これは、可用性と拡張性の両者をもたらす。
【０１０６】
以下に説明する典型的なファイル・システム・クラスタリングのソリューションは、パラレル・クラスタ・モデルにもとづいており、クラスタ・ノードの数（限界内）に関して性能を向上させ、クラスタの１つ以上のメンバーにおいて生じうるクラッシュにかかわらずファイル・システム・オブジェクト（ＦＳＯ）がアクセス可能に保たれるよう、高度に可用（ＨＡ）であると期待される。一方で、以下に説明する典型的なファイル・システム・クラスタリングのソリューションは、アプリケーションを実行できる汎用目的のコンピュータ・クラスタを提供するものとも、フォルト・トレラントなプラットフォームを提供するものとも予想されない。これらの条件は、本発明の特定の実施の形態に課された要件を表わしており、本発明そのものを限定するものではない。
【０１０７】
１．５  論点
以下で検討する主たる論点は、以下のとおりである。
・ここに提案するクラスタリングのソリューションによってもたらされる可能性を、限界および固有の制約のリスト、ならびに性能および可用性の両者に関する期待値とともに示すこと。
・このソリューションによって解決すべき重要な技術的課題、すなわち
どのクラスタ・ノードがクラスタ化されたファイル・システムのどの構成要素を管理するのか、およびクラスタ化されたグローバル名空間がどのように統合されるのか、
さまざまな種類の要求（読み出しアクセス、変更）が、性能向上のためクラスタにおいていかに取り扱われるのか、
故障を診断して高い可用性を提供するため、クラスタ・ノードの監視がどのように実行されるのか、
故障ノードの発生によってストレージ・ボリュームの引き継ぎがどのように管理されるのか、
クラスタがどのように管理および構成されるのか、および
典型的な実装のためのさまざまな構成要素。
【０１０８】
以下に続くセクションにおいて、本発明の典型的な実施の形態をさらに詳細に説明する。セクション２は、ソリューションの要件および潜在的境界に向けられている。セクション３は、詳細なソリューションを概括する。セクション４は、種々の実装上の問題に向けられている。セクション５は、多ボリューム操作のフォーマル・フォルト分析を示している。
【０１０９】
２  要件および全体のアーキテクチャ
このセクションは、要件をより詳細に概括する。さらに、基本的なアーキテクチャ上の選択肢、ならびに解決すべき鍵となる技術的課題のいくつかを概括する、
２．１  要件
先の検討にもとづき、このアーキテクチャが満足すべき要件は、以下のとおりである。
【０１１０】
１．ここに記載するソリューションは、セクション１．３においてすでに述べた種類の特定のファイル・サーバを目標としているが、本発明がそれに限られるわけではまったくなく、ここで検討するさまざまな要素が、広くファイル・サーバ・クラスタ一般に適用可能であることは明らかである。
【０１１１】
２．クラスタ化ソリューションにおいて達成可能な統合化性能は、クラスタの部分であるノードの数に関して擬線形の拡大が生じるようなものである。しかしながら、クラスタ化できるノードの最大数は限られているため、このソリューションの目的が、拘束のない拡張性にあるわけではないことに注意すべきである。
【０１１２】
３．クラスタ化の仕組みが、高度な拡張性をもたらす。これは、クラスタによって管理される論理ボリューム内のあらゆるＦＳＯのアクセシビリティを含むべきである。そのようなシステムにおいて可用性は、０．９９９９９以上でなければならない（「ファイブ・ナイン」基準と称されることがある）。これは、クラスタ・ノードの故障の検出およびその後の回復を、不稼働時間を１年間につき約５分に押さえることによって実行することを必要とする。
【０１１３】
４．高可用性要件の間接的結果として、クラスタ・ノードを動的にクラスタに結合でき、クラスタから分離できるべきである。これは、ノードの故障および回復のためにとくに重要であるが、広くより柔軟な環境を提供するためにも使用することができる。
【０１１４】
５．クラスタ・ノードのそれぞれを個々に構成するのと対照的に、ユニットとしてのクラスタ全体の管理および構成が可能であるべきである。
【０１１５】
６．クラスタが提供するであろうファイル・システム・イメージは、１つのツリーからなり、クライアントが接続するクラスタ・ノードにかかわらず均一である。
【０１１６】
７．実装のコスト／労苦、ならびに全体の複雑さが、ファイル・システム・クラスタリングのソリューションを計画する際に考慮される。
２．２  全体アーキテクチャの選択肢
以下では、適切な機構（フロントエンド・スイッチ、またはクラスタ・ノードへのクライアントの静的なパーティショニングなど）が、クラスタ・ノードとネットワークとの間に介装されるものと仮定する（これは論理的観点であり、実際においてスイッチが使用される場合、高可用性の要件を満足するために二重化されることが通常である）。その目的は、クラスタ・ノード間の負荷をバランスさせることにある。これについては、セクション３でより詳しく検討する。
【０１１７】
さらに、あらゆるクラスタ・ノードは、論理ボリュームの集合を通じて得られたファイル・システムを１つのエンティティとして眺めるものと仮定される（前記要件６を参照）。
【０１１８】
２．２．１  考えられる代案  Ｍｉｃｒｏｓｏｆｔ  Ｃｌｕｓｔｅｒｉｎｇ  ｐｒｏｄｕｃｔに実装されるような「無共有」の性質のクラスタリング・ソリューションは、ストレージの相互に排他的なサブセットを管理するクラスタ・ノードを設けることによって、高可用性（ＨＡ）の要件をサポートできる。サーバの１つがクラッシュした場合にのみ、他のサーバが、クラッシュのためにもはや可用でないストレージ・ボリュームの取り扱いを引き継ぐ。当然ながら、これにより設計が簡潔に保たれ、可用性が増す。
【０１１９】
この仕組みは、同じストレージ・ボリュームに対する同時多発アクセスの場合において、それらがすべて同じくラスタ・ノードを通って送られなければならず、ボトルネックとなりかねないことを意味している。したがって、この仕組みは、別個のサーバが使用されてそれぞれが自身のストレージ・ボリュームを取り扱っている状況に対し、性能という点でなんら向上をもたらさない。
【０１２０】
一方で、この形式のアーキテクチャは、故障引き継ぎの能力を提供し、高可用性（ＨＡ）のソリューションを実現する。しかしながら、ファイル・システム・クラスタリングのソリューションの鍵となる焦点は、性能に関して当該ソリューションの拡張性の向上にあり、このアプローチは、本発明の実施の形態にとくによく適しているというわけではない。
【０１２１】
それとは正反対に、完全に共有されたボリューム・オーナシップを備える分散ファイル・システムにもとづくクラスタリングの仕組みを考えることも可能である。これは、あらゆるクラスタ・メンバーが、いかなる静的または半静的なオーナーシップの割り当て政策もなく、一度に各ＦＳＯについて機能できることを意味する。これを行なうべく、いくつかのアーキテクチャが考え出されている。しかしながら、それらのソリューションの多く（参考文献［Ｔｈｅｋｋａｔｈ  １９９７］および［Ｐｒｅｓｌａｎ  １９９９］）は、頑丈かつ複雑であり、開発、デバッグ、および展開が困難な複雑な分散ロッキング・プロトコルにもとづいている。
【０１２２】
要件７ゆえ、この文献では、クライアント・アプリケーションおよびエンドユーザによって知覚されたとき、開発コスト／複雑さと達成可能な利益との間の妥当なバランスをもたらす仕組みを説明する。
【０１２３】
２．２．２  ＤｉＦＦＳ
ここに記載するソリューションは、ＤｉＦＦＳアーキテクチャ（参考文献［Ｋａｒａｍａｎｏｌｉｓ  ２００１］）に大まかにもとづいている。ＤｉＦＦＳの提案は、以下のコンセプトを実装するアーキテクチャを考案することによって、分散ロッキングおよびキャッシュの一貫性に関する問題を大幅に簡略化する。
【０１２４】
１．ただ１つのアクティブ・クラスタ・ノードが、ファイル・システム論理ボリュームの変更を担当する。以下では、このノードを「ボリューム・オーナ」と称する。
【０１２５】
２．複数のクラスタ・ノードがすべてのＦＳＯへの読み出しアクセスを有し、ＳＡＮバックエンドにアクセスすることによってクライアントからの読み出し要求に直接仕えることができる。
【０１２６】
３．クラスタ内のコヒーレンシをサポートするため、ストリームライン化されたノード間プロトコルが利用可能である。
【０１２７】
４．ＦＳＯ参照（ディレクトリ・リンク）が、論理ボリュームにまたがることができる。
【０１２８】
５．ＦＳＯリロケーションが利用可能であり、実際、よりよい拡張性を達成するため、ＦＳＯをホスト・スポットから直接リロケートするために使用される。
【０１２９】
６．ファイル・システム操作における順序付けが、生じうるファイル・システム不整合を、非同期ごみ収集によって定期的に除かれる「オーファン」ファイル（すなわち、ディスク・スペースを使用しているが、あらゆるディレクトリ参照が除去されたためもはやアクセスできないファイル）にのみ相当するようにする。関連プロトコルの完全な仕様が利用可能である。
【０１３０】
ＤｉＦＦＳに埋め込まれたコンセプトは、これらだけではない。しかしながら、これらは以下の検討に最も関係があり、なぜならば、このアーキテクチャが最初の４つに依存し、程度はより少ないが、最後の２つにも依存しているからである。
【０１３１】
以下では、用語「読み出し」を、更新を伴わないＦＳＯへのアクセスを意味しておおまかに使用する。例は、ファイル読み出し、ディレクトリ・サーチ、およびファイル属性またはオーナーシップ情報の要求である。同様に、用語「書き込み」を、オブジェクトのあらゆる修正を意味して使用する。これには、ファイルの書き込み、新規オブジェクトの作成および削除、属性の変更などが当てはまる。
【０１３２】
２．２．３  基本的な仮定
このアーキテクチャは、完全に自己完結のボリュームを想定している。これは、論理ボリューム間のいかなる物理的な相互参照（Ｕｎｉｘ（登録商標）の「ハード・リンク」など）も存在しないことを意味する。換言すると、ボリューム内の各ファイル・システム・ツリーが、自身の外の物理ポインタを有していない。物理的に自己完結である論理ボリュームを有することで、モデルが簡潔になり、完全性チェックがより簡単になり、効率的な実装に好適である。これに加え、より良好な故障の隔離（高度に可用なプラットフォームのための鍵となる属性である）がもたらされる。
【０１３３】
これの明らかにマイナスな結果は、以下のとおりである。
・１つの論理ボリューム内のファイル・システムから異なるボリューム内に実装されたＦＳＯへの参照が存在しない可能性がある。
・異なるボリュームのＦＳＯのいくつかを割り当てることによって１つのボリューム内のツリーを広げることが、できないと思われる。
【０１３４】
しかしながら、一見に反し、これらの結果は以下の理由からいずれも真実ではない。
・あとで示されるように、ハード・リンクのシンボリックかつ特別な変種を、ボリュームを横断する論理リンクの存在が期待されるあらゆる場所で使用できる。後者は、実際、ＮＡＳクライアントの利益のためのボリュームを横断するハード・リンクのセマンティクスの実装である。シンボリックなリンクおよび特別なハード・リンクのセマンティクスは、ボリューム横断の参照が、ファイル・システム完全性ルールに影響しないようなものである。
・あとで示されるように、ここのボリュームの空間的限界が、実際には、単に他のボリューム内に新しいファイル・システム・オブジェクトを割り当てるだけで克服できる。
【０１３５】
このアーキテクチャが、複数のボリュームを横断する１つのファイル・システム・イメージ（図３参照）をサポートしており、ただいま説明した問題ゆえ、このクラスタリングの仕組みが１つの巨大ボリュームを実装しないが、そのような仕組みのすべての有用な属性を保持していると思われる点に注目すべきである。
【０１３６】
実際上の多くの場合において、各クラスタ・ノードが、グローバル・ファイル・システムを実装するボリュームの少なくとも１つを管理すると仮定される。したがって、ボリュームの典型的な最小数は、クラスタ・ノードの数に等しい。しかしながら、これがこのアーキテクチャの厳格な要件ではなく、クラスタ・ノードの数がクラスタ化ファイル・システムを構成するボリュームの数よりも多くても、等しくても、あるいは少なくてもよいことに注意すべきである。
【０１３７】
ＤｉＦＦＳの基準１にもとづき、個々のボリュームは、１つのクラスタ・ノードに所有される。そのようなオーナ・ノードは、当該ボリュームのコンテントの修正が許されているただ１つのノードである。一方で、基準２にもとづき、すべてのノードが、読み出しのみのモードであらゆるボリュームへのアクセスを許されている。これは、或るボリュームへのすべての読み出しアクセスを並行して実行できる一方で、或るボリュームのあらゆる修正は、そのオーナ・ノードを通過しなければならないことを意味している。
【０１３８】
上記に加え、このアーキテクチャは、所与のＦＳＯを参照するために使用される論理パス名を、ＦＳＯが物理的に存在している実際の場所から分離させる。あとで示されるように、この能力のため、クラスタ・アーキテクチャは高いスループットを提供できる。
【０１３９】
上記の選択は、いくつかの関連する影響を含んでいる。所与の論理ボリュームについてのすべての修正要求を当該ボリュームのオーナに集中させることによって、これが潜在的にボトルネックとなりうることが明らかである。もたらされる明白な利点は、プロトコルのストリームライン化および複雑さの低減である。しかしながら、これが性能に与えるであろう影響の大きさを評価するにあたって、トラフィックの大部分が実際のところ読み出し操作からなると予想することが、確かに適切である。これは、以下の理由から、さらに確認されなければならない。
【０１４０】
１．クライアント側に実装されたキャッシュが、クライアント側のキャッシュからの読み出し要求を満足させることができる。これは、実際、書き込みの味方をして、読み出しと書き込みの実際のアンバランスを減らす傾向にある。
【０１４１】
２．読み出しは同期的であって、書き込みは多くの場合非同期である。したがって、あらゆるクラスタ・ノードは読み出しを直接制御でき、良好な応答時間が期待できる。
【０１４２】
３．読み出し操作は、アクセスされるＦＳＯを表わしているｉ−ｎｏｄｅについてのアクセス時間が更新されなければならないという副作用を有している。ｉ−ｎｏｄｅは、Ｗｉｎｄｏｗｓ（登録商標）  ＮＴにおいてファイル・レコードと等価であり、それが記載するファイル・システム・オブジェクトについてのメタデータデータ情報を保存するファイル・システム・データ構造である。この副作用は、実際、あらゆる読み出し操作を、論理ボリュームのオーナによって取り扱われなければならない書込み操作に変化させる。これは、事実上すべての読み出しアクセスを書き込みアクセスに変換し、この仕組みを深刻なボトルネックに変えるため、きわめて不都合である。
【０１４３】
しかしながら、解決手段は、ｉ−ｎｏｄｅアクセス時間の更新におけるより厳しくない基準、およびボリューム・オーナに対する軽量かつ非同期の呼び出しの使用に依存している。これは、アクセス時間が「セッション・セマンティクス」を呈するやり方で実行できる（参考文献［Ｌｅｖｙ  １９９０］）。
【０１４４】
ａ．ローカル・キャッシュ内のｉ−ｎｏｄｅのコピーのアクセス時間は、それを無効にすることなく修正できる。
【０１４５】
ｂ．次いで、同じことを実施してｉ−ｎｏｄｅをダーティとしてマークするよう、（フラッシュを要求することなく）ボリューム・オーナに通知が送信される。
【０１４６】
ｃ．ｉ−ｎｏｄｅのマスタ・コピーが変更を蓄積し、適切なときにフラッシュされ、クラスタにわたるすべてのキャッシュ・コピーを無効にする。
【０１４７】
３  クラスタリングの仕組み
先のセクションにおいて概括した問題が、少なくとも検討のための全体的枠組みを提供する。しかしながら、それらは単に、詳細に分析すべき問題の表面を引っ掻くのみである。
【０１４８】
このアーキテクチャにおいて、根底にある仮定は以下のものである。
【０１４９】
１．クラスタのクライアントをクラスタ・ノード間でパーティションするために、適切な負荷バランス機構が利用できるものと仮定される。この機能は、スイッチによって実装され、パーティション化はユーザのアイデンティティに関して行なわれる（さらには、これに先んじて）。負荷バランスについては、セクション４．１でさらに説明する。
【０１５０】
２．クラスタ間の高速相互接続が利用可能である。これは、クラスタ内キャッシュのコヒーレンシおよび複製をサポートし、操作要求をリレーして他のクラスタ・ノードへと応答を届けるために使用される。このクラスタ内相互接続については、セクション４．２でさらに説明する。
【０１５１】
３．高可用性モジュールが、システムの冗長性の保証およびその連続動作を担当する。
【０１５２】
以下のサブセクションで、このアーキテクチャをより詳細に説明する。
【０１５３】
３．１  アーキテクチャ
アーキテクチャの詳細な説明には、キャッシングおよびロッキングのファイル・システム名前空間の構造の説明が必要である。
【０１５４】
３．１．１  名前空間
本明細書の残りを読んだのちに明らかになるとおり、ここで定めるアーキテクチャは、１つのボリュームが全ファイル・システムのルートとして機能できるようにする。他のすべてのディレクトリおよびファイルは、他のボリューム内に割り当てることができるが、そのようなルートで始まるパス名によって参照される。これは、このアーキテクチャのクライアントの典型的ニーズにとって、的確、簡潔、かつ適切である。
【０１５５】
クラスタが構成されたのち、そこにそれまでは独立であるクラスタ（それまではスタンドアロンであるユニット）を加えたいと望む場合、最終的な結果は、新しいクラスタ・ルートにもとづかなければならないため、加えられるノード／クラスタのすべてのパス名を変更しなければならないというものである。しかしながら、共有、エクスポートされたマウント点、およびボリューム間リンクは、これを避けることができる。
【０１５６】
クラスタ内の各ボリュームは、「ボリュームＩＤ」と呼ばれる固有の数値ＩＤによって特定されなければならない。この固有のＩＤは、決して再使用されてはならない。
【０１５７】
ボリュームをグローバル・ファイル・システム・ヒエラルキを通じてアクセス可能にする行為は、「マウント」として知られている。
【０１５８】
個々のボリュームについてのマウント順序は、それらがマウントされる順序に関してインデックス番号（「マウント・インデックス）が各ボリュームに割り当てられるという点にのみ関係がある。このインデックスは、ボリュームのマウントが解除されるまで有効あり、ボリューム間の総順序の関係を実装するために使用される。これは、循環性を取り除いて、生じうるデッドロックを防止するため、マウント・インデックス値を増加させることによって異なるボリュームに位置する複数のＦＳＯをロックする必要がある場合に有用であろう。
【０１５９】
論理ボリュームは自己完結であり、論理ボリューム間に物理的な相互参照が存在する必要がないことを意味する。換言すれば、グローバル・ルート・ボリュームが、クラスタによってサポートされる森のすべてのツリーを一括して扱ってもよく、一括して扱わなくてもよいが、各ツリーは自身の外のポインタを有していない。シンボリック・リンク（および、下記にて紹介する「スクイジー・リンク」）が、ボリュームの外部のＦＳＯを指定する能力を実現することに注意すべきである。しかしながら、これは物理的ストレージという点では行なわれず、むしろシンボリック参照という点で行なわれる。したがって、そのようなポインタは、適切なコンテクストでの解釈の対象であり、ボリュームを自己完結に保つという基準に違反しない（これは、ＤｉＦＦＳに実装される仕組みからの大きな逸脱である）。論理ボリュームを完全に自己完結にするというこの属性は、モデルを簡単にし、完全性のチェックを単純にし、効率的な実装に適している。
【０１６０】
したがって、論理ボリュームが自己完結であるという事実にもかかわらず、ボリューム間参照が、シンボリック・リンクおよび「スクイジー・リンク」と呼ばれるハード・リンクの変種の形で利用可能である。後者は、ＮＡＳクライアントのためのボリュームを横断するハード・リンク・セマンティクスを完全に実装する。これらは、以下のサブセクション３．１．２．１で定義される。
【０１６１】
以上の理由で、このクラスタリングの仕組みは、複数のボリュームを横断する１つのファイル・システム・イメージ・セマンティクスの実装を可能にする。図１に示したような論理ヒエラルキが、マウントされたボリュームの純粋なネスティングの能力を超えておりながら、それらが好都合にここに記載のアーキテクチャの届く範囲内であることに注意すべきである。例えば、ファイル「Ｃ」および「ｙ」が、同じボリュームの一部でありながら、共通のサブツリーの一部ではない。
【０１６２】
３．１．２  ローカルおよび外部参照
ここに記載するような設計は、各論理ボリュームのための「ボリューム・オーナ」の役割を、半静的なやり方（すなわち、ノードがクラスタに加わったときから、シャットダウンまたはクラッシュなど、いかなる理由にせよ当該ノードがクラスタを離れるときまで）でただ１つのクラスタ・ノードに割り当てるため、論理ボリューム更新の管理の問題を簡単にする。同時に、それはクラスタ・ノードを横断する相互に排他的ではないキャッシュを必要とする。これは、ただ１つのノードが論理ボリューム・オーナであるとしても、複数のノードが読み出しのために１つのボリュームに同時にアクセスしうるためである。したがって、結果として生じる主要な問題は、ＳＡＮバックエンドを通じて読み込まれ、読み出しのみのアクセスを供えるノードにキャッシュされたデータが、論理ボリューム・オーナによって実行される修正に関して古くならないようにすることにある。これは、キャッシングおよびロッキングについてのセクションで詳細に取り扱われる。
【０１６３】
クライアントから入ってくるリクエストが処理されるときは常に、「ローカル」参照と「外部」参照とを区別する必要がある。ローカル参照は、論理ボリュームをアドレスしたＩ／Ｏ要求であって、当該ボリュームのオーナが当該要求の受領者である。外部参照は、論理ボリュームをアドレスした要求であって、要求の受領者が当該ボリュームのオーナではない。
【０１６４】
これら要求の初期において、コードが２つの場合の間で区別されなければならない。さらに、外部要求は、それらが読み出し形式のものであるか、書き込み形式のものであるかに応じて弁別されなければならない。以下が、それぞれの場合において取られる行為の概要である。
・ローカル読み出しおよび書き込みについて、要求を直接実行する。
・外部読み出しについて、要求を直接実行する。
・外部書き込みについて、要求をボリューム・オーナに向け直す。
【０１６５】
この設計の負の特徴は、以下のものである。
・作業負荷において１つのボリュームへの外部書き込みが支配的であるとき、ボリューム・オーナがボトルネックとなりうるため、うまく拡張されない。このような何かが生じうる考えられるユーザ側のシナリオは、以下のものである。
【０１６６】
多数のクライアントが、同じボリューム内において「書き込み」操作についてきわめて活動的である場合。
【０１６７】
同じボリューム内の多くのファイルが、異なるクライアントによって多重的に編集される場合。
・ＳＩＭ（ストレージ・インターフェイス・モジュール−ＳＡＮバックエンドおよびホストとセクタ・キャッシュをやり取りするシステム・ボード）キャッシュのコンテントが、同じセクタにアクセスしているすべてのノードにわたって複製される。これは、統合クラスタ・キャッシュの全体的な効率をいくらか制限する。この負の属性がこの設計に存在するが、これは多くのクラスタ設計に共通である。
【０１６８】
正の側面は、以下のとおりである。
・読み出し操作が、要求に関連するボリュームにかかわらずクラスタ・ノードを横断して並列に効率的に取り扱われる。
・ファイル・システム内の実際の書き込み操作は、ボリューム・オーナによって実行されなければならないが、プロトコル処理の大部分は要求を受信するノード内で実行される。これが、ボリューム・オーナの負荷を制限する。
・ボリュームのオーナがボリューム・コンテントの更新を許されている唯一のノードであるというルールが、分散された設計にもとづく必要がないため、ファイル・システム・アーキテクチャを大幅に簡略化する。これが、関連の開発コストおよびリスクを少なくする。
【０１６９】
しかしながら、ＦＳＯパス名の概念をその場所（すなわち、ＦＳＯが位置するボリューム）から分離させることにより、この設計の拡張性を向上させることが可能である。これは、すでに述べた「スクイジー・リンク」によって実行できる。
【０１７０】
３．１．２．１  スクイジー・リンク
スクイジー・リンク（以下では、ＳＬ）は、シンボリック・リンクとハード・リンクの間の混成である。それは、異なるボリュームに保存されたＦＳＯへのシンボリック参照を提供する。
【０１７１】
ＳＬは、常に、各ボリューム内で利用可能な既知のディレクトリ（「リロケーション・ディレクトリ」、以下では、ＲＤ）に保存されたＦＳＯを参照する。このディレクトリは、ＮＡＳクライアントからは隠されている。ＲＤ内のすべてのＦＳＯは、１６進値を符号化する名前を有し、「リロケーテッドＦＳＯ」と呼ばれる。そのような値が、新しいＲＤエントリが生成されたときに自動的に生成され、単調に増加すべきである点に注意すべきである。この値が、６４ビット・アドレス空間にマップされる。値０は、ヌルとして使用される。
【０１７２】
ＳＬは、ディレクトリ・エントリをボリュームＩＤを含むべく拡張することによって実装できる。したがって、「通常の」ディレクトリ・エントリ（ハード・リンク）は、ボリューム内のどこかのローカルＦＳＯを指し、ローカル・ボリュームＩＤおよびローカルｉ−ｎｏｄｅ番号（すなわち、「ｉ−番号」）を含んでいる。一方、ＳＬは、異なるボリュームＩＤを指し、ｉ−番号は、目標ボリュームのＲＤ内の参照されるＦＳＯの名前を表わしている数字列を符号化する数値によって置き換えられている。以下では、この数値ＩＤを「外部番号」または「ｅ−番号」と呼ぶ。したがって、ＳＬはシンボリックな形式であり、別個のｉ−ｎｏｄｅの割り当てを回避している。シンボリック参照を含むことによって、ＳＬはそれらが指し示すボリュームの詳細の物理的知識を有さない。別個のｉ−ｎｏｄｅの割り当てを回避することで、ストレージが節約され、より効率的である。
【０１７３】
このアプローチを使用することで、ＳＬは以下の属性を有することになる。
・ファイルまたはディレクトリを参照するために使用できる（シンボリック・リンクが行なうように）。
・クライアント側において、ハード・リンクと弁別不可能である。
・シンボリック情報のみを埋め込んでいる。したがって、目標ボリュームの明白な内部知識を有しておらず、ボリュームが自己完結であるという制約に違反しない。例えば、ＦＳＯをサポートするｉ−ｎｏｄｅの知識が存在せず、したがって任意の時点においてｉ−ｎｏｄｅが変化しても、ＲＤ内のＦＳＯの名前が同じままである限り、ＳＬには影響がない。
・リロケーテッドＦＳＯを指しているＳＬは、ＦＳＯについてのリンク・カウントを増加させない。この点のもとで、ハード・リンクのみがカウントされ、それらはボリュームに対し常にローカルである。したがって、やはりボリュームの完全性は、外部で生じる何物にも影響されない。
・あらゆるファイルを、ハード・リンク（ローカルに）およびＳＬ（ＲＤに設定された適切なハード・リンクを通じて）の両者によって参照できる。
・ＲＤ内の各リンクが、それを指す正確に１つのＳＬを有する（所与のリロケーテッド・ファイルは、ＲＤ内に複数のハード・リンクを有することができるが、そのようなハード・リンクのそれぞれは、ただ１つのＳＬによってのみ指定されることができる）。これは、ＦＳＯについてのリンク・カウントの完全性を、複数のボリュームを横断する完全性制約を生成する必要なく保つために必要である。
・クライアントがＳＬを削除するとき、これはそれが位置するディレクトリからのＳＬエントリの削除、およびそれが参照するＦＳＯの名前の削除の両者を生じさせるべきである。これは、もたらされるＦＳＯ参照カウントに応じ、ＦＳＯそのものの削除を含んでもよく、含まなくてもよい。
・ＳＬをダングリング（ｄａｎｇｌｉｎｇ）なままにすべきではない。ダングリングなＳＬは、ＦＳＯの削除と参照しているＳＬの削除の時間の間にクラッシュが生じた場合に、一時的に生じる（ＳＬが、リンクが存在しているそれではないボリューム上のＦＳＯを参照するという事実のため）可能性があり、ダングリングなリンクは害を生じることはないが、クライアントに見えないままに残り、すでに述べたように扱われる場合、検出されると即座に除去される。シンボリック・リンクと同様、ＳＬは、実際には、存在しないオブジェクトを指しうる。これは、例えばＳＬが参照するボリュームがマウントされる前など、一時的な基準で生じうる。恒久的にダングリングなリンク（ボリュームにはアクセスできるが、葉にはアクセスできない）を検出したノードは、ＳＬを除くことによって対処すべきである。
・ボリューム間の「関心の分離」は、以下をサポートする。
【０１７４】
ボリュームの完全性および一貫性の執行が、はるかに容易であり、システム完全性チェッカを、異なるボリュームにわたって並列に実行できる。
【０１７５】
故障の隔離がはるかに良好であり、ボリュームの致命的な故障によって、ファイル・システム全体が停止することがない。故障したボリュームのファイルおよびディレクトリがアクセス不可能になるだけである。
【０１７６】
ＳＬの使用は、１つ以上のクラスタ・ノードを、ディレクトリ情報のための純粋なメタデータ・サーバとして使用できるようにする。これは、或るアプリケーション・シナリオにおいて意味があり、ディレクトリ・ヒエラルキのみを取り扱うべき１つまたは複数のノードにユーザ接続を割り当てないことによって得ることができる。
【０１７７】
ＳＬによって、パス名を実際のＦＳＯ位置から分離させることができる。このため、ノード障害の結果として、ＳＬが他のボリューム上の固有のＦＳＯを指すか、あるいはＲＤに生成されたＦＳＯが、もはやＳＬによって参照されないことによって実際に親なしであるかのいずれかが生じうる。これらが、いくらかのストレージ空間の一時的な浪費を生じさせるが、ボリュームそのものの完全性を損なうことがない点で、致命的な故障ではないことに注意すべきである。したがって、それらは故障後のボリュームの再マウントを妨げない。同時に、そのような生じうる不整合を除くことが望まれる。これは、ダングリングな参照がファイル・システムによって検知されるため、オンザフライで行なうことができる。
【０１７８】
これに加え、特別な清掃プロセスが、そのような不整合をボリューム（その完全性を個々にチェックできる）が使用されているときにバックグラウンドで非同期的に取り除くことによって、これを達成することができる。リロケーテッドＦＳＯを削除すべきであるか、あるいは所有しているＳＬに再接続すべきであるかを検出するために、充分な情報冗長性が存在する。恒久的にダングリングなＳＬは、アクセスされ「ファイル発見できず」のエラーが報告されたときに検出され、必要に応じて削除される。このような清掃は、それがクラッシュが生じたときに修正されるＦＳＯにのみ適用されるという点で、システム・クラッシュの場合に指示されたやり方で実行される。
【０１７９】
これに加え、ＳＬをクラスタ・アーキテクチャにおいて完全に利用するため、ＳＬに適用しなければならない他のいくつかの行動ルールが存在する。これについては、以下のサブセクションで検討する。また、ＳＬは、続くセクションおよび以下のセクション３．１．２．１．２において述べるとおり、ボリューム間参照のためのハード・リンクの概念を完全に一般化できる。
【０１８０】
３．１．２．１．１  スクイジー・リンクおよびディレクトリ
ディレクトリへのＳＬの生成が可能であるとき、ＳＬが厳密にクライアントへのハード・リンクとして振る舞うことを確実にするため、「．．」ディレクトリ・エントリを正しく取り扱うことが必要である。これは、「．．」が常に、エントリを含んでいるＲＤ（物理的なペアレント）ではなく、ＳＬを含んでいるディレクトリ（「仮想ペアレント・ディレクトリ」、すなわちＶＰＤ）にマップされるべきであるということを意味している。
【０１８１】
或るディレクトリを指すただ１つのリンク（ハードまたはＳＬ）が存在可能であるため、ディレクトリそのものは、ただ１つのＶＰＤを有することができる。したがって、ＶＰＤへの参照をディレクトリｉ−ｎｏｄｅに埋め込むことが可能である。この参照は、「ＶＰＤバックリンク」として特定される。
【０１８２】
これを行なう容易な方法は、ボリュームＩＤおよびｉ−番号を参照されたディレクトリｉ−ｎｏｄｅに埋め込むことである。しかしながら、このようにすることで、ボリュームの特定の情報が他のものに埋め込まれ、それは避けるべき何かである。したがって、以下の方法の１つに従って進むことが、より良好である。
【０１８３】
１．以下のとおり必要なマッピングを供給する参照ボリュームに保存されたファイルを使用することによる。
【０１８４】
リロケーテッド・ディレクトリｉ−ｎｏｄｅが、参照ＶＰＤのボリュームＩＤ、ならびにディレクトリそのものを特定するＲＤリンクのｅ−番号を保存する。オブジェクトがディレクトリであるため、「．」および「．．」に加えただ１つのリンクを有することができる点に注意すべきである。したがって、ただ１つのｅ−番号が保存される必要がある。
【０１８５】
各ボリュームが、ＶＰＤを含んでいるディレクトリのローカルｉ−番号と、リロケーテッド・ディレクトリを特定する＜ボリュームＩＤ、ｅ−番号＞の組との間の関連付けを記憶するシステム・ファイルを提供する。これを、「バックリンク・ファイル」と呼ぶ。このファイルが、ローカル・ボリュームに関するデータにもとづく情報のみを保存し、ローカル・ボリュームのみの走査によってチェックおよび再構成できることに注意すべきである。
【０１８６】
リロケーテッド・ディレクトリｉ−ｎｏｄｅがキャッシュされるとき、「．．」エントリは、リロケーテッド・ディレクトリｉ−ｎｏｄｅのボリュームＩＤ、リロケーテッド・ディレクトリのｅ−番号、および適切なボリュームのバックリンク・ファイルによって、リロケーテッド・ディレクトリの＜ボリュームＩＤ、ｅ−番号＞を介してインデキシングすることによって解決できる。次いで、得られたペアレント・ディレクトリについての＜ボリュームＩＤ、ｉ−番号＞の組をキャッシュできる（これは、ディスクには保存されない）。
【０１８７】
「．．」へのアクセスが企てられたとき、これをトラップして、キャッシュされた参照を返すことができる。
【０１８８】
２．ＶＰＤバックリンクを、パス名として参照ディレクトリｉ−ｎｏｄｅ内に置くことによる。これは、別個のファイルを有する必要を節約し、更新を簡単にし、間接の数を少なくする。一方で、可変長のパス名をｉ−ｎｏｄｅに埋め込む必要があり、ＶＰＤに到達するために完全なパス名の参照が必要である。これは、論理的にはより簡潔であり、ＶＰＤへの参照を保つためにオブジェクトを１つだけ更新すればよいが、ＶＰＤ（または、そのパス名中の任意のディレクトリ）の名前が付け直された場合に、保存されたＶＰＤバックリンクの一部としてその構成要素を有しているすべてのリロケーテッド・ディレクトリを、やはり更新しなければならないという点で大きな欠点を有している。これは、高価につく操作である。
【０１８９】
最初のアプローチは、少しだけ複雑である。しかしながら、名前の付け直しに影響がないため、こちらが好ましい。これは、ＶＰＤの参照が比較的頻繁ではない操作に相違ないため、性能に大きな不利益をもたらすとは考えられない。しかしながら、そのような状況においては、パス名をヒントとしてディレクトリｉ−ｎｏｄｅ内に保存（仕組み２のように）し、ヒントが無効である場合に第１のアプローチに依拠する混成の仕組みを実装することによって、適切な戦略を考案することができる。
【０１９０】
この仕組みが、リロケーテッド・ディレクトリがアクセスされたときにキャッシュのみを実行し、外部ボリューム情報をｉ−ｎｏｄｅ内に埋め込まない点に注意すべきである。
【０１９１】
３．１．２．１．２  スクイジー・リンクおよびボリューム間参照
ひとたびＳＬの概念が定められると、それを、ボリュームを横断するハード・リンクのセマンティクスの実装に有用に使用することができる。これは、これがグローバル・ファイル・システムが個々のボリュームによって実装されているという概念をクライアントから隠す最後のステップであるという点で、真に有益である。換言すれば、クライアントは、自身が任意のディレクトリからファイル・システム内の任意のファイルへのハード・リンクであると理解するものを、それらが存在するボリュームにかかわらず、常に生成することが可能である。
【０１９２】
ここで鍵となる問題は、ＮＡＳクライアントがファイルへのみのハード・リンクを生成するために適用できるＵｎｉｘ（登録商標）リンク（）システム・コールの実装である。事実上、ハード・リンクは、ボリューム間のリンクが望まれるとき、ＳＬを使用してエミュレートできる。削除の場合と同様、リンクが加えられようとしているボリュームを所有しているノードが、常に操作を実行するものと仮定される。受信しているノードがオーナではない場合、当該ノードが当該要求をオーナへと送る。考えられる場合は、以下のとおりである。
【０１９３】
１．「共に存在」する（それらが同じボリューム内に存在することを意味する）ファイルを指してハード・リンクが生成されるとき、これはボリューム内のハード・リンクの生成を必要とする。これは、リンク（）システム・コールに予想される標準的な挙動である。
【０１９４】
２．ファイルへのハード・リンクが生成され、２者が共に存在してはいないとき、まず、目標ファイルへのハード・リンクが、目標ファイルが位置しているボリュームのＲＤに加えられなければならず、次いでこの新しいリンクを参照する新しいＳＬが、適当なディレクトリに生成されなければならない。同じボリュームのＲＤに新しいリンクを生成するだけで、ファイルは動かされず、当該ファイルへの他の参照も影響されない。
【０１９５】
３．新しいハード・リンクが、ＳＬを通じて参照されるファイルを指さなければならないとき、ファイル・システムが、目標ファイル（既存のＳＬが指しているファイル）を含むＲＤ内に新しいハード・リンクを生成すべきである。したがって、目標ファイルについてのリンク・カウントが、１だけ大きくなる。最後に、新しいハード・リンクへの参照を埋め込んでなるＳＬを、適当なディレクトリに生成すべきである。
【０１９６】
これを完全にサポートするために、サブセクション３．１．２．１において述べた基本的なＳＬの機能を実装するために存在しなければならない機能に関し、ファイル・システムに追加の機能は必要がない。
【０１９７】
種々の場合の取り扱いは、このようなやり方で、以下の有用な属性をもたらす。
・ＳＬが、リロケーテッド・ファイルへのハード・リンクのみを参照することができるため、ＳＬの除去が、依然先に説明したように行なわれる。基本的に、異なるボリュームのデータ構造を結び付けるＳＬについての参照カウントを加える必要がない。ＳＬの除去は、ＲＤ内のハード・リンクの除去を生じさせる。これが、ファイル参照カウントの減少を生じさせ、次いで、参照数が０に達したときファイルは削除される。したがって、これを扱うために追加の符号を設ける必要がなく、ファイル参照カウント機構は影響を受けない。
・ＲＤ内の各ハード・リンク（＝名前）が、依然ただ１つのＳＬによって参照されるため、ハード・リンク名が、関連のＳＬへの参照を埋め込むために必要な情報を埋め込むことができる。
【０１９８】
これが、ＮＡＳクライアントへの完全なハード・リンク・セマンティクスを備えるボリューム間リンクを実装する機構を提供する能力を完全に一般化する点に注意すべきである。このようにして、２つの異なる名前空間が存在する。
・ハード・リンクを通じてＦＳＯに接続され、ＲＤにＦＳＯを含んでおり、それぞれが自身の内部ヒエラルキを有しているボリュームの集合によって実装された物理的な名前空間（システムによってのみ見ることができる）。
・ボリュームを横断して全ファイル・システムに広がる論理名前空間（ＮＡＳクライアントによって見られる）が、ハード・リンクおよびスクイジー・リンクによって接続されたＦＳＯから作られ、ハード・リンクとＳＬの間の相違を、ボリューム境界およびＲＤの存在とともにクライアントから隠す。図４は、ハード・リンクおよびＳＬによって実装されたこの名前空間を、論理的観点（左上）を参照しつつ描いている。図２において、ディレクトリ「Ｗ」およびファイル「ａ」を生成したクライアントが、ノードＰ（ボリューム１のオーナ）を通じてそのようにしており、ディレクトリ「Ｂ」およびファイル「ｘ」を生成したクライアントが、ノードＱ（ボリューム２のオーナ）を通じてそのようにしており、ファイル「ｃ」および「ｙ」がノードＲ（ボリューム３のオーナ）を通じて生成されている点に注目すべきである。
【０１９９】
３．１．２．１．３  スクイジー・リンクの動作
このセクションでは、ＳＬに実装される動作についてさらに詳細に説明する。
【０２００】
３．１．２．１．３．１  スクイジー・リンクの生成
入ってくるＦＳＯ生成要求が、以下の条件の１つ（または２つ以上）が真であるときに、自動的にＳＬの生成を生じさせるべきである。
・ＦＳＯがファイルであり、生成が外部のボリュームのディレクトリで生じるべきである場合。
・ローカル・ボリュームにファイルのための充分な空間が存在しない場合。
・適切な構成パラメータが、ＳＬの生成がディレクトリにも当てはまる（ファイルには常に当てはまる）ように指示しており、かつ、
ＦＳＯが、外部ボリュームのディレクトリ内に生成されるべきディレクトリである場合、または
ローカル・ボリュームにディレクトリのための充分な空間が存在しない場合。
【０２０１】
生成は、以下のとおり生じるべきである。
【０２０２】
１．クラスタ・ノードのファイル・システム・ソフトウェアが、ローカルＲＤ内にＦＳＯを生成する。すでに述べたとおり、ＦＳＯに使用された名前が選ばれるべきである。
【０２０３】
２．ＦＳＯが生成された直後に、クラスタ・ノードのファイル・システム・ソフトウェアが、外部ボリュームのオーナを通じてスクイジー・リンクを生成し、次いで新しい名前をペアレント・ディレクトリに挿入する。さらに、ローカル・ボリュームにただいま生成されたファイル／ディレクトリへの適切なシンボリック参照で、ＳＬのコンテントが更新される。
【０２０４】
続いて、ＦＳＯへのすべてのアクセスは、ローカル・ボリュームにおいてＳＬを通じて生じるべきであり、書き込みアクセスは、ボリューム・オーナを通って集中される。
【０２０５】
３．１．２．１．３．２  スクイジー・リンク参照およびアクセス
ＳＬ内に収容されたシンボリック参照が、或るペアレント・ディレクトリ内の特定の名前のためのハンドルを得るために参照される。これは、常に通常の参照であり、返されたハンドルは、ディレクトリ・エントリ指定のとおり、要求されたオブジェクトについてのオブジェクト番号およびボリューム番号を含んでいる。
【０２０６】
コールが成功し、返されたボリューム番号が、ペアレント・ディレクトリのボリューム番号と同じである場合、これは実際に「通常」の場合である（すなわち、ＳＬが関与しない）。返されたボリュームＩＤが、ペアレント・ディレクトリのボリュームＩＤと同じではない場合、これは実際にＳＬの場合である。
【０２０７】
ファイル・システム・ソフトウェアが、リロケーテッド・ディレクトリ内の「．．」エントリに関して、セクション３．１．２．１．１にて説明した挙動を実装する。
【０２０８】
さらに、ファイル・システム・システムは、解釈の実行が不可能であることを検知し、考えられる原因を区別すべきである。
・葉が見つけられない場合、ＦＳＯがもはや存在しない場合であると診断されるべきである。
・第１のパス名成分に到達できない場合、ボリュームが現時点でマウントされていないゆえ、故障（おそらくは）と診断されるべきである。
【０２０９】
上記基準にもとづき、故障の場合には、ファイル・システムは、適切な回復行為を行なうべきであり、パニック・モードに入るべきではない。
【０２１０】
論理的に含まれているボリューム内に物理的に割り当てられていない既存のＦＳＯがアクセスされたとき、アクセスは適切なＲＤを指し示すＳＬに従うべきである。これが、読み出しアクセスまたはディレクトリ・アクセスである場合、すでに述べたとおり進行すべきである。ディレクトリへの書き込みアクセス（属性の設定、エントリの除去、新規ディレクトリの生成、など）は、当該ディレクトリが物理的に存在しているボリュームのオーナを通じて実行されるべきである。それらは、いかなる深刻な性能上の問題も、ボトルネックそのものも引き起こさない、「シングル・ショット」の操作であるように思われる。
【０２１１】
３．１．２．１．３．３  スクイジー・リンクの削除
入ってくる削除要求が受信されたとき、修正すべき２つのＦＳＯが存在し、すなわちペアレント・ディレクトリおよび削除の目標である。これらＦＳＯのそれぞれは、ローカルであっても外部であってもよく、以下の４つの場合を生じさせる。
・ローカル・ペアレント・ディレクトリおよびローカル目標について、通常の削除。
・外部ペアレント・ディレクトリおよびローカル目標について、ペアレント・ディレクトリのオーナへの転送。
・ローカル・ペアレント・ディレクトリおよび外部目標について、以下に述べるとおり進行。
・外部ペアレント・ディレクトリおよび外部目標について、ペアレント・ディレクトリのオーナへの転送。
【０２１２】
したがって、「特別」な場合は、ペアレント・ディレクトリはローカルであるが目標は外部であるＦＳＯの削除である。ファイル・システム・ソフトウェアは、この場合を検知して、ローカル・ペアレント・ディレクトリからリンクを取り去り、ＳＬを破壊する。
【０２１３】
これが完了したとき、続いてファイル・システム・ソフトウェアは、目標ＦＳＯを含んでいる外部ボリュームのオーナへと「削除」コールを発行する。次いで、このオーナが目標そのものへのリンクを削除し、当該ＦＳＯへのハード・リンク・カウントが０に達した場合に、ＦＳＯ空間を回収する。
【０２１４】
３．１．２．１．４  自動ファイル・リロケーション
適切な構成パラメータによって可能にされる最適な機構は、システム動作において集めた使用統計にもとづき、ファイルの自動リロケーションを促進する。これはディレクトリにも適用可能であるが、複雑さおよび大規模なツリーのコピーを減らすため、おそらくはディレクトリではなくファイルにのみ適用される。これは、外部ディレクトリにおけるＦＳＯの生成について概括したものと類似の機構によって実行される。バックグラウンドのタスクがこれを実行し、ホット・スポットのさらなる分散およびクラスタ・ノードを横断しての負荷のバランスを可能にする。各ファイルのリロケーションに関係するステップは、以下のものである。
・各ファイルがロックされ、リロケーションが終わるまで書き込みが阻止される。
・各ファイルが、リロケーションを実行するノードによって所有されているボリュームの１つのＲＤへとコピーされる。
・ボリューム・オーナが、含んでいるディレクトリのディレクトリ参照を無効にし、リロケートされたコピーへのＳＬで置き換え、ロックを解除して元のファイルを削除するよう要求される。
【０２１５】
重要な注意は、下記のとおりである。すなわち、ＳＬの機能するやり方のため、複数のハード・リンクを有するファイルを別のボリュームを指しているＳＬに変換することができず、なぜならば、そうでない場合には、同じファイルへのＳＬへと変換するためにすべてのリンクを辿る必要があり、それは潜在的に当該ボリュームの全面的なサーチであるからである。したがって、２つ以上のハード・リンクを有するファイルは、通常はまったくリロケートされないが、このルールは、それらがすべて同じディレクトリ内にあるなど、既存のリンクを容易に検出できる場合には緩和できる。
【０２１６】
クラスタ・ノードが、すでに元の含有ディレクトリ内でリロケートされＳＬによって表わされているファイルへの書き込みアクセスを得ようと試みるとき、当該ファイルをローカル・クラスタ・ノードによって所有されているボリュームへとリロケートするためのさらなる試みは行なわれない。その理由は、連続的リロケーションを防止するためであり、最初のリロケーションが、同じボリューム内における複数の激しくアクセスされるファイルの集中の回避という目的にすでに機能したためである。さらに、負荷バランサが、すでに接続の基礎をユーザのアイデンティティに置いていると仮定すれば、ファイルはもっとも適切な目的地に到達したに相違ない。
【０２１７】
自動リロケーションの仕組みが、ユーザがクラスタへの接続のために通過するノードの知識にもとづいている点に注意すべきである。リロケーションによって、複数のボリュームを横断してのファイルの純粋な散布（それ自身価値がある）を超える値を付加するため、ファイルのリロケーションが安定であることが望まれる。これは、所与のユーザが、常に同じクラスタ・ノードを通じてクラスタに接続すべきであることを意味している。
【０２１８】
ファイル・サイズの或るしきい値を条件とするクラスタ構成のさらなる選択肢（全体が無効にされてもよく、あるいは構成設定にもとづく或るしきい値にもとづいて条件付きで許される）は、最初の書き込みアクセスにおける自動ファイル・リロケーションを可能にする。書き込みアクセスが既存のファイルのコンテントの修正を必要とする場合、２つの場合が生じうる。
・ファイルが現在開かれており、すなわちファイルが共有されている場合、そこにファイルについての争いが存在するため、すべての書き込みアクセスは、当該ファイルが物理的に割り当てられているボリュームのオーナを通って集中される。したがって、この場合は、ボリューム・オーナによって処理される。
・ファイルが使用されていない場合、操作を処理しているローカル・ノードは、
ファイルをロックして、リロケーションが終わるまで書き込みを阻止し、
ＲＤ内にコピーを生成することによって、ファイルをローカルにキャッシュし、
ボリューム・オーナに、含んでいるディレクトリのディレクトリ参照を無効にし、コピーへのＳＬで置き換え、ロックを解除して元のファイルを削除するよう要求する。
【０２１９】
・ファイルの実際のコピーを怠惰なやり方で処理でき、すなわちファイルが開かれたときにコピーを実行する必要がなく、むしろファイルを元のボリュームにおいて見えないようにでき、ファイル・セクタを必要に応じてコピーできる。ファイルが最終的に閉じられたとき、それまでにコピーされなかったブロックがコピーされ、元のバージョンが削除される。
【０２２０】
ここに概括した機構は、クラスタ内のファイルの選択的リロケーションを効果的に実行する。これは、ユーザに認知されることなく、ファイルを種々のボリュームに自動のやり方で広げるという利点を有している。
【０２２１】
３．１．３  キャッシングおよび並行性
適切な性能、ならびにクラスタ内のデータの一貫性および完全性を保証するため、各ノードにおける適切なキャッシングがサポートされなければならない。これは、読み出しのみのアクセスのノードのキャッシュ・データが、論理ボリュームのオーナによって実行される修正に関し、古くならないことを確実にしなければならない。
【０２２２】
この問題は、内部システム・ロッキングの問題と密に結び付いており、新しいデータによるボリュームの更新を要求し、クラスタ・メンバーにキャッシュされたデータおよびメタデータが古くなったとき即座に破棄されることを確実にするため、適切な通信機構を使用する能力を必要とする。これは、下記が必要であることを意味している。
・ノードが自身のキャッシュ内のページを更新したときに、他のクラスタ・ノードに保持されているあらゆるコピーが確実に無効にされること。このタイミングは、古いキャッシュ・ページのオーナが当該ページを再取得しなければならないかもしれず、得られたビューがボリューム・オーナのものとコヒーレントであるように生じるべきであるため、重要である。ページは、更新されたバージョンがディスク上で利用可能なときにのみフラッシュされるべきであり、あるいは新しいバージョンが、ボリューム・オーナから直接取得されるべきである。
・得られるビューが一貫していることを確実にするために必要なとき、複数のメタデータ・キャッシュ・ページを一緒にフラッシュすること。
【０２２３】
書き込みによる読み取りロックの破壊および関連するキャッシュ・ページのフラッシュは、実際のところ関連する事象であるため、システム−レベルのロック・マネージャを、キャッシュ管理と一体化することができる。ボリュームのための実際のロック・マネージャは、当該ボリュームのオーナであるノード内で実行される。
【０２２４】
３．１．３．１  キャッシングおよびロッキング
このアーキテクチャは、２つのキャッシュが論理的に利用可能であると期待している。１つはメタデータ・キャッシュであり、ＦＳＭ（ファイル・システム・モジュール）ボード（すなわち、ファイル・システムを実行させるシステム・ボード）上で動作する。もう１つはセクタ・キャッシュであり、ＳＩＭボード上で動作する。
【０２２５】
ローカル要求は、基本的には、メタデータおよびセクタ・キャッシュ内で取り扱われる。一方、外部要求は、別個に取り扱われなければならない。外部書き込み要求は、目標とするボリュームを所有しているノードへと送られるとき、ローカル・キャッシュ（図５参照）を完全にバイパスする。一方、外部読み出し要求（図６参照）は、ローカル・メタデータおよびローカル・セクタ・キャッシュの両方を使用している。
【０２２６】
３．１．３．１．１  セクタ・キャッシュ
セクタ・キャッシュに使用される仕組みは、読み取りロックが有効であるとき、外部ボリューム・セクタが、読み出しのみモードでキャッシュされることを許すべきである。したがって、クラスタ・ノード（「要求者」）が外部ボリュームに属するセクタへの読み出しアクセスを必要とし、かつそれがまだキャッシュにないとき、読み出しのみロックを有する１つの読み出し要求をボリューム・オーナへと発行し、同じセクタについての他の読み出し要求をＳＡＮバックエンドへと発行すべきである（図５参照）。要求者は、セクタおよびそれのための読み出しのみロックの両者を受信するまで、ブロックすべきである。２つの場合が存在する。
【０２２７】
１．ボリューム・オーナがキャッシュ内に当該セクタを有していない場合、ロックを与え、それを要求したクラスタ・ノードおよびセクタ番号を記録し、ＳＡＮバックエンドが要求を満足させるようにすべきである。この時点で、要求者はロックを得、セクタがＳＡＮから利用可能になるまで待つべきである。次いで、それがクライアントの読み出し要求を満足させる。
【０２２８】
２．ボリューム・オーナがキャッシュ内に当該セクタを有しているばあい、２つのさらなる場面が存在する。
【０２２９】
ａ．セクタが書き込みロックされていない場合、ボリューム・オーナは、読み出しのみロックを与え、それとともにセクタのコンテントを送ることによって応答すべきである。次いで、要求者は、クライアントの要求を満足させ、ＳＡＮバックエンドによって戻されると直ぐに、セクタを落とす（あるいは、ＳＡＮコマンドを中止すべきである）。
【０２３０】
ｂ．セクタが書き込みロックされている場合、要求者は、ロックが与えられて場合ａに戻るまで停止すべきである。
【０２３１】
ボリューム・オーナがセクタを書き込みロックする必要があるとき、まず他のノードに流通している読み取りロックを破壊すべきである。これは、当該セクタについて他のノードのキャッシュ・エントリを無効にする効果も有している。この時点で、当該特定のセクタを必要としているあらゆるノードが、上記アルゴリズムの実行に戻るべきである。
【０２３２】
３．１．２．１．１．１  セクタ・キャッシュの一貫性
すべての論理ボリューム（実際には、いくつかの物理的なディスクによって構成されているであろう）は、特定のクラスタ・ノードによって「所有」され、そのノードのみが当該ボリュームに書き込みできる。一方で、クラスタ内の他のすべてのノードは、潜在的に、自身の所有ではないボリュームから読み出しデータをキャッシュすることができ、したがって、ボリュームがオーナによって書き込まれたときに、データの一貫性を保つために他のノードのキャッシュ・データをすべて確実に無効にする仕組みを有する必要がある。
【０２３３】
本発明の典型的な実施の形態においては、クラスタ内のすべてのノードが、セクタ・キャッシュ・ロック・マネージャを含んでいる。これが、当該ノードに所有されているボリュームからのクラスタ内のすべてのセクタ・キャッシュのデータのキャッシュを管理する。セクタ・キャッシュは、キャッシュ・ページ（典型的な実施の形態においては、サイズが３２キロバイト）で作られており、これらのページがロック・マネージャによって管理される。
【０２３４】
ロック・マネージャによって管理される各キャッシュ・ページは、２つの状態のうちの１つであることができる。
【０２３５】
読み取りロックこのページは、オーナでない少なくとも１つのノードのセクタ・キャッシュにキャッシュされている。
【０２３６】
書き込みロック−このページは、オーナ・ノードのセクタ・キャッシュにキャッシュされており、ダーティなデータを含むことができる（セクタ・キャッシュのデータが、ディスク上のデータよりも新しい可能性がある）。
【０２３７】
個々のロック・マネージャが何枚のキャッシュ・ページを管理できるべきかについて、問題がある。最悪の場合においては、クラスタ内のすべてのノードが、それらのセクタ・キャッシュをただ１つのボリュームからの読み出しデータの異なるブロックで一杯にすることは明らかである。これに対する１つの解決策は、この最悪の場合に対処したいロック・マネージャ上のメモリを指定することである。
【０２３８】
生じうる３つの異なるセクタ・キャッシュ操作が存在する。それらのそれぞれについてのロック・マネージャ上の実装を、以下に説明する。
【０２３９】
３．１．３．１．１．１．１  オーナの読み出し
ボリューム・オーナは、自身の所有するボリューム上のデータについて読み出しの要求を受信したとき、いかなるロックも取得することなく、あるいはロックの状態をチェックすることなく、ボリュームからオーナ・セクタ・キャッシュへとデータを読み出すことは自由である。ページがすでに書き込みロックされている場合、それは書き込みロックされたままである。
【０２４０】
３．１．３．１．１．１．２  オーナでない読み出し
非オーナが読み出し要求を受け取った場合、最初に、当該ページの読み取りロックをすでに有しているか否かを確かめるべくチェックが行なわれる。有している場合、要求されたデータを読み出すだけである。有していない場合、読み取りロックを求めてロック・マネージャに照会を行なわなければならない。この要求について、考えられる結果が２つ存在する。
【０２４１】
１．現時点でページがクラスタ内のどこにもキャッシュされていない場合、または他の１つ以上のノードによって読み取りロックされている場合、ロック・マネージャが、当該ページがこのノードによって読み取りロックされているとマークして、当該ノードに読み取りロックを付与し、この結果、ボリュームから自身のセクタ・キャッシュにデータを読み込むことができる。ノードがキャッシュ・ページをセクタ・キャッシュから取り除いたとき、誰が何をキャッシュしているかを適切に追跡できるよう、ロック・マネージャに知らせることが重要であることに注意すべきである。
【０２４２】
２．現時点でページが書き込みロックされているとき、ロック・マネージャは、読み取りロックの要求が失敗に終わったことをノードに伝える。この場合、ノードは読み出し要求をクラスタ・ポートを横切ってオーナ・ノードへと提出しなければならず、オーナ・ノードが、読み出したデータをオーナ・ノードを横切って返す。次いで、要求を行なっているノードは、読み取りロックを得ることができなかった旨をキャッシュしても、キャッシュしなくてもよく、次のチェックポイントが行なわれるまですべての読み出し要求をオーナ・ノードに提出する（読み出し要求は放棄してもよい）。
【０２４３】
３．１．３．１．１．１．３  オーナの書き込み
オーナ・ノードが書き込み要求を得たとき、生じうる３つの事象が存在する。
【０２４４】
１．ページが現時点でキャッシュされていない場合、ロック・マネージャが当該ページを書き込みロックされたとしてマークする。
【０２４５】
２．ページが現時点で読み取りロックされている場合、ロック・マネージャが、読み取りロックを保持しているノードのそれぞれに、それらの読み取りロックを破壊するよう要求を送信する。次いで、これらのノードのそれぞれは、あらゆる未完の読み出しが完了するのを待ち、今や読み取りロックが破壊されたことをロック・マネージャに伝える。これらロック破壊の要求がすべて完了したとき、キャッシュ・マネージャが当該ページを書き込みロックされたとしてマークする。
【０２４６】
３．ページがすでに書き込みロックされている場合、何も行なわない。
【０２４７】
ひとたび書き込みロックが取得されると、当該データをセクタ・キャッシュに書き込むことができる。
【０２４８】
ページについて書き込みロックが取得されるたびに、ロック・マネージャは、書き込みを行なうために使用されたチェックポイント番号を記録する。このチェックポイントが成功裏にディスクに書き込まれたときに、ページがのちのチェックポイント番号とともに書き込まれなかった場合、書き込みロックは放棄され、ページがロック・マネージャの表から取り除かれる。
【０２４９】
３．１．３．１．２  メタデータ・キャッシュ
メタデータ・キャッシュについて考えられる実装の仕組みは、メタデータ・キャッシュが、セクタ・キャッシュによってもたらされるものときわめて似ているが実際には独立である機構を実装しているものか、あるいはメタデータ・キャッシュがセクタ・キャッシュの従属であって特別な設備装置を必要としないものか、のいずれかである。
【０２５０】
従属メタデータ・キャッシュを実装するため、基本的な仮定は、セクタ・キャッシュが、セクタ番号からそれらが実装するメタデータ・オブジェクトへと逆マッピングを行なうための機構を有しているというものである。
【０２５１】
メタデータ・オブジェクトは、セクタに対するより高レベルの抽象である。しかしながら、それらは、より高いレベルのセマンティクスが組み合わされているが、最終的にはセクタ・データを含んでいる。従属の仕組みは、以下の考え方にもとづくことができる。
・外部クラスタ・ノードは、ボリューム全体を読み取りロックする必要を決して有さない。したがって、ボリューム・ロックは、完全にボリューム・オーナへとローカルである。・ボリューム・オーナがＦＳＯの更新を必要とするとき、ＦＳＯへの書き込みロックを得なければならない。外部ノードは、ＦＳＯを直接更新することが決してできず、ｉ−ｎｏｄｅロックの必要を有さない。しかしながら、ディレクトリのコンテントまたはファイルのコンテントあるいはマッピングが、外部ノードがそれを読み出している間に変化しうるリスクが存在する。よりトリッキーなのは、外部ノードが、読み出しアクセスを実行するときに複数の項目を考慮に入れる必要がある場合である。そのような場合に対処するため、ボリューム・オーナがＦＳＯへの書き込みロックを得る必要がある場合に、それがまず、ＦＳＯのｉ−ｎｏｄｅを表わしている最初のセクタ（このセクタそのものが修正されようとしているのではなくても）についてのあらゆる未決の読み取りロックを破壊すべきであり、さらに、修正すべきあらゆるセクタが読み取りロックされなければならないというルールを設定できる。読み取りロックの破壊が、外部ノードのセクタ・キャッシュが知らされることを含んでいる点に注意すべきである。次いで、それらが、それらのＦＳＭ複製をメタデータ・キャッシュにキャッシュされるセクタのために知らせることができる。
・このように、クラスタ内のＦＳＭコードが、所与の操作を実行するためにメタデータへのアクセスを必要とする場合、それはＦＳＯのｉ−ｎｏｄｅを得、ついで適切なデータを得なければならない。それがこれを実行したとき、要求された読み出し操作を実行する直前に、それが取り扱っているオブジェクトのｉ−ｎｏｄｅの最初のセクタが依然読み取りロックされているか確認される。より一般的には、いくつかの項目が一貫していなければならない場合、それらの有効性が、それらが取得された順序に対して逆の順序で確認されなければならない。そうである場合、操作を続けることができる。そうでない場合、それは放棄され、スクラッチから再開されなければならない。そのような場合（実際は、競合ゆえの例外であると考えられる）において考えられる代案は、書込み操作の場合と同様、要求をボリューム・オーナに送るというものである。ここで、以下に留意すべきである。
【０２５２】
セクタ・キャッシュへの照会は、読み取りロックの確認のために使用できる。考えられる代案は、セクタが無効である場合に、ＳＩＭセクタ・キャッシュが、適切なフラグをＦＳＭキャッシュ・バッファへと伝播させることができるようにするというものである。
【０２５３】
操作を再開させなければならない場合、関連するセクタの取得は、ボリューム・オーナ・ノードの書き込みロックが解除されるまで要求スレッドを阻止することを含んでいる。・ＳＩＭが他のデータのための空間を作るべくそのようにするとき、ＦＳＭボードのメタデータ・キャッシュが、外部メタデータを放棄しなければならない状態にならないようにすることが望ましい。これを得るため、外部メタデータが、それがもはや必要とされなくなる（または、他のメタデータのための余地を作るためフラッシュが必要になる）まで、あるいは無効になるまで、ＦＳＭキャッシュに保たれることが期待される。したがって、外部メタデータを含んでいるＳＩＭキャッシュ・エントリが、他のデータのための余地を作るためにフラッシュされるとき、ＳＩＭボードは、フラッシュされたメタデータを有する旨をオーナに知らせることを回避する。したがって、無効化要求がオーナから入ってきたとき、ＳＩＭボードは、その要求を直接処理する代わりに、それをＦＳＭメタデータ・キャッシュにリレーし、ＦＳＭメタデータ・キャッシュが適切に対処する。
・このように、メタデータ・ロックを別個の機構として実装する必要はない。また、これにより、ボリューム・オーナが所与のセクタについてのすべての読み取りロックの無効化を要求し、コピーを有していたすべてのノードがこれを確実にするまでブロックするという煩わしい同期プロトコルの必要性も避けられる。
・ボリューム・オーナは、ボリュームへの書き込みを扱う唯一の存在（他のノードの代理としてでさえも）であり、常に一貫したビューを有している。したがって、一貫したビューを保証するという問題は、外部読み出しにのみ当てはまる。
【０２５４】
３．１．３．２  このアプローチの属性
使用される仕組みゆえ、以下に留意すべきである。
・古くなったセクタ・キャッシュ・エントリのコピーは、決して使用されない。
・ボリューム・オーナによってキャッシュされたセクタが、常に好ましい。
・ＳＡＮバックエンドからのいくらかの追加の読み出しを要求でき、次いで単純に落とされる。実際、係属中の要求を放棄することによって、より盲目でない挙動が達成できる。さもなくば、読み出しを前もって発行するか否かについての判断を、ボリューム・オーナによる応答に関し、ＳＡＮバックエンドが当該ボリュームについて扱っているトラフィックの量によって、調節できる。
・ボリューム・オーナのみがロックを管理する。これにより、設計が簡略化される（さらに、拡張性が減らされる）。
・書き込みロックが、常に外部読み取りロックよりも高い優先順位を享受する。
・別個のノードに接続されたクライアントが同じファイルにアクセスしている場合、複数のノード・キャッシュ内でボリューム・セクタの潜在的複製が存在する。
・デッドロック管理の複雑な部分が、書き込みロックの使用に関係する。これは、ボリューム・オーナの側では変化しない。したがって、分散化設計が必要とされない。外部ノードにおいて、読み取りロックを常に破壊／解放および再取得できる。これにより、デッドロックの必要条件の１つが取り除かれる。したがって、デッドロックが存在し得ない。
・この仕組みそのものは、拘束のない拡張性を保証しない。実際、それは以下の場合に最もよく機能するであろう。
−クラスタ・オーナにおける読み取りロック／データ要求の管理のオーバヘッドが、限定されている。他の何よりも、このプロトコルは、きわめて簡潔であることが期待されており、読み取りロック要求（ボリューム・オーナへの）、データが添付されておりあるいは添付されていない読み取りロック応答（ボリューム・オーナから）およびフラッシュ／読み出しのみロックの破壊（ボリューム・オーナから）に限定されている。
【０２５５】
ボリューム・オーナとやり取りをするクラスタ・ノード数に限界がある。
【０２５６】
外部アクセスの多くが、読み出し型である。
【０２５７】
しかしながら、パス名をＦＳＯが割り当てられているボリュームから切り離すことは、実際、全ボリュームにわたるホット・スポットの顕著な分散をもたらすことができ、ボトルネックを減らす傾向にある。
・ここに記載のクラスタ間のセクタ・キャッシュのやりとりが、ＶＬＳＩにて取り扱われる場合、この仕組みがクラス他の拡張性を小数のノードに限定しないと期待することが妥当である。
・キャッシュに実装された共有のセマンティクスが、システムがクライアントに対し一貫したビューを常に保証できるようなものである。メタデータおよびセクタが、それらが一貫したやり方でキャッシュされたのち（キャッシュ・エントリの有効性をチェックすることによって確認される）、そのコンテントが直後に変化するかもしれないが、クライアントへと提供される情報は常に一貫している。これは、実際、データの同期が共通のアプリケーションまたは環境内で協働しているクライアント間の共通のロッキング・プロトコルの使用にのみもとづいている限りにおいて、充分である。しかしながら、ＮＡＳの確認を使用する分散アプリケーションが、別のチャネル（例えば、ソケット通信）を通じて他のクライアントとの同期を引き起こすために書き込む場合、この仮定は当てはまらないかもしれない。したがって、初期設定のルールとして、データがキャッシュされるべきであるとの非同期の告知をサポートし、特定のアプリケーションがこの挙動に依存する場合に、構成スイッチを通じて動機モードを可能にできるようにすることが適切かもしれない。
・メタデータ・キャッシュのサイズおよび効果が、決してセクタ・キャッシュのサイズによって制限されない。
・キャッシュ・マネージャが、新規クラスタ・ノードが動的にクラスタに合流／離脱したとき、それらを登録／未登録できなければならない。ハードウェア状態モニタ（高可用性ソフトウェアの一部）が、関連の事象を告知する。
【０２５８】
ここで述べたメタデータ・キャッシュの一貫性の仕組みは、セクタ・キャッシュの一貫性の仕組みの上に構築でき、セクタ・キャッシュ・ページを当該キャッシュ・ページに含まれたすべてのメタデータデータ・オブジェクトに関係付ける「逆マッピング」に依存している。
【０２５９】
３．１．４  多ボリューム操作
これまでに、メタデータ・キャッシュおよびセクタ・キャッシュの管理に関して、内部ロッキングを考察した。これは、完全にボリューム内の操作にとって正に必要とされているものであり、ロッキングが完全にボリューム・オーナの担当範囲内であり、実際に、スタンドアロンのノードで使用されるそれらと一致するやり方で扱われるべきである。
【０２６０】
より複雑な多ボリュームの操作は、すべてグローバル・ファイル・システム名前空間の管理を取り扱う。当然ながら、個々のボリュームにローカルである名前空間の操作は、ボリュームの文脈において取り扱われ、追加の複雑性はない。
【０２６１】
いくつかの多ボリューム操作の複雑性を、ＳＬの使用によって大きく軽減できることに注意すべきである。一例は、ボリュームから他のボリュームへのディレクトリのリネームである。ディレクトリ「Ｘ」（真のディレクトリであって、ＳＬではない）をボリューム「Ａ」からボリューム「Ｂ」の「Ｙ」へとリネームしたい場合、これは以下のとおり実現できる。
・ボリューム「Ａ」のＲＤへと「Ｘ」のローカル・リネームを、数値名を割り当てｉ−ｎｏｄｅ内のＶＰＤバックリンクを更新しつつ実行する。
・ボリューム「Ｂ」の適切なディレクトリに、前記リロケーテッド・ディレクトリを指す「Ｙ」と命名されたＳＬを生成する。
【０２６２】
「Ｘ」がすでにＳＬである場合には、以下を行なう必要がある。
・「Ｘ」についてのディレクトリ・エントリを、参照されたディレクトリを取り除くことなくボリューム「Ａ」から取り除かなければならない（これは、目標ディレクトリの更新を含む）。
・参照されたディレクトリのｉ−ｎｏｄｅを、新しいＶＰＤを指すＶＰＤバックラインを有するように更新しなければならない。
・参照されたディレクトリのための新しいＳＬを、ボリューム「Ｂ」の適切なディレクトリに生成しなければならない。
【０２６３】
この後者の操作には、最大３つのノードが関与しうる。
【０２６４】
この仕組みがファイル、ディレクトリおよびＳＬに当てはまり、実データのコピーを実行する必要はない。ＦＳＯがクラスタのどこに物理的に保存されているかに関する態様は、クライアントから隠されているため、あらゆるリネームまたは移動の操作は、このようにして取り扱うことができる。
【０２６５】
すべての場合において、操作は自己完結であるステップで取り扱うことができ（すなわち、ボリューム内の各名前空間の操作が原子的である）、複数ボリュームのロックの必要はない。中間ステップにおける故障の場合の回復は、親のないＦＳＯを収集する清掃によって自動的に取り扱われ、あるいは操作を実行しているエンティティによって調整される。
【０２６６】
清掃プロセスは、ノード故障のために完了しなかった操作から生じる親なしのＳＬおよびＦＳＯの除去を処理するために必要とされる。いずれの場合においても、多ボリューム操作に関係するオブジェクトのアイデンティティのログを記録することによって、清掃機による操作を、それらのオブジェクトにまで減らして最小化することができる。これについてのさらなる詳細は、セクション３．１．７にある。
【０２６７】
以下の多ボリューム操作が、クラスタ・ファブリック内で実行される。これは、それらがＮＡＳクライアントにとってまったくアクセスできないプリミティブという形で実装され、外界から保護されていることを意味している。したがって、実行すべき操作を生じさせるクライアントが関係するファイル・システム・オブジェクトを修正するための充分な特権を有していることを確認する標準的なファイル・システム保護のチェック以外に、特権についての特別なチェックは不要である。
【０２６８】
このセクションにおいて検討する多ボリューム操作が、通常は全体がサーバ・コードによってただ１つのボリューム内で取り扱われるより一般的な操作の特別な多ボリュームの場合を実装している点に注意すべきである。このように、外部ディレクトリ内のＦＳＯの生成は、ちょうど新しいＦＳＯを生成するコードによって扱われる多ボリュームの場合である。その意味では、これら多ボリューム操作は、ボリュームがすでにサポートしている基本的なローカル操作を単純に拡大している。
【０２６９】
興味を引く多ボリューム名前空間操作は、以下のものである。
・外部ディレクトリ内のＦＳＯ生成：ファイルまたはディレクトリの生成の特別な場合である。
・既存のファイルへのＳＬの作成：リンク・プリミティブの特別な場合である。
・非共居住ディレクトリへのファイルまたはディレクトリのリネーム／移動：一般的なリネーム／移動操作の特別な場合である。
・既存のファイルまたはディレクトリを指すＳＬのリネーム／移動：一般的なリネーム／移動操作のさらに特別な場合である。
・ファイルまたはディレクトリへのＳＬの除去：一般的な除去の特別な場合である。
【０２７０】
そのような操作を、全面的に１つのボリューム内で取り扱うことができるとき、それらは、単一ノードのファイル・システム実装例が実行すべき操作と相違しないため、この文脈においてさらなる検討を必要としない。
【０２７１】
以下のサブセクションは、多ボリューム操作のそれぞれが達成するもの、およびグローバル・ファイル・システムのための完全性および回復に関する影響について説明する。
【０２７２】
これを実装するために、２つの設備が必要である。以下で説明するプリミティブの組、およびスラッシュが関与する参加者に影響する場合に多ボリューム・トランザクションの前の状態への復帰を可能にする機構である。後者は、リモート側の自動アンドゥ設備およびＮＡＳクライアントには見えない「ローカル・アンドゥ・ディレクトリ」（以下では、ＬＵＤ）にもとづいている。これは、セクション３．１．４．６で検討される。
【０２７３】
多ボリューム操作のための擬似コードは、リモートにて呼び出すことができ、さらに１つのボリューム内で全体が原子的に実行される以下の８つのプリミティブによって構成される。
【０２７４】
【数４】
2010108520.tif 000005
このプリミティブは、「ｖｏｌＩＤ」によって特定されるボリュームのＲＤ内に新しいファイルまたはディレクトリ（「ｔｙｐｅ」項の値に応じて）を生成する。ＦＳＯの名前は、それまでに生成された最後の数値名を１つ増やすことによって得た数値列である。新しい名前へのポインタが関数値として返される。「ｖｐｄＢａｃｋｌｉｎｋ」項は、ディレクトリのためのＶＰＤバックリンクの生成のためにのみ使用される。ファイルの場合には、それは無視され、あるいはおそらくはデバッグのために保存される。
【０２７５】
【数５】
2010108520.tif 000006
このプリミティブは、「ｆＶｏｌ」によって特定されるボリューム内にパス名「ｆＮａｍｅ」を有する種類「ｔｙｐｅ」の新しいＳＬを生成する。参照されたＦＳＯは、ボリューム「ｔＶｏｌ」内のパス名「ｔＮａｍｅ」によって特定される。目標とする名前が未だ存在しない場合、コールは続けられる。目標名が存在して、ＳＬであり、かつダングリングである場合、ダングリングな参照が新しいもので置き換えられ、コールが続けられる。そうでない場合、名前がすでに存在し、ダングリングなＳＬのものではない場合、次に続くためには、「ｔｙｐｅ」が既存のオブジェクトの種類と一致しなければならない。既存のオブジェクトがＳＬである場合、次に続くためには、「ｔｙｐｅ」がＳＬの指すオブジェクトの種類と一致しなければならない。既存のオブジェクトの種類または既存のＳＬによって指し示されるオブジェクトの種類がディレクトリである場合、既存の目標ディレクトリは空でなければならない。上記の条件が満足され、かつ既存の目標がＳＬである場合、ＳＬの参照が、新しいもので置き換えられる。次いで、既存の目標名が、ボリューム「ｔＶｏｌ」に関連付けられたＬＵＤのサブディレクトリへと動かされ（これは、既存のダングリングでないＳＬにも当てはまる）、操作が続けられる（さらなる詳細については、セクション３．１．４．６を参照のこと）。
【０２７６】
【数６】
2010108520.tif 000007
このプリミティブは、ＳＬの生成を含む操作が続けられるとき、あるいはＬＵＤの清浄化を実行するために呼び出される。それは、（ｖｏｌ，ｎａｍｅ）の組によって特定されるＳＬが、既存のオブジェクトへの信頼できる参照を含んでいることをチェックする。そのようである場合、それは、ボリューム「ｔＶｏｌ」に関連付けられたＬＵＤサブディレクトリ内に生成されたエントリを、（ｖｏｌ，ｎａｍｅ）の組によって特定されるディレクトリ・エントリの上書きによって取り除く。「復旧」フラグが設定（これは、クラッシュ後に完全なＬＵＤ清浄化が行なわれる場合であろう）され、（ｖｏｌ，ｎａｍｅ）の組によって特定されるＳＬがダングリングである場合、ＬＵＤエントリはダングリングなＳＬを置き換えて復旧される。
【０２７７】
【数７】
2010108520.tif 000008
このプリミティブは、「ｖｏｌＩＤ」によって特定されるボリュームのＲＤ内の新しいリンクを生成する。この新しいリンクは、同じボリューム内のパス名「ｎａｍｅ」によって特定されるファイルを参照する（これは、前もってＲＤにある必要はない）。この新しいリンクは、新しい数値名が自動的に割り当てられる。新しい名前へのポインタが、関数値として返される。
【０２７８】
【数８】
2010108520.tif 000009
このプリミティブは、「ｖｏｌＩＤ」および「ｎａｍｅ」によって特定されたボリュームのＩＤおよびＦＳＯのパス名を返す。返された情報は、「ｐＶｏｌ」および「ｐＮａｍｅ」が指す変数内にある。「ｖｏｌＩＤ」および「ｎａｍｅ」がＳＬを参照している場合のみ、返された値が入力パラメータと相違する点に注目すべきである。
【０２７９】
【数９】
2010108520.tif 000010
このプリミティブは、「ｖｏｌＩＤ」および「ｎａｍｅ」によって特定されたリンクを、「ｖｏｌＩＤ」が指すボリュームのＲＤ内の数値名へとリネームする。参照されたＦＳＯは、同じボリュームにとどまり、リンクのみが元のディレクトリからＲＤへと移動する。新しい数値名へのポインタが、関数値として返される。これが、元の（ｖｏｌＩＤ，ｎａｍｅ）の組が、当該ボリュームのＲＤにすでに存在するＦＳＯを参照している場合にも当てはまることに注意すべきである。「ｏｐＩＤ」項は、当該操作に割り当てられた固有のＩＤが返されるべき場所を指している。「ｖＢｌ」項は、ディレクトリのためのＶＰＤバックリンクの生成のためにのみ使用される。ファイルの場合には、それは無視される。この操作は、「ｔｍｏ」として指定されたタイムアウトを有し、ＦＳＯの元のアイデンティティを、操作は行なわれたボリュームへとローカルにログとして記録する。タイムアウトが経過する前に「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」プリミティブ（下記参照）が呼び出されるまで、リロケーションは自動的にアンドゥされる。タイムアウトが過ぎた場合にリロケーションが自動的にアンドゥされるよう、アンドゥ・エントリがすみやかに生成されることに注意すべきである。これは、元のディレクトリ・エントリがもはやアクセスできないことを保証する。このアンドゥ・エントリもボリューム内にログとして記録され、ボリューム・オーナのクラッシュの場合、ボリュームがオンラインに復帰したときにそれが実行される。
【０２８０】
【数１０】
2010108520.tif 000011
このプリミティブは、２つのパラメータを取る。先の「Ｒｅｌｏｃａｔｅ（）」プリミティブの呼び出しによって返された「ｏｐＩＤ」および「ａｂｏｒｔ」トークンである。「ａｂｏｒｔ」がヌルでない場合、「ｏｐＩＤ」が参照する「Ｒｅｌｏｃａｔｅ（）」の呼び出しによって実行された操作が、アンドゥされる。そうでない場合、それが実行され、保留中のアンドゥ操作が削除される。このプリミティブは、「ｏｐＩＤ」が参照する「Ｒｅｌｏｃａｔｅ（）」の先の呼び出しが未知である場合（これは、タイムアウトが経過してリロケーションがアンドゥされたことを意味するかもしれない）、エラーを返す。
【０２８１】
【数１１】
2010108520.tif 000012
このプリミティブは、３つのパラメータを取る。（ｖｏｌＩＤ，ｎａｍｅ）の組が、削除すべきオブジェクトを特定する。「ｆｏｒｃｅ」フラグは、削除が必須であることを指定するために設定される。このプリミティブは、ＦＳＯへのリンクまたはＳＬに作用する。「ｆｏｒｃｅ」フラグが設定された場合、参照されたリンクは常に削除される。それがハード・リンクであり、それが指すオブジェクトについての参照カウントが０に達した場合、オブジェクトそのものが削除される。それがＳＬである場合、ＳＬだけが削除される。「ｆｏｒｃｅ」フラグが設定されていない場合、このプリミティブは、それが指すＦＳＯがダングリングなＳＬでない限り削除を実行しない。
【０２８２】
上記プリミティブはすべて同期的であり、すなわち要求された操作が完了したときにのみ応答が返されることを意味する。
【０２８３】
これは、考えられる仕組みのただ１つに過ぎず、以下のサブセクションの擬似コードを示すためだけに使用されている。
【０２８４】
多ボリューム操作がノードの故障によって潜在的に引き起こしうる考えられるエラーは、下記の分類に属する。
・ダングリングなＳＬ：これが生じたとき、ダングリングなＳＬは、名前が参照されたとき、または清掃機プロセスが不整合を検知したときに、ゴミとして収集されるべきである。
・ＲＤ内の参照されていないリンク名：先の場合と同様、ＲＤ内の参照されていないリンク名も、ゴミとして収集されるべきである。これが、当該リンクの指すオブジェクトが、それが当該オブジェクトへの最後のリンクであるときにのみ取り除かれなければならないことを意味していることに注意すべきである。
・ＲＤ内のリンク名が複数のＳＬによって参照されている場合：ＲＤ内の名前が数値であって単調に増加しているため、この場合は生じないであろう。新しいＳＬのそれぞれについて、リンクが新しい数値名で再生成される。
・ＦＳＯの元のＳＬが取り除かれたが、新しいものが生成できなかった場合：この場合には、部分的に成功した操作をアンドゥする能力が必要とされる。
【０２８５】
これらは、以下に説明する操作において評価される。生じうる故障は、クラスタ・ノードのハードウェアまたはソフトウェアの不具合によるものと仮定する。内部クラスタ操作が実行されるやり方のため、またクラスタ相互接続が構成されるやり方のため、クライアントがＮＡＳレベルの下のクラスタ・ノードと直接干渉することは不可能である。したがって、不整合を注入しようとする企ては、保護されているＮＡＳネットワーク・インターフェイスを使用することによってのみ生じうる。
【０２８６】
多ボリュームの操作は、コーディネータ（全体の操作を調整するノード）および操作によって影響される他のボリュームを所有する１つ以上のリモート・ノードを関与させる。コーディネータは、操作によって影響されるボリュームの１つのオーナである。これは、通常は、操作そのものを開始させるノードである。操作が、直接関与しない（すなわち、影響を受けるボリュームのいずれも所有していない）ノードへと要求された場合、当該要求は、リモート同期コールによって適切なコーディネータへと送られる。以下に述べる場合のそれぞれは、操作に関与する参加者のどれがコーディネータとして機能するかを指定している。以下に述べる仕組みが、考えられる仕組みの１つに過ぎないことに注意すべきである。基本的に、コーディネータの役割は、操作に直接関与する他の任意のノードに割り当てることができる。
【０２８７】
３．１．４．１  外部ディレクトリ内のＦＳＯ生成
この操作のためのコーディネータは、新しいＦＳＯが生成されるべきボリュームを所有するノードである。これが、ＦＳＯが実行中のノードのボリューム内に生成されることを確実にし、ローカル・アクセスに関して新しいＦＳＯの割り当てを最適化することに注意すべきである。
【０２８８】
この操作は、典型的には、当該ＦＳＯについてのペアレント・ディレクトリを収容したボリュームを所有していないノードを通じて新しいファイルまたはディレクトリが生成されるときに行なわれる。
【０２８９】
この操作には、コーディネータが所有するボリューム、およびＦＳＯのためのペアレント・ディレクトリが位置するボリュームを所有するリモート・ノードが関与する。コーディネータは、自身が所有するボリューム内にファイルまたはディレクトリを生成する。次いで、含んでいるディレクトリが存在するリモート・ノードが、新しいＦＳＯを指し示すＳＬを生成するよう要求される。
【０２９０】
新しい目標名がすでに存在しうる点に注意すべきである。この場合、生成されるオブジェクトが既存の目標のそれと互換でない（一方がファイルであり、他方がディレクトリである）場合、操作は失敗する。同じことが、オブジェクトが両方ともディレクトリであって、目標が空でない場合に生じる。そうでない場合、元の目標ＦＳＯがＬＵＤへと動かされ、ＳＬが新たに生成されたＦＳＯを指す。
【０２９１】
これについて、実行中のノード上の擬似コードは、以下のようである。
【０２９２】
【数１２】
2010108520.tif 000013
コーディネータが、ローカルＦＳＯを生成する（命令文１）。これを行なうためには、ローカル・ボリュームのみが関与すればよい。コールが失敗である場合（命令文２）、実行が中止される。成功である場合、リモート・ボリューム上にＳＬが生成されなければならない（命令文５）。コーディネータが命令文１と５の間で機能しなくなった場合、新たに生成されたＦＳＯ（存在するならば）は、当該ボリュームが復帰したときに親なしになり、したがって時期が来たときにゴミとして収集されるであろう。
【０２９３】
行５の操作が、ＳＬを生成しなければならないボリュームを所有しているリモート・ノードによって実行される。コーディネータが成功の応答を受信しない場合、ＳＬの生成がいくつかの理由で失敗したか、あるいはリモート・ノードがクラッシュしたため、そのようになったのであろう。ＨＡサブシステムが、そのようなクラッシュを検出するであろう。いずれにせよ、コーディネータが新しいＦＳＯを削除する。最悪な場合の状況は、ＳＬの生成後かつコーディネータへの応答前に、リモート・ノードがクラッシュする状況である。この場合、コーディネータがＦＳＯを削除し、リモートのＳＬがダングリングな状態で残され、ゴミとして収集される。いずれにせよ、行５において戻される関数値は、生成の成功と、当該名前のＳＬがすでに存在するためＳＬを生成できなかった場合と、他の理由で生成が失敗した場合との間の区別が可能でなければならない。戻されたコードは、しかるべく処理される。
【０２９４】
行８の操作は、リモートの操作である。行８における操作は、厳密に必要ではないことに注意すべきである。それは、単なる最適化である。
【０２９５】
行６の操作は、ゴミの収集が参照されなかったＦＳＯの除去を担当するため、単なる最適化である。
【０２９６】
この操作のセマンティクスは、同じ名前を有する既存のＦＳＯをゼロ長さに切り取ることを必要としてもよい。
【０２９７】
この操作によって生成されたＦＳＯが、その引き続く使用に結び付けられている点に注目すべきである。ノードがクラッシュした場合、アプリケーションの状態が失われ、アプリケーションは、全体の操作を再度実行しなければならない。アプリケーションが再度開始するとき、要求されたＦＳＯが存在しても、存在しなくてもよい。
【０２９８】
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・ローカル・ボリュームのＲＤ内に新しいＦＳＯが生成される。このＦＳＯの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。このオブジェクトは、ＳＬにリンクされるまでは、ＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがこのオブジェクトに干渉することはできない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。ＦＳＯの生成後に、名前が使用中のためＳＬを生成できない場合、新しいＦＳＯを削除しなければならない。
【０２９９】
生じうる結果（ＦＳＯは有用なデータを含んでいない）：
・成功。
・成功したが、クライアントが成功の通知を受信する前にノードがクラッシュした。アプリケーションの状態が失われ、ＦＳＯがすでに存在するが、操作を再度実行しなければならない。
・ＦＳＯが存在するが、ＳＬが生成されなかった：参照されないＦＳＯはゴミとして収集されることになる。
・リモート・ノードがＳＬを生成することなくクラッシュした。コーディネータがこれを検知し、ＦＳＯを取り除く。
・リモート・ノードが、ＳＬ生成後かつコーディネータへの通知前にクラッシュした。コーディネータがＦＳＯを取り除き、ＳＬがダングリングなまま残される。クライアントが操作の繰り返しを試みた場合、ダングリングなＳＬが正しいものと置き換えられる。そうでない場合、ＳＬはゴミとして収集される。
・ＦＳＯが生成されなかった。
【０３００】
３．１．４．２  既存のファイルへのＳＬの生成
コーディネータは、新しいＳＬが配置されなければならないディレクトリを所有するノードである。この操作には、このノードおよびファイルを収容しているボリュームのオーナが関与する。ディレクトリに適用できるものと同様のコールは、あらゆるディレクトリは自身を指すＳＬをただ１つだけ有することができるため、利用できないことに注意すべきである。
【０３０１】
手順は次のとおりである。コーディネータが、リモート・オーナに、ＲＤ内の目標ファイルへと新しいリンクを生成するように要求する。次いで、それを指すローカルＳＬが生成される。
【０３０２】
このための擬似コードは次のとおりである。
【０３０３】
【数１３】
2010108520.tif 000014
第１の動作（命令文１）は、参照されるべきファイルのためのボリュームおよびパス名の取り出し動作である。取り出した情報（ｆＶｏｌ，ｆＲｅｆ）が入力データ（ｓｒｃＶｏｌ，ｓｒｃＮａｍｅ）と一致する場合、使用されているパス名が実際のファイルのものであり、そうでない場合、ＳＬである。いずれにせよ、使用しなければならない実際のファイルを指しているものは、（ｆＶｏｌ，ｆＲｅｆ）の組である。
【０３０４】
行２の操作は、既存のファイルへのリンクが、ファイルが位置しているボリュームを所有するノードによってリモートで生成されるため、強調される。リンクされるべきファイルが、リモート・コールがなされた時点においてもはや存在しない場合、実行は中止される（命令文３および４）。
【０３０５】
応答の受信を不可能にするような故障が生じた場合、あるいはコーディネータが命令文２と６の間でクラッシュした場合、実行が中止され、ＲＤ内の新しいリンクは、ゴミとして収集される。
【０３０６】
行２のコールが成功である場合、新しい名前が返され、コーディネータがローカルＳＬを生成する（行６において）。そのようにすることの故障の場合、リンクのリモート削除が要求される。それがすみやかに続けられない場合でも、リンクはゴミとして収集される。
【０３０７】
命令文６が成功し、実行しているノードが直後に故障した場合、結果をクライアントに報告することができないが、ＳＬはその場所に残る。
【０３０８】
命令文７のプリミティブは、ゴミの収集が参照されなかったリンクの除去を担当するため、単なる最適化である。
【０３０９】
行９の呼び出しは、単なる最適化である。
【０３１０】
操作が実行されている間にノードがクラッシュした場合、アプリケーションの状態が失われ、アプリケーションが、全体の操作を再度実行しなければならないことに注目すべきである。アプリケーションが再度開始するとき、要求された名前が存在しても、存在しなくてもよい。
【０３１１】
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・既存のファイルへの新しいリンクがＲＤ内に生成される。この操作は、原子的である。リンクの生成が試みられた時点において、元となるファイルが存在する場合、生成は成功する。そうでない場合、操作の全体が中止される。やはり、リンクが生成されたのち、このリンクの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。古いリンクは、それが参照しているオブジェクトが正の参照カウントを有していて消失することがないため、この時点において任意のエンティティによって削除さえ可能である。新しいリンク名は、ＳＬにリンクされるまでは、ＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがそれと干渉することはありえない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。
【０３１２】
生じうる結果：
・成功。
・成功したが、成功の通知を返す前にコーディネータはクラッシュした。
・新規リンクが生成されたが、コーディネータがクラッシュし、あるいは応答が失われた。したがって、ＳＬが生成されなかった。参照されなかった新規リンクは、ゴミとして収集されることになる。
・新規リンクが生成され、ＳＬリンクの生成に失敗したが、新規リンクを削除できなかった。上記と同じ。
・リンクが生成されなかった。
【０３１３】
３．１．４．３  非共存在ディレクトリへのファイルまたはディレクトリのリネーム／移動
コーディネータが、ＦＳＯを除去しなければならないディレクトリを所有している。このコールには、このノードおよびＦＳＯを含んでいるボリュームのオーナが関与する。
【０３１４】
手順は次のとおりである。コーディネータが、ＦＳＯ（ＳＬではない）をＲＤディレクトリで数値名にリネームする。次いで、要求を行っているノードが、ＲＤ内のリモート・リンクを指すローカルＳＬを生成する。
【０３１５】
最初の状態は、図７に示すとおりである（ＦＳＯは、「通常」のディレクトリ内のエントリによって指し示されている）。最後の状態が、図８に示されている（今や、ＦＳＯがＲＤディレクトリのエントリによって指し示されている）。
【０３１６】
目標名が既存のディレクトリのものである場合、あるいはディレクトリを指しているＳＬのものである場合、実行は失敗し、下記のコードは該当しない。
【０３１７】
これについての擬似コードは以下のとおりである。
【０３１８】
【数１４】
2010108520.tif 000015
最初の動作はリモートである（協調されている）。リモート・ボリュームのオーナが、ターゲットをＲＤへとリロケートするよう要求される（命令文１）。ディレクトリについて、ＶＰＤバックリンクのみが使用される。タイムアウトが指定され、タイムアウト経過前に命令文９が実行されない限り、この動作はアンドゥされる。
【０３１９】
行１の要求が失敗に終わり、操作が放棄される可能性もある（命令文２および３）。成功し、成功の応答が返されて、命令文５に続く可能性もある。応答が受信される前にリモート・ノードがクラッシュした場合、応答が失われた場合、あるいは命令文６の前にコーディネータがクラッシュした場合、リロケートされたＦＳＯがアクセス不能になる可能性がある。しかしながら、命令文６の実行なくしてタイムアウトが経過したとき、リモート・ノードはＦＳＯを以前の状態に復帰させる。
【０３２０】
行１のコールが成功した場合、新しい名前が返され、コーディネータがローカルＩＤを生成する（行５において）。そのようにすることが失敗した場合、命令文７がＦＳＯを以前の名前に回復させる。
【０３２１】
命令文５が成功し、その直後に実行しているノードが故障した場合、命令文７を実行することができず、結果をクライアントに報告することもできない。したがって、タイムアウトののちにＦＳＯが以前の名前に戻り、ダングリングなＳＬがローカル・ボリュームに存在することになるが、ゴミとして収集される。一方、コーディネータによって所有されているボリュームが再びオンラインになったとき、ＳＬが既存の名前を上書きしてしまっているならば、このオブジェクトを利用することができない。これは、ＬＵＤ機構によって引き継がれる。ボリュームの再開が、ＬＵＤ回復を生じさせる。この場合、リモートＦＳＯが以前の状態に戻るため、ＬＵＤのための回復機能が、新たに生成されたＳＬについて有効な参照を検出せず、それをＬＵＤに保存されている当該名前に以前に関連付けられていたオブジェクトで上書きする。
【０３２２】
「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」の呼び出しが上手くいかなかった場合（タイムアウトが経過したためにそのようになるであろう）、新しいＳＬは削除（ダングリングである）され、状態は、このコードが実行を開始する前のそれに戻る。
【０３２３】
命令文７のプリミティブは、ゴミの収集が参照されなかったＦＳＯの除去を担当するため、単なる最適化である。
【０３２４】
成功の場合、命令文１１が、新しいＳＬ（存在する場合）で置き換えられたＬＵＤに保存されているオブジェクトを取り除く。失敗の場合、保存されているオブジェクトを復活させる。
【０３２５】
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・参照されたオブジェクトへの既存のＦＳＯリンクを、それが存在するディレクトリからＲＤへとリネームする。この操作は原子的であり、成功するか行なわれないかである。やはり、リネームののち、このリンクの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。新しいリンク名は、ＳＬにリンクされるまではＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがそれと干渉することはありえない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。
【０３２６】
生じうる結果（ＦＳＯが有用なコンテントを有している）：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・ＦＳＯがリロケートされたが、ＳＬが生成されなかった。有用なコンテントを有する参照されていないＦＳＯ。タイムアウトの経過によってＦＳＯが元の状態に戻され、ＬＵＤ機構が新しいＳＬによって上書きされたあらゆるオブジェクトを元に戻す。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、命令文７を実行する前にコーディネータがクラッシュした。この場合、すべてが実行されたにもかかわらず、ＦＳＯは以前の状態に戻る。
・ＦＳＯのリロケートが行なわれなかった。
【０３２７】
３．１．４．４  既存のファイルまたはディレクトリを指しているＳＬのリネーム／移動
コーディネータは、ＦＳＯの目標ペアレント・ディレクトリ（またはＶＰＤ）が位置しているボリュームのオーナであろう。
【０３２８】
２つの場合が存在する。
・ＳＬのリネームによって、ＳＬが既存のＦＳＯと共存在になる場合、この操作は、ＦＳＯが存在するボリュームについてのローカル・リネームということになり、続いて元のＳＬが取り除かれる。これが、共存在のＳＬが、次の場合で扱われるとおり、機能的に等価であるという点で、単なる最適化であることに注意すべきである。この場合において、最初の状態は図９に示すとおりである。最後の状態は図１０に示すとおりである。
・リネームによってＳＬが参照されたＦＳＯと共存在にならない場合、まずＦＳＯがリロケートされ（これは、ＲＤ内でのリネームのみを必要とするであろう）、次いで、目標ＦＳＯへの参照を埋め込んだ新しいＳＬが生成される。最後に古いＳＬが削除される。新旧のＳＬが同じボリューム内にあるか否かに応じ、最初のステップは、コーディネータ・ノードにローカルであるかもしれないし、ローカルでないかもしれない。この場合において、最初の状態は図１１に示すとおりである。最後の状態は図１２に示すとおりである。
【０３２９】
新しい目標名が既存のディレクトリのそれである場合、あるいはディレクトリを指しているＳＬのそれである場合、実行は失敗し、下記のコードは該当しない。
【０３３０】
これについての擬似コードは以下のとおりである。
【０３３１】
【数１５】
2010108520.tif 000016
最初に、実際のＦＳＯ情報が引き出される（命令文１）。
【０３３２】
新しいボリュームおよびＦＳＯボリュームが１つであって同じである場合、ＦＳＯが、単に新しい名前にリネームされる（命令文３）。これが、コーディネータが新しいペアレント・ディレクトリのためのボリュームのオーナであるため、ローカルな動作であることに注意すべきである。これが成功した場合、古いＳＬが削除される（命令文５）。ここで、リネームの操作が成功したが古いＳＬの削除が達成されなかった場合、後者がゴミとして収集されることに注意すべきである。
【０３３３】
前記２つのボリュームが一致しない場合、まず、ＦＳＯが新しい名前にリロケートされる（命令文９）。これは、タイムアウトの経過前に命令文１４が実行されない限り、自動的にアンドゥされる。リロケーションが成功しない場合、操作は中止される（命令文１０および１１）。次いで、新しいＳＬが生成される（命令文１３）。続く命令文（１４）は、命令文１３が成功したか否かに応じて、リロケートをコミットするか、あるいはアンドゥする。
【０３３４】
命令文１３が成功し、直後にコーディネータが故障した場合、命令文１４を実行することができず、結果をクライアントに知らせることもできない。
【０３３５】
したがって、タイムアウトののちにＦＳＯが以前の名前に戻り、ダングリングなＳＬがローカル・ボリュームに存在することになるが、ゴミとして収集される。一方、コーディネータによって所有されているボリュームが再びオンラインになったとき、ＳＬが既存の名前を上書きしてしまっているならば、このオブジェクトを利用することができない。これは、ＬＵＤ機構によって引き継がれる。ボリュームの再開が、ＬＵＤ回復を生じさせる。この場合、リモートＦＳＯが以前の状態に戻るため、ＬＵＤのための回復機能が、新たに生成されたＳＬについて有効な参照を検出せず、それをＬＵＤに保存されている当該名前に以前に関連付けられていたオブジェクトで上書きする。
【０３３６】
命令文１４の「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」の呼び出しが上手くいかなかった場合（タイムアウトが経過したためにそのようになるであろう）、新しいＳＬは削除（ダングリングである）され、状態は、このコードが実行を開始する前のそれに戻る。
【０３３７】
成功の場合、命令文１９が、新しいＳＬ（存在する場合）で置き換えられたＬＵＤに保存されているオブジェクトを取り除く。失敗の場合、保存されているオブジェクトを復活させる。
【０３３８】
そうでない場合、この時点においてダングリングであることに相違ないため、古いＳＬが削除される（命令文２２）。一方で、（ｏｌｄＶｏｌ，ｏｌｄＮａｍｅ）の組が再使用されている場合、削除はされないことに注意すべきである。最後に、クライアントへと応答が返される。
【０３３９】
命令文３のプリミティブは、標準ファイル・システムのリネーム・コールのリモート呼び出しである。
【０３４０】
すでに述べた場合と同様、この操作も多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
【０３４１】
生じうる結果（ＦＳＯが有用なコンテントを有している）：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・リンクが同じボリューム内でリネームされたが、コーディネータに知らされたか否かに関係なく、古いＳＬが削除されなかった（そして、ダングリングなまま残された）。この古いＳＬは、ゴミとして収集される。
・ＦＳＯがリロケートされたが、コーディネータのクラッシュまたはコーディネータへの通知の欠落によって、新しいＳＬが生成されなかった。タイムアウトの経過後にＦＳＯが元の状態に戻り、ＬＵＤ機構が新しいＳＬによって上書きされたあらゆるオブジェクトを元に戻す。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、コーディネータのクラッシュによって命令文１４が実行されなかった。タイムアウトの経過後にＦＳＯが元の状態に戻り、次いで、ダングリングな新しいＳＬがゴミとして収集される。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、コーディネータのクラッシュまたはリモート・ノードのクラッシュによって古いＳＬが削除されなかった（そしてダングリングなまま残された）。この古いＳＬは、ゴミとして収集される。
・失敗、変化なし。
【０３４２】
３．１．４．５  ファイルまたはディレクトリへのＳＬの除去
コーディネータは、ＳＬのオーナである。
【０３４３】
この操作は、ＳＬを取り除くこと、および当該ＳＬが指し示していたＲＤ内のリンクを取り除くことで構成される。これは、参照カウントによって決まるが、ＦＳＯの実際の削除を必要とするかもしれないし、必要としないかもしれない。
【０３４４】
これについての擬似コードは以下のとおりである。
【０３４５】
【数１６】
2010108520.tif 000017
まず、ＳＬの参照ＦＳＯが引き出される（命令文１）。次いで、ＳＬがローカルに削除される（命令文３）。成功した場合、ＳＬが参照していたＦＳＯリンクも、リモート・ボリュームにおいて削除される（命令文４）。
【０３４６】
生じうる結果：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・ＳＬが削除されたが、ＲＤ内のリンクは削除されず、参照されていない。このリンクは、ゴミとして削除される（これが唯一のリンクである場合、ＦＳＯが削除される）。
【０３４７】
３．１．４．６  ＳＬの生成およびＬＵＤの役割
ＬＵＤは、ＲＤと同様、ＮＡＳクライアントにとって見ることができない。それは、ローカル・ボリュームがローカルＦＳＯを置換したＳＬによって参照を有しているシステム内の各ボリュームに１つずつ、いくつかのサブディレクトリを有している。
【０３４８】
これらサブディレクトリの１つの各エントリは、ＦＳＯへのリンクまたはＳＬであり、新しいＳＬで置き換えられなければならない。このディレクトリ内のエントリのパス名のそれぞれは、ＦＳＯの元のパス名を、ＦＳＯを置き換えたＳＬにおいて参照されているｅ−番号とともに符号化している。
【０３４９】
他のボリュームがオンライン状態に達しているとき、ボリュームが回復すると、適切な回復プロセスがそのようなエントリのすべてを通過し、それ（そのパス名が知られている）を置き換えたＳＬが有効な参照を含んでいる（すなわち、既存のＦＳＯを指している）かどうかを確認するチェックが行なわれる。そのようである場合、ＬＵＤエントリが削除される。そうでない場合、ＳＬを削除して、ＬＵＤの保存されたリンク／ＳＬで再び置き替える。これが、ボリューム操作を実行しているノードがクラッシュした場合に、既存のＦＳＯの破壊を行なわないように処置し、「ｒｅｓｔｏｒｅ」項の設定とともにＣｌｅａｎｕｐＬＵＤ（）の呼び出しの繰り返しによって実行される。
【０３５０】
３．１．５  クライアント・ロッキング
クライアント・ロッキングは、所与のサービスが呼び出された時点におけるロックを明示的に要求するクライアント操作に関係する。これは、共有または排他モードにおけるファイル全体のロッキングまたはその一部のロッキングを含むことができる。
【０３５１】
クライアント・ロッキング・サポートは、ＮＦＳ様式のロッキングのセマンティクス、ならびにＷｉｎｄｏｗｓ（登録商標）の「ｏｐｌｏｃｋｓ」のそれ、およびクラスタ全体にわたる共有モードを完全にサポートできなければならない。
【０３５２】
これを取り扱うための自然なアプローチは、すべてのロッキング・コールを同じノードへと向け直すことによって、このレベルのロッキングを中央集権化するアプローチである。これは、ロッキング・プロトコルの文脈においてクライアント間でファイルの競合が生じた場合に、この種の要求が高速データ・パスの外であると考えられる点で機構を簡潔にし、それ自身が問題を引き起こすことがない。
【０３５３】
これの取り扱いにおける２つの選択肢は、次のものである。
・ＦＳＯにアクセスするための最初のノードが、すべてのクライアントが当該ファイルへのアクセスをやめるときまで、当該ＦＳＯについてのロック・マネージャとなることができる。これは、クラスタ・ノード間のロック管理の役割のよりよい分散をもたらす傾向にあり、これをかなり動的にする。
・あるいは、ロックが適用されるＦＳＯのオーナが、常に当該ＦＳＯのためのロック・マネージャの役割を実施することができる。この第２のアプローチは、ＦＳＯを修正できるエンティティのみが、そのロッキング・プロトコルを扱うエンティティであるという利点を有している。
【０３５４】
実際のところ、所与のＦＳＯのためのロック・マネージャの選択が、動的なネゴシエーションにもとづいて行なわれるのではなく、決定論的になるため、第２の選択肢が好ましい。したがって、それがよりよい選択肢である。
【０３５５】
３．１．６  クラスタ全体に保持されたチェックポイント
スタンドアロンのサーバのために設計されたような保持されたチェックポイント機構が、個々のボリュームに関して機能する。ファイルの外部ボリュームへのリロケートが許される場合、保持されたチェックポイントは、保持されたチェックポイントが取られた時点においてファイルのコンテントがクラスタ全体のビューと同期していることを保証しない。したがって、クラスタ・サービスは、すべてのボリュームについてのＩ／Ｏの中断、および各ボリュームについての保持されたチェックポイントの取得（これは並列に行なうことができる）を処理するクラスタ全体の保持されたチェックポイントを実装するであろう。このクラスタリング・サービスは、以下によって２相コミット機構を通じてのＩ／Ｏの中断をグローバルに調和しなければならない。
【０３５６】
１．保持されたチェックポイントが取られるまで、Ｉ／Ｏを中断する。
【０３５７】
２．ローカル保持されたチェックポイントを取り、Ｉ／Ｏを再開する。
【０３５８】
３．クラスタ全体に保持されたチェックポイントが取られたとき、すべてのボリュームについてチェックポイント番号を適切に同期させる。
【０３５９】
クラスタリング・サービスが、各ノードの関連ＡＰＩを適切に呼び出すように取り計らう。
【０３６０】
３．１．７  グローバル・ファイル・システム完全性チェック
先に概括したように、個々のボリュームの完全性を他のあらゆるボリュームのそれとは独立にチェックできるため、これを行なうために使用されるプログラムを、種々のボリューム上で並列に実行させることができる。
【０３６１】
したがって、各ボリューム・オーナは、必要であれば、当該ボリュームをクライアントによって利用可能にする前に、そのようなチェックを実行する。
【０３６２】
これがすべてのボリュームについてなされると、グローバル完全性チェッカ（清掃機）が、バックグラウンドで動作してＲＤ内のＳＬおよびＦＳＯを調べることによって作業を完了する。そのようなＦＳＯが親なしではないこと、およびダングリングなＳＬが存在していないことを確認すべきである。
【０３６３】
ごみ収集が未だ進行中の多ボリューム操作に影響しないことを確実にし、かつクラッシュしたノードの一時的な利用不可能性を確実に考慮に入れるため、清掃機は、以下の条件を満足するＦＳＯおよびＳＬのみを調べるべきである。
・ＳＬは、それが参照しているボリュームがオンラインである場合に調べられる。ＲＤ内のＦＳＯは、そのＳＬが存在すべきボリュームがアクティブである場合に調べられる。例えば、オフラインのボリュームを指しているＳＬは、調べるべきではない。
・調べられるべきＦＳＯまたはＳＬは、少なくともＸ分以上古いものである。Ｘは、あらゆる多ボリューム操作の完了を保証するために充分大きくあるべきである。
【０３６４】
この戦略が、ｅ−番号（すなわち、リロケートされたＦＳＯ参照）が常に増やされており、事実上再使用されない（１秒につき１００万個の新しいＲＤ名が生成されると仮定すると、６４ビットのアドレス空間は約５８５，０００年たつまでは埋め尽くされない）がゆえに有効であり、古いＳＬがダングリングになる点に注意すべきである。
【０３６５】
アルゴリズムは、グローバル・ファイル・システムにおいて上記条件に一致するすべての候補ＳＬを走査し、それらをＲＤの適切なエントリに一致させる。ＲＳ内のダングリングなＳＬおよび参照されていないＦＳＯが、削除される。
【０３６６】
多ボリューム操作に関係するオブジェクトのアイデンティティが、それぞれの多ボリューム走査の実行に先立ってログとして記憶された場合、清掃の所要時間および複雑さを、大幅に少なくできる点に注意すべきである。このようにして、操作をボリューム全体に適用するのではなく、そのようなエンティティに限定できる。当然ながら、チェックが実行され、適切な回復動作が行なわれた（必要な場合）のち、ログ・エントリを安全に削除することができる。
【０３６７】
ごみ収集の候補になったＦＳＯは、それらがデータを含んでいる場合、それらの削除が、それらを回復させることができるディレクトリへのリネームを構成するように取り扱われる。そのようなディレクトリ内に充分に長い継続時間の間とどまったのち、それらは恒久的に取り除かれる。
【０３６８】
３．１．９  分散サービス（ＤＳ）／高可用性（ＨＡ）サブシステム
各クラスタ・ノードは、ＤＳ／ＨＡサブシステムを含んでいる。ＤＳ／ＨＡサブシステムは、分散ファイル・システムのために必要なメンバーシップ、メッセージング、および構成インフラストラクチャを提供する。ＤＳ／ＨＡサブシステムのための要件および仮定は、かなり一般的であり、以下のものを含んでいる。
【０３６９】
１．ＤＳ／ＨＡサブシステムは、通信のための論理循環トポロジがクラスタに実装されていることを想定している。これは、各ノードが、このトポロジにおいて左（または右）隣りのＮＶＲＡＭデータの更新済みのコピーを有しており、ノード故障の場合に、隣りがデータの喪失なく引き継ぎを行なうことができることを保証するためになされる。さらに、隣りのＮＶＲＡＭのコピーを有しているノードが、当該隣のノードが故障した場合に、当該隣のノードの担当を引き継ぐための自然の候補である。このトポロジは、クラスタ内相互接続（以下で説明する）によって実装することができる。しかしながら、この同じトポロジを状態監視のために実装している冗長チャネルを有することが有用である。それらは、比較的低バンド幅のチャネルであるべきである。したがって、それらを低コストの手段によって実装することが可能である。
【０３７０】
２．信頼できるクラスタ・メンバーシップ機構。これは共有ストレージにとってきわめて重要な特徴である。とくに、メンバーシップ機構が、（ａ）クラスタ・メンバーシップに関し、すべてのノードが他のすべてのノードの状態と同じ決定に到達すること、および（ｂ）ネットワーク・パーティションの事象（「スプリット・ブレイン」シナリオと称されることもある）の場合に、最大１つのパーティションが生き残ることを保証しなければならない。
【０３７１】
３．ユニキャストまたはマルチキャスト・メッセージの順序正しい信頼できる配送。効率性の理由から、クラスタ相互接続が、少なくとも信頼できるユニキャスト配送をもたらすことが期待される。
【０３７２】
４．常時オンの構成。すなわち、最大の生存性を保証するため、クラスタ構成が、すべてのノードを横切って複製される。
【０３７３】
５．クラスタが安全な環境で稼動するものと仮定し、ビザンチン故障は考えない。インセイン型の故障は生じないと仮定する。
【０３７４】
６．クラスタ・アーキテクチャが高可用性をもたらさなければならない。ゆえに、故障の単独点が存在してはならない。さらに、可用性がファイブ・ナインの条件を満足しなければならない場合、早期故障検出を実行できる能力が重要である。高可用性の要件が、あらゆる単独の故障が、回復動作の終了後に再試行が試みられたときに、リソースへのクライアントのアクセスを不可能にしない限り、リソースを利用不可能にする故障がクライアントによって検出されないままにすることを指示しないことに注意すべきである。
【０３７５】
ＤＳ／ＨＡサブシステムは、以下の機能を実行する。
・各ＰＮの健康を監視する。
・スプリット・ブレイン・シンドロームを防止するため、クラスタ・クォーラムを確立して維持する。
・必要な状態移行を生じさせるため、イベントをＰＮに伝える。
・故障したＰＮからアクティブなＰＮへのＶＮの切り替え、および復帰の担当。
・秩序正しい起動が実行できるようにするための個々のボリュームの起動とローカルおよびグローバル完全性チェックの実行との協調。
【０３７６】
本発明の典型的な実施の形態においては、ＤＳ／ＨＡサブシステムは、ＦＳＭおよびおそらくはＳＩＭ上で実行される。便宜上、以下の検討ではＦＳＭボードのみを考えるが、ＳＩＭボードとの相互作用も、多かれ少なかれ自然に続く。例えば、ＤＳ／ＨＡサブシステムは、１つのノードの任意のボードと他のノードの任意のボードとの間の通信を可能にすべきである。これは、例えば、ボード識別子をノード識別子とともに（あるいは両者の組み合わせを）有するアドレスの仕組みを使用し、あるいは「メッセージ形式」を備え異なるサービスのためのＦＳＭおよびＳＩＭボード・レジスタについて異なるハンドラを有しているメッセージ層を使用して行なうことができる。
【０３７７】
図１３は、ＤＳ／ＨＡサブシステムと他の構成要素との関係を示している。見て取れるように、クラスタリング・モジュール、ＤＳ／ＨＡモジュール、および下にある相互接続との間に層状の関係が存在する。具体的には、種々のノードのクラスタリング・モジュールが、ＤＳ／ＨＡモジュールによってもたらされる抽象化層を通じてお互いに通信する。
【０３７８】
図１４は、ＤＳ／ＨＡモジュールの関連の構成要素を示している。ＤＳ／ＨＡモジュールは、以下のモジュールを含んでいる。
・相互接続ハードウェア・モジュール：保証なしおよび保証ありの両者の順次メッセージ配信を備える基本的なデータグラム機構を実装する。欠けているセマンティクスがもしあれば、ＩＭＦ層（下記参照）に実装される。
・ノード間メッセージング設備（ＩＭＦ）モジュール：（ａ）保証ありのメッセージ配信、および（ｂ）ノードのハートビートを提供する。クラスタ・メンバーシップをサポートするより低レベルの構成要素である。
・クォーラム・モジュール（ＱＭ）：クラスタ・クォーラム機構、ならびにクラスタ結合／分離機構を提供する。実際のクラスタ・メンバーシップ情報は、ＩＭＦ内に保持される。
・メッセージング・モジュール（ＭＭ）：ユニキャスト／マルチキャストな同期／非同期のメッセージング・プリミティブ、ならびにクラスタリングおよび他のモジュールのためのイベント登録およびハンドリングを提供する。ＩＨＭが保証ありのユニキャスト・メッセージングをサポートする場合、対応するＭＭおよびＩＭＦ機能は、単純なスタッブまたはマクロである。
・構成データベース・モジュール（ＣＤＭ）：複製された、常時オンの構成データベースを提供する。任意のノードについて実施された更新が、ＭＭの上部の２相コミット機構を使用して、他のすべてのノード上に自動的に複製される。
【０３７９】
見て取れるように、ＤＳ／ＨＡモジュールの種々の構成要素の間に層状の関係が存在する。高可用性の目的をサポートするため、高可用性のサポートに必要な構成要素が、各ノードにおいてアクティブでなければならない。
【０３８０】
３．１．９．１  ハートビート
ハートビート機構は、所与のノードが死んでいるか、生きているのかの判断を担当する。本発明の典型的な実施の形態においては、以下の理由から、ハートビート機構がＩＭＦモジュール（ＱＭモジュールではなく）の一部である
１．ハートビート・タイムアウトの場合に、ノードは死んでいると宣告（当該ノードが「誤った」パーティションに属しているのではないことを確認するため、ＣＭモジュールと相談のうえで）され、ＩＭＦモジュールが当該ノードについて係属中のすべてのメッセージを、（エラー状態とともに）フラッシュする。これは、ＣＭモジュールとＩＭＦモジュールとの間の不一致を防止する。
【０３８１】
２．ハートビート機構は、ノードのハートビート・タイムアウトを検出する低レベル・キープ・アライブの論理を実装し、残りのクラスタ・アルゴリズムから比較的独立している。ＱＭモジュールは、ノードが依然としてクラスタ・クォーラムの一部である（すなわち、ノードが「誤った」パーティションに属してはいない）か否かを実際に判断する。その働きは、クラスタの特定の実装に強く結び付いている。したがって、２つのモジュールを別にしておくことが理に適っている。類似のアプローチが、ＶＡＸＣｌｕｓｔｅｒｓ［Ｄａｖｉｓ  １９９３］によって使用されている。
【０３８２】
３．１．９．２  故障回復
ＨＡのサポートおよび個々のノード故障からの回復は、ストレージ・リソース（ボリューム）をそれらのオーナとして機能する「仮想ノード」（ＶＮ）へと関連付けることにある。ＶＮのそれぞれは、仮想名および仮想ＩＰアドレスを有しており、物理ノード（ＰＮ）に関連付けられている。ＨＡサブシステムがＰＮの故障を検出したとき、ＨＡサブシステムは、典型的には、当該ＰＮをシャットダウン（すでに死んでいる場合を除く）させ、故障したＰＮに関連付けられているＶＮを他の利用可能なＰＮへと移動（連結）させる。この移行は自動的であるが、故障はアプリケーションにとって完全にトランスペアレントではない。換言すれば、リカバリの進行中にアプリケーションがタイムアウトになる可能性があり、これはアプリケーションから見ることができる。しかしながら、アプリケーションは、同じ仮想名および同じ仮想アドレスを通じてアクセスしていたストレージへのアクセスを続け、この組が、他の物理ノードにトランスペアレントに関連付けられる。
【０３８３】
フェイルバックは、ＶＮを故障の発生前それらをサポートしていたＰＮへと復帰させることからなる。自動および手動フェイルバックの両方を生じさせることが可能である。これは、修復されたノードをオンラインに戻し、機能を実行しているすべてのノードの間に分散するために重要である。自動フェイルバックであっても、クライアント・アプリケーション内で検出されうる一時的中断を生じるため、手動のフェイルバックが、それが、活動のフェイルバック実行前の静かな停止を可能にして、アプリケーションにおけるいかなる形式の中断をも防止するため、典型的な選択であると予想される。
【０３８４】
２つ以上のノードを有するクラスタは、常に冗長である。したがって、１つのユニットが故障した場合の性能の低下を回避するため、予備のユニットを設けることができる。しかしながら、それは、クラスタ全体の可用性を向上させるためだけに設ける必要はない。
【０３８５】
この構造は、以下のサポートに好適である。
・高度な冗長性を備える完全に成熟したクラスタ構成。
・限られたノード数のローエンド・クラスタ構成。
・各ノードが故障したノードによって管理されていたボリュームの管理を引き継ぐことができる簡単なローエンド・アクティブ／アクティブなフェイルオーバ構成。しかしながら、そのような構成は、個々の集合していないボリュームを直接エクスポートすることを選択するかもしれない。
【０３８６】
３．２  要約
以上説明したアーキテクチャは、第１に、要求を複数のクラスタ・ノードへと並列に配ることによって、拡張可能な性能をもたらすことを目的にしている。加えて、可用性も向上する。
【０３８７】
このソリューションは、主に、パス名を、ＳＬを使用して、物理ファイル・アロケーションから分離させるというアイデアに基礎を置いており、多ボリューム操作についてであっても、複雑な分散ロッキングの仕組みという犠牲を払うことなく、最大の並列性が達成できる。
【０３８８】
このアーキテクチャは、個々のボリューム内において厳格なファイル・システム完全性をサポートし、ボリュームを横断していくぶんか緩いファイル・システム完全性をサポートする。しかしながら、後者が不整合なビューを生じさせることも、データ変造を生じさせることも決してなく、せいぜい参照されていないＦＳＯまたはダングリングなＳＬの削除を遅らせるという影響を有する程度である。
【０３８９】
このプロジェクトの段階Ｉの後のさらなる発展は、以下を目標とすることができる。
・使用統計にもとづくファイルの自動リロケーション。これにより、観測された使用パターンを利用してファイルの存在位置を改善することができる。
・クラスタのマージ。独立したクラスタを１つに合体させるための方法が存在すべきである。
・性能評価およびボトルネックの特定にもとづくさまざまな最適化。
【０３９０】
４  実装上の問題
このセクションでは、種々の実装上の問題を取り扱う。
【０３９１】
４．１  クラスタ内相互接続
クラスタ・メンバーが効率的に通信できるために、好ましくは、高速なプライベート通信チャネルが、クラスタ・ノードを相互接続するために使用される。プライベート（すなわち、クラスタ・ノードのみが利用可能であり、クラスタ・クライアントは利用できない）チャネルは、クラスタのあらゆるトランザクションに関与する当事者について認証および許可のチェックを不要にすることによって、通信プロトコルを能率化する。
【０３９２】
クラスタ内に、論理的に別個な２つのクラスタ内リンクが存在する。１つ目はＦＳＭ間であり、２つ目はＳＩＭ間である。各クラスタ・ノードからの２つの物理的な相互接続が存在するであろう。物理的な相互接続への論理リンクのマッピングは、相互接続の可用性および相互接続の負荷によって決められる。
【０３９３】
クラスタ内において、クラスタ・ノードを相互接続するために２つの相互接続スイッチを使用できる。各クラスタ・ノードからの２つの相互接続のそれぞれは、異なる相互接続スイッチに接続される。これが、スイッチおよびリンクのいくらかの冗長性をもたらす。
【０３９４】
各クラスタ・ノードは、クラスタ内制御ブロックを有するであろう。このクラスタ内制御ブロックは、典型的には、ＦＳＭまたはＳＩＭのいずれかに実装される。クラスタ内制御ブロックは、ＦＳＭ論理リンク・インターフェイス、ＳＩＭ論理リンク・インターフェイス、ならびにクラスタ間相互接続０およびクラスタ間相互接続１と称される２つのクラスタ間相互接続を含むであろう。物理的な相互接続への論理リンクのマッピングは、動的に実装されるであろう。このようにして、或る程度の負荷バランスが、必要とされる相互接続の冗長性とともにもたらされる。
【０３９５】
ＦＳＭ間のリンクは、ＷＦＳ要求ミラーリング（安定なストレージ・ソリューションを実現するため）、メタデータ・キャッシュ管理（コヒーレンシ、ロックの要求および応答、など）、ボリューム・オーナへの書き込み要求の転送、および一般的なクラスタ管理などの機能をサポートするため、メッセージおよびデータを運ぶであろう。
【０３９６】
ＳＩＭ間のリンクは、ファイル・データの転送を含むセクタ・データ・キャッシュ管理（コヒーレンシ、ロックの要求および応答、など）のための機能をサポートするため、メッセージおよびデータを運ぶであろう。
【０３９７】
４．２  クライアントの結び付け
ファイルが常に指定のクラスタ・ノードを通じて書き込まれることを確実にすることによって、性能を向上させることができる。
【０３９８】
理想的には、ファイルを、それらが存在しているボリュームを「所有」しているクラスタ・ノードを通じての書き込みのためだけに開かれることで、これがなされる。これは、些細なことではない。困難性は、特定のファイル・パス名が検出されたときに、当該要求が適切なクラスタ・ノードへと送られるように、要求パケットのすべてを処理しなければならないという点にある。これは、非標準スイッチとクラスタ・ノードとの間の密な一体化を通じて達成できる。
【０３９９】
他の（より最適ではない）ソリューション（「クラスタ・ノード親和性」基準と称される）が、所与のクライアントがクラスタ・サーバとして常に同じノードを使用するようクライアントをクラスタ・ノード間にパーティショニングすることによって、基本的に同じ利益をもたらす。このソリューションが基本的に同じ利益をもたらす理由は、所与のクライアントが同じファイルに何度も繰り返しアクセスする傾向にある（すなわち、参照の局在性）からである。
【０４００】
クライアントは、さまざまなやり方でクラスタ・ノード間にパーティショニングできる。
・クラスタ・ノードをクライアント−ベースで割り当てることによって。
・クラスタ・フロントエンドとして機能して適切なクライアント・パーティショニングの提供を担当するスイッチを設置するハードウェア−ベースのソリューションによって。
・ＤＮＳサーバの適切な設定によって。
・クラスタ・ノードに実装されたアドホック・ソフトウェアによって。
【０４０１】
クライアントを個々のクラスタ・ノードに結び付けるにあたって満足しなければならないいくつかの制約は、次のとおりである。
【０４０２】
１．当該ソリューションが、所与のクライアントが常に同じノードを自身のクラスタ・サーバとして使用するように、クライアントをクラスタ・ノード間にパーティションしなければならない。
【０４０３】
２．当該ソリューションが、クライアントのサーバへのワイヤ・スピードでの相互接続を可能にしなければならない。
【０４０４】
３．クライアントを物理的なクラスタ・ノードへと純粋に静的に結び付けるだけでは、ノードの故障および引き続くクラスタの自動再構成を許容しないため、中断のない可用性を保証するために不充分である。したがって、当該ソリューションが、ノード故障を考慮するため充分に柔軟でなくてはならない。
【０４０５】
４．クラスタ・ノードへのクライアントの結びつきを保証する能力は、故障は別にして、長い時間期間にわたって一貫して生じるようなものでなくてはならない。例えば、数時間または数日に限られたクライアント−サーバの結びつきは、決定論的な性能向上をもたらすために充分ではない。
【０４０６】
５．選択されたソリューションがハードウェア−ベースであろうと、ソフトウェア−ベースであろうと、高可用性の要件を満足するためには、当該ソリューションが故障の単独点を回避できていなければならない。
【０４０７】
これらの要件に加え、クライアントの組が、共通のファイルの組にそれらが存在するボリュームを「所有」しているクラスタ・ノードを通じてアクセスしてこれを変更し、さらに同じクラスタ・ノードを共有することが望まれる。
【０４０８】
クライアントを、クラスタ・ノード間でパーティションするため、要求を発しているクライアントを認識する機構が必要とされる。これを行なうための１つの方法は、要求を行なっているクライアントのＭＡＣ（メディア・アクセス制御）アドレスへとアクセスすることである。残念なことに、ＭＡＣアドレスそのものは、それをルーティング境界を横切るようにはしない。一方で、以下の問題を生じさせるものの、ソースＩＰアドレス（経路付けされている）を使用することができる。
【０４０９】
１．複数のクライアントがプロキシを通じて当該クラスタにアクセスする場合、ソースＩＰ認識が正確に機能するためには、特定のプロキシを通じて集中したすべてのクライアントについて、同じクラスタ・ノードを共有することが必要である。プロキシが、同じノードへとアクセスすべきクライアントを集合させるために使用される場合、プロキシの存在は、きわめて異なるソースＩＰアドレスを有するクライアントを一体にまとめるうえで好都合かもしれない。
【０４１０】
２．ＤＨＣＰ（動的ホスト構成プロトコル）が使用されている場合、ＤＨＣＰサーバによって管理されているＩＰアドレス空間を小さなセグメントにパーティションし、アドレス・セグメントがクラスタ・ノードの親和性にもとづいて割り当てられるようにする必要がある。換言すれば、各セグメントが、特定のクラスタ・ノードとやり取りをする必要があるすべてのクライアントを含むべきであり、なぜならば、それらがファイルおよびディレクトリの所与のセットにアクセスする傾向があるためである。したがって、ＩＰアドレスの動的割り当てが何であれ、その範囲を完全に認識し、適切に扱うことが可能である。
【０４１１】
これらの問題は、適切な構成によって対処可能であることに注意すべきである。
【０４１２】
４．２．１  クライアント−ベースのソリューション
このソリューションは、クラスタが含まれているネットワークの適切な構成によって得られる。それは、以下の原理にもとづいている。
・各クラスタ・ノードに、物理ＩＰアドレスならびに仮想ＩＰアドレスおよび名前が割り当てられている。この仮想アドレスは、最初はそれらのオーナ・ノードに結び付けられている。
・クライアントが、いくつかの基準に従ってクラスタ・ノードを横断してパーティションされる。例えば、クライアントを、クライアントが共通のファイルまたはディレクトリへの書き込みアクセスを共有しなければならない必要性に従って、クラスタ・ノードを横断してパーティションできる。そのようなクライアントのグループのそれぞれが、自身の所有するボリューム内に共有ファイルおよびディレクトリを割り当てるノードを特定する１つの仮想名へのアクセスを与えられる。
・クラスタ・ノードが故障したとき、ＶＮ／ＰＮの関係のため、セクション３．１．９で説明したとおりスイッチオーバがクライアントにとってトランスペアレントである。
【０４１３】
クライアント−ベースのソリューションのいくつかの利点には、次のものが含まれる。・簡潔であって、単刀直入である。
・追加の設備を必要としないため、安価であり、システム全体の可用性に影響を及ぼさない。
・クライアントとサーバ・ノードとの間に設備もソフトウェアも挿入しないため、性能を低下させる可能性がない。
・スイッチや追加の経路付け装置を使用しないため、クライアント・ネットワークとの互換性または一体化についての問題がない。
・クラスタの再構成がトランスペアレントである（ハードウェア−ベースのソリューションにも存在するクラスタ再構成に要する短いインターバルを除く）。
【０４１４】
クライアント−ベースのソリューションのいくつかの欠点には、次のものが含まれる。・ネットワークが、背後にクラスタ・ノードを隠しているスイッチに割り当てられた１つのアイデンティティではなく、多数の仮想ノード・アイデンティティを承知していなければならない。
・このソリューションの負担が、構成の問題に移されている。しかしながら、スイッチ−ベースのソリューションでは、これがスイッチそのものを構成することによって対処される一方で、ここでは、クライアントが適切に設定されなければならない。この負担は、構成プロセスを容易にする適切な管理ユーティリティを提供することによって、いくぶんか軽減できる。
【０４１５】
４．２．２  スイッチ−ベースのソリューション
スイッチを使用することによって、クライアントは、ただ１つの名前／ＩＰアドレスによってクラスタ全体をアドレスすることができ、スイッチが、適切なノードへのトランスペアレントなアクセスを管理する。
【０４１６】
主要なスイッチ製造者が、クライアントをサーバの集合体を横断して分配でき、かつ或る種の連続性（または「粘着性」）を保証できるイーサネット（登録商標）・スイッチを供給している。
【０４１７】
サーバ負荷バランス（ＳＬＢ）の問題に対処する多くのスイッチは、サーバの集合体をスイッチの背後に隠す能力を可能にし、負荷をバランスさせるため要求を種々のサーバへとアドレスする能力を可能にしている。
【０４１８】
これを行なう１つの方法は、パケットを特定の１つのサーバへと送信するため、クライアントのソースＩＰアドレスを使用することである。これは、各サーバの実際の負荷を考慮に入れていない点で、かなり静的な形式のバランスである。一方で、それは、所与のクライアントが常に同じサーバと通信することを保証し、コンテクストがすでにアクティブでありうる存在しているものをすべて利用する。
【０４１９】
多くのスイッチは、負荷を動的にバランスさせかつ粘着性を提供するはるかに洗練された仕組みを提供し、１つのパケットが所与のソースから所与のサーバへと送信され、所定に時間間隔内で続くすべてのパケットも、当該サーバへと向かう。
【０４２０】
永続的な接続を提供するためにしばしば使用される他の仕組みは、以下のように実装される。
・「クッキー」の使用による方法。クッキーは、サーバによって供給され、ブラウザによってクライアント内に保存されるトークンである。それらは、スイッチがコンテクストを推論してサーバへの適切な結びつきを確立できるようにする充分な参照情報をもたらす。これは、基本的に、ＨＴＴＰトラフィックに適用される。
・ＳＳＬセッションＩＤによる方法。これは、ＳＳＬセッションにのみ適用される。
・コンテクストに依存したパケット検査による方法。これは、使用中のアプリケーション・プロトコルに大きく依存し、Ｗｅｂサービスには限られない。
【０４２１】
各クライアントが特定のクラスタ・ノード（単に集合体のメンバーである任意のノードではなく）に接続される必要があるため、これらの規準はあまり関係がない。特定のソースＩＰアドレスを特定のクラスタ・ノードに結び付けることが適切であるが、そのようなソリューションをスイッチがサポートしないかもしれず、いくつかのスイッチが適切な構成を通じてサポートするかもしれない。
【０４２２】
ＳＬＢ能力を有する大部分のスイッチが、パケット内のソースＩＰアドレスのフィルタ処理、および要求されたサービスを提供するための集合体のサーバの１つへのパケットの経路付けを可能にする。これは、適切な構成エントリを通じてなされる。これを利用するため、集合体は、クライアント・アドレスの各組についてただ１つのサーバに制限されるべきである。結び付けは、クラスタＨＡサブシステムを通じて管理される仮想ＩＰアドレスに関して生じるべきである。これにより、ＨＡサブシステムが、ノード故障の場合にクラスタを適切に再構成でき、当該仮想ＩＰアドレスを故障ノードの機能を引き継いだノードによって再使用できるようにする。
【０４２３】
スイッチ−ベースのソリューションのいくつかの利点には、次のものが含まれる。
・スイッチに関連付けられたただ１つのＩＰアドレス／名前を発行すればよい。スイッチそのものがクラスタ・ノードを隠し、それが構成されたやり方に従ってトラフィックを経路付けする。
・中央集権化された構成によって、全所有コストが低減される。
・スイッチによって、顧客のネットワーク設定の大きな変更を回避でき、したがって極めて望ましい。
【０４２４】
スイッチ−ベースのソリューションのいくつかの欠点には、次のものが含まれる。
・スイッチ−ベースのソリューションは、一般に、ソフトウェア−ベースまたは構成ベースのソリューションよりも高価である。
・高可用性要件を満足させるため、スイッチ配置構成が冗長性を有していなければならず、さらにコストを増大させる。
・必要な特徴をさまざまな供給元から入手することができるが、以下に述べるとおり、それらは標準的な設備ではなく、継続的に入手可能であるかについて保証がない。
・或る特定の供給元からのスイッチを選択することが、別の供給元を標準としているユーザにとって受け入れられない。一方、複数の供給元からのスイッチを適用可能にすることは、余分な努力とコストを必要とする。
【０４２５】
以下の検討は、前記クライアント結び付け要件を満足することができるいくつかのＳＬＢスイッチについての詳細を提供する。
５  多ボリューム操作のための故障回復
このセクションでは、多ボリューム操作において生じうる考えられるいくつかのノード故障（ノード・クラッシュ）について、典型的な故障回復手順を説明する。セクション３．１．４で説明した多ボリューム操作のそれぞれ、および故障のそれぞれについて、典型的な回復の動作を示す。下記の表において、「ローカル・ノード」は「コーディネータ・ノード」の別名であって、ローカル・ノードが要求された操作を実行している（おそらくは他の要求者の代理として）ノードであることを意味している。
【０４２６】
このセクションは、再試行の場合にとられる動作を含んでおらず、すなわち、アプリケーション・ノードが要求を再試行しないと仮定している（これは、ｒｅｔｒｙ＝１のＮＦＳソフト・マウントについて生じる可能性があり、あるいはアプリケーション・ノードがＮＡＳへの要求を送信した直後にクラッシュする場合に生じうる）。
【０４２７】
表中の各動作に組み合わされている番号は、セクション３．１．４中の対応する擬似コードの命令文番号である。
【０４２８】
故障の列中の「Ｘ」は、回復動作が不要であることを示している。
【０４２９】
動作が示されていない行は、操作間における故障の状態を表わしている。
【０４３０】
５．１  外部（リモート）ディレクトリ内に（ローカル）ＦＳＯを生成（３．１．４．１）
【０４３１】
【表１】
2010108520.tif 000018
５．２  既存の（リモート）ファイルへの（ローカル）ＳＬの生成（３．１．４．２）
【０４３２】
【表２】
2010108520.tif 000019
５．３  （リモート）ディレクトリから非共存在（ローカル）ディレクトリへの（リモート）ファイルまたはディレクトリのリネーム／移動（３．１．４．３）
【０４３３】
【表３】
2010108520.tif 000020
５．４  既存のファイルまたはディレクトリを指しているＳＬのリネーム／移動（３．１．４．４）
この操作は、２つの異なる場合を有する。場合１は、目的地ボリュームがＦＳＯを保持しているボリュームである場合である。場合２は、目的地、ソース、およびＦＳＯボリュームが異なっている場合である。
【０４３４】
場合１については、初期状態が図９に示されており、最終の状態が図１０に示されている。これを念頭に置き、故障分析は以下のとおりとなる。
【０４３５】
【表４】
2010108520.tif 000021
場合１については、初期状態が図１１に示されており、最終の状態が図１２に示されている。これを念頭に置き、故障分析は以下のとおりとなる。
【０４３６】
【表５】
2010108520.tif 000022
【０４３７】
【表６】
2010108520.tif 000023
【０４３８】
【表７】
2010108520.tif 000024
【０４３９】
【表８】
2010108520.tif 000025
【０４４０】
【表９】
2010108520.tif 000026
【０４４１】
【表１０】
2010108520.tif 000027
【０４４２】
【表１１】
2010108520.tif 000028
【０４４３】
【表１２】
2010108520.tif 000029
【０４４４】
【表１３】
2010108520.tif 000030
【０４４５】
【表１４】
2010108520.tif 000031
５．５  ファイルまたはディレクトリへのＳＬの削除（３．１．４．５）
【０４４６】
【表１５】
2010108520.tif 000032
６．０  その他
以上、本発明のさまざまな実施の形態を、ＦＳＭ、ＳＩＭ、およびＮＩＭなどの種々のモジュールを含む特定のハードウェア−ベースのファイル・システム・プラットフォームに関して説明したが、本発明がここに記載した実施の形態またはプラットフォームに限られるものでは決してなく、本発明を他のやり方で具現化し、他のファイル・システム・プラットフォームに広く一般的に適用できることは、当業者であれば明らかである。
【０４４７】
本発明は、決してこれらに限られるわけではないが、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）とともに使用するコンピュータ・プログラム・ロジック、プログラマブル論理デバイス（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のＰＬＤ）とともに使用するプログラマブル・ロジック、複数の個別の素子の集まり、集積回路（例えば、特定用途向け集積回路（ＡＳＩＣ））、またはこれらの組み合わせを含む他の任意の手段を含む多くの別の形式で具現化できる。本発明の典型的な実施の形態においては、広く多数のボリュームを横断してファイル・システム・オブジェクトを管理するためのロジックのすべてが、コンピュータで実行可能な形式に変換され、それ自体がコンピュータで読み出し可能な媒体内に保存され、オペレーティング・システムの制御のもとでクラスタ・ノード内のマイクロプロセッサによって実行されるコンピュータ・プログラム・インストラクションの組として実装される。
【０４４８】
本明細書ですでに説明した機能のすべてまたは一部を実装するコンピュータ・プログラム・ロジックは、決してこれらに限られるわけではないが、ソースコード形式、コンピュータによって実行できる形式、および種々の中間的形式（例えば、アセンブラ、コンパイラ、リンカ、またはロケータによって生成された形式）を含むさまざまな形式で具現化できる。ソースコードは、さまざまなオペレーティング・システムまたは動作環境における使用のため、さまざまなプログラミング言語（例えば、オブジェクト・コード、アセンブリ言語、あるいはＦｏｒｔｒａｎ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、またはＨＴＭＬなどの高級言語）の任意のいずれかで実装された一連のコンピュータ・プログラム・インストラクションを含むことができる。ソースコードは、さまざまなデータ構造および通信メッセージを規定して使用することができる。ソースコードは、コンピュータで実行可能な形式（例えば、インタプリタを介して）であってよく、あるいはソースコードがコンピュータで実行可能な形式に変換（例えば、トランスレータ、アセンブラ、またはコンパイラによって）されてもよい。
【０４４９】
コンピュータ・プログラムは、任意の形式（例えば、ソースコード形式、コンピュータで実行可能な形式、または中間的な形式）で、恒久的または一時的に、半導体記憶装置（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュ・プログラマブルＲＡＭ）、磁気記憶装置（例えば、ディスケットまたは固定ディスク）、光学式記憶装置（例えば、ＣＤ−ＲＯＭ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、または他の記憶装置などの有形の記憶媒体に固定することができる。コンピュータ・プログラムは、これらに限られるわけではないが、アナログ技術、デジタル技術、光技術、無線技術（例えば、ブルートゥース）、ネットワーク技術、およびインターネットワーク技術を含むさまざまな通信技術のいずれかを使用してコンピュータへと伝達できる信号として任意の形式で固定できる。コンピュータ・プログラムは、印刷文書または電子文書が添付された持ち運び可能な記憶媒体（例えば、シュリンク包装されたソフトウェア）として任意の形式で配布でき、コンピュータ・システムにあらかじめ搭載（例えば、システムＲＯＭまたは固定ディスクに）でき、あるいは通信システム（例えば、インターネットまたはワールド・ワイド・ウェブ）を通してサーバまたは電子掲示板から配布できる。
【０４５０】
本明細書ですでに説明した機能のすべてまたは一部を実装するハードウェア・ロジック（プログラマブル・ロジック・デバイスで使用するプログラマブル・ロジックを含む）は、従来からの手動による方法を使用して設計でき、あるいはコンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えば、ＶＨＤＬまたはＡＨＤＬ）、またはＰＬＤプログラミング言語（例えば、ＰＡＬＡＳＭ、ＡＢＥＬ、またはＣＵＰＬ）などのさまざまなツールを使用して電子的に設計し、保存し、模擬し、あるいは記録することができる。
【０４５１】
プログラマブル・ロジックは、恒久的または一時的に、半導体記憶装置（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュ・プログラマブルＲＡＭ）、磁気記憶装置（例えば、ディスケットまたは固定ディスク）、光学式記憶装置（例えば、ＣＤ−ＲＯＭ）、または他の記憶装置などの有形の記憶媒体に固定することができる。プログラマブル・ロジックは、決してこれらに限られるわけではないが、アナログ技術、デジタル技術、光技術、無線技術（例えば、ブルートゥース）、ネットワーク技術、およびインターネットワーク技術を含むさまざまな通信技術のいずれかを使用してコンピュータへと伝達できる信号に固定できる。プログラマブル・ロジックは、印刷文書または電子文書が添付された持ち運び可能な記憶媒体（例えば、シュリンク包装されたソフトウェア）として配布でき、コンピュータ・システムにあらかじめ搭載（例えば、システムＲＯＭまたは固定ディスクに）でき、あるいは通信システム（例えば、インターネットまたはワールド・ワイド・ウェブ）を通してサーバまたは電子掲示板から配布できる。
【０４５２】
本発明は、本発明の本当の技術的範囲を離れることなく、他のいくつかの特定の形式で具現化できる。ここに記載した実施の形態は、あらゆる点に関し、例示として理解すべきであり、本発明を限定するものと考えるべきではない。
【図１】
2010108520.tif 000033
【図２】
2010108520.tif 000034
【図３】
2010108520.tif 000035
【図４】
2010108520.tif 000036
【図５】
2010108520.tif 000037
【図６】
2010108520.tif 000038
【図７】
2010108520.tif 000039
【図８】
2010108520.tif 000040
【図９】
2010108520.tif 000041
【図１０】
2010108520.tif 000042
【図１１】
2010108520.tif 000043
【図１２】
2010108520.tif 000044
【図１３】
2010108520.tif 000045
【図１４】
2010108520.tif 000046