JP4480153B2 - 分散ファイル・システムおよび方法 - Google Patents

分散ファイル・システムおよび方法 Download PDF

Info

Publication number
JP4480153B2
JP4480153B2 JP2004550258A JP2004550258A JP4480153B2 JP 4480153 B2 JP4480153 B2 JP 4480153B2 JP 2004550258 A JP2004550258 A JP 2004550258A JP 2004550258 A JP2004550258 A JP 2004550258A JP 4480153 B2 JP4480153 B2 JP 4480153B2
Authority
JP
Japan
Prior art keywords
volume
file system
node
system object
logical
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004550258A
Other languages
English (en)
Other versions
JP2006505071A (ja
Inventor
フランセスコ ラカプラ，
フィオレンゾ カッタネオ，
サイモン エル． ベンハム，
トレバー ウィリス，
クリストファー ジェイ． アストン，
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Data Systems Engineering UK Ltd
Original Assignee
Hitachi Data Systems Engineering UK Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Data Systems Engineering UK Ltd filed Critical Hitachi Data Systems Engineering UK Ltd
Publication of JP2006505071A publication Critical patent/JP2006505071A/ja
Application granted granted Critical
Publication of JP4480153B2 publication Critical patent/JP4480153B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
    • G06F16/1827—Management specifically adapted to NAS
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/912—Applications of a database
    • Y10S707/944—Business related
    • Y10S707/947—Human resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

（技術分野および背景技術）
本発明は、コンピュータのファイル・システムに関し、とくにはファイル・システム・オブジェクトが複数のファイル・システム・ノード上の複数の自己完結ボリュームに分散されているファイル・システムに関する。
（発明の開示）
ネットワーク接続型ストレージ（ＮＡＳ）ノードのクラスタにおける分散ファイル・システムおよび方法は、ファイル・システム・オブジェクトを多数の自己完結ボリュームにわたって分散させており、各ボリュームが、固有のクラスタ・ノードに所有されている。ボリューム間でファイル・システム・オブジェクトを参照するため、論理リンクが使用される。各ファイル・システム・オブジェクトは、当該オブジェクトのコンテンツがどこに保存されているのかを複数の属性（長さ、および所有者情報など、を含む）とともに記述する「ｉ−ｎｏｄｅ」と呼ばれるメタデータ構造によって実装されている。各クラスタ・ノードは、リロケーション・ディレクトリを含んでおり、該リロケーション・ディレクトリが、ローカルに保存され、論理リンクを使用して他のクラスタ・ノードから参照されるファイル・システム・オブジェクトへのハード・リンクを保持している。複数のボリュームが関与するさまざまなファイル・システム操作が、一度に２つ以上のボリュームに書き込みロックを置く必要なく実行される。さまざまなキャッシュの仕組みが、種々のクラスタ・ノードがファイル・システム・オブジェクト・データおよびメタデータをキャッシュできるようにしている。
本発明の一実施の形態においては、それぞれが複数の論理ストレージ・ボリュームへのアクセスを有している複数のクラスタ・ノードを使用して、該ノードと通信するクライアントによる前記ボリューム上のデータへのアクセスを提供するための方法が提供される。この方法は、所与のストレージ・ボリュームのデータまたはメタデータのコンテントを変更する操作（本明細書では、広く「書き込み」と称する）を、該ボリュームを所有しているとみなされる唯一のクラスタ・ノードによってのみ実施可能にすること、および、第１のクラスタ・ノードに、該第１のクラスタ・ノードが所有する第１のボリュームへのファイル・システム・オブジェクトの保存を実行させ、さらに前記第１のボリュームと第２のクラスタ・ノードが所有する第２のボリュームとの間の論理リンクを、該論理リンクが前記第１のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成することによって、ファイル・システム・オブジェクトを複数のボリュームを横断して保持することを含んでいる。ファイル・システム・オブジェクトは、ファイルまたはディレクトリであってよい。
この方法は、記論理識別子を、前記第１のボリュームのリロケーション・ディレクトリであって、前記第１のボリューム以外のボリュームから論理的に参照される前記第１のボリューム内のすべてのファイル・システム・オブジェクトについての論理識別子を列挙しているリロケーション・ディレクトリに保存することを含むことができる。リロケーション・ディレクトリは、通常は、階層構造を有している。前記第１のクラスタ・ノードに前記ファイル・システム・オブジェクトの保存を実行させるプロセス、および前記論理リンクを生成するプロセスは、通常は、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ実行される。前記プロセスを実行する過程において、通常は、１つのクラスタ・ノードに、前記種々のボリュームのための書き込みロック・マネージャの役割が割り当てられる。書き込みロック・マネージャは、通常は、前記ノードに書き込みロック・マネージャの役割が、該ノードが前記複数のクラスタ・ノードに合流するときから該第１ノードが前記複数のクラスタ・ノードを離れるときまで割り当てられるよう、半静的なやり方で割り当てられる。
前記論理リンクの生成のプロセスは、通常は、少なくとも前記第１のボリュームにおいて唯一である識別子を前記論理識別子として割り当てることを含んでいる。前記唯一の識別子は、通常は、前記第１のボリューム内のファイル・システム・オブジェクトのためにすでに割り当てられた論理識別子のカウントにもとづいて割り当てられる。
ファイル・システム・オブジェクトへのアクセスが、所与のボリューム内で直接行なわれるか、あるいは論理リンクを通じて他のボリュームから行なわれるのかは、当該ＮＡＳクラスタとやり取りするクライアント・ソフトウェアから完全に隠されている。
さらに、この方法は、任意のノードによる所与のストレージ・ボリュームに対する読み出しを実行可能にすることを含むことができる。通常は、各ボリュームにボリューム・キャッシュが組み合わされ、通常は、各ノードにクラスタ・ノード・キャッシュが組み合わされている。さらにこの方法は、選択されたボリューム内のセクタを読み出すための要求であって、該選択されたボリュームとは別個のボリュームを所有している活動クラスタ・ノードによって受信された要求を、該活動クラスタ・ノードに、前記選択されたボリュームのオーナであるクラスタ・ノードへと、前記セクタに対する第１の読み出し要求であって、読み出しのみロックを有している読み出し要求の発行を実行させ、さらに前記選択されたボリュームへと、前記セクタに対する第２の読み出し要求の発行を実行させ、前記選択されたボリュームのオーナであるクラスタ・ノードに、自身が自身のキャッシュ内に前記セクタを有しているか否かを判断させ、有していない場合に、前記読み出しのみロックを認可して前記選択されたボリュームが前記要求を満足させるようにし、有しておりかつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントを前記選択されたボリュームを所有しているノードのキャッシュから前記活動ノードへと送信するとともに、前記要求に関する前記選択されたボリュームの通信を停止し、有しておりかつ前記セクタが書き込みロックされている場合、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開することによって処理することができる。前記読み出しのみロックの認可は、通常は。キャッシュ状態を追跡できるよう、前記活動クラスタ・ノードおよび前記セクタのアイデンティティを記録することを含んでいる。
さらにこの方法は、前記第２のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子への論理参照を保存することを含むことができる。論理参照は、通常は、前記論理識別子と、前記第１のボリュームの前記リロケーション・ディレクトリの前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値（ｅ−番号）を含んでいる。論理参照は、通常は、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子に対する唯一無二の論理参照であるように制限されている。
さらにこの方法は、前記第２のボリュームから前記論理参照を削除すること、および前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除することを含むことができる。
さらにこの方法は、前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、および前記第２のボリュームから前記論理参照を削除することを含むことができる。
さらにこの方法は、前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを、例えば前記論理参照を折々に調べて該論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して割り出すこと、および該論理参照を前記第２のボリュームから削除することを含むことができる。
さらにこの方法は、前記第１のボリュームの前記ファイル・システム・オブジェクトがもはや他のボリュームのいかなる論理参照によっても参照されていないことを、例えば前記リロケーション・ディレクトリを折々に調べて前記ファイル・システム・オブジェクトが他のボリュームの少なくとも１つの論理参照によって参照されているか否かを割り出すための清掃機プロセスを使用して割り出すこと、および該ファイル・システム・オブジェクトを前記第１のボリュームから削除することを含むことができる。清掃機プロセスは、通常は、当該操作に関係するボリュームの１つがシャットダウンまたはクラッシュしたときに修正された参照およびファイル・システム・オブジェクトについて動作する。
さらにこの方法は、前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることを含むことができる。これは、典型的には、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ディレクトリを実装するｉ−ｎｏｄｅに、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照を保存することを含むことができる。前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照は、前記第２のボリュームに関連付けられたボリューム識別子、および前記第２のボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子を含むことができる。前記第２のボリュームは、前記第１のボリュームのＩＤと、前記第１のボリューム内のディレクトリおよび前記第１のボリュームの目標ディレクトリを参照しているｉ−ｎｏｄｅの数を特定する固有の数字（ｅ−番号）とで作られる組の間のファイル−ベースのマッピング表を実装する。前記第１のボリューム内の或るディレクトリの「．．」エントリが、第２のボリュームにおいてそれを指し示しているディレクトリへと帰着させなければならない場合、前記第２のボリュームのマッピング表を通じて参照操作が実行され、所望の参照が得られる。このファイル−ベースのマッピング表は、前記第２のボリュームと他のボリュームのリロケーション・ディレクトリ内のエントリとの間に新たな論理リンクが生成されるたびに、更新されなければならない。このマッピング表は、第２のボリュームを走査することによって排他的に再構成できる。
あるいは、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含むことができる。前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、通常は、前記第１のボリュームに、前記第２のボリューム内の前記論理参照を含んでいる前記ディレクトリへの参照を含んでいる別個のファイルを保存することを含んでいる。しかしながら、これは、保存された参照内のいずれかのディレクトリが移動またはリネームされたとき、論理参照の広範囲にわたる書き直しを必要とする。
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除すること；新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存すること；および、前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること、によって論理的にリロケートすることを含むことができる。通常は、前記論理参照が、前記第２のボリュームの前記ディレクトリから削除される。
さらにこの方法は、第３のボリュームによる前記ファイル・システム・オブジェクトの参照を、新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存すること；および、前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存すること、によって行なうことを含むことができる。
前記第１のボリュームと前記第２のボリュームとの間の論理リンクの生成は、通常は、前記第１のボリュームのリロケーション・ディレクトリに、前記ファイル・システム・オブジェクトへのハード・リンクを生成すること；および前記第２のボリュームのディレクトリに前記ハード・リンクへの論理リンクを生成すること、を含んでおり、前記ハード・リンクおよび前記論理リンクが、前記複数のクラスタ・ノードのクライアントからは見えない物理名前空間であって、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ハード・リンクを含むハード・リンクによってファイル・システム・オブジェクトに接続される固有の内部階層をそれぞれ備えている前記複数のボリュームを通じて実装された物理名前空間；および、前記複数のクラスタ・ノードのクライアントから見える論理名前空間であって、前記ボリュームを横断して全ファイル・システムにわたって広がり、かつハード・リンクと論理リンクとの間の相違が前記クライアントから隠されるようにハード・リンクおよび論理リンクを介して接続されたファイル・システム・オブジェクトで作られている論理名前空間、を形成している。
さらにこの方法は、前記ファイル・システム・オブジェクトへの書き込みの要求を前記第２のクラスタ・ノードによって受信すること；該要求を前記第１のクラスタ・ノードへと前記第２のクラスタ・ノードによって転送すること；および、前記第１のクラスタ・ノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと、を含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトへの書き込みの要求を前記第１のクラスタ・ノードによって受信すること；および、前記第１のクラスタ・ノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと、を含むことができる。
さらにこの方法は、第３のクラスタ・ノードによる前記ファイル・システム・オブジェクトの変更を、前記第３のクラスタ・ノードによって所有されている第３のボリュームへの変更済みファイル・システム・オブジェクトの保存を、前記第３のクラスタ・ノードに実行させること；および、前記第２のボリュームと前記第３のボリュームとの間の論理リンクを、該論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内にもたらすように生成すること、によって行なうことを含むことができる。
前記第１のボリュームと前記第２のボリュームとの間の論理リンクの生成は、前記論理リンクを生成するための要求を、前記第１のクラスタ・ノードによって前記第２のクラスタ・ノードへと送信すること；および、前記要求の受信をうけて、前記第２のクラスタ・ノードによって前記論理リンクを生成すること、を含むことができる。
前記第１のクラスタ・ノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることは、前記第２のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成するための要求を前記第１のクラスタ・ノードによって受信すること、を含むことができる。
前記第１のクラスタ・ノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることは、前記第２のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第２のクラスタ・ノードによって受信すること；および、前記第１のクラスタ・ノードに前記ファイル・システム・オブジェクトを生成すべきであることを、前記第２のクラスタ・ノードによって判断すること、を含むことができる。
さらにこの方法は、前記第２のクラスタ・ノードに、前記第１のボリュームに関連付けられた固有のボリューム識別子を含んでいる前記ファイル・システム・オブジェクトのためのファイル・ハンドルの生成を実行させること、を含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノード以外のクラスタ・ノードで受信すること；該要求を前記第２のクラスタ・ノードへと向けること；および、前記ファイル・システム・オブジェクトを前記第２のクラスタ・ノードによって削除すること、を含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノードによって受信すること；前記論理リンクの前記第２のクラスタ・ノードからの除去を生じさせること；前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のクラスタ・ノードによって前記第１のクラスタ・ノードへと送信すること；および、前記ファイル・システム・オブジェクトを前記第１のクラスタ・ノードによって削除すること、を含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のボリュームへと自動的にリロケートすることを含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから第３のクラスタ・ノードによって所有されている第３のボリュームへと、前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせること；前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を除去すること；前記第２のボリュームから、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への論理参照を除去すること；前記第２のボリュームと前記第３のボリュームとの間の新しい論理リンクを、該新しい論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための新しい論理識別子を前記第２のボリューム内にもたらすように生成すること；および、前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、によってリロケートすることを含むことができる。新しい論理識別子は、通常は、前記第３のボリュームのリロケーション・ディレクトリに保存される。さらに、この方法は、通常は、前記第３のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を、前記第２のボリュームのディレクトリに保存することを含んでいる。前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせることが、通常は、前記第１のボリュームから前記第３のボリュームへと、怠惰なコピー（ｌａｚｙ ｃｏｐｙ）技法を使用して前記ファイル・システム・オブジェクトをコピーすることを含んでいる。
さらにこの方法は、前記ファイル・システム・オブジェクトを前記第１のボリュームから前記第２のボリュームへと、前記第１のボリュームから前記第２のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせること；前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を取り除くこと；および、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への前記論理参照を、前記第２のボリュームから取り除くこと、によってリロケートすることを含むことができる。
さらにこの方法は、前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持すること；前記ファイル・システム・オブジェクトに関する前記データを、前記第１のクラスタ・ノードによって変更すること；および、前記少なくとも１つの別のクラスタ・ノードに、前記ファイル・システム・オブジェクトに関する前記データの無効化を実行させること、を含むことができる。さらにこの方法は、通常は、前記少なくとも１つの別のクラスタ・ノードに、前記ファイル・システム・オブジェクトに関する前記データの前記第１のボリュームからの再取得を実行させることを含んでいる。前記少なくとも１つの別のクラスタ・ノードに前記ファイル・システム・オブジェクトの一部分のコピーの無効化を実行させることが、通常は、前記ファイル・システム・オブジェクトに関するデータのコピーを有している他のクラスタ・ノードのリストを、前記第１のクラスタ・ノードによって保持すること；および、前記他のクラスタ・ノードのそれぞれに、前記ファイル・システム・オブジェクトに関する前記データが変更された旨の告知を送信すること、を含んでいる。前記ファイル・システム・オブジェクトに関するデータは、メタデータを含むことができ、その場合、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、前記メタデータを保存するためのメタデータ・キャッシュであって、ファイル・システム・オブジェクト・データのコピーを保存するために使用されるあらゆる他のキャッシュから独立して動作するメタデータ・キャッシュを、前記少なくとも１つの別のクラスタ・ノードによって保持することを含んでいる。さらに、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、前記少なくとも１つの別のクラスタ・ノードに、前記第１のクラスタ・ノードから前記ファイル・システム・オブジェクトに関するメタデータを読み出す前に、前記第１のクラスタ・ノードから読み取りロックを取得するよう要求することを含んでいる。前記ファイル・システム・オブジェクトに関するデータは、ファイル・システム・オブジェクト・データおよびメタデータを含むことができ、その場合、前記ファイル・システム・オブジェクトに関するデータのコピーを前記第１のクラスタ・ノードとは別の少なくとも１つのクラスタ・ノードによって保持することが、典型的には、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること；メタデータを保存するためのメタデータ・キャッシュを保持すること；および、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマッピングすること、を含んでいる。
前記ファイル・システム・オブジェクトを、それが前記第１のボリュームから第３のボリュームへとリロケートされたときに、リネームすることができる。
通常は、１つのクラスタ・ノードが、ファイル・システム・オブジェクトに影響する多ボリューム操作のためのコーディネータとして指定される。コーディネータは、通常は、前記多ボリューム操作に関係するボリュームのうちの１つのオーナである。
さらにこの方法は、各ボリュームについて、ファイル・システム・オブジェクトへの参照、およびボリュームから取り除かれて前記ファイル・システム・オブジェクトへの論理リンクまたは他の論理リンクで置き換えられた論理リンクを一時的に保存するためのローカル・ディレクトリを保持すること；および、対応するボリュームに影響する多ボリューム操作における故障からの回復のために、ローカル・ディレクトリを使用すること、を含むことができる。
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置が提供される。この装置は、固有のペアレント・ファイル・システム・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム；前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ；および、前記データ・ストレージ・ボリューム内にファイル・システム・オブジェクトを保存し、さらに当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照、および他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するためのオブジェクト・ストレージ・ロジック、を含んでいる。前記論理参照のそれぞれが、通常は、他のノードによって所有されているデータ・ストレージ・ボリュームに保存された対応するファイル・システム・オブジェクトにアクセスするための論理識別子を有し、前記ハード参照のそれぞれが、通常は、対応するペアレント・ノードによる対応するファイル・システム・オブジェクトへのアクセスのための論理識別子を有している。通常は、前記オブジェクト・ストレージ・ロジックが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、前記データ・ストレージ・ボリュームに前記ファイル・システム・オブジェクトを保存し、前記少なくとも１つのディレクトリに前記参照を保存する。このような操作を実行する過程において、前記オブジェクト・ストレージ・ロジックに前記種々のデータ・ストレージ・ボリュームのための書き込みロック・マネージャの役割を割り当てることができる。前記少なくとも１つのディレクトリが、通常は、前記ハード参照を保存するため、階層構造を有するリロケーション・ディレクトリを有している。通常は、前記オブジェクト・ストレージ・ロジックが、ハード参照のそれぞれについて前記論理識別子を、それら論理識別子のそれぞれが前記データ・ストレージ・ボリューム内において唯一であるように割り当てる。通常は、前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のファイル・システム・オブジェクトにすでに割り当てられた論理識別子のカウントにもとづいて固有の識別子を割り当てる。通常は、前記オブジェクト・ストレージ・ロジックが、前記ノードのいずれかによる前記データ・ストレージ・ボリュームの読み出しを実行可能にする。
この装置は、ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュを備えることができる。通常は、前記オブジェクト・ストレージ・ロジックが、他のノードによって所有されているデータ・ストレージ・ボリューム内のセクタを読み出すための要求を、前記セクタについて読み出しのみロックを有している第１の読み出し要求を前記他のノードへと発行し、前記セクタについて第２の読み出し要求を前記他のノードによって所有されている前記データ・ストレージ・ボリュームへと発行することによって処理する。通常は、前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のセクタについての読み出し要求であって、読み出しのみロックを有している読み出し要求を、前記セクタが前記ボリューム・キャッシュに保存されているか否かを判断すること；保存されていない場合に、前記読み出しのみロックを認可して前記要求を満足させること；保存されておりかつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントをキャッシュから送信すること；および、保存されておりかつ前記セクタが書き込みロックされている場合に、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開すること、によって処理する。通常は、前記オブジェクト・ストレージ・ロジックが、キャッシュ状態を追跡できるよう、前記読み出しのみロックの認可時に前記他のノードおよび前記セクタのアイデンティティを記録する。
通常は、論理参照のそれぞれが、他のノードのデータ・ストレージ・ボリュームのリロケーション・ディレクトリ内の対応するエントリを参照している。通常は、論理参照のそれぞれが、前記他のノードのデータ・ストレージ・ボリュームの前記リロケーション・ディレクトリ内の前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値を含んでいる。
通常は、前記オブジェクト・ストレージ・ロジックが、ディレクトリ（ファイルではなく）への論理参照のそれぞれについて、対応する仮想ペアレント・ノードへと戻る参照を保持する。前記対応する仮想ペアレント・ノードへと戻る参照は、前記仮想ペアレント・ノードが存在しているデータ・ストレージ・ボリュームに関連付けられたボリューム識別子を含むことができる。代案として、前記対応する仮想ペアレント・ノードへと戻る参照が、前記仮想ペアレント・ノードの前記データ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含むことができる。前記オブジェクト・ストレージ・ロジックは、前記対応する仮想ペアレント・ノードへと戻る参照を、論理的に参照されたファイル・システム・オブジェクトを実装するｉ−ｎｏｄｅ内に保存することができる。前記オブジェクト・ストレージ・ロジックは、＜参照されたボリュームＩＤ，参照されたｅ−番号＞の組と論理的に参照しているディレクトリのためのｉ−ｎｏｄｅ番号との間のマッピング表を、別個のファイル・システム・オブジェクトとして前記データ・ストレージ・ボリュームに保存することができる。マッピングは、参照しているボリュームの文脈において完全に実行され、ボリューム内の論理参照を走査し尽くすことにより、適当と認められるときに、外部アクセスへのいかなるアクセスも必要とせずにマッピング表を再構成することができる。
前記オブジェクト・ストレージ・ロジックは、新しいファイル・システム・オブジェクトを、新しいファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームに保存すること；前記新しいファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当てること；前記新しいファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること；および、前記新しいファイル・システム・オブジェクトへの論理参照を生成するため、他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームによって前記他のクラスタ・ノードに前記論理識別子を提供すること、によって生成できる。
前記オブジェクト・ストレージ・ロジックは、当該装置がオーナ・クラスタ・ノードであると考えられるボリュームから、外部のボリュームから参照されたファイル・システム・オブジェクトを、前記ファイル・システム・オブジェクトへのハード参照を前記少なくとも１つのディレクトリから削除することによって削除することができる。これは、前記ハード参照が当該ノードへの唯一の係属中のハード参照である場合、ファイル・システム・オブジェクトの実際の削除を生じさせることができる。前記オブジェクト・ストレージ・ロジックは、前記削除されたファイル・システム・オブジェクトへの論理参照を、前記対応する仮想ペアレント・ノードに削除させることができる。
前記オブジェクト・ストレージ・ロジックは、他のノードがペアレント・ノードであると考えられるファイル・システム・オブジェクトの削除を、削除されるファイル・システム・オブジェクトへの論理参照を前記少なくとも１つのディレクトリから削除することによって実行することができる。
通常は、前記オブジェクト・ストレージ・ロジックが、もはや前記データ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについてのハード参照を、例えば前記ハード参照を折々に調べてそれらが参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して、削除する。
通常は、前記オブジェクト・ストレージ・ロジックが、もはや他のノードのデータ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについての論理参照を、例えば前記論理参照を折々に調べてそれら参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを使用して、削除する。
前記オブジェクト・ストレージ・ロジックは、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトの他のノードへのリロケートを、前記ファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当てること；前記ファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること；および、前記ファイル・システム・オブジェクトへの論理参照を生成するため、前記他のノードによって所有されているデータ・ストレージ・ボリュームによって前記他のノードに前記論理識別子を提供すること、によって行なうことができる。
前記オブジェクト・ストレージ・ロジックは、他のノードのデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを、前記他のノードから論理識別子を入手すること；および、該論理識別子を含んでいる論理参照を前記少なくとも１つのディレクトリに保存すること、によってリロケートすることができる。
この装置は、通常は、他のノードに保存されたファイル・システム・オブジェクトに関するデータのコピーを保存するため、少なくとも１つのキャッシュを有しており、通常は、前記オブジェクト・ストレージ・ロジックが、特定のファイル・システム・オブジェクトが該ファイル・システム・オブジェクトが保存されているノードによって変更されたことを知ったときに、該ファイル・システム・オブジェクトに関するデータのコピーを無効化する。前記オブジェクト・ストレージ・ロジックが、通常は、前記ファイル・システム・オブジェクトに関するデータを再取得する。前記少なくとも１つのキャッシュは、ファイル・システム・オブジェクトに関連付けられたメタデータのコピーを保存するためのメタデータ・キャッシュを備えることができ、その場合、前記オブジェクト・ストレージ・ロジックが、前記メタデータ・キャッシュをファイル・システム・オブジェクト・データのコピーを保存するために使用される他のあらゆるキャッシュから独立して動作させることができ、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトに関するメタデータを読み出す前に読み取りロックを取得するよう他のノードに要求することができる。前記少なくとも１つのキャッシュは、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュおよびメタデータを保存するためのメタデータ・キャッシュを備えることができ、その場合、前記オブジェクト・ストレージ・ロジックが、通常は、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマップする。
通常は、前記オブジェクト・ストレージが、前記データ・ストレージ・ボリュームに保存された各ファイル・システム・オブジェクトについて、該ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを保持し、特定のファイル・システム・オブジェクトが変更されたときに前記他のノードのそれぞれに通知を行なう。
前記少なくとも１つのディレクトリが、通常は、ローカル・アンドゥ・ディレクトリを含んでおり、前記オブジェクト・ストレージ・ロジックが、ファイル・システム・オブジェクトへの参照、および論理参照で置き換えられた論理参照または他の論理参照を、前記ローカル・アンドゥ・ディレクトリに一時的に保存し、前記データ・ストレージ・ボリュームに影響する多ボリューム操作における故障からの回復のために、前記ローカル・アンドゥ・ディレクトリを使用する。
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置が提供される。この装置は、固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、当該装置のみが該データ・ストレージ・ボリュームへの書き込みを許されるよう、当該装置によって所有されているとみなされるデータ・ストレージ・ボリューム；前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ；ならびに、ファイル・システム・オブジェクトを複数のボリュームを横断して保持するための手段であって、他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するための手段；および当該装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を前記少なくとも１つのディレクトリに保存するための手段、を含んでいる手段、を備えている。
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトを生成するための手段を備えることができる。
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトを削除するための手段を備えることができる。
さらにこの装置は、１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするための手段を備えることができる。
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトをリネームするための手段を備えることができる。
さらにこの装置は、複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するための手段であって、他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうための手段；他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうための手段；当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するための手段；および、当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するための手段、を含んでいる手段を備えることができる。さらにこの装置は、他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするための手段、および、他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするための手段を備えることができる。
さらにこの装置は、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するための手段を備えることができる。
さらにこの装置は、複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段を備えることができる。
本発明の他の実施の形態においては、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタに関し、該ファイル・サーバ・クラスタのクラスタ・ノードを動作させるためのコンピュータ・プログラムを具現化してなるコンピュータで読み出し可能な媒体を有する装置が提供される。前記コンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを保持するためのプログラム・コード手段であって、前記クラスタ・ノードの少なくとも１つのディレクトリに、他のノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を保存するためのプログラム・コード手段；および、他のクラスタ・ノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するためのプログラム・コード手段、を含んでいるプログラム・コード手段を有している。
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを生成するためのプログラム・コード手段を有することができる。
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトを削除するためのプログラム・コード手段を有することができる。
さらにこのコンピュータ・プログラムは、１つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするためのプログラム・コード手段を有することができる。
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトをリネームするためのプログラム・コード手段を有することができる。
さらにこのコンピュータ・プログラムは、複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するためのプログラム・コード手段であって、他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうためのプログラム・コード手段；他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうためのプログラム・コード手段；当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するためのプログラム・コード手段；および、当該装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するためのプログラム・コード手段、を含んでいるプログラム・コード手段を有することができる。さらにこのコンピュータ・プログラムは、他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするためのプログラム・コード手段、および他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするためのプログラム・コード手段を有することができる。
さらにこのコンピュータ・プログラムは、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するためのプログラム・コード手段を有することができる。
さらにコンピュータ・プログラムは、複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段プログラム・コード手段を含むことができる。
本発明の他の実施の形態においては、ファイル・システム・オブジェクトに関するメタデータを、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、該ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタのクラスタ・ノードによって保持するための方法が提供される。この方法は、各ノードについて、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること；各ボリュームについて、メタデータを保存するための別個のメタデータ・キャッシュを保持すること；各ノードについて、他のノードから得たファイル・システム・オブジェクトを前記データ・キャッシュに保存すること；および、各ボリュームについて、他のノードから得たメタデータを前記メタデータ・キャッシュに保存すること、を含んでいる。
さらにこの方法は、前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータにマップすることを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、或るノードによって他のノードから、前記他のノードに保存されたメタデータを読み出すための読み取りロックを要求することによってファイル・システム・オブジェクトに関連付けられたメタデータを取得すること、および、前記読み取りロックが認可されたのちにのみ、前記他のノードからメタデータを読み出すことを含むことができる。前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することは、或るノードによって、該ノードが所有するファイル・システム・オブジェクトについての読み取りロックを有している他のあらゆるノードのリストを保持すること、および、該ノードによって前記ファイル・システム・オブジェクトに変更を、すべての読み取りロックを再取得させ、すべての読み取りロックが再取得されたのちにのみ前記ファイル・システム・オブジェクトを変更することによって加えることを含むことができる。
（特定の実施形態の詳細な説明）
１ はじめに
本発明の実施の形態は、ファイル・システム・クラスタリングのソリューションを提供する。ファイル・システム・クラスタの鍵となる構成要素には、クラスタを実現すべく相互接続され、受信したクライアントの要求の処理を実行する個々のサーバ（ノード）、および１つのエンティティとして管理される個々のファイル・システム・パーティション（ボリューム）が含まれる。
１．１ 用語の定義
本明細書および添付の図面において使用されるとき、以下の用語は、文脈上そのようでない場合を除き、以下に示す意味を有する。
ＣＤＭ 構成データベース・モジュール：複製された、クラスタ全体の、常時オンの構成データベース。
ＦＳＭ ファイル・システム・モジュール：ファイル・システムＡＰＩ群およびデータ構造の管理に充てられたモジュール。
ＦＳＯ ファイル・システム・オブジェクト：ファイル・システム内において個々に参照されうるあらゆるオブジェクト。
ＩＨＭ 相互接続ハードウェア・モジュール：保証なしおよび保証ありの両者のインオーダ・メッセージ配信を備える基本的なデータグラム機構をもたらすモジュール。
ＩＭＦ ノード間メッセージング・ファシリティ：保証ありのメッセージ配信およびハートビートの送信を提供する。
ＬＵＤ ローカル・アンドゥ・ディレクトリ：各ボリュームにて利用可能であって、クライアントからは見えない特別なディレクトリであり、新規スクイジー・リンク（下記参照）の生成によって置き換えられたファイル・システム・オブジェクトが、リカバリを容易にするため一時的に保存される。
ＭＭ メッセージング・モジュール：ユニキャスト／マルチキャストな同期／非同期のメッセージング・プリミティブおよびイベント・ハンドリングを提供する。
ＮＩＭ ネットワーク・インターフェイス・モジュール：ＴＣＰ／ＩＰフロントエンドのサポートを提供することによるネットワーク・インターフェイスの取り扱いに充てられたハードウェア・モジュール。
ＰＮ 物理ノード：クラスタ・コードを実行する物理的インフラストラクチャを提供するノードであって、仮想ノード（ＶＮ）アブストラクションをサポートするノード。ＰＮは、物理名および物理ＩＰアドレスを有している。ＰＮは、ＶＮへと「結び付け」られることによって、ＶＮに期待されるサービスを実行する。１つのＰＮを、複数のＶＮに結び付けることができる。
ＱＭ クォーラム・モジュール：クラスタ・クォーラム機構、ならびにクラスタ結合／分離機構を提供する。実際のクラスタ・メンバーシップ情報は、ＩＭＦ内に保持される。
ＲＤ リロケーション・ディレクトリ：すべてのボリューム中に存在し、クライアントからは隠されており、スクイジー・リンクを通じて参照されるＦＳＯを収容するために使用される特別なディレクトリ。
ＳＡＮ ストレージ・エリア・ネットワーク。
ＳＩＭ ストレージ・インターフェイス・モジュール：セクタ・キャッシュの管理およびＳＡＮバックエンドとのやり取りに充てられたハードウェア・モジュール。
ＳＬ スクイジー・リンク：ハード・リンクとして機能するが、ファイル・システム・ボリュームを横断して指定することができるリンク。
ＶＮ 仮想ノード：仮想ＩＰアドレス、仮想ノード名、いくつかのリソース（主にストレージ・ボリューム）、およびおそらくはサービスの集合を包含する論理抽象概念。ＶＮはそれぞれＰＮに関連付けられ、複数のＶＮを同じＰＮに関連付けることができる。
ＶＰＤ 仮想ペアレント・ディレクトリ：別のボリュームのディレクトリへのＳＬを収容しているディレクトリ。別のボリュームの物理的なペアレントではないが、ペアレント・ディレクトリとして振る舞わなければならない。
ＷＦＳ ＶＬＳＩファイル・システム：このモジュールは、ファイル・システム・サポート機能のＶＬＳＩ実装である。これは正確な頭文字ではなく、本来の頭文字ＶＦＳが、Ｕｎｉｘ（登録商標）システムのＶｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ ｌａｙｅｒとの混同を避けるためＷＦＳに変更されたものである。
「データ・ストレージ・システム」は、任意の適切な大データ記憶構成であって、これらに限られるわけではないが、１つ以上の磁気または光磁気あるいは光ディスク・ドライブ、半導体記憶装置、および磁気テープからなるアレイが含まれる。便宜上、データ・ストレージ・システムを、「ディスク」または「ハードディスク」と称することもある。
「ハードウェア実装サブシステム」は、主要なサブシステム機能がソフトウェア・プログラムの直接制御の外で動作する専用のハードウェアによって実行されるサブシステムを意味する。そのようなサブシステムが、ソフトウェア制御下のプロセッサとやり取りできるが、サブシステムそのものはソフトウェアによる直接制御下にはないことに注意すべきである。「主要な」機能とは、最も頻繁に使用される機能である。
「ハードウェア・アクセラレーテッド・サブシステム」は、主要なサブシステム機能が専用のプロセッサおよび専用のメモリ、ならびにこれらに加え（あるいはこれらに代えて）特殊目的のハードウェアを使用して実行されるサブシステムサブシステムを意味し、ここで専用のプロセッサおよびメモリは、あらゆる中央演算ユニット（ＣＰＵ）およびＣＰＵに関連するメモリと別個である。
「ＴＣＰ／ＩＰ」は、とりわけ、ｗｗｗ．ｉｅｔｆ．ｏｒｇのＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅのウェブサイトで規定されたプロトコルであり、このウェブサイトは、ここでの言及によって本明細書に組み込まれたものとする。「ＩＰ」はインターネット・プロトコルであり、同じ場所で規定されている。
「ファイル」は、データの論理的連関である。
プロトコル「ヘッダ」は、当該プロトコルのユーザに関連付けられたデータの伝送のために当該プロトコルによって指定されたフォーマットの情報である。
「ＳＣＳＩ関連」プロトコルには、ＳＣＳＩ、ＳＣＳＩ−２、ＳＣＳＩ−３、Ｗｉｄｅ ＳＣＳＩ、Ｆａｓｔ ＳＣＳＩ、Ｆａｓｔ Ｗｉｄｅ ＳＣＳＩ、Ｕｌｔｒａ ＳＣＳＩ、Ｕｌｔｒａ２ ＳＣＳＩ、Ｗｉｄｅ Ｕｌｔｒａ２ ＳＣＳＩ、または任意の同様なプロトコル、あるいは任意の後継のプロトコルが含まれる。ＳＣＳＩとは、「Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ」を指し、ｗｗｗ．ａｎｓｉ．ｏｒｇにウェブＵＲＬアドレスを有するＡｍｅｒｉｃａｎ Ｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ Ｉｎｓｔｉｔｕｔｅ（ＡＮＳＩ）によるコンピュータ周辺機器のパラレル接続のための規格である。
「第３層および第４層」と称する場合、ＩＳＯ規格であるＯｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ（「ＯＳＩ」）の７階層モデルにおける第３層および第４層を意味する。ＩＳＯ（国際標準化機構）は、ｗｗｗ．ｉｓｏ．ｃｈにウェブＵＲＬアドレスを有する。
「メタデータ」は、実際のファイル・コンテント・データに対し、ファイル・オーバヘッド情報を意味する。
「ファイル・コンテント・データ」は、ファイル・オーバヘッド情報を除くファイル・データを指す。
「書き込み」は、所与のストレージ・ボリュームにおいて、データのコンテントまたはメタデータを変更する操作を指す。
１．２ 参考文献
以下の参考文献は、そのすべてがここでの言及によって本明細書に組み込まれるものとするが、本明細書の全体を通じ、カッコ内の参照名を使用して引用される。
Figure 0004480153
Figure 0004480153
Figure 0004480153
 １．３ 典型的なファイル・サーバ・アーキテクチャ
本明細書に記載の主題に、本件出願と所有者が同一であって同一日に出願されたＧｅｏｆｆｒｅｙ Ｓ． Ｂａｒｒａｌｌ、Ｓｉｍｏｎ Ｌ． Ｂｅｎｈａｍ、Ｔｒｅｖｏｒ Ｅ． Ｗｉｌｌｉｓ、およびＣｈｒｉｓｔｏｐｈｅｒ Ｊ． Ａｓｔｏｎによる「Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｈａｒｄｗａｒｅ−Ｂａｓｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ」という名称の米国特許出願第１０／２８６，０１５号が関連し、この米国特許出願は、その全体がここでの言及によって本明細書に組み込まれたものとする。
図１は、本発明の種々の態様を適用することができるファイル・サーバの実施の形態のブロック図である。この種のファイル・サーバは、２００１年４月１９日公開の「Ａｐｐａｒａｔｕｓ Ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｈａｒｄｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｒ Ａｃｃｅｌｅｒａｔｉｏｎ ｏｆ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｆｕｎｃｔｉｏｎｓ」という名称のＰＣＴ出願公開番号ＷＯ０１／３８１７９ Ａ２に記載されており、この文献は、本件発明の共同発明者がやはり共同発明者である発明を記載しており、個々での言及によって本明細書に組み込まれたものとする。この図１は、前記ＰＣＴ出願の図３におおむね相当するものである。ここで、図１のファイル・サーバ１２は、ネットワーク１１と通信するサービス・モジュール１３を含むいくつかの構成要素を有している。サービス・モジュール１３は、ネットワークを介してサービス要求を受信してこれに応答し、ストレージ・アクセスに関するサービス要求を関連のファイル・システム・プロトコルにとって適切なフォーマットへと変換する（さらに、そのようなフォーマットを、そのような要求への応答を生成すべく変換する）ファイル・システム・モジュール１４と通信する。次いで、ファイル・システム・モジュール１４が、ストレージ・モジュール１５と通信し、ストレージ・モジュール１５が、ファイル・システム・モジュール１４の出力を、ストレージ・モジュール１５が通信するストレージ・システムへのアクセスを許容するフォーマットへと変換する。ストレージ・モジュールは、ストレージから読み出され、あるいはストレージへと書き込まれるファイル・コンテント・データのためのキャッシュを有している。前記ＰＣＴ出願に記載のとおり、種々のモジュールのそれぞれを、ハードウェアに実装することができ、ハードウェア・アクセラレーテッドとすることができる。
図２は、図１の実施の形態の実装例のブロック図である。この実装例においては、図１のサービス・モジュール１３、ファイル・システム・モジュール１４、およびストレージ・モジュール１５が、それぞれネットワーク・インターフェイス・ボード２１、ファイル・システム・ボード２２、およびストレージ・インターフェイス・ボード２３によって実装されている。ストレージ・インターフェイス・ボード２３が、この実施の形態において使用するストレージ・システムを構成しているストレージ装置２４と通信する。この実装例に関するさらなる詳細は、２００１年６月１２日出願の「Ａｐｐａｒａｔｕｓ Ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｈａｒｄｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｒ Ａｃｃｅｌｅｒａｔｉｏｎ ｏｆ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｆｕｎｃｔｉｏｎｓ」という名称の米国特許出願第０９／８７９，７９８号に記載されており、この米国特許出願は、ここでの言及によって本明細書に組み込まれたものとする。
１．４ クラスタの種類
一般的に言って、以下の２種類のクラスタが存在する。
１．Ｎ＋１ ＨＡ（フェイルオーバ）クラスタ。これらの種類のクラスタにおいては、アプリケーションまたはサービス（ＮＡＳヘッドなどの特殊目的の装置に適用されるとき、用語「アプリケーション」は、以下では「サービス」の同義語として使用される）は、１つのノードにおいて「アクティブ」モードで実行され、他のノードにおいて「スタンバイ」モードで実行される傾向にある。この種類のクラスタは、可用性を提供するが、拡張性は提供しない（可用性と拡張性の間に明確な区別が常に存在するわけではないが）。
２．パラレル・クラスタ。これらの種類のクラスタにおいては、アプリケーションまたはサービスが、２つ以上のクラスタ・ノードに分散されたやり方で実行される。これは、可用性と拡張性の両者をもたらす。
以下に説明する典型的なファイル・システム・クラスタリングのソリューションは、パラレル・クラスタ・モデルにもとづいており、クラスタ・ノードの数（限界内）に関して性能を向上させ、クラスタの１つ以上のメンバーにおいて生じうるクラッシュにかかわらずファイル・システム・オブジェクト（ＦＳＯ）がアクセス可能に保たれるよう、高度に可用（ＨＡ）であると期待される。一方で、以下に説明する典型的なファイル・システム・クラスタリングのソリューションは、アプリケーションを実行できる汎用目的のコンピュータ・クラスタを提供するものとも、フォルト・トレラントなプラットフォームを提供するものとも予想されない。これらの条件は、本発明の特定の実施の形態に課された要件を表わしており、本発明そのものを限定するものではない。
１．５ 論点
以下で検討する主たる論点は、以下のとおりである。
・ここに提案するクラスタリングのソリューションによってもたらされる可能性を、限界および固有の制約のリスト、ならびに性能および可用性の両者に関する期待値とともに示すこと。
・このソリューションによって解決すべき重要な技術的課題、すなわち
どのクラスタ・ノードがクラスタ化されたファイル・システムのどの構成要素を管理するのか、およびクラスタ化されたグローバル名空間がどのように統合されるのか、
さまざまな種類の要求（読み出しアクセス、変更）が、性能向上のためクラスタにおいていかに取り扱われるのか、
故障を診断して高い可用性を提供するため、クラスタ・ノードの監視がどのように実行されるのか、
故障ノードの発生によってストレージ・ボリュームの引き継ぎがどのように管理されるのか、
クラスタがどのように管理および構成されるのか、および
典型的な実装のためのさまざまな構成要素。
以下に続くセクションにおいて、本発明の典型的な実施の形態をさらに詳細に説明する。セクション２は、ソリューションの要件および潜在的境界に向けられている。セクション３は、詳細なソリューションを概括する。セクション４は、種々の実装上の問題に向けられている。セクション５は、多ボリューム操作のフォーマル・フォルト分析を示している。
２ 要件および全体のアーキテクチャ
このセクションは、要件をより詳細に概括する。さらに、基本的なアーキテクチャ上の選択肢、ならびに解決すべき鍵となる技術的課題のいくつかを概括する、
２．１ 要件
先の検討にもとづき、このアーキテクチャが満足すべき要件は、以下のとおりである。
１．ここに記載するソリューションは、セクション１．３においてすでに述べた種類の特定のファイル・サーバを目標としているが、本発明がそれに限られるわけではまったくなく、ここで検討するさまざまな要素が、広くファイル・サーバ・クラスタ一般に適用可能であることは明らかである。
２．クラスタ化ソリューションにおいて達成可能な統合化性能は、クラスタの部分であるノードの数に関して擬線形の拡大が生じるようなものである。しかしながら、クラスタ化できるノードの最大数は限られているため、このソリューションの目的が、拘束のない拡張性にあるわけではないことに注意すべきである。
３．クラスタ化の仕組みが、高度な拡張性をもたらす。これは、クラスタによって管理される論理ボリューム内のあらゆるＦＳＯのアクセシビリティを含むべきである。そのようなシステムにおいて可用性は、０．９９９９９以上でなければならない（「ファイブ・ナイン」基準と称されることがある）。これは、クラスタ・ノードの故障の検出およびその後の回復を、不稼働時間を１年間につき約５分に押さえることによって実行することを必要とする。
４．高可用性要件の間接的結果として、クラスタ・ノードを動的にクラスタに結合でき、クラスタから分離できるべきである。これは、ノードの故障および回復のためにとくに重要であるが、広くより柔軟な環境を提供するためにも使用することができる。
５．クラスタ・ノードのそれぞれを個々に構成するのと対照的に、ユニットとしてのクラスタ全体の管理および構成が可能であるべきである。
６．クラスタが提供するであろうファイル・システム・イメージは、１つのツリーからなり、クライアントが接続するクラスタ・ノードにかかわらず均一である。
７．実装のコスト／労苦、ならびに全体の複雑さが、ファイル・システム・クラスタリングのソリューションを計画する際に考慮される。
２．２ 全体アーキテクチャの選択肢
以下では、適切な機構（フロントエンド・スイッチ、またはクラスタ・ノードへのクライアントの静的なパーティショニングなど）が、クラスタ・ノードとネットワークとの間に介装されるものと仮定する（これは論理的観点であり、実際においてスイッチが使用される場合、高可用性の要件を満足するために二重化されることが通常である）。その目的は、クラスタ・ノード間の負荷をバランスさせることにある。これについては、セクション３でより詳しく検討する。
さらに、あらゆるクラスタ・ノードは、論理ボリュームの集合を通じて得られたファイル・システムを１つのエンティティとして眺めるものと仮定される（前記要件６を参照）。
２．２．１ 考えられる代案
Ｍｉｃｒｏｓｏｆｔ Ｃｌｕｓｔｅｒｉｎｇ ｐｒｏｄｕｃｔに実装されるような「無共有」の性質のクラスタリング・ソリューションは、ストレージの相互に排他的なサブセットを管理するクラスタ・ノードを設けることによって、高可用性（ＨＡ）の要件をサポートできる。サーバの１つがクラッシュした場合にのみ、他のサーバが、クラッシュのためにもはや可用でないストレージ・ボリュームの取り扱いを引き継ぐ。当然ながら、これにより設計が簡潔に保たれ、可用性が増す。
この仕組みは、同じストレージ・ボリュームに対する同時多発アクセスの場合において、それらがすべて同じくラスタ・ノードを通って送られなければならず、ボトルネックとなりかねないことを意味している。したがって、この仕組みは、別個のサーバが使用されてそれぞれが自身のストレージ・ボリュームを取り扱っている状況に対し、性能という点でなんら向上をもたらさない。
一方で、この形式のアーキテクチャは、故障引き継ぎの能力を提供し、高可用性（ＨＡ）のソリューションを実現する。しかしながら、ファイル・システム・クラスタリングのソリューションの鍵となる焦点は、性能に関して当該ソリューションの拡張性の向上にあり、このアプローチは、本発明の実施の形態にとくによく適しているというわけではない。
それとは正反対に、完全に共有されたボリューム・オーナシップを備える分散ファイル・システムにもとづくクラスタリングの仕組みを考えることも可能である。これは、あらゆるクラスタ・メンバーが、いかなる静的または半静的なオーナーシップの割り当て政策もなく、一度に各ＦＳＯについて機能できることを意味する。これを行なうべく、いくつかのアーキテクチャが考え出されている。しかしながら、それらのソリューションの多く（参考文献［Ｔｈｅｋｋａｔｈ １９９７］および［Ｐｒｅｓｌａｎ １９９９］）は、頑丈かつ複雑であり、開発、デバッグ、および展開が困難な複雑な分散ロッキング・プロトコルにもとづいている。
要件７ゆえ、この文献では、クライアント・アプリケーションおよびエンドユーザによって知覚されたとき、開発コスト／複雑さと達成可能な利益との間の妥当なバランスをもたらす仕組みを説明する。
２．２．２ ＤｉＦＦＳ
ここに記載するソリューションは、ＤｉＦＦＳアーキテクチャ（参考文献［Ｋａｒａｍａｎｏｌｉｓ ２００１］）に大まかにもとづいている。ＤｉＦＦＳの提案は、以下のコンセプトを実装するアーキテクチャを考案することによって、分散ロッキングおよびキャッシュの一貫性に関する問題を大幅に簡略化する。
１．ただ１つのアクティブ・クラスタ・ノードが、ファイル・システム論理ボリュームの変更を担当する。以下では、このノードを「ボリューム・オーナ」と称する。
２．複数のクラスタ・ノードがすべてのＦＳＯへの読み出しアクセスを有し、ＳＡＮバックエンドにアクセスすることによってクライアントからの読み出し要求に直接仕えることができる。
３．クラスタ内のコヒーレンシをサポートするため、ストリームライン化されたノード間プロトコルが利用可能である。
４．ＦＳＯ参照（ディレクトリ・リンク）が、論理ボリュームにまたがることができる。
５．ＦＳＯリロケーションが利用可能であり、実際、よりよい拡張性を達成するため、ＦＳＯをホスト・スポットから直接リロケートするために使用される。
６．ファイル・システム操作における順序付けが、生じうるファイル・システム不整合を、非同期ごみ収集によって定期的に除かれる「オーファン」ファイル（すなわち、ディスク・スペースを使用しているが、あらゆるディレクトリ参照が除去されたためもはやアクセスできないファイル）にのみ相当するようにする。関連プロトコルの完全な仕様が利用可能である。
ＤｉＦＦＳに埋め込まれたコンセプトは、これらだけではない。しかしながら、これらは以下の検討に最も関係があり、なぜならば、このアーキテクチャが最初の４つに依存し、程度はより少ないが、最後の２つにも依存しているからである。
以下では、用語「読み出し」を、更新を伴わないＦＳＯへのアクセスを意味しておおまかに使用する。例は、ファイル読み出し、ディレクトリ・サーチ、およびファイル属性またはオーナーシップ情報の要求である。同様に、用語「書き込み」を、オブジェクトのあらゆる修正を意味して使用する。これには、ファイルの書き込み、新規オブジェクトの作成および削除、属性の変更などが当てはまる。
２．２．３ 基本的な仮定
このアーキテクチャは、完全に自己完結のボリュームを想定している。これは、論理ボリューム間のいかなる物理的な相互参照（Ｕｎｉｘ（登録商標）の「ハード・リンク」など）も存在しないことを意味する。換言すると、ボリューム内の各ファイル・システム・ツリーが、自身の外の物理ポインタを有していない。物理的に自己完結である論理ボリュームを有することで、モデルが簡潔になり、完全性チェックがより簡単になり、効率的な実装に好適である。これに加え、より良好な故障の隔離（高度に可用なプラットフォームのための鍵となる属性である）がもたらされる。
これの明らかにマイナスな結果は、以下のとおりである。
・１つの論理ボリューム内のファイル・システムから異なるボリューム内に実装されたＦＳＯへの参照が存在しない可能性がある。
・異なるボリュームのＦＳＯのいくつかを割り当てることによって１つのボリューム内のツリーを広げることが、できないと思われる。
しかしながら、一見に反し、これらの結果は以下の理由からいずれも真実ではない。
・あとで示されるように、ハード・リンクのシンボリックかつ特別な変種を、ボリュームを横断する論理リンクの存在が期待されるあらゆる場所で使用できる。後者は、実際、ＮＡＳクライアントの利益のためのボリュームを横断するハード・リンクのセマンティクスの実装である。シンボリックなリンクおよび特別なハード・リンクのセマンティクスは、ボリューム横断の参照が、ファイル・システム完全性ルールに影響しないようなものである。
・あとで示されるように、ここのボリュームの空間的限界が、実際には、単に他のボリューム内に新しいファイル・システム・オブジェクトを割り当てるだけで克服できる。
このアーキテクチャが、複数のボリュームを横断する１つのファイル・システム・イメージ（図３参照）をサポートしており、ただいま説明した問題ゆえ、このクラスタリングの仕組みが１つの巨大ボリュームを実装しないが、そのような仕組みのすべての有用な属性を保持していると思われる点に注目すべきである。
実際上の多くの場合において、各クラスタ・ノードが、グローバル・ファイル・システムを実装するボリュームの少なくとも１つを管理すると仮定される。したがって、ボリュームの典型的な最小数は、クラスタ・ノードの数に等しい。しかしながら、これがこのアーキテクチャの厳格な要件ではなく、クラスタ・ノードの数がクラスタ化ファイル・システムを構成するボリュームの数よりも多くても、等しくても、あるいは少なくてもよいことに注意すべきである。
ＤｉＦＦＳの基準１にもとづき、個々のボリュームは、１つのクラスタ・ノードに所有される。そのようなオーナ・ノードは、当該ボリュームのコンテントの修正が許されているただ１つのノードである。一方で、基準２にもとづき、すべてのノードが、読み出しのみのモードであらゆるボリュームへのアクセスを許されている。これは、或るボリュームへのすべての読み出しアクセスを並行して実行できる一方で、或るボリュームのあらゆる修正は、そのオーナ・ノードを通過しなければならないことを意味している。
上記に加え、このアーキテクチャは、所与のＦＳＯを参照するために使用される論理パス名を、ＦＳＯが物理的に存在している実際の場所から分離させる。あとで示されるように、この能力のため、クラスタ・アーキテクチャは高いスループットを提供できる。
上記の選択は、いくつかの関連する影響を含んでいる。所与の論理ボリュームについてのすべての修正要求を当該ボリュームのオーナに集中させることによって、これが潜在的にボトルネックとなりうることが明らかである。もたらされる明白な利点は、プロトコルのストリームライン化および複雑さの低減である。しかしながら、これが性能に与えるであろう影響の大きさを評価するにあたって、トラフィックの大部分が実際のところ読み出し操作からなると予想することが、確かに適切である。これは、以下の理由から、さらに確認されなければならない。
１．クライアント側に実装されたキャッシュが、クライアント側のキャッシュからの読み出し要求を満足させることができる。これは、実際、書き込みの味方をして、読み出しと書き込みの実際のアンバランスを減らす傾向にある。
２．読み出しは同期的であって、書き込みは多くの場合非同期である。したがって、あらゆるクラスタ・ノードは読み出しを直接制御でき、良好な応答時間が期待できる。
３．読み出し操作は、アクセスされるＦＳＯを表わしているｉ−ｎｏｄｅについてのアクセス時間が更新されなければならないという副作用を有している。ｉ−ｎｏｄｅは、Ｗｉｎｄｏｗｓ（登録商標） ＮＴにおいてファイル・レコードと等価であり、それが記載するファイル・システム・オブジェクトについてのメタデータデータ情報を保存するファイル・システム・データ構造である。この副作用は、実際、あらゆる読み出し操作を、論理ボリュームのオーナによって取り扱われなければならない書込み操作に変化させる。これは、事実上すべての読み出しアクセスを書き込みアクセスに変換し、この仕組みを深刻なボトルネックに変えるため、きわめて不都合である。
しかしながら、解決手段は、ｉ−ｎｏｄｅアクセス時間の更新におけるより厳しくない基準、およびボリューム・オーナに対する軽量かつ非同期の呼び出しの使用に依存している。これは、アクセス時間が「セッション・セマンティクス」を呈するやり方で実行できる（参考文献［Ｌｅｖｙ １９９０］）。
ａ．ローカル・キャッシュ内のｉ−ｎｏｄｅのコピーのアクセス時間は、それを無効にすることなく修正できる。
ｂ．次いで、同じことを実施してｉ−ｎｏｄｅをダーティとしてマークするよう、（フラッシュを要求することなく）ボリューム・オーナに通知が送信される。
ｃ．ｉ−ｎｏｄｅのマスタ・コピーが変更を蓄積し、適切なときにフラッシュされ、クラスタにわたるすべてのキャッシュ・コピーを無効にする。
３ クラスタリングの仕組み
先のセクションにおいて概括した問題が、少なくとも検討のための全体的枠組みを提供する。しかしながら、それらは単に、詳細に分析すべき問題の表面を引っ掻くのみである。
このアーキテクチャにおいて、根底にある仮定は以下のものである。
１．クラスタのクライアントをクラスタ・ノード間でパーティションするために、適切な負荷バランス機構が利用できるものと仮定される。この機能は、スイッチによって実装され、パーティション化はユーザのアイデンティティに関して行なわれる（さらには、これに先んじて）。負荷バランスについては、セクション４．１でさらに説明する。
２．クラスタ間の高速相互接続が利用可能である。これは、クラスタ内キャッシュのコヒーレンシおよび複製をサポートし、操作要求をリレーして他のクラスタ・ノードへと応答を届けるために使用される。このクラスタ内相互接続については、セクション４．２でさらに説明する。
３．高可用性モジュールが、システムの冗長性の保証およびその連続動作を担当する。
以下のサブセクションで、このアーキテクチャをより詳細に説明する。
３．１ アーキテクチャ
アーキテクチャの詳細な説明には、キャッシングおよびロッキングのファイル・システム名前空間の構造の説明が必要である。
３．１．１ 名前空間
本明細書の残りを読んだのちに明らかになるとおり、ここで定めるアーキテクチャは、１つのボリュームが全ファイル・システムのルートとして機能できるようにする。他のすべてのディレクトリおよびファイルは、他のボリューム内に割り当てることができるが、そのようなルートで始まるパス名によって参照される。これは、このアーキテクチャのクライアントの典型的ニーズにとって、的確、簡潔、かつ適切である。
クラスタが構成されたのち、そこにそれまでは独立であるクラスタ（それまではスタンドアロンであるユニット）を加えたいと望む場合、最終的な結果は、新しいクラスタ・ルートにもとづかなければならないため、加えられるノード／クラスタのすべてのパス名を変更しなければならないというものである。しかしながら、共有、エクスポートされたマウント点、およびボリューム間リンクは、これを避けることができる。
クラスタ内の各ボリュームは、「ボリュームＩＤ」と呼ばれる固有の数値ＩＤによって特定されなければならない。この固有のＩＤは、決して再使用されてはならない。
ボリュームをグローバル・ファイル・システム・ヒエラルキを通じてアクセス可能にする行為は、「マウント」として知られている。
個々のボリュームについてのマウント順序は、それらがマウントされる順序に関してインデックス番号（「マウント・インデックス）が各ボリュームに割り当てられるという点にのみ関係がある。このインデックスは、ボリュームのマウントが解除されるまで有効あり、ボリューム間の総順序の関係を実装するために使用される。これは、循環性を取り除いて、生じうるデッドロックを防止するため、マウント・インデックス値を増加させることによって異なるボリュームに位置する複数のＦＳＯをロックする必要がある場合に有用であろう。
論理ボリュームは自己完結であり、論理ボリューム間に物理的な相互参照が存在する必要がないことを意味する。換言すれば、グローバル・ルート・ボリュームが、クラスタによってサポートされる森のすべてのツリーを一括して扱ってもよく、一括して扱わなくてもよいが、各ツリーは自身の外のポインタを有していない。シンボリック・リンク（および、下記にて紹介する「スクイジー・リンク」）が、ボリュームの外部のＦＳＯを指定する能力を実現することに注意すべきである。しかしながら、これは物理的ストレージという点では行なわれず、むしろシンボリック参照という点で行なわれる。したがって、そのようなポインタは、適切なコンテクストでの解釈の対象であり、ボリュームを自己完結に保つという基準に違反しない（これは、ＤｉＦＦＳに実装される仕組みからの大きな逸脱である）。論理ボリュームを完全に自己完結にするというこの属性は、モデルを簡単にし、完全性のチェックを単純にし、効率的な実装に適している。
したがって、論理ボリュームが自己完結であるという事実にもかかわらず、ボリューム間参照が、シンボリック・リンクおよび「スクイジー・リンク」と呼ばれるハード・リンクの変種の形で利用可能である。後者は、ＮＡＳクライアントのためのボリュームを横断するハード・リンク・セマンティクスを完全に実装する。これらは、以下のサブセクション３．１．２．１で定義される。
以上の理由で、このクラスタリングの仕組みは、複数のボリュームを横断する１つのファイル・システム・イメージ・セマンティクスの実装を可能にする。図１に示したような論理ヒエラルキが、マウントされたボリュームの純粋なネスティングの能力を超えておりながら、それらが好都合にここに記載のアーキテクチャの届く範囲内であることに注意すべきである。例えば、ファイル「Ｃ」および「ｙ」が、同じボリュームの一部でありながら、共通のサブツリーの一部ではない。
３．１．２ ローカルおよび外部参照
ここに記載するような設計は、各論理ボリュームのための「ボリューム・オーナ」の役割を、半静的なやり方（すなわち、ノードがクラスタに加わったときから、シャットダウンまたはクラッシュなど、いかなる理由にせよ当該ノードがクラスタを離れるときまで）でただ１つのクラスタ・ノードに割り当てるため、論理ボリューム更新の管理の問題を簡単にする。同時に、それはクラスタ・ノードを横断する相互に排他的ではないキャッシュを必要とする。これは、ただ１つのノードが論理ボリューム・オーナであるとしても、複数のノードが読み出しのために１つのボリュームに同時にアクセスしうるためである。したがって、結果として生じる主要な問題は、ＳＡＮバックエンドを通じて読み込まれ、読み出しのみのアクセスを供えるノードにキャッシュされたデータが、論理ボリューム・オーナによって実行される修正に関して古くならないようにすることにある。これは、キャッシングおよびロッキングについてのセクションで詳細に取り扱われる。
クライアントから入ってくるリクエストが処理されるときは常に、「ローカル」参照と「外部」参照とを区別する必要がある。ローカル参照は、論理ボリュームをアドレスしたＩ／Ｏ要求であって、当該ボリュームのオーナが当該要求の受領者である。外部参照は、論理ボリュームをアドレスした要求であって、要求の受領者が当該ボリュームのオーナではない。
これら要求の初期において、コードが２つの場合の間で区別されなければならない。さらに、外部要求は、それらが読み出し形式のものであるか、書き込み形式のものであるかに応じて弁別されなければならない。以下が、それぞれの場合において取られる行為の概要である。
・ローカル読み出しおよび書き込みについて、要求を直接実行する。
・外部読み出しについて、要求を直接実行する。
・外部書き込みについて、要求をボリューム・オーナに向け直す。
この設計の負の特徴は、以下のものである。
・作業負荷において１つのボリュームへの外部書き込みが支配的であるとき、ボリューム・オーナがボトルネックとなりうるため、うまく拡張されない。このような何かが生じうる考えられるユーザ側のシナリオは、以下のものである。
多数のクライアントが、同じボリューム内において「書き込み」操作についてきわめて活動的である場合。
同じボリューム内の多くのファイルが、異なるクライアントによって多重的に編集される場合。
・ＳＩＭ（ストレージ・インターフェイス・モジュール−ＳＡＮバックエンドおよびホストとセクタ・キャッシュをやり取りするシステム・ボード）キャッシュのコンテントが、同じセクタにアクセスしているすべてのノードにわたって複製される。これは、統合クラスタ・キャッシュの全体的な効率をいくらか制限する。この負の属性がこの設計に存在するが、これは多くのクラスタ設計に共通である。
正の側面は、以下のとおりである。
・読み出し操作が、要求に関連するボリュームにかかわらずクラスタ・ノードを横断して並列に効率的に取り扱われる。
・ファイル・システム内の実際の書き込み操作は、ボリューム・オーナによって実行されなければならないが、プロトコル処理の大部分は要求を受信するノード内で実行される。これが、ボリューム・オーナの負荷を制限する。
・ボリュームのオーナがボリューム・コンテントの更新を許されている唯一のノードであるというルールが、分散された設計にもとづく必要がないため、ファイル・システム・アーキテクチャを大幅に簡略化する。これが、関連の開発コストおよびリスクを少なくする。
しかしながら、ＦＳＯパス名の概念をその場所（すなわち、ＦＳＯが位置するボリューム）から分離させることにより、この設計の拡張性を向上させることが可能である。これは、すでに述べた「スクイジー・リンク」によって実行できる。
３．１．２．１ スクイジー・リンク
スクイジー・リンク（以下では、ＳＬ）は、シンボリック・リンクとハード・リンクの間の混成である。それは、異なるボリュームに保存されたＦＳＯへのシンボリック参照を提供する。
ＳＬは、常に、各ボリューム内で利用可能な既知のディレクトリ（「リロケーション・ディレクトリ」、以下では、ＲＤ）に保存されたＦＳＯを参照する。このディレクトリは、ＮＡＳクライアントからは隠されている。ＲＤ内のすべてのＦＳＯは、１６進値を符号化する名前を有し、「リロケーテッドＦＳＯ」と呼ばれる。そのような値が、新しいＲＤエントリが生成されたときに自動的に生成され、単調に増加すべきである点に注意すべきである。この値が、６４ビット・アドレス空間にマップされる。値０は、ヌルとして使用される。
ＳＬは、ディレクトリ・エントリをボリュームＩＤを含むべく拡張することによって実装できる。したがって、「通常の」ディレクトリ・エントリ（ハード・リンク）は、ボリューム内のどこかのローカルＦＳＯを指し、ローカル・ボリュームＩＤおよびローカルｉ−ｎｏｄｅ番号（すなわち、「ｉ−番号」）を含んでいる。一方、ＳＬは、異なるボリュームＩＤを指し、ｉ−番号は、目標ボリュームのＲＤ内の参照されるＦＳＯの名前を表わしている数字列を符号化する数値によって置き換えられている。以下では、この数値ＩＤを「外部番号」または「ｅ−番号」と呼ぶ。したがって、ＳＬはシンボリックな形式であり、別個のｉ−ｎｏｄｅの割り当てを回避している。シンボリック参照を含むことによって、ＳＬはそれらが指し示すボリュームの詳細の物理的知識を有さない。別個のｉ−ｎｏｄｅの割り当てを回避することで、ストレージが節約され、より効率的である。
このアプローチを使用することで、ＳＬは以下の属性を有することになる。
・ファイルまたはディレクトリを参照するために使用できる（シンボリック・リンクが行なうように）。
・クライアント側において、ハード・リンクと弁別不可能である。
・シンボリック情報のみを埋め込んでいる。したがって、目標ボリュームの明白な内部知識を有しておらず、ボリュームが自己完結であるという制約に違反しない。例えば、ＦＳＯをサポートするｉ−ｎｏｄｅの知識が存在せず、したがって任意の時点においてｉ−ｎｏｄｅが変化しても、ＲＤ内のＦＳＯの名前が同じままである限り、ＳＬには影響がない。
・リロケーテッドＦＳＯを指しているＳＬは、ＦＳＯについてのリンク・カウントを増加させない。この点のもとで、ハード・リンクのみがカウントされ、それらはボリュームに対し常にローカルである。したがって、やはりボリュームの完全性は、外部で生じる何物にも影響されない。
・あらゆるファイルを、ハード・リンク（ローカルに）およびＳＬ（ＲＤに設定された適切なハード・リンクを通じて）の両者によって参照できる。
・ＲＤ内の各リンクが、それを指す正確に１つのＳＬを有する（所与のリロケーテッド・ファイルは、ＲＤ内に複数のハード・リンクを有することができるが、そのようなハード・リンクのそれぞれは、ただ１つのＳＬによってのみ指定されることができる）。これは、ＦＳＯについてのリンク・カウントの完全性を、複数のボリュームを横断する完全性制約を生成する必要なく保つために必要である。
・クライアントがＳＬを削除するとき、これはそれが位置するディレクトリからのＳＬエントリの削除、およびそれが参照するＦＳＯの名前の削除の両者を生じさせるべきである。これは、もたらされるＦＳＯ参照カウントに応じ、ＦＳＯそのものの削除を含んでもよく、含まなくてもよい。
・ＳＬをダングリング（ｄａｎｇｌｉｎｇ）なままにすべきではない。ダングリングなＳＬは、ＦＳＯの削除と参照しているＳＬの削除の時間の間にクラッシュが生じた場合に、一時的に生じる（ＳＬが、リンクが存在しているそれではないボリューム上のＦＳＯを参照するという事実のため）可能性があり、ダングリングなリンクは害を生じることはないが、クライアントに見えないままに残り、すでに述べたように扱われる場合、検出されると即座に除去される。シンボリック・リンクと同様、ＳＬは、実際には、存在しないオブジェクトを指しうる。これは、例えばＳＬが参照するボリュームがマウントされる前など、一時的な基準で生じうる。恒久的にダングリングなリンク（ボリュームにはアクセスできるが、葉にはアクセスできない）を検出したノードは、ＳＬを除くことによって対処すべきである。
・ボリューム間の「関心の分離」は、以下をサポートする。
ボリュームの完全性および一貫性の執行が、はるかに容易であり、システム完全性チェッカを、異なるボリュームにわたって並列に実行できる。
故障の隔離がはるかに良好であり、ボリュームの致命的な故障によって、ファイル・システム全体が停止することがない。故障したボリュームのファイルおよびディレクトリがアクセス不可能になるだけである。
ＳＬの使用は、１つ以上のクラスタ・ノードを、ディレクトリ情報のための純粋なメタデータ・サーバとして使用できるようにする。これは、或るアプリケーション・シナリオにおいて意味があり、ディレクトリ・ヒエラルキのみを取り扱うべき１つまたは複数のノードにユーザ接続を割り当てないことによって得ることができる。
ＳＬによって、パス名を実際のＦＳＯ位置から分離させることができる。このため、ノード障害の結果として、ＳＬが他のボリューム上の固有のＦＳＯを指すか、あるいはＲＤに生成されたＦＳＯが、もはやＳＬによって参照されないことによって実際に親なしであるかのいずれかが生じうる。これらが、いくらかのストレージ空間の一時的な浪費を生じさせるが、ボリュームそのものの完全性を損なうことがない点で、致命的な故障ではないことに注意すべきである。したがって、それらは故障後のボリュームの再マウントを妨げない。同時に、そのような生じうる不整合を除くことが望まれる。これは、ダングリングな参照がファイル・システムによって検知されるため、オンザフライで行なうことができる。
これに加え、特別な清掃プロセスが、そのような不整合をボリューム（その完全性を個々にチェックできる）が使用されているときにバックグラウンドで非同期的に取り除くことによって、これを達成することができる。リロケーテッドＦＳＯを削除すべきであるか、あるいは所有しているＳＬに再接続すべきであるかを検出するために、充分な情報冗長性が存在する。恒久的にダングリングなＳＬは、アクセスされ「ファイル発見できず」のエラーが報告されたときに検出され、必要に応じて削除される。このような清掃は、それがクラッシュが生じたときに修正されるＦＳＯにのみ適用されるという点で、システム・クラッシュの場合に指示されたやり方で実行される。
これに加え、ＳＬをクラスタ・アーキテクチャにおいて完全に利用するため、ＳＬに適用しなければならない他のいくつかの行動ルールが存在する。これについては、以下のサブセクションで検討する。また、ＳＬは、続くセクションおよび以下のセクション３．１．２．１．２において述べるとおり、ボリューム間参照のためのハード・リンクの概念を完全に一般化できる。
３．１．２．１．１ スクイジー・リンクおよびディレクトリ
ディレクトリへのＳＬの生成が可能であるとき、ＳＬが厳密にクライアントへのハード・リンクとして振る舞うことを確実にするため、「．．」ディレクトリ・エントリを正しく取り扱うことが必要である。これは、「．．」が常に、エントリを含んでいるＲＤ（物理的なペアレント）ではなく、ＳＬを含んでいるディレクトリ（「仮想ペアレント・ディレクトリ」、すなわちＶＰＤ）にマップされるべきであるということを意味している。
或るディレクトリを指すただ１つのリンク（ハードまたはＳＬ）が存在可能であるため、ディレクトリそのものは、ただ１つのＶＰＤを有することができる。したがって、ＶＰＤへの参照をディレクトリｉ−ｎｏｄｅに埋め込むことが可能である。この参照は、「ＶＰＤバックリンク」として特定される。
これを行なう容易な方法は、ボリュームＩＤおよびｉ−番号を参照されたディレクトリｉ−ｎｏｄｅに埋め込むことである。しかしながら、このようにすることで、ボリュームの特定の情報が他のものに埋め込まれ、それは避けるべき何かである。したがって、以下の方法の１つに従って進むことが、より良好である。
１．以下のとおり必要なマッピングを供給する参照ボリュームに保存されたファイルを使用することによる。
リロケーテッド・ディレクトリｉ−ｎｏｄｅが、参照ＶＰＤのボリュームＩＤ、ならびにディレクトリそのものを特定するＲＤリンクのｅ−番号を保存する。オブジェクトがディレクトリであるため、「．」および「．．」に加えただ１つのリンクを有することができる点に注意すべきである。したがって、ただ１つのｅ−番号が保存される必要がある。
各ボリュームが、ＶＰＤを含んでいるディレクトリのローカルｉ−番号と、リロケーテッド・ディレクトリを特定する＜ボリュームＩＤ、ｅ−番号＞の組との間の関連付けを記憶するシステム・ファイルを提供する。これを、「バックリンク・ファイル」と呼ぶ。このファイルが、ローカル・ボリュームに関するデータにもとづく情報のみを保存し、ローカル・ボリュームのみの走査によってチェックおよび再構成できることに注意すべきである。
リロケーテッド・ディレクトリｉ−ｎｏｄｅがキャッシュされるとき、「．．」エントリは、リロケーテッド・ディレクトリｉ−ｎｏｄｅのボリュームＩＤ、リロケーテッド・ディレクトリのｅ−番号、および適切なボリュームのバックリンク・ファイルによって、リロケーテッド・ディレクトリの＜ボリュームＩＤ、ｅ−番号＞を介してインデキシングすることによって解決できる。次いで、得られたペアレント・ディレクトリについての＜ボリュームＩＤ、ｉ−番号＞の組をキャッシュできる（これは、ディスクには保存されない）。
「．．」へのアクセスが企てられたとき、これをトラップして、キャッシュされた参照を返すことができる。
２．ＶＰＤバックリンクを、パス名として参照ディレクトリｉ−ｎｏｄｅ内に置くことによる。これは、別個のファイルを有する必要を節約し、更新を簡単にし、間接の数を少なくする。一方で、可変長のパス名をｉ−ｎｏｄｅに埋め込む必要があり、ＶＰＤに到達するために完全なパス名の参照が必要である。これは、論理的にはより簡潔であり、ＶＰＤへの参照を保つためにオブジェクトを１つだけ更新すればよいが、ＶＰＤ（または、そのパス名中の任意のディレクトリ）の名前が付け直された場合に、保存されたＶＰＤバックリンクの一部としてその構成要素を有しているすべてのリロケーテッド・ディレクトリを、やはり更新しなければならないという点で大きな欠点を有している。これは、高価につく操作である。
最初のアプローチは、少しだけ複雑である。しかしながら、名前の付け直しに影響がないため、こちらが好ましい。これは、ＶＰＤの参照が比較的頻繁ではない操作に相違ないため、性能に大きな不利益をもたらすとは考えられない。しかしながら、そのような状況においては、パス名をヒントとしてディレクトリｉ−ｎｏｄｅ内に保存（仕組み２のように）し、ヒントが無効である場合に第１のアプローチに依拠する混成の仕組みを実装することによって、適切な戦略を考案することができる。
この仕組みが、リロケーテッド・ディレクトリがアクセスされたときにキャッシュのみを実行し、外部ボリューム情報をｉ−ｎｏｄｅ内に埋め込まない点に注意すべきである。
３．１．２．１．２ スクイジー・リンクおよびボリューム間参照
ひとたびＳＬの概念が定められると、それを、ボリュームを横断するハード・リンクのセマンティクスの実装に有用に使用することができる。これは、これがグローバル・ファイル・システムが個々のボリュームによって実装されているという概念をクライアントから隠す最後のステップであるという点で、真に有益である。換言すれば、クライアントは、自身が任意のディレクトリからファイル・システム内の任意のファイルへのハード・リンクであると理解するものを、それらが存在するボリュームにかかわらず、常に生成することが可能である。
ここで鍵となる問題は、ＮＡＳクライアントがファイルへのみのハード・リンクを生成するために適用できるＵｎｉｘ（登録商標）リンク（）システム・コールの実装である。事実上、ハード・リンクは、ボリューム間のリンクが望まれるとき、ＳＬを使用してエミュレートできる。削除の場合と同様、リンクが加えられようとしているボリュームを所有しているノードが、常に操作を実行するものと仮定される。受信しているノードがオーナではない場合、当該ノードが当該要求をオーナへと送る。考えられる場合は、以下のとおりである。
１．「共に存在」する（それらが同じボリューム内に存在することを意味する）ファイルを指してハード・リンクが生成されるとき、これはボリューム内のハード・リンクの生成を必要とする。これは、リンク（）システム・コールに予想される標準的な挙動である。
２．ファイルへのハード・リンクが生成され、２者が共に存在してはいないとき、まず、目標ファイルへのハード・リンクが、目標ファイルが位置しているボリュームのＲＤに加えられなければならず、次いでこの新しいリンクを参照する新しいＳＬが、適当なディレクトリに生成されなければならない。同じボリュームのＲＤに新しいリンクを生成するだけで、ファイルは動かされず、当該ファイルへの他の参照も影響されない。
３．新しいハード・リンクが、ＳＬを通じて参照されるファイルを指さなければならないとき、ファイル・システムが、目標ファイル（既存のＳＬが指しているファイル）を含むＲＤ内に新しいハード・リンクを生成すべきである。したがって、目標ファイルについてのリンク・カウントが、１だけ大きくなる。最後に、新しいハード・リンクへの参照を埋め込んでなるＳＬを、適当なディレクトリに生成すべきである。
これを完全にサポートするために、サブセクション３．１．２．１において述べた基本的なＳＬの機能を実装するために存在しなければならない機能に関し、ファイル・システムに追加の機能は必要がない。
種々の場合の取り扱いは、このようなやり方で、以下の有用な属性をもたらす。
・ＳＬが、リロケーテッド・ファイルへのハード・リンクのみを参照することができるため、ＳＬの除去が、依然先に説明したように行なわれる。基本的に、異なるボリュームのデータ構造を結び付けるＳＬについての参照カウントを加える必要がない。ＳＬの除去は、ＲＤ内のハード・リンクの除去を生じさせる。これが、ファイル参照カウントの減少を生じさせ、次いで、参照数が０に達したときファイルは削除される。したがって、これを扱うために追加の符号を設ける必要がなく、ファイル参照カウント機構は影響を受けない。
・ＲＤ内の各ハード・リンク（＝名前）が、依然ただ１つのＳＬによって参照されるため、ハード・リンク名が、関連のＳＬへの参照を埋め込むために必要な情報を埋め込むことができる。
これが、ＮＡＳクライアントへの完全なハード・リンク・セマンティクスを備えるボリューム間リンクを実装する機構を提供する能力を完全に一般化する点に注意すべきである。このようにして、２つの異なる名前空間が存在する。
・ハード・リンクを通じてＦＳＯに接続され、ＲＤにＦＳＯを含んでおり、それぞれが自身の内部ヒエラルキを有しているボリュームの集合によって実装された物理的な名前空間（システムによってのみ見ることができる）。
・ボリュームを横断して全ファイル・システムに広がる論理名前空間（ＮＡＳクライアントによって見られる）が、ハード・リンクおよびスクイジー・リンクによって接続されたＦＳＯから作られ、ハード・リンクとＳＬの間の相違を、ボリューム境界およびＲＤの存在とともにクライアントから隠す。図４は、ハード・リンクおよびＳＬによって実装されたこの名前空間を、論理的観点（左上）を参照しつつ描いている。図２において、ディレクトリ「Ｗ」およびファイル「ａ」を生成したクライアントが、ノードＰ（ボリューム１のオーナ）を通じてそのようにしており、ディレクトリ「Ｂ」およびファイル「ｘ」を生成したクライアントが、ノードＱ（ボリューム２のオーナ）を通じてそのようにしており、ファイル「ｃ」および「ｙ」がノードＲ（ボリューム３のオーナ）を通じて生成されている点に注目すべきである。
３．１．２．１．３ スクイジー・リンクの動作
このセクションでは、ＳＬに実装される動作についてさらに詳細に説明する。
３．１．２．１．３．１ スクイジー・リンクの生成
入ってくるＦＳＯ生成要求が、以下の条件の１つ（または２つ以上）が真であるときに、自動的にＳＬの生成を生じさせるべきである。
・ＦＳＯがファイルであり、生成が外部のボリュームのディレクトリで生じるべきである場合。
・ローカル・ボリュームにファイルのための充分な空間が存在しない場合。
・適切な構成パラメータが、ＳＬの生成がディレクトリにも当てはまる（ファイルには常に当てはまる）ように指示しており、かつ、
ＦＳＯが、外部ボリュームのディレクトリ内に生成されるべきディレクトリである場合、または
ローカル・ボリュームにディレクトリのための充分な空間が存在しない場合。
生成は、以下のとおり生じるべきである。
１．クラスタ・ノードのファイル・システム・ソフトウェアが、ローカルＲＤ内にＦＳＯを生成する。すでに述べたとおり、ＦＳＯに使用された名前が選ばれるべきである。
２．ＦＳＯが生成された直後に、クラスタ・ノードのファイル・システム・ソフトウェアが、外部ボリュームのオーナを通じてスクイジー・リンクを生成し、次いで新しい名前をペアレント・ディレクトリに挿入する。さらに、ローカル・ボリュームにただいま生成されたファイル／ディレクトリへの適切なシンボリック参照で、ＳＬのコンテントが更新される。
続いて、ＦＳＯへのすべてのアクセスは、ローカル・ボリュームにおいてＳＬを通じて生じるべきであり、書き込みアクセスは、ボリューム・オーナを通って集中される。
３．１．２．１．３．２ スクイジー・リンク参照およびアクセス
ＳＬ内に収容されたシンボリック参照が、或るペアレント・ディレクトリ内の特定の名前のためのハンドルを得るために参照される。これは、常に通常の参照であり、返されたハンドルは、ディレクトリ・エントリ指定のとおり、要求されたオブジェクトについてのオブジェクト番号およびボリューム番号を含んでいる。
コールが成功し、返されたボリューム番号が、ペアレント・ディレクトリのボリューム番号と同じである場合、これは実際に「通常」の場合である（すなわち、ＳＬが関与しない）。返されたボリュームＩＤが、ペアレント・ディレクトリのボリュームＩＤと同じではない場合、これは実際にＳＬの場合である。
ファイル・システム・ソフトウェアが、リロケーテッド・ディレクトリ内の「．．」エントリに関して、セクション３．１．２．１．１にて説明した挙動を実装する。
さらに、ファイル・システム・システムは、解釈の実行が不可能であることを検知し、考えられる原因を区別すべきである。
・葉が見つけられない場合、ＦＳＯがもはや存在しない場合であると診断されるべきである。
・第１のパス名成分に到達できない場合、ボリュームが現時点でマウントされていないゆえ、故障（おそらくは）と診断されるべきである。
上記基準にもとづき、故障の場合には、ファイル・システムは、適切な回復行為を行なうべきであり、パニック・モードに入るべきではない。
論理的に含まれているボリューム内に物理的に割り当てられていない既存のＦＳＯがアクセスされたとき、アクセスは適切なＲＤを指し示すＳＬに従うべきである。これが、読み出しアクセスまたはディレクトリ・アクセスである場合、すでに述べたとおり進行すべきである。ディレクトリへの書き込みアクセス（属性の設定、エントリの除去、新規ディレクトリの生成、など）は、当該ディレクトリが物理的に存在しているボリュームのオーナを通じて実行されるべきである。それらは、いかなる深刻な性能上の問題も、ボトルネックそのものも引き起こさない、「シングル・ショット」の操作であるように思われる。
３．１．２．１．３．３ スクイジー・リンクの削除
入ってくる削除要求が受信されたとき、修正すべき２つのＦＳＯが存在し、すなわちペアレント・ディレクトリおよび削除の目標である。これらＦＳＯのそれぞれは、ローカルであっても外部であってもよく、以下の４つの場合を生じさせる。
・ローカル・ペアレント・ディレクトリおよびローカル目標について、通常の削除。
・外部ペアレント・ディレクトリおよびローカル目標について、ペアレント・ディレクトリのオーナへの転送。
・ローカル・ペアレント・ディレクトリおよび外部目標について、以下に述べるとおり進行。
・外部ペアレント・ディレクトリおよび外部目標について、ペアレント・ディレクトリのオーナへの転送。
したがって、「特別」な場合は、ペアレント・ディレクトリはローカルであるが目標は外部であるＦＳＯの削除である。ファイル・システム・ソフトウェアは、この場合を検知して、ローカル・ペアレント・ディレクトリからリンクを取り去り、ＳＬを破壊する。
これが完了したとき、続いてファイル・システム・ソフトウェアは、目標ＦＳＯを含んでいる外部ボリュームのオーナへと「削除」コールを発行する。次いで、このオーナが目標そのものへのリンクを削除し、当該ＦＳＯへのハード・リンク・カウントが０に達した場合に、ＦＳＯ空間を回収する。
３．１．２．１．４ 自動ファイル・リロケーション
適切な構成パラメータによって可能にされる最適な機構は、システム動作において集めた使用統計にもとづき、ファイルの自動リロケーションを促進する。これはディレクトリにも適用可能であるが、複雑さおよび大規模なツリーのコピーを減らすため、おそらくはディレクトリではなくファイルにのみ適用される。これは、外部ディレクトリにおけるＦＳＯの生成について概括したものと類似の機構によって実行される。バックグラウンドのタスクがこれを実行し、ホット・スポットのさらなる分散およびクラスタ・ノードを横断しての負荷のバランスを可能にする。各ファイルのリロケーションに関係するステップは、以下のものである。
・各ファイルがロックされ、リロケーションが終わるまで書き込みが阻止される。
・各ファイルが、リロケーションを実行するノードによって所有されているボリュームの１つのＲＤへとコピーされる。
・ボリューム・オーナが、含んでいるディレクトリのディレクトリ参照を無効にし、リロケートされたコピーへのＳＬで置き換え、ロックを解除して元のファイルを削除するよう要求される。
重要な注意は、下記のとおりである。すなわち、ＳＬの機能するやり方のため、複数のハード・リンクを有するファイルを別のボリュームを指しているＳＬに変換することができず、なぜならば、そうでない場合には、同じファイルへのＳＬへと変換するためにすべてのリンクを辿る必要があり、それは潜在的に当該ボリュームの全面的なサーチであるからである。したがって、２つ以上のハード・リンクを有するファイルは、通常はまったくリロケートされないが、このルールは、それらがすべて同じディレクトリ内にあるなど、既存のリンクを容易に検出できる場合には緩和できる。
クラスタ・ノードが、すでに元の含有ディレクトリ内でリロケートされＳＬによって表わされているファイルへの書き込みアクセスを得ようと試みるとき、当該ファイルをローカル・クラスタ・ノードによって所有されているボリュームへとリロケートするためのさらなる試みは行なわれない。その理由は、連続的リロケーションを防止するためであり、最初のリロケーションが、同じボリューム内における複数の激しくアクセスされるファイルの集中の回避という目的にすでに機能したためである。さらに、負荷バランサが、すでに接続の基礎をユーザのアイデンティティに置いていると仮定すれば、ファイルはもっとも適切な目的地に到達したに相違ない。
自動リロケーションの仕組みが、ユーザがクラスタへの接続のために通過するノードの知識にもとづいている点に注意すべきである。リロケーションによって、複数のボリュームを横断してのファイルの純粋な散布（それ自身価値がある）を超える値を付加するため、ファイルのリロケーションが安定であることが望まれる。これは、所与のユーザが、常に同じクラスタ・ノードを通じてクラスタに接続すべきであることを意味している。
ファイル・サイズの或るしきい値を条件とするクラスタ構成のさらなる選択肢（全体が無効にされてもよく、あるいは構成設定にもとづく或るしきい値にもとづいて条件付きで許される）は、最初の書き込みアクセスにおける自動ファイル・リロケーションを可能にする。書き込みアクセスが既存のファイルのコンテントの修正を必要とする場合、２つの場合が生じうる。
・ファイルが現在開かれており、すなわちファイルが共有されている場合、そこにファイルについての争いが存在するため、すべての書き込みアクセスは、当該ファイルが物理的に割り当てられているボリュームのオーナを通って集中される。したがって、この場合は、ボリューム・オーナによって処理される。
・ファイルが使用されていない場合、操作を処理しているローカル・ノードは、
ファイルをロックして、リロケーションが終わるまで書き込みを阻止し、
ＲＤ内にコピーを生成することによって、ファイルをローカルにキャッシュし、
ボリューム・オーナに、含んでいるディレクトリのディレクトリ参照を無効にし、コピーへのＳＬで置き換え、ロックを解除して元のファイルを削除するよう要求する。
・ファイルの実際のコピーを怠惰なやり方で処理でき、すなわちファイルが開かれたときにコピーを実行する必要がなく、むしろファイルを元のボリュームにおいて見えないようにでき、ファイル・セクタを必要に応じてコピーできる。ファイルが最終的に閉じられたとき、それまでにコピーされなかったブロックがコピーされ、元のバージョンが削除される。
ここに概括した機構は、クラスタ内のファイルの選択的リロケーションを効果的に実行する。これは、ユーザに認知されることなく、ファイルを種々のボリュームに自動のやり方で広げるという利点を有している。
３．１．３ キャッシングおよび並行性
適切な性能、ならびにクラスタ内のデータの一貫性および完全性を保証するため、各ノードにおける適切なキャッシングがサポートされなければならない。これは、読み出しのみのアクセスのノードのキャッシュ・データが、論理ボリュームのオーナによって実行される修正に関し、古くならないことを確実にしなければならない。
この問題は、内部システム・ロッキングの問題と密に結び付いており、新しいデータによるボリュームの更新を要求し、クラスタ・メンバーにキャッシュされたデータおよびメタデータが古くなったとき即座に破棄されることを確実にするため、適切な通信機構を使用する能力を必要とする。これは、下記が必要であることを意味している。
・ノードが自身のキャッシュ内のページを更新したときに、他のクラスタ・ノードに保持されているあらゆるコピーが確実に無効にされること。このタイミングは、古いキャッシュ・ページのオーナが当該ページを再取得しなければならないかもしれず、得られたビューがボリューム・オーナのものとコヒーレントであるように生じるべきであるため、重要である。ページは、更新されたバージョンがディスク上で利用可能なときにのみフラッシュされるべきであり、あるいは新しいバージョンが、ボリューム・オーナから直接取得されるべきである。
・得られるビューが一貫していることを確実にするために必要なとき、複数のメタデータ・キャッシュ・ページを一緒にフラッシュすること。
書き込みによる読み取りロックの破壊および関連するキャッシュ・ページのフラッシュは、実際のところ関連する事象であるため、システム−レベルのロック・マネージャを、キャッシュ管理と一体化することができる。ボリュームのための実際のロック・マネージャは、当該ボリュームのオーナであるノード内で実行される。
３．１．３．１ キャッシングおよびロッキング
このアーキテクチャは、２つのキャッシュが論理的に利用可能であると期待している。１つはメタデータ・キャッシュであり、ＦＳＭ（ファイル・システム・モジュール）ボード（すなわち、ファイル・システムを実行させるシステム・ボード）上で動作する。もう１つはセクタ・キャッシュであり、ＳＩＭボード上で動作する。
ローカル要求は、基本的には、メタデータおよびセクタ・キャッシュ内で取り扱われる。一方、外部要求は、別個に取り扱われなければならない。外部書き込み要求は、目標とするボリュームを所有しているノードへと送られるとき、ローカル・キャッシュ（図５参照）を完全にバイパスする。一方、外部読み出し要求（図６参照）は、ローカル・メタデータおよびローカル・セクタ・キャッシュの両方を使用している。
３．１．３．１．１ セクタ・キャッシュ
セクタ・キャッシュに使用される仕組みは、読み取りロックが有効であるとき、外部ボリューム・セクタが、読み出しのみモードでキャッシュされることを許すべきである。したがって、クラスタ・ノード（「要求者」）が外部ボリュームに属するセクタへの読み出しアクセスを必要とし、かつそれがまだキャッシュにないとき、読み出しのみロックを有する１つの読み出し要求をボリューム・オーナへと発行し、同じセクタについての他の読み出し要求をＳＡＮバックエンドへと発行すべきである（図５参照）。要求者は、セクタおよびそれのための読み出しのみロックの両者を受信するまで、ブロックすべきである。２つの場合が存在する。
１．ボリューム・オーナがキャッシュ内に当該セクタを有していない場合、ロックを与え、それを要求したクラスタ・ノードおよびセクタ番号を記録し、ＳＡＮバックエンドが要求を満足させるようにすべきである。この時点で、要求者はロックを得、セクタがＳＡＮから利用可能になるまで待つべきである。次いで、それがクライアントの読み出し要求を満足させる。
２．ボリューム・オーナがキャッシュ内に当該セクタを有しているばあい、２つのさらなる場面が存在する。
ａ．セクタが書き込みロックされていない場合、ボリューム・オーナは、読み出しのみロックを与え、それとともにセクタのコンテントを送ることによって応答すべきである。次いで、要求者は、クライアントの要求を満足させ、ＳＡＮバックエンドによって戻されると直ぐに、セクタを落とす（あるいは、ＳＡＮコマンドを中止すべきである）。
ｂ．セクタが書き込みロックされている場合、要求者は、ロックが与えられて場合ａに戻るまで停止すべきである。
ボリューム・オーナがセクタを書き込みロックする必要があるとき、まず他のノードに流通している読み取りロックを破壊すべきである。これは、当該セクタについて他のノードのキャッシュ・エントリを無効にする効果も有している。この時点で、当該特定のセクタを必要としているあらゆるノードが、上記アルゴリズムの実行に戻るべきである。
３．１．２．１．１．１ セクタ・キャッシュの一貫性
すべての論理ボリューム（実際には、いくつかの物理的なディスクによって構成されているであろう）は、特定のクラスタ・ノードによって「所有」され、そのノードのみが当該ボリュームに書き込みできる。一方で、クラスタ内の他のすべてのノードは、潜在的に、自身の所有ではないボリュームから読み出しデータをキャッシュすることができ、したがって、ボリュームがオーナによって書き込まれたときに、データの一貫性を保つために他のノードのキャッシュ・データをすべて確実に無効にする仕組みを有する必要がある。
本発明の典型的な実施の形態においては、クラスタ内のすべてのノードが、セクタ・キャッシュ・ロック・マネージャを含んでいる。これが、当該ノードに所有されているボリュームからのクラスタ内のすべてのセクタ・キャッシュのデータのキャッシュを管理する。セクタ・キャッシュは、キャッシュ・ページ（典型的な実施の形態においては、サイズが３２キロバイト）で作られており、これらのページがロック・マネージャによって管理される。
ロック・マネージャによって管理される各キャッシュ・ページは、２つの状態のうちの１つであることができる。
読み取りロックこのページは、オーナでない少なくとも１つのノードのセクタ・キャッシュにキャッシュされている。
書き込みロック−このページは、オーナ・ノードのセクタ・キャッシュにキャッシュされており、ダーティなデータを含むことができる（セクタ・キャッシュのデータが、ディスク上のデータよりも新しい可能性がある）。
個々のロック・マネージャが何枚のキャッシュ・ページを管理できるべきかについて、問題がある。最悪の場合においては、クラスタ内のすべてのノードが、それらのセクタ・キャッシュをただ１つのボリュームからの読み出しデータの異なるブロックで一杯にすることは明らかである。これに対する１つの解決策は、この最悪の場合に対処したいロック・マネージャ上のメモリを指定することである。
生じうる３つの異なるセクタ・キャッシュ操作が存在する。それらのそれぞれについてのロック・マネージャ上の実装を、以下に説明する。
３．１．３．１．１．１．１ オーナの読み出し
ボリューム・オーナは、自身の所有するボリューム上のデータについて読み出しの要求を受信したとき、いかなるロックも取得することなく、あるいはロックの状態をチェックすることなく、ボリュームからオーナ・セクタ・キャッシュへとデータを読み出すことは自由である。ページがすでに書き込みロックされている場合、それは書き込みロックされたままである。
３．１．３．１．１．１．２ オーナでない読み出し
非オーナが読み出し要求を受け取った場合、最初に、当該ページの読み取りロックをすでに有しているか否かを確かめるべくチェックが行なわれる。有している場合、要求されたデータを読み出すだけである。有していない場合、読み取りロックを求めてロック・マネージャに照会を行なわなければならない。この要求について、考えられる結果が２つ存在する。
１．現時点でページがクラスタ内のどこにもキャッシュされていない場合、または他の１つ以上のノードによって読み取りロックされている場合、ロック・マネージャが、当該ページがこのノードによって読み取りロックされているとマークして、当該ノードに読み取りロックを付与し、この結果、ボリュームから自身のセクタ・キャッシュにデータを読み込むことができる。ノードがキャッシュ・ページをセクタ・キャッシュから取り除いたとき、誰が何をキャッシュしているかを適切に追跡できるよう、ロック・マネージャに知らせることが重要であることに注意すべきである。
２．現時点でページが書き込みロックされているとき、ロック・マネージャは、読み取りロックの要求が失敗に終わったことをノードに伝える。この場合、ノードは読み出し要求をクラスタ・ポートを横切ってオーナ・ノードへと提出しなければならず、オーナ・ノードが、読み出したデータをオーナ・ノードを横切って返す。次いで、要求を行なっているノードは、読み取りロックを得ることができなかった旨をキャッシュしても、キャッシュしなくてもよく、次のチェックポイントが行なわれるまですべての読み出し要求をオーナ・ノードに提出する（読み出し要求は放棄してもよい）。
３．１．３．１．１．１．３ オーナの書き込み
オーナ・ノードが書き込み要求を得たとき、生じうる３つの事象が存在する。
１．ページが現時点でキャッシュされていない場合、ロック・マネージャが当該ページを書き込みロックされたとしてマークする。
２．ページが現時点で読み取りロックされている場合、ロック・マネージャが、読み取りロックを保持しているノードのそれぞれに、それらの読み取りロックを破壊するよう要求を送信する。次いで、これらのノードのそれぞれは、あらゆる未完の読み出しが完了するのを待ち、今や読み取りロックが破壊されたことをロック・マネージャに伝える。これらロック破壊の要求がすべて完了したとき、キャッシュ・マネージャが当該ページを書き込みロックされたとしてマークする。
３．ページがすでに書き込みロックされている場合、何も行なわない。
ひとたび書き込みロックが取得されると、当該データをセクタ・キャッシュに書き込むことができる。
ページについて書き込みロックが取得されるたびに、ロック・マネージャは、書き込みを行なうために使用されたチェックポイント番号を記録する。このチェックポイントが成功裏にディスクに書き込まれたときに、ページがのちのチェックポイント番号とともに書き込まれなかった場合、書き込みロックは放棄され、ページがロック・マネージャの表から取り除かれる。
３．１．３．１．２ メタデータ・キャッシュ
メタデータ・キャッシュについて考えられる実装の仕組みは、メタデータ・キャッシュが、セクタ・キャッシュによってもたらされるものときわめて似ているが実際には独立である機構を実装しているものか、あるいはメタデータ・キャッシュがセクタ・キャッシュの従属であって特別な設備装置を必要としないものか、のいずれかである。
従属メタデータ・キャッシュを実装するため、基本的な仮定は、セクタ・キャッシュが、セクタ番号からそれらが実装するメタデータ・オブジェクトへと逆マッピングを行なうための機構を有しているというものである。
メタデータ・オブジェクトは、セクタに対するより高レベルの抽象である。しかしながら、それらは、より高いレベルのセマンティクスが組み合わされているが、最終的にはセクタ・データを含んでいる。従属の仕組みは、以下の考え方にもとづくことができる。
・外部クラスタ・ノードは、ボリューム全体を読み取りロックする必要を決して有さない。したがって、ボリューム・ロックは、完全にボリューム・オーナへとローカルである。
・ボリューム・オーナがＦＳＯの更新を必要とするとき、ＦＳＯへの書き込みロックを得なければならない。外部ノードは、ＦＳＯを直接更新することが決してできず、ｉ−ｎｏｄｅロックの必要を有さない。しかしながら、ディレクトリのコンテントまたはファイルのコンテントあるいはマッピングが、外部ノードがそれを読み出している間に変化しうるリスクが存在する。よりトリッキーなのは、外部ノードが、読み出しアクセスを実行するときに複数の項目を考慮に入れる必要がある場合である。そのような場合に対処するため、ボリューム・オーナがＦＳＯへの書き込みロックを得る必要がある場合に、それがまず、ＦＳＯのｉ−ｎｏｄｅを表わしている最初のセクタ（このセクタそのものが修正されようとしているのではなくても）についてのあらゆる未決の読み取りロックを破壊すべきであり、さらに、修正すべきあらゆるセクタが読み取りロックされなければならないというルールを設定できる。読み取りロックの破壊が、外部ノードのセクタ・キャッシュが知らされることを含んでいる点に注意すべきである。次いで、それらが、それらのＦＳＭ複製をメタデータ・キャッシュにキャッシュされるセクタのために知らせることができる。
・このように、クラスタ内のＦＳＭコードが、所与の操作を実行するためにメタデータへのアクセスを必要とする場合、それはＦＳＯのｉ−ｎｏｄｅを得、ついで適切なデータを得なければならない。それがこれを実行したとき、要求された読み出し操作を実行する直前に、それが取り扱っているオブジェクトのｉ−ｎｏｄｅの最初のセクタが依然読み取りロックされているか確認される。より一般的には、いくつかの項目が一貫していなければならない場合、それらの有効性が、それらが取得された順序に対して逆の順序で確認されなければならない。そうである場合、操作を続けることができる。そうでない場合、それは放棄され、スクラッチから再開されなければならない。そのような場合（実際は、競合ゆえの例外であると考えられる）において考えられる代案は、書込み操作の場合と同様、要求をボリューム・オーナに送るというものである。ここで、以下に留意すべきである。
セクタ・キャッシュへの照会は、読み取りロックの確認のために使用できる。考えられる代案は、セクタが無効である場合に、ＳＩＭセクタ・キャッシュが、適切なフラグをＦＳＭキャッシュ・バッファへと伝播させることができるようにするというものである。
操作を再開させなければならない場合、関連するセクタの取得は、ボリューム・オーナ・ノードの書き込みロックが解除されるまで要求スレッドを阻止することを含んでいる。
・ＳＩＭが他のデータのための空間を作るべくそのようにするとき、ＦＳＭボードのメタデータ・キャッシュが、外部メタデータを放棄しなければならない状態にならないようにすることが望ましい。これを得るため、外部メタデータが、それがもはや必要とされなくなる（または、他のメタデータのための余地を作るためフラッシュが必要になる）まで、あるいは無効になるまで、ＦＳＭキャッシュに保たれることが期待される。したがって、外部メタデータを含んでいるＳＩＭキャッシュ・エントリが、他のデータのための余地を作るためにフラッシュされるとき、ＳＩＭボードは、フラッシュされたメタデータを有する旨をオーナに知らせることを回避する。したがって、無効化要求がオーナから入ってきたとき、ＳＩＭボードは、その要求を直接処理する代わりに、それをＦＳＭメタデータ・キャッシュにリレーし、ＦＳＭメタデータ・キャッシュが適切に対処する。
・このように、メタデータ・ロックを別個の機構として実装する必要はない。また、これにより、ボリューム・オーナが所与のセクタについてのすべての読み取りロックの無効化を要求し、コピーを有していたすべてのノードがこれを確実にするまでブロックするという煩わしい同期プロトコルの必要性も避けられる。
・ボリューム・オーナは、ボリュームへの書き込みを扱う唯一の存在（他のノードの代理としてでさえも）であり、常に一貫したビューを有している。したがって、一貫したビューを保証するという問題は、外部読み出しにのみ当てはまる。
３．１．３．２ このアプローチの属性
使用される仕組みゆえ、以下に留意すべきである。
・古くなったセクタ・キャッシュ・エントリのコピーは、決して使用されない。
・ボリューム・オーナによってキャッシュされたセクタが、常に好ましい。
・ＳＡＮバックエンドからのいくらかの追加の読み出しを要求でき、次いで単純に落とされる。実際、係属中の要求を放棄することによって、より盲目でない挙動が達成できる。さもなくば、読み出しを前もって発行するか否かについての判断を、ボリューム・オーナによる応答に関し、ＳＡＮバックエンドが当該ボリュームについて扱っているトラフィックの量によって、調節できる。
・ボリューム・オーナのみがロックを管理する。これにより、設計が簡略化される（さらに、拡張性が減らされる）。
・書き込みロックが、常に外部読み取りロックよりも高い優先順位を享受する。
・別個のノードに接続されたクライアントが同じファイルにアクセスしている場合、複数のノード・キャッシュ内でボリューム・セクタの潜在的複製が存在する。
・デッドロック管理の複雑な部分が、書き込みロックの使用に関係する。これは、ボリューム・オーナの側では変化しない。したがって、分散化設計が必要とされない。外部ノードにおいて、読み取りロックを常に破壊／解放および再取得できる。これにより、デッドロックの必要条件の１つが取り除かれる。したがって、デッドロックが存在し得ない。
・この仕組みそのものは、拘束のない拡張性を保証しない。実際、それは以下の場合に最もよく機能するであろう。
−クラスタ・オーナにおける読み取りロック／データ要求の管理のオーバヘッドが、限定されている。他の何よりも、このプロトコルは、きわめて簡潔であることが期待されており、読み取りロック要求（ボリューム・オーナへの）、データが添付されておりあるいは添付されていない読み取りロック応答（ボリューム・オーナから）およびフラッシュ／読み出しのみロックの破壊（ボリューム・オーナから）に限定されている。
ボリューム・オーナとやり取りをするクラスタ・ノード数に限界がある。
外部アクセスの多くが、読み出し型である。
しかしながら、パス名をＦＳＯが割り当てられているボリュームから切り離すことは、実際、全ボリュームにわたるホット・スポットの顕著な分散をもたらすことができ、ボトルネックを減らす傾向にある。
・ここに記載のクラスタ間のセクタ・キャッシュのやりとりが、ＶＬＳＩにて取り扱われる場合、この仕組みがクラス他の拡張性を小数のノードに限定しないと期待することが妥当である。
・キャッシュに実装された共有のセマンティクスが、システムがクライアントに対し一貫したビューを常に保証できるようなものである。メタデータおよびセクタが、それらが一貫したやり方でキャッシュされたのち（キャッシュ・エントリの有効性をチェックすることによって確認される）、そのコンテントが直後に変化するかもしれないが、クライアントへと提供される情報は常に一貫している。これは、実際、データの同期が共通のアプリケーションまたは環境内で協働しているクライアント間の共通のロッキング・プロトコルの使用にのみもとづいている限りにおいて、充分である。しかしながら、ＮＡＳの確認を使用する分散アプリケーションが、別のチャネル（例えば、ソケット通信）を通じて他のクライアントとの同期を引き起こすために書き込む場合、この仮定は当てはまらないかもしれない。したがって、初期設定のルールとして、データがキャッシュされるべきであるとの非同期の告知をサポートし、特定のアプリケーションがこの挙動に依存する場合に、構成スイッチを通じて動機モードを可能にできるようにすることが適切かもしれない。
・メタデータ・キャッシュのサイズおよび効果が、決してセクタ・キャッシュのサイズによって制限されない。
・キャッシュ・マネージャが、新規クラスタ・ノードが動的にクラスタに合流／離脱したとき、それらを登録／未登録できなければならない。ハードウェア状態モニタ（高可用性ソフトウェアの一部）が、関連の事象を告知する。
ここで述べたメタデータ・キャッシュの一貫性の仕組みは、セクタ・キャッシュの一貫性の仕組みの上に構築でき、セクタ・キャッシュ・ページを当該キャッシュ・ページに含まれたすべてのメタデータデータ・オブジェクトに関係付ける「逆マッピング」に依存している。
３．１．４ 多ボリューム操作
これまでに、メタデータ・キャッシュおよびセクタ・キャッシュの管理に関して、内部ロッキングを考察した。これは、完全にボリューム内の操作にとって正に必要とされているものであり、ロッキングが完全にボリューム・オーナの担当範囲内であり、実際に、スタンドアロンのノードで使用されるそれらと一致するやり方で扱われるべきである。
より複雑な多ボリュームの操作は、すべてグローバル・ファイル・システム名前空間の管理を取り扱う。当然ながら、個々のボリュームにローカルである名前空間の操作は、ボリュームの文脈において取り扱われ、追加の複雑性はない。
いくつかの多ボリューム操作の複雑性を、ＳＬの使用によって大きく軽減できることに注意すべきである。一例は、ボリュームから他のボリュームへのディレクトリのリネームである。ディレクトリ「Ｘ」（真のディレクトリであって、ＳＬではない）をボリューム「Ａ」からボリューム「Ｂ」の「Ｙ」へとリネームしたい場合、これは以下のとおり実現できる。
・ボリューム「Ａ」のＲＤへと「Ｘ」のローカル・リネームを、数値名を割り当てｉ−ｎｏｄｅ内のＶＰＤバックリンクを更新しつつ実行する。
・ボリューム「Ｂ」の適切なディレクトリに、前記リロケーテッド・ディレクトリを指す「Ｙ」と命名されたＳＬを生成する。
「Ｘ」がすでにＳＬである場合には、以下を行なう必要がある。
・「Ｘ」についてのディレクトリ・エントリを、参照されたディレクトリを取り除くことなくボリューム「Ａ」から取り除かなければならない（これは、目標ディレクトリの更新を含む）。
・参照されたディレクトリのｉ−ｎｏｄｅを、新しいＶＰＤを指すＶＰＤバックラインを有するように更新しなければならない。
・参照されたディレクトリのための新しいＳＬを、ボリューム「Ｂ」の適切なディレクトリに生成しなければならない。
この後者の操作には、最大３つのノードが関与しうる。
この仕組みがファイル、ディレクトリおよびＳＬに当てはまり、実データのコピーを実行する必要はない。ＦＳＯがクラスタのどこに物理的に保存されているかに関する態様は、クライアントから隠されているため、あらゆるリネームまたは移動の操作は、このようにして取り扱うことができる。
すべての場合において、操作は自己完結であるステップで取り扱うことができ（すなわち、ボリューム内の各名前空間の操作が原子的である）、複数ボリュームのロックの必要はない。中間ステップにおける故障の場合の回復は、親のないＦＳＯを収集する清掃によって自動的に取り扱われ、あるいは操作を実行しているエンティティによって調整される。
清掃プロセスは、ノード故障のために完了しなかった操作から生じる親なしのＳＬおよびＦＳＯの除去を処理するために必要とされる。いずれの場合においても、多ボリューム操作に関係するオブジェクトのアイデンティティのログを記録することによって、清掃機による操作を、それらのオブジェクトにまで減らして最小化することができる。これについてのさらなる詳細は、セクション３．１．７にある。
以下の多ボリューム操作が、クラスタ・ファブリック内で実行される。これは、それらがＮＡＳクライアントにとってまったくアクセスできないプリミティブという形で実装され、外界から保護されていることを意味している。したがって、実行すべき操作を生じさせるクライアントが関係するファイル・システム・オブジェクトを修正するための充分な特権を有していることを確認する標準的なファイル・システム保護のチェック以外に、特権についての特別なチェックは不要である。
このセクションにおいて検討する多ボリューム操作が、通常は全体がサーバ・コードによってただ１つのボリューム内で取り扱われるより一般的な操作の特別な多ボリュームの場合を実装している点に注意すべきである。このように、外部ディレクトリ内のＦＳＯの生成は、ちょうど新しいＦＳＯを生成するコードによって扱われる多ボリュームの場合である。その意味では、これら多ボリューム操作は、ボリュームがすでにサポートしている基本的なローカル操作を単純に拡大している。
興味を引く多ボリューム名前空間操作は、以下のものである。
・外部ディレクトリ内のＦＳＯ生成：ファイルまたはディレクトリの生成の特別な場合である。
・既存のファイルへのＳＬの作成：リンク・プリミティブの特別な場合である。
・非共居住ディレクトリへのファイルまたはディレクトリのリネーム／移動：一般的なリネーム／移動操作の特別な場合である。
・既存のファイルまたはディレクトリを指すＳＬのリネーム／移動：一般的なリネーム／移動操作のさらに特別な場合である。
・ファイルまたはディレクトリへのＳＬの除去：一般的な除去の特別な場合である。
そのような操作を、全面的に１つのボリューム内で取り扱うことができるとき、それらは、単一ノードのファイル・システム実装例が実行すべき操作と相違しないため、この文脈においてさらなる検討を必要としない。
以下のサブセクションは、多ボリューム操作のそれぞれが達成するもの、およびグローバル・ファイル・システムのための完全性および回復に関する影響について説明する。
これを実装するために、２つの設備が必要である。以下で説明するプリミティブの組、およびスラッシュが関与する参加者に影響する場合に多ボリューム・トランザクションの前の状態への復帰を可能にする機構である。後者は、リモート側の自動アンドゥ設備およびＮＡＳクライアントには見えない「ローカル・アンドゥ・ディレクトリ」（以下では、ＬＵＤ）にもとづいている。これは、セクション３．１．４．６で検討される。
多ボリューム操作のための擬似コードは、リモートにて呼び出すことができ、さらに１つのボリューム内で全体が原子的に実行される以下の８つのプリミティブによって構成される。
Figure 0004480153
 このプリミティブは、「ｖｏｌＩＤ」によって特定されるボリュームのＲＤ内に新しいファイルまたはディレクトリ（「ｔｙｐｅ」項の値に応じて）を生成する。ＦＳＯの名前は、それまでに生成された最後の数値名を１つ増やすことによって得た数値列である。新しい名前へのポインタが関数値として返される。「ｖｐｄＢａｃｋｌｉｎｋ」項は、ディレクトリのためのＶＰＤバックリンクの生成のためにのみ使用される。ファイルの場合には、それは無視され、あるいはおそらくはデバッグのために保存される。
Figure 0004480153
 このプリミティブは、「ｆＶｏｌ」によって特定されるボリューム内にパス名「ｆＮａｍｅ」を有する種類「ｔｙｐｅ」の新しいＳＬを生成する。参照されたＦＳＯは、ボリューム「ｔＶｏｌ」内のパス名「ｔＮａｍｅ」によって特定される。目標とする名前が未だ存在しない場合、コールは続けられる。目標名が存在して、ＳＬであり、かつダングリングである場合、ダングリングな参照が新しいもので置き換えられ、コールが続けられる。そうでない場合、名前がすでに存在し、ダングリングなＳＬのものではない場合、次に続くためには、「ｔｙｐｅ」が既存のオブジェクトの種類と一致しなければならない。既存のオブジェクトがＳＬである場合、次に続くためには、「ｔｙｐｅ」がＳＬの指すオブジェクトの種類と一致しなければならない。既存のオブジェクトの種類または既存のＳＬによって指し示されるオブジェクトの種類がディレクトリである場合、既存の目標ディレクトリは空でなければならない。上記の条件が満足され、かつ既存の目標がＳＬである場合、ＳＬの参照が、新しいもので置き換えられる。次いで、既存の目標名が、ボリューム「ｔＶｏｌ」に関連付けられたＬＵＤのサブディレクトリへと動かされ（これは、既存のダングリングでないＳＬにも当てはまる）、操作が続けられる（さらなる詳細については、セクション３．１．４．６を参照のこと）。
Figure 0004480153
 このプリミティブは、ＳＬの生成を含む操作が続けられるとき、あるいはＬＵＤの清浄化を実行するために呼び出される。それは、（ｖｏｌ，ｎａｍｅ）の組によって特定されるＳＬが、既存のオブジェクトへの信頼できる参照を含んでいることをチェックする。そのようである場合、それは、ボリューム「ｔＶｏｌ」に関連付けられたＬＵＤサブディレクトリ内に生成されたエントリを、（ｖｏｌ，ｎａｍｅ）の組によって特定されるディレクトリ・エントリの上書きによって取り除く。「復旧」フラグが設定（これは、クラッシュ後に完全なＬＵＤ清浄化が行なわれる場合であろう）され、（ｖｏｌ，ｎａｍｅ）の組によって特定されるＳＬがダングリングである場合、ＬＵＤエントリはダングリングなＳＬを置き換えて復旧される。
Figure 0004480153
 このプリミティブは、「ｖｏｌＩＤ」によって特定されるボリュームのＲＤ内の新しいリンクを生成する。この新しいリンクは、同じボリューム内のパス名「ｎａｍｅ」によって特定されるファイルを参照する（これは、前もってＲＤにある必要はない）。この新しいリンクは、新しい数値名が自動的に割り当てられる。新しい名前へのポインタが、関数値として返される。
Figure 0004480153
 このプリミティブは、「ｖｏｌＩＤ」および「ｎａｍｅ」によって特定されたボリュームのＩＤおよびＦＳＯのパス名を返す。返された情報は、「ｐＶｏｌ」および「ｐＮａｍｅ」が指す変数内にある。「ｖｏｌＩＤ」および「ｎａｍｅ」がＳＬを参照している場合のみ、返された値が入力パラメータと相違する点に注目すべきである。
Figure 0004480153
 このプリミティブは、「ｖｏｌＩＤ」および「ｎａｍｅ」によって特定されたリンクを、「ｖｏｌＩＤ」が指すボリュームのＲＤ内の数値名へとリネームする。参照されたＦＳＯは、同じボリュームにとどまり、リンクのみが元のディレクトリからＲＤへと移動する。新しい数値名へのポインタが、関数値として返される。これが、元の（ｖｏｌＩＤ，ｎａｍｅ）の組が、当該ボリュームのＲＤにすでに存在するＦＳＯを参照している場合にも当てはまることに注意すべきである。「ｏｐＩＤ」項は、当該操作に割り当てられた固有のＩＤが返されるべき場所を指している。「ｖＢｌ」項は、ディレクトリのためのＶＰＤバックリンクの生成のためにのみ使用される。ファイルの場合には、それは無視される。この操作は、「ｔｍｏ」として指定されたタイムアウトを有し、ＦＳＯの元のアイデンティティを、操作は行なわれたボリュームへとローカルにログとして記録する。タイムアウトが経過する前に「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」プリミティブ（下記参照）が呼び出されるまで、リロケーションは自動的にアンドゥされる。タイムアウトが過ぎた場合にリロケーションが自動的にアンドゥされるよう、アンドゥ・エントリがすみやかに生成されることに注意すべきである。これは、元のディレクトリ・エントリがもはやアクセスできないことを保証する。このアンドゥ・エントリもボリューム内にログとして記録され、ボリューム・オーナのクラッシュの場合、ボリュームがオンラインに復帰したときにそれが実行される。
Figure 0004480153
 このプリミティブは、２つのパラメータを取る。先の「Ｒｅｌｏｃａｔｅ（）」プリミティブの呼び出しによって返された「ｏｐＩＤ」および「ａｂｏｒｔ」トークンである。「ａｂｏｒｔ」がヌルでない場合、「ｏｐＩＤ」が参照する「Ｒｅｌｏｃａｔｅ（）」の呼び出しによって実行された操作が、アンドゥされる。そうでない場合、それが実行され、保留中のアンドゥ操作が削除される。このプリミティブは、「ｏｐＩＤ」が参照する「Ｒｅｌｏｃａｔｅ（）」の先の呼び出しが未知である場合（これは、タイムアウトが経過してリロケーションがアンドゥされたことを意味するかもしれない）、エラーを返す。
Figure 0004480153
 このプリミティブは、３つのパラメータを取る。（ｖｏｌＩＤ，ｎａｍｅ）の組が、削除すべきオブジェクトを特定する。「ｆｏｒｃｅ」フラグは、削除が必須であることを指定するために設定される。このプリミティブは、ＦＳＯへのリンクまたはＳＬに作用する。「ｆｏｒｃｅ」フラグが設定された場合、参照されたリンクは常に削除される。それがハード・リンクであり、それが指すオブジェクトについての参照カウントが０に達した場合、オブジェクトそのものが削除される。それがＳＬである場合、ＳＬだけが削除される。「ｆｏｒｃｅ」フラグが設定されていない場合、このプリミティブは、それが指すＦＳＯがダングリングなＳＬでない限り削除を実行しない。
上記プリミティブはすべて同期的であり、すなわち要求された操作が完了したときにのみ応答が返されることを意味する。
これは、考えられる仕組みのただ１つに過ぎず、以下のサブセクションの擬似コードを示すためだけに使用されている。
多ボリューム操作がノードの故障によって潜在的に引き起こしうる考えられるエラーは、下記の分類に属する。
・ダングリングなＳＬ：これが生じたとき、ダングリングなＳＬは、名前が参照されたとき、または清掃機プロセスが不整合を検知したときに、ゴミとして収集されるべきである。
・ＲＤ内の参照されていないリンク名：先の場合と同様、ＲＤ内の参照されていないリンク名も、ゴミとして収集されるべきである。これが、当該リンクの指すオブジェクトが、それが当該オブジェクトへの最後のリンクであるときにのみ取り除かれなければならないことを意味していることに注意すべきである。
・ＲＤ内のリンク名が複数のＳＬによって参照されている場合：ＲＤ内の名前が数値であって単調に増加しているため、この場合は生じないであろう。新しいＳＬのそれぞれについて、リンクが新しい数値名で再生成される。
・ＦＳＯの元のＳＬが取り除かれたが、新しいものが生成できなかった場合：この場合には、部分的に成功した操作をアンドゥする能力が必要とされる。
これらは、以下に説明する操作において評価される。生じうる故障は、クラスタ・ノードのハードウェアまたはソフトウェアの不具合によるものと仮定する。内部クラスタ操作が実行されるやり方のため、またクラスタ相互接続が構成されるやり方のため、クライアントがＮＡＳレベルの下のクラスタ・ノードと直接干渉することは不可能である。したがって、不整合を注入しようとする企ては、保護されているＮＡＳネットワーク・インターフェイスを使用することによってのみ生じうる。
多ボリュームの操作は、コーディネータ（全体の操作を調整するノード）および操作によって影響される他のボリュームを所有する１つ以上のリモート・ノードを関与させる。コーディネータは、操作によって影響されるボリュームの１つのオーナである。これは、通常は、操作そのものを開始させるノードである。操作が、直接関与しない（すなわち、影響を受けるボリュームのいずれも所有していない）ノードへと要求された場合、当該要求は、リモート同期コールによって適切なコーディネータへと送られる。以下に述べる場合のそれぞれは、操作に関与する参加者のどれがコーディネータとして機能するかを指定している。以下に述べる仕組みが、考えられる仕組みの１つに過ぎないことに注意すべきである。基本的に、コーディネータの役割は、操作に直接関与する他の任意のノードに割り当てることができる。
３．１．４．１ 外部ディレクトリ内のＦＳＯ生成
この操作のためのコーディネータは、新しいＦＳＯが生成されるべきボリュームを所有するノードである。これが、ＦＳＯが実行中のノードのボリューム内に生成されることを確実にし、ローカル・アクセスに関して新しいＦＳＯの割り当てを最適化することに注意すべきである。
この操作は、典型的には、当該ＦＳＯについてのペアレント・ディレクトリを収容したボリュームを所有していないノードを通じて新しいファイルまたはディレクトリが生成されるときに行なわれる。
この操作には、コーディネータが所有するボリューム、およびＦＳＯのためのペアレント・ディレクトリが位置するボリュームを所有するリモート・ノードが関与する。コーディネータは、自身が所有するボリューム内にファイルまたはディレクトリを生成する。次いで、含んでいるディレクトリが存在するリモート・ノードが、新しいＦＳＯを指し示すＳＬを生成するよう要求される。
新しい目標名がすでに存在しうる点に注意すべきである。この場合、生成されるオブジェクトが既存の目標のそれと互換でない（一方がファイルであり、他方がディレクトリである）場合、操作は失敗する。同じことが、オブジェクトが両方ともディレクトリであって、目標が空でない場合に生じる。そうでない場合、元の目標ＦＳＯがＬＵＤへと動かされ、ＳＬが新たに生成されたＦＳＯを指す。
これについて、実行中のノード上の擬似コードは、以下のようである。
Figure 0004480153
 コーディネータが、ローカルＦＳＯを生成する（命令文１）。これを行なうためには、ローカル・ボリュームのみが関与すればよい。コールが失敗である場合（命令文２）、実行が中止される。成功である場合、リモート・ボリューム上にＳＬが生成されなければならない（命令文５）。コーディネータが命令文１と５の間で機能しなくなった場合、新たに生成されたＦＳＯ（存在するならば）は、当該ボリュームが復帰したときに親なしになり、したがって時期が来たときにゴミとして収集されるであろう。
行５の操作が、ＳＬを生成しなければならないボリュームを所有しているリモート・ノードによって実行される。コーディネータが成功の応答を受信しない場合、ＳＬの生成がいくつかの理由で失敗したか、あるいはリモート・ノードがクラッシュしたため、そのようになったのであろう。ＨＡサブシステムが、そのようなクラッシュを検出するであろう。いずれにせよ、コーディネータが新しいＦＳＯを削除する。最悪な場合の状況は、ＳＬの生成後かつコーディネータへの応答前に、リモート・ノードがクラッシュする状況である。この場合、コーディネータがＦＳＯを削除し、リモートのＳＬがダングリングな状態で残され、ゴミとして収集される。いずれにせよ、行５において戻される関数値は、生成の成功と、当該名前のＳＬがすでに存在するためＳＬを生成できなかった場合と、他の理由で生成が失敗した場合との間の区別が可能でなければならない。戻されたコードは、しかるべく処理される。
行８の操作は、リモートの操作である。行８における操作は、厳密に必要ではないことに注意すべきである。それは、単なる最適化である。
行６の操作は、ゴミの収集が参照されなかったＦＳＯの除去を担当するため、単なる最適化である。
この操作のセマンティクスは、同じ名前を有する既存のＦＳＯをゼロ長さに切り取ることを必要としてもよい。
この操作によって生成されたＦＳＯが、その引き続く使用に結び付けられている点に注目すべきである。ノードがクラッシュした場合、アプリケーションの状態が失われ、アプリケーションは、全体の操作を再度実行しなければならない。アプリケーションが再度開始するとき、要求されたＦＳＯが存在しても、存在しなくてもよい。
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・ローカル・ボリュームのＲＤ内に新しいＦＳＯが生成される。このＦＳＯの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。このオブジェクトは、ＳＬにリンクされるまでは、ＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがこのオブジェクトに干渉することはできない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。ＦＳＯの生成後に、名前が使用中のためＳＬを生成できない場合、新しいＦＳＯを削除しなければならない。
生じうる結果（ＦＳＯは有用なデータを含んでいない）：
・成功。
・成功したが、クライアントが成功の通知を受信する前にノードがクラッシュした。アプリケーションの状態が失われ、ＦＳＯがすでに存在するが、操作を再度実行しなければならない。
・ＦＳＯが存在するが、ＳＬが生成されなかった：参照されないＦＳＯはゴミとして収集されることになる。
・リモート・ノードがＳＬを生成することなくクラッシュした。コーディネータがこれを検知し、ＦＳＯを取り除く。
・リモート・ノードが、ＳＬ生成後かつコーディネータへの通知前にクラッシュした。コーディネータがＦＳＯを取り除き、ＳＬがダングリングなまま残される。クライアントが操作の繰り返しを試みた場合、ダングリングなＳＬが正しいものと置き換えられる。そうでない場合、ＳＬはゴミとして収集される。
・ＦＳＯが生成されなかった。
３．１．４．２ 既存のファイルへのＳＬの生成
コーディネータは、新しいＳＬが配置されなければならないディレクトリを所有するノードである。この操作には、このノードおよびファイルを収容しているボリュームのオーナが関与する。ディレクトリに適用できるものと同様のコールは、あらゆるディレクトリは自身を指すＳＬをただ１つだけ有することができるため、利用できないことに注意すべきである。
手順は次のとおりである。コーディネータが、リモート・オーナに、ＲＤ内の目標ファイルへと新しいリンクを生成するように要求する。次いで、それを指すローカルＳＬが生成される。
このための擬似コードは次のとおりである。
Figure 0004480153
 第１の動作（命令文１）は、参照されるべきファイルのためのボリュームおよびパス名の取り出し動作である。取り出した情報（ｆＶｏｌ，ｆＲｅｆ）が入力データ（ｓｒｃＶｏｌ，ｓｒｃＮａｍｅ）と一致する場合、使用されているパス名が実際のファイルのものであり、そうでない場合、ＳＬである。いずれにせよ、使用しなければならない実際のファイルを指しているものは、（ｆＶｏｌ，ｆＲｅｆ）の組である。
行２の操作は、既存のファイルへのリンクが、ファイルが位置しているボリュームを所有するノードによってリモートで生成されるため、強調される。リンクされるべきファイルが、リモート・コールがなされた時点においてもはや存在しない場合、実行は中止される（命令文３および４）。
応答の受信を不可能にするような故障が生じた場合、あるいはコーディネータが命令文２と６の間でクラッシュした場合、実行が中止され、ＲＤ内の新しいリンクは、ゴミとして収集される。
行２のコールが成功である場合、新しい名前が返され、コーディネータがローカルＳＬを生成する（行６において）。そのようにすることの故障の場合、リンクのリモート削除が要求される。それがすみやかに続けられない場合でも、リンクはゴミとして収集される。
命令文６が成功し、実行しているノードが直後に故障した場合、結果をクライアントに報告することができないが、ＳＬはその場所に残る。
命令文７のプリミティブは、ゴミの収集が参照されなかったリンクの除去を担当するため、単なる最適化である。
行９の呼び出しは、単なる最適化である。
操作が実行されている間にノードがクラッシュした場合、アプリケーションの状態が失われ、アプリケーションが、全体の操作を再度実行しなければならないことに注目すべきである。アプリケーションが再度開始するとき、要求された名前が存在しても、存在しなくてもよい。
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・既存のファイルへの新しいリンクがＲＤ内に生成される。この操作は、原子的である。リンクの生成が試みられた時点において、元となるファイルが存在する場合、生成は成功する。そうでない場合、操作の全体が中止される。やはり、リンクが生成されたのち、このリンクの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。古いリンクは、それが参照しているオブジェクトが正の参照カウントを有していて消失することがないため、この時点において任意のエンティティによって削除さえ可能である。新しいリンク名は、ＳＬにリンクされるまでは、ＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがそれと干渉することはありえない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。
生じうる結果：
・成功。
・成功したが、成功の通知を返す前にコーディネータはクラッシュした。
・新規リンクが生成されたが、コーディネータがクラッシュし、あるいは応答が失われた。したがって、ＳＬが生成されなかった。参照されなかった新規リンクは、ゴミとして収集されることになる。
・新規リンクが生成され、ＳＬリンクの生成に失敗したが、新規リンクを削除できなかった。上記と同じ。
・リンクが生成されなかった。
３．１．４．３ 非共存在ディレクトリへのファイルまたはディレクトリのリネーム／移動
コーディネータが、ＦＳＯを除去しなければならないディレクトリを所有している。このコールには、このノードおよびＦＳＯを含んでいるボリュームのオーナが関与する。
手順は次のとおりである。コーディネータが、ＦＳＯ（ＳＬではない）をＲＤディレクトリで数値名にリネームする。次いで、要求を行っているノードが、ＲＤ内のリモート・リンクを指すローカルＳＬを生成する。
最初の状態は、図７に示すとおりである（ＦＳＯは、「通常」のディレクトリ内のエントリによって指し示されている）。最後の状態が、図８に示されている（今や、ＦＳＯがＲＤディレクトリのエントリによって指し示されている）。
目標名が既存のディレクトリのものである場合、あるいはディレクトリを指しているＳＬのものである場合、実行は失敗し、下記のコードは該当しない。
これについての擬似コードは以下のとおりである。
Figure 0004480153
 最初の動作はリモートである（協調されている）。リモート・ボリュームのオーナが、ターゲットをＲＤへとリロケートするよう要求される（命令文１）。ディレクトリについて、ＶＰＤバックリンクのみが使用される。タイムアウトが指定され、タイムアウト経過前に命令文９が実行されない限り、この動作はアンドゥされる。
行１の要求が失敗に終わり、操作が放棄される可能性もある（命令文２および３）。成功し、成功の応答が返されて、命令文５に続く可能性もある。応答が受信される前にリモート・ノードがクラッシュした場合、応答が失われた場合、あるいは命令文６の前にコーディネータがクラッシュした場合、リロケートされたＦＳＯがアクセス不能になる可能性がある。しかしながら、命令文６の実行なくしてタイムアウトが経過したとき、リモート・ノードはＦＳＯを以前の状態に復帰させる。
行１のコールが成功した場合、新しい名前が返され、コーディネータがローカルＩＤを生成する（行５において）。そのようにすることが失敗した場合、命令文７がＦＳＯを以前の名前に回復させる。
命令文５が成功し、その直後に実行しているノードが故障した場合、命令文７を実行することができず、結果をクライアントに報告することもできない。したがって、タイムアウトののちにＦＳＯが以前の名前に戻り、ダングリングなＳＬがローカル・ボリュームに存在することになるが、ゴミとして収集される。一方、コーディネータによって所有されているボリュームが再びオンラインになったとき、ＳＬが既存の名前を上書きしてしまっているならば、このオブジェクトを利用することができない。これは、ＬＵＤ機構によって引き継がれる。ボリュームの再開が、ＬＵＤ回復を生じさせる。この場合、リモートＦＳＯが以前の状態に戻るため、ＬＵＤのための回復機能が、新たに生成されたＳＬについて有効な参照を検出せず、それをＬＵＤに保存されている当該名前に以前に関連付けられていたオブジェクトで上書きする。
「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」の呼び出しが上手くいかなかった場合（タイムアウトが経過したためにそのようになるであろう）、新しいＳＬは削除（ダングリングである）され、状態は、このコードが実行を開始する前のそれに戻る。
命令文７のプリミティブは、ゴミの収集が参照されなかったＦＳＯの除去を担当するため、単なる最適化である。
成功の場合、命令文１１が、新しいＳＬ（存在する場合）で置き換えられたＬＵＤに保存されているオブジェクトを取り除く。失敗の場合、保存されているオブジェクトを復活させる。
この操作が、以下の理由で多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
・参照されたオブジェクトへの既存のＦＳＯリンクを、それが存在するディレクトリからＲＤへとリネームする。この操作は原子的であり、成功するか行なわれないかである。やはり、リネームののち、このリンクの名前は新規であり、クラスタ内のいかなるＳＬによっても知ることができず、あるいは参照することができない。新しいリンク名は、ＳＬにリンクされるまではＲＤの外には知られていない。したがって、クラスタ内の他のエンティティがそれと干渉することはありえない。
・新規なＦＳＯを参照する新規なＳＬの生成は、原子的な操作である。したがって、やはりここでも、他のプロセスまたはノードからの干渉は不可能である。
生じうる結果（ＦＳＯが有用なコンテントを有している）：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・ＦＳＯがリロケートされたが、ＳＬが生成されなかった。有用なコンテントを有する参照されていないＦＳＯ。タイムアウトの経過によってＦＳＯが元の状態に戻され、ＬＵＤ機構が新しいＳＬによって上書きされたあらゆるオブジェクトを元に戻す。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、命令文７を実行する前にコーディネータがクラッシュした。この場合、すべてが実行されたにもかかわらず、ＦＳＯは以前の状態に戻る。
・ＦＳＯのリロケートが行なわれなかった。
３．１．４．４ 既存のファイルまたはディレクトリを指しているＳＬのリネーム／移動
コーディネータは、ＦＳＯの目標ペアレント・ディレクトリ（またはＶＰＤ）が位置しているボリュームのオーナであろう。
２つの場合が存在する。
・ＳＬのリネームによって、ＳＬが既存のＦＳＯと共存在になる場合、この操作は、ＦＳＯが存在するボリュームについてのローカル・リネームということになり、続いて元のＳＬが取り除かれる。これが、共存在のＳＬが、次の場合で扱われるとおり、機能的に等価であるという点で、単なる最適化であることに注意すべきである。この場合において、最初の状態は図９に示すとおりである。最後の状態は図１０に示すとおりである。
・リネームによってＳＬが参照されたＦＳＯと共存在にならない場合、まずＦＳＯがリロケートされ（これは、ＲＤ内でのリネームのみを必要とするであろう）、次いで、目標ＦＳＯへの参照を埋め込んだ新しいＳＬが生成される。最後に古いＳＬが削除される。新旧のＳＬが同じボリューム内にあるか否かに応じ、最初のステップは、コーディネータ・ノードにローカルであるかもしれないし、ローカルでないかもしれない。この場合において、最初の状態は図１１に示すとおりである。最後の状態は図１２に示すとおりである。
新しい目標名が既存のディレクトリのそれである場合、あるいはディレクトリを指しているＳＬのそれである場合、実行は失敗し、下記のコードは該当しない。
これについての擬似コードは以下のとおりである。
Figure 0004480153
 最初に、実際のＦＳＯ情報が引き出される（命令文１）。
新しいボリュームおよびＦＳＯボリュームが１つであって同じである場合、ＦＳＯが、単に新しい名前にリネームされる（命令文３）。これが、コーディネータが新しいペアレント・ディレクトリのためのボリュームのオーナであるため、ローカルな動作であることに注意すべきである。これが成功した場合、古いＳＬが削除される（命令文５）。ここで、リネームの操作が成功したが古いＳＬの削除が達成されなかった場合、後者がゴミとして収集されることに注意すべきである。
前記２つのボリュームが一致しない場合、まず、ＦＳＯが新しい名前にリロケートされる（命令文９）。これは、タイムアウトの経過前に命令文１４が実行されない限り、自動的にアンドゥされる。リロケーションが成功しない場合、操作は中止される（命令文１０および１１）。次いで、新しいＳＬが生成される（命令文１３）。続く命令文（１４）は、命令文１３が成功したか否かに応じて、リロケートをコミットするか、あるいはアンドゥする。
命令文１３が成功し、直後にコーディネータが故障した場合、命令文１４を実行することができず、結果をクライアントに知らせることもできない。
したがって、タイムアウトののちにＦＳＯが以前の名前に戻り、ダングリングなＳＬがローカル・ボリュームに存在することになるが、ゴミとして収集される。一方、コーディネータによって所有されているボリュームが再びオンラインになったとき、ＳＬが既存の名前を上書きしてしまっているならば、このオブジェクトを利用することができない。これは、ＬＵＤ機構によって引き継がれる。ボリュームの再開が、ＬＵＤ回復を生じさせる。この場合、リモートＦＳＯが以前の状態に戻るため、ＬＵＤのための回復機能が、新たに生成されたＳＬについて有効な参照を検出せず、それをＬＵＤに保存されている当該名前に以前に関連付けられていたオブジェクトで上書きする。
命令文１４の「ＲｅｌｏｃａｔｅＣｏｍｐｌｅｔｅｄ（）」の呼び出しが上手くいかなかった場合（タイムアウトが経過したためにそのようになるであろう）、新しいＳＬは削除（ダングリングである）され、状態は、このコードが実行を開始する前のそれに戻る。
成功の場合、命令文１９が、新しいＳＬ（存在する場合）で置き換えられたＬＵＤに保存されているオブジェクトを取り除く。失敗の場合、保存されているオブジェクトを復活させる。
そうでない場合、この時点においてダングリングであることに相違ないため、古いＳＬが削除される（命令文２２）。一方で、（ｏｌｄＶｏｌ，ｏｌｄＮａｍｅ）の組が再使用されている場合、削除はされないことに注意すべきである。最後に、クライアントへと応答が返される。
命令文３のプリミティブは、標準ファイル・システムのリネーム・コールのリモート呼び出しである。
すでに述べた場合と同様、この操作も多ボリュームの干渉を引き起こすことがなく、多ボリュームのロックを必要としないことに注目すべきである。
生じうる結果（ＦＳＯが有用なコンテントを有している）：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・リンクが同じボリューム内でリネームされたが、コーディネータに知らされたか否かに関係なく、古いＳＬが削除されなかった（そして、ダングリングなまま残された）。この古いＳＬは、ゴミとして収集される。
・ＦＳＯがリロケートされたが、コーディネータのクラッシュまたはコーディネータへの通知の欠落によって、新しいＳＬが生成されなかった。タイムアウトの経過後にＦＳＯが元の状態に戻り、ＬＵＤ機構が新しいＳＬによって上書きされたあらゆるオブジェクトを元に戻す。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、コーディネータのクラッシュによって命令文１４が実行されなかった。タイムアウトの経過後にＦＳＯが元の状態に戻り、次いで、ダングリングな新しいＳＬがゴミとして収集される。
・ＦＳＯがリロケートされ、ＳＬが生成されたが、コーディネータのクラッシュまたはリモート・ノードのクラッシュによって古いＳＬが削除されなかった（そしてダングリングなまま残された）。この古いＳＬは、ゴミとして収集される。
・失敗、変化なし。
３．１．４．５ ファイルまたはディレクトリへのＳＬの除去
コーディネータは、ＳＬのオーナである。
この操作は、ＳＬを取り除くこと、および当該ＳＬが指し示していたＲＤ内のリンクを取り除くことで構成される。これは、参照カウントによって決まるが、ＦＳＯの実際の削除を必要とするかもしれないし、必要としないかもしれない。
これについての擬似コードは以下のとおりである。
Figure 0004480153
 まず、ＳＬの参照ＦＳＯが引き出される（命令文１）。次いで、ＳＬがローカルに削除される（命令文３）。成功した場合、ＳＬが参照していたＦＳＯリンクも、リモート・ボリュームにおいて削除される（命令文４）。
生じうる結果：
・成功。
・成功したが、成功の通知が返される前にノードがクラッシュした。
・ＳＬが削除されたが、ＲＤ内のリンクは削除されず、参照されていない。このリンクは、ゴミとして削除される（これが唯一のリンクである場合、ＦＳＯが削除される）。
３．１．４．６ ＳＬの生成およびＬＵＤの役割
ＬＵＤは、ＲＤと同様、ＮＡＳクライアントにとって見ることができない。それは、ローカル・ボリュームがローカルＦＳＯを置換したＳＬによって参照を有しているシステム内の各ボリュームに１つずつ、いくつかのサブディレクトリを有している。
これらサブディレクトリの１つの各エントリは、ＦＳＯへのリンクまたはＳＬであり、新しいＳＬで置き換えられなければならない。このディレクトリ内のエントリのパス名のそれぞれは、ＦＳＯの元のパス名を、ＦＳＯを置き換えたＳＬにおいて参照されているｅ−番号とともに符号化している。
他のボリュームがオンライン状態に達しているとき、ボリュームが回復すると、適切な回復プロセスがそのようなエントリのすべてを通過し、それ（そのパス名が知られている）を置き換えたＳＬが有効な参照を含んでいる（すなわち、既存のＦＳＯを指している）かどうかを確認するチェックが行なわれる。そのようである場合、ＬＵＤエントリが削除される。そうでない場合、ＳＬを削除して、ＬＵＤの保存されたリンク／ＳＬで再び置き替える。これが、ボリューム操作を実行しているノードがクラッシュした場合に、既存のＦＳＯの破壊を行なわないように処置し、「ｒｅｓｔｏｒｅ」項の設定とともにＣｌｅａｎｕｐＬＵＤ（）の呼び出しの繰り返しによって実行される。
３．１．５ クライアント・ロッキング
クライアント・ロッキングは、所与のサービスが呼び出された時点におけるロックを明示的に要求するクライアント操作に関係する。これは、共有または排他モードにおけるファイル全体のロッキングまたはその一部のロッキングを含むことができる。
クライアント・ロッキング・サポートは、ＮＦＳ様式のロッキングのセマンティクス、ならびにＷｉｎｄｏｗｓ（登録商標）の「ｏｐｌｏｃｋｓ」のそれ、およびクラスタ全体にわたる共有モードを完全にサポートできなければならない。
これを取り扱うための自然なアプローチは、すべてのロッキング・コールを同じノードへと向け直すことによって、このレベルのロッキングを中央集権化するアプローチである。これは、ロッキング・プロトコルの文脈においてクライアント間でファイルの競合が生じた場合に、この種の要求が高速データ・パスの外であると考えられる点で機構を簡潔にし、それ自身が問題を引き起こすことがない。
これの取り扱いにおける２つの選択肢は、次のものである。
・ＦＳＯにアクセスするための最初のノードが、すべてのクライアントが当該ファイルへのアクセスをやめるときまで、当該ＦＳＯについてのロック・マネージャとなることができる。これは、クラスタ・ノード間のロック管理の役割のよりよい分散をもたらす傾向にあり、これをかなり動的にする。
・あるいは、ロックが適用されるＦＳＯのオーナが、常に当該ＦＳＯのためのロック・マネージャの役割を実施することができる。この第２のアプローチは、ＦＳＯを修正できるエンティティのみが、そのロッキング・プロトコルを扱うエンティティであるという利点を有している。
実際のところ、所与のＦＳＯのためのロック・マネージャの選択が、動的なネゴシエーションにもとづいて行なわれるのではなく、決定論的になるため、第２の選択肢が好ましい。したがって、それがよりよい選択肢である。
３．１．６ クラスタ全体に保持されたチェックポイント
スタンドアロンのサーバのために設計されたような保持されたチェックポイント機構が、個々のボリュームに関して機能する。ファイルの外部ボリュームへのリロケートが許される場合、保持されたチェックポイントは、保持されたチェックポイントが取られた時点においてファイルのコンテントがクラスタ全体のビューと同期していることを保証しない。したがって、クラスタ・サービスは、すべてのボリュームについてのＩ／Ｏの中断、および各ボリュームについての保持されたチェックポイントの取得（これは並列に行なうことができる）を処理するクラスタ全体の保持されたチェックポイントを実装するであろう。このクラスタリング・サービスは、以下によって２相コミット機構を通じてのＩ／Ｏの中断をグローバルに調和しなければならない。
１．保持されたチェックポイントが取られるまで、Ｉ／Ｏを中断する。
２．ローカル保持されたチェックポイントを取り、Ｉ／Ｏを再開する。
３．クラスタ全体に保持されたチェックポイントが取られたとき、すべてのボリュームについてチェックポイント番号を適切に同期させる。
クラスタリング・サービスが、各ノードの関連ＡＰＩを適切に呼び出すように取り計らう。
３．１．７ グローバル・ファイル・システム完全性チェック
先に概括したように、個々のボリュームの完全性を他のあらゆるボリュームのそれとは独立にチェックできるため、これを行なうために使用されるプログラムを、種々のボリューム上で並列に実行させることができる。
したがって、各ボリューム・オーナは、必要であれば、当該ボリュームをクライアントによって利用可能にする前に、そのようなチェックを実行する。
これがすべてのボリュームについてなされると、グローバル完全性チェッカ（清掃機）が、バックグラウンドで動作してＲＤ内のＳＬおよびＦＳＯを調べることによって作業を完了する。そのようなＦＳＯが親なしではないこと、およびダングリングなＳＬが存在していないことを確認すべきである。
ごみ収集が未だ進行中の多ボリューム操作に影響しないことを確実にし、かつクラッシュしたノードの一時的な利用不可能性を確実に考慮に入れるため、清掃機は、以下の条件を満足するＦＳＯおよびＳＬのみを調べるべきである。
・ＳＬは、それが参照しているボリュームがオンラインである場合に調べられる。ＲＤ内のＦＳＯは、そのＳＬが存在すべきボリュームがアクティブである場合に調べられる。例えば、オフラインのボリュームを指しているＳＬは、調べるべきではない。
・調べられるべきＦＳＯまたはＳＬは、少なくともＸ分以上古いものである。Ｘは、あらゆる多ボリューム操作の完了を保証するために充分大きくあるべきである。
この戦略が、ｅ−番号（すなわち、リロケートされたＦＳＯ参照）が常に増やされており、事実上再使用されない（１秒につき１００万個の新しいＲＤ名が生成されると仮定すると、６４ビットのアドレス空間は約５８５，０００年たつまでは埋め尽くされない）がゆえに有効であり、古いＳＬがダングリングになる点に注意すべきである。
アルゴリズムは、グローバル・ファイル・システムにおいて上記条件に一致するすべての候補ＳＬを走査し、それらをＲＤの適切なエントリに一致させる。ＲＳ内のダングリングなＳＬおよび参照されていないＦＳＯが、削除される。
多ボリューム操作に関係するオブジェクトのアイデンティティが、それぞれの多ボリューム走査の実行に先立ってログとして記憶された場合、清掃の所要時間および複雑さを、大幅に少なくできる点に注意すべきである。このようにして、操作をボリューム全体に適用するのではなく、そのようなエンティティに限定できる。当然ながら、チェックが実行され、適切な回復動作が行なわれた（必要な場合）のち、ログ・エントリを安全に削除することができる。
ごみ収集の候補になったＦＳＯは、それらがデータを含んでいる場合、それらの削除が、それらを回復させることができるディレクトリへのリネームを構成するように取り扱われる。そのようなディレクトリ内に充分に長い継続時間の間とどまったのち、それらは恒久的に取り除かれる。
３．１．９ 分散サービス（ＤＳ）／高可用性（ＨＡ）サブシステム
各クラスタ・ノードは、ＤＳ／ＨＡサブシステムを含んでいる。ＤＳ／ＨＡサブシステムは、分散ファイル・システムのために必要なメンバーシップ、メッセージング、および構成インフラストラクチャを提供する。ＤＳ／ＨＡサブシステムのための要件および仮定は、かなり一般的であり、以下のものを含んでいる。
１．ＤＳ／ＨＡサブシステムは、通信のための論理循環トポロジがクラスタに実装されていることを想定している。これは、各ノードが、このトポロジにおいて左（または右）隣りのＮＶＲＡＭデータの更新済みのコピーを有しており、ノード故障の場合に、隣りがデータの喪失なく引き継ぎを行なうことができることを保証するためになされる。さらに、隣りのＮＶＲＡＭのコピーを有しているノードが、当該隣のノードが故障した場合に、当該隣のノードの担当を引き継ぐための自然の候補である。このトポロジは、クラスタ内相互接続（以下で説明する）によって実装することができる。しかしながら、この同じトポロジを状態監視のために実装している冗長チャネルを有することが有用である。それらは、比較的低バンド幅のチャネルであるべきである。したがって、それらを低コストの手段によって実装することが可能である。
２．信頼できるクラスタ・メンバーシップ機構。これは共有ストレージにとってきわめて重要な特徴である。とくに、メンバーシップ機構が、（ａ）クラスタ・メンバーシップに関し、すべてのノードが他のすべてのノードの状態と同じ決定に到達すること、および（ｂ）ネットワーク・パーティションの事象（「スプリット・ブレイン」シナリオと称されることもある）の場合に、最大１つのパーティションが生き残ることを保証しなければならない。
３．ユニキャストまたはマルチキャスト・メッセージの順序正しい信頼できる配送。効率性の理由から、クラスタ相互接続が、少なくとも信頼できるユニキャスト配送をもたらすことが期待される。
４．常時オンの構成。すなわち、最大の生存性を保証するため、クラスタ構成が、すべてのノードを横切って複製される。
５．クラスタが安全な環境で稼動するものと仮定し、ビザンチン故障は考えない。インセイン型の故障は生じないと仮定する。
６．クラスタ・アーキテクチャが高可用性をもたらさなければならない。ゆえに、故障の単独点が存在してはならない。さらに、可用性がファイブ・ナインの条件を満足しなければならない場合、早期故障検出を実行できる能力が重要である。高可用性の要件が、あらゆる単独の故障が、回復動作の終了後に再試行が試みられたときに、リソースへのクライアントのアクセスを不可能にしない限り、リソースを利用不可能にする故障がクライアントによって検出されないままにすることを指示しないことに注意すべきである。
ＤＳ／ＨＡサブシステムは、以下の機能を実行する。
・各ＰＮの健康を監視する。
・スプリット・ブレイン・シンドロームを防止するため、クラスタ・クォーラムを確立して維持する。
・必要な状態移行を生じさせるため、イベントをＰＮに伝える。
・故障したＰＮからアクティブなＰＮへのＶＮの切り替え、および復帰の担当。
・秩序正しい起動が実行できるようにするための個々のボリュームの起動とローカルおよびグローバル完全性チェックの実行との協調。
本発明の典型的な実施の形態においては、ＤＳ／ＨＡサブシステムは、ＦＳＭおよびおそらくはＳＩＭ上で実行される。便宜上、以下の検討ではＦＳＭボードのみを考えるが、ＳＩＭボードとの相互作用も、多かれ少なかれ自然に続く。例えば、ＤＳ／ＨＡサブシステムは、１つのノードの任意のボードと他のノードの任意のボードとの間の通信を可能にすべきである。これは、例えば、ボード識別子をノード識別子とともに（あるいは両者の組み合わせを）有するアドレスの仕組みを使用し、あるいは「メッセージ形式」を備え異なるサービスのためのＦＳＭおよびＳＩＭボード・レジスタについて異なるハンドラを有しているメッセージ層を使用して行なうことができる。
図１３は、ＤＳ／ＨＡサブシステムと他の構成要素との関係を示している。見て取れるように、クラスタリング・モジュール、ＤＳ／ＨＡモジュール、および下にある相互接続との間に層状の関係が存在する。具体的には、種々のノードのクラスタリング・モジュールが、ＤＳ／ＨＡモジュールによってもたらされる抽象化層を通じてお互いに通信する。
図１４は、ＤＳ／ＨＡモジュールの関連の構成要素を示している。ＤＳ／ＨＡモジュールは、以下のモジュールを含んでいる。
・相互接続ハードウェア・モジュール：保証なしおよび保証ありの両者の順次メッセージ配信を備える基本的なデータグラム機構を実装する。欠けているセマンティクスがもしあれば、ＩＭＦ層（下記参照）に実装される。
・ノード間メッセージング設備（ＩＭＦ）モジュール：（ａ）保証ありのメッセージ配信、および（ｂ）ノードのハートビートを提供する。クラスタ・メンバーシップをサポートするより低レベルの構成要素である。
・クォーラム・モジュール（ＱＭ）：クラスタ・クォーラム機構、ならびにクラスタ結合／分離機構を提供する。実際のクラスタ・メンバーシップ情報は、ＩＭＦ内に保持される。
・メッセージング・モジュール（ＭＭ）：ユニキャスト／マルチキャストな同期／非同期のメッセージング・プリミティブ、ならびにクラスタリングおよび他のモジュールのためのイベント登録およびハンドリングを提供する。ＩＨＭが保証ありのユニキャスト・メッセージングをサポートする場合、対応するＭＭおよびＩＭＦ機能は、単純なスタッブまたはマクロである。
・構成データベース・モジュール（ＣＤＭ）：複製された、常時オンの構成データベースを提供する。任意のノードについて実施された更新が、ＭＭの上部の２相コミット機構を使用して、他のすべてのノード上に自動的に複製される。
見て取れるように、ＤＳ／ＨＡモジュールの種々の構成要素の間に層状の関係が存在する。高可用性の目的をサポートするため、高可用性のサポートに必要な構成要素が、各ノードにおいてアクティブでなければならない。
３．１．９．１ ハートビート
ハートビート機構は、所与のノードが死んでいるか、生きているのかの判断を担当する。本発明の典型的な実施の形態においては、以下の理由から、ハートビート機構がＩＭＦモジュール（ＱＭモジュールではなく）の一部である
１．ハートビート・タイムアウトの場合に、ノードは死んでいると宣告（当該ノードが「誤った」パーティションに属しているのではないことを確認するため、ＣＭモジュールと相談のうえで）され、ＩＭＦモジュールが当該ノードについて係属中のすべてのメッセージを、（エラー状態とともに）フラッシュする。これは、ＣＭモジュールとＩＭＦモジュールとの間の不一致を防止する。
２．ハートビート機構は、ノードのハートビート・タイムアウトを検出する低レベル・キープ・アライブの論理を実装し、残りのクラスタ・アルゴリズムから比較的独立している。ＱＭモジュールは、ノードが依然としてクラスタ・クォーラムの一部である（すなわち、ノードが「誤った」パーティションに属してはいない）か否かを実際に判断する。その働きは、クラスタの特定の実装に強く結び付いている。したがって、２つのモジュールを別にしておくことが理に適っている。類似のアプローチが、ＶＡＸＣｌｕｓｔｅｒｓ［Ｄａｖｉｓ １９９３］によって使用されている。
３．１．９．２ 故障回復
ＨＡのサポートおよび個々のノード故障からの回復は、ストレージ・リソース（ボリューム）をそれらのオーナとして機能する「仮想ノード」（ＶＮ）へと関連付けることにある。ＶＮのそれぞれは、仮想名および仮想ＩＰアドレスを有しており、物理ノード（ＰＮ）に関連付けられている。ＨＡサブシステムがＰＮの故障を検出したとき、ＨＡサブシステムは、典型的には、当該ＰＮをシャットダウン（すでに死んでいる場合を除く）させ、故障したＰＮに関連付けられているＶＮを他の利用可能なＰＮへと移動（連結）させる。この移行は自動的であるが、故障はアプリケーションにとって完全にトランスペアレントではない。換言すれば、リカバリの進行中にアプリケーションがタイムアウトになる可能性があり、これはアプリケーションから見ることができる。しかしながら、アプリケーションは、同じ仮想名および同じ仮想アドレスを通じてアクセスしていたストレージへのアクセスを続け、この組が、他の物理ノードにトランスペアレントに関連付けられる。
フェイルバックは、ＶＮを故障の発生前それらをサポートしていたＰＮへと復帰させることからなる。自動および手動フェイルバックの両方を生じさせることが可能である。これは、修復されたノードをオンラインに戻し、機能を実行しているすべてのノードの間に分散するために重要である。自動フェイルバックであっても、クライアント・アプリケーション内で検出されうる一時的中断を生じるため、手動のフェイルバックが、それが、活動のフェイルバック実行前の静かな停止を可能にして、アプリケーションにおけるいかなる形式の中断をも防止するため、典型的な選択であると予想される。
２つ以上のノードを有するクラスタは、常に冗長である。したがって、１つのユニットが故障した場合の性能の低下を回避するため、予備のユニットを設けることができる。しかしながら、それは、クラスタ全体の可用性を向上させるためだけに設ける必要はない。
この構造は、以下のサポートに好適である。
・高度な冗長性を備える完全に成熟したクラスタ構成。
・限られたノード数のローエンド・クラスタ構成。
・各ノードが故障したノードによって管理されていたボリュームの管理を引き継ぐことができる簡単なローエンド・アクティブ／アクティブなフェイルオーバ構成。しかしながら、そのような構成は、個々の集合していないボリュームを直接エクスポートすることを選択するかもしれない。
３．２ 要約
以上説明したアーキテクチャは、第１に、要求を複数のクラスタ・ノードへと並列に配ることによって、拡張可能な性能をもたらすことを目的にしている。加えて、可用性も向上する。
このソリューションは、主に、パス名を、ＳＬを使用して、物理ファイル・アロケーションから分離させるというアイデアに基礎を置いており、多ボリューム操作についてであっても、複雑な分散ロッキングの仕組みという犠牲を払うことなく、最大の並列性が達成できる。
このアーキテクチャは、個々のボリューム内において厳格なファイル・システム完全性をサポートし、ボリュームを横断していくぶんか緩いファイル・システム完全性をサポートする。しかしながら、後者が不整合なビューを生じさせることも、データ変造を生じさせることも決してなく、せいぜい参照されていないＦＳＯまたはダングリングなＳＬの削除を遅らせるという影響を有する程度である。
このプロジェクトの段階Ｉの後のさらなる発展は、以下を目標とすることができる。
・使用統計にもとづくファイルの自動リロケーション。これにより、観測された使用パターンを利用してファイルの存在位置を改善することができる。
・クラスタのマージ。独立したクラスタを１つに合体させるための方法が存在すべきである。
・性能評価およびボトルネックの特定にもとづくさまざまな最適化。
４ 実装上の問題
このセクションでは、種々の実装上の問題を取り扱う。
４．１ クラスタ内相互接続
クラスタ・メンバーが効率的に通信できるために、好ましくは、高速なプライベート通信チャネルが、クラスタ・ノードを相互接続するために使用される。プライベート（すなわち、クラスタ・ノードのみが利用可能であり、クラスタ・クライアントは利用できない）チャネルは、クラスタのあらゆるトランザクションに関与する当事者について認証および許可のチェックを不要にすることによって、通信プロトコルを能率化する。
クラスタ内に、論理的に別個な２つのクラスタ内リンクが存在する。１つ目はＦＳＭ間であり、２つ目はＳＩＭ間である。各クラスタ・ノードからの２つの物理的な相互接続が存在するであろう。物理的な相互接続への論理リンクのマッピングは、相互接続の可用性および相互接続の負荷によって決められる。
クラスタ内において、クラスタ・ノードを相互接続するために２つの相互接続スイッチを使用できる。各クラスタ・ノードからの２つの相互接続のそれぞれは、異なる相互接続スイッチに接続される。これが、スイッチおよびリンクのいくらかの冗長性をもたらす。
各クラスタ・ノードは、クラスタ内制御ブロックを有するであろう。このクラスタ内制御ブロックは、典型的には、ＦＳＭまたはＳＩＭのいずれかに実装される。クラスタ内制御ブロックは、ＦＳＭ論理リンク・インターフェイス、ＳＩＭ論理リンク・インターフェイス、ならびにクラスタ間相互接続０およびクラスタ間相互接続１と称される２つのクラスタ間相互接続を含むであろう。物理的な相互接続への論理リンクのマッピングは、動的に実装されるであろう。このようにして、或る程度の負荷バランスが、必要とされる相互接続の冗長性とともにもたらされる。
ＦＳＭ間のリンクは、ＷＦＳ要求ミラーリング（安定なストレージ・ソリューションを実現するため）、メタデータ・キャッシュ管理（コヒーレンシ、ロックの要求および応答、など）、ボリューム・オーナへの書き込み要求の転送、および一般的なクラスタ管理などの機能をサポートするため、メッセージおよびデータを運ぶであろう。
ＳＩＭ間のリンクは、ファイル・データの転送を含むセクタ・データ・キャッシュ管理（コヒーレンシ、ロックの要求および応答、など）のための機能をサポートするため、メッセージおよびデータを運ぶであろう。
４．２ クライアントの結び付け
ファイルが常に指定のクラスタ・ノードを通じて書き込まれることを確実にすることによって、性能を向上させることができる。
理想的には、ファイルを、それらが存在しているボリュームを「所有」しているクラスタ・ノードを通じての書き込みのためだけに開かれることで、これがなされる。これは、些細なことではない。困難性は、特定のファイル・パス名が検出されたときに、当該要求が適切なクラスタ・ノードへと送られるように、要求パケットのすべてを処理しなければならないという点にある。これは、非標準スイッチとクラスタ・ノードとの間の密な一体化を通じて達成できる。
他の（より最適ではない）ソリューション（「クラスタ・ノード親和性」基準と称される）が、所与のクライアントがクラスタ・サーバとして常に同じノードを使用するようクライアントをクラスタ・ノード間にパーティショニングすることによって、基本的に同じ利益をもたらす。このソリューションが基本的に同じ利益をもたらす理由は、所与のクライアントが同じファイルに何度も繰り返しアクセスする傾向にある（すなわち、参照の局在性）からである。
クライアントは、さまざまなやり方でクラスタ・ノード間にパーティショニングできる。
・クラスタ・ノードをクライアント−ベースで割り当てることによって。
・クラスタ・フロントエンドとして機能して適切なクライアント・パーティショニングの提供を担当するスイッチを設置するハードウェア−ベースのソリューションによって。
・ＤＮＳサーバの適切な設定によって。
・クラスタ・ノードに実装されたアドホック・ソフトウェアによって。
クライアントを個々のクラスタ・ノードに結び付けるにあたって満足しなければならないいくつかの制約は、次のとおりである。
１．当該ソリューションが、所与のクライアントが常に同じノードを自身のクラスタ・サーバとして使用するように、クライアントをクラスタ・ノード間にパーティションしなければならない。
２．当該ソリューションが、クライアントのサーバへのワイヤ・スピードでの相互接続を可能にしなければならない。
３．クライアントを物理的なクラスタ・ノードへと純粋に静的に結び付けるだけでは、ノードの故障および引き続くクラスタの自動再構成を許容しないため、中断のない可用性を保証するために不充分である。したがって、当該ソリューションが、ノード故障を考慮するため充分に柔軟でなくてはならない。
４．クラスタ・ノードへのクライアントの結びつきを保証する能力は、故障は別にして、長い時間期間にわたって一貫して生じるようなものでなくてはならない。例えば、数時間または数日に限られたクライアント−サーバの結びつきは、決定論的な性能向上をもたらすために充分ではない。
５．選択されたソリューションがハードウェア−ベースであろうと、ソフトウェア−ベースであろうと、高可用性の要件を満足するためには、当該ソリューションが故障の単独点を回避できていなければならない。
これらの要件に加え、クライアントの組が、共通のファイルの組にそれらが存在するボリュームを「所有」しているクラスタ・ノードを通じてアクセスしてこれを変更し、さらに同じクラスタ・ノードを共有することが望まれる。
クライアントを、クラスタ・ノード間でパーティションするため、要求を発しているクライアントを認識する機構が必要とされる。これを行なうための１つの方法は、要求を行なっているクライアントのＭＡＣ（メディア・アクセス制御）アドレスへとアクセスすることである。残念なことに、ＭＡＣアドレスそのものは、それをルーティング境界を横切るようにはしない。一方で、以下の問題を生じさせるものの、ソースＩＰアドレス（経路付けされている）を使用することができる。
１．複数のクライアントがプロキシを通じて当該クラスタにアクセスする場合、ソースＩＰ認識が正確に機能するためには、特定のプロキシを通じて集中したすべてのクライアントについて、同じクラスタ・ノードを共有することが必要である。プロキシが、同じノードへとアクセスすべきクライアントを集合させるために使用される場合、プロキシの存在は、きわめて異なるソースＩＰアドレスを有するクライアントを一体にまとめるうえで好都合かもしれない。
２．ＤＨＣＰ（動的ホスト構成プロトコル）が使用されている場合、ＤＨＣＰサーバによって管理されているＩＰアドレス空間を小さなセグメントにパーティションし、アドレス・セグメントがクラスタ・ノードの親和性にもとづいて割り当てられるようにする必要がある。換言すれば、各セグメントが、特定のクラスタ・ノードとやり取りをする必要があるすべてのクライアントを含むべきであり、なぜならば、それらがファイルおよびディレクトリの所与のセットにアクセスする傾向があるためである。したがって、ＩＰアドレスの動的割り当てが何であれ、その範囲を完全に認識し、適切に扱うことが可能である。
これらの問題は、適切な構成によって対処可能であることに注意すべきである。
４．２．１ クライアント−ベースのソリューション
このソリューションは、クラスタが含まれているネットワークの適切な構成によって得られる。それは、以下の原理にもとづいている。
・各クラスタ・ノードに、物理ＩＰアドレスならびに仮想ＩＰアドレスおよび名前が割り当てられている。この仮想アドレスは、最初はそれらのオーナ・ノードに結び付けられている。
・クライアントが、いくつかの基準に従ってクラスタ・ノードを横断してパーティションされる。例えば、クライアントを、クライアントが共通のファイルまたはディレクトリへの書き込みアクセスを共有しなければならない必要性に従って、クラスタ・ノードを横断してパーティションできる。そのようなクライアントのグループのそれぞれが、自身の所有するボリューム内に共有ファイルおよびディレクトリを割り当てるノードを特定する１つの仮想名へのアクセスを与えられる。
・クラスタ・ノードが故障したとき、ＶＮ／ＰＮの関係のため、セクション３．１．９で説明したとおりスイッチオーバがクライアントにとってトランスペアレントである。
クライアント−ベースのソリューションのいくつかの利点には、次のものが含まれる。
・簡潔であって、単刀直入である。
・追加の設備を必要としないため、安価であり、システム全体の可用性に影響を及ぼさない。
・クライアントとサーバ・ノードとの間に設備もソフトウェアも挿入しないため、性能を低下させる可能性がない。
・スイッチや追加の経路付け装置を使用しないため、クライアント・ネットワークとの互換性または一体化についての問題がない。
・クラスタの再構成がトランスペアレントである（ハードウェア−ベースのソリューションにも存在するクラスタ再構成に要する短いインターバルを除く）。
クライアント−ベースのソリューションのいくつかの欠点には、次のものが含まれる。
・ネットワークが、背後にクラスタ・ノードを隠しているスイッチに割り当てられた１つのアイデンティティではなく、多数の仮想ノード・アイデンティティを承知していなければならない。
・このソリューションの負担が、構成の問題に移されている。しかしながら、スイッチ−ベースのソリューションでは、これがスイッチそのものを構成することによって対処される一方で、ここでは、クライアントが適切に設定されなければならない。この負担は、構成プロセスを容易にする適切な管理ユーティリティを提供することによって、いくぶんか軽減できる。
４．２．２ スイッチ−ベースのソリューション
スイッチを使用することによって、クライアントは、ただ１つの名前／ＩＰアドレスによってクラスタ全体をアドレスすることができ、スイッチが、適切なノードへのトランスペアレントなアクセスを管理する。
主要なスイッチ製造者が、クライアントをサーバの集合体を横断して分配でき、かつ或る種の連続性（または「粘着性」）を保証できるイーサネット（登録商標）・スイッチを供給している。
サーバ負荷バランス（ＳＬＢ）の問題に対処する多くのスイッチは、サーバの集合体をスイッチの背後に隠す能力を可能にし、負荷をバランスさせるため要求を種々のサーバへとアドレスする能力を可能にしている。
これを行なう１つの方法は、パケットを特定の１つのサーバへと送信するため、クライアントのソースＩＰアドレスを使用することである。これは、各サーバの実際の負荷を考慮に入れていない点で、かなり静的な形式のバランスである。一方で、それは、所与のクライアントが常に同じサーバと通信することを保証し、コンテクストがすでにアクティブでありうる存在しているものをすべて利用する。
多くのスイッチは、負荷を動的にバランスさせかつ粘着性を提供するはるかに洗練された仕組みを提供し、１つのパケットが所与のソースから所与のサーバへと送信され、所定に時間間隔内で続くすべてのパケットも、当該サーバへと向かう。
永続的な接続を提供するためにしばしば使用される他の仕組みは、以下のように実装される。
・「クッキー」の使用による方法。クッキーは、サーバによって供給され、ブラウザによってクライアント内に保存されるトークンである。それらは、スイッチがコンテクストを推論してサーバへの適切な結びつきを確立できるようにする充分な参照情報をもたらす。これは、基本的に、ＨＴＴＰトラフィックに適用される。
・ＳＳＬセッションＩＤによる方法。これは、ＳＳＬセッションにのみ適用される。
・コンテクストに依存したパケット検査による方法。これは、使用中のアプリケーション・プロトコルに大きく依存し、Ｗｅｂサービスには限られない。
各クライアントが特定のクラスタ・ノード（単に集合体のメンバーである任意のノードではなく）に接続される必要があるため、これらの規準はあまり関係がない。特定のソースＩＰアドレスを特定のクラスタ・ノードに結び付けることが適切であるが、そのようなソリューションをスイッチがサポートしないかもしれず、いくつかのスイッチが適切な構成を通じてサポートするかもしれない。
ＳＬＢ能力を有する大部分のスイッチが、パケット内のソースＩＰアドレスのフィルタ処理、および要求されたサービスを提供するための集合体のサーバの１つへのパケットの経路付けを可能にする。これは、適切な構成エントリを通じてなされる。これを利用するため、集合体は、クライアント・アドレスの各組についてただ１つのサーバに制限されるべきである。結び付けは、クラスタＨＡサブシステムを通じて管理される仮想ＩＰアドレスに関して生じるべきである。これにより、ＨＡサブシステムが、ノード故障の場合にクラスタを適切に再構成でき、当該仮想ＩＰアドレスを故障ノードの機能を引き継いだノードによって再使用できるようにする。
スイッチ−ベースのソリューションのいくつかの利点には、次のものが含まれる。
・スイッチに関連付けられたただ１つのＩＰアドレス／名前を発行すればよい。スイッチそのものがクラスタ・ノードを隠し、それが構成されたやり方に従ってトラフィックを経路付けする。
・中央集権化された構成によって、全所有コストが低減される。
・スイッチによって、顧客のネットワーク設定の大きな変更を回避でき、したがって極めて望ましい。
スイッチ−ベースのソリューションのいくつかの欠点には、次のものが含まれる。
・スイッチ−ベースのソリューションは、一般に、ソフトウェア−ベースまたは構成ベースのソリューションよりも高価である。
・高可用性要件を満足させるため、スイッチ配置構成が冗長性を有していなければならず、さらにコストを増大させる。
・必要な特徴をさまざまな供給元から入手することができるが、以下に述べるとおり、それらは標準的な設備ではなく、継続的に入手可能であるかについて保証がない。
・或る特定の供給元からのスイッチを選択することが、別の供給元を標準としているユーザにとって受け入れられない。一方、複数の供給元からのスイッチを適用可能にすることは、余分な努力とコストを必要とする。
以下の検討は、前記クライアント結び付け要件を満足することができるいくつかのＳＬＢスイッチについての詳細を提供する。
５ 多ボリューム操作のための故障回復
このセクションでは、多ボリューム操作において生じうる考えられるいくつかのノード故障（ノード・クラッシュ）について、典型的な故障回復手順を説明する。セクション３．１．４で説明した多ボリューム操作のそれぞれ、および故障のそれぞれについて、典型的な回復の動作を示す。下記の表において、「ローカル・ノード」は「コーディネータ・ノード」の別名であって、ローカル・ノードが要求された操作を実行している（おそらくは他の要求者の代理として）ノードであることを意味している。
このセクションは、再試行の場合にとられる動作を含んでおらず、すなわち、アプリケーション・ノードが要求を再試行しないと仮定している（これは、ｒｅｔｒｙ＝１のＮＦＳソフト・マウントについて生じる可能性があり、あるいはアプリケーション・ノードがＮＡＳへの要求を送信した直後にクラッシュする場合に生じうる）。
表中の各動作に組み合わされている番号は、セクション３．１．４中の対応する擬似コードの命令文番号である。
故障の列中の「Ｘ」は、回復動作が不要であることを示している。
動作が示されていない行は、操作間における故障の状態を表わしている。
５．１ 外部（リモート）ディレクトリ内に（ローカル）ＦＳＯを生成（３．１．４．１）
Figure 0004480153
 ５．２ 既存の（リモート）ファイルへの（ローカル）ＳＬの生成（３．１．４．２）
Figure 0004480153
 ５．３ （リモート）ディレクトリから非共存在（ローカル）ディレクトリへの（リモート）ファイルまたはディレクトリのリネーム／移動（３．１．４．３）
Figure 0004480153
 ５．４ 既存のファイルまたはディレクトリを指しているＳＬのリネーム／移動（３．１．４．４）
この操作は、２つの異なる場合を有する。場合１は、目的地ボリュームがＦＳＯを保持しているボリュームである場合である。場合２は、目的地、ソース、およびＦＳＯボリュームが異なっている場合である。
場合１については、初期状態が図９に示されており、最終の状態が図１０に示されている。これを念頭に置き、故障分析は以下のとおりとなる。
Figure 0004480153
 場合１については、初期状態が図１１に示されており、最終の状態が図１２に示されている。これを念頭に置き、故障分析は以下のとおりとなる。
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
Figure 0004480153
 ５．５ ファイルまたはディレクトリへのＳＬの削除（３．１．４．５）
Figure 0004480153
 ６．０ その他
以上、本発明のさまざまな実施の形態を、ＦＳＭ、ＳＩＭ、およびＮＩＭなどの種々のモジュールを含む特定のハードウェア−ベースのファイル・システム・プラットフォームに関して説明したが、本発明がここに記載した実施の形態またはプラットフォームに限られるものでは決してなく、本発明を他のやり方で具現化し、他のファイル・システム・プラットフォームに広く一般的に適用できることは、当業者であれば明らかである。
本発明は、決してこれらに限られるわけではないが、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）とともに使用するコンピュータ・プログラム・ロジック、プログラマブル論理デバイス（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のＰＬＤ）とともに使用するプログラマブル・ロジック、複数の個別の素子の集まり、集積回路（例えば、特定用途向け集積回路（ＡＳＩＣ））、またはこれらの組み合わせを含む他の任意の手段を含む多くの別の形式で具現化できる。本発明の典型的な実施の形態においては、広く多数のボリュームを横断してファイル・システム・オブジェクトを管理するためのロジックのすべてが、コンピュータで実行可能な形式に変換され、それ自体がコンピュータで読み出し可能な媒体内に保存され、オペレーティング・システムの制御のもとでクラスタ・ノード内のマイクロプロセッサによって実行されるコンピュータ・プログラム・インストラクションの組として実装される。
本明細書ですでに説明した機能のすべてまたは一部を実装するコンピュータ・プログラム・ロジックは、決してこれらに限られるわけではないが、ソースコード形式、コンピュータによって実行できる形式、および種々の中間的形式（例えば、アセンブラ、コンパイラ、リンカ、またはロケータによって生成された形式）を含むさまざまな形式で具現化できる。ソースコードは、さまざまなオペレーティング・システムまたは動作環境における使用のため、さまざまなプログラミング言語（例えば、オブジェクト・コード、アセンブリ言語、あるいはＦｏｒｔｒａｎ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、またはＨＴＭＬなどの高級言語）の任意のいずれかで実装された一連のコンピュータ・プログラム・インストラクションを含むことができる。ソースコードは、さまざまなデータ構造および通信メッセージを規定して使用することができる。ソースコードは、コンピュータで実行可能な形式（例えば、インタプリタを介して）であってよく、あるいはソースコードがコンピュータで実行可能な形式に変換（例えば、トランスレータ、アセンブラ、またはコンパイラによって）されてもよい。
コンピュータ・プログラムは、任意の形式（例えば、ソースコード形式、コンピュータで実行可能な形式、または中間的な形式）で、恒久的または一時的に、半導体記憶装置（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュ・プログラマブルＲＡＭ）、磁気記憶装置（例えば、ディスケットまたは固定ディスク）、光学式記憶装置（例えば、ＣＤ−ＲＯＭ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、または他の記憶装置などの有形の記憶媒体に固定することができる。コンピュータ・プログラムは、これらに限られるわけではないが、アナログ技術、デジタル技術、光技術、無線技術（例えば、ブルートゥース）、ネットワーク技術、およびインターネットワーク技術を含むさまざまな通信技術のいずれかを使用してコンピュータへと伝達できる信号として任意の形式で固定できる。コンピュータ・プログラムは、印刷文書または電子文書が添付された持ち運び可能な記憶媒体（例えば、シュリンク包装されたソフトウェア）として任意の形式で配布でき、コンピュータ・システムにあらかじめ搭載（例えば、システムＲＯＭまたは固定ディスクに）でき、あるいは通信システム（例えば、インターネットまたはワールド・ワイド・ウェブ）を通してサーバまたは電子掲示板から配布できる。
本明細書ですでに説明した機能のすべてまたは一部を実装するハードウェア・ロジック（プログラマブル・ロジック・デバイスで使用するプログラマブル・ロジックを含む）は、従来からの手動による方法を使用して設計でき、あるいはコンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えば、ＶＨＤＬまたはＡＨＤＬ）、またはＰＬＤプログラミング言語（例えば、ＰＡＬＡＳＭ、ＡＢＥＬ、またはＣＵＰＬ）などのさまざまなツールを使用して電子的に設計し、保存し、模擬し、あるいは記録することができる。
プログラマブル・ロジックは、恒久的または一時的に、半導体記憶装置（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュ・プログラマブルＲＡＭ）、磁気記憶装置（例えば、ディスケットまたは固定ディスク）、光学式記憶装置（例えば、ＣＤ−ＲＯＭ）、または他の記憶装置などの有形の記憶媒体に固定することができる。プログラマブル・ロジックは、決してこれらに限られるわけではないが、アナログ技術、デジタル技術、光技術、無線技術（例えば、ブルートゥース）、ネットワーク技術、およびインターネットワーク技術を含むさまざまな通信技術のいずれかを使用してコンピュータへと伝達できる信号に固定できる。プログラマブル・ロジックは、印刷文書または電子文書が添付された持ち運び可能な記憶媒体（例えば、シュリンク包装されたソフトウェア）として配布でき、コンピュータ・システムにあらかじめ搭載（例えば、システムＲＯＭまたは固定ディスクに）でき、あるいは通信システム（例えば、インターネットまたはワールド・ワイド・ウェブ）を通してサーバまたは電子掲示板から配布できる。
本発明は、本発明の本当の技術的範囲を離れることなく、他のいくつかの特定の形式で具現化できる。ここに記載した実施の形態は、あらゆる点に関し、例示として理解すべきであり、本発明を限定するものと考えるべきではない。
本発明の前記の特徴は、添付の図面を参照しつつ以下の詳細な説明を参照することによって、より容易に理解されるであろう。
図１は、本発明の種々の態様を適用することができるファイル・サーバの一実施の形態のブロック図である。 図２は、図１の実施の形態の実装例のブロック図である。 図３は、本発明の一実施の形態による複数のボリュームを横切ってサポートされたただ１つのファイル・システム・イメージを描いたダイアグラムである。 図４は、図３の論理階層に従いハード・リンクおよびスクイジー・リンクによって実装された論理名前空間を描いたダイアグラムである。 図５は、本発明の一実施の形態による外部書き込み要求の取り扱いを描いたダイアグラムであり、目標ボリュームを所有するノードへと転送されるときにローカル・キャッシュをバイパスしている。 図６は、本発明の一実施の形態による外部読み出し要求の取り扱いを描いたダイアグラムであり、ローカル・メタデータおよびローカル・セクタ・キャッシュの両方を使用している。 図７は、ローカル・ボリュームおよびリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが本発明の一実施の形態に従ってローカル・ボリュームによってリネームされる前の状態であり、ファイル・システム・オブジェクトが、リモート・ボリューム内の「通常の」ディレクトリ内のエントリによって指し示されている。 図８は、図７のローカル・ボリュームおよびリモート・ボリュームの状態を、本発明の一実施の形態によってファイル・システム・オブジェクトをリネームした後について描いたダイアグラムであり、ファイル・システム・オブジェクトが、リモート・ボリュームのＲＤ内のエントリによって指し示されており、ローカル・ボリュームが、前記リモート・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを含んでいる。 図９は、ローカル・ボリュームおよびリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが、ローカル・ボリュームのＲＤ内のエントリによって指し示されており、リモート・ボリュームが、前記ローカル・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを含んでおり、本発明の一実施の形態に従ってリモート・ボリュームからのスクイジー・リンクをリネームする前の状態である。 図１０は、図９のローカル・ボリュームおよびリモート・ボリュームの状態を、本発明の一実施の形態によってスクイジー・リンクを既存のファイル・システム・オブジェクトと共存在となるようにリネームした後について描いたダイアグラムであり、ファイル・システム・オブジェクトが、ローカル・ボリューム内の「通常の」ディレクトリ内のエントリによって指し示されており、スクイジー・リンクがリモート・ボリュームから取り除かれている。 図１１は、ローカル・ボリューム、第１のリモート・ボリューム、および第２のリモート・ボリュームの状態を描いたダイアグラムであり、ファイル・システム・オブジェクトが、第１のリモート・ボリュームのＲＤ内のエントリによって指し示されており、第２の遠各ボリュームが、前記第１のリモート・ボリュームのＲＤ内のリンクを指し示すスクイジー・リンクを有しており、本発明の一実施の形態に従って第２のリモート・ボリュームからスクイジー・リンクをリネームする前の状態である。 図１２は、ローカル・ボリューム、第１のリモート・ボリューム、および第２のリモート・ボリュームの状態を、本発明の一実施の形態に従って前記スクイジー・リンクをファイル・システム・オブジェクトと共存在にならないようにリネームした後について描いたダイアグラムであり、前記スクイジー・リンクが第２のリモート・ボリュームから取り去られ、新しいスクイジー・リンクがローカルに生成されている。 図１３は、本発明の一実施の形態による分散サービス／高可用性サブシステムと他の構成要素との間の関係を示している。 図１４は、分散サービス／高可用性サブシステムの関連構成要素を示している。

Claims (111)

  1. それぞれが複数の論理ストレージ・ボリュームへのアクセスを有している複数のクラスタ・ノードを使用して、前記ノードと通信するクライアントによる前記ボリューム上のデータへのアクセスを提供するための方法であって、
    前記方法は、
    各ボリュームを、単一のノードにより所有されるように制限することであって、ボリュームのオーナのみが前記ボリュームへの書き込みの許可を有している、こと、および
    第１のノードに、前記第１のノードが所有する第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることと、前記第１のボリュームと第２のノードが所有する第２のボリュームとの間の論理リンクを生成することとによって、ファイル・システム・オブジェクトを前記複数のボリュームを横断して保持すること
    を含んでおり、
    前記論理リンクは、前記第１のボリューム内の前記ファイル・システム・オブジェクトを参照し、
    前記第１のボリュームと前記第２のボリュームとの間の論理リンクを生成するプロセスは、前記論理リンクにより参照される前記ファイル・システム・オブジェクトを識別する論理識別子を前記第２ボリュームのディレクトリ内に生成することと、前記論理識別子と前記第２のボリュームとの間の固有の連関を前記第１のボリューム内に作成することとを含んでいる、方法。
  2. 前記論理識別子を、前記第１のボリュームのリロケーション・ディレクトリであって、前記第１のボリューム以外のボリュームから論理的に参照される前記第１のボリューム内のすべてのファイル・システム・オブジェクトについての論理識別子を列挙しているリロケーション・ディレクトリに保存すること
    をさらに含んでいる、請求項１に記載の方法。
  3. 前記第１のノードに前記ファイル・システム・オブジェクトの保存を実行させるプロセス、および前記論理リンクを生成するプロセスが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ実行される、請求項１に記載の方法。
  4. 前記プロセスを実行する過程において、前記第１のノードに前記第１および第２のボリュームのための書き込みロック・マネージャの役割を割り当てること
    をさらに含んでいる、請求項３に記載の方法。
  5. 前記リロケーション・ディレクトリが階層構造を有している、請求項２に記載の方法。
  6. 前記論理リンクを生成することが、少なくとも前記第１のボリュームにおいて固有である識別子を前記論理識別子として割り当てることを含んでいる、請求項１に記載の方法。
  7. 固有の識別子を割り当てることが、前記第１のボリューム内のファイル・システム・オブジェクトのためにすでに割り当てられた論理識別子のカウントにもとづく数字を割り当てることを含んでいる、請求項６に記載の方法。
  8. 任意のノードによる所与のストレージ・ボリュームに対する読み出しを実行可能にすること
    をさらに含んでいる、請求項１に記載の方法。
  9. 前記ボリュームのそれぞれにボリューム・キャッシュが関連付けられ、前記ノードのそれぞれにノード・キャッシュが関連付けられており、
    前記方法が、
    選択されたボリューム内のセクタを読み出すための要求であって、前記選択されたボリュームとは別個のボリュームを所有している活動ノードによって受信された要求を、
    前記活動ノードに、前記選択されたボリュームのオーナであるノードへと、前記セクタに対する第１の読み出し要求であって、読み出しのみロックを有している読み出し要求の発行を実行させ、前記選択されたボリュームへと、前記セクタに対する第２の読み出し要求の発行を実行させることと、
    前記選択されたボリュームのオーナであるノードに、自身が自身のキャッシュ内に前記セクタを有しているか否かを判断させることと、
    有していない場合に、前記読み出しのみロックを認可して前記選択されたボリュームが前記要求を満足させるようにすることと、
    有しており、かつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントを前記選択されたボリュームを所有しているノードのキャッシュから前記活動ノードへと送信し、前記要求に関する前記選択されたボリュームの通信を停止することと、
    有しており、かつ前記セクタが書き込みロックされている場合、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開することと
    によって処理することをさらに含んでいる、請求項８に記載の方法。
  10. 前記読み出しのみロックを認可がすることが、キャッシュ状態を追跡できるよう、前記活動ノードおよび前記セクタのアイデンティティを記録することを含んでいる、請求項９に記載の方法。
  11. 前記第２のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子への論理参照を保存すること
    をさらに含んでいる、請求項２に記載の方法。
  12. 前記論理参照が、
    前記論理識別子、および
    前記第１のボリュームの前記リロケーション・ディレクトリの前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値
    を含んでいる、請求項１１に記載の方法。
  13. 前記論理参照を、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記論理識別子に対する唯一無二の論理参照であるように制限すること
    をさらに含んでいる、請求項１１に記載の方法。
  14. 前記第１のノードに前記別個および選択されたボリュームのための書き込みロック・マネージャの役割を割り当てることが、
    前記第１のノードに前記第１および第２のボリュームのための書き込みロック・マネージャの役割を、書き込みロック・マネージャの役割が前記第１のノードに、前記第１のノードが前記複数のクラスタ・ノードに合流するときから前記第１ノードが前記複数のクラスタ・ノードを離れるときまで割り当てられるよう、半静的なやり方で割り当てること
    を含んでいる、請求項４に記載の方法。
  15. 前記第２のボリュームから前記論理参照を削除すること、および
    前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除すること
    をさらに含んでいる、請求項１１に記載の方法。
  16. 前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること、および
    前記第２のボリュームから前記論理参照を削除すること
    をさらに含んでいる、請求項１１に記載の方法。
  17. 前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを割り出すこと、および
    前記論理参照を前記第２のボリュームから削除すること
    をさらに含んでいる請求項１１に記載の方法。
  18. 前記論理参照が存在しないファイル・システム・オブジェクトを参照していることを割り出すことが、
    前記論理参照を折々に調べて前記論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出す清掃機プロセスを、第２において実行すること
    を含んでいる、請求項１７に記載の方法。
  19. 前記第１のボリュームの前記ファイル・システム・オブジェクトが、もはや他のボリュームのいかなる論理参照によっても参照されていないことを割り出すこと、および
    前記ファイル・システム・オブジェクトを前記第１のボリュームから削除すること
    をさらに含んでいる、請求項１１に記載の方法。
  20. 前記第１のボリュームの前記ファイル・システム・オブジェクトがもはや他のボリュームのいかなる論理参照によっても参照されていないことを割り出すことが、
    前記リロケーション・ディレクトリを折々に調べて前記ファイル・システム・オブジェクトが他のボリュームの少なくとも１つの論理参照によって参照されているか否かを割り出す清掃機プロセスを、前記第１のノードにおいて実行すること
    を含んでいる、請求項１９に記載の方法。
  21. 前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすること
    をさらに含んでいる請求項１１に記載の方法。
  22. 前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、
    前記第１のボリュームの前記リロケーション・ディレクトリに、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照を保存すること
    を含んでいる、請求項２１に記載の方法。
  23. 前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、
    前記第２のボリュームに関連付けられたボリューム識別子、および
    前記第２のボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子
    を含んでいる、請求項２２に記載の方法。
  24. 前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの参照が、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名を含んでいる、請求項２２に記載の方法。
  25. 前記第１のボリュームの「．．」ディレクトリ・エントリを、前記第２のボリューム内の前記論理参照を含んでいるディレクトリへとマッピングすることが、
    前記第１のボリュームに、前記第２のボリューム内の前記論理参照を含んでいる前記ディレクトリへの参照を含んでいる別個のファイルを保存すること
    を含んでいる、請求項２１に記載の方法。
  26. 前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、
    前記第１のボリュームの前記リロケーション・ディレクトリから前記論理識別子を削除することと、
    新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存することと、
    前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存することと
    によって、論理的にリロケートすること
    をさらに含んでいる、請求項１１に記載の方法。
  27. 前記論理参照を前記第２のボリュームの前記ディレクトリから削除すること
    をさらに含んでいる、請求項２６に記載の方法。
  28. 第３のボリュームによって前記ファイル・システム・オブジェクトを、
    新しい論理識別子を前記第１のボリュームの前記リロケーション・ディレクトリに保存することと、
    前記第３のボリュームのディレクトリに、前記第１のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を保存することと
    によって参照すること
    をさらに含んでいる、請求項１１に記載の方法。
  29. 前記第１のボリュームと前記第２のボリュームとの間の論理リンクを生成することが、
    前記ハード・リンクおよび前記論理リンクが、
    前記複数のノードの前記クライアントからは見えない物理名前空間であって、前記第１のボリュームの前記リロケーション・ディレクトリ内の前記ハード・リンクを含むハード・リンクによってファイル・システム・オブジェクトに接続される固有の内部階層をそれぞれ備えている前記複数のボリュームを通じて実装された物理名前空間、および
    前記複数のノードの前記クライアントから見える論理名前空間であって、前記ボリュームを横断して全ファイル・システムにわたって広がり、かつハード・リンクと論理リンクとの間の相違が前記クライアントから隠されるようにハード・リンクおよび論理リンクを介して接続されたファイル・システム・オブジェクトで作られている論理名前空間
    を形成することをさらに含んでいる、
    請求項１に記載の方法。
  30. 前記ファイル・システム・オブジェクトへの書き込みの要求を、前記第２のノードによって受信すること、
    前記要求を前記第１のノードへと、前記第２のノードによって転送すること、および
    前記第１のノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと
    をさらに含んでいる、請求項１に記載の方法。
  31. 前記ファイル・システム・オブジェクトへの書き込みの要求を、前記第１のノードによって受信すること、および
    前記第１のノードによって前記ファイル・システム・オブジェクトへの書き込みを行なうこと
    をさらに含んでいる、請求項１に記載の方法。
  32. 第３のノードによって前記ファイル・システム・オブジェクトを、
    前記第３のノードによって所有されている第３のボリュームへの変更済みファイル・システム・オブジェクトの保存を、前記第３のノードに実行させること、および
    前記第２のボリュームと前記第３のボリュームとの間の論理リンクを、前記論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための論理識別子を前記第２のボリューム内に提供するように生成すること
    によって変更すること
    をさらに含んでいる、請求項１に記載の方法。
  33. 前記第１のボリュームと前記第２のボリュームとの間の論理リンクを生成することが、
    前記論理リンクを生成するための要求を、前記第１のノードによって前記第２のノードへと送信すること、および
    前記要求の受信をうけて、前記第２のノードによって前記論理リンクを生成すること
    を含んでいる、請求項１に記載の方法。
  34. 前記第１のノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることが、
    前記第２のノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第１のノードによって受信すること
    を含んでいる、請求項１に記載の方法。
  35. 前記第１のノードに前記第１のボリュームへのファイル・システム・オブジェクトの保存を実行させることが、
    前記第２のノードに前記ファイル・システム・オブジェクトを生成するための要求を、前記第２のノードによって受信すること、および
    前記第１のノードに前記ファイル・システム・オブジェクトを生成すべきであることを、前記第２のノードによって判断すること
    を含んでいる、請求項１に記載の方法。
  36. 各ボリュームが固有のボリューム識別子に関連付けられており、
    前記方法が、
    前記第２のノードに、前記第１のボリュームに関連付けられた前記ボリューム識別子を含んでいる、前記ファイル・システム・オブジェクトのためのファイル・ハンドルの生成を実行させること
    をさらに含んでいる、請求項１に記載の方法。
  37. 前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノード以外のノードで受信すること、および
    前記要求を前記第２のノードへと向けること、ならびに
    前記ファイル・システム・オブジェクトを前記第２のノードによって削除すること
    をさらに含んでいる、請求項１に記載の方法。
  38. 前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノードによって受信すること、
    前記論理リンクの前記第２のノードからの除去を生じさせること、
    前記ファイル・システム・オブジェクトを削除するための要求を、前記第２のノードによって前記第１のノードへと送信すること、および
    前記ファイル・システム・オブジェクトを前記第１のノードによって削除すること
    をさらに含んでいる、請求項１に記載の方法。
  39. 前記ファイル・システム・オブジェクトが、
    ファイル、および
    ディレクトリ
    のうちの１つを含んでいる、請求項１に記載の方法。
  40. 前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと論理的にリロケートすることが、所定の条件のもとで自動的に実行される、請求項２６に記載の方法。
  41. 前記ファイル・システム・オブジェクトを、前記第１のボリュームから第３のノードによって所有されている第３のボリュームへと、
    前記第１のボリュームから前記第３のボリュームへと、前記ファイル・システム・オブジェクトのコピーを生じさせること、
    前記第１のボリュームの前記リロケーション・ディレクトリから、前記論理識別子を除去すること、
    前記第２のボリュームから、前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への論理参照を除去すること、
    前記第２のボリュームと前記第３のボリュームとの間の新しい論理リンクを、前記新しい論理リンクが前記第３のボリューム内の前記ファイル・システム・オブジェクトにアクセスするための新しい論理識別子を前記第２のボリューム内に提供するように生成すること、および
    前記第１のボリュームから前記ファイル・システム・オブジェクトを削除すること
    によってリロケートすること
    をさらに含んでいる、請求項１１に記載の方法。
  42. 前記新しい論理識別子を、前記第３のボリュームのリロケーション・ディレクトリに保存すること
    をさらに含んでいる、請求項４１に記載の方法。
  43. 前記第３のボリュームの前記リロケーション・ディレクトリに保存された前記新しい論理識別子への新しい論理参照を、前記第２のボリュームのディレクトリに保存すること
    をさらに含んでいる、請求項４２に記載の方法。
  44. 前記第１のボリュームから前記第３のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせることが、
    前記第１のボリュームから前記第３のボリュームへと、怠惰なコピー技法を使用して前記ファイル・システム・オブジェクトをコピーすること
    を含んでいる、請求項４１に記載の方法。
  45. 前記ファイル・システム・オブジェクトを、前記第１のボリュームから前記第２のボリュームへと、
    前記第１のボリュームから前記第２のボリュームへと前記ファイル・システム・オブジェクトのコピーを生じさせること、
    前記第１のボリュームの前記リロケーション・ディレクトリから、前記論理識別子を取り除くこと、および
    前記第１のボリュームの前記リロケーション・ディレクトリに保存されていた前記論理識別子への前記論理参照を、前記第２のボリュームから取り除くこと
    によってリロケートすること
    をさらに含んでいる、請求項１１に記載の方法。
  46. 前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持すること、
    前記ファイル・システム・オブジェクトに関する前記データを、前記第１のノードによって変更すること、および
    前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトに関する前記データの無効化を実行させること
    をさらに含んでいる、請求項１に記載の方法。
  47. 前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトに関する前記データの前記第１のボリュームからの再取得を実行させること
    をさらに含んでいる、請求項４６に記載の方法。
  48. 前記少なくとも１つの別のノードに、前記ファイル・システム・オブジェクトの一部分のコピーの無効化を実行させることが、
    前記ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを、前記第１のノードによって保持すること、および
    前記他のノードのそれぞれに、前記ファイル・システム・オブジェクトに関する前記データが変更された旨の告知を送信すること
    を含んでいる、請求項４６に記載の方法。
  49. 前記ファイル・システム・オブジェクトに関する前記データが、メタデータを含んでおり、
    前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
    前記メタデータを保存するためのメタデータ・キャッシュであって、ファイル・システム・オブジェクト・データのコピーを保存するために使用されるあらゆる他のキャッシュから独立して動作するメタデータ・キャッシュを、前記少なくとも１つの別のノードによって保持すること
    を含んでいる、請求項４６に記載の方法。
  50. 前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
    前記少なくとも１つの別のノードに、前記第１のノードから前記ファイル・システム・オブジェクトに関するメタデータを読み出す前に、前記第１のノードから読み取りロックを取得するよう要求すること
    をさらに含んでいる、請求項４９に記載の方法。
  51. 前記ファイル・システム・オブジェクトに関するデータが、ファイル・システム・オブジェクト・データおよびメタデータを含んでおり、
    前記ファイル・システム・オブジェクトに関するデータのコピーを、前記第１のノードとは別の少なくとも１つのノードによって保持することが、
    ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること、
    メタデータを保存するためのメタデータ・キャッシュを保持すること、および
    前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータへとマッピングすること
    を含んでいる、請求項４６に記載の方法。
  52. 前記ファイル・システム・オブジェクトが、前記第１のボリューム内の第１の名前に関連付けられており、
    前記ファイル・システム・オブジェクトを前記第１のボリュームから前記第３のボリュームへと論理的にリロケートすることが、
    前記ファイル・システム・オブジェクトを、前記第３のボリューム内の第２の名前に関連付けること
    をさらに含んでいる、請求項２６に記載の方法。
  53. １つのノードを、前記ファイル・システム・オブジェクトに作用する多ボリューム操作のためのコーディネータとして指定することをさらに含んでおり、
    前記コーディネータが、前記多ボリューム操作に関係するボリュームのうちの１つのオーナである、請求項１に記載の方法。
  54. 各ボリュームについて、ファイル・システム・オブジェクトへの参照、およびボリュームから取り除かれて前記ファイル・システム・オブジェクトへの論理リンクまたは他の論理リンクで置き換えられた論理リンクを一時的に保存するためのローカル・ディレクトリを保持すること、および
    対応するボリュームに影響する多ボリューム操作における故障からの回復のために、ローカル・ディレクトリを使用すること
    をさらに含んでいる、請求項１に記載の方法。
  55. 複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、前記ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置であって、
    前記装置は、
    固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、前記装置のみが前記データ・ストレージ・ボリュームへの書き込みを許されるよう、前記装置によって所有されているデータ・ストレージ・ボリューム、
    前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ、および
    前記データ・ストレージ・ボリューム内にファイル・システム・オブジェクトを保存し、さらに前記装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照、および他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するため、作用可能に組み合わされたオブジェクト・ストレージ・ロジック
    を有している、装置。
  56. 前記論理参照のそれぞれが、他のノードによって所有されているデータ・ストレージ・ボリュームに保存された参照されているファイル・システム・オブジェクトを識別するための論理識別子を有し、
    前記ハード参照のそれぞれが、対応するペアレント・ノードによる対応するファイル・システム・オブジェクトを識別するための論理識別子を有している
    請求項５５に記載の装置。
  57. 前記オブジェクト・ストレージ・ロジックが、多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、前記データ・ストレージ・ボリュームに前記ファイル・システム・オブジェクトを保存し、前記少なくとも１つのディレクトリに前記参照を保存するため、作用可能に組み合わされている、請求項５５に記載の装置。
  58. 前記操作を実行する過程において、前記オブジェクト・ストレージ・ロジックに前記種々のデータ・ストレージ・ボリュームのための書き込みロック・マネージャの役割が割り当てられる、請求項５７に記載の装置。
  59. 前記少なくとも１つのディレクトリが、前記ハード参照を保存するため、階層構造を有するリロケーション・ディレクトリを有している、請求項５６に記載の装置。
  60. 前記オブジェクト・ストレージ・ロジックが、ハード参照のそれぞれについて前記論理識別子を、前記論理識別子のそれぞれが前記データ・ストレージ・ボリューム内において固有であるように割り当てるため、作用可能に組み合わされている、請求項５６に記載の装置。
  61. 前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のファイル・システム・オブジェクトにすでに割り当てられた論理識別子のカウントにもとづいて固有の識別子を割り当てるため、作用可能に組み合わされている、請求項６０に記載の装置。
  62. 前記オブジェクト・ストレージ・ロジックが、前記ノードのいずれかによる前記データ・ストレージ・ボリュームの読み出しを実行可能にするため、作用可能に組み合わされている、請求項５５に記載の装置。
  63. ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュをさらに有しており、
    前記オブジェクト・ストレージ・ロジックが、他のノードによって所有されているデータ・ストレージ・ボリューム内のセクタを読み出すための要求を、
    前記セクタについての第１の読み出し要求であって、読み出しのみロックを有している読み出し要求を、前記他のノードへと発行し、前記セクタについての第２の読み出し要求を、前記他のノードによって所有されている前記データ・ストレージ・ボリュームへと発行すること
    によって処理するため、作用可能に組み合わされている
    請求項６２に記載の装置。
  64. ノード・キャッシュおよび前記データ・ストレージ・ボリュームに関連付けられたボリューム・キャッシュをさらに有しており、
    前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリューム内のセクタについての読み出し要求であって、読み出しのみロックを有している読み出し要求を、
    前記セクタが前記ボリューム・キャッシュに保存されているか否かを判断することと、
    保存されていない場合に、前記読み出しのみロックを認可して前記要求を満足させることと、
    保存されており、かつ前記セクタが書き込みロックされていない場合に、前記読み出しのみロックを認可して前記セクタのコンテントをキャッシュから送信することと、
    保存されており、かつ前記セクタが書き込みロックされている場合に、前記読み出しのみロックの認可が可能になるまで前記要求についての肯定的動作を引き延ばし、次いで前記セクタが書き込みロックされていないときに至って処理を再開することと
    によって処理するため、作用可能に組み合わされている、請求項６２に記載の装置。
  65. 前記オブジェクト・ストレージ・ロジックが、キャッシュ状態を追跡できるよう前記読み出しのみロックの認可時に前記他のノードおよび前記セクタのアイデンティティを記録するため、作用可能に組み合わされている、請求項６４に記載の装置。
  66. 論理参照のそれぞれが、他のノードのデータ・ストレージ・ボリュームのリロケーション・ディレクトリ内の対応するエントリを参照している、請求項５６に記載の装置。
  67. 論理参照のそれぞれが、
    前記他のノードのデータ・ストレージ・ボリュームの前記リロケーション・ディレクトリ内の前記参照されているファイル・システム・オブジェクトの名前を表わしている数値列を符号化する数値
    をさらに有している、請求項６６に記載の装置。
  68. 前記オブジェクト・ストレージ・ロジックが、各ハード参照について対応するペアレント・ノードへと戻る参照を保持するため、作用可能に組み合わされている、請求項５５に記載の装置。
  69. 前記対応するペアレント・ノードへと戻る参照が、
    前記ペアレント・ノードのデータ・ストレージ・ボリュームに関連付けられたボリューム識別子、および
    前記ペアレント・ノードのデータ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリに関連付けられたノード識別子
    を有している、請求項６８に記載の装置。
  70. 前記対応するペアレント・ノードへと戻る参照が、
    前記ペアレント・ノードの前記データ・ストレージ・ボリューム内の前記論理参照を含んでいるディレクトリへの可変長パス名
    を有している、請求項６８に記載の装置。
  71. 前記オブジェクト・ストレージ・ロジックが、前記対応するペアレント・ノードへと戻る参照を、前記少なくとも１つの内のハード参照とともに保存するため、作用可能に組み合わされている、請求項６８に記載の装置。
  72. 前記オブジェクト・ストレージ・ロジックが、前記対応するペアレント・ノードへと戻る参照を、前記データ・ストレージ・ボリューム内の別個のファイル・システム・オブジェクトとして保存するため、作用可能に組み合わされている、請求項６８に記載の装置。
  73. 前記オブジェクト・ストレージ・ロジックが、新しいファイル・システム・オブジェクトを、
    新しいファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームに保存すること、
    前記新しいファイル・システム・オブジェクトへのハード参照について、論理識別子を割り当てること、
    前記新しいファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存すること、および
    前記新しいファイル・システム・オブジェクトへの論理参照を、他のノードによって所有されているデータ・ストレージ・ボリュームによって生成するため、前記他のノードに前記論理識別子を提供すること
    によって生成するため、作用可能に組み合わされている、請求項５５に記載の装置。
  74. 前記オブジェクト・ストレージ・ロジックが、前記装置がペアレント・ノードであると考えられるファイル・システム・オブジェクトを、
    前記ファイル・システム・オブジェクトを前記データ・ストレージ・ボリュームから削除すること、および
    前記ファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリから削除すること
    によって削除するため、作用可能に組み合わされている、請求項５５に記載の装置。
  75. 前記オブジェクト・ストレージ・ロジックが、前記削除されたファイル・システム・オブジェクトへの論理参照を前記対応するペアレント・ノードに削除させるため、作用可能に組み合わされている、請求項７４に記載の装置。
  76. 前記オブジェクト・ストレージ・ロジックが、他のノードがペアレント・ノードであると考えられるファイル・システム・オブジェクトを、
    削除されるファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリから削除すること
    によって削除するため、作用可能に組み合わされている、請求項５５に記載の装置。
  77. 前記オブジェクト・ストレージ・ロジックが、もはや前記データ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについてのハード参照を削除するため、作用可能に組み合わされている、請求項５５に記載の装置。
  78. 前記オブジェクト・ストレージ・ロジックが、前記ハード参照を折々に調べて前記ハード参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを有している、請求項７７に記載の装置。
  79. 前記オブジェクト・ストレージ・ロジックが、もはや他のノードのデータ・ストレージ・ボリューム中に存在しないファイル・システム・オブジェクトについての論理参照を削除するため、作用可能に組み合わされている、請求項５５に記載の装置。
  80. 前記オブジェクト・ストレージ・ロジックが、前記論理参照を折々に調べて前記論理参照が参照しているファイル・システム・オブジェクトが存在するか否かを割り出すための清掃機プロセスを有している、請求項７９に記載の装置。
  81. 前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを他のノードへと、
    前記ファイル・システム・オブジェクトへのハード参照のために論理識別子を割り当てることと、
    前記ファイル・システム・オブジェクトへの前記ハード参照を、前記少なくとも１つのディレクトリに保存することと、
    前記ファイル・システム・オブジェクトへの論理参照を、前記他のノードによって所有されているデータ・ストレージ・ボリュームによって生成するため、前記他のノードに前記論理識別子を提供することと
    によってリロケートするため、作用可能に組み合わされている、請求項５５に記載の装置。
  82. 前記オブジェクト・ストレージ・ロジックが、他のノードのデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトを、
    前記他のノードから論理識別子を入手すること、および
    前記論理識別子を含んでいる論理参照を前記少なくとも１つのディレクトリに保存すること
    によってリロケートするため、作用可能に組み合わされている、請求項５５に記載の装置。
  83. 他のノードに保存されたファイル・システム・オブジェクトに関するデータのコピーを保存するため、少なくとも１つのキャッシュをさらに有しており、
    前記オブジェクト・ストレージ・ロジックが、特定のファイル・システム・オブジェクトが前記ファイル・システム・オブジェクトが保存されているノードによって変更されたことを知ったときに、前記ファイル・システム・オブジェクトに関するデータのコピーを無効化するよう、作用可能に組み合わされている、請求項５５に記載の装置。
  84. 前記オブジェクト・ストレージ・ロジックが、前記ファイル・システム・オブジェクトに関するデータを再取得するよう、作用可能に組み合わされている、請求項８３に記載の装置。
  85. 前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存された各ファイル・システム・オブジェクトについて、前記ファイル・システム・オブジェクトに関するデータのコピーを有している他のノードのリストを保持し、特定のファイル・システム・オブジェクトが変更されたときに前記他のノードのそれぞれに通知を行なうよう、作用可能に組み合わされている、請求項５５に記載の装置。
  86. 前記少なくとも１つのキャッシュが、ファイル・システム・オブジェクトに関連付けられたメタデータのコピーを保存するためのメタデータ・キャッシュを有しており、
    前記オブジェクト・ストレージ・ロジックが、前記メタデータ・キャッシュをファイル・システム・オブジェクト・データのコピーを保存するために使用される他のあらゆるキャッシュから独立して動作させるよう、作用可能に組み合わされている、請求項８３に記載の装置。
  87. 前記オブジェクト・ストレージ・ロジックが、前記データ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトに関するメタデータを読み出す前に読み取りロックを取得するよう他のノードに要求するため、作用可能に組み合わされている、請求項８６に記載の装置。
  88. 前記少なくとも１つのキャッシュが、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュおよびメタデータを保存するためのメタデータ・キャッシュを有しており、
    前記オブジェクト・ストレージ・ロジックが、前記データ・キャッシュ内の各データを前記メタデータ・キャッシュ内の対応するメタデータへとマップするよう、作用可能に組み合わされている、請求項８３に記載の装置。
  89. 前記少なくとも１つのディレクトリが、ローカル・アンドゥ・ディレクトリを含んでおり、
    前記オブジェクト・ストレージ・ロジックが、ファイル・システム・オブジェクトへの参照、および論理参照で置き換えられた論理参照または他の論理参照を、前記ローカル・アンドゥ・ディレクトリに一時的に保存し、前記データ・ストレージ・ボリュームに影響する多ボリューム操作における故障からの回復のために、前記ローカル・アンドゥ・ディレクトリを使用するよう、作用可能に組み合わされている、請求項５５に記載の装置。
  90. 複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、前記ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタにおいて、クラスタ・ノードとして動作するための装置であって、
    前記装置は、
    固有のペアレント・ノードをそれぞれ有するファイル・システム・オブジェクトを保存するためのデータ・ストレージ・ボリュームであって、前記装置のみが前記データ・ストレージ・ボリュームへの書き込みを許されるよう、前記装置によって所有されているデータ・ストレージ・ボリューム、
    前記種々のデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの参照を保存するための少なくとも１つのディレクトリ、
    ファイル・システム・オブジェクトを複数のボリュームを横断して保持するための手段であって、
    他のノードがペアレント・ノードであると考えられるデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を、前記少なくとも１つのディレクトリに保存するための手段、および
    前記装置がペアレント・ノードであると考えられる他のクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するための手段
    を含んでいる手段
    を有している装置。
  91. 複数のボリュームを横断してファイル・システム・オブジェクトを生成するための手段をさらに有している、請求項９０に記載の装置。
  92. 複数のボリュームを横断してファイル・システム・オブジェクトを削除するための手段をさらに有している、請求項９０に記載の装置。
  93. １つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするための手段
    をさらに有している、請求項９０に記載の装置。
  94. 複数のボリュームを横断してファイル・システム・オブジェクトをリネームするための手段
    をさらに有している、請求項９０に記載の装置。
  95. 複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するための手段であって、
    他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうための手段、
    他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうための手段、
    前記装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するための手段、および
    前記装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するための手段
    を含んでいる手段をさらに有している、請求項９０に記載の装置。
  96. 他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするための手段、および
    他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするための手段
    をさらに有している、請求項９５に記載の装置。
  97. 多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するための手段
    をさらに有している、請求項９０に記載の装置。
  98. 複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するための手段
    をさらに有している、請求項９０に記載の装置。
  99. 複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、前記ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタのクラスタ・ノードを動作させるためのコンピュータ・プログラムを具現化してなるコンピュータで読み出し可能な媒体を有する装置であって、
    前記コンピュータ・プログラムが、
    前記クラスタ・ノードの少なくとも１つのディレクトリに、他のノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへのハード参照を保存するためのプログラム・コード手段、
    他のクラスタ・ノードがペアレント・ノードであると考えられるクラスタ・ノードによって所有されているデータ・ストレージ・ボリュームに保存されたファイル・システム・オブジェクトへの論理参照を、前記少なくとも１つのディレクトリに保存するためのプログラム・コード手段、および
    各ボリュームを、単一のノードにより所有されるように制限するためのプログラム・コード手段であって、ボリュームのオーナのみが前記ボリュームへの書き込みの許可を有している、プログラム・コード手段
    を含んでいる複数のボリュームを横断してファイル・システム・オブジェクトを保持するためのプログラム・コード手段
    を有している装置。
  100. 前記コンピュータ・プログラムが、
    複数のボリュームを横断してファイル・システム・オブジェクトを生成するためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  101. 前記コンピュータ・プログラムが、
    複数のボリュームを横断してファイル・システム・オブジェクトを削除するためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  102. 前記コンピュータ・プログラムが、
    １つのボリュームから他のボリュームへとファイル・システム・オブジェクトをリロケートするためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  103. 前記コンピュータ・プログラムが、
    複数のボリュームを横断してファイル・システム・オブジェクトをリネームするためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  104. 前記コンピュータ・プログラムが、
    複数のボリュームを横断してファイル・システム・オブジェクトへのアクセスを制御するためのプログラム・コード手段であって、
    他のノードによって所有されているファイル・システム・オブジェクトから読み出しを行なうためのプログラム・コード手段、
    他のノードによって所有されているファイル・システム・オブジェクトへと書き込みを行なうためのプログラム・コード手段、
    前記装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる読み出しアクセスを提供するためのプログラム・コード手段、および
    前記装置によって所有されているファイル・システム・オブジェクトへの、他のノードによる書き込みアクセスを提供するためのプログラム・コード手段
    を含んでいるプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  105. 前記コンピュータ・プログラムが、
    他のノードによって所有されているファイル・システム・オブジェクト・データをキャッシュするためのプログラム・コード手段、および
    他のノードによって所有されているファイル・システム・オブジェクトに関するメタデータをキャッシュするためのプログラム・コード手段
    をさらに有している、請求項１０４に記載の装置。
  106. 前記コンピュータ・プログラムが、
    多ボリューム・ロッキングが回避されるよう、書き込みロックを一度にただ１つのボリュームにのみ置きつつ、複数のボリュームを横断してファイル・システム・オブジェクトを操作するためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  107. 前記コンピュータ・プログラムが、
    複数のボリュームを横断して生じて前記ファイル・システム・オブジェクトに影響を及ぼす故障から回復するためのプログラム・コード手段
    をさらに有している、請求項９９に記載の装置。
  108. ファイル・システム・オブジェクトに関するメタデータを、複数の論理ストレージ・ボリュームへのアクセスをそれぞれ有している複数のクラスタ・ノードを相互接続して備え、前記ノードと通信するクライアントに前記ボリューム上のデータへのアクセスを提供するファイル・サーバ・クラスタのクラスタ・ノードによって保持するための方法であって、
    各ノードについて、ファイル・システム・オブジェクト・データを保存するためのデータ・キャッシュを保持すること、
    各ボリュームについて、メタデータを保存するための別個のメタデータ・キャッシュを保持すること、
    各ノードについて、他のノードから得たファイル・システム・オブジェクト・データを前記データ・キャッシュに保存すること、
    各ボリュームについて、他のノードから得たメタデータを前記メタデータ・キャッシュに保存すること、
    各ボリュームを、単一のノードにより所有されるように制限することであって、ボリュームのオーナのみが前記ボリュームへの書き込みの許可を有している、こと、および
    前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作すること
    を含んでいる、方法。
  109. 前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
    前記データ・キャッシュ内の各データを、前記メタデータ・キャッシュ内の対応するメタデータにマップすること
    を含んでいる、請求項１０８に記載の方法。
  110. 前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
    或るノードによって他のノードから、ファイル・システム・オブジェクトに関連付けられたメタデータを、
    前記他のノードに保存されたメタデータを読み出すための読み取りロックを要求すること、および
    前記読み取りロックが認可されたのちにのみ、前記他のノードからメタデータを読み出すこと
    によって取得することを含んでいる、請求項１０８に記載の方法。
  111. 前記メタデータ・キャッシュを前記データ・キャッシュに隷属するものとして操作することが、
    或るノードによって、前記ノードが所有するファイル・システム・オブジェクトについての読み取りロックを有している他のあらゆるノードのリストを保持すること、および
    前記ノードによって前記ファイル・システム・オブジェクトに変更を、すべての読み取りロックを再取得させ、すべての読み取りロックが再取得されたのちにのみ前記ファイル・システム・オブジェクトを変更することによって加えること
    を含んでいる、請求項１０８に記載の方法。
JP2004550258A 2002-11-01 2003-10-30 分散ファイル・システムおよび方法 Expired - Fee Related JP4480153B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/286,153 US8041735B1 (en) 2002-11-01 2002-11-01 Distributed file system and method
PCT/US2003/034495 WO2004042618A2 (en) 2002-11-01 2003-10-30 Distributed file system and method

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010020731A Division JP2010108520A (ja) 2002-11-01 2010-02-01 分散ファイル・システムおよび方法

Publications (2)

Publication Number Publication Date
JP2006505071A JP2006505071A (ja) 2006-02-09
JP4480153B2 true JP4480153B2 (ja) 2010-06-16

Family

ID=32312065

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2004550258A Expired - Fee Related JP4480153B2 (ja) 2002-11-01 2003-10-30 分散ファイル・システムおよび方法
JP2010020731A Pending JP2010108520A (ja) 2002-11-01 2010-02-01 分散ファイル・システムおよび方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2010020731A Pending JP2010108520A (ja) 2002-11-01 2010-02-01 分散ファイル・システムおよび方法

Country Status (6)

Country Link
US (2) US8041735B1 (ja)
EP (1) EP1556793B1 (ja)
JP (2) JP4480153B2 (ja)
AU (1) AU2003284377A1 (ja)
CA (1) CA2504340C (ja)
WO (1) WO2004042618A2 (ja)

Families Citing this family (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7343487B2 (en) * 2001-10-10 2008-03-11 Nokia Corporation Datacast distribution system
US7457822B1 (en) 2002-11-01 2008-11-25 Bluearc Uk Limited Apparatus and method for hardware-based file system
US8285825B1 (en) * 2002-11-13 2012-10-09 Novell, Inc. Method and system for managing network resources based on a dynamic quorum
US7865536B1 (en) * 2003-02-14 2011-01-04 Google Inc. Garbage collecting systems and methods
US8452821B2 (en) 2007-06-29 2013-05-28 Microsoft Corporation Efficient updates for distributed file systems
US8086565B2 (en) 2008-02-18 2011-12-27 Microsoft Corporation File system watcher in the presence of different file systems
US8548956B2 (en) * 2008-02-28 2013-10-01 Mcafee, Inc. Automated computing appliance cloning or migration
US8214404B2 (en) 2008-07-11 2012-07-03 Avere Systems, Inc. Media aware distributed data layout
US9323681B2 (en) * 2008-09-18 2016-04-26 Avere Systems, Inc. File storage system, cache appliance, and method
US9170953B2 (en) * 2008-09-18 2015-10-27 Avere Systems, Inc. System and method for storing data in clusters located remotely from each other
JP5234342B2 (ja) 2008-09-22 2013-07-10 株式会社日立製作所 計算機システム及びその制御方法
WO2010036889A1 (en) * 2008-09-25 2010-04-01 Bakbone Software, Inc. Remote backup and restore
US8103621B2 (en) * 2008-10-03 2012-01-24 International Business Machines Corporation HSM two-way orphan reconciliation for extremely large file systems
WO2010131373A1 (en) * 2009-05-15 2010-11-18 Hitachi,Ltd. Storage subsystem
US8326802B2 (en) * 2009-06-11 2012-12-04 International Business Machines Corporation File system location verification using a sentinel
US8495044B2 (en) * 2009-09-02 2013-07-23 Microsoft Corporation File system node updates
CN102055779B (zh) * 2009-10-30 2013-11-20 国际商业机器公司 生成高可用性组的方法、设备及系统
US9037620B2 (en) * 2009-12-16 2015-05-19 Microsoft Technology Licensing, Llc File system active symbolic link
US9479480B2 (en) * 2010-01-29 2016-10-25 Citrix Systems, Inc. Systems and methods of using SSL pools for WAN acceleration
US8793645B2 (en) 2010-04-02 2014-07-29 Microsoft Corporation Replacement of data element in a graph
US8285762B2 (en) 2010-05-11 2012-10-09 International Business Machines Corporation Migration of metadata and storage management of data in a first storage environment to a second storage environment
JP5824519B2 (ja) * 2010-09-13 2015-11-25 株式会社東芝 分散型メタデータキャッシュ
US9400799B2 (en) * 2010-10-04 2016-07-26 Dell Products L.P. Data block migration
US8793328B2 (en) * 2010-12-17 2014-07-29 Facebook, Inc. Distributed storage system
US9348712B1 (en) * 2010-12-22 2016-05-24 Netapp, Inc. Policy-based volume caching in a clustered storage system
US9009196B2 (en) * 2011-03-16 2015-04-14 Microsoft Technology Licensing, Llc Discovery and client routing to database nodes
JP2012205088A (ja) 2011-03-25 2012-10-22 Toshiba Corp ノード及びグループ鍵更新方法
US8943019B1 (en) * 2011-04-13 2015-01-27 Symantec Corporation Lookup optimization during online file system migration
US9342599B2 (en) * 2011-05-25 2016-05-17 Thomas Stetson Elliott Methods and systems for centralized audio and video news product collection, optimization, storage, and distribution
US10684989B2 (en) * 2011-06-15 2020-06-16 Microsoft Technology Licensing, Llc Two-phase eviction process for file handle caches
US8621603B2 (en) 2011-09-09 2013-12-31 Lsi Corporation Methods and structure for managing visibility of devices in a clustered storage system
US8996467B2 (en) * 2011-12-29 2015-03-31 Druva Inc. Distributed scalable deduplicated data backup system
WO2013116530A1 (en) * 2012-02-01 2013-08-08 Xerocole, Inc. Dns outage avoidance method for recursive dns servers
WO2013119516A1 (en) 2012-02-06 2013-08-15 Xerocole, Inc. Data sharing method for recursive dns servers
JP5867161B2 (ja) * 2012-02-29 2016-02-24 富士通株式会社 データアクセス制御装置、データアクセス制御方法およびプログラム
US9207877B1 (en) * 2012-03-30 2015-12-08 Emc Corporation Detection and avoidance of stalled filesystems to prevent stalling of virtual tape drives during tape mounts
US8583840B1 (en) 2012-04-25 2013-11-12 Lsi Corporation Methods and structure for determining mapping information inconsistencies in I/O requests generated for fast path circuits of a storage controller
US9774676B2 (en) 2012-05-21 2017-09-26 Google Inc. Storing and moving data in a distributed storage system
US9195611B2 (en) 2012-06-04 2015-11-24 Google Inc. Efficiently updating and deleting data in a data storage system
US9449006B2 (en) * 2012-06-04 2016-09-20 Google Inc. Method and system for deleting obsolete files from a file system
US9230000B1 (en) 2012-06-04 2016-01-05 Google Inc. Pipelining Paxos state machines
US9659038B2 (en) 2012-06-04 2017-05-23 Google Inc. Efficient snapshot read of a database in a distributed storage system
US9298576B2 (en) 2012-06-04 2016-03-29 Google Inc. Collecting processor usage statistics
WO2013184712A2 (en) 2012-06-04 2013-12-12 Google Inc. Systems and methods of increasing database access concurrency using granular timestamps
US9317511B2 (en) * 2012-06-19 2016-04-19 Infinidat Ltd. System and method for managing filesystem objects
WO2014000822A1 (en) * 2012-06-29 2014-01-03 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for implementing a distributed database
US9852073B2 (en) * 2012-08-07 2017-12-26 Dell Products L.P. System and method for data redundancy within a cache
US9549037B2 (en) 2012-08-07 2017-01-17 Dell Products L.P. System and method for maintaining solvency within a cache
US20140047183A1 (en) * 2012-08-07 2014-02-13 Dell Products L.P. System and Method for Utilizing a Cache with a Virtual Machine
US9367480B2 (en) 2012-08-07 2016-06-14 Dell Products L.P. System and method for updating data in a cache
US9311240B2 (en) 2012-08-07 2016-04-12 Dell Products L.P. Location and relocation of data within a cache
US9495301B2 (en) * 2012-08-07 2016-11-15 Dell Products L.P. System and method for utilizing non-volatile memory in a cache
WO2014046650A1 (en) 2012-09-19 2014-03-27 Bluearc Uk Limited System and method for managing deduplication using checkpoints in a file storage system
US8924443B2 (en) * 2012-10-05 2014-12-30 Gary Robin Maze Document management systems and methods
KR20140047230A (ko) * 2012-10-10 2014-04-22 (주)티베로 분산 시스템에서 분산 트랜잭션의 최적화를 위한 방법 및 트랜잭션을 최적화한 분산 시스템
US9152501B2 (en) * 2012-12-19 2015-10-06 International Business Machines Corporation Write performance in fault-tolerant clustered storage systems
US20140201177A1 (en) * 2013-01-11 2014-07-17 Red Hat, Inc. Accessing a file system using a hard link mapped to a file handle
EP2951978A4 (en) * 2013-01-29 2016-08-31 Hewlett Packard Entpr Dev Lp METHOD AND SYSTEMS FOR STORING COMMONLY USED FILES
US9984083B1 (en) * 2013-02-25 2018-05-29 EMC IP Holding Company LLC Pluggable storage system for parallel query engines across non-native file systems
US9805092B1 (en) 2013-02-25 2017-10-31 EMC IP Holding Company LLC Parallel processing database system
US9613119B1 (en) * 2013-03-14 2017-04-04 Nutanix, Inc. Unique identifiers for data replication, migration, failover operations and failback operations
US9769111B1 (en) * 2013-04-28 2017-09-19 Amdocs Software Systems Limited System, method, and computer program for many-to-one communications in a network
US9529890B2 (en) * 2013-04-29 2016-12-27 Moogsoft, Inc. System for decomposing events from managed infrastructures using a topology proximity engine, graph topologies, and k-means clustering
US9152776B2 (en) * 2013-04-30 2015-10-06 Netapp, Inc. Secure access-based enumeration of a junction or mount point on a clustered server
US10754825B2 (en) * 2013-08-28 2020-08-25 Red Hat, Inc. Path resolver for client access to distributed file systems
US9571356B2 (en) 2013-09-27 2017-02-14 Zettaset, Inc. Capturing data packets from external networks into high availability clusters while maintaining high availability of popular data packets
US9798791B1 (en) * 2013-12-04 2017-10-24 Ca, Inc. System and method for filtering files during data replication
US9450852B1 (en) * 2014-01-03 2016-09-20 Juniper Networks, Inc. Systems and methods for preventing split-brain scenarios in high-availability clusters
WO2015110171A1 (en) 2014-01-24 2015-07-30 Hitachi Data Systems Engineering UK Limited Method, system and computer program product for replicating file system objects from a source file system to a target file system and for de-cloning snapshot-files in a file system
US20150248443A1 (en) * 2014-03-02 2015-09-03 Plexistor Ltd. Hierarchical host-based storage
CN103984768B (zh) 2014-05-30 2017-09-29 华为技术有限公司 一种数据库集群管理数据的方法、节点及系统
WO2016018447A1 (en) * 2014-07-31 2016-02-04 Hewlett-Packard Development Company, L.P. File creation
WO2016024986A1 (en) 2014-08-15 2016-02-18 Hewlett-Packard Development Company, L.P. Three phase commit for a distributed file system
US10270735B2 (en) * 2014-10-10 2019-04-23 Microsoft Technology Licensing, Llc Distributed components in computing clusters
US9870368B2 (en) 2014-10-27 2018-01-16 Cohesity, Inc. Concurrent access and transactions in a distributed file system
US9697227B2 (en) * 2014-10-27 2017-07-04 Cohesity, Inc. Concurrent access and transactions in a distributed file system
WO2016073029A1 (en) * 2014-11-03 2016-05-12 Hewlett Packard Enterprise Development Lp Detecting inconsistencies in hierarchical organization directories
WO2016073030A1 (en) 2014-11-03 2016-05-12 Hewlett Packard Enterprise Development Lp Policy and configuration data for a user directory
US20160212198A1 (en) * 2015-01-16 2016-07-21 Netapp, Inc. System of host caches managed in a unified manner
US10108624B1 (en) * 2015-02-04 2018-10-23 Amazon Technologies, Inc. Concurrent directory move operations using ranking rules
US10887429B1 (en) * 2015-06-30 2021-01-05 EMC IP Holding Company LLC Processing multi-protocol redirection links
CN106469150B (zh) * 2015-08-14 2019-10-08 阿里巴巴集团控股有限公司 文件读写方法、装置和系统
US10320702B2 (en) 2015-09-30 2019-06-11 Veritas Technologies, LLC Input/output fencing optimization
US10733147B2 (en) * 2015-10-19 2020-08-04 Google Llc Distributed management of file modification-time field
US10467005B2 (en) * 2015-12-15 2019-11-05 International Business Machines Corporation Resilient distributed garbage collection
US10650045B2 (en) 2016-02-05 2020-05-12 Sas Institute Inc. Staged training of neural networks for improved time series prediction performance
US10795935B2 (en) 2016-02-05 2020-10-06 Sas Institute Inc. Automated generation of job flow definitions
US10642896B2 (en) 2016-02-05 2020-05-05 Sas Institute Inc. Handling of data sets during execution of task routines of multiple languages
US10650046B2 (en) 2016-02-05 2020-05-12 Sas Institute Inc. Many task computing with distributed file system
US10353916B2 (en) * 2016-03-25 2019-07-16 Bentley Systems, Incorporated Techniques for conversion of CAD descriptions
US10719499B2 (en) * 2016-06-06 2020-07-21 INTERNATIONAL BUSINESS MACHINES CORPORATIOb Establishing distributed consensus via alternate voting strategies in a dispersed storage network
US10248470B2 (en) 2016-08-31 2019-04-02 International Business Machines Corporation Hierarchical hardware object model locking
US11119870B2 (en) * 2016-09-21 2021-09-14 Nec Corporation Calculator, cluster management system, method, and non-transitory computer readable medium
KR102162466B1 (ko) * 2016-10-07 2020-10-08 한국전자통신연구원 분산 스토리지 서버, 그것에 포함되는 서버 장치, 및 서버 장치를 동작시키는 방법
US10810165B2 (en) * 2016-10-07 2020-10-20 Electronics And Telecommunications Research Institute Distributed storage server, server device included therein, and method of operating server device
US10635648B2 (en) 2016-11-30 2020-04-28 Nutanix, Inc. Entity identifier generation in distributed computing systems
KR20180085187A (ko) * 2017-01-18 2018-07-26 한국전자통신연구원 토러스 연결망 기반 분산 파일 시스템의 볼륨 확장 및 축소 방법 및 이를 위한 장치
USD898059S1 (en) 2017-02-06 2020-10-06 Sas Institute Inc. Display screen or portion thereof with graphical user interface
CN106776055B (zh) * 2017-02-19 2019-10-25 网宿科技股份有限公司 一种分布式锁实现方法和系统
USD898060S1 (en) 2017-06-05 2020-10-06 Sas Institute Inc. Display screen or portion thereof with graphical user interface
US10721719B2 (en) * 2017-06-20 2020-07-21 Citrix Systems, Inc. Optimizing caching of data in a network of nodes using a data mapping table by storing data requested at a cache location internal to a server node and updating the mapping table at a shared cache external to the server node
US11860819B1 (en) * 2017-06-29 2024-01-02 Amazon Technologies, Inc. Auto-generation of partition key
US10915497B1 (en) * 2017-07-31 2021-02-09 EMC IP Holding Company LLC Multi-tier storage system with controllable relocation of files from file system tier to cloud-based object storage tier
US10735369B2 (en) * 2018-06-22 2020-08-04 Microsoft Technology Licensing, Llc Hierarchical namespace service with distributed name resolution caching and synchronization
US10984022B2 (en) * 2018-07-30 2021-04-20 Sap Se Clustering process for objects using link counts
US11423080B2 (en) 2018-07-30 2022-08-23 Sap Se Clustering process for objects using comparison structures
US10320625B1 (en) 2018-08-21 2019-06-11 Capital One Services, Llc Managing service deployment in a cloud computing environment
US10938897B2 (en) * 2019-01-31 2021-03-02 EMC IP Holding Company LLC Extended group service changes
US11271992B2 (en) * 2020-01-22 2022-03-08 EMC IP Holding Company LLC Lazy lock queue reduction for cluster group changes
KR102289834B1 (ko) * 2020-03-09 2021-08-12 한림대학교 산학협력단 센서 장치의 저장 공간을 이용한 가상 스토리지 시스템 및 이의 작동 방법
US11934679B2 (en) * 2020-10-21 2024-03-19 EMC IP Holding Company, LLC System and method for segmenting volumes across a multi-node storage system
US11803511B2 (en) * 2021-11-05 2023-10-31 Microsoft Technology Licensing, Llc Methods and systems for ordering operations on a file system having a hierarchical namespace
CN114579514B (zh) * 2022-04-25 2022-10-04 阿里云计算有限公司 一种基于多计算节点的文件处理方法、装置及设备

Family Cites Families (252)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US665689A (en) * 1900-06-21 1901-01-08 Martin Landenberger Bottle-stopper.
US3702462A (en) 1967-10-26 1972-11-07 Delaware Sds Inc Computer input-output system
US3588831A (en) 1968-11-13 1971-06-28 Honeywell Inf Systems Input/output controller for independently supervising a plurality of operations in response to a single command
US3699532A (en) 1970-04-21 1972-10-17 Singer Co Multiprogramming control for a data handling system
CS164932B2 (ja) 1971-09-07 1975-11-28
US4075691A (en) 1975-11-06 1978-02-21 Bunker Ramo Corporation Communication control unit
JPS6038740B2 (ja) 1976-04-19 1985-09-03 株式会社東芝 デ−タ処理装置
US4074072A (en) 1976-05-24 1978-02-14 Bell Telephone Laboratories, Incorporated Multiprocessor control of a partitioned switching network by control communication through the network
US4079452A (en) 1976-06-15 1978-03-14 Bunker Ramo Corporation Programmable controller with modular firmware for communication control
US4096567A (en) 1976-08-13 1978-06-20 Millard William H Information storage facility with multiple level processors
US4228496A (en) 1976-09-07 1980-10-14 Tandem Computers Incorporated Multiprocessor system
US4080649A (en) 1976-12-16 1978-03-21 Honeywell Information Systems Inc. Balancing the utilization of I/O system processors
US4156907A (en) 1977-03-02 1979-05-29 Burroughs Corporation Data communications subsystem
US4101960A (en) 1977-03-29 1978-07-18 Burroughs Corporation Scientific processor
US4156906A (en) 1977-11-22 1979-05-29 Honeywell Information Systems Inc. Buffer store including control apparatus which facilitates the concurrent processing of a plurality of commands
JPS54111726A (en) 1978-02-22 1979-09-01 Hitachi Ltd Control unit for multiplex virtual memory
US4399503A (en) 1978-06-30 1983-08-16 Bunker Ramo Corporation Dynamic disk buffer control unit
US4253144A (en) 1978-12-21 1981-02-24 Burroughs Corporation Multi-processor communication network
US4240143A (en) 1978-12-22 1980-12-16 Burroughs Corporation Hierarchical multi-processor network for memory sharing
US4377843A (en) 1979-04-19 1983-03-22 Wescom Switching, Inc. Data distribution interface
FR2472234A1 (fr) 1979-12-21 1981-06-26 Philips Ind Commerciale Protocoles de communication geres par les modules de communication utilises dans un systeme de traitement de donnees reparti
US4333144A (en) 1980-02-05 1982-06-01 The Bendix Corporation Task communicator for multiple computer system
US4323967A (en) 1980-04-15 1982-04-06 Honeywell Information Systems Inc. Local bus interface for controlling information transfers between units in a central subsystem
US4488231A (en) 1980-09-29 1984-12-11 Honeywell Information Systems Inc. Communication multiplexer having dual microprocessors
US4414624A (en) 1980-11-19 1983-11-08 The United States Of America As Represented By The Secretary Of The Navy Multiple-microcomputer processing
US4385206A (en) 1980-12-16 1983-05-24 Stromberg-Carlson Corporation Programmable port sense and control signal preprocessor for a central office switching system
FR2500659B1 (fr) 1981-02-25 1986-02-28 Philips Ind Commerciale Dispositif pour l'allocation dynamique des taches d'un ordinateur multiprocesseur
JPS57155666A (en) 1981-03-20 1982-09-25 Fujitsu Ltd Instruction controlling system of vector processor
US4445174A (en) 1981-03-31 1984-04-24 International Business Machines Corporation Multiprocessing system including a shared cache
AU551032B2 (en) 1981-03-31 1986-04-17 British Telecommunications Public Limited Company Safety arrangement in computer control system
US4412285A (en) 1981-04-01 1983-10-25 Teradata Corporation Multiprocessor intercommunication system and method
JPS57164340A (en) 1981-04-03 1982-10-08 Hitachi Ltd Information processing method
US4394727A (en) 1981-05-04 1983-07-19 International Business Machines Corporation Multi-processor task dispatching apparatus
US4456957A (en) 1981-09-28 1984-06-26 Ncr Corporation Apparatus using a decision table for routing data among terminals and a host system
US4442487A (en) 1981-12-31 1984-04-10 International Business Machines Corporation Three level memory hierarchy using write and share flags
US4448419A (en) 1982-02-24 1984-05-15 Telnaes Inge S Electronic gaming device utilizing a random number generator for selecting the reel stop positions
US4500960A (en) 1982-06-28 1985-02-19 At&T Bell Laboratories Geographically distributed multiprocessor time-shared communication processing system
US4685125A (en) 1982-06-28 1987-08-04 American Telephone And Telegraph Company Computer system with tasking
US4614841A (en) 1982-06-29 1986-09-30 At&T Bell Laboratories Geographically distributed multiprocessor time-shared communication processing system
US4527232A (en) 1982-07-02 1985-07-02 Sun Microsystems, Inc. High-speed memory and memory management system
US4550368A (en) 1982-07-02 1985-10-29 Sun Microsystems, Inc. High-speed memory and memory management system
US4608631A (en) 1982-09-03 1986-08-26 Sequoia Systems, Inc. Modular computer system
US4626634A (en) 1982-09-30 1986-12-02 At&T Bell Laboratories Multiprocessor computing system featuring shared global control
US4590556A (en) 1983-01-17 1986-05-20 Tandy Corporation Co-processor combination
US4654654A (en) 1983-02-07 1987-03-31 At&T Bell Laboratories Data network acknowledgement arrangement
US4536874A (en) 1983-07-21 1985-08-20 Stoffel James C Bandwidth efficient multipoint data communication system
JPS6054052A (ja) 1983-09-02 1985-03-28 Nec Corp 処理継続方式
US4558413A (en) 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US4633245A (en) 1983-12-30 1986-12-30 International Business Machines Corporation Local area network interconnect switching system
US5255369A (en) 1984-03-10 1993-10-19 Encore Computer U.S., Inc. Multiprocessor system with reflective memory data transfer device
US4638427A (en) 1984-04-16 1987-01-20 International Business Machines Corporation Performance evaluation for an asymmetric multiprocessor system
JP2539352B2 (ja) 1984-06-20 1996-10-02 株式会社日立製作所 階層型多重計算機システム
US4710868A (en) 1984-06-29 1987-12-01 International Business Machines Corporation Interconnect scheme for shared memory local networks
US5067071A (en) 1985-02-27 1991-11-19 Encore Computer Corporation Multiprocessor computer system employing a plurality of tightly coupled processors with interrupt vector bus
US4769772A (en) 1985-02-28 1988-09-06 Honeywell Bull, Inc. Automated query optimization method using both global and parallel local optimizations for materialization access planning for distributed databases
US4754395A (en) 1985-05-06 1988-06-28 Computer X, Inc. Network interface module with minimized data paths
US5113523A (en) 1985-05-06 1992-05-12 Ncube Corporation High performance computer system
US4694396A (en) 1985-05-06 1987-09-15 Computer X, Inc. Method of inter-process communication in a distributed data processing system
US4649473A (en) 1985-06-17 1987-03-10 International Business Machines Corporation Flexible data transmission for message based protocols
US4714995A (en) 1985-09-13 1987-12-22 Trw Inc. Computer integration system
US4719569A (en) 1985-10-11 1988-01-12 Sun Microsystems, Inc. Arbitrator for allocating access to data processing resources
US4825354A (en) 1985-11-12 1989-04-25 American Telephone And Telegraph Company, At&T Bell Laboratories Method of file access in a distributed processing computer network
JPS62192820A (ja) 1986-02-20 1987-08-24 Mitsubishi Electric Corp マン・マシン・インタフェイス管理方式
US4783705A (en) 1986-02-27 1988-11-08 Quantum Corporation High capacity disk file with embedded sector servo and SCSI interface
US4809169A (en) 1986-04-23 1989-02-28 Advanced Micro Devices, Inc. Parallel, multiple coprocessor computer architecture having plural execution modes
US4727538A (en) 1986-05-20 1988-02-23 American Telephone And Telegraph Company, At&T Bell Laboratories Information transfer method and arrangement
US4803621A (en) 1986-07-24 1989-02-07 Sun Microsystems, Inc. Memory access system
US4845609A (en) 1986-07-25 1989-07-04 Systech Corporation Computer communications subsystem using an embedded token-passing network
US4780821A (en) 1986-07-29 1988-10-25 International Business Machines Corp. Method for multiple programs management within a network having a server computer and a plurality of remote computers
US4819159A (en) 1986-08-29 1989-04-04 Tolerant Systems, Inc. Distributed multiprocess transaction processing system and method
US4783730A (en) 1986-09-19 1988-11-08 Datapoint Corporation Input/output control technique utilizing multilevel memory structure for processor and I/O communication
US4766534A (en) 1986-10-16 1988-08-23 American Telephone And Telegraph Company, At&T Bell Laboratories Parallel processing network and method
JPS63100562A (ja) 1986-10-17 1988-05-02 Hitachi Ltd フアイルシステム管理方式
US5764922A (en) 1986-11-04 1998-06-09 Unisys Corporation I/O system for off-loading operating system functions
JPH0821926B2 (ja) 1987-01-12 1996-03-04 株式会社東芝 情報通信ネツトワ−ク
US4887204A (en) 1987-02-13 1989-12-12 International Business Machines Corporation System and method for accessing remote files in a distributed networking environment
US5133053A (en) 1987-02-13 1992-07-21 International Business Machines Corporation Interprocess communication queue location transparency
US4897781A (en) 1987-02-13 1990-01-30 International Business Machines Corporation System and method for using cached data at a local node after re-opening a file at a remote node in a distributed networking environment
US5001628A (en) 1987-02-13 1991-03-19 International Business Machines Corporation Single system image uniquely defining an environment for each user in a data processing system
US4805107A (en) 1987-04-15 1989-02-14 Allied-Signal Inc. Task scheduler for a fault tolerant multiple node processing system
US5201040A (en) 1987-06-22 1993-04-06 Hitachi, Ltd. Multiprocessor system having subsystems which are loosely coupled through a random access storage and which each include a tightly coupled multiprocessor
US5113496A (en) 1987-08-04 1992-05-12 Mccalley Karl W Bus interconnection structure with redundancy linking plurality of groups of processors, with servers for each group mounted on chassis
CA1301294C (en) 1987-08-21 1992-05-19 Klaus Kuhlmann Modularly structured digital communications system
US5109515A (en) 1987-09-28 1992-04-28 At&T Bell Laboratories User and application program transparent resource sharing multiple computer interface architecture with kernel process level transfer of user requested services
JPH01108675A (ja) 1987-10-21 1989-04-25 Hitachi Ltd 電子伝票処理システム
JP2644780B2 (ja) 1987-11-18 1997-08-25 株式会社日立製作所 処理依頼機能を持つ並列計算機
NZ226733A (en) 1987-12-21 1990-05-28 Honeywell Bull Coupling incompatible cpu to data processing system
US5050070A (en) 1988-02-29 1991-09-17 Convex Computer Corporation Multi-processor computer system having self-allocating processors
US4993017A (en) 1988-03-15 1991-02-12 Siemens Aktiengesellschaft Modularly structured ISDN communication system
US4899333A (en) 1988-03-31 1990-02-06 American Telephone And Telegraph Company At&T Bell Laboratories Architecture of the control of a high performance packet switching distribution network
US4922486A (en) 1988-03-31 1990-05-01 American Telephone And Telegraph Company User to network interface protocol for packet communications networks
US4872157A (en) 1988-03-31 1989-10-03 American Telephone And Telegraph Company, At&T Bell Laboratories Architecture and organization of a high performance metropolitan area telecommunications packet network
US4875206A (en) 1988-03-31 1989-10-17 American Telephone And Telegraph Comopany, At&T Bell Laboratories High bandwidth interleaved buffer memory and control
US4872159A (en) 1988-03-31 1989-10-03 American Telephone And Telegraph Company At&T Bell Laboratories Packet network architecture for providing rapid response time
US4914583A (en) 1988-04-13 1990-04-03 Motorola, Inc. Method of indicating processes resident within a cell of a data processing system
US5008814A (en) 1988-08-15 1991-04-16 Network Equipment Technologies, Inc. Method and apparatus for updating system software for a plurality of data processing units in a communication network
US4991133A (en) 1988-10-07 1991-02-05 International Business Machines Corp. Specialized communications processor for layered protocols
US5262965A (en) 1988-10-31 1993-11-16 Bts-Broadcast Television Systems, Inc. System and method for high speed computer graphics image computation using a parallel connected, asynchronous multiprocessor ring coupled to a synchronous special purpose video processing ring
EP0367182A3 (en) 1988-10-31 1992-07-22 Bts Broadcast Television Systems Gmbh High-speed digital computing system
IT1227360B (it) 1988-11-18 1991-04-08 Honeywell Bull Spa Sistema multiprocessore di elaborazione dati con replicazione di dati globali.
US5073852A (en) 1988-12-16 1991-12-17 Cayman Systems, Inc. Network protocol translator including method and apparatus for reducing interprocess communication and data exchange overhead
US5210824A (en) 1989-03-03 1993-05-11 Xerox Corporation Encoding-format-desensitized methods and means for interchanging electronic document as appearances
JPH02297229A (ja) 1989-03-03 1990-12-07 Xerox Corp データベース・システム
US5036459A (en) 1989-03-09 1991-07-30 U.S. Philips Corporation Multi-processor computer system with distributed memory and an interprocessor communication mechanism, and method for operating such mechanism
US5058110A (en) 1989-05-03 1991-10-15 Ultra Network Technologies Protocol processor
US5113522A (en) 1989-05-17 1992-05-12 International Business Machines Corporation Data processing system with system resource management for itself and for an associated alien processor
US5155809A (en) 1989-05-17 1992-10-13 International Business Machines Corp. Uncoupling a central processing unit from its associated hardware for interaction with data handling apparatus alien to the operating system controlling said unit and hardware
US5283868A (en) 1989-05-17 1994-02-01 International Business Machines Corp. Providing additional system characteristics to a data processing system through operations of an application program, transparently to the operating system
US5359713A (en) 1989-06-01 1994-10-25 Legato Systems, Inc. Method and apparatus for enhancing synchronous I/O in a computer system with a non-volatile memory and using an acceleration device driver in a computer operating system
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5113500A (en) 1989-08-23 1992-05-12 Unisys Corporation Multiple cooperating and concurrently operating processors using individually dedicated memories
US5371885A (en) 1989-08-29 1994-12-06 Microsoft Corporation High performance file system
US5163131A (en) 1989-09-08 1992-11-10 Auspex Systems, Inc. Parallel i/o network file server architecture
ATE179811T1 (de) 1989-09-08 1999-05-15 Auspex Systems Inc Betriebssystemaufbau mit mehreren verarbeitungseinheiten
JPH05502526A (ja) 1989-09-08 1993-04-28 オースペックス　システムズ　インコーポレイテッド 擬似同期ハンドシェイキングおよびブロックモードデータ転送を利用したエンハンストｖｍｅバスプロトコル
US5185857A (en) 1989-12-13 1993-02-09 Rozmanith A Martin Method and apparatus for multi-optional processing, storing, transmitting and retrieving graphical and tabular data in a mobile transportation distributable and/or networkable communications and/or data processing system
US5276860A (en) 1989-12-19 1994-01-04 Epoch Systems, Inc. Digital data processor with improved backup storage
US5179702A (en) 1989-12-29 1993-01-12 Supercomputer Systems Limited Partnership System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling
US5175825A (en) 1990-02-02 1992-12-29 Auspex Systems, Inc. High speed, flexible source/destination data burst direct memory access controller
US5118975A (en) 1990-03-05 1992-06-02 Thinking Machines Corporation Digital clock buffer circuit providing controllable delay
US5218697A (en) 1990-04-18 1993-06-08 Microsoft Corporation Method and system for networking computers having varying file architectures
ATE119732T1 (de) 1990-06-26 1995-03-15 Siemens Ag Programmgesteuerte kommunikationsanlage.
CA2045799C (en) 1990-07-11 1999-03-23 Kenneth L. Thompson File system with read/write and read only storage
JP2888958B2 (ja) 1990-10-20 1999-05-10 富士通株式会社 部分書き換え可能な記憶媒体におけるファイル管理方式
US5673394A (en) 1990-10-31 1997-09-30 Microsoft Corporation Method of sharing memory between an operating system and an application program
US5367698A (en) 1991-10-31 1994-11-22 Epoch Systems, Inc. Network file migration system
US5243699A (en) 1991-12-06 1993-09-07 Maspar Computer Corporation Input/output system for parallel processing arrays
US6256642B1 (en) 1992-01-29 2001-07-03 Microsoft Corporation Method and system for file system management using a flash-erasable, programmable, read-only memory
CA2131627A1 (en) 1992-03-09 1993-09-16 Yu-Ping Cheng High-performance non-volatile ram protected write cache accelerator system
JP3213766B2 (ja) 1992-03-16 2001-10-02 株式会社日立製作所 レプリケートファイル更新システム
EP0672277B1 (en) 1992-12-01 1998-05-13 Microsoft Corporation A method and system for in-place interaction with embedded objects
GB9300913D0 (en) 1993-01-19 1993-03-10 Madge Networks Ltd Interface apparatus
US5519853A (en) 1993-03-11 1996-05-21 Legato Systems, Inc. Method and apparatus for enhancing synchronous I/O in a computer system with a non-volatile memory and using an acceleration device driver in a computer operating system
EP0622922B1 (en) 1993-04-29 2000-11-29 International Business Machines Corporation Method and device of multicasting data in a communications system
US5963962A (en) 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
US6604118B2 (en) 1998-07-31 2003-08-05 Network Appliance, Inc. File system image transfer
DE69435146D1 (de) 1993-06-03 2008-11-13 Network Appliance Inc Verfahren und Vorrichtung zum Beschreiben beliebiger Bereiche eines Dateisystems
US7174352B2 (en) 1993-06-03 2007-02-06 Network Appliance, Inc. File system image transfer
WO1994029796A1 (en) 1993-06-03 1994-12-22 Network Appliance Corporation A method for allocating files in a file system integrated with a raid disk sub-system
JPH08511368A (ja) 1993-06-04 1996-11-26 ネットワーク・アプリアンス・コーポレーション 不揮発性メモリを用いてｒａｉｄサブシステムにパリティを形成する方法
US5613105A (en) 1993-06-30 1997-03-18 Microsoft Corporation Efficient storage of objects in a file system
JPH0778098A (ja) * 1993-09-08 1995-03-20 Fujitsu Ltd ファイル管理システム
US5699518A (en) 1993-11-29 1997-12-16 Microsoft Corporation System for selectively setting a server node, evaluating to determine server node for executing server code, and downloading server code prior to executing if necessary
JPH07175710A (ja) 1993-12-20 1995-07-14 Canon Inc データ管理方法及び装置
US5701462A (en) 1993-12-29 1997-12-23 Microsoft Corporation Distributed file system providing a unified name space with efficient name resolution
US5608909A (en) 1994-04-15 1997-03-04 Microsoft Corporation Method and system for caching presentation data of a source object in a presentation cache
US5657455A (en) 1994-09-07 1997-08-12 Adaptec, Inc. Status indicator for a host adapter
US5960180A (en) 1994-09-07 1999-09-28 Adaptec, Inc. Host adapter integrated circuit having autoaccess pause
US5835953A (en) 1994-10-13 1998-11-10 Vinca Corporation Backup system that takes a snapshot of the locations in a mass storage device that has been identified for updating prior to updating
US5745752A (en) 1994-12-13 1998-04-28 Microsoft Corporation Dual namespace client having long and short filenames
CA2167790A1 (en) 1995-01-23 1996-07-24 Donald S. Maier Relational database system and method with high data availability during table data restructuring
US5513314A (en) 1995-01-27 1996-04-30 Auspex Systems, Inc. Fault tolerant NFS server system and mirroring protocol
US5630059A (en) 1995-02-06 1997-05-13 International Business Machines Corporation Expedited message transfer in a multi-nodal data processing system
US5819306A (en) 1995-02-14 1998-10-06 General Magic Shadow mechanism for a modifiable object oriented system
US5930831A (en) 1995-02-23 1999-07-27 Powerquest Corporation Partition manipulation architecture supporting multiple file systems
JP3123012B2 (ja) 1995-03-02 2001-01-09 松下電器産業株式会社 マルチメディアサーバー
US5701491A (en) 1995-05-31 1997-12-23 Microsoft Corporation, Inc. Method and system for transitioning the network mode of a workstation
US5761669A (en) 1995-06-06 1998-06-02 Microsoft Corporation Controlling access to objects on multiple operating systems
US5675782A (en) 1995-06-06 1997-10-07 Microsoft Corporation Controlling access to objects on multiple operating systems
US5628005A (en) 1995-06-07 1997-05-06 Microsoft Corporation System and method for providing opportunistic file access in a network environment
US6275867B1 (en) 1995-09-12 2001-08-14 International Business Machines Corporation Operation-partitioned off-loading of operations in a distributed environment
US5845280A (en) 1995-09-25 1998-12-01 Microsoft Corporation Method and apparatus for transmitting a file in a network using a single transmit request from a user-mode process to a kernel-mode process
US5892917A (en) 1995-09-27 1999-04-06 Microsoft Corporation System for log record and log expansion with inserted log records representing object request for specified object corresponding to cached object copies
US5802288A (en) 1995-10-26 1998-09-01 International Business Machines Corporation Integrated communications for pipelined computers
US5923846A (en) 1995-11-06 1999-07-13 Microsoft Corporation Method of uploading a message containing a file reference to a server and downloading a file from the server using the file reference
US5742818A (en) 1995-12-15 1998-04-21 Microsoft Corporation Method and system of converting data from a source file system to a target file system
US5754771A (en) 1996-02-12 1998-05-19 Sybase, Inc. Maximum receive capacity specifying query processing client/server system replying up to the capacity and sending the remainder upon subsequent request
US5794230A (en) 1996-03-15 1998-08-11 Microsoft Corporation Method and system for creating and searching directories on a server
US5907703A (en) 1996-05-08 1999-05-25 Mijenix Corporation Device driver for accessing computer files
US6901509B1 (en) 1996-05-14 2005-05-31 Tumbleweed Communications Corp. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US5867657A (en) 1996-06-06 1999-02-02 Microsoft Corporation Distributed scheduling in a multiple data server system
US5958061A (en) 1996-07-24 1999-09-28 Transmeta Corporation Host microprocessor with apparatus for temporarily holding target processor state
US6044367A (en) 1996-08-02 2000-03-28 Hewlett-Packard Company Distributed I/O store
US5889952A (en) 1996-08-14 1999-03-30 Microsoft Corporation Access check system utilizing cached access permissions
US5832205A (en) 1996-08-20 1998-11-03 Transmeta Corporation Memory controller for a microprocessor for detecting a failure of speculation on the physical nature of a component being addressed
US5926832A (en) 1996-09-26 1999-07-20 Transmeta Corporation Method and apparatus for aliasing memory data in an advanced microprocessor
US6034963A (en) 1996-10-31 2000-03-07 Iready Corporation Multiple network protocol encoder/decoder and data processor
US6487644B1 (en) 1996-11-22 2002-11-26 Veritas Operating Corporation System and method for multiplexed data back-up to a storage tape and restore operations using client identification tags
US6148377A (en) * 1996-11-22 2000-11-14 Mangosoft Corporation Shared memory computer networks
US5909540A (en) * 1996-11-22 1999-06-01 Mangosoft Corporation System and method for providing highly available data storage using globally addressable memory
US6026474A (en) * 1996-11-22 2000-02-15 Mangosoft Corporation Shared client-side web caching using globally addressable memory
US6006228A (en) 1996-12-11 1999-12-21 Ncr Corporation Assigning security levels to particular documents on a document by document basis in a database
SG77151A1 (en) 1997-01-09 2000-12-19 Sun Microsystems Inc Full-featured special purpose network server
US5905855A (en) 1997-02-28 1999-05-18 Transmeta Corporation Method and apparatus for correcting errors in computer systems
US5950225A (en) 1997-02-28 1999-09-07 Network Appliance, Inc. Fly-by XOR for generating parity for data gleaned from a bus
US5929655A (en) 1997-03-25 1999-07-27 Adaptec, Inc. Dual-purpose I/O circuit in a combined LINK/PHY integrated circuit
US6012107A (en) 1997-05-22 2000-01-04 Adaptec, Inc. Hardware control block delivery queues for host adapters and other devices with onboard processors
US6047332A (en) * 1997-06-30 2000-04-04 Sun Microsystems, Inc. Global file system-based system and method for rendering devices on a cluster globally visible
US6044438A (en) 1997-07-10 2000-03-28 International Business Machiness Corporation Memory controller for controlling memory accesses across networks in distributed shared memory processing systems
US5931920A (en) 1997-08-05 1999-08-03 Adaptec, Inc. Command interpreter system in an I/O controller
US6105075A (en) 1997-08-05 2000-08-15 Adaptec, Inc. Scatter gather memory system for a hardware accelerated command interpreter engine
US6088740A (en) 1997-08-05 2000-07-11 Adaptec, Inc. Command queuing system for a hardware accelerated command interpreter engine
US6230200B1 (en) 1997-09-08 2001-05-08 Emc Corporation Dynamic modeling for resource allocation in a file server
US6192408B1 (en) 1997-09-26 2001-02-20 Emc Corporation Network file server sharing local caches of file access information in data processors assigned to respective file systems
US6591302B2 (en) 1997-10-14 2003-07-08 Alacritech, Inc. Fast-path apparatus for receiving data corresponding to a TCP connection
US6389479B1 (en) 1997-10-14 2002-05-14 Alacritech, Inc. Intelligent network interface device and system for accelerated communication
US6427173B1 (en) 1997-10-14 2002-07-30 Alacritech, Inc. Intelligent network interfaced device and system for accelerated communication
US6427171B1 (en) 1997-10-14 2002-07-30 Alacritech, Inc. Protocol processing stack for use with intelligent network interface device
US6434620B1 (en) 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US6226680B1 (en) 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US6470415B1 (en) 1999-10-13 2002-10-22 Alacritech, Inc. Queue system involving SRAM head, SRAM tail and DRAM body
US5941969A (en) 1997-10-22 1999-08-24 Auspex Systems, Inc. Bridge for direct data storage device access
US6081883A (en) 1997-12-05 2000-06-27 Auspex Systems, Incorporated Processing system with dynamically allocatable buffer memory
AU3304699A (en) * 1998-02-20 1999-09-06 Storm Systems Llc File system performance enhancement
US6457130B2 (en) 1998-03-03 2002-09-24 Network Appliance, Inc. File access control in a multi-protocol file server
US6317844B1 (en) 1998-03-10 2001-11-13 Network Appliance, Inc. File server storage arrangement
US6173293B1 (en) * 1998-03-13 2001-01-09 Digital Equipment Corporation Scalable distributed file system
WO1999059064A1 (en) * 1998-05-12 1999-11-18 Sun Microsystems, Inc. Highly available cluster virtual disk system
US6269252B1 (en) 1998-05-27 2001-07-31 Motorola, Inc. Programmable bridging apparatus to connect multiple networks of different protocols
US6085278A (en) 1998-06-02 2000-07-04 Adaptec, Inc. Communications interface adapter for a computer system including posting of system interrupt status
US6070200A (en) 1998-06-02 2000-05-30 Adaptec, Inc. Host adapter having paged data buffers for continuously transferring data between a system bus and a peripheral bus
US6279011B1 (en) 1998-06-19 2001-08-21 Network Appliance, Inc. Backup and restore for heterogeneous file server environment
US6263445B1 (en) 1998-06-30 2001-07-17 Emc Corporation Method and apparatus for authenticating connections to a storage system coupled to a network
US6604236B1 (en) 1998-06-30 2003-08-05 Iora, Ltd. System and method for generating file updates for files stored on read-only media
US6192375B1 (en) 1998-07-09 2001-02-20 Intel Corporation Method and apparatus for managing files in a storage medium
US6119244A (en) 1998-08-25 2000-09-12 Network Appliance, Inc. Coordinating persistent status information with multiple file servers
US6425034B1 (en) 1998-10-30 2002-07-23 Agilent Technologies, Inc. Fibre channel controller having both inbound and outbound control units for simultaneously processing both multiple inbound and outbound sequences
US6321238B1 (en) 1998-12-28 2001-11-20 Oracle Corporation Hybrid shared nothing/shared disk database system
US6871224B1 (en) 1999-01-04 2005-03-22 Cisco Technology, Inc. Facility to transmit network management data to an umbrella management system
US6564252B1 (en) 1999-03-11 2003-05-13 Microsoft Corporation Scalable storage system with unique client assignment to storage server partitions
US6446141B1 (en) 1999-03-25 2002-09-03 Dell Products, L.P. Storage server system including ranking of data source
US6442617B1 (en) 1999-03-31 2002-08-27 3Com Corporation Method and system for filtering multicast packets in a peripheral component environment
US6466978B1 (en) 1999-07-28 2002-10-15 Matsushita Electric Industrial Co., Ltd. Multimedia file systems using file managers located on clients for managing network attached storage devices
US6961749B1 (en) 1999-08-25 2005-11-01 Network Appliance, Inc. Scalable file server with highly available pairs
US6785822B1 (en) 1999-09-16 2004-08-31 International Business Machines Corporation System and method for role based dynamic configuration of user profiles
ATE390788T1 (de) 1999-10-14 2008-04-15 Bluearc Uk Ltd Vorrichtung und verfahren zur hardware-ausführung oder hardware-beschleunigung von betriebssystemfunktionen
US6484177B1 (en) 2000-01-13 2002-11-19 International Business Machines Corporation Data management interoperability methods for heterogeneous directory structures
US6894976B1 (en) 2000-06-15 2005-05-17 Network Appliance, Inc. Prevention and detection of IP identification wraparound errors
US6728897B1 (en) 2000-07-25 2004-04-27 Network Appliance, Inc. Negotiating takeover in high availability cluster
US6640233B1 (en) 2000-08-18 2003-10-28 Network Appliance, Inc. Reserving file system blocks
US6751635B1 (en) 2000-08-18 2004-06-15 Network Appliance, Inc. File deletion and truncation using a zombie file space
US6910154B1 (en) 2000-08-18 2005-06-21 Network Appliance, Inc. Persistent and reliable delivery of event messages
US6862648B2 (en) 2000-10-30 2005-03-01 Sun Microsystems, Inc. Interface emulation for storage devices
US7003780B2 (en) 2000-12-11 2006-02-21 International Business Machines Corporation Method and an apparatus to extend the logic volume manager model to allow device management plug-ins
US20020078066A1 (en) * 2000-12-18 2002-06-20 David Robinson Data storage system including a file system for managing multiple volumes
US6775792B2 (en) 2001-01-29 2004-08-10 Snap Appliance, Inc. Discrete mapping of parity blocks
ATE480822T1 (de) 2001-02-13 2010-09-15 Candera Inc Failover-verarbeitung in einem speicherungssystem
US6799284B1 (en) 2001-02-28 2004-09-28 Network Appliance, Inc. Reparity bitmap RAID failure recovery
US6728735B1 (en) 2001-03-12 2004-04-27 Network Appliance, Inc. Restartable dump that produces a consistent filesystem on tapes
US6668264B1 (en) 2001-04-03 2003-12-23 Network Appliance, Inc. Resynchronization of a target volume with a source volume
US6748380B2 (en) 2001-05-14 2004-06-08 International Business Machines Corporation Method, system, and program product for permission to access software
US6928478B1 (en) 2001-06-25 2005-08-09 Network Appliance, Inc. Method and apparatus for implementing a MAC address pool for assignment to a virtual interface aggregate
US6944785B2 (en) 2001-07-23 2005-09-13 Network Appliance, Inc. High-availability cluster virtual server system
US6920579B1 (en) 2001-08-20 2005-07-19 Network Appliance, Inc. Operator initiated graceful takeover in a node cluster
US7017084B2 (en) 2001-09-07 2006-03-21 Network Appliance Inc. Tracing method and apparatus for distributed environments
US6895429B2 (en) 2001-12-28 2005-05-17 Network Appliance, Inc. Technique for enabling multiple virtual filers on a single filer to participate in multiple address spaces with overlapping network addresses
US6748510B1 (en) 2002-02-28 2004-06-08 Network Appliance, Inc. System and method for verifying disk configuration
US7039828B1 (en) 2002-02-28 2006-05-02 Network Appliance, Inc. System and method for clustered failover without network support
US7007046B2 (en) 2002-03-19 2006-02-28 Network Appliance, Inc. Format for transmission file system information between a source and a destination
US6983296B1 (en) 2002-08-12 2006-01-03 Network Appliance, Inc. System and method for tracking modified files in a file system
US7080223B2 (en) 2002-10-15 2006-07-18 International Business Machines Corporation Apparatus and method to manage and copy computer files
US7373366B1 (en) 2005-06-10 2008-05-13 American Megatrends, Inc. Method, system, apparatus, and computer-readable medium for taking and managing snapshots of a storage volume

Also Published As

Publication number Publication date
US20120036161A1 (en) 2012-02-09
EP1556793B1 (en) 2013-02-27
AU2003284377A1 (en) 2004-06-07
US8041735B1 (en) 2011-10-18
EP1556793A2 (en) 2005-07-27
JP2006505071A (ja) 2006-02-09
CA2504340A1 (en) 2004-05-21
WO2004042618A2 (en) 2004-05-21
US8788530B2 (en) 2014-07-22
WO2004042618A3 (en) 2004-12-09
CA2504340C (en) 2016-01-05
JP2010108520A (ja) 2010-05-13

Similar Documents

Publication Publication Date Title
JP4480153B2 (ja) 分散ファイル・システムおよび方法
US10248655B2 (en) File storage system, cache appliance, and method
US6950833B2 (en) Clustered filesystem
US8001222B2 (en) Clustered filesystem with membership version support
AU2005207573B2 (en) Geographically distributed clusters
US8311980B2 (en) Namespace consistency for a wide-area file system
US7383463B2 (en) Internet protocol based disaster recovery of a server
US5991771A (en) Transaction synchronization in a disconnectable computer and network
US9275058B2 (en) Relocation of metadata server with outstanding DMAPI requests
US20050289152A1 (en) Method and apparatus for implementing a file system
US7475077B2 (en) System and method for emulating a virtual boundary of a file system for data management at a fileset granularity
AU2005207572B2 (en) Cluster database with remote data mirroring
US20030028514A1 (en) Extended attribute caching in clustered filesystem
US20030140210A1 (en) Dynamic and variable length extents
AU2005269315A1 (en) Metadata management for fixed content distributed data storage
US20040153841A1 (en) Failure hierarchy in a cluster filesystem
CA2227430C (en) Transaction clash management in a disconnectable computer and network
AU2011265370B2 (en) Metadata management for fixed content distributed data storage
Shillingsburg Fault tolerance in the Pulsar cluster server
Abdala {ota, naffouri, fanwar, mbilal}@ mit. edu December 6, 2002
Johnson et al. Designing Distributed Search Structures with Lazy Updates

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20061023

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090731

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091030

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091109

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091126

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20091203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100311

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100315

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130326

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130326

Year of fee payment: 3

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D04

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130326

Year of fee payment: 3

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D02

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D04

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130326

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130326

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140326

Year of fee payment: 4

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees