JP4568115B2 - ハードウェアベースのファイルシステムのための装置および方法 - Google Patents

Description

（技術分野および背景技術）
本発明は、コンピュータ・ファイル・システムに関し、特に、コンピュータ・プリケーション・プログラムの実行に用いられるプロセッサーに関連したハードウェアとは異なるコンピュータ・ハードウェアを用いてアクセスするファイル・システムに関するものである。

（発明の要旨）
本発明の一実施形態の中には、幾つか例を挙げると、磁気記憶装置、光磁気記録装置、または光記憶装置などを含むデータ記憶システムにアクセスし利用するファイル・サーバ・システムが設けられている。本システムには、データ記憶システムとつながっており、データ記憶システムに記憶されたデータを提供し、データ記憶システムからデータを検索するデータ・バス装置が含まれている。また、本システムには、複数の連結サブモジュールが含まれており、グループとしての連結サブモジュールは、ファイル・サービス要求を受け取るための制御入力端と、ファイル・サービス要求に応じるための制御出力端と、につながっており、このようなサービス要求を処理したり、制御出力端から要求に対する回答を発出している。制御入力端、及び制御出力端は通常データ・バス装置とは異なっている。各サブモジュールは、かかるファイル・システム要求の処理に関連した異なるオペレーション一式を行うよう形成されている。本システムは、また、複数のメタデータ・メモリー・キャッシュを含んでいる。各メタデータ・メモリー・キャッシュは、通常はファイル内容データを記憶しないサブモジュールのオペレーションに関係したメタデータを記憶するための、対応サブモジュールと関連付けられている。

例示的な実施形態として、階層的に配列された複数の連結サブモジュールがある。

例示的な実施形態には、次のサブモジュール、即ち、記憶システムの中でファイル・システム・オブジェクトの記憶、及び検索を行うオブジェクト記憶サブモジュールと、ファイル属性に関連付けられたデータ構造を管理するファイル・サブモジュールと、ファイル・サブモジュール用のディレクトリ管理を行うディレクトリ・サブモジュールと、ディレクトリ・サブモジュール用のディレクトリ探索を行うツリー・サブモジュールと、次の記憶用のファイル・システム要求データを記憶システムに記憶する不揮発性記憶装置と関連付けられた不揮発性記憶装置処理サブモジュールと、データ記憶システムの中のスペースの割当てに関するデータを検索、及び更新する空きスペース割当てサブモジュールと、が含まれている。

特に、ツリー・サブモジュールは、ディレクトリ・サブモジュール用の論理ツリー構造を管理する。ツリー構造を実質的に平衡させる目的で、ディレクトリ・サブモジュールは、ランダム（または、多分より正確には、擬似乱数）値と各ファイルを関連付けし、ツリー・サブモジュールは、ディレクトリ・サブモジュールからのランダム値に基づいて論理ツリー構造を管理する。各ランダム値は、例えば、巡回冗長検査（ＣＲＣ）、または他のランダム化手法を用いて、ファイル名で作成される。ツリー・サブモジュールは、各ランダム値を論理ツリー構造のインデックスと関連付けを行い、ランダム値を使って論理ツリー構造にアクセスする。ツリー・サブモジュールは、各ランダム値をディレクトリ表のインデックスと関連付けを行う。

不揮発性記憶装置処理サブモジュールは、プロセッサの故障復帰依頼により、ファイル・システム要求データを、不揮発性記憶装置に記憶する。不揮発性記憶装置処理サブモジュールは、不揮発性記憶装置にファイル・システム要求データの記憶を確認した旨の通知を、プロセッサへ送る。不揮発性記憶装置処理サブモジュールは、不揮発性記憶装置に記憶されているファイル・システム要求データをインターフェイスを経由して別のファイル・サーバから受け取ることができる。不揮発性記憶装置処理サブモジュールは、また、別のファイル・サーバによるファイル・システム要求データの不揮発性記憶のために、ファイル・システム要求データをインターフェイスを経由して別のファイル・サーバへ送ってもよい。

オブジェクト記憶サブモジュールは、記憶システムに記憶される各ファイル・システム・オブジェクト用のファイル構造を維持している。ファイル構造は、通常は、専用のメタデータ・キャッシュに記憶されている。ファイル・システム・オブジェクトは、通常、ファイル、ディレクトリ、ファイル属性などのものを含んでいる。オブジェクト記憶サブモジュールは、種々のチェックポイントにおいて、ファイル構造を記憶システムに記憶する。チェックポイントは、外部プロセッサにより開始できる。即ち、ある事象が起きた時、例えば、記憶システムにファイル構造を前回記憶してから所定の時間が経過した時、ファイル・システム要求データの記憶に使用された不揮発性記憶装置の一部が一杯になった時、または記憶システムと関連付けされたセクター・キャッシュが一杯になった時である。

チェックポイントを取得するために、チェックポイント問合せコマンドを不揮発性記憶装置処理サブモジュールに送り、チェックポイント用記憶システムにファイル構造の記憶を開始する。チェックポイント問合せコマンドは通常チェックポイント用のチェックポイント番号を含んでいる。不揮発性記憶装置処理サブモジュールは、不揮発性記憶装置にどのような未処理のファイル・システム要求でも記憶し、他のファイル・サーバのファイル・システム要求数の不揮発性記憶のため、インターフェイスを経由して別のファイル・サーバにファイル・システム要求数を随意的に送り、ファイル・システム要求数をファイル・サブモジュールへ送り、続いて、チェックポイント・コマンドをファイル・サブモジュールへ送る。（ファイル・システム要求の記憶、及び「ミラーリング」、並びにファイル・システム要求のファイル・サーバ・モジュールへの通過は、チェックポイントの取得中も必要に応じて起きていることに留意されたい。）ファイル・サブモジュールは、どのようなファイル・システム要求でも処理し、不揮発性記憶装置処理サブモジュールから、チェックポイント・コマンドを受け取り次第、残りのサブモジュールを経由して完了するある一定のオペレーションを待ち、次にチェックポイント・コマンドをディレクトリ・サブモジュールへ送る。ディレクトリ・サブモジュールは、チェックポイント・コマンドをファイル・サブモジュールから受け取り、チェックポイント・コマンドをツリー・サブモジュールへ送る。ツリー・サブモジュールは、チェックポイント・コマンドをディレクトリ・サブモジュールから受け取り、チェックポイント・コマンドをオブジェクト記憶サブモジュールへ送る。オブジェクト記憶サブモジュールは、チェックポイント・コンマンドをツリー・サブモジュールから受け取り、チェックポイント問合せを空きスペース割当てサブモジュールへ送る。空きスペース割当てサブモジュールは、チェックポイント問合せをオブジェクト記憶サブモジュールから受け取り、チェックポイント問合せを受け取った後に開始されたオペレーション含むチェックポイントに必要な全てのオペレーションを完了する。オブジェクト記憶サブモジュールは、次に、最後のチェックポイント以降に修正された全てのオブジェクトを示す更新オブジェクト・リストを含むファイル・システム・オブジェクトを記憶システムに書き込む。

本発明の代表的な実施形態においては、各ファイル構造は複数のノード、及び少なくとも１つのデータ・ブロックから構成されている。各ノードは、通常は、他のノードを指すポインタ、データ・ブロック記述子を指すポインタ、及びノードが作成されている間のチェックポイントを示すチェックポイント番号などを含んでいる。

本発明の特殊な実施形態においては、ファイル構造には、第１、及び第２のチェックポイント用の情報を記憶する少なくとも２つのルート・ノードが含まれている。記憶システムは論理的にセクターに分割され、２つのルート・ノードは、好ましくは、記憶システムの連接セクターに記憶される。各ルート・ノードは通常、ファイル・システム・オブジェクトの型を示すオブジェクト型（例えば、ファイル、ディレクトリ、空きスペース・オブジェクト、ボリューム記述子オブジェクトなど）、ファイル・システム・オブジェクトと関連付けされたデータ・ブロック数を示すオブジェクト長さ、ルート・ノードが利用された回数を示す再利用カウント、ルート・ノードの以前のインスタンス化を指すポインタ、ルート・ノードの次のインスタンス化を指すポインタ、データ・ブロックを指すポインタを含む少なくとも１つのデータ・ブロック記述子、データ・ブロックが作成された相対的時間を示すチェックポイント番号、データ・ブロックが零または非零、及びファイル属性（イーノード）であることを示す標識、などを含んでいる。実際のオブジェクト長さは、データ・ブロックの整数でなくともよいが、その場合、オブジェクト長さは、ブロックの使用数のカウントがわかる次のより高いブロックの倍数に切り上げることに留意されたい。

ルート・ノード以外に、ファイル構造は、データ・ブロック記述子を含む多数の直接ノードを含むことができる。ルート・ノードは直接ノードを指すポインタを含むことができる。ファイル構造は、また、多数の間接ノードで構成できる。間接ノードは、他の間接ノードまたは直接ノードを指す。ルート・ノードは、間接ノードを指すポインタを含んでよい。オブジェクトは、それに関連付けられたデータを有しなくてもよいが、その場合には、オブジェクトはどのようなブロック記述子も持たない。

大きな空き（即ち、ゼロで埋められた）ファイルが作成し易いように、ファイル構造は、データ・ブロックが零か非零かであるかを示す、ファイル・システムと関連付けられた各データ・ブロックごとの標識を通常含んでいる。ファイル構造は、また、各ノード、及びデータ・ブロックが作成されたかどうかを示す、各ノード、及びデータ・ブロック用の標識を通常含んでいる。オブジェクト記憶サブモジュールは、必要に応じて、各ノード、及びデータ・ブロックを作成し、ファイル・システム書込み要求の応じ、ノード、及びデータ・ブロックが作成されたことを示す、各ノード、及びデータ・ブロック用の標識を設定する。オブジェクト記憶サブモジュールは、通常、空きスペース割当てサブモジュールによってスペースをデータ・ブロックに割り当てることによりデータ・ブロックを作成する。

故障から容易に回復できるように、オブジェクト記憶サブモジュールは、通常、記憶システムにファイル構造と共に時々記憶したトランザクション・ログを通常維持している。
各サブモジュールは、専用のハードウェアまたは専用のプロセッサを用いて実現してもよい。

本発明の別の実施形態においては、２台以上の相互接続ファイル・サーバを有するクラスター化ファイル・サーバが設けられている。３台以上のファイル・サーバをスイッチにより相互接続することが好ましいが、２台のファイル・サーバは、背中合わせに接続できる。スイッチは、どのようなサーバにも他のどのサーバとも連絡しあう能力を与える。サーバは次に本機能を利用して、例えば、仮想ループ構成で、ファイル・システム要求データを不揮発性記憶するためにサーバ間でファイル・システム要求データを交換する。通常、サーバのうち１台が利用できななくなっても、スイッチの構成を修正する必要はないが、逆に、サーバは、その状況を認識し、その結果、仮想ループを修正する。

本発明の別の実施形態においては、少なくとも３台のファイル・サーバ、及びスイッチを有するクラスター化ファイル・サーバが設けられている。各ファイル・サーバはファイル・システム要求を発出するとともに不揮発性記憶領域を含む。スイッチは、いかなるファイル・サーバの不揮発性記憶装置でも他のファイル・サーバの選択した１台からファイル・システム要求データをを記憶できるようファイル・サーバを相互接続する。スイッチは、各ファイル・サーバからのファイル・システム要求データを少なくとも１台の他のファイル・サーバに記憶するよう、例えば、仮想ループ構成で、構成することができる。スイッチには、通常、ファイル・システム要求データの記憶に利用できなくなったファイル・サーバの側路のために構成を修正する能力がある。

本発明の別の実施形態には、ネットワークを経由してファイル・サービス要求を受け取り応答するサービス・モジュールを有するファイル・サーバと、サービス要求に応じるファイル・モジュールと、サービス・モジュール、及びファイル・モジュールとつながっているプロセッサとが設けられている。サービス・モジュールは、ファイル・サービス要求をプロセッサに渡す。プロセッサはファイル・サービス要求を処理してファイル・サービス要求をファイル・モジュールに渡す。ファイル・モジュールは、ファイル・サービス要求に対する回答を直接ファイル・モジュールに送り、プロセッサを側路する。

本発明の別の実施形態には、ファイル・システムの再利用データ構造を管理する方法がある。本方法には、再利用データ構造の再利用値を維持するステップと、データ構造が再利用される度に再利用値を変更するステップが含まれている。再利用データ構造は通常ファイル・システム・オブジェクトと関連付けられたオブジェクト構造のルート・ノードである。クライアントは通常ファイル・システム・オブジェクトにアクセスを要求する時の再利用値を含んでいる。この場合、この要求の再利用値は、ルート・ノードの再利用値と比較されてルート・ノードがクライアントに再利用値を与えた後で再利用されたのかどうかを判断するとともに、その要求の再利用値がルート・ノードの再利用値に一致する場合かつその場合に限りその要求は応じられる。

本発明の別の実施形態には、継続的なチェックポイントで、不揮発性記憶装置にファイル・システム・オブジェクト維持する方法が付与されている。本方法は、ファイル・システム・オブジェクト用のオブジェクト構造を維持するステップを含んでいる。このオブジェクト構造は、第１のルート・ノードが根付いた第１のツリー構造、及び第２のルート・ノードが根付いた第２のツリー構造から成る。各ツリー構造は随意的に多数の中間ノードと多数のデータ・ブロックとで構成されている。各ツリー構造はファイル・システム・オブジェクトのバージョンを表す。本方法は、また、第２のルート・ノードが根付いた第２のツリー構造を前記不揮発性記憶装置に記憶中に第１のルート・ノードが根付いた第１のツリー構造を使って前記オブジェクト構造の管理、及び第１のルート・ノードが根付いた第１のツリー構造を前記不揮発性記憶装置に記憶中に第２のルート・ノードが根付いた第２のツリー構造を使って前記オブジェクト構造の管理を交互に管理するステップと、を含んでいる。本方法は、また、各ルート・ノードごとに、バージョン番号を維持するステップを含んでおり、バージョン番号は対応するツリー構造と関連付けられたチェックポイントを示す。不揮発性記憶装置は、通常、複数のセクターから構成されている。第１、及び第２のルート・ノードは、通常、不揮発性記憶装置の隣接セクターに記憶される。本方法は、また、通常、ルート・ノードのバージョン番号に基づいてファイル・システム・オブジェクトの最新の有効バージョンを決定するステップを含んでいる。本方法は、また、通常、不揮発性記憶装置の空きスペース領域のリスト維持するステップと、空きルート・ノードのリストを維持するステップと、空きスペース領域のリスト、及び空きルート・ノードのリストの１つからルート・ノードをオブジェクト構造に割り当てるステップと、空きスペース領域のリストのみから中間ノード、及びデータ・ブロックをオブジェクト構造に割り当てるステップと、を含んでいる。本方法は、また、不揮発性記憶装置からファイル・システム・オブジェクトを削除するステップを含んでいる。不揮発性記憶装置からファイル・システム・オブジェクトを削除するステップは、通常、空きルート・ノードのリストにルート・ノードを追加するステップと、空きスペース領域のリストに中間ノード、及びデータ・ブロックを追加するステップとを含んでいる。

本発明の別の実施形態には、ファイル・システムにオブジェクトの読取り専用バージョンを保持する方法が付与されている。本方法は、オブジェクト用のオブジェクト構造を維持するステップを含んでおり、そのオブジェクト構造は、オブジェクトの現行バージョンと、多数の中間ノードと、オブジェクト・データを記憶する多数のデータ・ブロックと、とに関連付けられた少なくともルート・ノードを含み、各ノードは、ルート・ノードから各データ・ブロックまでの経路を形成するために、少なくとも１つのデータ・ブロック、または別のノードのリファレンスを含んでいる。本方法は、また、オブジェクト構造を不揮発性記憶装置に記憶するステップと、オブジェクトの保持バージョン用のルート・ノードのコピーを作成するステップとを含んでいる。本方法はまた、オブジェクトのオブジェクト構造にルート・ノードのコピーのリファレンスを記憶するステップを含んでもよい。本方法は、また、ルート・ノードのコピーにルート・ノードのリファレンスを記憶するステップを含むことができる。本方法は、また、ルート・ノードからルート・ノードの以前のバージョンのリファレンスを入手するステップと、ルート・ノードのコピーにルート・ノードの以前のバージョンのリファレンスを記憶するステップと、ルート・ノードの以前のバージョンにルート・ノードのコピーのリファレンスを記憶するステップとを含むことができる。本方法は、また、不揮発性記憶装置にルート・ノードのコピーを記憶するステップを含むことができる。

本方法は、オブジェクトの保持バージョンと関連付けられた全ての中間ノードまたはデータ・ブロックも修正せずにオブジェクト・データを修正するステップを含んでもよい。オブジェクトの保持バージョンと関連付けられた全ての中間ノードまたはデータ・ブロックも修正せずにオブジェクト・データを修正するステップは、通常、データ・ブロックのコピーを作成するステップと、データ・ブロックのコピーを修正してデータ・ブロックの修正済みコピーを作るステップと、オブジェクトの保持済みバージョンと関連付けられたデータ・ブロックへの経路に沿った全ての中間ノードを修正せずにルート・ノードからデータ・ブロックの修正済みコピーまでの経路を形成するステップとを含んでいる。ルート・ノードはデータ・ブロックのリファレンスを有することができる。このリファレンスは修正されデータ・ブロックでなくデータ・ブロックの修正済みコピーを参照する。あるいは、ルート・ノードからデータ・ブロックの修正済みコピーまでの経路は、データ・ブロックのリファレンスを有するルート・ノードにより参照される中間ノードを含むことができるが、この場合には、中間ノードのコピーが作成され、修正されて、データ・ブロックではなく、データ・ブロックの修正済みコピーが参照される。ルート・ノードは修正されて中間ノードのコピーが参照される。あるいは、ルート・ノードからデータ・ブロックまでの経路は、ルート・ノードが参照する少なくとも第１の中間ノード、及びデータ・ブロックのリファレンスを有する最後の中間ノードを含む複数の中間ノード含んでもよいが、この場合には、各中間ノードのコピーが作成されて、ルート・ノードは、修正され第１の中間ノードのコピーを参照し、最後の中間ノードのコピーは修正されデータ・ブロックの修正済みコピーを参照し、ルート・ノードからデータ・ブロックの修正済みコピーまでの経路を形成するため、他の各中間ノードのコピーは修正され、別の中間ノードのコピーを参照する。

本方法は、また、オブジェクトの保持済みバージョンと関連付けられた全ての中間ノードまたはデータ・ブロックも修正せずにオブジェクトからデータ・ブロックを削除するステップを含むことができる。ルート・ノードはデータ・ブロックのリファレンスを有してもよいが、この場合には、オブジェクトからデータ・ブロックを削除するステップは、ルート・ノードからデータ・ブロックのリファレンスを削除するステップを含む。あるいは、ルート・ノードからデータ・ブロックまでの経路は、ルート・ノードにより参照され、データ・ブロックのリファレンスを有する中間ノードを含んでもよいが、この場合には、オブジェクトからデータ・ブロックを削除するステップは、中間ノードのコピーを作成するステップと、中間ノードのコピーからデータ・ブロックのリファレンスを削除するステップと、ルート・ノードを修正して中間ノードのコピーを参照するステップとを含む。あるいは、ルート・ノードからデータ・ブロックまでの経路は、ルート・ノードにより参照される少なくとも第１の中間ノード、及びデータ・ブロックのリファレンスを有する最後の中間ノードを含む複数の中間ノードを含んでもよいが、この場合には、オブジェクトからデータ・ブロックを削除するステップは、各中間ノードのコピーを作成するステップと、ルート・ノードを修正して第１の中間ノードのコピーを参照するステップと、最後の中間ノードのコピーからデータ・ブロックのリファレンスを削除するステップと、ルート・ノードから最後の中間ノードまでの経路を形成するために、他の各中間ノードのコピーを修正し別の中間ノードを参照するステップとを含む。

本方法は、オブジェクトの保持済みバージョンと関連付けられた全ての中間ノードまたはデータ・ブロックを修正せずに、新しいデータ・ブロックをオブジェクトに追加するステップを含むことができる。新しいデータ・ブロックをオブジェクトに追加するステップは、新しいデータ・ブロックを割り当てるステップと、新らしいデータ・ブロックのリファレンスをルート・ノードに追加するステップとを含むことができる。新しいデータ・ブロックをオブジェクトに追加するステップは、新らしいデータ・ブロックを割り当てるステップと、中間ノードのコピーを作成するステップと、新らしいデータ・ブロックのリファレンスを中間ノードのコピーに記憶するステップと、中間ノードのコピーのリファレンスをルート・ノードに記憶するステップとを含んでもよい。新データ・ブロックのオブジェクトへの追加ステップは、新データ・ブロックの割当てステップと、新中間ノードの割当てステップと、新データ・ブロックのリファレンスを新中間ノードに記憶するステップと、ルート・ノードに新中間ノードのリファレンスを記憶するステップとを含むことができる。新データ・ブロックを追加するステップは、新データ・ブロックの割当てステップと、新中間ノードの割当てステップと、新データ・ブロックのリファレンスを新中間ノードに記憶するステップと、新中間ノードへの経路をオブジェクトの保持済みバージョンと関連付けられた全ての中間ノードまたはデータ・ブロックを修正せずに形成するステップとを含むことができる。

本方法は、また、オブジェクトの保持済みバージョン用の修正済みオブジェクト・リストを維持するステップを含むことができる。修正済みオブジェクト・リストは、オブジェクトの保持済みバージョン用のルート・ノードのコピー作成後に追加され、修正され、削除された全ての中間ノードを示している。

本方法は、また、ファイル・システムからオブジェクトの保持済み読取り専用バージョンを削除するステップを含むことができる。ファイル・システムからオブジェクトの保持済み読取り専用バージョンを削除するステップは、オブジェクトの読取り専用バージョンを保持した後、修正された全ての中間ノード、及びデータ・ブロックを識別するステップと、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーを識別するステップと、オブジェクトの以前の保持済みバージョンと関連付けられたルート・ノードで、それが存在する場合に識別するステップと、オブジェクトの最後の保持済みバージョンとオブジェクトの現行バージョンの１つである、オブジェクトの最後のバージョンと関連付けられたルート・ノードを識別するステップと、削除されるオブジェクトの保持済みバージョンと関連付けられた全ての中間ノード、及びデータ・ブロックを識別するステップと、削除されるオブジェクトの保持済みバージョンによってのみ使用される全ての中間ノード、及びデータ・ブロックを識別するステップと、削除されるオブジェクトの保持済みバージョンによってのみ使用される各中間ノード、及びデータ・ブロックをオブジェクト構造から削除するステップと、オブジェクトの後のバージョンによって使用される全ての中間ノード、及びデータ・ブロックを識別するステップと、オブジェクトの後のバージョンによって使用される全ての中間ノード、及びデータ・ブロックをオブジェクトの後のバージョンと関連付けられた修正済みオブジェクト・リストに追加するステップと、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーが削除されるオブジェクトの保持済みバージョンにのみ使用されたかどうかを判断するステップと、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーが削除されるオブジェクトの保持済みバージョンにのみ使用された場合かつその場合に限り、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーをオブジェクトから削除するステップとを含む。オブジェクトの保持済み読取り専用バージョンで修正される全ての中間ノード、及びデータ・ブロックを識別するステップは、通常、オブジェクトの読取り専用バージョンを保持した後で修正済みの中間ノード、及びデータ・ブロックのリストを維持するステップを含んでいる。オブジェクトの保持済み読取り専用バージョン用ルート・ノードは、通常、オブジェクトの以前の保持済みバージョンのルート・ノードのリファレンスで、それが存在する場合は含み、オブジェクトの以前の保持済みバージョンと関連付けられたルート・ノードを識別するステップは、通常、オブジェクトの保持済み読取り専用バージョン用のルート・ノードの中のオブジェクトの以前の保持済みバージョンのルート・ノードのリファレンスにアクセスするステップを含んでいる。オブジェクトの保持済み読取り専用バージョン用のルート・ノードは、通常、オブジェクトの後のバージョンのルート・ノードのリファレンスを含み、オブジェクトの後のバージョンと関連付けられたルート・ノードの識別するステップは、オブジェクトの保持済み読取り専用バージョン用のルート・ノードの中のオブジェクトの後のバージョンのルート・ノードのリファレンスにアクセスするステップを含んでいる。削除されるオブジェクトの保持済みバージョンによってのみ使用される全ての中間ノード、及びデータ・ブロックを識別するステップは、通常、削除されるオブジェクトの保持済みバージョンの各中間ノード、及びデータ・ブロックについては、オブジェクトの以前のバージョン、及びオブジェクトの後のバージョンに等価の中間ノードまたはデータ・ブロックがあれば識別するステップと、オブジェクトの以前のバージョンと、オブジェクトの後のバージョンとの双方で、削除されるオブジェクトの保持済みバージョンの中間ノードまたはデータ・ブロックを等価の中間ノードまたはデータ・ブロックと比較するステップと、等価の中間ノードまたはデータ・ブロックが、それが存在する場合、オブジェクトの以前のバージョン、及びオブジェクトの後のバージョンにおいて、異なる場合かつその場合に限り、中間ノードまたはデータ・ブロックが削除されるオブジェクトの保持済みバージョンによってのみ使用されていることを判断するステップとを含む。各削除済み中間ノード、及びデータ・ブロックは通常空きスペース領域にリストに追加される。オブジェクトの以前の保持済みバージョンと関連付けられたルート・ノードは、通常、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーのリファレンスを含み、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーのリファレンスを、これが存在する場合、オブジェクトの後のバージョンと関連付けられたルート・ノードのリファレンスで置き換え、リファレンスが存在しない場合、ヌル値で置き換えるステップを含んでいる。オブジェクトの後のバージョンと関連付けられたルート・ノードは、通常、削除される保持済みバージョン用のルート・ノードのコピーのリファレンスを含み、削除される保持済みバージョン用のルート・ノードのコピーをオブジェクト構造から削除するステップは、通常、削除されるオブジェクトの保持済みバージョン用のルート・ノードのコピーのリファレンスを、これが存在する場合、オブジェクトの以前のバージョンと関連付けられたルート・ノードのリファレンスで置き換え、リファレンスが存在しなければ、ヌル値で置き換えるステップを含んでいる。ルート・ノードの削除済みコピーは、通常、空きルート・ノードのリストに追加される。

本発明の別の実施形態には、ファイル・システムのオブジェクトの一部の内容を示す方法が付与されている。本方法はオブジェクトの多数のデータ・ブロックを含むオブジェクト構造を維持するステップ、及び各データ・ブロックごとの標識を維持するステップとを含み、各標識は、対応するデータ・ブロックが論理的に所定値で満たされていることを示す第１のの状態と、対応するデータ・ブロックがオブジェクト・データを含むことを示す第２の状態とを有する。各標識は、通常、対応するデータ・ブロックを参照するノードに維持されている。所定値は、通常、ゼロ値である。本方法は、また、所定値を対応するデータ・ブロックに書き込まずに、対応するデータ・ブロックが論理的に所定値で満たされていることを示す第１の状態に標識を設定するステップを含む。本方法は、また、オブジェクト・データをデータ・ブロックに書き込むステップと、データ・ブロックに対応する標識を対応するデータ・ブロックがオブジェクト・データを含むことを示す第２の状態に設定するステップとを含んでいる。

本発明の別の実施形態では、ファイル・システムのスパース・オブジェクトを割り当てる方法を付与している。本方法は、ルート・ノードをオブジェクトに割り当てるステップと、必要に応じて追加のノード、及びデータ・ブロックをゼロで埋められていないオブジェクトの部分にのみ割り当てるステップとを含んでいる。各ノードは、データ・ブロックおよび／または他のノードの多数のリファレンスを含む。各ノードは、通常、別のノードの各リファレンスごとの標識を含む。各標識は、他のノードが割り当てられたことを示す第１の状態、及び他のノードが割り当てられていないことを示す第２の状態を有する。未割当てノードと関連付けられた各リファレンス用の標識が最初に第２の状態に設定される。オブジェクト・データを前記オブジェクトのゼロで埋められた部分に書き込むために、追加のノード、及びデータ・ブロックが割り当てられ、割当て済みノードのリファレンスを割り当て済みノードのリファレンスを有する各ノードに記憶するとともに、割当て済みノードのリファレンス用標識を前記第１の状態に設定する。

本発明の別の実施形態では、ファイル・システムにオブジェクトと関連付けられたメータデータを記憶する方法が付与されている。本方法は、少なくともルート・ノードと、随意的に中間ノード、及びデータ・ブロックとを含む、オブジェクト用第１のオブジェクト構造を維持するステップ、並びにメタデータの第１の部分をルート・ノードに記憶するステップを含む。本方法は、また、多数のデータ・ブロックをメタデータの第２部分の記憶に割り当てるステップも含んでいる。本方法は、また、第２のオブジェクト構造をメタデータの第３の部分の記憶用に割り当てるステップを含む。この場合には、第２のオブジェクト構造のリファレンスは、通常、第１のオブジェクト構造、例えば、第１のオブジェクト構造のルート・ノード、またはメタデータの第２部分に記憶される。

本発明の別の実施形態では、不発性記憶装置と、オブジェクトの現行バージョンを管理するための２つ、及び２つだけ有するオブジェクト構造を用いて継続的なチェックポイントで不揮発性記憶装置にファイル・システム・オブジェクトを維持する手段とを含む装置が設けられ、この手段は継続的チェックポイントで前記オブジェクトの管理用の前記２つのルート・ノードの間で交互に繰り返す。装置は、また、通常、オブジェクト構造を介してオブジェクトの読取り専用バージョンを保持する手段を備えている。装置は、また、通常、オブジェクトからオブジェクトの保持済み読取り専用バージョンを削除する手段を備えている。装置は、また、通常、オブジェクトの少なくとも１つの保持済み読取り専用バージョンがオブジェクト構造に存在する間は、オブジェクトの現行バージョンを削除する手段を備えている。装置は、また、通常、オブジェクトの現行バージョンをオブジェクトの保持済み読取り専用バージョンに復帰させる手段を備えている。

本発明の別の実施形態では、不揮発性記憶装置を有するファイル・システムにファイル・システム・オブジェクトを維持する方法が付与されている。本方法は、複数のファイル・システム・オブジェクトのそれぞれのオブジェクト構造であって、少なくとも１つのルート・ノード、及び随意的に多数の中間ノード、及び多数のデータ・ブロックを含むオブジェクト構造を維持するステップと、全ての修正済みノードを識別するトランザクション・ログを維持するステップと、不揮発性記憶装置にトランザクション・ログにより識別された全ての修正済み中間ノードを記憶するステップと、不揮発性記憶装置にトランザクション・ログを記憶するステップと、不揮発性記憶装置にトランザクション・ログを記憶した後にのみ、不揮発性記憶装置にトランザクション・ログによって識別された全ての修正済みルート・ノードを記憶するステップと、を含む。本方法は、また、不揮発性記憶装置へのトランザクション・ログの記憶時と、不揮発性記憶装置へのトランザクション・ログによって識別された全ての修正済みルート・ノードの記憶時との間に故障が起きたことを判断するステップと、トランザクション・ログによって識別された各ノードに関しては、不揮発性記憶装置に記憶されたノードの以前のバージョンに復帰するステップとを含んでいる。

本発明の別の実施形態では、共有資源を管理する少なくとも第１のファイル・サーバと、共有資源にアクセスする第２のファイル・サーバとを有する分散型ファイル・システムにおける共有資源へアクセスする方法が付与されている。本方法には、共有資源用のキャッシュを第２のファイル・サーバにより維持するステップと、共有資源への読み込みアクセスを第２のファイル・サーバにより第１のファイル・サーバに要求するステップと、共有資源への読み込みアクセスを第１のファイル・サーバにより第２のファイル・サーバへ与えるステップと、共有資源データを前記第２のファイル・サーバにより前記第１のファイル・サーバから得るステップと、第２のファイル・サーバにより共有資源をキャッシュに記憶するステップと、を含んでいる。

本発明の別の実施形態では、共有資源を管理する少なくとも第１のファイル・サーバと共有資源にアクセスする第２のファイル・サーバとを有する分散型ファイル・システムにおける共有資源へアクセスする方法が付与されている。本方法は、第２のファイル・サーバにより共有資源用のキャッシュを維持するステップと、第２のファイル・サーバによる共有資源への読み込みアクセスを第１のファイル・サーバに要求するステップと、第１のファイル・サーバにより共有資源への読み込みアクセスを第２のファイル・サーバに対して否認するステップと、第１のファイル・サーバにより共有資源データを前記第２のファイル・サーバへ与えるステップと、第２のファイル・サーバによりキャッシュから共有資源データを省略するステップとを含む。

本発明の別の実施形態には、複数のファイル・サーバの間で共有する資源を有する分散型ファイル・システムにおけるオペレーション用のファイル・サーバが設けられている。ファイル・サーバには、共有資源と関連付けられたデータを記憶するためのキャッシュと、共有資源へのアクセスを制御する分散型ロック手段であって、作動可能に接続されキャッシュの共有資源データを選択的に記憶する分散型ロック手段と、を備えている。

（発明の実施の形態）
用語の定義について述べる。明細書本文、及び特許請求の範囲に使用されている以下の用語は、文脈上、他の意味に解すべき場合を除き、指示した意味を有するものとする。即ち、「データ記憶システム」は、適切な大型のデータ記憶装置であって、１台または複数の磁気、また磁気光学、または光ディスク・ドライブ群、並びに固体記憶装置、及び磁気テープを含むが、これらに限定するものではない。便宜上、データ記憶システムは、「ディスク」、または「ハード・ディスク」と呼ばれることもある。「ハードウェア実行サブシステム」なる語は、主なサブシステム機能はソフトウェア・プログラムの力が直接及ばないところで作動する専用ハードウェアの中で果たされるサブシステムを意味する。この種のサブシステムは、ソフトウェアの制御下にあるプロセッサと影響し合うこともあるが、サブシステム自体はソフトウェアにより直接制御されることはないことを留意すべきである。「主な」機能とは、使用頻度が高い機能のことである。

「ハードウェア加速サブシステム」とは、主なサブシステム機能が専用のプロセッサ、及び専用のメモリ、さらに（または代替的に）、特殊目的のハードウェアを使って発揮させられるものである。換言すれば、専用のプロセッサ、及びメモリは、いかなる中央処理装置（ＣＰＵ）、及びＣＰＵと関連したメモリとは異なる。

「ファイル」とは、データの論理的結合である。

「メタデータ」は、実際のファイル内容データとは対照的にファイル・オバーヘッド情報を指している。

「ファイル内容データ」は、ファイル・オバーヘッド情報が全くないファイル・データを指す。

ここに記載の内容に関し、Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ という表題で共有米国特許出願番号１０／２８６，１５３が、Ｆｒａｎｃｅｓｃｏ Ｌａｃａｐｒａ，Ｆｉｏｒｅｎｚｏ Ｃａｔｔａｎｅｏ，Ｓｉｍｏｎ Ｌ．Ｂｅｎｈａｍ，Ｔｒｅｖｏｒ Ｅ．Ｗｉｌｌｉｓ，Ｃｈｒｉｓｔｏｐｈｅｒ Ｊ．Ａｓｔｏｎ の名義で同日付けで出願され、全体を参照することにより本書に盛り込まれている。

図１は、本発明の様々な態様が適用されるファイル・サーバの実施形態のブロック線図である。この種のファイル・サーバは、２００１年４月１９日付けで公表されたＰＣＴ出願番号ＷＯ０１／２８１７９ Ａ２の表題が、Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｈａｒｄｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｒ Ａｃｃｅｌｅｒａｔｉｏｎ ｏｆ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｆｕｎｃｔｉｏｎｓ（この中の共同発明者も、同じく共同発明者である発明を説明した文書であるが）も参照することにより本書に盛り込まれている。図１は、上述のＰＣＴ出願の図３に概ね対応している。図１の中のファイル・サーバ１２は、ネットワーク１１とつながったサービス・モジュール１３を含む構成要素を有している。サービス・モジュール１３は、ネットワークからサービス要求を受け取るとともに応答し、ファイル・システム・モジュール１４とつながっており、記憶アクセスに関するサービス要求を関連のファイル・システム・プロトコルに合ったフォーマットに直す（及び、要求を発出するこのようなフォーマットから、このような要求に直す）。次に、ファイル・システム・モジュール１４は、記憶モジュール１５とつながることによって、ファイル・システム・モジュール１４の出力を、記憶モジュール１５がつながっている記憶システムへのアクセスが可能なフォーマットに変換する。記憶モジュールは、記憶装置に書込み、読取られるファイル内容データ用のセクター・キャッシュを有している。前記ＰＣＴ出願で説明したように、各種モジュールはそれぞれハードウェア実行でもハードウェア加速でもよい。

図２は、図１の実施形態の実行に関するブロック線図である。この実行においては、図１のサービス・モジュール１３、ファイル・システム・モジュール１４、記憶モジュール１５は、それぞれネットワーク・インターフェイス・ボード２１、ファイル・システム・ボード２２、記憶インターフェイス・ボード２３により実行される。記憶装置インターフェイス・ボード２３は、記憶装置２４とつながっており、実施の形態で用いられる記憶システムを構成している。この実行に関しては、Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｈａｒｄｗａｒｅ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｒ Ａｃｃｅｌｅｒａｔｉｏｎ ｏｆ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｆｕｎｃｔｉｏｎｓという表題の２００１年６月１２日付け出願の米国出願、連続番号０９／８７９，７９８に、さらに詳細に記載され、参照することとにより本書に盛り込まれている。

図３は、本発明によるファイル・システム・モジュールの実施形態のブロック線図である。ファイル・システム・モジュールの実施形態は、図１、及び図２で説明したタイプのシステムに用いることができる。各種インターフェイス用の例示的なバス幅が示してあるが、本発明はこれらのバス幅、またはどのような特定のバス幅にも限定されるものではないことに留意すべきである。

この実施形態のデータの流れは、Ｔｏ Ｄｉｓｋ Ｐｒｏｔｏｃｏｌ を略して、ＴＤＰと呼ばれる上位バス３１１、及び、Ｆｒｏｍ Ｄｉｓｋ Ｐｒｏｔｏｃｏｌを略して、ＦＤＰと呼ばれる下位バス３１２によって示されている。このようなプロトコルは、普通、例えば図２の記憶インターフェイス・ボード２３によって実行できる図１の記憶モジュール１５との通信を指している。ファイル・システム・モジュールは、常に、データバス３１１、及びデータバス３１２とは異なる制御経路を使用し、この制御経路の中では、データバス３１１、及びデータバス３１２により伝送されるデータのポインタを用いている。データバス３１１、及びデータバス３１２は、それぞれ書込みバッファ ＷＲＢＵＦＦ、及び読取りバッファ ＲＤＢＵＦＦを備えている。例えば、磁気テープなどへのバックアップ目的のため、図面の左部分にＣＯＰＹＰＡＴＨとして確認できる、データバス３１２からデータバス３１１への２つのバッファの間にダイレクト・データ・パスが設けられている。

このファイル・システム・モジュールで個別になっているサブモジュール系列は、ファイル・システム管理に関したタスクを処理している。これらのサブモジュールは、通常それぞれ自前のキャッシュメモリを有し、サブモジュールのタスクに関したメタデータを記憶している。（メタデータとは、実際のファイル内容データとは対照的にファイル・オバーヘッド情報を指している。ファイル内容データは、上述のデータバス３１１、及びデータバス３１２を通って処理される。）これらのサブモジュールは、空きスペース割当て３２１、オブジェクト記憶３２２、ファイル・システム・ツリー３２３、ファイル・システム・ディレクトリ３２４、ファイル・システム・ファイル３２５、不揮発性記憶装置処理３２６である。

サブモジュールは、プロセッサの普通の管理下で動作するが、処理されるファイル・システム要求の内容により命じられる方法でサブモジュールの特殊なタスクを処理するよう組織化されている。具体的には、より上位のサブモジュールは連続的に左側のより遠くに位置するようにサブモジュールは階層的に配列されている。各サブモジュール左側から要求を受け取るとともに、各要求を満たし、左側へ応答を送る仕事を行う。そして、もしサブモジュールが要求を直接に満たしえない場合には、次に要求を発出して、それを右側へ送り、従属する右側のサブモジュールから回答を受け取ることができる。任意のサブモジュールは、従属のサブモジュールにより提供される回答を、同様のデータに対しての要求を再度送ることがないように、近い所のその関連のキャッシュに記憶ができる。一実施例においては、これらのサブモジュールは、適当に構成したＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）を使って、ハードウェアに実装される。各サブモジュールは、別個のＦＰＧＡを用いて実装してもよい。または、多数のブモジュールを単体のＦＰＧＡに組み入れてもよい。（例えば、ファイル・システム・ツリー３２３、及びファイル・システム・ディレクトリ３２４を単体のＦＰＧＡに組み入れることもできる）。あるいは、各サブモジュール（または、サブモジュールの組合せ）は、例えば、本目的にそってプログラムされた集積回路、または専用のプロセッサを用いて実装することができる。

本書で付与されているファイル・システムの実施形態は自然界に分布していることが分かる。この自然界での分布により、ファイル内容キャッシュとは異なるキャッシュメモリのファイル・システムと関連付けたメタデータ全てを保持することができる。この配置（配列）には、メタデータが関係するファイルのサイズ、及びファイル操作処理のスループットの増加、及びプロセッサ・オーバーヘッドの減少に関係なく、大量のメタデータをキャッシュに入れる能力を含む数多くの利点がある。

ファイル・システムの要求の処理は、例えば１０秒毎に、あるユーザ設定期間よりも低くない頻度で起こるよう計画した一連のチェックポイントを図で詳細に表す。各連続したチェックポイントに関しては、以前に記憶されたファイル構造情報が直前のチェックポイントに取って替わる、ディスクに記憶した現行のファイル構造情報が記憶されている。チェックポイントには連続番号が付けられ、ファイル要求の処理を一時的にグループ化するのに使用される。

ある選択された時点のファイル・システム構造の知識を持つことは多様な目的に対し有益であるかもしれない。この能力は、現行のセーブ済みチェックポイントに関連付けされたファイル・システム構造データのユーザ・トリガ記憶を可能にすることで与えられ、以下、便宜上、保持済みチェックポイントと称し、以下に詳細に述べる。保持済みチェックポイントは、本質的に、特定のチェックポイントにおけるファイル・システム構造の読取り専用版である。多数の保持済みチェックポイントを取得することができ、メカニズムには、選択された保持済みチェックポイントを削除、またはファイル・システムを選択された保持済みチェックポイントに復帰（例えば、ファイル・システムをカタストロフィの後に続くわかっている状態に戻る）が含まれる。

ファイル・システムモジュールの中心には、オブジェクト記憶サブモジュール３２２がある。この実装においては、ハードディスクに記憶される項目の全てが、形式（例えば、ファイル、ディレクトリ、空きスペースの割当情報、最後のチェックポイントを取得した後で作成され修正されたオブジェクトのリスト、最後の保持済みチェックポイントを取得した後で作成され修正されたオブジェクトのリスト、及び、あるファイルの属性情報を含む）に関係なくオブジェクトと見なし、このような項目の記憶はオブジェクト記憶サブモジュール３２２で取り扱われる。オブジェクト記憶サブモジュールオブジェクトに関する次のオペレーションを行うことができる。即ち、作成、削除、書込み、及び読取りである。さらに、プロセッサからの命令により、オブジェクト記憶サブモジュールはチェックポイントを作成し、また保持済みチェックポイントをも作成、保持済みチェックポイントを削除、またはファイル・システムを保持済みチェックポイントへ復帰させることができる。オブジェクト記憶サブモジュールは、ディスク上に記憶されたデータの物理的位置を追跡することにより、以下に説明する各種のデータ構造を用いて各オブジェクトと関連付けらる。オブジェクト記憶サブモジュールは、バス３１１の通信リンクにディスク記憶要求を送らせバス３１２の通信リンクによりディスク記憶回答を入手する。もし、オブジェクト記憶サブモジュールは、読取りオペレーションための要求を受け取ったら、オブジェクト記憶サブモジュールは、バス３１１に働きかけることで要求を直接満足させることができる。

本書のファイル・システムの実施形態が使用されている記憶システムは「ディスク」と称されるが、記憶システムは、１台または複数の磁気、また磁気光学、または光ディスク・ドライブ群、並びに固体記憶装置、及び磁気テープを含むが、これらに限定しない、適当な大量のデータ記憶構成であればどのようなものであってもよいことは言うまでもない。

空きスペース割当てサブモジュール３２１は、オブジェクト記憶サブモジュール３２２の動作に必要なデータを管理し、オブジェクト記憶サブモジュール３２２の影響を受けて、ディスク上のスペースの総合的割当てを探知する。オブジェクト記憶サブモジュール３２２から要求を受け取ると、空きスペース割当てサブモジュール３２１は、利用可能なブロック番号をオブジェクト記憶サブモジュールに提供する。空きスペース割当を探知するために、空きスペース割当てサブモジュールは、ディスク上のデータの各ブロックの空きおよび／または空いてない状態を示す単一ビットで、ディスクのビット・マップを確立する。このビット・マップ自体は、オブジェクト記憶サブモジュールにより処理される特殊なオブジェクトとしてディスクに記憶されている。一方では、オブジェクト記憶サブモジュールは、ディスク上で空きスペースの管理と割当の目的で、空きスペース割当サブモジュールと双方向の通信路を有し、他方では、空きスペース割当サブモジュールは、ディスク空きスペース・ビット・マップ用のデータを検索したり、更新するためのオブジェクト記憶サブモジュールとの双方向の通信路を有しているので、オブジェクト記憶、及び空きスペース割当サブモジュールの間には２つの双方向経路がある。

ファイル・システム・ファイル・サブモジュール３２５は、ファイルのタイム・スタンプ、ファイルの所有者、ファイルのリンク数（即ち、ファイルが所有する名前の数）、読取り専用の状態などのファイルの属性と関連付けられたデータ構造を管理する。中でも、とりわけ、本サブモジュールは、ファイルを作成する要求を取り扱い、ディレクトリを作成し、親ディレクトリのファイル名を挿入し、親ディレクトリを更新する。このサブモジュールは、次に、以下に説明する他のサブモジュールと対話を行う。

ファイル・システム・ディレクトリ・サブモジュール３２４は、ディレクトリの管理を行う。ディレクトリは、リスト・ファイルとして管理され、これらのファイルは、このファイルの関連付けられたオブジェクト番号と一緒に、ディレクトリと関連付けられる。ファイル・システム・ディレクトリ・サブモジュール３２４は、各ディレクトリの次のオペレーションを管理する。即ち、作成、削除、ファイルのディレクトリへの挿入、エントリの削除、エントリの探索、ディレクトリの内容のリスト作成である。

ファイル・システム・ディレクトリ・サブモジュール３２４は、ファイル・システム・ツリー・サブモジュール３２３と協働して効率的なディレクトリ検索を行う。従来のツリー構造はディレクトリ用に作成されるが、木の分岐を、ファイル名自体を使うのではなく、ファイル名から生成されるＣＲＣ（巡回冗長合計検査）などの擬似乱数値を使って、非アルファベット的方法で処理する。ＣＲＣは、各ファイル名に対して無作為であり、普通は、特有な傾向にあるので、通常、この方法は、ファイル名の全てが偶然類似していたとしても、木を強制的に平衡させる。このため、新しいファイル名の入ったディレクトリ一覧表を更新する際には、ファイル・システム・ディレクトリ・サブモジュール３２４は、ファイル名のＣＲＣを生成し、ファイル・システム・ツリー・サブモジュール３２３にそのインデックスのＣＲＣを利用するよう要求する。ファイル・システム・ツリー・サブモジュールは、ファイル名のＣＲＣをディレクトリ表のインデックスと間連付けを行う。このようにして、サブモジュールはＣＲＣの検索を行うとともに、インデックスを復帰させる。

ファイル・システム・ツリー・サブモジュール３２３は、ファイル・システム・ディレクトリ・サブモジュール３２４と同様の方法で働き、以下の機能を支援している。即ち、作成、削除、ＣＲＣのディレクトリへの挿入、エントリの削除、エントリの探索である。しかしながら、どの場合も、その機能はファイルではなく、ＣＲＣに関するものである。

もっともまれな場合で、２つの異なるファイル用のＣＲＣが同じである場合があり、ファイル・システム・モジュールは、このような場合でも処理する必要がある。このような状態に対応するために、ファイル・システム・ツリー・サブモジュール３２４は同じＣＲＣを有する全ファイルのリストを維持するとともに、ＣＲＣを有する任意のあるファイルから同じＣＲＣを有する別のファイルまでのポインタを有することによって確実に維持している。（ＣＲＣが相対的にユニークであるため、これは、最終選考リストになりそうであるである。）ファイル・システム・ディレクトリ３２４は、任意のあるファイル用のリストの始点を維持している。

不揮発性記憶装置処理サブモジュール３２６は、不揮発性記憶装置（図３に示すＮＶＲＡＭと称される）と、インターフェイスで連結され、停電時や他の事態において、ディスクにセーブされる予定のキャッシュ・データが実際にディスクにセーブされないよう防ぐための復帰の方法を備えている。具体的には、最後のチェックポイント（チェックポイントは図３の説明の冒頭近くで、説明済みである）において、ファイル・システム構造一式が記憶されているので、不揮発性記憶装置処理サブモジュール３２６のタスクとしては、最後のチェックポイントの後のファイル・システム・要求データを記憶することである。この方法においては、回復、ファイル・システム要求データの処理の次の中断は、最後の記憶されているチェックポイントからファイル・システム構造データを用い、次に、ＮＶＲＡＭに記憶されているその次のファイル・システム要求を再度処理することにより達成できる。

オペレーション中に、受け取ったあらゆるファイル・システム要求（未修正の要求を除く）に関して、プロセッサが、不揮発性記憶装置処理サブモジュール３２６に、ＮＶＲＡＭに要求を記憶するかどうかを伝える。そして、仮に、そのように伝えると、次に、ＮＶＲＡＭにその要求を記憶する。（もし、本サブモジュールが、マルチ・ノードのファイル・サーバ・システムの一部である場合には、その要求も、別のノードのＮＶＲＡＭに記憶される。）サブモジュールのそばの（及び別のファイル・サーバ・ノードの任意の対になったサブモジュールのそばの）ＮＶＲＡＭの中に局所的に記憶装置が存在すると、サブモジュールが、判断するまで、クライアントには要求履行の受取通知は返送されない。このファイル・システム要求のキャッシング方法は、プロセッサがファイル・システム要求をＮＶＲＡＭに最初に書き込み、次いでディスクに書き込む、従来のシステムとはかなり違っている。ファイル・システム要求をＮＶＲＡＭにコピーする時に手間がかかるプロセッサがない（コピーは自動的に行われる。）ために、この方法は違っているのである。

ＮＶＲＡＭのオーバーフローを避けるために、チェックポイントは、ＮＶＲＡＭのデータ量が所定の閾値に達した時には、強制的にチェックポイントが発生するようになっている。チェックポイントは、以前のチェックポイントがもはや存在しない時点における、次のチェックポイントが作成されるまでに限って有効である。

ファイル・サーバ・システムをクラスター化した時に、揮発性記憶装置をスイッチを用いてミラー化し、仮想ループを得るようにしてもよい。図６は、不揮発性メモリを垂直ループ構成でミラー化した本発明の実施形態によるクラスター化ファイル・サーバ構成のブロック線図である。本図において、５つのファイル・サーバ・ノードがクラスター化されていると仮定している。（この手法は、サーバ・ノードのどのような番号ともうまくいくが、各サーバ・ノードがファイル・システム・モジュールを結合し、そして、ファイル・システム・モジュールは、不揮発性記憶装置処理サブモジュール３２６、指定のＮＶ＿Ａ（項目６１）、ＮＶ＿Ｂ（項目６２）、ＮＶ＿Ｃ（項目６３）ＮＶ＿Ｄ（項目６４）ＮＶ＿Ｅ（項目６５）を有する。）これらのサブモジュールはそれぞれスイッチ６６を経由して、サブモジュールの中の異なる１つと接続されることにより、対応するサブモジュールに関連付けされたＮＶＲＡＭに記憶されている元のファイル・システム要求データのバックアップ・コピーを、接続されたサブモジュールに関連したＮＶＲＡＭが維持が可能となる。スイッチ６６による接続を破線で示してあり、バックアップ・パス６１１は、ＮＶ＿Ａに関連付けられたＮＶＲＡＭのファイル・システム要求データを、ＮＶ＿Ｂに関連付けれたＮＶＲＡＭによってバックアップが可能となる。同様に、バックアップ・パス６２１は、ＮＶ＿Ｂに関連付けられたＮＶＲＡＭのファイル・システム要求データを、ＮＶ＿Ｃなどに関連付けれたＮＶＲＡＭによってバックアップが、ループの最後の部分に達するまで、可能である。ここでバックアップ・パス６５１は、ＮＶ＿Ｅに関連付けられたＮＶＲＡＭのファイル・システム要求データを、ＮＶ＿Ａなどに関連付けれたＮＶＲＡＭによってバックアップが可能である。仮に、サーバ・ノードが、非稼働となった場合には、スイッチは、稼働している他の残りのノードからループを再構成できる。

本書で説明するように、整合性のあるファイル・システム・イメージ（チェックポイントと称する）が、等間隔でディスクに記憶されており、プロセッサにより要求されたが、チェックポイントのディスクに未だ記憶されていない全てのファイル・システム変更は、不揮発性記憶装置処理サブモジュールによりＮＶＲＡＭに記憶される。

システムが故障した場合には、プロセッサは、オンディスク・ファイル・システムが「クリーン」でないことを検出し、回復手順を開始する。先ず、オンディスク・ファイル・システムは、ディスクに記憶されている最後のチェックポイントで表される状態に戻される。これはチェックポイントであるから、内部的には整合性がある。しかしながら、チェックポイントを取得した後で要求される変化は全て喪失される。回復手順を完了するため、これらの変化は復旧させる必要がある。このことは可能である。何故なら、これらの変化は全てがプロセッサによって発出された要求により起きており、また、上記のように、プロセッサにより要求されたが、チェックポイントのディスクに未だ記憶されていない全てのファイル・システム変更は、不揮発性記憶装置処理サブモジュールによりＮＶＲＭに記憶されるからである。喪失した変化は、それゆえに、プロセッサによって要求されたファイル・システムの変更オペレーションの順序を、最後のチェックポイントの時から、システム故障まで繰り返すことにより回復可能である。

これを完了させるため、プロセッサはＮＶＲＡＭの内容を調べ、最後のチェックポイントの時から、システム故障までのプロセッサが要求したオペレーションの全てを抽出する。次いで、プロセッサはこれらの要求をファイル・システム・ファイル・サブモジュールに再提出し、必要なオンディスク変更を行うことにより要求を満足する。ファイル・システム・ファイル・サブモジュールは、「目下の」ファイル・システム要求と、回復手順中の発出されている再提出要求とを識別しない。双方とも同一の方法で（再提出要求がそこにないため、それがＮＶＲＡＭにログされない場合を除いて）処理される。

この手順で厄介なことは、ファイル（またはディレクトリ）参照を行うファイル・ハンドルに関することである。普通のオペレーションでは、ファイルが作成される時には、ファイルはファイル・ハンドルに割り当てられる。そのファイルを引き続き参照する必要があるオペレーションはいずれもこのファイル・ハンドルを用いてそのようにしている。従って、例えば、次のような一連のオペレーションが行われる。即ち、
（１）プロセッサはファイル作成を要求する。
（２）ファイル・システム・ファイル・サブモジュールはファイルを作成しファイル・ハンドルＡを返す。
（３）プロセッサはデータの書き込みをファイル・ハンドルＡに要求する。ファイルＡにデータを書き込むよう要求する？
（４）ファイル・システム・ファイル・サブモジュールは書き込みを実行する。

本例においては、手順（１）及び（３）の２つの要求は、ＮＶＲＡＭに記憶される。
ここで困った問題が持ち上がってくる。それは、上述の回復手続き中にファイル・システム・ファイル・サブモジュールが割り当てたファイル・ハンドルは、当初割り当てられたファイル・ハンドルとは異なる恐れがあるからである。従って、例えば、ＮＶＲＡＭに記憶されるオペレーションは、上記の例と同じものかも知れない。しかしながら、回復中においては、手順（２）でファイル・システム・ファイル・サブモジュールが戻すファイル・ハンドルはＢかも知れない。この場合には、ファイル・ハンドルＡは、ファイル・システム・ファイル・サブモジュールによって認識されていないので、ファイル・ハンドルＡを使った手順（３）のデータの書き込みはできていない。

この問題を解決するため、ファイルが作成される度に、プロセッサが明確にＮＶＲＡＭの中に割当て済みハンドルのログを行う。（これは不揮発性記憶装置処理サブモジュールへの特別要求によって行う。）従って、回復時のＮＶＲＡＭの内容は、以下の通りである。即ち、
（１）プロセッサはファイル作成を要求する。

ここで他の無関係要求に対するより多くのエントリがあるかもしれない。
（２）作成ファイルをファイル・ハンドルＡに割り当てる。

ここで他の無関係要求に対するより多くのエントリがあるかもしれない。
（３）プロセッサはデータの書き込みをファイル・ハンドルＡに要求する。

従って、回復手続き中に、作成オペレーションに遭遇した場合には、プロセッサはＮＶＲＡＭを探索して割当て済みハンドルを探し出す。そして、プロセッサは作成要求を発して、（潜在的に異なる）ハンドルを得る。この時点以降は、再生オペレーションにおける作成済みファイル用の以前のハンドルのリファレンスは全て、作成済みファイル用のハンドルで置き換えられる。

例えば、前記の回復手続きは以下のように進められる。即ち、
（１）プロセッサは、ファイル作成要求を再度提出する。

（２）ファイル・システム・ファイル・サブモジュールはファイルを作成し、ハンドルＢを戻す。

（３）プロセッサは、以前の割当て済みハンドルを探索し、以前に割当て済みハンドルがハンドルＡであるのか判断する。

（４）プロセッサは、ハンドルＡのＮＶＲＡＭのその後のリファレンスはどれもがハンドルＢで置き換えられるべきであるとこに留意する。

（５）プロセッサは、ハンドルＡをハンドルＢと取替え、データの書き込みをファイルＢに要求する。

（６）ファイル・システム・ファイル・サブモジュールは書き込みを実行する。

通常の実施形態では、あるファイル・システム要求に応ずる自動応答機構を利用している。図４は、ソフトウェア制御を介在させずにファイル・サービス・モジュールによってネットワーク・リクエストへの自動応答が可能となる本発明の実施形態への制御フローの使用方法を示すブロック線図である。図４には、図１と同様に、サービス・モジュール１３、ファイル・システム・モジュール１４、記憶モジュール１５があり、サービス・モジュール１３、及びファイル・システム・モジュール１４は、ソフトウェア４１の制御を受けており、記憶装置モジュール１５は記憶装置４２とつながっている。ブロック間の接続は、データ流れではなく制御流れを表している。サービス・モジュール１３がファイル・サービス要求を識別すると、要求は通常はサービス・モジュール１３からソフトウェア制御４１へ送られ、例えば、安全や他の複雑なタスクを処理する。次に、ソフトウェア制御４１の下で、要求はファイル・システム・モジュール１４により処理される。他方において、ファイル・システム要求への回答は、これは必ずしも複雑ではないが、ソフトウェア制御４１を経て返送されるのではなく、制御流れ４３を経由して、ファイル・システム・モジュール１４から、直接サービス・モジュール１３へと返送される。最終的に、ソフトウェア制御４１には、要求が満足されたことが伝えられる。

共通の記憶装置にアクセスするファイル・サーバ・ノードのクラスターを採用した構成においては、多数のノードが共通の記憶装置の配置に関する矛盾するタスクを行おうと努めるかもしれない事例に取り組む必要がある。図５は、本問題を扱う本発明の実施形態によるセクター・キャッシュ・ロッキングを具体化したクラスター化ファイル・サーバ構成のブロック線図である。本実施形態において、ファイル・サーバ・ノードＡ（項目５２）、及びファイル・サーバ・ノードＢ（項目５３）は、双方ともクライアント５１とつながっており、各サーバ・ノードがディスクＡ（項目５４）、及びディスクＢ（項目５５）の両方にアクセス（即ち、ディスクから読み取り、書き込み）できるように構成されている。（ここで、以前に説明した方法に類似した方法において、「ディスク」なる語は、任意の記憶装置識別子であるとともに、数枚のディスクの用途、例えば、または１台のディスク・ドライブ上の特別領域の用途を含んでいる。記憶装置のモードは、磁気、及び光磁気に適したどのようなものでも含むこれに限定するものではない。）
本実施形態においては、各サーバ・ノードは、セクター・レベルで、ディスクＡ、及びディスクＢのそれぞれのセークター・キャッシュを維持している。このような状況のもとでは、各サーバ・ノードがディスクの書き込みを処理する場合のキャッシュ整合性を得る方法に関する問題を解決する必要がある。この問題は次のように処理する。ある任意のディスクについては、サーバ・ノードの１つだけがディスクに書き込める。（クライアントはディスクに、またはサーバ・ノードを経由して、ディスクに書き込めるが。）例えば、図５においては、サーバ・ノードＡだけがディスクＡに書き込めるとともに、サーバ・ノードＢだけがディスクＢに書き込める。各サーバ・ノードは、サーバ・ノードが書き込むディスクのロック・マネージャを実行する。ディスクは３２キロバイト・ページに分割される。各ページは３つの状態の１つにできる。即ち、キャッシュされていない状態、読み取りがロックされている状態、または書き込みがロックされている状態である。

例として、サーバ・ノードＡがディスクＢの読取りをキャッシュに入れたいと希望している場合を想定する。従って、サーバ・ノードＡは、先ず、サーバ・ノードＢと連絡をとる必要がある。サーバ・ノードＡが読み取りを希望しているページの読取りロックを要求する。サーバ・ノードＡが読み取りロックの状態になると、サーバ・ノードＡはデータを読み取り、データをサーバ・ノードＡのセクター・キャッシュに置く。さて、サーバ・ノードＢが同じページの書き込みを希望している場合を想定してみよう。サーバ・ノードＢには、サーバ・ノードＡからこのページの読取りロックを有している旨、連絡済みである。従って、サーバ・ノードＢはサーバ・ノードＡと連絡を取って、サーバ・ノードＡの読取りロックの中断をサーバ・ノードＡに命令する。次に、サーバ・ノードＢは、サーバ・ノードＡからの読取りロックが解除された旨の連絡を待つ。（すると直ぐに、サーバ・ノードＡは、サーバ・ノードＡのキャッシュから、そのページを一気に消去する。）次に、サーバ・ノードＢは、書込みロックを有し、ページに書き込める。もし、サーバ・ノードＡが、再び、ページを読み込みたいと希望する場合には、サーバ・ノードＡは、読取りロックを要求する。サーバ・ノードＢは、読込みロックは否認するが、サーバ・ノードＢのキャッシュは更新する旨の応答をして、サーバ・ノードＡにキャッシュに入ったデータを転送する。サーバ・ノードＡは、このデータをキャッシュに入れられないので、読取りロックを否認される。次に、読込みロックは、ディスクＢがディスクＢのキャッシュから更新される場合に（即ち、次のチェックポイントにおいて）サーバ・ノードＡに与えてもよい。このように、上記の実行により、分散したロック・マネージャが付与され、ハードウェアにおいても、同様のことが行われる。

１．オブジェクト記憶構造
１．１ オブジェクト記憶データ構造の概要
オブジェクト記憶サブモジュールは、各種のファイル・システム・オブジェクトを維持し記憶するために用いられる。ファイル・システム・オブジェクトはファイル・オブジェクト、ディレクトリ・オブジェクト、空きスペース割当てオブジェクト、修正済みチェックポイント・オブジェクト・リスト・オブジェクト、修正済み保持オブジェクト・リスト・オブジェクト、及びｍノード・オブジェクトを含んでいる。ファイル・オブジェクトは、ユーザ・データ、及びワープロ、または表計算ファイルなど関連属性の記憶用ファイル・システム・ファイル・サブモジュールによって作成される。ディレクトリ・オブジェクトは、ディレクトリ情報の記憶用ファイル・システム・ディレクトリ・サブモジュールにより作成される。空きスペース割当てオブジェクトは、空きスペース割当情報の記憶用の空きスペース割当サブモジュールにより作成される。修正済みチェックポイント・オブジェクト・リスト・オブジェクト、及び修正済み保持オブジェクト・リスト・オブジェクト（双方とも、以下でさらに詳細に述べる。）は、それぞれチェックポイント、及び保持済みチェックポイントに関する情報の記憶用オブジェクト・記憶サブモジュールによって作成される。ｍノード・オブジェクト（以下にさらに詳細に説明する）は、ファイル、またはディレクトリ・オブジェクトに関連付けられた超過ファイル属性を保持するための特殊なオブジェクト（即ち、以下に述べる、ファイル、またはディレクトリ・オブジェクトの中の所定領域に収まれないファイル属性である。例えば、ＣＩＦＳの安全に関する属性などのファイル属性である。）であって、ファイル、またはディレクトリ・オブジェクトのクリエータによって作成され、これは、ファイル、またはディレクトリ・オブジェクト内にｍノード・オブジェクトのリファレンスを含んでいる。

以下にデータ構造の概要について述べる。この構造は、ディスクに記憶される位置を追跡するオブジェクト記憶サブモジュールが採用している「オーノード（ｏｎｏｄｅ）」と呼ばれているものである。データ構造の他の詳細については、後で説明する。（これらのデータ構造は、本発明の典型的な唯一の実施形態であることに留意すべきである。）
オブジェクトは、ルート・オーノード、及び随意に多数の間接、及び直接オーノードから作られている。また、チェックポイント、及び保持済みチェックポイントを制御するのに使用される、多数の他のオンディスク・オブジェクト、及び構造も存在している。それらの全てを以下に説明する。

オーノードには、ルートオーノード、直接オーノード、間接オーノードの３種類がある。（例えば、ファイル、またはディレクトリなどの）オブジェクトを作成する場合には、対応するルート・オーノードが作成される（実際は、以下に述べる通り、１対のルート・オーノードである）。各ルート・オーノードは、ディスクの所与のセクター番号に記憶され、セクター番号は、独自にルート・オーノード、及び、結果的にルート・オーノードの対応オブジェクトをも識別する。通常の実施形態においては、各セクターは５１２バイトであるので、ルート・オーノードのサイズは同じく５１２バイトに限定される。明らかになってくるように、本ファイル構造の実装の態様は、基本型Ｕｎｉｘ（登録商標）ファイル構造に類似しているが、従来のＵｎｉｘ（登録商標）システムは、間接ポンインタの固定番号のみを有している。そして、ポンインタの固定番号を用いると、ファイル・サイズの限界に達する。さらに、従来のＵｎｉｘ（登録商標）システムは、特に、ファイルにのみ、かかる記憶技術を用いており、本発明の種々の実施形態の方法におけるオブジェクト記憶モデルも採用していない。

ルート・オーノードは、実際にはペアで作成される。ルート・オーノードはセクター番号で識別されるため、それのペアの他の構成要素は、その次に高いセクター番号となる。ペアの構造は、ペアの一方のルート・オーノードが、チェックポイントに対して有効であるとともに完全となるよう使用される。ペアの他方の構成要素の対応オブジェクトが修正されると、それは次いで更新され、オブジェクトの新しい状態を反映する。普通の処理においては、ペアのオーノードの両方の構成要素が読み取られ、チェックポイント番号がより高い要素が現在のものとなる。
ファイル・システム要求の多くはディスクの使用方法を含んでいる。ブロックの関するこのような使用方法について便宜的に述べる。ブロックは、特殊なデータ記憶ユニットであり、普通の実施形態においては、規模が、２キロバイトから６４キロバイトの範囲であることが多い。

ルート・オーノード・データ構造は、識別するチェックポイント番号を含み、このチェックポイントの下で、オブジェクトの本バージョンが作成される。また、ルート・オーノードにおいて、データ構造は、ルート・オーノードがメタデータを供給しているオブジェクトの型を識別するパラメータである。オブジェクト型は、例えば、空きスペース、ファイル、またはディレクトリのいずれであってもよい。さらにオブジェクト型以外に、ルート・オーノードは、また、ブロックのオブジェクト長さのパラメータを有している。

別のルート・オーノード・パラメータは再使用カウントである。オブジェクトが削除されると、空きスペースへ戻らずに空きルート・オーノードの待ち行列に進むため、再使用カウント・パラメータが使用される。所与のルート・オーノードが新しいオブジェクトに割り当てられると、関連付けられたルート・オーノード再使用カウントは増加する。再使用カウントは、オブジェクトに関連付けられたファイル・ハンドルの一部である。ルート・オーノードが再使用される度に再使用カウントを増加させることにより、ルート・オーノードの旧バージョンで作成されるファイル処理を用いたファイル要求を識別し、排除することが可能である。

上記に提案の通り、ルート・オーノード一連のポインタを担持している。これらポインタの１つは、直前を先行するルート・オーノードのバージョンいずれかを指すポインタである。もし、保持済みチェックポイントが関連のチェックポイント期間中に取得されたことが分かった場合には、直前を先行する当のルート・オーノードのバージョンが記憶されていた可能性がある。そしてポインタは、ルート・オーノードのそのような直前のバージョンのセクター番号を識別する。

ルート・オーノードが対応する実際のデータについては、ルート・オーノードのオブジェクトと関連付けられたデータの各ブロックを指す別個のポインタがある。データブロックが１８個までの位置は、ルート・オーノードに記憶されている。１８ブロックを越えるデータについては、直接オーノードがさらに必要となる。その場合には、ルート・オーノードは、また、直接ポインタを指すポインタを有し、これはルート・オーノードの中で、ディスクのセクター番号で識別される。

ルート・オーノードのように、直接オーノードは、チェックポイント番号を識別するパラメータを含んでおり、これを基準にして直接オーノードが作成される。直接オーノードは、直接オーノードのルート・オーノードに対応するオブジェクトに関連するブロックデータ約６０、または６１個までの位置を記憶するために配置されている。

最初の直接オーノードが充分に活用されデータ・ブロックを識別すると、次に、１つ、または複数の間接オーノードが使用されて最初のオーノード、ならびに、オブジェクトに対応するデータのブロックを有する追加の直接オーノードを識別する。このような場合においては、ルート・オーノードは間接オーノードを示すポインタを有し、間接オーノードは、対応する直接オーノードを指示するポインタを有している。間接オーノードが充分に活用されると、追加の介在する間接オーノードは、必要に応じて使用される。この構造により、ファイルの断片化とは関係なく、ファイルの一部の識別が迅速にできるようになる。

直接、及びルート・オーノードの構造は、なかでも、ファイルが最初に作成される時、通常０値に設定する大きなファイルを迅速に作成することができる別の特徴を備えている。この特徴は、対応するブロックが０値を有するかどうかを識別する各ルート、及び直接オーノードの各ブロックポインタごとのフラグである。
また、大きいファイルの迅速な作成が容易になる関連の特徴もある。いずれのモードでも、ブロックまたは他のオーノードを指すポインタはいずれもブロックまたはオーノードが実際に作成されたかどうかを識別するビットを有している。関連のブロック、及びオーノードが未だ作成されていない場合には、ブロック、及びオーノードは必要に応じて作成され、書き込み要求に応じ、そして、その結果、割り当てビットが切り替わる。ブロックの作成には、空きスペース割当てサブモジュールからのスペースの割り当て、ブロックへのデータの書き込み、及び関連のオーノードのビット・フラグの設定が必要なことに留意されたい。

回復のために、現行のチェックポイントで修正されたオーノード全部のトランザクション・ログも記憶されている。さらに、修正済みルート・オーノードを全部有するディスク上でトランズアクション・ログが完全に終わるまで、ルート・オーノードは、ディスクには書き込まれない。（ルート・オーノードにはこのように書込みが遅延する特徴がある。他のオーノードにはないし、ある必要もない。何故なら、これらは、ルート・オーノードのみを経てアクセスされるからである。）現行の無効チェックポイントに関する回復モードにおいては、仮にオーノードが現行チェックポイントで修正された場合には、以前のチェックポイント値が利用される。（オーノードの内容が、トランザクション・ログと一緒にディスクに記憶されるとともに、メタデータ・キャッシュのフライに維持されることに留意されたい。）
オーノード構造もまた、オーノード構造に関するディスク書き込みをさらに減らす方法で、本実施例で確立されている。結局、オーノード構造は、ファイル内容のみならず、ファイル属性の記憶装置も収容しなければならない。ファイルの属性は、ファイル規模、ファイル作成時間、及び期日、ファイル修正時間、及び期日、読出し専用状況、アクセス許可、その他を含む多様なパラメータを含んでいる。この関係は、ルート・オーノードは未だディスクに書き込まれていないため、ルート・オーノードの内容変更は所与のチェックポイントで頻繁に行われるという事実を利用している。（ルート・オーノードのディスク書き込みは遅延するということを思い起こすだろう。）従って、ルート・オーノードの一部は、ファイルの属性を記憶するために保存される。

より一般的に、ファイルの属性の記憶装置用の以下の構造を定義する。即ち、
イーノード（ｅｎｏｄｅ）（更新用の小さなオバーヘッド、容量限定的）。本構造は、ルート・オーノードで定義され、１２８バイトである。

アイノード（ｉｎｏｄｅ）（更新用の中程度のオバーヘッド、イーノードよりも大きい容量を備える）。このアイノードは、ファイルまたはディレクトリを表す第１のｎバイト（通常は、０〜６４キロバイト）のオブジェクトである。（そして、従って、オブジェクト用のルート・オーノードが示す場所にあるディスクに記憶されている。）このアイノードは、安全の記述子として、ＣＩＦＳ目的で、このような属性情報に用いられる。

エムノード（ｍｎｏｄｅ）（高価、更新用オバーヘッド、容量は無限に近い）これは、データ記憶用専用のオブジェクトであり、従って、ディスクに自前の記憶場所を有する。オブジェクトは、イーノードで（あるいは、アイノードで）識別される。

図３の実施形態に関したオブジェクト記憶装置について、以下に、さらに詳細に説明する。

１．２ ルート・オーノード
各ルート・オーノードは、長さが５１２バイトある。以下の情報がルート・オーノードに記憶されている。
・オブジェクトの本バージョンを作成するチェックポイント番号
・オブジェクトの本バージョンのデータ長
・本オブジェクト用ランリストに使用される間接参照のレベル数
・オブジェクトの型、これは主に、オブジェクトにアクセスするために要求が届いた時に判断が正しいかどうかのチェック用として用いられる。
・本ルート・オーノードの使用頻度を伝えるための再使用カウント
・保持済みチェックポイント用に作られた旧ルート・オーノードバージョンを指すポインタ（もし、１つある場合）
・新ルート・オーノード・バージョンを指すポインタ（もし、これが、保持済みチェックポイント用に作られたコピーの場合のみに有効）
・データブロック記述子が１９個まで。各データブロック記述子は、データブロックを指すポインタ、データが作成されるチェックポイント番号、ブロックが零補充されているかどうかを伝えるビットを含む。
・直接オーノードか間接オーノードかのいずれかを指す単一ポインタ
・本オブジェクト用の１２８バイトのイーノード・データ
・巡回冗長検査ＣＲＣ、及びルート・オーノードが有効かどうかを調べられる各種判断の倍長語
所与オブジェクトについては、ルート・オーノードの現行の有効バージョンを記憶できる場所が２箇所ある。これらの場所は、（ｏｂｊ＿ｎｕｍ＊５１２）または（（ｏｂｊ＿ｎｕｍ＊５１２）＋５１２）のいずれかのボリュームにオフセットされたビットの所にある。いずれが最も最新かを探すため、双方とも読み取る必要がある。全ての認証検査に合格するだけでなく、後の作成チェックポイント番号をも有するものが最新の有効バージョンである。

以下の第４節で述べるように、オブジェクトは、チェックポイントを取得する度に作成されるルート・オーノードのコピーを含んでもよい。旧ルート・オーノードを指すポインタ、及び新ルート・オーノードを指すポインタにより、保持済みチェックポイント用に作成された現行のルート・オーノード、及びルート・オーノードのコピーのいずれも含む、双方に好まれるルート・オーノードのリスト作成が可能である。双方に好まれるリストにより保持済みチェックポイントの作成、及び削除が容易となる。

１．３ 間接オーノード
間接オーノードは、ルート・オーノードと直接オーノードとの間の間接参照レベルを提供するものである。各間接オーノードは、長さが１キロバイトである。間接オノード１対を、最小のディスク・ブロック・サイズ、２キロバイトを有するディスク・ブロックにパック可能であるが、各間接オーノードは、通常、簡易化のために別個のディスク・ブロックに記憶されている。

間接オーノードには、次の情報が記憶されている。
・間接オーノード作成チェックポイント番号
・間接または直接オーノードのいずれかを示す１２２までのポインタ
・巡回冗長検査ＣＲＣ、及び間接オーノードが有効かどうかを調べられる各種判断の倍長語
ルート・オーノードと同様に、現行の有効間接オーノードは、間接オーノードの一番最新のバージョンを含むペアの間接オーノードの１つと一緒に、ペアで保持される。しかしながら、ルート・オーノードと違って、現行の有効な間接オーノードは、直接現行ルート・オーノードから示されているので、どちらが一番最新かを知るために間接オーノードの双方を読み取る必要はない。

１．４ 直接オーノード
直接オーノードはディスクのデータ・ブロックを指す直接ポインタを付与する。各間接オーノードは長さが１キロバイトであり、このことは直接オーノードのペアは現行の最小データ・ブロック・サイズの２キロバイトに適合することを意味する。

直接オーノードには、次の情報が記憶されている。
・直接オーノード作成チェックポイント番号
・データブロック記述子が６２個まで。各データ・ブロック記述子は、データブロックを指すポインタ、及びデータを作成するチェックポイント番号、及びブロックが零補充されているかどうか伝えるビットを含む。
・巡回冗長検査ＣＲＣ、及び間接オーノードが有効かどうかを調べられる各種判断の倍長語。

１．５ 動的スーパーブロック
ディスク上では２つの動的スーパーブロックがあり、それらの１つだけを、任意の時点における最も最新と見なす。これらは、ディスクのチェックポイントの状態を記録するのに用いる。

各動的スーパーブロックには、次の情報が記憶されている。
・動的スーパーブロックと関連付けられたチェックポイント番号
・本チェックポイント用修正済みチェックポイント・オブジェクト・リスト・オブジェクトの処理
・最後に保持したチェックポイントからの修正済み保持オブジェクト・リスト・オブジェクトのオブジェクト番号
・本チェックポイントの状態。状態として、ＷＲＩＴＴＥＮ＿ＯＢＪ＿ＬＩＳＴ、及びＣＨＥＣＫＰＯＩＮＴ＿ＣＲＥＡＴＥＤ が予想される。
・巡回冗長検査ＣＲＣ、及び間接オーノードが有効かどうかを調べられる各種判断の倍長語
連続するチェックポイントは、使用する動的スーパーブロックのチェックポイントの間で交互に繰り返している。ソフトウェアがボリュームを開くと、ソフトウェアは、動的スーパーブロックの両方を読み取る必要がある。ＣＨＥＣＫＰＯＩＮＴ＿ＣＲＥＡＴＥＤと印されたボリューム状態を有し、判断が正しいかどうかの全てチェックに合格した最後のチェックポイント番号の付いている一方が、本ボリュームの最後の有効なチェックポイントを識別する。ＯＢＪ＿ＳＴＯＲＥ ＯＰＥＮ＿ＶＯＬＵＭＥコールは、オブジェクト記憶サブモジュールが、どちらの動的スーパーブロックを初めに使用すべきかを識別する。これは、最も最新のチェックポイントを特定しなかった方となる。

１．６ 修正済みチェックポイント・オブジェクト・リスト・オブジェクト
各チェックポイントの開始において、修正済みチェックポイント・オブジェクト・リスト・オブジェクトが作成される。このチェックポイントの一部として異なるオブジェクトが作成され、修正される度に、そのオブジェクト番号は、修正済みチェックポイント・オブジェクト・リスト・オブジェクトに書き込まれるため、チェックポイントが作成された時には、そのチェックポイントで作成された、または修正されたオブジェクトを全てリストにしたオブジェクトが存在する。

１．７ 修正済み保持オブジェクト・リスト・オブジェクト
各保持済みチェックポイントの開始において、修正済み保持オブジェクト・リスト・オブジェクトが作成される。保持済みチェックポイントが作成された後で異なるオブジェクトが作成され、または修正される度に、並びに次の保持済みチェックポイントが取得されるまで、そのオブジェクト番号は修正済み保持オブジェクト・リスト・オブジェクトに書き込まれる。

２．オブジェクト動作の基本
２．１ オブジェクト作成、及び削除
オブジェクトが（ＷＦＳ ＡＰＩ ＯＢＪ＿ＣＲＥＡＴＥ ｃａｌｌを用いて）初めて作成される場合、オブジェクトは、間接オーノード、直接オーノード、またはデータ・ブロックのいずれかを指すポインタがないルート・オーノード（実際は、ルート・オーノードのペア）しか持っていない。

１つだけ留意すべきことは、一旦、ディスク・ブロックがルート・オーノードとして割り当てられると、そのディスク・ブロックは、他のどれにも絶対に用いてはならないことである。何故ならば、ルート・オーノードに対して戻された処理は、ルート・オーノードのディスク上でセクター・オフセットであるオブジェクト番号を含むからである。もしも、オブジェクトが削除され、次いで、クライアントが処理をキャッシュに入れたままで、ファイル用の別の要求を携えて入って来た場合、オブジェクトの記憶が出て行って、オブジェクト番号で指定される位置でディスクのデータを読み取ることになる。もしも、ディスク・ブロックが再使用されていたとしたら、ディスク・ブロックは、あらゆる種類の問題を引き起こすルート・オーノード（または、実際に新しいルート・オーノードである）になると思われる。

この問題を乗り越えるために、次の３項目を行う。

１． 仮にクライアントが再びそのオブジェクトを読み取ろうとしても、オブジェクト記憶にはオブジェクトは削除されていることが分かるよう、ルート・オーノードが削除された場合には、そのオブジェクト型をディスクの上にＯＢＪ＿ＴＹＰＥ＿ＤＥＬＥＴＥＤとして設定する。

２． オブジェクトが削除される時には、オブジェクトのルート・オーノードが使用しているディスク・スペースを空きスペース割り当て制御装置へ戻さない。代わりに、削除されたルート・オーノードは空きルート・オーノードのリンク・リストに保持する。（データ・ブロックと違って、ルート・オーノードがペアで配置されているため、これらの空きになったデータブロックを、チェックポイントが取得される前に、再利用するのが安全であることを留意されたい。）オブジェクトが作成された時には、空きルート・オーノードは、それが利用できれば使用する。空きルート・オーノードが利用できない場合に限り、ルート・オーノードの新ディスク・スペースが割り当てられる。

３． ルート・オーノードが最初新しく割り当てられた空きスペースで作成された場合には、ルート・オーノードには零の再利用カウントを与える。ルート・オーノードが新しいオブジェクト用に再利用される度に、再利用カウントは増加する。再利用カウントはクライアントへ戻す処理の一部を成している。このことは、再利用されたルート・オーノードを参照した以前の処理は、再利用カウントが間違っているため、無効として削除されることを意味している。

２．２ オブジェクト・データ作成
データが作成される時に、そのデータは初めに、ルート・オーノードから直接示されたデータ・ブロックに入れられる。これは、図７の線図に示してある。他のオーノードがないルート・オーノードの用法を示す。この線図、及び以下の全ての線図において、簡略化のために、ルート・オーノード、及び直接オーノードはデータ・ポインタ２個のみで示され、また、間接オーノードは間接オーノード・ポインタ、または直接オーノード・ポインタ２個のみで示されていることに留意されたい。

一旦、直接ブロック・ポインタの全部が満たされると、次に、直接オーノードＡが、ルート・オーノードから直接オーノードへのポインタによって作成される。図８は、この直接オーノードＡを有するルート・オーノードを使用した模様を示している。ルート・オーノードは、直接、または間接のオーノードのいずれかを指す１本だけのポインタを除き、多数のデータ・ブロックを有していることに留意されたい。

もし、オブジェクトの中のデータが次第に直接オーノードの中のデータ・ポインタの全てを満たすようになってくると、図９に示すように間接オーノードＢが作成される。図９はこの間接オーノード、及び直接オーノードを有するルート・オーノードを使用した模様を示している。直接オーノードＡを指していたルート・オーノードの中のポインタは変更されて、間接オーノードＢを指し、そして、間接オーノードＢの最初のポインタは直接オーノードＡを指すよう設定される。同時に新しいオーノードＣが作成されて、これも、間接オーノードＢから指される。データが多く作成されるに従い、直接オーノードも多く作成され、それらの全ては、間接オーノードから指される。

一度、間接オーノードＢの直接オーノード・ポインタの全てが使用されると、別のオーノードＤが作成され、これはルート・オーノードと最初の間接オーノードＢの間に挿入される。他の間接オーノードＥ、及び直接オーノードＦも、作成されて、より多くのデータ・ブロックが参照できるようになる。これらの状況は図１０に示してあり、ここではルート・オーノードと直接オーノードの間に置かれた多数の間接オーノード層の用法を図示している。

直接オーノード、及び間接オーノードを追加することにより、さらに多くのレベルの間接参照を作成するこの方法は、繰り返されて、オブジェクトが含む大量のデータを収容する。

オブジェクトのアイノード部分は、オブジェクトのデータ部分と同様、オブジェクト記憶サブモジュールによって処理されるということに留意すべきである。オブジェクト記憶サブモジュールは、アイノード部分とアイノード部分を区別せず、アイノード部分に自動的な割当も行わない。逆に、データがオブジェクトに追加されるので、オブジェクトを作成、または修正する構成要素（通常は、ファイル・システム・ファイル・サブモジュール、またはファイル・システム・ディレクトリサブモジュールなどのオブジェクト記憶サブモジュールより上流にあるサブモジュール）が、アイノードにどれだけのスペースを残すかを判断しなければならない。

２．３ オブジェクト・データ削除
データをオブジェクト、及びデータ・ブロックから削除され、直接オーノード、及び間接オーノードはもはや不要となるので、空きスペース割り当て制御装置へ戻される。

一実施形態によれば、オブジェクトが減少するに従い、残りの全ての直接オーノード、及び間接オーノードが空いてくる、ルート・オーノードの直接ブロックポインタを経由して、オブジェクトの全てのデータを参照できるまでの間接参照のレベル数、及び間接参照のレベルは零に設定される。

２．４ 零の補充
もし、ファイルへの書き込みがなされ、これが、現行のファイルの終端を超えてスタート・オフセットを有している場合には、新しい書込みデータの現行終端と開始との間のファイルの不定部分は零で埋める必要がある。オブジェクトの長さが現行の長さより長く設定されている場合も同じことが起こる。

これは、もしファイルが作成され、長さが、例えば、１ギガバイトに、設定された場合には、特に問題となる。直接実装の場合、これには、ファイルに割り当てられたディスク・ブロックは実際に零で書き込む必要がある。１ギガバイトのファイルの場合、１０秒程度掛かると思われる。１テラバイトでは、３時間程度掛かる。

本発明の実施形態では、この問題は、そのブロックが零補充されたかどうかを伝える各データ・ブロック・ポインタを備えたビットを有することで、避けられる。もしも、オブジェクト記憶サブモジュールがこのビットが設定されるのを確認しておれば、オブジェクト記憶サブモジュールは、ディスク上では、このブロックが全く違うものを含んでいるかも知れないが、このブロックを零で補充すべきことを認識している。もし、ブロックが読み取られている場合には、オブジェクト記憶サブモジュールは、それのディスクに書き込まれる内容ではなく、このブロック用の零を戻す。もし、ブロックが、ブロック全体を補充しない書き込みで、書き込まれる場合には、オブジェクト記憶サブモジュールは先ず零を、いま書き込まれていないブロック全部に書き込み、このブロック用の零を補充されたビットをリセットする。

この場合には、ディスク・ブロックは零で補充されていないが、ディスク・ブロックはファイルの零を補充された部分の全てに対して割り当てられる。

２．５ スパース・オーノード構造
一旦、零の補充問題が解決すれば、ある非常に大きな値へのオブジェクトの長さ設定に関する次の問題は、データ・ブロックを割り当て、及び必要な直接オーノード構造、及び間接オーノード構造の作成に掛かる時間である。ディスク・ブロック・サイズが４キロバイトの場合で、１テラバイトのオブジェクトには、ほぼ４百万の直接オーノード、ならびに、これより少ない間接オーノードが必要になる。ディスクへの書き込みには、約４０秒掛かると思われる。また必要なデータ・ブロック全部の空きスペース割り当て、及び空きスペース・ビットマップの次の更新がこの時間に大きく加わる。もし、チェックポイントがファイル作成が始まった直後に取得されるのであれば、システム全体は、この全時間中、（どのボリュームに対しても）要求に応じられなくなる。

本発明の実施の形態においては、２つの面を有する方法によって解決する。解決策の第１の態様は、ファイルの零の補充部分のディスク・ブロックを実際に割り当てないことである。このことは、オブジェクト記憶が、零の補充ブロックへの書き込みを確認する時に、オブジェクト記憶は最初に、ディスク・スペースをそのブロックに割り当て、及びディスク・スペースを指すポインタを関連のオーノード構造に置かなければならない。

第２の態様は、第１の態様の上の設ける。即ち、データ・ブロックを割り当てないことに以外に、オーノード構造も作成しない。この態様を実施するため、各オーノード・ポインタは、それが指すオーノードが割り当てられたかどうかを伝えるビットを有する。もし、有していなければ、オペレーションが生じ，これにより、オーノードが有効であることが求められ、この時に限り、オーノードに対してディスク・スペースが割り当てられて、正確なポインタが挿入される。このように、巨大な零補充オブジェクトは、ルート・オーノードのみを有することになり、明らかに、非常に迅速に作成できる。

３．チェックポイント
３．１ ファイル・システム整合性概論
ファイル・システムの基本的特徴の１つに、システム故障時のファイル・システム整合性を維持する能力がある。

本書のファイル・システムの実施形態に関しては、チェックポイント機構が用いられているが、これが従来の実施形態とは異なった実装により、ファイル・システム整合性を維持している。メタデータをディスクの新しい領域に、常に書き込むのではなくて、代表的な従来のシステム同様に、ある任意のオーノード・メタデータ２コピーを維持して、これの一方のコピーは有効であり、他方は更新中とすることができる。仮に、一方のコピーが更新中にシステムが故障した場合には、システムは、他のコピーに復帰できるため、有効であると保障される。ユーザ・データについては、システムは、ユーザによりトリガーされたファイル・システム・データ構造セーブの整合性、または高い性能、及びファイルの非断片化を与えるために、それをディスクの新しい領域に常に書き込むのか、または、既存データに上書きするのかの選択を、オブジェクト・本位で、有することできる。これに関することは全て、次節で詳細に述べる。

３．２ ユーザ・データ処理
ユーザ・データの処理はメタデータの処理法に影響するので、先ず、ユーザ・データの処理について考察する。

オブジェクトのルート・オーノード、間接オーノード、または直接オーノードに含まれないものの意味を、先ず、「ユーザ・データ」で定義することが大切である。オブジェクト記憶へ入れられるユーザ・データは、本書の実施形態のファイル・システムの別の部分へ入れる（ディレクトリ・リストや空きスペース・ビットマップなどの）メタデータであってもよいお。このようなデータの場合、例え、ＮＶＲＭの内容が喪失していたとしても、ディスクに書き込まれるファイル・システムが常に整合性があることを確実にするために、チェックポイントにおけるディスクのデータが整合性があるのか確認することが重要である。

ルート・オーノードは、遅延書き込みコマンドを用いて、常に記憶モジュールに書き込まれる。遅延書き込みコマンドには、タグ番号が付けられ、コマンドに関連つけられたデータは、タグ・フラッシュが正確なタグ番号で行われるまで、ディスクには書き込まれない。本処理が行われる理由を説明したオーノード処理についての節を参照されたい。これに関しての１つの問題は、記憶モジュールのセクター・キャッシュは、それがシステム全体をロックするため、汚損したルート・オーノードで絶対に満たされていないことを保証する必要がることである。他のオーノード構造、及びオーノード・データについては、ルート・オーノードに用いられたものに付けられた異なるタグ番号で、普通のタグ付き書き込みが使用できる。これによって、記憶モジュールに、ディスクにそれらを書き込む前にタグ・フラッシュを待つ必要がなくなるオプションを与えると共に、セクター・キャッシュが満たされる危険性が低下する。

オーノード・ユーザ・データは、多くの異なる方法で処理できる。２つのデータ処理モード、即ち、データ・コピー・モード、及びデータ上書きモード、ならびに任意の第３のデータ処理モード、即ち、データ・ペア・モードであるが、これらについて以下に述べる。データ処理モードは、オブジェクト本位で選択が可能である。

データ・コピー・モード
本モードを用いたオブジェクトは、オブジェクト用チェックポイント化メタデータ、及び、ユーザ・データの両方が整合性があることを保証する。本モードを、実際にはシステムの他のブロックのメタデータであるユーザ・データに使用すべきである。

データ・コピー・モードにおいては、以前のチェックポイント番号で書き込まれたデータ・ブロックに書き込む時に、以下のことが行われる。

新しいデータ・ブロックを割り当てる。

旧ブロックの内容を新しいブロックにコピーする。（新しいデータがブロック全体を満たしておれば、必要ない。

新データを新ブロックに書き込む。

新ブロックを指すオーノード・データ・ポインタを更新する。

旧ブロックを空きスペース割当て制御装置に戻す。

最後の手順は、ここで、旧ブロックは未だ、以前のチェックポイントであるので、少し変わった手順であってもよい。もし、次に、空きスペース割り当てサブモジュールが、空きスペース要求に応答して、再びデータ・ブロックを使い切ってしまうならば、チェックポイント化されたデータはその時、上書きされるので、問題が起こることになる。しかしながら、空きスペース割り当てサブモジュールに対する要求事項の１つは、空きスペースとして、制御装置へ戻されるデータ・ブロックは、チェックポイントが取得された後では、決して再びなくなってはならないことである。このことによって、最後の手順は安全となる。

データ・上書きモード
本モードを用いたオブジェクトは、チェックポイント化されたメタデータが、整合性はあるが、必ずしもチェックポイント化されたユーザ・データではないことを保証する。本モードは、真実のユーザ・データ（即ち、ファイル内容）である全てのデータに用いることができる。

データ・上書きモードにおいては、以前のチェックポイント番号で、事前に書き込まれたデータ・ブロックに書き込む時に、以下のことが行われる。

新データを旧データ・ブロックに書き込む。

上書きモードにおいては、システムが故障し、ＮＶＲＡＭの内容が喪失された場合にデータ整合性の問題のみがあることに留意されたい。ＮＶＲＡＭが機能している限り、ユーザ・データは、ＮＶＲＡＭの内容を再生することにより、整合性のある状態に置ける。以上のこを下の表に要約する。

データ・ペア・モード
空きスペースオブジェクトなどのオブジェクトを考慮すると、オブジェクトはファイル・システム・メタデータを含んでいるので、データ・コピー・モードを使用する必要がある。しかしながら、本モードにおいては、オブジェクトは絶えず更新されているため、細かく断片化されそうである。

この種のオブジェクトについては、モードが含まれ、それにより、あらゆるデータブロックは、オーノード構造と同様の方法でペアを有している。このことによって、データがチェックポイント化されるので、ぺアの中のブロック間で交換が可能となる。これを行うことにより、ファイル断片化の問題を軽減化し、同時に、全ての割り当てを処理する空きスペース割り当てサブモジュール、及びオブジェクトが修正されるためブロックの開放が要らなくなる。

空きスペースオブジェクトは、普通のオペレーションでは絶対にサイズを変えないため、この種の処理に特に役に立っている。

３．３ オーノード処理
既に述べた通り、あらゆるオーノード構造（ルート・オーノード、間接オーノード、直接オーノード）は実際は、ペア構造で出来ている。他に適当な名前がないため、個々の構造は、ペアの左側（ＬＨＳ）、及びペアの右側（ＲＨＳ）と称す。

先ずは、図１１チェックポイントＡのルート・オーノードの作成について、考察してみよう。これが先ず作成される場合には、ルート・オーノードをペアのＬＨＳに書き込む。ルート・オーノードは記憶モジュール内では有効であるが、遅延書き込みを用いて書き込まれているため、チェックポイントが作成されるまでディスクに書き込まれないことに留意されたい。
チェックポイントＡが作成される前に起こるルート・オーノードへの全ての変化（例えば、オブジェクトへの書き込み、オブジェクトの削除、同じルート・オーノードを用いた新しいオブジェクト作成など）は、ＬＨＳルート・オーノードの上で起こる。

チェックポイントＡが作成される時には、タグ付のフラッシュが発出されることによりＬＨＳがディスクに書き込まれる。もし、チェックポイントが取得されている間に、（チェックポイントＢに反映する）さらに多くの修正がルート・オーノードに対して行われた場合には、これらの修正は、図１２に示す、ルート・オーノードのＲＨＳに書き込まれる。

一旦、チェックポイントＡが作成されると、ルート・オーノードはディスクに書き込まれ、ルート・オーノード・ペアは図１３に示す態様を有するようになる。

システムがチェックポイントＢの作成を始めると仮定してみよう。チェックポイントＢのタグ付きのフラッシュが発出されると、ルート・オーノードは図１４に示す態様を有するようになる。

チェックポイントＢ用のルート・オーノードのＲＨＳが未だディスクに書き込まれている間に、オブジェクトがチェックポイントＣの一部として再度修正されたと、もう１度仮定してみよう。チェックポイントＢが未だ作成されていないため、ディスクのルート・オーノードのＬＨＳバージョンは、依然として最新の有効なチェックポイントＡを含んでいる。従って、ＬＨＳを更新するために遅延書き込みが用いられるが、チェックポイントＣが作成されるまでは、ＬＨＳへの変更のいずれも、ディスクに書き込まれないようにしなければならない。チェックポイントＢが作成されている間の状況は図１５に示している。

一旦、チェックポイントＢが作成されると、システムはディスクにチェックポイントＣのＬＨＳルート・オーノードを書き込み始められるように思えるかもしれない。このことは、直接オーノード、及び間接オーノードにも成り立つが、ルート・オーノードについては当て嵌まらない。その理由は、もし、システムがチェックポイントＣが作成される前に故障したとして、しかしながら、その時までに、ルート・オーノードのＬＨＳがディスクに書き込まれており、次に、オブジェクト記憶がルート・オーノードのペアを読み取りに来て、どちらが最新の有効なものかを探し出したとすれば、システムは、チェックポイントＣに関連付けられたＬＨＳルート・オーノードが最も最新であると考えるだろう。これは間違いである。このため、任意のルート・オーノードがディスクに書き込まれる前に、どのルート・オーノードが修正されるのかを伝えるために、修正済みチェックポイント化オブジェクト・リストは、書き込まれる。これによって、システムは、ルート・オーノードを更新している間に故障から回復することができる。この件は、チェックポイント回復の関する節でさらに説明する。

さて、以下の全ての線図を簡略化するため、チェックポイントの作成途中の当面の状況は省略する。

システムが、図１６に示すようなルート・オーノードで始動したと想像してみよう。

ルート・オーノードが今、２つのレベルの間接参照があるように延びていると仮定する。チェックポイントを取得する前に、構造は図１７の態様を有している。直接オーノード、及び間接オーノードは、以前のチェックポイントが完全に作成される前に遅延書込みで全て書き込まれ、一旦以前のチェックポイントがディスク上で有効になると、タグ付き書込みで全て書き込まれていることに留意されたい。データは全てタグ付の書き込みで書き込まれている。

もし、次に、チェックポイントが取得されると、構造は図１８に示す態様を取る。

さて、データ・ブロック２への書き込みが、データ・コピー・モードのオブジェクトで行われたと仮定する。この場合、新しいデータ・ブロック２が割り当てられ、オーノード構造の全てが更新されこの新ブロックを指す。チェックポイントの前の構造は、図１９に示すような態様である。チェックポイント化データはオリジナルとして保存され、オリジナル・データ・ブロック２は修正されないことに留意されたい。

チェックポイント後、構造は図２０に示すような態様となる。

さてここで、この新しい構造について、データ・ブロック１がデータ・上書きモードのオブジェクトで上書きされたと仮定してみよう。この場合、イーノード構造の他のものは変化していないので、（新オーノードを有する）ルート・オーノードだけが更新される。ブロック０のチェックポイント化バージョンは修正済みであるので、本モードでは、チェックポイント化されたデータは破損している。以上の動作結果は、図２１に示す。
３．４ 記憶モジュール・タグ番号
チェックポイント・プロセス期間中、多くの異なる記憶モジュール・タグ番号が使用されている。タグ番号の詳細は下表に示す。

所与の３２キロバイトの記憶モジュール・セクター・キャッシュ・ブロックは、１つの遅延書込みタグ待ち行列、及び１つの非遅延書込みタグ待ち行列の中でのみに存在可能である。従って、同じブロックが異なるタグ番号で書き込まれた場合にどのようになるかという問題が発生する。

動的スーパーブロックは、この３２キロバイトのセクター・キャッシュ・ブロックの中で、これが唯一であるよう配列される。即ち、このことは、それが存在するセクター・キャッシュ・ブロックは、異なるタグ番号では、絶対に書き込み不可能であるということを意味している。

ある一定のバッファに関しては、同一チェックポイント番号用のルート・オーノード遅延書込み、ならびに直接及び間接オーノード遅延書込みの双方が存在する場合には、ルート・オーノード遅延書込みタグ待ち行列で終わる必要がある。

２つの遅延書込み問合せに関しては、チェックポイントＮ＋１の遅延書き込みを開始する時には、チェックポイントＮからの遅延書込みタグを持ったどのようなバッファも決して存在しないよう、チェックポイントを、その時点で、構成する。もし、それぞれに対する別の汚損したブロック・ビットマップを持った２つの遅延書込みタグ・待ち行列の中にキャッシュ・ブロックが存在する場合には、以前のチェックポイントの遅延書き込みタグ付きフラッシュが発出される前に、システムは、次のチェックポイントの遅延書き込みを開始する。これについては、以下のチェックポイント取得の節において、さらに詳細に述べる。

残り２つのタグ付き書込み構造については、チェックポイントをその時点で構成するようにシステムがチェックポイントＮ＋１のタグ付き書き込みを開始する際にはチェックポイントＮからの記憶モジュールの中にどのようなタグ付きバッファも絶対にないことである。もし、キャッシュ・ブロックに割り当てられたタグ番号を有したキャッシュ・ブロックがチェックポイントの中に書き込まれている場合には、修正済みチェックポイント・オブジェクト・リスト・タグ待ち行列でブロックが終わるかを確認する必要がある。もし、時間を短縮のために、以下に提案する性能改善が行われるならば、システムチェックポイントを取得している間に新しい要求を処理することが不可能となり、この確認はさらに複雑になる。

３．５ チェックポイント取得 − 簡易版
ファイル・システム・ソフトウェアにチェックポイント取得に必要な種々の理由がある。
・本チェックポイントに使用されるＮＶＲＡＭの半分が一杯になってきている。
・記憶モジュール上のセクター・キャッシュが一杯になってきている。
・前回チェックポイントが取得されてから、所定の時間（通常１０秒）が経っている。
・保持済みチェックポイントを取得する旨ユーザから要求があった。

チェックポイントを取得することが必要であったり、望ましい、または便利な時が、他にもあると思われる。

システム・レベルにおいて、チェックポイントの取得には、マウントされる各ボリュームについて、以下のオペレーションが含まれる。

１．ファイル・システムが整合状態となるようシステムの全オペレーションを停止する。

２．記憶モジュールの修正済みチェックポイント・オブジェクト・リスト・オブジェクトのタグ・フラッシュを行う。

３．修正済みチェックポイント・オブジェクト・リスト・オブジェクトが書き込まれたことを伝えるため、チェックポイント・動的スーパーブロックを更新する。

４．記憶モジュールのオーノード構造、及びオーノードデータのタグ・フラッシュを行う。

５．チェックポイントが今作成されたことを伝えるため動的スーパーブロックを更新する。

手順４が始まると直ぐに、システムは新しい問合せに応じ始める。

３．６ チェックポイント取得 - 詳細説明
チェックポイントを取得するために必要な実際のオペレーションについて以下に述べる。これらのことは図２２に、要約してある。オペレーションは単一ボリュームのみをマウントした場合を仮定して説明してある。（もし、その時に、多数のボリュームあれば、各手順のオペレーションはマウントされたボリュームごとに繰り返される。）
１．ファイル・システム・ソフトウェアは、それがオペレーション一式を不揮発性記憶装置処理サブモジュールに入れるまで待つ。これが完了すると、不揮発性記憶装置処理サブモジュールから整合性の在るファイル・システムが得られる。

２．次に、本ソフトウェアは、ＷＦＳ＿ＣＲＥＡＴＥ＿ＣＨＥＣＫＰＯＩＮＴの問合せを不揮発性記憶装置処理サブモジュールへ入れる。本コマンドは、次のチェックポイントの作成に使用されるチェックポイント番号を含んでいる。

３．不揮発性記憶装置処理サブモジュールは、チェックポイント問合せの前の全部のコマンドがファイル・システム・ファイル・サブモジュール、及びこれのクラスター・ぺア・マシン（１つしかない場合）の双方が入れられるまで待ち、自前のＮＶＲＡＭにこれらのコマンドを全て記憶する。

４．不揮発性記憶装置処理サブモジュールは、ソースとして不揮発性記憶装置処理サブモジュール、及び宛先としてファイル・システム・ファイル・サブモジュールを有する新しいチェックポイント・コマンドを生成する。不揮発性記憶装置処理サブモジュールは、次に、プロセッサからの多くの要求の処理が始められる。これらは、ＮＶＲＡＭの残りの半分に今記憶される。そして、これらの要求をファイル・システム・ファイル・サブモジュールに渡し始めることができる。
５．ファイル・システム・ファイル・サブモジュールは、チェックポイント問合せの前のコマンドの全てが完了するまで待つ。これが起きるまで、不揮発性記憶装置処理サブモジュールからの新しいコマンドのどのようなものであれ処理し始めることはできない。これは、最長の遅延が起きそうな全チェックポイント・オペレーションの中のポイントであることに留意されたい。現在の我々の予測では、ビジーなファイル・システムで、このオペレーションは、数１０ミリ秒掛かっている。これを軽減する別の方法により、ファイル・システム・ファイル・サブモジュールは、完了すべき未処理のオペレーションを待つ間ディスクのどのような修正も行わないオペレーションを続けることができる。

６．ファイル・システム・ファイル・サブモジュールは、次いで、ソースとしてファイル・システム・ファイル・サブモジュール、及び宛先としてファイル・システム・ディレクトリ・サブモジュールを有する新しいチェックポイント問合せを生成する。この時点で、ファイル・システム・ファイル・サブモジュールは不揮発性記憶装置処理サブモジュールからの新しいコマンドを処理し始めることができる。

７．次に、手順５、及び手順６は、ファイル・システム・ディレクトリ・サブモジュール、及びファイル・システム・ツリー・サブモジュールのために繰り返される。これらのそれぞれについて、手順５の待ち時間は未処理のオペレーションがないことを保証すべきであるので、完了すべき未処理のオペレーションを待つ必要はないことに留意されたい。

８．オブジェクト記憶サブモジュールがファイル・システム・ツリー・サブモジュールからチェックポイント・コマンドを受け取ると、オブジェクト記憶サブモジュールは、空きスペース割当てサブモジュールに作成チェックポイント問合せを送る。この時、オブジェクト記憶サブモジュールはまた、ファイル・システム・ツリー・サブモジュールインターフェイスからのどのような新しい問合せの処理も停止する
９．空きスペース割当てサブモジュールは、未処理の空きスペース問合せを完了し、適切なビットマップを更新すると、チェックポイント応答を返送する。空きスペース割当てサブモジュールが、オブジェクト記憶サブモジュールに送っているオブジェクト問合せは、オブジェクト記憶サブモジュールにより生成されているより多くの空きスペース問合せとなる恐れがあるので、チェックポイント応答を返送を待っている間、オブジェクト記憶サブモジュールは新しい空きスペースを処理し（、及び完了すべきこれらを待ち）続けなければないことに留意されたい。チェックポイント応答を送る前に、空きスペース問合せを処理すること、及び完了すべきスペース問合せを待つことによって起きる「無限ループ」を防ぐまたは逃れる対策を立てる必要がある。

１０．オブジェクト記憶サブモジュールが、空きスペース割当てサブモジュールからチェックポイント応答を受け取ると、オブジェクト記憶サブモジュールは、記憶モジュールにタグ付きフラッシュを送り、記憶モジュールが、このボリューム用の修正済みチェックポイント・オブジェクト・リスト・オブジェクトを一気に消去するよう伝える。修正済みチェックポイント・オブジェクト・リストは、ある一定のボリュームの現行チェックポイント中に修正されたオブジェクト全部のオブジェクト番号を記録したオブジェクトである。

１１．修正済みチェックポイント・オブジェクト・リスト・オブジェクトのＴＡＧ＿ＦＬＵＳＨが完了すると、オブジェクト記憶サブモジュールは、ＷＲＩＴＥ＿ＯＢＪ＿ＬＩＳ、及び修正済みチェックポイント・オブジェクト・リスト・オブジェクトの処理に設定された状態で、このチェックポイント番号用の動的スーパーブロックに書き込む。これは、ディスクを経由し、タグ付き書き込みを用い、続いてタグ付きフラッシュにより、書き込む必要がある。これは、チェックポイントをより迅速に書き込むため（これは動的スーパーブロックを書き込む時間が長くなる可能性があるが）に行われるので、直接、及び間接オーノード、ならびに、オーノード・データのフラッシュは同時に行うことに留意されたい。

１２．動的スーパーブロックがディスクに書き込まると、タグ付きフラッシュはルート・オーノードの全部（また、もし、これが以前に行われていなければ、直接、及び間接オーノードに対して）に発出可能である。

１３．タグ付きフラッシュが発出されると同時に、オブジェクト記憶サブモジュールは次のチェックポイントの作業を始める。このことは、現行のチェックポイント番号を、チェックポイント問合せで指示されるものに更新し、正確なタグ番号を、新しいチェックポイントの全ての構造に使用することに変換し、ファイル・システム・ツリー・サブモジュールからの問合せを処理し始めることを意味している。あるいは、もし、３２キロバイトのキャッシュ・ブロックを（それぞれに対し別々の汚損したブロック・マスクの付いた）２つの遅延書込みタグ待ち行列の中に置けるように記憶モジュール・キャッシュ制御装置を変更した場合、手順１０でタグ・フラッシュが発出されると同時に、次のチェックポイントの作業を始めることが可能となる。これによって、手順１０、及び手順１２の間での大幅な遅延にがあるため、性能が改善する。

１４．オーノードデータ、及びオーノード構造の２つのタグ付きフラッシュが完了すると、オブジェクト記憶サブモジュールは、ＷＲＩＴＴＥＮ＿ＣＨＥＣＫＰＯＩＮに設定された状態で、このチェックポイント番号用の動的スーパーブロックに書き込む。これは、タグ付き書き込みを用いて、次にタグ付きフラッシュによりディスクに書き込む必要がある。

１５．動的スーパーブロックがディスクに書き込まれると、チェックポイントは首尾よく作成される。オブジェクト記憶サブモジュールが、ファイル・システム・ツリー・サブモジュールへ、チェックポイント回答を送る。これがファイル・システム・ディレクトリ・サブモジュール、及びファイル・システム・ファイル・サブモジュールを経由して不揮発性記憶装置処理サブモジュールへ戻るチェックポイント応答となる。これが、チェックポイント応答を確認した時、このチェックポイントと関連付けされたＮＶＲＡＭのセーブ済みデータ全てを処分する。

１６．不揮発性記憶装置処理サブモジュールは、次に、プロセッサに応答する。プロセッサがチェックポイントの応答を確認したときに限り、プロセッサは別のチェックポイントの生成を要求する。

３．７ チェックポイントの復元
ボリュームをマウントすると、システムは普通、最後の有効チェックポイントへ戻ることを希望する。
これを解決するには、ソフトウェアが動的スーパーブロックの双方を読み取る必要がある。これらの双方とも有効でなければならない。オブジェクト記憶サブモジュールが動的スーパーブロックに書き込む方法は、スーパーブロックの書き込みはディスク上の破損した動的スーパーブロックを、システムに残してはならないを確実に行うべきである。双方の動的スーパーブロックが有効であることを、例えば、あらゆるオペレーションをボリューム上で行う前に２つのチェックポイント・オペレーションを行うなど、充分に確実にするための追加対策を講じてもよい。

双方の動的スーパーブロックが有効あり、次に、フトウェアが、後のチェックポイント番号をもったものを探すと仮定しよう。この動的スーパーブロックの状態には２つの可能性がある。

ＷＲＩＴＴＥＮ＿ＯＢＪ＿ＬＩＳＴ
この状態は、オブジェクト記憶が、修正済みチェックポイント・オブジェクト・リストをディスクに書き込んだけれども、システムが故障した時点では、オーノード構造、及びオーノード・データの全てを未だ書き込んでいないことを意味する。このことは、オブジェクト記憶が、アンクリーンなシステム停止であったことと、ディスクの最近の有効なチェックポイントが他の動的スーパーブロックに記録されたものであることを示している。（その状態は、ＷＲＩＴＴＥＮ＿ＣＨＥＣＫＰＯＩＮＴである。）
この状態においては、ディスク上のルート・オーノードの幾つかは、このチェックポイント作成の１部分として、更新されている。このことは、このチェックポイントに書き込まれたもののペアの時点でこのルート・オーノードを読み取ることが、最新の有効なものになりそうな時に問題がある。このことは、このチェックポイントが完全でなかったので間違っている。同じ問題は、他の全てのオーノード構造には当て嵌まらないことに留意されたい。何故なら、それを参照するオブジェクトが、使用するペアの中から正しいものを、直接向けられるからである。

この問題は、修正済みチェックポイント・オブジェクト・リストを利用して処理する。これは、ルート・オーノードへの変更がある前にディスクに書き込み、それのルート・オーノードがチェックポイントで修正されようとしているトランザクション・ログを提供する。チェックポイント不能の場合には、ソフトウェアが、修正済みチェックポイント・オブジェクト・リスト・オブジェクトを読み取り、それが向いているオブジェクトのそれぞれを通過する。オブジェクトのそれぞれについては、ソフトウェアがルート・オーノードのペアを読み取る必要がある。そして、もし、それらのいずれかが書き込まれておれば、それは無効である。

ＷＲＩＴＴＥＮ＿ＣＨＥＣＫＰＯＩＮＴ
この状態は、システムが作動しなくなった時、オブジェクト記憶がオーノード構造、及びデータをディスクに書き込み中ではないことと、この動的スーパーブロックで定義されたチェックポイント番号は、ディスク上の最後のチェックポイントであることとを意味している。このことは、ボリュームがクリーンに停止したため、ＮＶＲＡＭの中の再生すべきオペレーションが未だ存在するという意味ではない。

４．保持済みチェックポイント
チェックポイントは、チェックポイントが、もはや存在しなくなる時点での、次のチェックポイントが作成されるまでに限り有効である。従って、ユーザが、チェックポイントの削除を選択するまで、有効性、及びアクセス可能性を機構が維持するよう、チェックポイントを保持するためのユーザ・トリガー機構が設けられる。上述の通り、ユーザ・トリガー機構によって保持されるこのようなチェックポイントを本書では保持済みチェックポイントと称す。オブジェクト記憶モジュールは多数の保持済みチェックポイントを維持する能力がある。保持済みチェックポイントが活性状態にある限り、保持済みチェックポイントから構成される、オーノード、及びデータ・ブロックは修正、または空きスペースへ戻ることはできない。オーノード、及びデータ・ブロックは、多数の保持済みチェックポイントの構成要素であってもよく、オーノード、及びデータ・ブロックが、少なくとも１つの保持済みチェックポイントの構成要素である限り、特定のオーノード、及びデータ・ブロックは空きスペースへ戻れないことに留意されたい。

４．１ 保持済みチェックポイントの作成
保持済みチェックポイントは最初にある任意のボリュームに次の一連のオペレーションを行うことにより作成される。

１．チェックポイントを取得する。

２．コマンドを必要ボリュームのオブジェクト記憶サブモジュールに発出して、保持済みチェックポイントを作成する。

３．別のチェックポイントを取得する。

オブジェクト記憶サブモジュールがコマンドを受け取り、保持済みチェックポイントを作成すると、オブジェクト記憶サブモジュールは、ボリューム上の最後の保持済みチェックポイントはどのチェックポイント番号で作成されているかを指示する記録を更新する。これは、動的スーパーブロックに記録され、オペレーション３のチェックポイントが取得された時にディスクにセーブされている。保持済みチェックポイントは、オペレーション２の多数ボリューム上に取得が可能である。

４．２ 保持済みチェックポイントの後のオブジェクトの修正
オブジェクト記憶サブモジュールがオブジェクト修正要求を受け取る度に、オブジェクト記憶サブモジュールは最初にルート・オーノード・オブジェクトを調べて、ルート・オーノード・オブジェクトが作成されたチェックポイント番号を決定する。もし、ルート・オーノード・オブジェクトが最後の保持済みチェックポイントの作成以前に作成されている場合は、ルート・オーノード・オブジェクトはその最後の保持済みチェックポイントの一部である。この場合、ルート・オーノード・オブジェクトは、上述の通り、修正不可能である。何故なら、このことで、保持済みチェックポイントのオブジェクトのバージョンを損傷するからである。逆に、以下の例により述べる特殊な方法でオブジェクトを修正する。

図２３はチェックポイント番号１で作成されるオブジェクト例としてオブジェクト構造を示す。オブジェクトは、データ・ブロック０（２３１０）、データ・ブロック１（２３１２）、データ・ブロック２（２３１４）、データ・ブロック３（２３１６）の４つのデータ・ブロックを含んでいる。直接オーノード２３０６は、データ・ブロック０（２３１０）を示すポインタ、及びデータ・ブロック１（２３１２）を示すポインタを含んでいる。直接オーノード２３０８は、データ・ブロック２（２３１４）を示すポインタ、及びデータ・ブロック３（２３１６）を示すポインタを含んでいる。間接オーノード２３０４、直接オーノード２３０６を示すポインタ、及び直接オーノード２３０８を示すポインタを含んでいる。ルート・オーノード２３０２は、間接オーノード２３０４を示すポインタを含んでいる。全てのオーノード、及び全てのデータ・ブロックには、チェックポイント番号１が付いている。

さて、保持済みチェックポイントがチェックポイント番号２で取得され、データ・ブロック０（２３１０）は、チェックポイント番号３で修正されると仮定しよう。

この場合、オブジェクト記憶サブモジュールは先ずオブジェクト用ルート・オーノード２３０２をロードするとともに、チェックポイント番号２で設定される最後の保持済みチェックポイントの前に（チェックポイント番号１で作成された）ルート・オーノード２３０２が作成されたことを認識する。オブジェクトの最も最新バージョンへのアクセスを最適化するため、最も最新のルート・オーノードは、オブジェクト番号で表示されるセクター番号のところにあることが好ましい。従って、他に何かを行う前に、オブジェクト記憶サブモジュールはディスクの空きスペースに、旧ルート・オーノードのコピーをセーブし、セーブ済みルート・オーノードを示すポインタを、更新済みのルート・オーノードに書き込み、そして、更新済みルート・オーノードを示すポインタをセーブ済みルート・オーノードに書き込む。

図２４は、旧ルート・オーノードがディスク空きスペースへセーブされた後のオブジェクト構造を示す。具体的には、ブロック２４０３は、旧ルート・オーノードをディスクの空きスペースへセーブしたコピーを表している。現行のルート・オーノード２４０２を示すポインタはセーブ済みルート・オーノード２４０３に書き込まれている。ブロック２４０２は、チェックポイント番号３を持つ更新済みルート・オーノードを表す。セーブ済みルート・オーノード２４０３を示すポインタは現行のルート・オーノード２４０２に書き込まれている。

オブジェクト記憶サブモジュールは、次に、オブジェクト記憶サブモジュールがデータ・ブロック０（２３１０）用の記述子に到達するまでルート・オーノードから始まるオブジェクト構造を横断する。データ・ブロック０（２３１０）は最後の保持済みチェックポイントの取得以前に作成されているので、修正不可能である。その代わり、オブジェクト記憶サブモジュールは、必要なデータ修正をして、データ・ブロック０（２３１０）のコピーをディスクの空きスペースへ書き込む。

図２５は、データ・ブロック０の修正済みコピーをディスクの空きスペースへ書き込んだ後のオブジェクト構造をしめす。具体的には、ブロック２５１０は、ディスクの空きスペースへ書き込まれたデータ・ブロック０の修正済みコピーを表す。ブロック２５１０は、チェックポイント番号３（即ち、そこでその番号が作成されたチェックポイント）を含んでいる。

さて、オブジェクト記憶サブモジュールは、直接オーノードに新しいデータ・ブロック２５１０を示すポインタを置く必要があるが、直接オーノード２３０６が保持済みチェックポイントの構成要素であるので、オブジェクト記憶サブモジュールは、直接オーノード２３０６に新しいデータ・ブロック２５１０を示すポインタを置けない。オブジェクト記憶サブモジュールは、それ故、新しいデータ・ブロック０（２５１０）、及び旧データ・ブロック１（２３１２）を示すポインタを有する新しい直接オーノードを作成する。

図２６は、新しいデータ・ブロック用として新しい直接オーノードを作成した後のオブジェクト構造を示す。具体的には、ブロック２６０６は、新しい直接オーノードを表す。ブロック２６０６はチェックポイント番号３、ならびに新しいデータ・ブロック０（２５１０）、及び旧データ・ブロック１（２３１２）を示すポインタを含んでいる。

オブジェクト記憶サブモジュールは、間接オーノードに新しい直接オーノード２６０６を示すポインタを置く必要があるが、間接オーノード２３０４が保持済みチェックポイントの構成要素であるので、オブジェクト記憶サブモジュールは、間接オーノード２３０４に新しい直接オーノード２６０６を示すポインタを置けない。それ故、オブジェクト記憶サブモジュールは、新しい直接オーノード２６０６、及び旧直接オーノード２３０８を示すポインタを有する新しい間接オーノードを作成する。

図２７は、新しい直接オーノード用として新しい間接オーノードを作成した後のオブジェクト構造を示す。具体的には、ブロック２７０４は、新しい間接オーノードを表す。ブロック２７０４は、チェックポイント番号３、ならびに新しい直接オーノード２６０６、及び旧直接オーノード２３０８を示すポインタを含んでいる。

最後に、オブジェクト記憶サブモジュールは、オブジェクトルート・オーノード２４０２の現行バージョンの新しい間接オーノード２７０４を示すポインタを書き込む。

図２８は、新しい間接オーノード２７０４を示すポインタをオブジェクト・ルート・オーノード２４０２の現行バージョンに書き込んだ後のオブジェクト構造を示す。

データ・ブロック０の修正が完了した後、ブロック２４０３、２３０４、２３０６、２３１０は保持済みチェックポイントの構成要素となったが、オブジェクトの現行のバージョンの構成要素ではない、即ちブロック２３０８、２３１２、２３１４、２３１６は、保持済みチェックポイント、及びオブジェクトの現行バージョン双方の構成要素であり、ブロック２４０２、２７０４、２６０６、２５１０は、現行バージョン双方の構成要素ではあるが、保持済みチェックポイントの構成要素ではないことに留意されたい。

さて、保持済みチェックポイントがチェックポイント番号４で取得され、データ・ブロック３（２３１６）がチェックポイント５で削除されたと仮定しよう。ここでの手続きは、データ・ブロック０を修正した上記手続きに類似しており、データ・ブロック３の削除後のオブジェクト構造を示す図２９を参照して説明する。

この場合、オブジェクト記憶サブモジュールは、ブロック２９０３で表されるチェックポイント番号３から旧ルート・オーノードのコピーをディスク空きスペースにセーブし、ルート・オーノード・オブジェクト２９０２を更新してチェックポイント番号５を含めるとともに、現行、及びセーブ済みルート・オーノードの各種ポインタを更新する。具体的には、セーブ済みのルート・オーノード２９０３は、事実上、現行ルート・オーノード２９０２、及び以前のルート・オーノード２４０３の間の２重にリンクされたリストに挿入されている。現行ルート・オーノード２９０２においては、旧ルート・オーノードバージョンを示すポインタは更新されて、以前のセーブ済みルート・オーノード２４０３ではなく、セーブ済みルート・オーノード２９０３を示す。以前のセーブ済みルート・オーノード２４０３においては、新しいルート・オーノードバージョンを示すポインタは更新されて、現行のルート・オーノード２９０２ではなく、新しいセーブ済みルート・オーノード２９０３を示す。セーブ済みオーノード２９０３においては、新しいルート・オーノード・バージョンを示すポインタは更新されて、現行のルート・オーノード２９０２を示す。一方、旧ルート・オーノード・バージョンを示すポインタは更新されて、以前のセーブ済みルート・オーノード２４０３を示す。

次に、オブジェクト記憶サブモジュールは、データ・ブロック３（２３１６）用記述子を含む直接オーノード２３０８に到着するまで、ルート・オーノードから始まるオブジェクト構造を横断する。直接オーノード２３０８、及びデータ・ブロック３（２３１６）は既存の保持済みチェックポイントの構成要素であるので、データ・ブロック３（２３１６）の記述子を取り外すために、オブジェクト記憶サブモジュールはデータ・ブロック３（２３１６）を簡単に削除ができないし、また直接オーノード２３０８を修正することもできない。従って、オブジェクト記憶サブモジュールは、チェックポイント番号５、及びデータ・ブロック２（２３１４）を指すポインタは有するが、データ・ブロック３（２３１６）を指すポインタは有しない新しい直接オーノード２９０８を作成する。また、オブジェクト記憶サブモジュールは、チェックポイント番号５、並びに旧直接オーノード２６０６、及び新しい直接オーノード２９０８を指すポインタを有する新しい間接オーノード２９０４を作成する。最後に、オブジェクト記憶サブモジュールは、新しい間接オーノード２９０４を示すポインタを、ルート・オーノード２９０２の現行バージョンへ書き込む。

データ・ブロック３の削除後、ブロック２９０３、２４０３、２３０４、２７０４、２３０６、２３０８、２３１０、２３１６は、少なくとも１つの保持済みチェックポイントの構成要素となるが、オブジェクトの現行バージョンの構成要素ではない。即ち、ブロック２６０６、２５１０、２３１２、２３１４は、オブジェクトの現行バージョン、及び少なくとも１つの保持済みチェックポイントの構成要素であって、ブロック２９０２、２９０４、２９０８は、オブジェクトの現行バージョンの構成要素ではあるが、保持済みチェックポイントの構成要素ではないことに留意されたい。

４．３ 保持済みチェックポイントへのアクセス
オブジェクト記憶サブモジュールに、オブジェクトのオペレーションを行うよう依頼があると、オブジェクト記憶サブモジュールに処理が回され、そのオブジェクトを識別することが可能となる。とりわけ、この処理は、要求されたオブジェクトのチェックポイント番号を特定する。通常、このチェックポイント番号はオブジェクトの現行バージョンを示す値に設定される。しかしながら、もしも、異なるチェックポイント番号が特定された場合、オブジェクト記憶サブモジュールはオブジェクトの要求されたバージョンのオペレーションを行うことになる。

オブジェクト記憶サブモジュールは、要求されたチェックポイント番号、または以前のチェックポイント番号を有するルート・オーノードが見付かるまで、ルート・オーノードの新バージョンからルート・オーノードの旧バージョンまでのポインタを使って、現行、及びセーブ済みルート・オーノードを通ってオブジェクトの要求されたバージョンを探そうとする。オブジェクト記憶サブモジュールは、次に、そのルート・オーノードからオブジェクト構造を横断する。以上のことは、図２９を再度参照した例によって説明している。

もし、オブジェクト記憶サブモジュールが、チェックポイント番号５の要求を受け取ると、オブジェクト記憶サブモジュールは初めにルート・オーノード・オブジェクト２９０２の現行バージョンへ進む。現行ルート・オーノード２９０２は、要求済みチェックポイント番号であるチェックポイント番号５を持っている。従って、オブジェクト記憶サブモジュールはオブジェクトの要求バージョンを付与するルート・オーノード２９０２からオブジェクト構造を横断する。具体的には、ルート・オーノード２９０２は、間接オーノード２９０４を指している。間接オーノード２９０４は、直接オーノード２６０６、及び２９０８を指している。直接オーノード２６０６は、修正済みデータ・ブロック０（２５１０）、及びデータ・ブロック１（２３１２）を指している。直接オーノード２９０８は、データ・ブロック２（２３１４）を指している。このように、オブジェクトの現行バージョンはデータ・ブロック０を含み、削除済みデータ・ブロック３を排除している。

もし、オブジェクト記憶サブモジュールがチェックポイント番号４の要求を受け取ると、オブジェクト記憶サブモジュールは先ずルート・オーノード・オブジェクト２９０２の現行バージョンへ進む。現行オーノード２９０２は、チェックポイント番号５を有しているが、これがあまりにも新し過ぎて、オブジェクト記憶サブモジュールはセーブ済みルート・オーノード２９０３を指すポインタに従う。ルート・オーノード２９０３は、オブジェクトの要求バージョンよりも以前のチェックポイント番号３を有している。従って、オブジェクト記憶サブモジュールは、オブジェクトの要求バージョンを付与するルート・オーノード２９０３からオブジェクト構造を横断する。具体的には、ルート・オーノード２９０３は、間接オーノード２７０４を指している。間接オーノード２７０４は直接オーノード２６０６、及び２３０８を指している。直接オーノード２６０６は、修正済みデータ・ブロック０（２５１０）、及びデータ・ブロック１（２３１２）を指している。直接２３０８は、データ・ブロック２（２３１４）、及びデータ・ブロック３（２３１６）を指している。このように、チェックポイント番号４の保持済みチェックポイントは、修正済みデータ・ブロック０を含むとともに、データ・ブロック３をも含んでいる。

もし、オブジェクト記憶サブモジュールがチェックポイント番号２の要求を受け取った場合には、オブジェクト記憶サブモジュール最初にルート・オーノードブジェクト２９０２の現行バージョンへ進む。現行ルート・オーノード２９０２はチェックポイント番号５を有してが、あまりにも新し過ぎるため、オブジェクト記憶サブモジュールはルート・オーノード２９０２のポインタを用いセーブ済みルート・オーノード２９０３にアクセスする。セーブ済みルート・オーノード２９０３はチェックポイント番号３を有しているが、これもまた新し過ぎるため、ルート・オーノード２９０３のポインタを使用しセーブ済みルート・オーノード２４０３にアクセスする。セーブ済みルート・オーノード２４０３は、オブジェクトの要求バージョンよりも前のチェックポイント番号１を有している。次いで、オブジェクト記憶サブモジュールは、オブジェクトの要求バージョンを付与するセーブ済みルート・オーノード２４０３からオブジェクト構造を横断する。具体的には、ルート・オーノード２４０３は間接オーノード２３０４を指している。間接オーノード２３０４は直接オーノード２３０６、及び２３０８を指している。直接オーノード２３０６は、データ・ブロック０（２３１０）、及びデータ・ブロック１（２３１２）を指している。直接オーノード２３０８は、データ・ブロック２（２３１４）、及びデータ・ブロック３（２３１６）をポインタで指している。このように、チェックポイント番号２の保持済みチェックポイントは、元の４つのデータ・ブロックを含んでいる。

もし、オブジェクト記憶サブモジュールがオブジェクトの要求バージョンを発見できない場合には、オブジェクト記憶サブモジュールは、通常、エラーメッセージを発生することに留意されたい。図２９をもう一度参照して、例えば、もし、オブジェクト記憶サブモジュールがチェックポイント番号０の要求を受け取った場合には、オブジェクト記憶サブモジュールは、ルート・オーノード２４０３に到着するまで、ルート・オーノードを通って進む。ルート・オーノード２４０３は新し過ぎ、以前のルート・オーノードを示すポインタを有していないため、オブジェクト記憶サブモジュールはオブジェクトの要求バージョンが発見できなかったことを示すエラーメッセージを発生する。

さらに、保持済みチェックポイントを修正することはできず、オブジェクト記憶サブモジュールは読取りオペレーションのみをその上で行うことができるということに留意されたい。

４．４ 保持済みチェックポイントの削除
保持済みチェックポイントを削除するプロセスには、２つの段階がある。

第１の段階には、削除予定の保持済みチェックポイントで作成あるいは修正されるオブジェクト全部のリスト入手が含まれる。これは、保持済みチェックポイント全てに対して作られている特殊なオブジェクト（修正済み保持オブジェクト・リスト・オブジェクト）を使ってできる。このオブジェクトは、ボリュームが一番最初に開かれた時、または保持済みチェックポイントが取得された後のいずれかの場合に、作成する。もし、オブジェクトが、以前の保持済みチェックポイントで作成されている場合には、オブジェクトを作成される度に、または、初めてオブジェクトが修正される時に、オブジェクト番号をこのオブジェクトに書き込む。この特殊なオブジェクトのオブジェクト番号を動的スーパーブロックに記憶する。保持済みチェックポイントを作成する前に、ソフトウェアは、後で保持済みチェックポイントの削除を希望した時のために、この特殊オブジェクトのオブジェクト番号を記録する。

保持済みチェックポイント削除の第２段階には、保持済みチェックポイントで、作成または修正のいずれかが行われるオブジェクトそれぞれの次の一連のオペレーションが含まれる。

１．オブジェクトが他のオペレーションで使えないようにオブジェクトをロックする。保持済みチェックポイントが作動中のファイル・システムで削除される場合のみ、これが必要となる。

２．もし、最も最近の保持済みチェックポイントが削除される、及びオブジェクトが削除されておれば、保持済みチェックポイント用のルート・オーノードと、以前の保持済みチェックポイント用のルート・オーノード（１つある場合）と、次の保持済みチェックポイントのルート・オーノード（１つある場合）、またはオブジェクトの現行バージョンのルート・オーノードのいずれかと、を探す。

３．削除される保持済みチェックポイント構造を経由して進み、それが使用している全ての間接、及び直接オーノード、ならびにデータ・ブロックを識別する。このようなオーノード、及びデータ・ブロックのそれぞれに関しては、削除される保持済みチェックポイントだけで、項目を使用しているのかどうかを判断する。これは、オブジェクトの以前と次の両バージョンに等価な項目を見つけることで行うことができる。もし、等価項目が、オブジェクトの以前と次のバージョンで異なっておれば、その項目は、この保持済みチェックポイントに特有である。

４．もし、項目が、削除される保持済みチェックポイントのみで使用されるならば、項目は、もはや必要なくなるので、空きスペースへ戻される。もし、その項目が保持済みチェックポイントのみで使用されており、次の更新済み保持オブジェクト・リストの中に既になければ、次のチェックポイント用の更新済み保持オブジェクト・リストに追加される。更新済み保持オブジェクト・リストに項目を追加することで、オブジェクト記憶サブモジュールは、その保持済みチェックポイントが削除されることになる時に、項目が未だ必要とされているのかどうかの調査について認識する。

５．最後に、もし、この保持済みチェックポイント用のルート・オーノードがこの保持済みチェックポイントの中だけで使用されているのであれば、ルート・オーノードもまたもはや必要でなく、削除される。この場合、もし、旧保持済みチェックポイントがあれば、削除される保持済みチェックポイントのルート・オーノードを以前に指していたルート・オーノードの次のバージョンから後方へ向かうポインタ（もしあれば）は、更新されて、以前の保持済みチェックポイントのルート・オーノードを指す。

ファイル・システム整合性を維持するため、チェックポイントの取得プロセスと保持済みチェックポイント削除とを結合する方法について細心の注意を払う必要があり、これにより、チェックポイントが常にファイル・システムの首尾一貫した考え方を表わしていること、及び保持済みチェックポイントの削除途中での故障が回復できることが確実となる。

保持済みチェックポイントの削除は例示することができる。図２９を参照して、チェックポイント番号４で作成された保持済みチェックポイントが削除されると仮定しよう。このチェックポイントはルート・オーノード２９０３で表されている。構造の中で、この保持済みチェックポイントで使用される項目は、ルート・オーノード２９０３、及び直接オーノード２７０４のみである。これらのオーノードは空きスペースへ戻される。ルート・オーノード２９０２は更新されて削除済みルート・オーノード２９０３でなくルート・オーノード２４０３を指す。図３０は保持済みチェックポイント番号４のチェックポイントが削除された後のオブジェクト構造を示している。

再度、図３０を参照して、さて、チェックポイント番号２が未だ存在している間に、オブジェクトの現行バージョンが削除されると仮定しよう。これは、構造の中で現行バージョンに特有な全ての項目を識別する必要性、及びこれらの項目を空きスペースに戻す必要性がある点で、削除される保持済みチェックポイントの場合と、類似している。この場合、オーノード２９０４、２６０６、２９０８は、オブジェクトの現行バージョンに使用されるが、残りの保持済みチェックポイントのいずれにも使用されないので、これらのオーノードは空きスペースに戻される。現行ルート・オーノード２９０２は、修正されて、削除されたオブジェクトを参照しているが、少なくとも１つの有効な保持済みチェックポイントを指すポインタを未だ有していることを示してる。図３１は、オブジェクトの現行バージョンが削除された後のオブジェクト構造を示す。

本オブジェクトの残り全ての保持済みチェックポイントが削除されると、ルート・オーノード２９０２は、空きスペースでなく、空きルート・オーノード待ち行列に戻される。

４．５ 保持済みチェックポイントへの復帰
幾つかの状況下で、稼働中のファイル・システムを保持済みチェックポイントで表されるバージョンは復帰させる必要や望ましいことがあるかもしれない。稼働中のファイル・システムを保持済みチェックポイントで表されるバージョンへ復帰させるには、多くの異なる方法によって可能である。稼働中のファイル・システムを保持済みチェックポイントへの復帰は以下のようなことを含む。

１．保持済みチェックポイントと関連付けされたルート・オーノードの関連内容を、現行のルート・オーノードにコピーすること。（例えば、直接オーノード、及び間接オーノード、ならびにデータ・ブロックを指すポインタ、以前の保持済みチェックポイントを指すポインタなど）
２．以前の保持済みチェックポイント（１つある場合）と関連付けされたルート・オーノードを識別すること、及び、稼働中のファイル・システムが復帰させられる保持済みチェックポイントと関連付けられたルート・オーノードなく、現行のルート・オーノードを指すようルート・オーノードのポインタを修正する。

３．保持済みチェックポイントと関連付けされたルート・オーノードを削除すること。

４．更新済みチェックポイント・オブジェクト・リストをクリアすること。（即ち、稼働中のファイル・システムを保持済みチェックポイントで表されるバージョンへ復帰させた後、事実上、修正済みオブジェクトは存在しない。）
５．ファイル・システムが復帰させられるチェックポイントが保持された後で取得された任意の保持済みチェックポイントと関連付けられたルート・オーノード、及び他のオブジェクトを含む、チェックポイントの保持後に作成された全てのオブジェクトを削除すること。

以前の保持済みチェックポイントと関連付けられたルート・オーノードのポインタを修正する以外に、もし１つあれば、旧保持済みチェックポイントのいずれも変化がないままである。しかしながら、新しい保持済みチェックポイントは全てが実質的には削除される。

４．６ 保持済みチェックポイントに関する他のオペレーション
保持済みチェックポイントと通常関連付けられた他の全ての機能は本書に述べる機構を用いて果たすことができる。例えば、インクリメンタル・バックアップは、継続的保持済みチェックポイントの間で変化するものを算定するための更新済み保持オブジェクト・リストを用いて行うことができる。

本特許の前述の特徴は、添付図面と照合して以下の詳細な説明を参照することによってさらに容易に理解されるだろう。
図１は、本発明の様々な態様を適用したファイル・サーバの実施形態のブロック線図である。 図２は、図１の実施形態の実行に関するブロック線図である。 図３は、本発明の実施形態に基づくファイル・システム・モジュールのブロック線図である。 図４は、ソフトウェア制御を介在させずにファイル・サービス・モジュールによってネットワーク・リクエストへの自動応答が可能となる本発明の実施形態への制御フローの使用方法を示すブロック線図である。 図５は、本発明の実施形態に基づくセクター・キャッシュ・ロッキングを具体化したクラスター化ファイル・サーバ構成のブロック線図である。 図６は、不揮発性メモリを垂直ループ構成でミラー化した本発明の実施形態によるクラスター化ファイル・サーバ構成のブロック線図である。 図７は、図３に示す実施形態に基づく他のオーノード（ｏｎｏｄｅ）を有しないルート・オーノード（ｒｏｏｔ ｏｎｏｄｅ）の用法を示すブロック線図である。 図８は、直接オーノードを有するルート・オーノードの用法を示すブロック線図である。 図９は、直接オーノード、及び間接オーノードを有するルート・オーノードの用法を示すブロック線図である。 図１０は、ルート・オーノードと、直接オーノードとの間に置かれた間接オーノード多重層の用法を示すブロック線図である。 図１１は、図３の実施形態に基づくチェックポイントＡ期間中のルート・ノードの作成状況を示す線図である。 図１２は、図１１のルート・オーノードに対して、ルート・ノードの右側に書き込まれた修正を更に行った場合の効果を示す線図である。 図１３は、チェックポイントＡの作成結果を示す線図であって、ディスクに図１２のルート・オーノードが書き込まれている。 図１４は、同じルート・オーノード用のチェックポイントＢの作成結果を示す線図である。 図１５は、チェックポイントＢが作成される間に、チェックポイントＣの一部分としてルート・オーノードを修正した場合の結果を示す線図である。 図１６は、２レベルの間接参照を有するオブジェクト構造の一部であるルート・オーノードの図の出発点を示す線図である。 図１７は、図１６のルート・オーノードが対応するオブジェクトの構造を示す線図である。 図１８は、図１７に図示されるオブジェクトに対してチェックポイントを取った場合の結果を示す図である。 図１９は、図１８のデータ構造に関して、新しいチェックポイントを取得する前に、新しいデータブロック２を割り当てるとともに、この新しいデータブロックを指すオーノード構造の全てを更新した場合の結果を示す図である。 図２０は、図１９の構造に関して、チェックポイントを取得した場合の結果を示す線図である。 図２１は、図２０の構造に関して、データ上書きモードのオブジェクトでデータ・ブロック１に書き込んだ場合の結果を示す線図である。 図２２は、チェックポイントの作成ステップ示すスケジュール表である。 図２３は、チェックポイント番号１でのデータブロック４個と、各種のオーノードとを含む典型的なオブジェクトの構造を示す線図である。 図２４は、保持済みチェックポイントをチェックポイント番号２で取得した後、及びチェックポイント番号３の期間中にデータブロック０を修正している間、具体的には、オブジェクトのルート・オーノードのコピーが空きスペースへセーブされ、ルート・オーノードを更新してセーブ済みルート・オーノードを示すポインターが含まれるようにした後の、本発明の実施形態に基づく、図２３の典型的なオブジェクトの構造を示す線図である。 図２５は、データブロックの修正済みコピーを空きスペースへ書き込んだ後の、本発明の実施の形態による、図２４の典型的なオブジェクトの構造を示す線図である。 図２６は、新しい直接オーノードを作成してデータブロックの修正済みコピーを指すようにした後の、本発明の実施形態による、図２５の典型的なオブジェクトの構造を示す線図である。 図２７は、新しい間接オーノードを作成して新しい直接オーノードを指すようにした後の、本発明の実施の形態による、図２６の典型的なオブジェクトの構造を示す線図である。 図２８は、新しい間接オーノードを指すポインターをオブジェクト用の現行ルート・オーノードに書き込んだ後の、本発明の実施の形態による、図２７の典型的なオブジェクトの構造を示す線図である。 図２９は、保持済みチェックポイントをチェックポイント番号４で取得し、データブロック３がチェックポイント番号５で削除された後の、本発明の実施の形態による、図２８の典型的なオブジェクトの構造を示す線図である。 図３０は、チェックポイント番号４で取得された保持済みチェックポイントが削除された後の、本発明の実施の形態による、図２９の典型的なオブジェクトの構造を示す線図である。 図３１は、オブジェクトの現行バージョンが削除され、チェックポイント番号２で取得された保持済みチェックポイントのみが残った、本発明の実施の形態による、図３０の典型的なオブジェクトの構造を示す線図である。

Claims (43)

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. 前記記憶システムは、
    磁気記憶装置、
    光磁気記憶装置、及び
    光記憶装置
    のうちの少なくとも１つを含む、請求項１または２に記載のファイル・サーバ・システム。

Images