JPH08511367A - ライトエニウエアファイルシステムレイアウト - Google Patents

Abstract

(57)【要約】 本発明は、整合性のある状態にファイルシステムを維持し、かつ、ファイルシステムの読出し専用コピーを作成する方法を提供する。ファイルシステムに対する変更は、つよく制御されている。このファイルシステムは、１つの整合状態から別の整合状態へ進む。ルートｉノードによってルートされるディスク上の自己整合性ブロックの集合は、整合点と呼ばれる。整合点を実施するために、新しいデータは、常に、ディスク上の割り当てられていないブロックに書き込まれる。ファイルシステム情報ブロック（２４４０）がｉノードファイル（１２１０）のための新しいルートｉノードをディスク上に書込むことにより更新されるとき、新しい整合点が生じる。このように、ルートｉノードが更新されない限り、ディスク上に存在するファイルシステムの状態は変化しない。また、本発明は、ファイルシステムの読出し専用コピーであるスナップショット（図２２）をも作成する。初めて作成される時は、スナップショットは、ディスク空間を使用しない。それは、同じファイルシステムに対して、多くの異なるスナップショットが作成できるように設計される。従来のファイルシステムでは、全体のｉノードファイルと全間接ブロックとを複製することによりクローンを作るが、これと異なり、本発明は、ｉノードファイルを記述するｉノードのみを複製する。多ビットフリーブロックマップファイル（１６３０）が、ディスク上での上書きを防止するために用いられる。

Description

【発明の詳細な説明】 ライトエニウエアファイルシステムレイアウト発明の背景 １．発明の分野 本発明は、整合性のある（consistent）ファイルシステムを維持し、かつ、こ のファイルシステムの読出し専用コピーを作成する方法及びその装置の分野に関 する。 ２．背景技術 全てのファイルシステムは、システムが故障した場合でも、整合性を維持する 必要がある。この目的のために、現在までにいくつかの異なる整合性維持技法が 、従来技術において用いられて来た。 どのようなファイルサーバの管理においても、最も難しく時間のかかる問題点 の１つは、ファイルデータのバックアップを作成することにある。伝統的な解決 方法は、データをテープまたは他のオフライン媒体にコピーすることであった。 あるファイルシステムでは、バックアップが完全に整合性があることを確認する ために、バックアップ処理中に、ファイルサーバをオフラインにする必要がある 。最近のバックアップにおける進歩により、迅速にファイルシステムのクローン （clone）を作り（即ち、ディスク上にファイルシステムの読出し専用のコピー を作る従来技術の方法）、アクティブ（active）なファイルシステムからではな く、このクローンからバックアップを行うことができる。このタイプのファイル システムでは、バックアップの間ファイルサーバをオンラインに保持できる。 ファイルシステムの整合性 従来技術によるファイルシステムが、Ｃｈｕｔａｎｉ等によるエピソードファ イルシステム（The Episode File System）と題する論文（ＵＳＥＮＩＸ、１９ ９２年ウィンタ号、４３〜５９頁）に開示されている。この論文は、メタデータ （即ち、ｉノードテーブル、ディレクトリ、ビットマップ、間接ブロック）等を 用いるファイルシステムであるエピソードファイルシステムについて述べている 。それは、スタンドアローンのファイルシステムとして、または、分散ファイル システムとして使用できる。エピソードファイルシステムは、複数の別々のファ イルシステム階層構造をサポートし、また、複数のファイルシステムについて、 一括して「集合体」として言及している。特に、エピソードシステムは、除々に データを変化させるため、各フアイルシステムのクローンを備える。エピソード システムでは、各ロジカルファイルシステムは、「アノード（anode）テーブル 」を含む。アノードテーブルは、バークレ・ファスト・ファイル・システム（Be rkeley Fast File System）等のファイルシステムで用いられるｉノードテーブ ルに相当する。アノードテーブルは、２５２バイトの構造を有している。アノー ドは、エピソードファイルシステムのメタデータだけではなく、全ての使用者デ ータを記憶するのに用いられる。アノードは、補助ファイルとディレクトリを含 むファイルシステムのルートディレクトリを記述する。エピソードの各々のこの 様なファイルシステムは、「ファイル集合」と呼ばれる。ファイル集合内の全デ ータは、アノードテーブルをとおして反復し、各ファイルを順に処理することに より、探し出すことができる。エピソードシステムは、ファイルシステムの読出 し専用コピー（ここではクローンという）を作成して、コピー・オン・ライト（ Copy-On-Write）（ＣＯＷ）技術を用いて、アクティブなファイルシステムとデ ータを共有する。 エピソードシステムは、システムのクラッシュの後、ファイルシステムを回復 させるのに、ロギング技術を用いている。ロギング技術は、ファイルシステムの メタデータが整合的であるかどうかを確認する。ビットマップテーブルは、ファ イルシステム内の各ブロックが割り当てられているか否かについての情報を含む 。また、ビットマップテーブルは、各ブロックがログ（記録）されているか否か をも示す。全ての最新のメタデータは、集合体の処理（transaction）ログを記 憶しているログ「コンテナ」（container）に記憶される。ログは、ディスクブ ロックの循環バッファとして処理される。エピソードシステムの処理ロギングは 、ファイルシステムの整合性を確認するために、元来データベースのために開発 された ロギング技法を用いる。この技法は、注意深く順序づけられた書込み（write） と回復（recovery）プログラム（その中のデータベース技法によって補われる） を用いる。 ＩＢＭのＪＦＳ及びベリタス社（Veritas Corporation）のＶｘＦＳを含む他 の先行技術システムは、回復処理を早めるために各形態の処理ロギングを用いて いるが、未だ回復処理を必要としている。 もう１つの従来技術方法は、「オーダードライト」（ordered write）技法と 呼ばれ、それは、一連の関係する書込みを行っている間にシステムの故障が生じ た時に損害を最小とするため、全てのディレクトリブロックに、注意深く決めら れた順序で書き込む。この従来技術では、発生した不整合性が無害のものである ことを確認することを試みる。たとえば、少数の使用されていないブロックまた はｉノードは、割り当てられたものとしてマークされる。この技法の主な短所は 、それがディスクのオーダに与える制限の為に、高性能を達成することが困難に なることである。 他の従来技術システムは、「回復を伴うオーダードライト（ordered write wi th recovery）」技法と呼ばれる上記の第２の従来技術の改良方法である。この 方法では、不整合性は、潜在的に有害となり得る。しかし、書込みのオーダは、 回復プログラムで不整合が発見され処理されるように制限される。この方法の例 としては、元のＵＮＩＸファイルシステムと、バークレイファストファイルシス テム（ＦＦＳ）がある。この技法では、ディスクオーダリング（ordering）の性 能上の減点を充分除く様にディスクオーダリングを減じている。もう１つの不利 な点は、回復プロセスが、時間がかかる点である。それは、典型的には、ファイ ルシステムのサイズに比例している。そのため、たとえば５ＧＢのＦＦＳファイ ルシステムを回復するには、１時間以上を必要とする。ファイルシステムのクローン 図１は、ファイル集合のクローンを作成するためのコピー・オン・ライト（Ｃ ＯＷ）技術の使用を示すエピソードファイルシステムの従来技術の図である。ア ノード１１０は、セットされたＣＯＷビットを有する第１のポインタ１１０Ａか らなる。ポインタ１１０Ａは直接データブロック１１４を参照する。アノード１ １０は、クリアされたＣＯＷビットを有する第２のポインタ１１０Ｂからなる。 アノードのポインタ１１０Ｂは、間接ブロック１１２を参照する。間接ブロック １１２は、直接データブロック１２４を参照するポインタ１１２Ａからなる。ポ インタ１１２ＡのＣＯＷビットは、セットされている。間接ブロック１１２は、 データブロック１２６を参照する第２のポインタ１１２Ｂからなる。ポインタ１ １２ＢのＣＯＷビットはクリアされる。 クローンアノード１２０は、データブロック１１４を参照する第１のポインタ １２０Ａからなる。ポインタ１２０ＡのＣＯＷビットは、クリアされる。クロー ンアノード１２０の第２のポインタ１２０Ｂは間接ブロック１２２を参照する。 ポインタ１２０ＢのＣＯＷビットはクリアされる。次に、間接ブロック１２２は 、データブロック１２４を参照するポインタ１２２Ａからなる。ポインタ１２２ ＡのＣＯＷビットはクリアされる。 図１に示すように、エピソードファイルシステムの各直接ポインタ１１０Ａ、 １１２Ａ〜１１２Ｂ、１２０Ａおよび１２２Ａ、および、間接ポインタ１１０Ｂ と１２０Ｂは、ＣＯＷビットを含む。変更されていないブロックは、アクティブ ファイルシステムとクローンの両方に含まれ、ＣＯＷビットをセットする（１） 。ポインタにより参照されるブロックが変更された時にＣＯＷビットはクリアさ れ（０）、そのため、アクティブなファイルシステムの１部であるが、クローン ではない。 図１に示すように、コピー・オン・ライトブロックが変更されると、新たに、 ブロックが割り当てられ更新される。次に、この新しいブロックへのポインタ内 のＣＯＷフラグがセットされる。元のアノード１１０のポインタ１１０ＡのＣＯ Ｗビットは、クリアされる。 こうして、クローンアノード１２０が作られると、クローンアノード１２０の ポインタ１２０Ａは、データブロック１１４も参照する。元のアノード１１０も クローンアノード１２０も共に、データブロック１１４を参照する。また、デー タブロック１２４も、元の間接ブロック１１２内のポインタ１１２Ａのクリアさ れたＣＯＷビットにより示される様に、変更される。このように、クローンアノ ードが作られるとき、間接ブロック１２２が作られる。間接ブロック１２２のポ インタ１２２Ａは、データブロック１２４を参照し、ポインタ１２２ＡのＣＯＷ ビットがクリアされる。元のアノード１１０の間接ブロック１２２と、クローン アノード１２０の間接ブロック１２２は、共に、データブロック１２４を参照す る。 図１は、単一ファイル用にクローンアノード１２０を作るためのアノードのコ ピー動作を示す。ただし、クローンアノードは、ファイルシステム中で変更した データブロックを有する各ファイルに対して作成する必要がある。クローンの場 合には、全てのｉノードをコピーしなければならない。ファイルシステム中です べての変更されたファイルに対してクローンアノードを作ることにより、かなり の量のディスクスペースを消費することになる。さらに、エピソードシステムは 、各ポインタが唯一のＣＯＷビットしか有していないので、多数のクローンをサ ポートできない。単一のＣＯＷは、１以上のクローンを区別することができない 。１以上のクローンに対しては、セットできる第２のＣＯＷがない。 ファイル集合の「クローン」は、アクティブなファイル集合が読出し、また、 書込める、アクティブなファイル集合の読出し専用コピーである。クローンは、 ＣＯＷ技術を用いて実施され、ブロック毎に、アクティブなファイル集合とデー タブロックを共有する。エピソードシステムは、ファイル集合に記憶されている 各アノードをコピーしてクローン化を実施する。初めにクローンを作るときは、 アクティブなファイル集合の書込み可能アノードもクローンされたアノードと共 に、同じデータブロックを指す。しかし、元のアノード中の直接ブロックおよび 間接ブロックのディスクアドレスは、ＣＯＷとしてタグ（tag）される。そのた め、書込み可能のファイル集合を更新してもクローンに影響を与えない。ＣＯＷ ブロックが変更されると、新しいブロックがファイルシステム内で割り当てられ 、その変更に伴って更新される。この新しいブロックに対するポインタのＣＯＷ フラグはクリアされる。 従来のエピソードシステムは、ファイルシステム内の全体のｉノードファイル と全ての間接ブロックを複製するクローンを作成する。エピソードシステムは、 アクティブなファイルシステムとクローンの両方によって使われるブロックに対 する全ポインタにコピー・オン・ライト（ＣＯＷ）ビットをセットできるように 全てのｉノード及び間接ブロックを複製する。エピソードシステムでは、アクテ ィブなファイルシステムに書き込まれた新しいデータが、クローンの１部で、そ のために変更してはならない「古い」データを上書きしないように、これらのブ ロックを確認することが重要である。 この従来技術でクローンを作成するには、ＩＧＢディスクで３２ＭＢまでを使 用する。また、この従来技術では、ファイルシステムの８個のクローンを維持す るのに、ＩＧＢディスクで（４ＫＢのブロックに対して）２５６ＭＢのディスク 空間を使用する。このように、先行技術では、データの損失を防止するのに多数 のクローンを使用できない。そのかわりに、テープバックアップ装置のような、 ディスクドライブ以外の補助記憶手段がファイルシステムのバックアップを行う のを容易にするために用いられる。クローンは、クローンが作成された瞬間に整 合性のある状態でファイルシステムをバックアップするのに用いられる。ファイ ルシステムのクローンを作ることにより、クローンは、アクティブなファイルシ ステムをシャットダウンし、使用者がファイルシステムを用いることを妨げるこ となしに補助記憶手段に対してバックアップ可能となる。このようにして、クロ ーンは、ファイルシステムが整合性を有するようにバックアップされる間、使用 者がアクティブファイルシステムにアクセスを続けることを可能とする。次いで 、バックアップが１度で完了すると、クローンは削除される。エピソードシステ ムは、各ポインタが１つのＣＯＷビットしか有していないので、多数のクローン をサポートできない。単一のＣＯＷビットは、１つ以上のクローンを区別できな い。１より多いクローンに対してセットできる第２のＣＯＷビットはない。 ファイルシステムのクローンを作成するこの先行技術システムの１つの短所は 、それがファイルシステム中の全てのｉノードと全ての間接ブロックの複製を必 要とすることである。多くの小さなファイルを有するシステムでは、ｉノードだ けでも、ファイルシステム中の全ディスク空間のかなりの割合を使用する。たと え ば、４ＫＢのファイルで満たされた１ＧＢのファイルシステムは、３２ＭＢのｉ ノードを有している。このように、エピソードクローンを作成することは、かな りのディスク空間を使い、多量の（即ち、多くのメガバイトの）ディスクトラフ ィック（traffic）を生じる。この条件の結果として、ファイルシステムのクロ ーンを作成するには、完成までにかなりの時間を必要とする。 この先行技術システムのもう１つの短所は、同じファイルシステムの多数のク ローンを作成するのが難しいという点である。この結果、クローンは、ファイル システムをテープでバックアップする等の短い期間の操作に対して、１時に一つ 使用され、次に消去されるという傾向になっている。発明の概要 本発明は、整合性のある状態にファイルシステムを維持し、かつ、ファイルシ ステムの読出し専用コピーを作成する方法を提供する。ファイルシステムを整合 性のある状態に維持するために、ファイルシステムに対する変更は、きびしく制 御されている。このファイルシステムは、１つの自己整合状態から別の自己整合 状態へ進む。ルートｉノードによってルート（root）されるディスク上の自己整 合性ブロックの集合は、整合点（ＣＰ）と呼ばれる。整合点を実施するために、 ＷAＦＬは、常に、ディスク上の割り当てられていないブロックに新しいデータ を書くが、決して現存のデータを上書きすることはない。ファイルシステム情報 （fsinfo）ブロックがｉノードファイルのための新しいルートｉノードをその中 に書込むことにより更新されるとき、新しい整合点が生じる。このように、ルー トｉノードが更新されない限り、ディスク上に存在するファイルシステムの状態 は変化しない。 また、本発明は、ファイルシステムの仮想読出し専用コピーであるスナップシ ョット（snapshot）をも作成する。初めて作成される時は、スナップショットは 、ディスク空間を使用しない。それは、同じファイルシステムに対して、多くの 異なるスナップショットが作成できるように設計される。従来のファイルシステ ムでは、全体のｉノードファイルと全ての間接ブロックを複製することにより、 クローンを作るが、これと異なり、本発明は、ｉノードファイルを記述するｉノ ー ドのみを複製する。こうして、スナップショットに必要な実際のディスク空間は 複製ｉノードを格納するのに用いる１２８バイトにすぎない。スナップショット に必要な本発明の１２８バイトは、従来技術のクローンに用いられる数メガバイ トよりかなり少ない。 本発明は、アクティブなファイルシステムに書き込まれた新しいデータが、ス ナップショット（１以上）の１部である「古い」データを上書きするのを防止す る。古いデータは、それがスナップショットの１部である限り、上書きされない ことが必要である。これは、多重ビットのフリーブロックのマップを用いること により達成される。大部分の従来技術のファイルシステムは、ブロックが割り当 てられているか否かを示すために、ブロック毎に単一ビットを有するフリーブロ ックマップを用いる。本発明は、３２ビットエントリを有するブロックマップを 用いる。第１ビットは、ブロックが、アクティブなファイルシステムにより使用 されるか否かを示し、残りの２０ビットは、２０個のスナップショットまで用い られるが、３１ビットの内のいくつかのビットは、他の目的に用いてもよい。図面の簡単な説明 図１は、ファイルシステムの従来技術の「クローン」を示すブロック図である 。 図２は、汚れバッフアを有するｉノードのリストを示す図である。 図３は、ＷＡＦＬのオン・ディスクｉノードを示す図である。 図４Ａ〜図４Ｄは、異なるレベルの間接度（indirection）を有するＷＡＦＬ のオン・ディスクｉノードを示す図である。 図５は、整合点を生成する方法を示す流れ図である。 図６は、整合点を生成する図５のステップ５３０を示す流れ図である。 図７は、スナップショットを作成するための図５のステップ５３０を示す流れ 図である。 図８は、本発明によるＷＡＦＬのメモリ内（incore）ｉノードを示す図である 。 図９Ａ〜図９Ｄは、本発明による、異なるレベルの間接度を有するＷＡＦＬの メモリ内のｉノードを示す図である。 図１０は、ファイル用のメモリ内ｉノード１０２０を示す図である。 図１１Ａ〜図１１Ｄは、本発明によるブロックマップファイルを示す図である 。 図１２は、本発明によるｉノードファイルを示す図である。 図１３Ａ〜図１３Ｂは、本発明によるｉノードマップファイルを示す図である 。 図１４は、本発明によるディレクトリを示す図である。 図１５は、ファイルシステム情報構造を示す図である。 図１６は、ＷＡＦＬファイルシステムを示す図である。 図１７Ａ〜図１７Ｌは、整合点の生成を示す図である。 図１８Ａ〜図１８Ｃは、スナップショットの生成を示す図である。 図１９は、ｉノードファイルへの変更を示す図である。 図２０は、ファイルシステムを整合状態に維持するために用いられるファイル システム情報ブロックを示す図である。 図２１Ａ〜図２１Ｆは、スナップショットの生成を示す詳細な図である。 図２２は、それぞれ共通ファイルを参照する３つのスナップショットを有する アクティブなＷＡＦＬファイルシステムを示す図である。 図２３Ａ〜図２３Ｂは、ａタイムの更新を示す図である。発明の詳細な説明 ファイルシステムにおける読出し専用コピー作成システムについて述べる。本 発明に関する記述の全体を通して、より詳しく説明するために、ディスク（複数 ）の番号や性質、ディスクブロックサイズ等に関して、以下に詳細に説明する。 しかし、明らかに、このような詳細な説明は無くても、当該技術に関する熟練者 であれば、本発明を実施することは可能である。たとえば、本発明が不明瞭にな るのを避けるために、公知の特徴については詳細には説明していない。ライトエニウエアファイルシステムレイアウト 本発明は、ライトエニウエア（writeanywhere）（どこでも書込みできる）フ ァイルシステムレイアウト（ＷＡＦＬ）を用いる。このディスクフォーマットシ ステムは、ブロックベース（つまり、断片的部分を含まない４ＫＢのブロック） であり、ファイルを表すのにｉノードを用い、単純に特別にフォーマットされた ファイルからなるディレクトリを含む。ＷＡＦＬは、ファイルシステムのレイア ウトを記述するメタデータを保存するためのファイル（複数）を用いる。ＷＡＦ Ｌのメタデータファイルは、ｉノードファイル、ブロックマップ（blkmap）ファ イルおよびｉノードマップ（inomap）ファイルを含む。ｉノードファイルは、フ ィルシステム用のｉノードテーブルを含む。ブロックマップファイルは、どのデ ィスクブロックが割り当てられているかを示す。ｉノードマップは、どのｉノー ドが割り当てられているかを示す。オンディスク及びメモリ内（incore）のＷＡ ＦＬのｉノードについては、後に述べる。オンディスクＷＡＦＬｉノード ＷＡＦＬのｉノードは従来のｉノードとは異なる。オンディスク（ディスク上 ）ＷＡＦＬｉノードは、それぞれ、同レベルの間接度（indirection）を有する １６個のブロックを指す。ブロック番号は４ビット長である。一つのｉノード中 の同レベルの間接度を有するブロック番号を使用することで、ファイルの再帰プ ロセスをより容易にしている。図３は、オンディスクｉノード３１０を表すブロ ック図である。オンディスクｉノード３１０は、標準ｉノード情報３１０Ａと同 レベルの間接度を有する１６個のブロック番号エントリ３１０Ｂとからなる。ｉ ノ ード情報３１０Ａは、ファイルの所有者、許可、ファイルサイズ、アクセスタイ ム等に関する情報からなるが、これらは当業者にとって公知のことである。オン ディスクｉノード３１０は、異なるレベルの間接度を有する複数個のブロック番 号からなる従来のｉノードとは異なる。一つのｉノード３１０に含まれるすべて のブロック番号エントリ３１０Ｂの間接度を同レベルに保つことによって、ファ イルシステムを単純にできる。 ６４バイト以下の小さいファイルに関しては、１６個のブロック番号ではなく 、ｉノード自体に直接データが保存される。図４Ａは、図３に示されたｉノード ３１０に類似した、レベル０のｉノード４１０を表す。しかし、ｉノード４１０ は１６個のブロック番号３１０Ｂの代わりに、６４バイトのデータ４１０Ｂから なる。したがって、非常に小さいファイルについては、ディスクブロックを割り 当てる必要が無い。 ６４ＫＢ以下の大きさのファイルに関しては、１６個のブロック番号のそれぞ れが直接４ＫＢのデータブロックを参照する。図４Ｂは、１６ブロック番号３１ ０Ｂからなるレベル１のｉノード３１０を表す。ブロック番号エントリ０〜１５ は、対応する４ＫＢのデータブロック４２０Ａ〜４２０Ｃを指す。 ６４ＫＢ以上かつ６４ＭＢ以下の大きさのファイルに関しては、１６ブロック 番号のそれぞれが単独間接ブロックを参照する。この場合、４ＫＢの単独間接ブ ロックは、４ＫＢのデータブロックを参照する１０２４個のブロック番号からな る。図４Ｃは、１６個の単独間接ブロック４３０Ａ〜４３０Ｃを参照する１６個 のブロック番号３１０Ｂからなるレベル２のｉノード３１０を表す。図４Ｃに示 すように、ブロック番号エントリ０は、単独間接ブロック４３０Ａを指す。単独 間接ブロック４３０Ａは、４ＫＢのデータブロック４４０Ａ〜４４０Ｃを参照す る１０２４個のブロック番号からなる。同様に、各単独間接ブロック４３０Ｂ〜 ４３０Ｃは、１０２４個までのデータブロックをアドレスできる。 ６４ＭＢ以上の大きさのファイルに関しては、ｉノード中の１６個のブロック 番号が、２重間接ブロックを参照する。それぞれ４ＫＢの２重間接ブロックは、 対応する単独間接ブロックを指す１０２４個のブロック番号からなる。この場合 、 各単独間接ブロックは、４ＫＢデータブロックを指す１０２４個のブロック番号 からなる。このようにして、６４ＧＢまでのアドレスが可能である。図４Ｄは、 ブロック番号エントリ０、１および１５が、２重間接ブロック４７０Ａ，４７０ Ｂおよび４７０Ｃをそれぞれ参照する１６個のブロック番号３１０Ｂからなるレ ベル３のｉノード３１０を表す。２重間接ブロック４７０Ａは、単独間接ブロッ ク４８０Ａ〜４８０Ｂを指す１０２４個のブロック番号エントリ０〜１０２３か らなる。各単独間接ブロック４８０Ａ〜４８０Ｂは、この場合、１０２４個のデ ータブロックを参照する。図４Ｄに示すように、単独間接ブロック４８０Ａは１ ０２４個のデータブロック４９０Ａ〜４９０Ｃを参照し、単独間接ブロック４８ ０Ｂは、１０２４個のデータブロック４９０Ｃ〜４９０Ｆを参照する。メモリ内のＷＡＦＬｉノード 図８は、メモリ内（in core）のＷＡＦＬｉノード８２０を表すブロック図で ある。メモリ内のｉノード８２０は、（図３に示す）オンディスクｉノード３１ ０の情報、ＷＡＦＬバッファデータ構造８２０Ａおよび１６個のバッファポイン タ８２０Ｂからなる。メモリ内のＷＡＦＬｉノードは３００バイトの大きさを有 する。ＷＡＦＬバッファは、ディスクに保存されている４ＫＢブロックに相当す るメモリ内の４ＫＢである。メモリ内のｉノード８２０は、異なる間接度レベル を有するバッファを参照する従来のｉノードとは異なる。各のメモリ内のＷＡＦ Ｌｉノード８２０は、同一の間接度レベルを有する１６個のバッファを指す。バ ッファポインタは、４バイト長である。一つのｉノード８２０に含まれる全バッ ファポインタ８２０Ｂを同一の間接度レベルに保つことにより、ファイルシステ ムを簡単にできる。メモリ内のｉノード８２０は、また、リンクリスト用のポイ ンタ、整合点中（in-consistency）（ＩＮ＿ＣＰ）フラグおよび汚れフラグから なるメモリ内情報８２０Ｃを含む。汚れフラグは、ｉノード自体が変更されてい ること、または、汚れフラグが参照しているバッファが変更されたものであるこ とを示している。ＩＮ＿ＣＰフラグはｉノードが整合点（後で説明する）の中に あることをマークするために用いられる。リンクリスト用ポインタについて、以 下に述べる。 図１０は、ＷＡＦＬｉノード１０１０が参照するファイルを表す。このファイ ルは、間接ＷＡＦＬバッファ１０２０〜１０２４及び直接ＷＡＦＬバッファ１０ ３０〜１０３４からなる。ＷＡＦＬのメモリ内のｉノード１０１０は、標準ｉノ ード情報１０１０Ａ（汚れバッファの計数値を含む）、ＷＡＦＬバッファデータ 構造１０１０Ｂ、１６個のバッファポインタ１０１０Ｃおよび標準オンディスク ｉノード１０１０Ｄからなる。メモリ内のＷＡＦＬｉノード１０１０は、およそ ３００バイトの大きさを有する。オンディスクｉノードは１２８バイトの大きさ である。ＷＡＦＬバッファデータ構造１０１０Ｂは、１６個のバッファポインタ １０１０Ｃを参照する第１ポインタと、オンディスクブロック番号１０１０Ｄを 参照する第２ポインタとからなる。 各ｉノード１０１０は、参照する汚れバッファの計数値を持っている。ｉノー ド１０１０は、汚れｉノードのリストおよび／または汚れバッファを有するｉノ ードのリストに入れられる。一つのｉノードが参照する汚れバッファの全てがデ ィスクへの書込みが予定されているか、または、実際に書込まれている場合には 、ｉノード１０１０に対する汚れバッファの計数値が０にセットされる。そして 、ｉノード１０１０は、そのフラグ（つまり、汚れバッファがないこと）に従っ て、ふたたびキューされる。このｉノード１０１０は、次のｉノードが処理され る前に、クリアされる。さらに、ｉノードが整合点中にあることを示すｉノード のフラグがクリアされる。ｉノード１０１０自体が整合点においてディスクに書 き込まれる。 ＷＡＦＬバッファ構造は、間接ＷＡＦＬバッファ１０２０によって表される。 ＷＡＦＬバッファ１０２０は、ＷＡＦＬバッファデータ構造１０２０Ａと、１０ ２４個のＷＡＦＬバッファポインタからなる４ＫＢバッファ１０２０Ｂと、１０ ２４個のオンディスクブロック番号からなる４ＫＢバッファ１０２０Ｃからなる 。ＷＡＦＬバッファデータ構造は５６バイトの大きさを有するとともに、２つの ポインタからなる。ＷＡＦＬバッファデータ構造１０２０Ａのポインタの一つは 、４ＫＢバッファ１０２０Ｂを参照し、もう一つのポインタはバッファ１０２０ Ｃを参照する。図１０において、ＷＡＦＬｉノード１０１０の１６個のバッファ ポ インタ１０１０Ｃは、１６個の単独間接ＷＡＦＬバッファ１０２０〜１０２４を 指す。一方、ＷＡＦＬバッファ１０２０は、１０２４個の直接ＷＡＦＬバッファ 構造１０３０〜１０３４を参照する。ＷＡＦＬバッファ１０３０は、直接ＷＡＦ Ｌバッファを代表している。 直接ＷＡＦＬバッファ１０３０は、ＷＡＦＬバッファデータ構造１０３０Ａと 、対応するオンディスク４ＫＢデータブロックのキャッシュバージョンを含む４ ＫＢ直接バッファ１０３０Ｂとからなる。直接ＷＡＦＬバッファ１０３０は、間 接ＷＡＦＬバッファ１０２０のような４ＫＢバッファを有しない。ＷＡＦＬバッ ファデータ構造１０３０Ａの第２バッファポインタは、０にされ、第２の４ＫＢ バッファを指さない。これにより、メモリの非効率な使用を防止して、メモリ空 間が使われていないバッファに割り当てられないようにする。 図１０に示すように、ＷＡＦＬファイルシステムにおいて、ＷＡＦＬのメモリ 内のｉノード構造１０１０は、ＷＡＦＬバッファ構造１０２０〜１０２４および １０３０〜１０３４のツリーを参照する。これは、間接ブロックおよび／または 直接ブロックを指すブロック番号からなる標準ｉノードによって参照される、デ ィスク上のブロックツリーに類似している。このように、ＷＡＦＬｉノード１０ １０は、１６個のボリュームブロック番号からなるオンディスクｉノード１０１ ０ＤおよびＷＡＦＬバッファ構造１０２０〜１０２４および１０３０〜１０３４ を指す１６個のバッファポインタ１０１０Ｃからなる。ＷＡＦＬバッファ１０３ ０〜１０３４は、ボリュームブロック番号によって参照されたブロックのキャッ シュ成分を含む。 ＷＡＦＬインコード（in-code）ｉノード１０１０は１６個のバッファポイン タ１０１０Ｃを含む。次に、１６個のバッファポインタ１０１０Ｃは、ＷＡＦＬ バッファ１０２０〜１０２４および１０３０〜１０３４のツリーのルートである ＷＡＦＬバッファ構造１０１０Ｂによって参照される。このように、各ＷＡＦＬ ｉノード１０１０は、ｉノード１０１０中の１６個のバッファポインタ１０１０ Ｃを指すＷＡＦＬバッファ構造１０１０Ｂを含む。これにより、再帰的に実行さ れるバッファのツリーを処理するアルゴリズムが容易になる。仮にｉノード１０ １０中の１６個のバッファポインタ１０１０ＣがＷＡＦＬバッファ構造１０１０ Ｂによって表されないとしたら、バッファ１０２０〜１０２４及び１０３０〜１ ０３４のツリー全体を操作するための再帰的アルゴリズムの実施が困難になる。 図９Ａ〜図９Ｄは、異なるレベルの間接度を有するｉノードを表す。図９Ａ〜 図９Ｄに、間接度を示すために、簡単化された間接及び直接のＷＡＦＬバッファ が表される。しかし、図９のＷＡＦＬバッファは、対応する図１０の間接及び直 接のバッファを表すと理解されるべきである。６４バイト以下の小さなファイル に関しては、データは、１６個のバッファポインタの代わりにｉノード中に直接 に保存される。図９Ａは、図８に示されるｉノード８２０が１６個のバッファポ インタ８２０Ｂの代わりに６４バイトのデータ９２０Ｂからなるという点を除い て、レベル０のｉノード８２０はこのｉノード８２０と同一であることを表す。 それゆえ、追加のバッファが、非常に小さいファイルに対して割り当てられるこ とがない。 ６４ＫＢより小さいファイルに関しては、１６個のバッファポインタの各々が 、直接４ＫＢの直接ＷＡＦＬバッファを参照する。図９Ｂは１６個のバッファポ インタ８２０Ｂからなるレベル１のｉノード８２０を表す。バッファポインタＰ ＴＲ０〜ＰＴＲ１５は、対応する４ＫＢの直接ＷＡＦＬバッファ９２２Ａ〜９２ ２Ｃを指す。 ６４ＫＢ以上かつ６４ＭＢ以下の大きさのファイルに関しては、１６個のバッ ファポインタの各々が、単独間接ＷＡＦＬバッファを参照する。この場合、各４ ＫＢの単独間接ＷＡＦＬバッファは、４ＫＢ直接ＷＡＦＬバッファを参照する１ ０２４個のバッファポインタからなる。図９Ｃは、１６個の単独間接ＷＡＦＬバ ッファ９３０Ａ〜９３０Ｃを参照する１６個のバッファポインタ８２０Ｂからな るレベル２のｉノード８２０を表す。図９Ｃに示すように、バッファポインタＰ ＴＲ０は、単独間接ＷＡＦＬバッファ９３０Ａを指す。単独間接ＷＡＦＬバッフ ァ９３０Ａは、４ＫＢ直接ＷＡＦＬバッファ９４０Ａ〜９４０Ｃを参照する１０ ２４個のポインタからなる。同様に、単独間接ＷＡＦＬバッファ９３０Ｂ〜９３ ０Ｃは、それぞれ、１０２４個までの直接ＷＡＦＬバッファをアドレスできる。 ６４ＭＢ以上の大きなファイルに関しては、ｉノードの１６個のバッファポイ ンタが２重間接ＷＡＦＬバッファを参照する。各４ＫＢ２重間接ＷＡＦＬバッフ ァは、対応する単独間接ＷＡＦＬバッファを指す１０２４個のポインタからなる 。この場合、各単独間接ＷＡＦＬバッファは、４ＫＢ直接ＷＡＦＬバッファを指 す１０２４のポインタからなる。このように、６４ＧＢまでがアドレスできる。 図９Ｄは、ポインタＰＴＲ０、ＰＴＲ１およびＰＴＲ１５が、２重間接ＷＡＦＬ バッファ９７０Ａ、９７０Ｂおよび９７０Ｃをそれぞれ参照する１６個のポイン タ８２０Ｂを有するレベル３のｉノード８２０を表す。２重間接ＷＡＦＬバッフ ァ９７０Ａは、１０２４個の単独間接ＷＡＦＬバッファ９８０Ａ〜９８０Ｂを指 す１０２４個のポインタよりなる。次に、各単独間接ＷＡＦＬバッファ９８０Ａ 〜９８０Ｂは、１０２４個の直接ＷＡＦＬバッファを参照する。図９Ｄに示すよ うに、単独間接ＷＡＦＬバッファ９８０Ａは、１０２４個の直接ＷＡＦＬバッフ ァ９９０Ａ〜９９０Ｃを参照する。そして、単独間接ＷＡＦＬバッファ９８０Ｂ は、１０２４個の直接ＷＡＦＬバッファ９９０Ｄ〜９９０Ｆを参照する。ディレクトリ ＷＡＦＬシステムにおけるディレクトリは、二つの区分に分かれる４ＫＢブロ ックに保存される。図１４は、本発明におけるディレクトリブロック１４１０を 説明する。各ディレクトリブロック１４１０は、固定長ディレクトリエントリ構 造１４１２〜１４１４からなる第１区分１４１０Ａと、実際のディレクトリ名１ ４１６〜１４１８を含む第２区分１４１０Ｂとからなる。各ディレクトリエント リは、ファイルＩＤ（id）および作成（generation）を含む。この情報は、当業 界で周知であるので、図１４には示されない。ディレクトリブロックの第１区分 １４１０Ａ中の各エントリ１４１２〜１４１４は、第２区分１４１０Ｂ中に含ま れているその名を指すポインタを有している。さらに、各エントリ１４１２〜１ ４１４は、第２区分中に含まれているその名に依存するハッシュ値を含んでおり 、ハッシュがヒット（ハッシュマッチ）した時に限りその名前が検査される。例 えば、第１区分１４１０Ａのエントリ１４１２は、ハッシュ値１４１２Ａ及びポ インタ１４１２Ｂからなる。ハッシュ値１４１２Ａは、第２区分１４１０Ｂの可 変 長エントリ１４１６に保存されているディレクトリ名「ＤＩＲＥＣＴＯＲＹ＿Ａ ＢＣ」に依存する値である。エントリ１４１０のポインタ１４１２Ｂは、第２区 分１４１０Ｂの可変長エントリ１４１６を指す。第１区分１４１０Ａ中の固定長 ディレクトリエントリ１４１２〜１４１４を用いることによって、名前ルックア ップ処理が迅速になる。ディレクトリブロック１４１０中の、次のエントリを見 付け出すための操作は不要である。さらに、第１区分１４１０Ａ中のエントリ１ ４１２〜１４１４を小さく保持することにより、ラインフィルデータキャッシュ を有するファイルシステムのヒット速度が改善される。メタデータ ＷＡＦＬは、メタデータとして知られている、ファイル中にファイルシステム を記述する情報を保持している。メタデータは、ｉノードファイル、ｉノードマ ップファイルおよびブロックマップファイルからなる。ＷＡＦＬは、メタデータ を、ディスクの任意の場所に（anywhere）書込まれる可能性のあるファイルに保 存する。全てのＷＡＦＬメタデータは、ファイルの中に保持されているので、正 にファイルシステム中の他のファイルと同様に、任意の場所に書込むことができ る。 第１のメタデータファイルは、ファイルシステムにおける他の全てのファイル を記述するｉノードを含む「ｉノードファイル」である。図１２は、ｉノードフ ァイル１２１０を表した図である。ｉノードファイル１２１０は、ディスクの定 められた場所に「ｉノードテーブル」を書き込む従来のシステムとは異なり、デ ィスクの任意の場所に書込むことが出来る。ｉノードファイル１２１０は、ｉノ ードファイル１２１０自体を除いて、ファイルシステム中の各ファイルに対する ｉノード１２１０Ａ〜１２１０Ｆを含む。ｉノードファイル１２１０は、「ルー トｉノード」として参照されるｉノードによって指される。ルートｉノードは、 後述するファイルシステム情報（ｆｓｉｎｆｏ）ブロックとして参照されるディ スク上の定められた場所に保持される。ｉノードファイル１２１０自体は、ディ スク上の４ＫＢブロック（またはメモリ中の４ＫＢバッファ）中に保存される。 図１２は、ｉノード１２１０Ａ〜１２１０Ｃが４ＫＢバッファ１２２０中に保存 されていることを表している。１２８バイトの大きさを有するオンディスクｉノ ー ドに関しては、４ＫＢバッファ（またはブロック）は、３２個のｉノードよりな る。メモリ内のｉノードファイル１２１０は、ＷＡＦＬバッファ１２２０からな る。一つのメモリ内のｉノード（つまり１２１０Ａ）がロードされた時には、メ モリ内ｉノード１２１０Ａのオンディスクｉノード部分が、ｉノードファイル１ ２１０のバッファ１２２０のためにコピーされる。バッファデータ自体は、ディ スクからロードされる。逆の順番で、ディスクにデータが書き込まれる。オンデ ィスクｉノードのコピーであるメモリ内のｉノード１２１０Ａが、ｉノードファ イル１２１０の対応バッファ１２２０にコピーされる。そして、ｉノードファイ ル１２１０が、書き込み割り当てされると共に、ｉノードファイル１２１０のバ ッファ１２２０中にデータが保存される。 他のメタデータファイルは、「ブロックマップ」（ｂｌｋｍａｐ）ファイルで ある。図１１Ａは、一つのブロックマップファイル１１１０を表す。ブロックマ ップファイル１１１０は、ディスクシステム中の各４ＫＢブロックに対する３２ ビットエントリ１１１０Ａ〜１１１０Ｃを含む。これは、また、フリーブロック マップファイルとして用いられる。ブロックマップファイル１１１０は、一つの ディスクブロックが割り当てられたか否かを示す。図１１Ｂは、ブロックマップ ファイル１１１０（図１１Ａに示す）の一ブロックエントリ１１１０Ａの図であ る。図１１Ｂに示すように、エントリ１１１０Ａは、３２ビット（ビット０〜ビ ット３１）からなる。エントリ１１１０Ａのビット０は、アクティブなファイル システムビット（ＦＳビット）である。エントリ１１１０ＡのＦＳビットは、対 応するブロックがアクティブなファイルシステムの一部であるか否かを示す。エ ントリ１１１０Ａのビット１〜２０は、ブロックが対応するスナップショット１ 〜２０の一部であるか否かを示すビットである。次の上位１０ビット（ビット２ １〜ビット３０）は予約されている。ビット３１は、エントリ１１１０Ａの整合 点ビット（ＣＰビット）である。 ブロック用の３２ビットエントリ１１１０Ａ中の全てのビット（ビット０〜ビ ット３１）がクリアになっている（０の値に設定される）時には、そのファイル システムにおいて、一つのブロックがフリーブロックとして有効である。図１１ Ｃ は、ディスクブロックがフリーであることを示す図１１Ａのエントリ１１１０Ａ を表す。このように、ビット０〜３１の全てがゼロの値を有する時は、ブロック マップファイル１１１０のエントリ１１１０Ａによって参照されたブロックはフ リーである。図１１Ｄは、アクティブなファイルシステムにおける割り当てられ たブロックの全てを示す図１１Ａのエントリ１１１０Ａを表す。ＦＳビットとし て参照されるビット０が１の値に設定されている時は、ブロックマップファイル １１１０のエントリ１１１０Ａは、アクティブなファイルシステムの一部である ブロックを示している。ビット１〜ビット２０は、もし在る場合には、ブロック を参照する対応スナップショットを示すために用いる。スナップショットについ ては、後で詳細に述べる。仮にビット０が０の値に設定されても、必ずしもブロ ックが割り当て可能であること示すものではない。ブロックを割り当てるために は、全スナップショットビットがゼロでなければならない。しかし、整合点の一 部として記録すべくメモリビット３１にロードされた時には、エントリ１１１０ Ａのビット３１は、常にディスク上のビット０と同じ状態を有する。 その他のメタデータファイルは、フリーｉノードマップとして利用される「ｉ ノードマップ」（ｉｎｏｍａｐ）である。図１３Ａは、一つのｉノードマップフ ァイル１３１０を表す。ｉノードマップファイル１３１０は、図１２に示される ｉノードファイル１２１０中の各ブロック用の８ビットエントリ１３１０Ａ〜１ ３１０Ｃを含む。各エントリ１３１０Ａ〜１３１０Ｃは、ｉノードファイル１２ １０の対応ブロック中の割り当てられたｉノードの計数値である。図１３Ａは、 エントリ１３１０Ａ〜１３１０Ｃ中の、それぞれの値３２、５および０を示す。 ｉノードファイル１２１０は、まだ、ブロック中のどのｉノードがフリーである かを調べなければならない。しかし、多数のランダムブロックをディスクからメ モリにロードする必要はない。ｉノードファイル１２１０の各４ＫＢブロック１ ２２０は、３２個のｉノードを保持する。それゆえに、ｉノードファイル１２１ ０の各ブロック用の８ビットのｉノードマップエントリ１３１０Ａ〜１３１０Ｃ は、０から３２の範囲の値を有することができる。ｉノードファイル１２１０の ブロック１２２０が、使用中のｉノードを有しない時は、そのｉノードマップフ ァイル １３１０中のエントリ１３１０Ａ〜１３１０Ｃはゼロである。ブロック１２２０ のｉノードファイル１２１０中の全てのｉノードが使用中である時には、ｉノー ドマップファイル１３１０のエントリ１３１０Ａ〜１３１０Ｃは、値３２を有す る。 図１３Ｂは、ｉノードファイル１３４０の４ＫＢブロック１３４０Ａ〜１３４ ０Ｃを参照するｉノードマップファイル１３５０を表す。例えば、ｉノードファ イル１３４０は、３個の４ＫＢブロック１３４０Ａ〜１３４０Ｃ中に、３７個の ｉノードを保存する。ｉノードファイル１３４０のブロック１３４０Ａ〜１３４ ０Ｃは、それぞれ３２、５および０の使用されたｉノードを含む。ブロックマッ プファイル１３５０のエントリ１３５０Ａ〜１３５０Ｃは、それぞれ、ｉノード ファイル１３４０のブロック１３４０Ａ〜１３４０Ｃを参照する。このように、 ｉノードマップファイルのエントリ１３５０Ａ〜１３５０Ｃは、ｉノードファイ ル１３４０のブロック１３４０Ａ〜１３４０Ｃ用として、それぞれ、３２、５お よび０の値を有している。一方、ｉノードマップファイルのエントリ１３５０Ａ 〜１３５０Ｃは、それぞれ、ｉノードファイル１３４０のブロック１３４０Ａ〜 １３４０Ｃの０、２７および３２のフリーのｉノードを示している。 図１３に示すように、計数値の代わりにｉノードマップファイル１３１０のエ ントリ１３１０Ａ〜１３１０Ｃ用のビットマップを用いることは、不利である。 何故ならば、ｉノードファイル１２１０（図１２に示す）のブロック１２２０用 のエントリ１３１０Ａ〜１３１０Ｃ当たり、１バイトでは無く４バイトが必要で あるからである。ｉノードファイル１２１０のブロック１２２０中のフリーｉノ ードは、ｉノードマップファイル１３１０中に示す必要がない。なぜならば、ｉ ノード自体がそのような情報を含んでいるからである。 図１５は、ファイルシステム情報（fsinfo）構造１５１０を表す。ファイルシ ステムのルートｉノード１５１０Ｂは、ディスク上の定められた場所に保持され て、ファイルシステムのブート中に位置が分かるようにされている。ファイルシ ステム情報ブロックは、メタデータではないが、ＷＡＦＬシステムの一部である 。ルートｉノード１５１０Ｂは、ｉノード１２１０を参照するｉノードである。 そ れは、ファイルシステム中のブロックの番号、ファイルシステムの作成時間等を 含む情報１５１０Ａを含むファイルシステム情報構造の一部である。この種々の 情報１５１０Ａは、さらに、チェックサム１５１０Ｃ（後に述べる）からなる。 別の実施例において、ルートｉノード１５１０Ｂ自体を除いて、この情報１５１ ０Ａは、メタデータファイル中に保持することができる。ファイルシステム情報 構造１５１０の２つの同一コピーは、ディスク上の定められた場所に保持される 。 図１６は、ディスク上で整合状態にあるＷＡＦＬファイルシステム１６７０を 表し、このファイルシステムは、二つのファイルシステム情報ブロック１６１０ および１６１２、ｉノードファイル１６２０、ブロックマップファイル１６３０ 、ｉノードマップファイル１６４０、ルートディレクトリ１６５０および典型的 なファイル（またはディレクトリ）１６６０からなる。ｉノードファイル１６２ ０は、ファイルシステム１６７０中の他のファイル１６３０〜１６６０を参照す る複数のｉノード１６２０Ａ〜１６２０Ｄからなる。ｉノードファイル１６２０ のｉノード１６２０Ａは、ブロックマップファイル１６３０を参照する。ｉノー ド１６２０Ｂは、ｉノードマップファイル１６４０を参照する。ｉノード１６２ ０Ｃは、ルートディレクトリ１６５０を参照する。ｉノード１６２０Ｄは、典型 的なファイル（またはディレクトリ）１６６０を参照する。このように、ｉノー ドファイルは、ファイルシステム情報ブロック１６１０および１６１２を除くフ ァイルシステム１６７０中の全てのファイル１６３０〜１６６０を指す。ファイ ルシステム情報ブロック１６１０および１６１２は、それぞれ、ｉノードファイ ル１６２０のｉノードのコピー１６１０Ｂおよび１６１２Ｂを含む。ファイルシ ステム情報ブロック１６１０及び１６１２のルートｉノード１６１０Ｂおよび１ ６１２Ｂは、全メタデータ１６３０〜１６４０を含むファイルシステム１６７０ 中の残りのファイル１６３０〜１６６０を記述するｉノードファイル１６２０を 記述している。したがって、ルートｉノード１６１０Ｂおよび１６１２Ｂは、ブ ロックのツリーのルートとみなされる。ＷＡＦＬシステム１６７０は、このツリ ー構造をその更新方法（整合点）用に、そしてスナップショットを実行するため に用いる。これらについては後述する。汚れブロックを有するｉノードのリスト ＷＡＦＬファイルシステムのメモリ内のｉノード（すなわち、図１０に示すＷ ＡＦＬｉノード１０１０）は、それぞれの状態に応じた異なるリンクリストに保 持されている。ｉノードには、図２に示すように、汚れブロックを参照するｉノ ードが、汚れｉノードリストに保持されている。汚れていないバリッドデータを 含むｉノードは、別のリストに保持される。そして、非バリッドデータを有する ｉノードは、別に保持される。これらは、当業界において公知である。本発明は 、汚れデータブロックを有するｉノードのリストを利用して、実行すべき書き込 み割り当てを必要とする全てのｉノードを見つけることを容易にする。 図２は、本発明による汚れｉノードのリスト２１０を表す。汚れｉノードのリ スト２１０は、ＷＡＦＬのメモリ内のｉノード２２０〜１７５０からなる。図１ ７に示すように、ＷＡＦＬのメモリ内の各ｉノード２２０〜２５０は、それぞれ 、リンクリスト中の他のｉノードを指すポインタ２２０Ａ〜２５０Ａからなる。 たとえば、ＷＡＦＬｉノード２２０〜２５０は、それぞれ、メモリ中の位置２０ ４８、２１５２、２８７８、３４４８および３７１２に保存される。このように して、ｉノード２２０のポインタ２２０Ａはアドレス２１５２を含む。したがっ て、ＷＡＦＬｉノード２２２が指される。次に、ＷＡＦＬｉノード２２２は、ア ドレス２８７８を用いるＷＡＦＬｉノードを指す。ＷＡＦＬｉノード２３０は、 ＷＡＦＬｉノード２４０を指す。ＷＡＦＬｉノード２４０は、ｉノード１７５０ を指す。ＷＡＦＬｉノード２５０のポインタ２５０Ａはヌル値を含み、したがっ て、他のｉノードを指さない。このように、それは、汚れｉノードのリスト２１ ０中の最後のｉノードである。リスト２１０中の各ｉノードは、図１０に描かれ たように、バッファツリーからなるファイルを表している。各ｉノード２２０〜 ２５０によって参照されるブロックの少なくとも一つは、汚れバッファである。 汚れバッファは、ＷＡＦＬシステムにおいて、新しいディスクの位置に書き込ま ねばならない変更されたデータを含んでいる。ＷＡＦＬは、常に汚れバッファを ディスク上の新しい位置に書き込む。整合点 今まで説明してきたＷＡＦＬディスク構造は、静的である。本発明において、 ファイルシステム１６７０への変化は、ファイルシステム１６７０を整合状態に 保つために、強く制御される。ファイルシステム１６７０は、１つの自己整合状 態から他の自己整合状態へ進む。ルートｉノード１５１０Ｂによりルートされる ディスク上の自己整合ブロックの集合（またはツリー）は、整合点（ＣＰ）とい う。整合点を提供するため、ＷＡＦＬは、常に、新しいデータをディスク上の割 り当てられていないブロックに書く。ＷＡＦＬは、存在しているデータを上書き することはない。こうして、ルートｉノード１５１０Ｂが更新されないかぎり、 ディスクで表されるファイルシステム１６７０の日付は変わらない。しかし、フ ァイルシステム１６７０が有用であるためには、ファイルシステムは、常に、新 しく書込まれたデータを参照せねばならず、したがって、新しい整合点が書込ま れねばならない。 図１６を参照すると、新しい整合点は、まずすべてのファイルシステムブロッ ク（ｉノードファイル１６２０、ブロックマップファイル１６３０、ｉノードマ ップファイル１６４０などのメタデータファイルにおけるブロックを含む）をデ ィスク上の新しい位置にフラッシュ（flush）することにより、書込まれる。フ ァイルシステム１６７０のための新しいルートｉノード１６１０Ｂ、１６１２Ｂ は、次に、ディスクに書込まれる。ファイルシステムを原子的に更新するこの方 法を用いると、オンディスクファイルシステムは、決して整合的でない。このオ ンディスクファイルシステム１６７０は、ルートｉノード１６１０Ｂ、１６１２ Ｂが書込まれるまで、古い整合点を反映する。ルートｉノード１６１０Ｂ、１６ １２Ｂが書込まれた後にすぐに、ファイルシステム１６７０は新しい整合点を反 映する。ファイルシステム１６７０のデータ構造は、任意の順序に更新でき、ル ートｉノード１６１０Ｂ、１６１２Ｂが更新される前にファイルシステム１６７ ０内の全ブロックがディスクに書込まれねばならないという１つの条件を除いて 、ディスクへのデータの書込みについて順序の条件はない。 新しい整合点に変換するため、ルートｉノード１６１０Ｂ、１６１２Ｂは、信 頼できるようにまた原子的に更新されねばならない。ルートｉノード１６１０Ｂ 、１６１２Ｂを含むファイルシステム情報構造１６１０、１６１２の２つの同一 のコピーを保持することにより、ＷＡＦＬは、これを実行する。ルートｉノード １６１０Ｂ、１６１２Ｂを更新する間、ファイルシステム情報構造１６１０の第 １のコピーは、ディスクに書込まれ、次に、ファイルシステム情報構造１６１２ の第２のコピーが書込まれる。ファイルシステム情報構造１６１０、１６１２に おけるチェックサム１６１０Ｃ、１６１２Ｃは、それぞれ、ディスクに書込まれ るとき、ｉノードのコピーをそれぞれ含むファイルシステム情報構造１６１０、 １６１２のコピーの１つを破壊するシステムクラッシュの発生を検知するために 使用される。通常は、この２つのファイルシステム情報構造１６１０、１６１２ は同一である。整合点を作成するアルゴリズム 図５は、整合点を作成する方法を説明する。ステップ５１０において、システ ムにおけるすべての「汚れ」ｉノード（変更されたデータを含む新しいブロック を指すｉノード）は、その内容が、またその内容のみがディスクに書込まれる整 合点にあるとしてマークされる。これらの書込みが完全であるときにのみ、他の ｉノードからの書込みがディスクに達することを許される。さらに、汚い書込み が発生している間、新しい変更は、整合点にあるｉノードに対して行うことがで きない。 整合点の１部であるすべての汚れｉノードに整合点フラグを立てることに加え て、グローバル整合点フラグが、使用者が要求する変化が強く制御された形で起 こるように立てられる。グローバル整合点フラグが立てられると、使用者が要求 する変化は、整合点にあるｉノードに影響することを許されない。さらに、整合 点フラグが立てられたｉノードのみが、その汚れブロックに対してディスク空間 を割り当てられる。その結果、ファイルシステムの状態は、整合点が始まるとき に存在したように、ディスクに正確にフラッシュされる。 ステップ５２０において、正規の（regular）ファイルがディスクにフラッシ ュされる。この正規のファイルのフラッシュは、正規のファイルの中の汚れブロ ッ クのためのディスク空間を割り当てるステップと、対応するＷＡＦＬバッファを ディスクに書込むステップからなる。ｉノードそれ自体は、次にｉノードファイ ルにフラッシュ（コピー）される。書込まれることが必要なすべてのｉノードが 、汚れバッファを有するｉノードのリスト、または、汚いｉノードであるが汚れ バッファを有しないｉノードのリストのいずれかに存在する。ステップ５２０が 終わったとき、整合点には通常のｉノードはもはや存在せず、入ってくるすべて のＩ／Ｏ要求は、ディスクＩ／Ｏ操作のためになおロックされているバッファを 使用しないなら、これらの要求はうまくいく。 ステップ５３０において、特別なファイルがディスクにフラッシュされる。こ の特別なファイルのフラッシュは、２つの特別なファイル、ｉノードファイルと ブロックマップファイル、における汚れブロックに対してディスク空間を割り当 てるステップ、整合点を更新してブロックマップファイルにおける各エントリに 対しアクティブなファイルシステムビット（ＦＳビット）を調和させるステップ 、および、ブロックをディスクに書込むステップからなる。ｉノードファイルと ブロックマップファイルを割り当てる書込みは、それらを割り当てる書込みの過 程がそれらのファイル自体を変化するので、複雑である。そうして、ステップ５ ３０において、変化が終わる前にディスクＩ／Ｏ操作において重要なブロックが ロックされるのを防止するために、これらのファイルを変える間は、書込みは、 ディスエーブルにされる。 また、ステップ５３０において、ファイルシステム情報ブロックを除いて、フ ァイルシステムが完全に自己整合性がありディスクに書込まれようとする唯一の 時点であるので、スナップショットの作成と除去（後で説明する）がおこなわれ る。同じスナップショットｉノードが１つのパスで使用できるように、１つのス ナップショットは、新しいものが作成される前に、ファイルシステムから除去さ れる。 図６は、ステップ５３０に含まれるステップを示す流れ図である。ステップ５ ３０は、ディスク空間をブロックマップファイルとｉノードファイルに割り当て 、ブロックマップファイルにおける各エントリに対してアクティブなＦＳビット をＣＰビットにコピーする。ステップ６１０において、ブロックマップファイル の ためのｉノードは、ｉノードファイルにあらかじめフラッシュされる。このこと は、ブロックマップファイルのｉノードを含むｉノードファイルにおけるブロッ クが汚くてステップ６２０がそのブロックにディスク空間を割り当てることを保 証する。 ステップ６２０において、ディスク空間は、ｉノードとブロックマップファイ ルにおけるすべての汚れブロックに対して割り当てられる。この汚れブロックは 、ブロックマップファイルの汚れｉノードを含むｉノードファイルにおけるブロ ックを含む。 ステップ６３０において、ブロックマップファイルのためのｉノードがふたた びフラッシュされるが、しかし、今回は、実際のｉノードが、ｉノードファイル における前記のまえもってフラッシュされたブロックに書込まれる。ステップ６ １０は、ブロックマップファイルのｉノードを含むｉノードファイルのブロック をすでに汚くしている。こうして、ステップ６２０におけるように、もう１つの 書込み割り当ては、スケジュールされる必要がない。 ステップ６４０において、ブロックマップファイルにおける各ブロックのため のエントリが更新される。各エントリは、ブロックマップファイルにおける汚れ ブロックにおける全エントリに対してアクティブなＦＳビットをＣＰビットにコ ピーする（すなわち、ビット０をビット３１にコピーする）ことにより、更新さ れる。 ステップ６５０において、ブロックマップとｉノードファイルにおけるすべて の汚れブロックは、ディスクに書込まれる。 ブロックマップファイルの汚れブロックにおけるエントリのみが、ステップ６ ４０において、アクティブなファイルシステムビット（ＦＳビット）を整合点ビ ット（ＣＰビット）にコピーさせる必要がある。整合点のすぐ後で、すべてのブ ロックマップエントリがアクティブなＦＳビットとＣＰビットの両方について同 じ値を有する。時間が進むにつれ、ファイルシステムのブロックマップファイル エントリのいくつかのアクティブなＦＳビットがクリアされるか、セットされる 。変化されたＦＳビットを含むブロックマップファイルのブロックは、したがっ て、 汚いとマークされる。次の整合点の間、クリーンであるブロックは、ふたたびコ ピーされる必要がない。クリーンなブロックは、前の整合点で汚くなく、また、 それらのブロック内においてそれ以後何も変わっていないので、コピーされない 。こうして、すべてのブロックマップエントリにおいて同じ値を有するアクティ ブなＦＳビットとＣＰビットとともにファイルシステムが始めに生成されるかぎ り、汚れブロックを有するエントリのみが各整合点において更新される必要があ る。 図５を参照して、ステップ５４０において、ファイルシステム情報（fsinfo） ブロックが更新され、次に、ディスクにフラッシュされる。ファイルシステム情 報ブロックは、ｉノードファイルについての新しいルートｉノードを書くことに より更新される。ファイルシステム情報ブロックは、２度書込まれる。はじめに １つの位置に書込まれ、次に、第２の位置に書込まれる。この２つの書込みは、 システムクラッシュが書込みの間に起きたときに自己整合的なファイルシステム がディスク上に存在するように、行われる。したがって、もし第２のファイルシ ステム情報ブロックを書いている間にシステムがクラッシュしたならば、新しい 整合点が存在し、または、もし第１のファイルシステム情報ブロックが故障した なら、（最近の整合点が始まる前のディスク上の）前の整合点が存在する。ファ イルの故障の後でファイルシステムが再スタートされるとき、正しいチェックサ ム値を有するファイルシステム情報ブロックにおける整合点のための最高の作成 （generation）計数値が使用される。これは後で詳細に説明される。 ステップ５５０において、整合点が完成される。このことは、汚れｉノードが 整合点の１部でなかったために遅延された当該整合点がふたたびキューされるこ とを要求する。整合点の間に状態が変化されたｉノードは、整合点ウエイト（Ｃ Ｐ＿ＷＡＩＴ）キューにある。ＣＰ＿ＷＡＩＴキューは、ステップ５４０が終わ る前で、かつ、整合点がスタートしたステップ５１０の後で変化したｉノードを 保持する。整合点が終わると、ＣＰ＿ＷＡＩＴキューにおけるｉノードは、汚れ バッファを有するｉノードの通常のリストと、汚れバッファを持たない汚れｉノ ードのリストにおいて、ふたたびキューされる。整合性の単一の順序づけの条件 図２０Ａ〜図２０Ｃに示されるように、本発明は、単一の順序づけの条件を有 する。この単一の順序づけの条件は、すべての他のブロックがディスクに書込ま れた後でのみファイルシステム情報ブロック１８１０がディスクに書込まれると いうことである。ファイルシステム情報ブロック１８１０の書込みは、原子的で あり、そうでないと、全体のファイルシステム１８３０は、失われるであろう。 こうして、ＷＡＦＬファイルシステムは、ファイルシステム情報ブロック１８１ ０が１度に、整合状態においてでなく書込まれることを要求する。図１５に示す ように、各ファイルシステム情報ブロック１８１０（１５１０）は、チェックサ ム１５１０Ｃと作成計数値１５１０Ｄを含む。 図２０Ａは、ファイルシステム情報ブロック１８１０、１８７０の作成計数値 １８１０Ｄ、１８７０Ｄの更新を説明する。整合点（またはスナップショット） が行われるたびに、ファイルシステム情報ブロックの作成計数値が更新される。 図２０Ａは、ファイルシステムの整合点を示す同じ値Ｎをそれぞれ有する作成計 数値１８１０Ｄ、１８７０Ｄを有する２つのファイルシステム情報ブロック１８ １０、１８７０を示します。２つのファイルシステム情報ブロックは、前の整合 点（ディスク上の古いファイルシステム）１８３０を参照する。ファイルシステ ムの新しいバージョンは、ディスク上に存在し、新しい整合点１８３１として参 照される。作成計数値は、整合点ごとにインクリメントされる。 図２０Ｂにおいて、第１のファイルシステム情報ブロック１８１０の作成計数 値１８１０Ｄは更新され、Ｎ＋１の値を与えられる。これは、次にディスクに書 込まれる。図２０Ｂは、ファイルシステム情報ブロック１８１０の作成計数値１ ８１０Ｄの値Ｎ＋１を示すが、第２のファイルシステム情報ブロック１８７０の 作成計数値１８７０Ｄは、値Ｎを有する。ファイルシステム情報ブロック１８１ ０は、新しい整合点１８３１を参照するが、これに対し、ファイルシステム情報 ブロック１８７０は、古い整合点１８３０を参照する。次に、図２０Ｃに示すよ うに、ファイルシステム情報ブロック１８７０の作成計数値１８７０Ｄが更新さ れ、ディスクに書込まれる。図２０Ｃにおいて、ファイルシステム情報ブロック １８７０の作成計数値１８７０Ｄは、値Ｎ＋１を有する。したがって、この２つ のファイルシステム情報ブロック１８１０と１８７０は、同じ作成計数値Ｎ＋１ を有する。 システムクラッシュがファイルシステム情報ブロックの更新（複数）の間で起 こるとき、ファイルシステム情報ブロック１８１０と１８７０の各コピーは、自 己整合チェックサム（図示しない）を有するが、作成計数値１８１０Ｄと１８７ ０Ｄの一方がより大きい値を有する。システムクラッシュは、ファイルシステム が図２０Ｂに示す状態にあるときに起こる。たとえば、図２０Ｂに示すように本 発明の好ましい実施例において、ファイルシステム情報ブロック１８１０の作成 計数値１８１０Ｄは、第２のファイルシステム情報ブロック１８７０の前に更新 される。したがって、作成計数値１８１０Ｄ（値１）は、ファイルシステム情報 ブロック１８７０の作成計数値１８７０Ｄより大きい。第１のファイルシステム 情報ブロック１８１０の作成計数値がより高いので、それは、システムクラッシ ュの後でファイルシステムを回復するために選択される。これは、第１のファイ ルシステム情報ブロック１８１０がその作成計数値１８１０Ｄにより示されるよ うにより新しいデータを含むためである。第１のファイルシステム情報ブロック が更新中にシステムクラッシュが起こったために壊れた場合は、ファイルシステ ム情報ブロックの他のコピー１８７０が、ファイルシステム１８３０を整合状態 に回復するために使用される。 ２つのファイル空間情報ブロック１８１０と１８７０を本発明において同時に 更新することはできない。したがって、ファイル空間情報ブロック１８１０と１ ８７０の少なくとも１つのコピーがファイルシステムにおいて存在する。このこ とは、システムが常に整合状態に回復されることを可能にする。 ＷＡＦＬは、特殊な再生過程を必要としない。これは、ロギング、オーダード ライト（順序だてられた書込み）、および、多くは、回復を伴うオーダードライ トを用いる従来技術と異なる。これは、ＲＡＩＤにより保護されるデータ破壊ま たはソフトウエアのみがＷＡＦＬファイルシステムを破壊できるからである。シ ステムが故障したときにデータを失うことを避けるために、ＷＡＦＬは、最新の 整合点の後で行われたすべての操作の非破壊トランザクションのログを保持でき る。このログは、ＷＡＦＬディスクフォーマットと完全に独立であり、操作がシ ステムクラッシュの間に失われるのを防ぐためにのみ必要である。しかし、ファ イルシステムの整合性を維持するために必要ではない。整合点の作成 先に説明したように、ＷＡＦＬファイルシステムへの変化は、ファイルシステ ムを整合状態に維持するために強く制御される。図１７Ａ〜図１７Ｈは、ＷＡＦ Ｌファイルシステムに対しての整合点の作成を示す。整合点の作成は、図５と図 ６を参照して説明される。 図１７Ａ〜図１７Ｈにおいて、変更されなかったバッファは、その側にアスタ リスクを有しない。したがって、バッファは、オンディスクブロックに対応する のと同じデータを含む。こうして、ブロックは、メモリにロードできるが、その オンディスクバージョンに関して変化されていない。１つのアスタリスク（*） を側に持つバッファは、メモリにおける汚れバッファを指す（そのデータが変更 される）。２重のアスタリスク（**）を側に持つバッファは、ディスク空間に割 り当てられている汚れバッファを指す。最後に、３重のアスタリスク（***）を 側に持つバッファは、ディスク上の新しいブロックに書込まれる汚れバッファで ある。バッファの状態を表すこの方法は、図２１Ａ〜図２１Ｅにおいても用いら れる。 図１７Ａは、ｉノード２３０６Ａと２３０６Ｂからなる汚れバッファを持つｉ ノードのリスト２３９０を示す。ｉノード２３０６Ａと２３０６Ｂは、バッファ のツリー（複数）を参照する。ここで、各ツリーの少なくとも１つのバッファは 変更されている。初めに、ｉノード２３０６Ａと２３０６Ｂの整合点フラグ２３ ９１と２３９２がクリアされる（０）。本システムについての汚れバッファを持 つｉノードのリスト２３９０が示されるが、当業者に明らかであるが、ｉノード の他のリスト（複数）もメモリに存在してもよい。たとえば、汚れｉノードであ るが、汚れバッファを持たないｉノードのリストがメモリに維持される。また、 これらのｉノードは、整合点にあるとしてマークされねばならない。これらは、 汚れｉノードが汚れブロックを参照しないけれども、ｉノードファイルの汚れコ ンテンツをディスクに書くために、ディスクに対しフラッシュされねばならない 。これは、図５のステップ５２０でなされる。 図１７Ｂは、ファイルシステム情報ブロック２３０２、ｉノードファイル２３ ４６、ブロックマップファイル２３４４およびファイル２３４０、２３４２から なる前の整合点のＷＡＦＬファイルシステムを表す。ファイル２３４０は、それ ぞれデータ「Ａ」、「Ｂ」、「Ｃ」を含むブロック２３１０〜２３１４からなる 。ファイル２３４２は、それぞれデータ「Ｄ」、「Ｅ」、「Ｆ」を含むブロック ２３１６〜２３２０からなる。ブロックマップファイル２３４４はブロック２３ ２４からなる。ｉノードファイル２３４６は、２つの４ＫＢブロック２３０４と ２３０６からなる。第２のブロック２３０６は、ファイル２３４０、ファイル２ ３４２およびブロックマップファイル２３４４をそれぞれ参照するｉノードファ イル２３０６Ａ〜２３０６Ｃからなる。これは、ｉノードにおけるファイル番号 をリストすることによりブロック２３０６において示される。ファイルシステム 情報ブロック２３０２は、ルートｉノードからなる。このルートｉノードは、ｉ ノードファイル２３４６のブロック２３０４と２３０６を参照する。こうして、 図１７Ｂは、ルートｉノードを含むファイルシステム情報ブロック２３０２によ りルートされるファイルシステムにおけるバッファのツリーを示す。 図１７Ｃは、メモリにおけるブロック２３１４と２３２２のための２つの変更 されたバッファを説明する。アクティブなファイルシステムは、データ「Ｃ」を 含むブロック２３１４がファイル２３４０から除去されるように、変更される。 また、ブロック２３２０に格納されるデータ「Ｆ」は、「Ｆプライム」に変更さ れ、ディスクブロック２３２２のためのバッファに格納される。ディスクブロッ ク２３１４と２３２２のためのバッファに含まれる変更されるデータは、この時 点でメモリにおいてのみ存在する。図１７Ｃにおけるアクティブなファイルシス テムにおける全ての他のブロックは、変更されず、したがって、そのそばにアス タリスクを持たない。しかし、これらのブロックのいくつか、または、全ては、 メモリにおいて対応するきれいなバッファを持ってもよい。 図１７Ｄは、メモリにおけるブロックマップファイル２３４４のエントリ２３ ２４Ａ〜２３２４Ｍを説明する。エントリ２３２４Ａ〜２３２４Ｍは、ブロック マップファイル２３４４の４ＫＢブロック２３２４のためのバッファに含まれる 。前に説明したように、ビット０とビット３１は、それぞれ、ＦＳビットとＣＰ ビットである。整合点ビット（ＣＰビット）は、１つの整合点が始まったが終わ っていないときに対応するブロックが変更されないことを保証するために、整合 点の間、セットされる。ビット１は、第１スナップショットビット（後で説明す る）である。ブロックマップエントリ２３２４Ａと２３２４Ｂは、図１７Ｂに示 すように、ｉノードファイル２３４６の４ＫＢブロック２３０４と２３０６がア クティブなファイルシステムにあり（ＦＳビット＝１）、整合点にある（ＣＰビ ット＝１）を示す。同様に、他のブロック２３１０〜２３１２と２３１６〜２３ ２０と２３２４は、アクティブなファイルシステムにあり、整合点にあることを 示す。しかし、ブロック２３０８、２３２２および２３２６〜２３２８は、（ビ ット０とビット３１にそれぞれ示すように）アクティブなファイルシステムにも 整合点にもない。除去されたブロック２３１４のためのエントリは、ＦＳビット に値０を持ち、アクティブなファイルシステムから除かれたことを示す。 図５のステップ５１０において、システムにおけるすべての「汚れ」ブロック は、整合点にあるとしてマークされる。汚れｉノードは、汚れｉノードと、汚れ バッファを参照するｉノードの両方を含む。図１７１は、汚れバッファを持つｉ ノードのリストを示す。ここで、ｉノード２３０６Ａと２３０６Ｂの整合点フラ グ２３９１と２３９２はセットされる（１）。ｉノード２３０６Ａは、アクティ ブなファイルシステムから除去されるべきファイル２３４０のデータ「Ｃ」を含 むブロック２３１４を参照する。ｉノードファイル２３４２のブロック２３０６ のｉノード２３０６Ａは、ファイル２３４２を参照する。データ「Ｆ」を含むブ ロック２３２０は、変更されており、データ「Ｆ」を含む新しいブロックが割り 当てられねばならない。ステップ５１０において、汚れｉノード２３０６Ａと２ ３０６Ｂは、ブロック２３０８のためのバッファにコピーされる。ブロック２３ ０６のためのバッファは、続いてディスクに書込まれる（ステップ５３０）。こ れは、図１７Ｅに示される。変更されたデータは、メモリにおいてのみ存在し、 バッファ２３０８は汚いとマークされる。ｉノード２３０６Ａと２３０６Ｂの整 合点フラグ２３９１と２３９２は、図１７Ａに示すように、クリアされる（０） 。これは、これらのｉノードを他のプロセスによる使用のために解放する。 ステップ５２０において、正規のファイルはディスクにフラッシュされる。こ うして、ブロック２３２２はディスク空間に割り当てられる。ファイル２３４０ のブロック２３１４は、削除され、したがって、整合点が終わるまでこのブロッ クに対してなにも起こらない。ブロック２３２２は、ステップ５２０において、 ディスクに書込まれる。これらは、図１７Ｆにおいて示され、ここで、ブロック ２３２２と２３１４のためのバッファはディスクに書込まれる（***によりマー クされる）。ディスク空間の中間的割り当て（**）は示されない。ｉノードファ イル２３４６のブロック２３０８のｉノード２３０８Ａと２３０８Ｂは、ｉノー ドファイルにフラッシュされる。ブロック２３０８のｉノード２３０８Ａは、フ ァイル２３４６のブロック２３１０と２３１２を参照する。ｉノード２３０８Ｂ は、ファイル２３４２のためのブロック２３１６、２３１８、２３２２を参照す る。図１７Ｆに示すように、ディスク空間は、ｉノード２３４６のブロック２３ ０８と、ファイル２３４２のための直接ファイル２３２２について割り当てられ る。しかし、ファイルシステムそれ自体は、更新されない。こうして、ファイル システムは整合状態にとどまる。 ステップ５３０において、ブロックマップファイル２３４４は、ディスクにフ ラッシュされる。これは図１７Ｇに示され、ここで、ブロックマップファイル２ ３４４はアスタリスクにより汚いとして示される。 図６のステップ６１０において、ブロックマップファイルのためのｉノードは 、図１７Ｈに示されるように、ｉノードファイルにまえもってフラッシュされる 。ｉノード２３０８Ｃは、ｉノードファイル２３４６のブロック２３０６Ｂにフ ラッシュされている。しかし、ｉノード２３０８Ｃはなおブロック２３２４を参 照する。ステップ６２０において、ディスク空間は、ブロックマップファイル２ ３４４とｉノードファイル２３４６のために割り当てられる。ブロック２３０８ は、ｉノードファイル２３４６のために割り当てられ、ブロック２３２６は、ブ ロッ クマップファイル２３４４のために割り当てられる。上に説明したように、ｉノ ードファイル２３４６のブロック２３０８は、ブロックマップファイル２６４４ のためのまえもってフラッシュされたブロック２３０８Ｃを含む。ステップ６３ ０において、ブロックマップファイル２３４４のためのｉノードは、ｉノード２ ３４６における上記のまえもってフラッシュされたブロック２３０８Ｃに書込ま れる。こうして、メモリ内のｉノード２３０８Ｃは更新されて、ステップ６２０ においてブロック２３２４を参照し、ブロック２３０８に書込まれるべきブロッ ク２３０６を含むメモリ内のバッファにコピーされる。これは、図１７Ｈに示さ れ、ここで、ｉノード２３０８Ｃはブロック２３２６を参照する。 ステップ６４０において、ブロックマップファイル２３４４における各ブロッ ク２３０４〜２３２６のためのエントリ２３２６Ａ〜２３２６Ｌは、図１７Ｊに おいて更新される。図１７Ｂで整合点が始まってから変更していないブロックは 、それらのエントリにおいて同じ値を有する。エントリは、ビット０（ＦＳビッ ト）を整合点ビット（ビット３１）にコピーすることにより、更新される。ブロ ック２３０６は、アクティブなファイルシステムの１部ではない。したがって、 ビット０は０に等しい（ビット０は、ステップ６２０でｉノードファイルのその 部分に新しいデータを保持するようにブロック２３０８が割り当てらたときにオ フにされる）。これは、図１７Ｊにおいてエントリ２３２６Ｂについて示される 。同様に、ファイル２３４０のブロック２３１４のためのエントリ２３２６Ｆは ０に等しいビット０とビット３１を有する。ファイル２３４２のブロック２３２ ０とブロックマップファイル２３４４のブロック２３２４は、同様に、エントリ ２３６１と２３２６Ｋに示すように取り扱われる。ステップ６５０において、ｉ ノードファイル２３４６の汚れブロック２３０８とブロックマップファイル２３ ４４の汚れブロック２３２６は、ディスクに書込まれる。これは、図１７Ｋにお いて、ブロック２３０８と２３２６の側の３重アスタリスクにより示される。 図５を参照して、ステップ５４０において、ファイルシステム情報ブロック２ ３０２はディスクにフラッシュされ、これは２度行われる。こうして、図１７Ｌ において、ファイルスペース（fs）情報ブロック２３０２は、汚くされ、次に、 （３ 重アスタリスクにより示すように）ディスクに書込まれる。図１７Ｌにおいて、 単独のファイルスペース情報ブロック２３０２が示される。図に示すように、フ ァイルスペース情報ブロック２３０２は、いま、ｉノードファイル２３４６のブ ロック２３０４と２３０８を参照する。図１７Ｌにおいて、ブロック２３０６は 、もはやアクティブなファイル空間におけるｉノードファイル２３４６の１部で はない。同様に、ｉノードファイル２３４６のｉノード２３０８Ａにより参照さ れるファイル２３４０は、ブロック２３１０と２３１２からなる。ブロック２３ １４は、もはやこの整合点におけるファイル２３４０の１部ではない。ファイル ２３４２は、この新しい整合点においてブロック２３１６、２３１８および２３ ２２からなるが、ブロック２３２０はファイル２３４２の１部ではない。さらに 、ｉノードファイル２３４６のブロック２３０８は、ブロック２３２６からなる 新しいブロックマップファイル２３４４を参照する。 図１７Ｌに示すように、１つの整合点において、アクティブなファイルシステ ムは、新しいファイル２３４６のｉノードをファイルスペース情報ブロック２３ ０２にコピーすることにより、更新される。しかし、前の整合点のブロック２３ １４、２３２０、２３２４および２３０６はディスク上に残っている。これらの ブロックは、古い整合点１８３０と新しい整合点１８３１の両方が図２０におい てステップ５４０の間に存在することを保証するために、ファイルシステムを更 新するときに決して上書きされない。スナップショット ＷＡＦＬシステムは、スナップショットをサポートしている。スナップショッ トは、スナップショットが作成（generate）される瞬間の全ファイルシステムの 読出し専用コピーである。新たに作成されるスナップショットは、アクティブな ファイルシステムが指すものと同じディスクブロックを指す。したがって、それ は短時間に作成され、追加のディスク空間を消費することはない。アクティブな ファイルシステムにおけるデータブロックが変更されディスク上の新たな位置に 書き込まれる時にのみ、スナップショットは追加の空間を使用し始める。 ＷＡＦＬは、１から２０まで番号付けされた２０個までの異なるスナップショ ットをサポートする。したがって、ＷＡＦＬは、同一ファイルシステムの多重の 「クローン」の作成を可能にする。各スナップショットは、アクティブなファイ ルシステムがルートｉノードにより表わされるのと同様に、スナップショットｉ ノードにより表わされる。スナップショットは、ファイルシステムのルートデー タ構造を複製することにより作成される。好ましい実施例において、ルートデー タ構造はルートｉノードである。しかし、全ファイルシステムを表わすどのよう なデータ構造も使用することができる。スナップショットｉノードは、ｉノード ファイル中の固定位置に存在する。スナップショットの２０個の限界は、ブロッ クマップエントリの大きさにより決定されている。ＷＡＦＬは、新たなスナップ ショットＮの作成に２つのステップを必要とする。すなわち、ルートｉノードを スナップショットＮ用のｉノードにコピーし、ビット０をブロックマップファイ ルにある各ブロックマップエントリのビットＮにコピーする。ビット０は、ルー トｉノードの下のツリーが指すブロックを示す。 その結果は、ルートｉノードと全く同じディスクブロックを示すスナップショ ットｉノードＮによって確立された新たなファイルシステムツリーである。スナ ップショットにある各ブロックのブロックマップに対応するビットを設定すれば 、アクティブなファイルがスナップショットブロックを使用しなくなっても、ス ナップショットブロックの解放が防止される。ＷＡＦＬは新たなデータを未使用 のディスク位置に常に書き込むので、アクティブなファイルシステムが変わって も、ス ナップショットツリーは変わらない。新たに作成されたスナップショットツリー は、ルートｉノードと全く同じブロックを参照するので、新たなディスク空間は 使用されない。時間が経過すると、スナップショットは、別途解放されたディス クブロックを参照する。したがって、時間が経過すると、スナップショットとア クティブなファイルシステムが共有するブロックは徐々に少なくなり、スナップ ショットが使用する空間は増大する。スナップショットは、それが許容できない 数のディスクブロックを使用するようになると削除することができる。 アクティブなスナップショットのリストはスナップショットの名前とともに、 スナップショットディレクトリと呼ばれるメタデータファイルに格納される。デ ィスクの状態は上に記したように更新される。他の全ての変更とともに、ある整 合点より別の整合点に自動的に進むことにより、更新は行われる。変更されたブ ロックはディスク上の未使用位置に書き込まれ、その後に、更新されたファイル システムを記載した新たなルートｉノードが書き込まれる。スナップショットの概観 図１８Ａは、スナップショットが取り出される前のファイルシステム１８３０ を示し、ＷＡＦＬファイルシステムの概観をより簡単にするため、間接性のレベ ルは除かれている。ファイルシステム１８３０は、図１６のファイルシステム１ ６９０を示している。ファイルシステム１８３０はブロック１８１２〜１８２０ からなる。ｉノードファイルのｉノードは、ファイルシステム情報ブロック１８ １０に含まれる。ファイルシステム情報ブロック１８１０の一つのコピーしか図 １８Ａには示されていないが、ファイルシステム情報ブロックの第２のコピーも ディスク上にあるものと解釈すべきである。ファイルシステム情報ブロック１８ １０に含まれたｉノード１８１０Ａは、同一の間接性レベルの１６のブロックを 指す１６のポインタを有している。図１８Ａのブロック１８１２〜１８２０は、 直接ブロック、間接ブロック等を含むファイルシステム１８３０内の全てのブロ ックを示している。５個のブロック１８１２〜１８２０しか示されていないが、 各ブロックは他のブロックを指してもよい。 図１８Ｂは、スナップショットの作成を示す。スナップショットは、全ファイ ルシステム１８３０用に、ファイルシステム情報ブロック１８１０に格納されて いるｉノードファイルのｉノード１８１０Ａをスナップショットｉノード１８２ ２に単にコピーすることにより作成される。ｉノードファイルのｉノード１８１ ０Ａをコピーすることにより、アクティブなファイルシステムと同じファイルシ ステムを示すｉノードの新たなファイルが作成される。ｉノードファイルそれ自 体のｉノード１８１０Ａがコピーされるので、他のブロック１８１２〜１８２０ は２重にされる必要はない。コピーされたｉノードまたはスナップショットｉノ ード１８２２は、次に、ｉノードファイルにコピーされ、ｉノードファイルのブ ロックを汚す。一つまたはそれ以上の間接性レベルからなるｉノードファイルに 対し、各間接ブロックが順に汚される。ブロックを汚すこのプロセスは、全ての 間接性レベルを通して進む。ディスク上のｉノードファイルの各４キロバイトブ ロックは、３２のｉノードを含み、各ｉノードは１２８バイトの長さである。 図１８Ｂの新しいスナップショットｉノード１８２２は、スナップショット１ ８２２が取り出されると、ｉノードファイルのｉノード１８１０Ａにより参照さ れる最高レベルの間接性のブロック１８１２〜１８２０を指す。ｉノードファイ ルそれ自体は、ファイルシステム１８３０のスナップショットを含んでいるので 、再帰的構造である。各スナップショット１８２２は、ｉノードファイルにコピ ーされるｉノードファイルのｉノード１８１０Ａのコピーである。 図１８Ｃは、スナップショット１８２２が取り出された後、アクティブなファ イルシステム１８３０に変化が発生する時のアクティブなファイルシステム１８ ３０とスナップショット１８２２を示す。この図に示されるように、データ「Ｄ 」を有するブロック１８１８は、スナップショット１８２２が取り出された後に 変更されるので（図１８Ｂ）、データ「Ｄprime」を含む新たなブロック１８２ ４は、アクティブなファイルシステム１８３０用として割り当てられる。したが って、アクティブなファイルシステム１８３０はブロック１８１２〜１８１６と １８２０〜１８２４とを有するが、データ「Ｄ」を含むブロック１８１８を含ま ない。しかし、ＷＡＦＬシステムはディスク上のブロックに上書きしないので、 データ「Ｄ」を含むブロック１８１８は上書きされない。ブロック１８１８は、 ブ ロック１８１８用のブロックマップエントリに設定されているスナップショット ビットにより上書きされないよう保護されている。したがって、スナップショッ ト１８２２はなお、ブロック１８１２〜１８１６と１８２０と同様、未変更のブ ロック１８１８を指している。本発明は、図１８Ａ〜図１８Ｃに示されるように 、ファイルシステムの「クローン」を作成しクローンがディスク上のｉノードフ ァイルの全てのブロックのコピーである従来のシステムとは異なる。したがって 、従来技術のｉノードファイルの全内容が２重にされるので、ディスクＩ／Ｏ操 作にかなりの時間を必要とするばかりでなく、かなりの量（ＭＢ）のディスク空 間を必要とする。 図１８Ｃにおいてアクティブなファイルシステム１８３０は変更されるとき、 ブロック１８１２〜１８２０を有するファイルシステムは上書きされないので、 アクティブなファイルシステムはより多くのディスク空間を使用する。図１８Ｃ において、ブロック１８１８は直接ブロックとして示されている。しかし、実際 のファイルシステムにおいては、同様に間接ブロックによりブロック１８１８を 指してもよい。したがって、ブロック１８１８が変更され、ブロック１８２４と して新たなディスク位置に格納されると、対応する直接ブロックおよび間接ブロ ックもまたコピーされ、アクティブなファイルシステム１８３０に割り当てられ る。 図１９は、図１８Ｃのブロック１８２４に発生する変化を示す。図１８Ｃのブ ロック１８２４は、図１９において破線１８２４の内側に示されている。図１９ は、図１８Ｃのブロック１８２４に対するいくつかの間接性レベルを示している 。図１８Ｃのディスクに書き込まれる新たなブロック１９１０は、図１９におい て１９１０の符号が付されている。ブロック１８２４は、２重間接性により参照 される変更データを含むデータブロック１９１０を有しているので、二つの他の ブロック１９１８と１９２６も変更される。単独間接ブロック１９１８のポイン タ１９２４は新しいブロック１９１０を示すので、ブロック１９１８もディスク の新たな位置に書き込む必要がある。同様に、間接ブロック１９２６のポインタ １９２８はブロック１９１８を指すので、変更される。したがって、図１９に示 されるように、データブロック１９１０を変更することにより、いくつかの間接 ブ ロック１９１８と１９２６も変更を生じさせることができる。これはまた、ディ スクの新たな位置へのブロック１９１８と１９２６の書込みを必要とする。 図１８Ｃのデータブロック１８２４の直接および間接のブロック１９１０、１ ９１８、１９２６は変えられ、新たな位置に書き込まれるので、ｉノードファイ ルのｉノードは新たなブロックに書き込まれる。ｉノードファイルの変更された ブロックは、データが上書きされないので、ディスク上の新たなブロックが割り 当てられる。 図１９に示されるように、ブロック１９１０は間接ブロック１９２６、１９１ ８によってそれぞれ指し示される。したがって、ブロック１９１０が変更され、 新たなディスク位置に格納されると、対応する直接および間接のブロックもまた コピーされ、アクティブなファイルシステムに割り当てられる。したがって、多 くのデータ構造が更新される必要がある。直接ブロック１９１０および間接ブロ ック１９１８、１９２６を変えると、ブロックマップファイルが変更される。 スナップショット用キーデータ構造はブロックマップエントリであり、各エン トリは一つのスナップショットに対し多重のビットを有する。これは、複数のス ナップショットの作成を可能とする。スナップショットは、ファイルシステム（ 図１８の１８３０）であるブロックのツリーのピクチャである。新しいデータが スナップショットのブロック上に書き込まれないかぎり、スナップショットによ り表わされるファイルシステムは変わらない。スナップショットは整合点と類似 している。 本発明のファイルシステムは、ファイルシステム情報ブロック１８１０、１８ ７０が書き込まれた時点で完全に整合性がある。したがって、システムへの給電 が妨げられても、再始動のときに、ファイルシステム１８３０は整合状態に達す る。ＩＧＢファイルシステムの従来の典型的な「クローン」では８〜３２ＭＢの ディスク空間が使用されているので、クローンは、本発明のように整合点または スナップショットに導かない。 図２２を参照すると、ディスク上に既に二つのスナップショット２１１０Ａと ２１１０Ｂが存在する。三つ目のスナップショットが作成される瞬間に、アクテ ィ ブなファイルシステムを指すルートｉノードは、ｉノードファイル２１１０の第 ３のスナップショットのためにｉノードエントリ２１１０Ｃにコピーされる。同 時に、通過する整合点において、スナップショット３が作成されたことをフラグ が示す。全ファイルシステムは、ブロックマップファイルにおける各エントリご とにビット０がセットされるか（１）、あるいは、クリアされるか（０）をチェ ックすることにより処理される。各ブロックマップエントリの全てのビット０の 値はスナップショット３のためのプレーンにコピーされる。終了すると、ファイ ルシステムの各アクティブブロック２１１０〜２１１６と１２０７は、それが取 り出される瞬間にスナップショットに存在する。 所定時間連続してディスク上に存在したブロックも、第３のスナップショット ２１１０Ｃの前の対応するスナップショット２１１０Ａ〜２１１０Ｂに存在する 。あるブロックが十分長い時間ファイルシステムに存在したならば、それはすべ てのスナップショットに存在する。ブロック１２０７はそのようなブロックであ る。図２２に示されるように、ブロック１２０７は、アクティブなｉノードファ イルのｉノード２２１０Ｇにより示されるとともに、スナップショット１、２、 ３により間接的に示される。 スナップショットの順番は、ファイルシステムコピーの時間順を必ずしも示す わけではない。ファイルシステムの個々のスナップショットは任意の時に削除す ることができ、こうすることによりエントリをさらに使用することが可能となる 。アクティブなファイルシステムを参照するブロックマップエントリのビット０ がクリアされ（ブロックのアクティブなファイルシステムからの削除を示す）、 いずれかのスナップショット参照ビットが設定されると、ブロックは再使用でき ない。これは、ブロックが、なお使用されているスナップショットの一部だから である。ブロックは、ブロックマップエントリの全てのビットが０に設定される 時にのみ再使用できる。スナップショットを作成するアルゴリズム スナップショットの作成は、図５に示されるような規則的整合点の作成にほぼ 完全に類似している。ステップ５１０において、全ての汚れｉノードは、整合点 にあるものとしてマークが付けられる。ステップ５２０において、全ての正規の ファイルはディスクに対しフラッシュされる。ステップ５３０において、特別な ファイル（すなわち、ｉノードファイルとブロックマップファイル）は、ディス クに対しフラッシュされる。ステップ５４０において、ファイルシステム情報ブ ロックはディスクにフラッシュされる。ステップ５５０において、整合点にない 全てのｉノードは処理される。図５については詳細に先に説明している。実際、 スナップショットの作成は、整合点の作成の一部として行われる。スナップショ ットの作成と整合点の作成における基本的な違いは、ブロックマップファイルの すべてのエントリが、スナップショットビットにコピーされたアクティブなＦＳ ビットを有していることである。スナップショットビットは、スナップショット のブロックが上書きされることのないよう保護するために、対応するスナップシ ョットを示している。スナップショットの作成および削除は、ステップ５３０で 行われるが、これは、ファイルシステムが完全に自己整合性があり、ディスクに まさに移る唯一の点だからである。 異なるステップ（複数）が、新たなスナップショットが作成される時の整合点 のために図６に示されているステップ５３０において行われる。ステップは、正 規の整合点のステップと非常に類似している。図７は、スナップショットを作成 するためにステップ５３０が有するステップを示す流れ図である。上述したよう に、ステップ５３０は、ディスク空間をブロックマップファイルとｉノードファ イル用に割り当てるとともに、対応するスナップショットを示すスナップショッ トビットにアクティブＦＳビットをコピーし、スナップショットのブロックが上 書きされないよう保護する。 ステップ７１０において、ブロックマップファイルのｉノードと作成されてい るスナップショットはディスクに前もってフラッシュされる。ブロックマップフ ァイルのｉノードのｉノードファイルのブロックへのフラッシュ（整合点に対す る図６のステップ６１０のように）に加えて、作成されているスナップショット のｉノードもまた、ｉノードファイルのブロックにフラッシュされる。その結果 、スナップショットのｉノードを含むｉノードファイルのブロックは汚れること に なる。 ステップ７２０において、ブロックマップファイルの各ブロックマップは汚れ ている。ステップ７６０（後で記載する）において、ブロックマップファイルの すべてのエントリは、汚れブロックのエントリの代わりに更新される。したがっ て、ブロックマップファイルのすべてのブロックはここで汚れているとのマーク を付ける必要があり、ステップ７３０はディスク空間をそれに書き込み割り当て る。 ステップ７３０において、ディスク空間は、ｉノードとブロックマップファイ ルのすべての汚れブロックに割り当てられる。汚れブロックには、汚れブロック マップファイルのｉノードを含むｉノードファイルのブロックと新たなスナップ ショット用ｉノードを含むブロックとが含まれる。 ステップ７４０において、ファイルシステム用ルートｉノードの内容は、ｉノ ードファイルのスナップショットのｉノードにコピーされる。この時、新たな整 合点の一部でありディスクに書き込まれる各ブロックには、それに割り当てられ るディスク空間がある。したがって、ルートｉノードをスナップショットｉノー ドに２重化すると、アクティブな全ファイルシステムが効率的にコピーされる。 スナップショットに存在する実際のブロックは、アクティブなファイルシステム の同じブロックである。 ステップ７５０において、ブロックマップファイルとスナップショットのｉノ ードは、ｉノードファイルにコピーされる。 ステップ７６０において、ブロックマップファイルのエントリは更新される。 アクティブなＦＳビットのエントリのためのＣＰビットへのコピーに加えて、ア クティブなＦＳビットも、新たなスナップショットに対応するスナップショット ビットにコピーされる。 ステップ７７０において、ブロックマップとｉノードファイルとの中のすべて の汚れブロックはディスクに書き込まれる。 最後に、ある時点で、スナップショットそれ自体が、ステップ７６０において ファイルシステムから削除される。スナップショットは、アクティブなファイル システムのｉノードファイルの中におけるそのスナップショットｉノードエント リをクリアし、ブロックマップファイルの各エントリにおけるスナップショット 番号に対応する各ビットをクリアすることにより、ファイルシステムより削除さ れる。また、設定値からクリアされる全てのブロックマップエントリの中のスナ ップショットの各ビットの計数が行われ、これにより、スナップショットを削除 することにより解放されるブロックの計数値（解放されるディスク空間の大きさ に相当する量）が得られる。このシステムは、最も古いスナップショットに基づ いて削除すべきスナップショットを決定する。使用者もまた、特定のスナップシ ョットの削除を手動で選択できる。 本発明は、スナップショットの総数を限定するとともに、エピソードのように ＣＯＷビットを有するポインタを使用する代わりに、スナップショットを追跡す るための複数のビットを有するエントリを持つブロックマップファイルを維持す る。未使用ブロックは、そのブロックマップファイルエントリにおけるビットが すべて０である。時間が経過すると、アクティブなファイルシステムビット０（ ビット０）は、一般にある時点で１となる。ビット０を設定することにより、対 応するブロックを、アクティブなファイルシステムにおいて割り当てられたもの として、同定する。上述したように、全てのスナップショットビットは、まず０ に設定される。いずれかのスナップショットビットが設定される前にアクティブ なファイルのビットがクリアされると、ディスク上に格納されたどのスナップシ ョットにもブロックは存在しない。それ故、ブロックは再割り当てのためにすぐ に使用でき、スナップショットから続いて回復できない。スナップショットの作成 前述したように、スナップショットは整合点に非常に類似している。それ故、 スナップショットの作成を、これと、図１７Ａ〜図１７Ｌに示される整合点の作 成との間の相違を参照して説明する。図２１Ａ〜図２１Ｆは、スナップショット 作成の相違を示している。 図１７Ａ〜図１７Ｄは、スナップショット開始時のＷＡＦＬファイルシステム の状態を示している。すべての汚れｉノードは、ステップ５１０において整合点 にあるものとしてマークされており、正規のファイルは、ステップ５２０におい てディスクにフラッシュされる。したがって、スナップショットの最初の処理は 、整合点のものと同一である。スナップショットのための処理は、ステップ５３ ０において整合点のものと相違している。図７によるスナップショットの処理を 以下に説明する。 以下の説明は、ＷＡＦＬファイルシステムの第２のスナップショット用のもの である。第１のスナップショットは、図１７Ｃのブロックマップエントリに記録 されている。エントリ２３２４Ａ〜２３２４Ｍに示されているように、ブロック ２３０４〜２３０６、２３１０〜２３２０、２３２４は、第１スナップショット に含まれている。他の全てのスナップショットビット（ビット１〜ビット２０） は、対応するスナップショットがディスク上にないことを示す０の値を持ってい るものとする。図２１Ａは、ステップ５１０とステップ５２０が終了した後のフ ァイルシステムを示している。 ステップ７１０において、スナップショット２のｉノード２３０８Ｃと２３０ ８Ｄとブロックマップファイル２３４４はディスクに対しあらかじめフラッシュ される。その結果、スナップショット２のｉノードを包含しつつあるｉノードフ ァイルのブロックが汚いことを保証する。図２１Ｂにおいて、ｉノード２３０８ Ｃと２３０８Ｄは、スナップショット２に対し、かつ、ブロックマップファイル ２３４４に対し、あらかじめフラッシュされる。 ステップ７２０において、全ブロックマップファイル２３４４は汚されている 。その結果、ステップ７３０において、全体のブロックマップファイル２３４４ がディスク空間に割り当てられる。ステップ７３０において、ディスク空間は、 図２１Ｃに示されるように、汚れブロック２３０８と２３２６およびｉノードフ ァイル２３４６とブロックマップファイル２３４４に対し割り当てられる。この ことは、ブロック２３０８と２３２６の横に三重アスタリスク（***）で示され ている。これは、図６のステップ６２０においてブロックマップファイル２３４ ４で変化したエントリを有するブロックにのみディスク空間が割り当てられる整 合点の作成とは異なる。図２１Ｃのブロックマップファイル２３４４は単一ブロ ッ ク２３２４を有している。しかし、ブロックマップファイル２３４４が１より多 いブロックを有すると、ディスク空間はステップ７３０において全ブロックに割 り当てられる。 ステップ７４０において、新しいファイルシステムのルートｉノードは、スナ ップショット２のｉノード２３０８Ｄにコピーされる。ステップ７５０において 、ブロックマップファイル２３４４とスナップショット２のｉノード２３０８Ｃ と２３０８Ｄは、図２１Ｄに示されるようにディスクにフラッシュされる。図は 、スナップショット２のｉノード２３０８Ｄがブロック２３０６ではなく、ブロ ック２３０４と２３０８を参照することを示している。 ステップ７６０において、ブロックマップファイル２３４４のブロック２３２ ６におけるエントリ２３２６Ａ〜２３２６Ｌは図２１Ｅに示されるように更新さ れる。図２１Ｅは、スナップショット２のビット（ビット２）が、各エントリ２ ３２６Ａ〜２３２６ＬのＦＳビットとＣＰビットと同様に更新されることを示し ている。したがって、ブロック２３０４、２３０８〜２３１２、２３１６〜２３ １８、２３２２、２３２６はスナップショット２に含まれるのに対し、ブロック ２３０６、２３１４、２３２０、２３２４は含まれない。ステップ７７０におい て、汚れブロック２３０８と２３２６はディスクに書き込まれる。 スナップショット２の次の処理は、図５に示される整合点の作成のものと同一 である。ステップ５４０において、二つのファイルシステム情報ブロックはディ スクにフラッシュされる。したがって、図２１Ｆは、このステップの後の整合状 態にあるＷＡＦＬファイルシステムを示している。ステップ５４０が終了した後 の、整合性のあるファイルシステムのファイル２３４０、２３４２、２３４４、 ２３４６は、図２１Ｆの破線の内側に示される。ステップ５５０において、整合 点は、この整合点になかったｉノードを処理することにより終了する。アクセスタイム上書き ＵＮＩＸファイルシステムは、各ｉノードにおいて「アクセスタイム」（ａタ イム(atime)）を維持する必要がある。ａタイムは、ファイルが読み出された最 後の時間を示している。それは、ファイルがアクセスされるたびに更新される。 その結果、ファイルが読出されると、ｉノードファイルにおいてｉノードを含む ブロックは書き換えられ、ｉノードを更新する。これは、結果として、ファイル の読出しによりディスク空間を使い尽くす可能性があるので、スナップショット の作成には不利である。さらに、ファイルシステムのすべてのファイルの読出し により、全ｉノードファイルの２重化を惹き起す。本発明は、この問題を解決す る。 ａタイムにより、ｉノードを変更するとｉノードファイル用の新たなブロック がディスクに書き込まれるので、読出しはディスク空間を消費する可能性がある 。さらに、ファイルシステムが一杯となるようなファイルシステムにとって異常 な事態が発生すると、読出し動作は失敗に終わる可能性がある。 一般に、ディスク上のデータは、ディスクに格納されたデータを保護するよう に、ＷＡＦＬファイルシステムに上書きされることはない。この規則の唯一の例 外は、図２３Ａ〜図２３Ｂに示されるように、ｉノードに対するａタイム上書き である。「ａタイム上書き」が発生すると、ｉノードファイルのブロックで変更 される唯一のデータは、それに含まれる一つあるいはそれ以上のｉノードのａタ イムであり、ブロックは同じ位置で書き換えられる。これはＷＡＦＬシステムに おける唯一の例外であり、他の場合は、新しいデータは常に新しいディスク位置 に書き込まれる。 図２３Ａは、古いＷＡＦＬｉノードファイルブロック２４２０のｉノード２４ ２２のａタイム２４２３と、ブロック２４２０を示すスナップショットｉノード ２４３２のａタイム２４３３を示す。ブロック２４２０のｉノード２４２２は直 接ブロック２４１０を参照する。ｉノード２４２２のａタイム２４２３は、「４ ／３０ ９：１５ＰＭ」であるのに対し、スナップショットｉノード２４３２の ａタイム２４３３は「５／１ １０：００ＡＭ」である。図２３Ａは、直接バッ ファ２４１０がアクセスされる前のファイルシステムを示している。 図２３Ｂは、直接ブロック２４１０がアクセスされた後の直接ブロック２４１ ０のｉノード２４２２を示す。図に示されるように、ｉノード２４２２のアクセ スタイム２４２３は、それを示すスナップショット２４３２のアクセスタイム２ ４３３とともに上書きされる。したがって、直接ブロック２４１０のｉノード２ ４２２のアクセスタイム２４２３は「５／１ １１：２３ＡＭ」である。 新しいａタイムでｉノードファイルブロックを上書きすると、スナップショッ トにおいてわずかな非整合が発生する。スナップショットのファイルのａタイム は、実際には、スナップショットが作成された時間より後のはずである。ユーザ がこの非整合を発見しないように、ＷＡＦＬは、スナップショットの全てのファ イルのａタイムをファイルが最後にアクセスされた時間の代わりにスナップショ ットが実際に作成された時間に調節する。このスナップショットタイムは、スナ ップショットを全体として記載しているｉノードに格納される。したがって、ス ナップショットを介してアクセスすると、ｉノード２４２２のアクセスタイム２ ４２３は、常に「５／１ １０：００ＡＭ」として報告される。これは、「４／ ３０ ９：１５ＰＭ」であると予想される更新前と、「５／１ １１：２３ＡＭ 」であると予想される更新後の両方で発生する。アクティブなファイルシステム を介してアクセスすると、時間は更新前と更新後においてそれぞれ「４／３０ ９：１５ＰＭ」と「５／１ １１：２３ＡＭ」として報告される。 このように、ファイルシステムを整合状態に維持し、ファイルシステムの読出 し専用コピーを作成する方法が開示された。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 マルコム、マイケル アメリカ合衆国カリフォルニア州94022、 ロス・アルトス、サウス・アバロン・ドラ イブ48番 (72)発明者 ラウ、ジェイムズ アメリカ合衆国カリフォルニア州95014、 カパチノ、アップランド・ウェイ11570番 (72)発明者 ラキチス、バイロン アメリカ合衆国カリフォルニア州94043、 マウンテン・ビュー、ノース・ウィッシマ ン・ナンバー130、100番

Claims (1)

1. 【特許請求の範囲】 １．ファイルシステムにある複数の変更されたブロックを指す複数のｉノードを 整合点にあるものとしてマークを付けるステップ、 正規ファイルを記憶手段に対しフラッシュし、特殊なファイルを上記の記憶手 段にフラッシュするステップ、 ファイルシステム情報の少なくとも一つのブロックを上記の記憶手段にフラッ シュするステップ、および、 上記の整合点の一部ではなかった汚れｉノードを再キューするステップ からなる整合点の作成方法。 ２．請求項１の方法において、上記の特殊なファイルを上記の記憶手段に送る上 記のステップは、さらに、 ブロックマップファイル用のｉノードをｉノードファイルに予めフラッシュす るステップ、 上記のｉノードと上記のブロックマップファイルにあるすべての汚れブロック とに上記の記憶手段における空間を割当てるステップ、 上記のブロックマップファイル用の上記のｉノードを再びフラッシュするステ ップ、 上記のブロックマップファイルにある複数のエントリ（この複数のエントリの 各々は上記の記憶手段上のブロックを示す）を更新するステップ、および、 上記のブロックマップファイルと上記のｉノードファイルにある全ての汚れブ ロックを上記の記憶手段に書込むステップ からなる方法。