(57)【要約】ブロックの割当て及び消去、並びに、ＣＰ及びＰＣＰＩの作成及び消去を永久的なログに記録することにより、生成された変更されたブロックの伝送の効率を向上させるシステム及び方法。このログは、各更新サイクル（その中で変化が宛先ミラーに伝送される）の間にストレージオペレーティングシステムによってスキャンされ、更新サイクルの終了時点で存在しているものとしてファイルシステムによって参照された変更のあったブロック、又は、更新サイクルの終了時点で存在していたＰＣＰＩによって参照された変更のあったブロックだけが、伝送の際に実際に送信される。その結果、変化を伝送する回数が減る。
2007517290.tif 000002
【特許請求の範囲】
【請求項１】
ソースから宛先ミラーへの更新データ識別子の伝送の効率を向上させるシステムであって、
時間経過による差分変化のエントリを記録するログと、
まだ割当てられていないデータ識別子であって、その後消去されるデータ識別子を、更新伝送サイクル内で伝送させる変更ブロック機能と
からなるシステム。
【請求項２】
前記変化のそれぞれに関連する前記エントリは、ボリュームブロック番号、及び、前記データ識別子のそれぞれの割当て及び消去のうちのいずれか一方を示すオペレーションフラグをそれぞれ含む、請求項１に記載のシステム。
【請求項３】
前記ログは、ＣＰ作成時刻の後、ＣＰ作成時間内において消去されたブロックを記憶するように構成され、その際に前記伝送は行われるが、前記消去されたブロックは消去されたものとしてストレージオペレーティングシステムのアクティブマップ上には示されず、それによって、前記消去されたブロックが不注意により再使用されることがないように構成される、請求項２に記載のシステム。
【請求項４】
前記ログのユーザのそれぞれは、該ユーザに関連する第１のコンシステンシ・ポイント及び第１のＣＰを含むレジスタ・エントリを有し、前記ストレージオペレーティングシステムは、前記ユーザによって、前記第１のコンシステンシ・ポイント及び前記第１のＣＰからスキャンを開始するように構成される、請求項３に記載のシステム。
【請求項５】
前記ログは、前記第１のＣＰより前に発生するエントリを削除するように構成される、請求項４に記載のシステム。
【請求項６】
前記エントリはそれぞれｑｔｒｅｅ識別子を含む、請求項５に記載のシステム。
【請求項７】
前記時間経過による差分変化のエントリはＣＰ作成時間を含む、請求項１に記載のシステム。
【請求項８】
前記時間経過による差分変化のエントリは、コンシステンシポイントイメージ（ＰＣＰＩ）作成時間を含む、請求項１に記載のシステム。
【請求項９】
前記時間経過による差分変化のエントリは、コンシステンシポイントイメージ（ＰＣＰＩ）消去時間を含む、請求項１に記載のシステム。
【請求項１０】
前記データ識別子は、ストレージオペレーティングシステムにおけるデータ識別子の更新伝送サイクル内の変化から生成される、請求項１に記載のシステム。
【請求項１１】
前記変更ブロック機能は、まだ割り当てられていないデータ識別子であって、その後消去されるデータ識別子を前記更新伝送サイクル内で伝送させるのみである、請求項１に記載のシステム。
【請求項１２】
ストレージオペレーティングシステムにおけるデータ識別子の２つの離れたコンシステンシ・ポイント（ＣＰ）間における更新されたデータ識別子のソースから宛先ミラーへの伝送の効率を向上させる方法であって、
前記２つの離れたＣＰ間の変化のそれぞれに関連するエントリをログに記録するステップと、
前記ログをスキャンし、まだ割当てられていないデータ識別子であって、その後消去されるデータ識別子を、２つのコンシステンシ・ポイント終了時刻間の更新伝送サイクル内において生成するステップと
からなる方法。
【請求項１３】
前記変化のそれぞれに関連する前記エントリは、ボリュームブロック番号、及び、前記データ識別子のそれぞれの割当て及び消去のうちのいずれか一方を示すオペレーションフラグをそれぞれ含む、請求項１２に記載の方法。
【請求項１４】
ＣＰ作成時刻の後、ＣＰ作成時間内において消去されたブロックをログに記憶することを更に含み、その際に前記伝送は行われるが、ストレージオペレーティングシステムのアクティブマップ上において、前記消去されたブロックの指示は消去されたものとして省略され、それによって、前記消去されたブロックが不注意により再使用されることがない、請求項１３に記載の方法。
【請求項１５】
前記ログのユーザのそれぞれは、該ユーザに関連する第１のコンシステンシ・ポイント及び第１のＣＰを含むレジスタ・エントリを有し、前記ストレージオペレーティングシステムは、前記ユーザによって前記第１のＣＰから開始されるように構成される、請求項１４に記載の方法。
【請求項１６】
前記最も古い第１のＣＰより前に発生するエントリを前記ログから削除することを更に含む、請求項１５に記載の方法。
【請求項１７】
前記エントリはそれぞれｑｔｒｅｅ識別子を含む、請求項１２に記載の方法。
【請求項１８】
ＣＰ作成時間のエントリを前記ログに記録するステップを更に含む、請求項１２に記載の方法。
【請求項１９】
ストレージオペレーティングシステムにおけるデータ識別子の２つの離れたコンシステンシ・ポイント（ＣＰ）間における変化のスキャンによって生成される更新されたデータ識別子のソースから宛先ミラーへの伝送の効率を向上させるためのコンピュータ読取可能媒体であって、該コンピュータ読取可能媒体が、
前記２つの離れたＣＰ間における変化のそれぞれに関連するエントリをログに記録するステップと、
前記ログをスキャンし、まだ割り当てられていないデータ識別子であって、その後消去されるデータ識別子を、２つのコンシステンシポイント終了時刻間の更新伝送サイクル内において生成するステップと
を実施するためのプログラム命令を含む、コンピュータ読取可能媒体。
【請求項２０】
前記変化のそれぞれに関連するエントリは、ボリュームブロック番号、及び、前記データ識別子のそれぞれの割当て及び消去のうちのいずれか一方を示すオペレーションフラグをそれぞれ含む、請求項１９に記載のコンピュータ読取可能媒体。
【請求項２１】
ＣＰ作成時刻の後、ＣＰ作成時間内において消去されたブロックを前記ログに記憶することを更に含み、その際に前記伝送は行われるが、ストレージオペレーティングシステムのアクティブマップ上において、前記消去されたブロックの指示は消去されたものとして省略され、それによって、前記消去されたブロックが不注意によって再使用されることがない、請求項２０に記載のコンピュータ読取可能媒体。
【請求項２２】
前記ログのユーザのそれぞれは、該ユーザに関連する第１のコンシステンシ・ポイント及び第１のＣＰを含むレジスタ・エントリを有し、前記ストレージオペレーティングシステムは、前記ユーザによって前記第１のＣＰから開始されるように構成される、請求項２１に記載のコンピュータ読取可能媒体。
【請求項２３】
前記最も古い第１のＣＰよりも前に発生するエントリを前記ログから削除することを更に含む、請求項１９に記載のコンピュータ読取可能媒体。
【請求項２４】
前記エントリはそれぞれｑｔｒｅｅ識別子を含む、請求項１９に記載のコンピュータ読取可能媒体。
【請求項２５】
ソースから宛先複製への更新されたブロックの伝送の効率を向上させる方法であって、
ブロックが割当て済みであるか、それとも消去されているかを示すエントリに応じて、変更されたブロックのセットをログに伝送するステップと、
割当ても消去もされていないブロックを前記ログ内の更新伝送サイクルにおいて前記宛先複製へ選択的に伝送するステップと
からなる方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明はファイルシステムに関し、詳しくは、ファイルサーバのディスク書き込み処理を減らす技術に関する。
【背景技術】
【０００２】
発明の背景
ファイルサーバは、ディスクのような記憶装置における情報の編成に関連するファイルサービスを提供するコンピュータである。ファイルサーバ又は「ファイラ」は、情報をディレクトリやファイルの階層構造としてディスク上に論理編成するためのファイルシステムを実施するストレージオペレーティングシステムを有する。「ディスク上」の各ファイルは、例えば、情報を記憶するように構成された１セットのディスクブロックのようなデータ構造として実施される場合がある。一方、ディレクトリは、他のファイルやディレクトリに関する情報を記憶するための特殊形式のファイルとして実施される場合がある。
【０００３】
ファイラは、情報配送のクライアント／サーバモデルに従って動作するように更に構成され、それによって、多数のクライアントが、例えばファイラのようなサーバ上に記憶されたファイルにアクセスすることができる。このモデルにおいて、クライアントは、コンピュータ上で実施されるデータベースアプリケーションのようなアプリケーションを有する場合があり、直接接続、あるいは、ポイント・ツー・ポイント接続、共有ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）又はインターネットのような公共ネットワークを介して実施される仮想私設ネットワーク（ＶＰＮ）を介してファイラに「接続」される場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージを（パケットの形で）ファイラに発行することによって、ファイラに対し、ファイルシステムのサービスを要求することができる。
【０００４】
ファイルシステムの一般的タイプは「定位置書き込み型」ファイルシステムであり、その一例は、従来のバークレイ・ファーストファイルシステムである。「ファイルシステム」とは、ディスクのような記憶装置上のデータやメタデータの構造を一般に言い、ファイルシステムによって、そうしたディスク上のデータの読み書きが可能になる。定位置書き込み型ファイルシステムでは、ディスク上のinodeやデータブロックのようなデータ構造の位置が、一般に固定されている。inodeはファイルに関するメタデータのような情報の記憶に使用されるデータ構造であるのに対し、データブロックは、そのファイルの実際のデータの記憶に使用される構造である。inodeに記憶される情報には、例えば、ファイルの所有者、ファイルのアクセス権、ファイルのサイズ、ファイルタイプ、及び、ファイルのデータブロックのディスク上の位置の参照などがある。ファイルデータの位置の参照は、ポインタとしてinodeに与えられ、ファイル内のデータ量によっては、間接ブロックを更に参照する場合もあり、従ってデータブロックを参照する場合がある。定位置書き込み型ファイルシステムによれば、inodeやデータブロックに対する変更は「定位置」で行われる。ファイルの更新によってファイルのデータの品質が拡張される場合、更に別のデータブロックが割り当てられ、適当なinodeがそのデータブロックを参照するように更新される。
【０００５】
ファイルシステムの他のタイプとして、ディスク上のデータを上書きしないWrite Anywhereファイルシステムがある。ディスク上のデータブロックをディスクからメモリに取り出し（読み出し）、そのデータブロックを新たなデータで「汚す」と、そのデータブロックはディスク上の新たな位置に記憶（書き込み）され、それによって書き込み性能が最適化される。Write Anywhereファイルシステムは、データがディスク上に実質的に連続的に配置されるような最適ディスクレイアウトを最初に想定している。この最適ディスクレイアウトによって、効率的なアクセス動作が得られ、特に、ディスクに対するシーケンシャルリード動作の場合に効率的なアクセス動作が得られる。ファイラ上で動作するように構成されたWrite Anywhereファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから入手できるWrite Anywhere File Layout(WAFL)である。WAFLファイルシステムは、マイクロカーネルの内部で、ファイラ及び関連ディスクストレージの全体的プロトコルスタックの一部として実施される。このマイクロカーネルは、ネットワーク接続されたクライアントからのファイルサービス要求の処理を行うためにファイラに常駐するネットワーク・アプライアンスのData ONTAPソフトウェアの一部として提供される。
【０００６】
本明細書で使用される「ストレージオペレーティングシステム」という用語は通常、データアクセスを管理するための、コンピュータ上で動作するコンピュータ実行可能コードを意味し、ファイラの場合、コンピュータ実行可能コードは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから入手できるマイクロカーネルとして実施されるData ONTAPストレージオペレーティングシステムのようなファイルシステムセマンティックを実施する場合がある。Data ONTAPストレージオペレーティングシステムは、Write Anywhere File Layout (WAFL)ファイルシステムを実施する。ストレージオペレーティングシステムは、UNIXやWindows NTのような汎用オペレーティングシステム、あるいは、本明細書に記載するような記憶目的のために構成された、設定可能機能を備えた汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施することも可能である。
【０００７】
ディスクストレージは一般に、複数のストレージディスクからなる１以上のストレージ「ボリューム」として実施され、ボリュームによって記憶空間の全体的論理配置が画定される。現在市販されているファイラ実施形態は、多数（例えば、１５０以上）の個別のボリュームを提供することができる。本明細書の目的のために、各ボリュームは独自のファイルシステムに関係し、ボリュームとファイルシステムは一般に同義語として使用されるものとする。ボリューム内のディスクは通常、１以上のＲＡＩＤグループとして編成される。ＲＡＩＤ実施形態は、データをＲＡＩＤグループ内の所与の数の物理ディスクにわたって「ストライプ」状に書き込み、そのストライプ化されたデータに関するパリティ情報を適切にキャッシュすることによって、データ記憶の信頼性／完全性を向上させる。WAFLファイルシステムの例の場合、ＲＡＩＤ４実施形態を使用すると有利である。この実施形態は具体的には、１グループのディスクにわたるデータのストライピングを課し、そのＲＡＩＤグループ内の特定のディスクに別個にパリティをキャッシュする。本明細書に記載する「ボリューム」は通常、ＲＡＩＤ４又は等価な高信頼性実施形態に従って構成された、少なくとも１つのデータディスク及び１つの関連パリティディスクから構成される（あるいは、データパーティションとパリティパーティションを一台のディスク上に設けることも可能である）。
【０００８】
信頼性を向上させ、ファイラ、ファイラに関連するディスク、又は、ストレージ・インフラストラクチャの一部が故障したときに、災害復旧を容易にするために、基礎データ、及び／又は、データの編成を行うファイルシステムの一部又は全部は一般に、「ミラーリング」、すなわち複製される。ミラーは、例えば、リモートサイトで作成され、そこに記憶されるため、メインの記憶場所、又は、そのインフラストラクチャに物理的被害を場合がある真の災害（例えば、洪水、停電、戦争活動など）が起きたときの復元の可能性を高めることができる。ファイルシステムに対する最も最近の変更を捕捉するために、ミラーは一定時間間隔で更新され、その時間間隔は通常、管理者によって設定される。更新の１つの一般的形として、スナップショットプロセスを使用するものがある。
【０００９】
ファイルシステム層は、一連のイメージプロセス、すなわち、スナップショットプロセス（下記の図７の「ＰＣＰＩ」７３０を参照）を含み、それらがファイルシステムのイメージ作成機能を実施する。スナップショット作成の詳しい説明については、ネットワーク・アプライアンス・インコーポレイテッドにより出版された「File Sytem Design for an NFS File Server Appliance」と題するDavid Hitz他によるＴＲ３００２、及び、「METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM」と題するDavid Hitz他による米国特許第５，８１９，２９２号に記載されており、これらの文献は参照により本明細書に援用される。「Ｓｎａｐｓｈｏｔ（スナップショット）」という用語はネットワーク・アプライアンス・インコーポレイテッドの商標である。本発明では、この用語は、永久的コンシステンシー・ポイント（ＣＰ）イメージを指すものとして使用される。永久的コンシステンシー・ポイント・イメージ（ＰＣＰＩ）とは、或る時点において記憶装置（例えば、ディスク）又は他の永久的メモリに記憶されたストレージシステムの表現であり、詳しくは、アクティブファイルシステムの表現であり、他の時点において取得された他のＰＣＰＩから自分を区別するための名前、又は、他の一意の識別子を有する。ＰＣＰＩは、イメージを取得した時点におけるアクティブファイルシステムに関する他の情報（メタデータ）を更に有する場合がある。なお、本明細書全体を通じて、「ＰＣＰＩ」という用語と「スナップショット」という用語は、ネットワーク・アプライアンスの商標権を傷つけることなく、交換可能に使用される。
【００１０】
背景として、スナップショットとは、或る特定時点において作成されたファイルシステムの復元可能バージョンである。ＰＣＰＩは一般に、何らかの定期的スケジュールに基づいて作成される。ＰＣＰＩはアクティブファイルシステムと共にディスク上に記憶され、ストレージオペレーティングシステムによる要求に応じてファイラメモリのキャッシュに呼び出される。例示的なファイルシステムデータ識別子バッファツリー構造（この例ではｉｎｏｄｅを使用しているが、他の形のブロックやデータ識別子を使用してもよい）１００を図１に示す。図示のツリー構造は、ファイルシステム情報ブロック（図示せず）に存在する場合がある。ルートｉｎｏｄｅ１０５は、所与のファイルシステムに関係するｉｎｏｄｅファイルを表わす情報を記憶する。図示のファイルシステムｉｎｏｄｅ構造において、ルートｉｎｏｄｅ１０５は、ｉｎｏｄｅファイル間接ブロック１１０へのポインタを有している。ｉｎｏｄｅファイル間接ブロック１１０は、一連のｉｎｏｄｅファイルデータブロック１１５へのポインタを有する。ｉｎｏｄｅファイルデータブロック１１５は、ファイルデータブロック１２０Ａ、１２０Ｂ、及び、１２０Ｃへのポインタを有する。図示の実施形態において、ファイルデータブロック（１２０Ａ〜Ｃ）はそれぞれ、４キロバイト（ＫＢ）のデータを記憶することができる。なお、この構造１００は簡略化されたものであり、このバッファツリーにおいてデータブロックとルートｉｎｏｄｅの間に、適宜、更に別のデータ識別子の層を追加して設けてもよい。
【００１１】
ファイルシステムが所与のファイルシステムのＰＣＰＩを生成するときに、図２に示すようにＰＣＰＩｉｎｏｄｅ２０５が生成される。ＰＣＰＩｉｎｏｄｅ２０５は、実質的に、データ構造（ファイルシステム）１００のルートｉｎｏｄｅ１０５の複製コピーである。図示の構造２００は、図１と同じｉｎｏｄｅファイル間接ブロック１１０、ｉｎｏｄｅファイルデータブロック１１５、及び、ファイルデータブロック１２０Ａ〜Ｃを有している。ユーザがファイルデータブロックに変更を加えた場合、ファイルシステム層は、新たなデータブロックをディスクに書き込み、その新たに作成されたブロックを指すように、アクティブファイルシステムを変更する。
【００１２】
図３は、ファイルデータブロックに変更が加えられた後の例示的データ構造構造３００を示している。この例では、ファイルデータブロック１２０Ｃがファイルデータブロック１２０Ｃ’に変更された。ファイルデータブロック１２０Ｃがファイルデータブロック１２０Ｃ’に変更されるとき、変更されたデータブロックの内容は、例示的ファイルシステムの機能により、ディスク上の新たな場所に書き込まれる。新たな位置に書き込まれるため、ファイルデータブロック１２０Ｃの新たな場所を反映させるために、変更されたファイルデータブロック１２０Ｃを指すｉｎｏｄｅファイルデータブロック３１５を修正しなければならない。同様に、ｉｎｏｄｅファイル間接ブロック３１０も、その新たに変更されたｉｎｏｄｅファイルデータブロックを指すように、書き換えなければならない。したがって、あるファイルデータブロックが変更された後、ＰＣＰＩｉｎｏｄｅ２０５は、元のｉｎｏｄｅファイルシステム間接ブロック１１０へのポインタを有し、ｉｎｏｄｅファイルシステム間接ブロック１１０はｉｎｏｄｅファイルデータブロック１１５へのリンクを有することになる。ｉｎｏｄｅファイルデータブロック１１５は、元のファイルデータブロック１２０Ａ、１２０Ｂ、及び、１２０Ｃへのポインタを有する。ただし、新たに書き込まれたｉｎｏｄｅファイルデータブロック３１５は、未変更のファイルデータブロック１２０Ａ及び１２０Ｂへのポインタを有する。ｉｎｏｄｅファイルデータブロック３１５は、アクティブファイルシステムの新たな構成を表わす変更後のファイルデータブロック１２０Ｃ’へのポインタを更に有する。新たな構造３００を表わす新たなファイルシステムルートｉｎｏｄｅ３０５が作成される。なお、いずれかのスナップショットブロック（例えば２０５、１１０、及び、１２０Ｃ）に記憶されたメタデータ（図示せず）は、それらのブロックが全てのＰＣＰＩから解放されるまで、それらのブロックが再使用、すなわち、上書きされることを防止する。したがって、アクティブファイルシステムルートｉｎｏｄｅ３０５は、新たなブロック３１０、３１５、及び、１２０Ｃ’を指す一方、古いブロック２０５、１１０、１１５、及び１２０Ｃは、ＰＣＰＩが完全に解放されるまで保持される。
【００１３】
ＰＣＰＩが作成され、ファイルデータブロックが変更された後、ファイルシステム層は、ＰＣＰＩｉｎｏｄｅにアクセスすることにより、ファイルシステムｉｎｏｄｅ構造を、スナップショットの時点において存在していたように復元、すなわち「復旧」させることができる。ＰＣＰＩｉｎｏｄｅ２０５に含まれるポインタをｉｎｏｄｅファイル間接ブロック１１０及びｉｎｏｄｅファイルデータブロック１１５を通して、未変更のファイルデータブロック１２０Ａ〜Ｃまでたどることにより、ファイルシステム層は、そのフィルシステムをスナップショットの作成時点において存在していたようにファイルシステムを復元することができる。
【００１４】
ミラーリングの際には、上記のＰＣＰＩの全体が、（周知のインターネットのような）ネットワークを介して遠くの記憶場所に送信される。一般に、ＰＣＰＩとは、或る時点におけるファイルシステムのイメージ（通常は読み出し専用）であり、アクティブファイルシステムと同様に主記憶装置に記憶され、アクティブファイルシステムのユーザによりアクセスされる。なお、「アクティブファイルシステム」とは、現在の入出処理の対象になっているファイルシステムを意味する。アクティブファイルシステムは、例えば一連のディスクのような主記憶装置に記憶され、例えばテープのような二次記憶装置を使用して、そのアクティブファイルシステムのバックアップを記憶する場合がある。スナップショットが作成された後、起こり得る災害復旧に備えてそのイメージ化したものを残したまま、アクティブファイルシステムは再確立される。ＰＣＰＩが生成されるたびに、古いアクティブファイルシステムは新たなＰＣＰＩになり、新たなアクティブファイルシステムは、何らかの新たな変化の記録を実行する。種々の時間ベース、又はその他の規準に応じて、特定数のＰＣＰＩが維持される。スナップショットプロセスの詳細については、Blake Lewis他による「INSTANT SNAPSHOT」と題する米国特許出願０９／９３２，５７８号に記載されている。この文献は、参照により完全に説明されたものとして本明細書に援用される。
【００１５】
ファイルシステムのサイズが数十ギガバイト又は数百ギガバイト（あるいは数テラバイト）である場合、ファイルシステム全体の完全な複製をリモート（宛先）サイトに作成することは不便なことがある。リモートデータミラーリング又は複製のためのフルバックアップアプローチは、ネットワークの帯域幅に大きな負担をかけ、また、宛先とソースの両方のファイラの処理能力にも大きな負担をかける。１つの解決方法として、ファイルシステムボリュームのうちの変更された部分だけを複製するという方法がある。したがって、図４は、ソースファイルシステム４００が宛先ストレージサイト４０２（図示されていないサーバーとアタッチド・ストレージから構成される）にネットワークリンク４０４を介して接続される場合の、ボリュームベースのミラーリング／複製手順を示している。宛先４０２は、管理者によって設定された何らかの一定時間間隔で、定期的なミラー／複製更新を受信する。これらの時間間隔は、利用可能な帯域幅、データの重要性、変更の頻度、及び、ボリューム全体のサイズといった種々の規準に基づいて選択される。
【００１６】
簡単に要約すると、ソースは、時間的に離れた一対のボリュームのＰＣＰＩを作成する。それらのＰＣＰＩは、データをファイラの不揮発性メモリに収容する収容プロセスの一部として、又は、他のメカニズムによって作成することができる。「新しい」ＰＣＰＩ４１０は、ボリュームのアクティブファイルシステムの最近のＰＣＰＩである。「古い」ＰＣＰＩ４１２は、そのボリュームの古い方のＰＣＰＩであり、このＰＣＩＰＩは宛先ミラー上に複製されたファイルシステムのイメージに一致していなければならない。なお、新しいＰＣＰＩ４１２が作成された後、ファイルサーバは、新たなファイルサービス要求の処理を続けることができる。新しいＰＣＰＩは、当時最新のボリューム状態の絶対表現ではなく、その時までの活動のチェックポイントとして機能する。ディフェレンサ４２０は、古いＰＣＰＩと新しいＰＣＰＩにおけるブロック４２２をスキャンする。具体的には、ディフェレンサはブロック単位で処理を行い、各ＰＣＰＩにおけるブロックのリストを検査し、どのブロックが割当て済みであるか比較する。Write-anywhereシステムでは、ＰＣＰＩがブロックを参照している限り、そのブロックは再使用されないため、データの変化は新たなブロックに書き込まれる。図５に示す変化が識別された場合（データを意味する「Ｘ」の有無によって記されている）ディフェレンサ４２０における判断プロセス４００は、データを宛先４０２へ伝送すべきか否かを判断する。判断プロセス５００は、古いブロックと新しいブロックを次のようにして比較する：（ａ）旧／新ブロック対４３０のように、データが古いブロックと新しいブロックのどちらにも存在しない場合（ケース５０２）、伝送できるデータはない。（ｂ）旧／新データブロック対４３２のように、古いブロックにはデータがあるが、新しいブロックにはデータがない場合（ケース５０４）、このデータは既に伝送が済んでいるため（そして、新たな宛先ＰＣＰＩポインタはいずれも、それを無視するので）、新たなブロック状態は伝送されない。（ｃ）旧／新ブロック対４３４のように、古いブロックと新しいブロックの両方にデータが存在する場合（ケース５０６）、何も変化は起きてなく、このブロックデータは１つ前のＰＣＰＩに既に伝送されている。最後に、（ｄ）旧／新ブロック対４３６のように、古いブロックにはデータが存在しないが、新しいブロックには存在する場合（ケース５０８）、変更されたデータブロックがネットワークを介して伝送され、変更されたボリューム４４２として、宛先における変更されたボリュームミラー／複製セット４４０の一部になる。Write Anywhere構成の例において、変更されたブロックは、ストレージアレイ内の新たな未使用の場所に書き込まれる。変更されたブロックが全て書き込まれた後、次に、新しいＰＣＰＩのルートポインタであるベースファイルシステム情報ブロックが、宛先に収容される。伝送されたファイルシステム情報ブロックは収容され、宛先における変更されたブロック構造を指すことによって宛先ファイルシステム全体が更新され、１つ前のファイルシステム情報ブロックが置き換えられる。この時点で変更は宛先ボリュームミラーの最新の差分更新として収容される。このファイ��システムは、ソース上の「新しい」ミラーを正確に表わす。やがて、さらなる漸進的変化から、新たな「新しい」ミラーが生成される。
【００１７】
ＰＣＰＩのボリュームベースの遠隔ミラーリングアプローチの詳細については、Steven Kleiman他による本願と同じ譲受人の「FILE SYSTEM IMAGE TRANSFER」と題する米国特許出願第０９／１２７，４９７号、及び、Steven Kleiman他による「FILE SYSTEM IMAGE TRANSFER BETWEEN DISSIMILAR FILE SYSTEMS」と題する米国特許出願第０９／４２６，４０９号に記載されており、これらの特許文献はいずれも参照により本明細書に援用される。
【００１８】
ソースからリモートストレージ宛先への差分ミラーリングのためのボリュームベースのアプローチは効率的ではあるが、環境によっては、ボリューム構造の全体より少ない量を複製することが望ましいことがある。ボリュームベースのアプローチは通常、ボリューム全体をスキャンして変化を探し、それらの変化をブロック単位で伝送しなければならない。言い換えれば、このスキャンは、ブロックに含まれるファイル、ｉｎｏｄｅ、及び、データ構造に関する基礎情報を何も考慮せず、ブロックだけを考慮する。宛先は１セットのボリュームとして編成され、その結果、ソースと宛先の間にボリューム単位の一対一のマッピングが確立される。１つのボリュームに１テラバイト以上の情報が記憶されることがある場合、変化を探して比較するブロック単位のアプローチは、依然としてかなり大きなプロセッサオーバヘッド、及び、関連する処理時間を必要とする場合がある。多くの場合、スキャン中のルートｉｎｏｄｅより下にあるサブブロックに小さな変化があるだけにすぎない。しかしながら、ボリューム内の全ブロックのリストが検査されるため、ブロック（ファイル、ｉｎｏｄｅ構造など）の多くのグループに変化がないことは、考慮されない。また、ボリュームのサイズや範囲が大きくなのにつれて、ミラーリングされるデータをｑｔｒｅｅのようなサブグループに分割しなければならないという必要性が強まる。なぜなら、グループによっては頻繁に変更を受けるものがあり、そのようなグループは、あまり頻繁に変更を受けない他のグループに比べて頻繁にＰＣＰＩ／スナップショットを更新しなければならないからである。さらに、元のサブグループと、イメージ化された（スナップショット化された）サブグループとを１つのボリューム内に混在させ、ボリューム全体を移動させることなく、特定の重要データを離れた場所に移せることが望ましい場合がある。
【００１９】
ボリュームのそのような下位編成の１つは、周知のｑｔｒｅｅである。本明細書に記載されるような例示的ストレージシステム上で実施されるようなｑｔｒｅｅは、ボリュームのファイルシステムにおけるサブツリーである。ｑｔｒｅｅの重要な特徴は、或るｑｔｒｅｅが与えられたときに、ファイルシステム内の任意のファイル又はディレクトリがそのｑｔｒｅｅの要素であるか否かを迅速にテストできることにあり、そのため、ｑｔｒｅｅは、ファイルシステムを個々のデータセットとして編成するための優れた手段として機能する。複製データのソースと宛先の両方としてｑｔｒｅｅを使用することが望ましい場合がある。ｑｔｒｅｅの遠隔非同期ミラーリングのためのアプローチについては、Michael L. Federwisch他による「SYSTEM AND METHOD FOR DETERMINING CHANGES IN TWO SNAPSHOTS AND FOR TRANSMITTING CHANGES TO A DESTINATION SNAPSHOT」と題する米国特許出願第１０／１００，９６７号に記載されている。この文献の教示は参照により本明細書に援用される。
【００２０】
上記のミラーリングアプローチは非同期であるため、ＰＣＰＩの実際の作成後に行われる場合があり、断続的に行われる場合もある。その結果、ネットワーク帯域幅の望ましくない負担が軽減され、使用可能な帯域幅に応じて、変化情報を遠方の宛先へ伝送することが可能になる。ネットワークを介した変化データの伝送ロスが発生したときに、ミラー更新手順を使用して、それを無事になされた最後の伝送から確実に復元できるようにするために、ソースと宛先の両方に、一連のチェックポイント及び他の標準的な伝送基準点を作成してもよい。
【００２１】
上記のディフェレンサ・スキャン手順は、幾らか効率がよくなっている。なぜなら、変更のないブロックは、その下にある全てのブロックが全て未変更であって、それらをスキャンする必要が無いことを意味するからである。ただし、ブロックに変更があったときは常に、その所与の変化が通常、バッファツリーに沿って最大でルートまで伝搬され、ブランチ内の各ブロックをスキャンしなければならない。したがって、ツリーに対する比較的少数（すなわち、おそらくブロックの総数の１／１０００程度）のランダム書き込みがあっても、違いを見付けるためにツリー全体をスキャンしなければならないか否かは、分からない。そのため、ボリューム及び関連データ構造のサイズが増大するほど、システムやネットワークに対して課せられる処理の負担は大きくなる。現在のところ、こうしたボリュームのサイズは１テラバイト近づいていて、又は、それ以上になることもある。したがって、宛先ミラーへ伝送するための変更されたブロックのリストを生成するためのもっと効率的な方法が必要とされている。更新間隔が比較的短く（例えば１秒以下）、変更されたブロックの頻繁な検査と、変更されたブロックの頻繁な伝送が必要な場合、これは特に重要となる。
【発明の開示】
【課題を解決するための手段】
【００２２】
発明の概要
本発明は、ストレージオペレーティングシステムにおけるデータ識別子の２つの異なる時点における永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）間に発生する更新されたブロックの伝送の効率を改善し、ソースと宛先を最初に同期させた後は、新たなＰＣＰＩを作成することなく、宛先がソースに繰り返し同期されるシステム及び方法を提供することにより、従来技術の欠点を克服する。ファイルシステムは、特定の変化を変更ログに記録する。ミラーリングアプリケーションは、ファイルシステム内の特定ポイントを常に選択する。各更新サイクルの間にログはストレージオペレーティングシステムによってスキャンされ、更新サイクル（変化を宛先ミラーに伝送するサイクル）の最後の時点で存在しているものとしてファイルシステムによって参照された変化のある（あった）ブロックだけが、伝送の際に実際に送信される。ログのスキャンは、ブロック差分をとるよりも効率がよく、特に、大きなファイルシステムの短い更新サイクル（１以下のコンシステンシ・ポイントを範囲とするような更新サイクル）の場合に効率がよく、ソースと宛先を最初に同期させた後は、新たなＰＣＰＩを作成する必要がない。参照されたブロックだけを更新サイクルの最後の時点で伝送することで、伝送する変化の数を減らすことができ、特に、更新サイクル中に変化が上書き又は消去される場合がある長い更新サイクルの場合に、伝送される変化の数を減らすことができる。一実施形態において、ログは、１つの処理（割当て、又は、消去）と、ブロック識別子とを含むブロックの一連の識別子を含む。この識別子は、ブロックのボリュームブロック番号であってもよい。また、ログは、ＰＣＰＩ作成のためのマーカー、及び、コンシステンシ・ポイント（ＣＰ）のマーカーを更に含む。ストレージオペレーティングシステムのアクティブマップにおいて、消去されたブロックは、それらがミラーに対して書き込まれるまで更新されない。このようにして、それらはミラーリングシステムによって確実に利用可能になる。
【００２３】
本発明の上記の利点及び他の利点は、添付の図面とあわせて下記の説明を読むと分かりやすいであろう。図中、同じ参照符号は、同一の要素または機能的に類似の要素を指している。
【発明を実施するための最良の形態】
【００２４】
例示的実施形態の詳細な説明
Ａ．ネットワーク及びファイルサーバ環境
さらなる背景として、図６は、本発明と共に使用するのに都合がよいソースシステム６１０と宛先システム６１２とを含む、一対の相互接続されたコンピュータ（この例では、ファイルサーバ）を含むストレージシステム環境６００を示す略ブロック図である。説明のために、ソースシステム６１０は、ソースボリューム６１４上の１以上のストレージディスク６６２を管理するネットワーク接続されたファイルサーバであるものとする。ソースシステム６１０は、オペレーティングシステム７００を実行している。オペレーティングシステム７００は、ソースシステム６１０に接続されたディスク６６２上にファイルシステム、又は、他の（例えば、ブロックベースの）データ構造を実現する。
【００２５】
宛先システム６１２は、ディスク６６０のアレイを含む１以上の宛先ボリューム６１６を管理する。ソースと宛先はネットワーク６１８によってリンクされ、ネットワーク６１８はローカルネットワークや、周知のインターネットのようなワイドエリアネットワークからなる。ソース６１０と６１２のそれぞれに内蔵された適当なネットワークアダプタ６３０によって、ネットワーク６１８を介した通信が可能になる。なお、本明細書で使用されるように、「ソース」という用語は、本発明の目的データが伝送される際の元の場所として広く定義され、「宛先」という用語は、データが伝送される場所として広く定義される。ネットワークによって接続されるソースシステムと宛先システムは、本明細書で使用されるソースと宛先の特定の例であり、ソースと宛先は、直接リンク、又は、ループバック（ローカルソースとローカル宛先の間でデータストリームを伝送するための単一コンピュータ内の「ネットワーク」構成」）によってリンクされたコンピュータ／ファイラであってもよく、その場合、ソースと宛先は、同じファイルサーバを含む場合もある。
【００２６】
この例において、ソースシステム６１０と宛先システム６１２はいずれもファイルサーバであり、通常は、システムバス６４５によって相互接続されたプロセッサ６２０、メモリ６２５、ネットワークアダプタ６３０、及び、ストレージアダプタ６４０を含む。また、ソースと宛先は、情報をデータとデータ識別子（例えば、ファイルやディレクトリ）の階層構造としてディスク上に論理編成するファイルシステム機能又は他のデータ管理機能を実施するストレージオペレーティングシステム７００（図７）を実施する。この例において、ソース６１０上のストレージオペレーティングシステム（７００）と宛先６１２上のストレージオペレーティングシステム（７００）は同じものであり、同様のアプリケーション及びユーティリティを実行している。ただし、ソースオペレーティングシステムと宛先オペレーティングシステムの構造及び機能は異なるが、両方とも、本明細書に記載するようなスナップショット機能、及び、ミラーリング機能を実施する。
【００２７】
当業者には分かるように、本明細書に記載する本発明の技術は、ストレージシステムとして実施されるスタンドアロンのコンピュータを含めて、いかなるタイプの特殊な目的のコンピュータ（例えば、ファイルサービスを提供するアプライアンス）にも、汎用コンピュータにも適用することができる。そのため、ソースシステム６１０及び宛先システム６１２は、代わりにストレージシステムとも呼ばれる。また、本発明の教示は、限定はしないが、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及び、ホスト／クライアントコンピュータに直接取り付けされるディスクアセンブリを含む、種々のストレージシステムアーキテクチャに適合する。したがって、「ストレージシステム」という用語は、それらの構成も含むものとして広い意味で解釈しなければならない。
【００２８】
図示の実施形態において、各システムメモリ６２５は、ソフトウェアプログラムコードを記憶するためにプロセッサやアダプタによってアドレス指定可能な記憶場所を有する。メモリは、電源の入れ直しや、他のリブート動作によって一般にクリアされるランダムアクセスメモリ（ＲＡＭ）の形をとる（すなわち、「揮発性］メモリである）。また、プロセッサ及びアダプタは、そのソフトウェアコードを実行し、データ構造を操作するように構成された処理要素、及び／又は、論理回路を有する。ストレージオペレーティングシステム７００は、その一部が通常、メモリに常駐し、処理要素によって実行され、とりわけ、ファイラによって実施されるファイルサービスを支えるストレージオペレーションを実施することにより、ファイラを機能的に構成する。当業者には明らかなように、本明細書に記載する本発明の技術に関係するプログラム命令の記憶や実行には、他の処理手段や、種々のコンピュータ読取可能媒体を含む他の記憶手段を使用することも可能である。
【００２９】
ネットワークアダプタ６３０は、システム６１０、６１２をネットワーク６１８に接続すために必要な機械的、電気的、及び、信号回路を含み、ネットワーク６１８には、ポイント・ツー・ポイント接続や、ローカルエリアネットワークのような共有媒体がある。また、ソース６１０は、情報配送のクライアント／サーバモデルに従って、宛先ファイラ６１２と通信する。つまり、クライアントがファイラのサービスを要求すると、ファイラは、例えばＴＣＰ／ＩＰプロトコルや他のネットワークプロトコルフォーマットによってカプセル化されたパケット６５５をネットワーク６１８を介してやりとりすることにより、クライアントから要求されたサービスの要求の結果を返す。
【００３０】
各ストレージアダプタ６４０は、ファイラ上で実行されているオペレーティングシステム７００（図７）と協働し、クライアントによって要求された情報にアクセスする。この情報は、ストレージアダプタ６４０を介してシステム６１０、６１２、又は、本明細書に規定されるような各ストレージシステムの他のノードに取り付けられたディスク６６２上に記憶されている場合がある。ストレージアダプタ６４０は、従来の高性能なファイバチャネル・シリアルリンク・トポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を有する。情報は、ストレージアダプタによって取得され、以下で説明するようにシステムバス６４５を介してネットワークアダプタ６３０へ転送される前に、ＰＣＰＩ手順の一部としてプロセッサ６２０によって処理される。その際、情報はパケットにフォーマットされ、宛先サーバへ伝送される。これについても、後で詳しく説明する。
【００３１】
システム６１０と６１２のどちらかは、ネットワークアダプタ６３０を介して１以上のクライアント６７０にも更に相互接続される。クライアントはそれぞれ、ＬＡＮ又は他のネットワーク（６１８）を介して、ファイルサービスを求める要求をシステム６１２に送信し、要求に対する応答を受信する。クライアントとファイラ６１２の間のデータの伝送は、コモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルや、ＮＦＳのような他の適当なプロトコルのカプセル化として規定されたデータパケット６７４を使用して行われる。
【００３２】
ファイルサーバの例示的な一実施形態において、各システムは、データのフォールトトレラントなバックアップが可能な不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）６３５を有し、電源故障その他によるサービスの停止を切り抜けるためのファイラトランザクションの完全性を可能にする場合がある。ＮＶＲＡＭのサイズは、例えばその実施形態や、ファイルサーバにおける機能によって異なる場合がまる。ＮＶＲＡＭは通常、特定の時間に基づくトランザクションの塊（例えば、数秒分）をログに記録するのに十分なサイズを有する。各クライアント要求が完了した後、その要求の結果を要求元クライアントに返す前に、ＮＶＲＡＭはバッファキャッシュと並列に満たされる。定期的な時間間隔で、及び／又は、重要なイベントの発生後に発生する各連続したコンシステンシ・ポイント（ＣＰ）の後、ＮＶＲＡＭはフラッシュされ、新たな要求情報で再度満たされる。故障又は他の障害が原因でＣＰが発生しなかった場合、ＮＶＲＡＭログ６８０の内容を再生することにより、最も最近の要求を復元することができる。
【００３３】
図示の実施形態において、ディスク６６０及び６６２は、複数のボリューム（例えば、宛先ボリューム６１６及びソースボリューム６１４のそれぞれ）に編成され、各ボリュームはそのボリュームに関連するファイルシステムを有する。これらのボリュームはそれぞれ、１以上のディスク６６０を有する。一実施形態において、物理ディスク６６０はＲＡＩＤグループに編成され、好ましいＲＡＩＤ４構成にしたがって、幾つかのディスクはストライプ状にデータを記憶し、幾つかのディスクはそのデータの独立したパリティを記憶する。ただし、他の構成（例えば、複数のストライプにわたって分散されたパリティを有するＲＡＩＤ５など）も可能である。この実施形態では、最小限の１台のパリティディスク及び１台のデータディスクが使用される。ただし、通常の実施形態は、１ＲＡＩＤグループあたり３台のデータディスク及び１台のエータディスクを有し、１ボリュームあたり複数のＲＡＩＤグループを有する。
【００３４】
Ｂ．ストレージオペレーティングシステム
ディスク６６０、６６２に対する一般的アクセスを可能にするために、図７に示すストレージオペレーティングシステム７００は、情報をデータ識別子及びデータ（ディレクトリとファイル）の階層構造としてディスク上に論理編成するwrite-anywhereファイルシステム又は他のデータ処理機能を実施する。「ディスク上」の各ファイルは、データのような情報を記憶するように構成された一連のデータブロックとして実施される一方、ディレクトリは、他のファイルやディレクトリへの参照が記憶される特殊なフォーマットのファイルとして実施される。上に記載及び規定したように、本明細書に記載する例示的実施形態において、ストレージオペレーティングシステムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているNetApp Data ONTAPオペレーティングシステムであり、このオペレーティングシステムはWrite Anywhere File Layout (WAFL)ファイルシステムを実施する。当然ながら、任意のファイルシステムを使用することができるものと考えられ、そのため、「ＷＡＦＬ」と言う用語を使用した場合でも、それは本発明の教示に適合する任意のファイルシステムを指すものとして広い意味で解釈しなければならない。
【００３５】
次に、例示的ファイラのそれぞれの好ましいストレージオペレーティングシステムの構成について簡単に説明する。ただし、当然ながら、本発明の原理は、種々の代替ストレージオペレーティングシステムアーキテクチャを使用して実施することもできるものと考えられる。図７に示すように、図示のストレージオペレーティングシステム７００は、ネットワークドライバ（例えば、イーサネット（Ｒ）ドライバ）のメディアアクセス層７０５を含む一連のソフトウェア層からなる。オペレーティングシステムは、インターネットプロトコル（ＩＰ）層７１０、並びに、それを支える搬送機構であるトランスポート・コントロール・プロトコル（ＴＣＰ）層７１５、及び、ユーザ・データグラム・プロトコル（ＤＵＰ）層７２０を含む。ファイルシステムプロトコル層は、マルチプロトコルデータアクセスを提供し、その目的のために、ＣＩＦＳプロトコル７２５、ＮＦＳプロトコル７７３０、及び、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）層７３５を有する。また、ストレージオペレーティングシステム７００は、ＲＡＩＤプロトコルのようなディスクストレージプロトコル、及び、スモールコンピュータ・システムインタフェース（ＳＣＳＩ）のようなディスク制御プロトコルを更に実施するディスクストレージ層７４０を更に含む。
【００３６】
ディスクソフトウェア層と、ファイルシステムプロトコル層の間を橋渡しするのは、ストレージオペレーティングシステム７００のファイルシステム層７５０である。一般に、ファイルシステム層７５０は、例えば４キロバイト（ＫＢ）のデータブロックを使用し、ｉｎｏｄｅを使用してファイルを表現するブロックベースのディスク上フォーマット表現を有するファイルシステムを実施する。トランザクション要求に応じて、要求されたデータが「コア内」に存在しない場合、すなわち、ファイラサーバのメモリ６２５に存在しない場合、ファイルシステムは、その要求されたデータをボリュームからロードする（読み出す）ための処理を生成する。情報がメモリ内にない場合、ファイルシステム層７５０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイルの中を検索し、適当なエントリにアクセスし、ボリュームブロック番号を読み出す。次に、ファイルシステム層７５０は、そのボリュームブロック番号をディスクストレージ（ＲＡＩＤ）層７４０へ渡し、ディスクストレージ層７４０は、そのボリュームブロック番号をディスクブロック番号にマッピングし、後者をディスクドライバ層７４５の適当なドライバ（例えば、ファイバチャネルディスク相互接続上で実施されるＳＣＳＩのカプセル化）に送信する。ディスクドライバは、ボリュームからディスクブロック番号にアクセスし、ファイルサーバによる処理に備えて、要求されたデータをメモリ６２５にロードする。要求の処理が完了すると、ファイラ（及び、ストレージオペレーティングシステム）は、クライアント６７０に応答を返す。
【００３７】
なお、ファイラにおいて受信されたクライアント要求に対してデータストレージアクセスを実施しなければならない上記のストレージオペレーティングシステムの種々の層を貫通するストレージアクセスデータ要求パス７７０は、代わりに、ハードウェアで実施してもよいし、ハードウェアとソフトウェアの組み合わせで実施してもよい。つまり、本発明の代替実施形態において、ストレージアクセス要求データパス６７０は、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の内部で論理回路として実施してもよい。この種のハードウァア実施形態によれば、クライアント６７０によって発行されたファイルシステム要求パケット６７４に応答してファイルサーバ６１０、６１２によって提供されるファイルサービスのパフォーマンスが向上する。
【００３８】
ファイルシステム層７５０の上にあるのは、複製／ミラーリングアプリケーション７９０である。このアプリケーションは、上記の差分機能を使用して更新されたＰＣＰＩを生成する役割と、複製、すなわちミラーリングされたデータを宛先に伝送して記憶する役割とを有する。この実施形態において、スナップショットミラーリングアプリケーション７９０は通常、ＴＣＰ／ＩＰ層７１５、７１０、並びに、ファイルシステムＰＣＰＩメカニズム（７３０）への直接リンク７９２及び７９４によって示されているように、ストレージアクセス要求パス７７０の外側で動作する。
【００３９】
本発明の一実施形態によれば、複製／ミラーリングアプリケーション７９０の中にあるのは、後で詳しく説明される新規の変更ブロックロギング手順を実施するブロックロギング機能７９８である。この実施形態において、この手順は通常、ソースシステム６１０上で実施される。
【００４０】
Ｃ．変更されたブロックのロギング
コンシステンシ・ポイント間におけるファイルシステムのかなりの量の変更されたブロックが、実際には、比較的短い時間サイクルの間であっても、大きな変化を受けるメタデータであると考えられている。言い換えれば、１つのミラー更新サイクル内において、特定の幾つかのブロックが割当てられ、消去される場合がある。１サイクル内で幾つかのブロックが割り当てられ、消去される場合、通常、それらをミラーの更新に含める必要はない。図８は、全てのブロック割当て（「Ａ」及びブロック識別子（）によって指定される）８０２、８０４、８０５及び８０６、並びに、ブロック消去（Ｄ及びブロック識別子（）によって指定される）８０８、８１０、８１２及び８１５を常にトラッキングし続ける高密度にパックされた永久的ログ８００の詳細を示している。このログはメタファイルとしてオペレーティングシステム内に作成され、通常、ユーザはそれを見ることができない。ブロックに対する変更は通常、それが行われた時間に基づく順番で、このログに入れられる。図示のように、全てのブロック割当て及びブロック消去が時間順に記録され、それらがシステムの残りの部分にとって見えるようにされる。この順番は、それらが発生した実際の順番でなくてもよい。例えば、ＣＰが始まった後でなされた変更を、ＣＰ内のあらゆるのものの後で行われたかのような順番でログに記録することにより、違いが発生することがある。エントリの各セットと共に、所与の時点におけるＰＣＰＩの作成８２０、８２２のような他の情報、所与のＰＣＰＩの消去８３５、及び、コンシステンシ・ポイントＣＰ（）の終了の発生８３０、８３２、８３４も、それらの発生に応じて記録される。なお、この実施形態における各ＰＣＰＩの生成や消去は、ＣＰの端において発生する。同様に、変更されたブロックのエントリは、それらがＣＰ／ＰＣＰＩ境界内にあるか否かに応じて、特定のＣＰ、及び／又は、ＰＣＰＩに関連付けられる。言い換えれば、ＰＣＰＩ（ｂａｒ）及びＣＰ（０）は、エントリ８０２、８０４、８０５、８０６、８０８及び８１０を含み、ＣＰ（１）も、エントリ８１２などを含む。なお、ＰＣＰＩは各ＰＣにおいて発生する必要はない。このように所与のＣＰにおいてＰＣＰＩを作成することが望ましいのは、ファイルシステムに「矛盾のない」ときである。
【００４１】
割当てと消去はログに記録される。すなわち、割当ては、所与の時間にどのブロックが変更され、消去されたかを判定し、変更されたブロックの内容がミラーに実際に伝送され、もはや不要であることが確実になるまで、それらのブロックが再使用されないようにするために、割当てが記録される。消去されたブロックの再使用を防止するために、ＰＣＰＩ（スナップショット）は通常、作成されない。その理由は、それに関わるパフォーマンスコストによる。したがって、消去されたブロックが再使用されるリスクがある。この例では、ファイルシステムは、ファイルシステムが普通行うように、消去されたブロックを空いているブロックとしてマークすることはない。代わりに、消去は、変更ログに記録される。
【００４２】
消去が全てのミラーに無事に伝送されると、その消去は、アクティブマップ（ファイルシステム内でどのブロックが割当て済みであり、どのブロックが空いているかを示すメタファイル）に反映され、実際の場所／再使用のために利用可能にされる。
【００４３】
通常、割当て済みブロックは全て、ファイルシステムによって参照されたときにミラーへ伝送される。ただし、最適化を施すことができる。１セットの更新がミラーに適用され、それら更新が、ブロック割当てとそれに続くブロック消去を含む場合、そのブロック割当ての後に作成され、更新サイクル内の最後のＣＰの時点においても存在している（すなわち消去されていない）ＰＣＰＩによってそのブロックが参照されない限り（すなわち、当該ブロックへの参照を含まない限り）、そのブロックの伝送は省略することができる。
【００４４】
エントリ８０４及び８１０を参照すると、ブロックＸは、完全に所与のＣＰ及びＰＣＰＩサイクル（ＰＣＰＩ（ｂａｒ））内で、割り当てられ（Ａ（Ｘ））、消去されている（Ｄ（Ｘ））。言い換えれば、ブロックＸは、次のＣＰ及びＰＣＰＩまでに解放されている。したがって、ミラー更新８４０が次のＣＰの終了より前に伝送される場合（短いサイクルで）、ブロックＸは適用可能な更新サイクル内で割当られ、その割当てが解除されているため、ブロックＸは省略してもよい。
【００４５】
エントリ８０６及び８１２を参照すると、ミラー更新サイクルが、ログの開始からミラー更新８４０によって参照されるポイントを含むそのポイントまでを範囲とする場合、ミラーがＣＰ（０）８３０の時点におけるソースの状態に矛盾しないように、ブロックＭが伝送される。しかしながら、ミラー更新が、ログの開始からミラー更新１  ８６０又はミラー更新２  ８８０によって参照されるポイントを含むそのポイントまでを範囲とする場合、消去８１２によってブロックＭの参照は解除され、ブロックＭがＣＰ（２）やＣＰ（３）の時点において存在するＰＣＰＩによって参照されることはない。したがって、その伝送は省略してもよい。なお、ＰＣＰＩ（ｆｏｏ）は、ブロックＭが消去された後、ＣＰ（１）の最後の時点で作成されるため、ブロックＭを含まない。
【００４６】
エントリ８０５及び８１５を参照すると、ミラー更新サイクルが、ログの開始からミラー更新１  ８６０（ＣＰ（２））によって参照されるポイントを含むそのポイントまでを範囲とする場合、ブロックｚは消去されているが、ＰＣＰＩ（ｆｏｏ）の後のＣＰにおいて起きた消去は作成された。したがって、ブロックｚはＰＣＰＩ（ｆｏｏ）に存在し（によって参照され）、宛先がＰＣＰＩ（ｆｏｏ）の正確なコピーを得られるように、ブロックｚは伝送される。
【００４７】
ただし、ミラー更新が、ログの開始からミラー更新２  ８８０（ＣＰ（３））によって参照されるポイントを含むそのポイントまでを範囲とする場合、ブロックｚの伝送は省略してもよい。なぜなら、ＰＣＰＩ（ｆｏｏ）が、更新サイクルの終了よりも前に消去され、ブロックｚへの参照が全て削除されているである。したがって、ミラー更新が完了し、その結果、ＰＣＰＩ（ｆｏｏ）に関する状態を伝送する必要がなくなると、ＰＣＰＩ（ｆｏｏ）は存在しなくなる。なお、この実施形態では、ミラー更新サイクルの長さは、ミラーリングアプリケーション７９０によって決定される。
【００４８】
図９Ａは、一般的なログエントリ９００Ａの詳細を示している。このログエントリは、ログエントリ番号９０１と、オペレーションフィールド（ブロック割当て、又は、ブロック消去）９０２とから構成されている。ログエントリ番号は、特定のログエントリを識別する一意的な（重複しない）番号である。ログエントリ番号は例えば、エントリがログに追加される際に、連続的に増加する番号でログエントリに割り当てられる。また、ブロックボリュームブロック番号９０４も設けられている。ブロックボリュームブロック番号は、特定のブロックを識別する。任意選択で、エントリは、ｑｔｒｅｅ識別子（又は、他のサブボリューム編成ＩＤ）９０６を有することができる。上記のように、ブロックがｑｔｒｅｅの一部である場合、ｑｔｒｅｅ識別子をブロックに関連付けることにより、選択されたｑｔｒｅｅの情報だけを宛先ミラーに伝送することができる。同様に、他の情報のためのオプションフィールド９０８を設けてもよい。この情報には、例えば、複数のボリューム構造又は他のコンテナからなる仮想ボリュームを使用する場合の、ブロックの移動に関するいわゆる「攪拌」情報がある。ＣＰ及びＰＣＰＩのエントリは、オペレーティングシステム及びブロック変更機能７９８による識別に適した任意の形に構成することができる。
【００４９】
ログエントリ９００Ａと同様に、図９Ｂは、ＰＣＰＩの消去又は作成のための例示的なログエントリ９００Ｂを示す略ブロック図である。ログエントリ９００Ｂは、作成／消去フィールド９１０、及び、ＰＣＰＩ識別子フィールド９１２を含む。作成／消去フィールド９１０は、このエントリ９００Ｂが、ＰＣＰＩの作成又は消去のロギングしているか否かを識別する。ＰＣＰＩ識別子フィールド９１２には、作成中又は破壊中のＰＣＰＩのＰＣＰＩ  ＩＤが格納される。
【００５０】
当然ながら、管理者によって、又は、自動的に（例えば、オペレーティングシステムによって）、特定のＰＣＰＩが消去された場合、宛先がソースに同期した状態を維持するために、その消去はログに記録される。例えば、ＰＣＰＩ（ｂａｒ）を消去すると、その消去を識別するエントリがログに入れられる。
【００５１】
ログは常に構築され続け、新たに消去されたブロックは変更ログにのみ記録され、アクティブマップには記録されないため、所与のログユーザがログを使用し始める場所を決定する技術が必要である。このように、ログの古いセグメントは所与のユーザによって無視され、その結果、ログのスキャンが高速化される。また、どのログユーザも使用していないログの比較的古いセグメントにおけるブロック消去はアクティブマップに伝送され、その結果、ファイルシステムはそれらのブロックを再割当て／再使用することができる。図１０を参照すると、各ログユーザは、レジストリエントリ１００５を作成する。エントリ１００５には、ミラーに対する前回の更新サイクルにおいて処理されたログ内の最終レコードのログエントリ番号を有する。このレジストリエントリによれば、ユーザは、そのユーザに関連するログの開始点に直ぐにジャンプすることができる。同様に、ユーザがログに関心がなくなった場合、レジストリエントリはレジストリから除去される。なお、一実施形態において、ログ内の最も古いレジストリエントリまでに記録されたブロック消去が全てアクティブマップに伝送された後は、そのレジストリエントリよりも古いログは消去してもよい。なぜなら、ログのその部分は、存在するいずれのユーザ及びアクティブファイルシステムにも関係しないからである。
【００５２】
図１１は、上で概ね説明したような効率の改善のための基本手順１１００の詳細を示している。まず、ＣＰ境界上に新たなＰＣＰＩを作成し、そのＣＰレコードのログエントリ番号を登録する（ステップ１１０５）。ファイルシステムが変更ログを更新していない場合、ファイルシステムは、このポイントから前方へ向かって更新を開始する。次に、ＰＣＰＩを宛先に伝送する（ステップ１１１０）。この目的のために使用可能な技術には、上に記載した「FILE SYSTEM IMAGE TRANSFER」と題するSteven Kleiman他による米国特許出願第０９／１２７，４９７号や、「FILE SYSTEM IMAGE TRANSFER BETWEEN DISSIMILAR FILE SYSTEMS」と題するSteven Kleiman他による米国特許出願第０９／４２６，４０９号に記載されているボリュームベースのリモートＰＣＰＩミラーリング技術がある。
【００５３】
現在のミラー状態に反映されている状態よりも新しい時点へのミラー更新が発生した場合、登録されたログエントリの後の最初のエントリから開始して、ミラーの更新によって反映されるログエントリを含むそのログエントリまで、ログをスキャンする（ステップ１１１５）。更新サイクルの最後は、ミラーリングアプリケーションによって指定することができ、ＣＰ境界であってもよいし、ＰＣＰＩであってもよいし、あるいは、ログの最後のような任意のポイントであってよい。ファイルシステムによって参照された新たに割り当てられたブロック、及び、ログのスキャン範囲の最後の時点において存在しているＰＣＰＩが全て、ミラーに伝送される（ステップ１１２０）。変更されたブロックの伝送が無事に終了した後、次に、既存のログエントリ番号が、スキャンされ更新された最終ログレコードのログエントリ番号で置き換えられるように、レジストリエントリを更新する（ステップ１１２５）。登録されたミラー更新が全て、１セットのログレコードを送出した後、それらのログレコード中のブロック消去は全てアクティブマップに伝送され、送出されたログレコードは消去することができる。ステップ１１１５から開始される次のミラー更新サイクルに対しても、このプロセスが繰り返される。
【００５４】
ステップ１１２０によって伝送すべきブロックのセットを判定するために、ログのスキャン範囲にある各ブロック割り当てレコードに対し、図１２に詳細を示す手順１２００を適用する。この手順はステップ１２０５から開始され、次に、ログ割当てレコードの後からログのスキャン範囲内の最後のレコードを含むそのレコードまでログ内のエントリを検査し、ブロックの消去が記録されたエントリがあるか否かを判定する（ステップ１２１０）。レコードが全く存在しない場合、そのブロックを伝送しなければならない（ステップ１２８０）。レコードが存在する場合、ログを検査し、正しい「最終レコード」、すなわち、残りのステップにおいて検査しなければならないログ範囲の終わりをマークしているレコードを識別する（ステップ１２２０〜１２４０）。まず、ＰＣＰＩ作成及び消去がＣＰ境界上に発生しているので、ブロック消去が属しているるＣＰを判定しなければならない。ログは順番に並べられているので、ブロック消去が属しているＣＰは、ブロック消去の後に記録された最初のＣＰである。したがって、ログを検査し、ブロック消去の後にＣＰが記録されているか否かを調べる（ステップ１２２０）。ブロック消去の後のスキャン範囲にＣＰが記録されていた場合、そのＣＰレコードを「終了レコード」として指定する（ステップ１２３０）。スキャン範囲にＣＰが何も記録されていなかった場合、更新サイクルの終了時点でＣＰがまだ終了していないので、スキャン範囲内の最後のエントリを「終了レコード」として指定する（ステップ１２４０）。次に、ログを検査し、ブロック割当てレコードとその最終レコードとの間にＰＣＰＩ作成レコードが存在するか否かを調べる（ステップ１２５０）。存在しなければ、そのブロックを伝送しなければならない。存在する場合は、ＰＣＰＩ作成レコードと終了レコードとの間のログレコードを検査し、ログのその範囲にそのＰＣＰＩの消去が記録されているか否かを調べる（ステップ１２６０）。何もレコードが存在しない場合、そのブロックを伝送しなければならない（ステップ１２８０）。そうでなければ、そのブロックの伝送は省略することができる（ステップ１２７０）。
【００５５】
図１３は、ブロック消去をアクティブファイルシステムに伝搬させることが出来るときを判定するのに使用される手順の詳細を示している。この手順はステップ１３０５から開始され、次いで、全てのアクティブなレジストリエントリをスキャンし、ログ内の最も古いレコードを参照するエントリを見付ける（ステップ１３１０）。次に、変更ログに記録された全てのブロック消去を空きブロックとしてアクティブファイルシステムにマーキングする（ステップ１３２０）。次に、この手順がステップ１３４０において完了する前に、ログの開始からステップ１３１０で識別されたログエントリを含むそのログエントリまでの全てのエントリを消去する（ステップ１３３０）。
【００５６】
図１４は、ブロックを消去する場合にファイルシステム層（ステップ７５０）に必要とされる変更の詳細を示している。通常、ブロックが消去される場合、そのブロックは空き（従って、再使用可能）としてファイルシステム・アクティブ・マップに、すなわち、ファイルシステム内のあらゆるブロックをトラッキングし、ブロックが割当て済みであるか、それとも空きであるかを示すメタファイルにマーキングされる。この方法を使用してミラーの管理を開始した場合、消去は変更ログに記録され、図１３に詳細を示すログフラッシュ手順は、図１３に示す詳細に従って、通常のブロック解放手順を開始する。図１４に記載した手順１４００はステップ１４０５から開始され、次いで、ファイルシステム層は、ブロックが、図１３に記載したログフラッシュ手順によって空きとしてマーキングされているか否かを判定する（ステップ１４１０）。空きとしてマーキングされている場合、標準（既存）ブロック解放メカニズムを使用して、そのブロック消去を処理する（ステップ１４４０）。空きとしてマーキングされていない場合、システムは、同期複製方法が現在使用中であるか否かをチェックする（ステップ１４２０）。使用中であれば、そのブロック消去（解放）を変更ログに記録する（ステップ１４３０）。使用中でなければ、ステップ１４５２においてこの手順が完了する前に、既存のブロック解放メカニズムが使用される（１４４０）。
【００５７】
一般に、ロギング機能は、ＣＰ（Ｎ）までミラーを更新する際に下記の例示的な規則に従う。
【００５８】
１．ＣＰ（Ａ）において割当て済みとしてログにマーキングされているブロックであって、後にＣＰ（Ｘ）によって消去済みとしてマークされるブロックを伝送しないことにより、ミラー更新伝送帯域幅使用を最適化することができる。ただし、ＣＰ（Ｙ）におけるＰＣＰＩ作成によってブロックが再び参照されない限りＡ＜＝Ｘ＜＝Ｎ、Ａ＜＝Ｙ＜＝Ｘ＜＝Ｎであり、Ｚ＞Ｎである場合、ＰＣＰＩはＣＰ（Ｚ）まで消去されない。
【００５９】
２．ログ内のレコードは、当該処理の正しい順序を形成しなければならない。複数の処理が同時に実行されている場合にそれらを連番に並び替える周知の方法が文献に記載されている。
【００６０】
３．オペレーティングシステムが作業の対象としている現在のＣＰがＣＰ（Ｚ）であるものと仮定した場合、ＣＰ（Ｎ）のエントリを含むそのエントリまでの全てのエントリが、全ての宛先に伝送され、処理された後、すなわち、ＣＰ（Ｎ）の全てのレコードを反映する全てのレジストリエントリが処理され、無事に伝送された後、Ｘ＜＝ＭＩＮ（Ｎ，Ｚ−１）であれば、ＣＰ（Ｘ）の一部であるログ内の全てのエントリについて、消去をアクティブマップに安全に伝搬させることができる。
【００６１】
４．部分的にのみ現在のＣＰよりも古い場合がある日付までミラーが維持される場合、消去がアクティブマップに伝搬される限り（項目３のたびに）、及び、ミラーがＣＰ（Ｎ）まで安全に更新されたことが確認されるまでログエントリが削除されないかぎり、ＣＰ（Ｎ）を含むそのＣＰまでの全てのＣＰのブロックをログに伝送することができる。
【００６２】
５．最後に、複数のミラー（例えば、Ｎ方向「展開」）のソースとしてファイルサーバを使用したい場合、所与のＣＰ又はそれ以降において全てのミラーが安全になるまで、ログからエントリが何も削除されず、又は、消去は所与のＣＰのアクティブマップに伝搬されない。
【００６３】
以上が、本発明の例示的実施形態の詳細な説明である。本発明の思想及び範囲から外れることなく、種々の変更及び追加を施すことが可能である。例えば、この説明は、種々のリンクによって接続された種々のコンピュータ、及び／又は、ファイルサーバ構成に適用することができる。また、本発明の教示は、コンピュータ上で実行されるコンピュータ読取可能媒体のプログラム命令を含む、ハードウェアやソフトウェアのような形で実施することができ、また、ハードウェアとソフトウェアの組み合わせの形で実施してもよい。従って、この説明は、単なる例として解釈すべきものであり、本発明の範囲を制限するものではない。
【図面の簡単な説明】
【００６４】
【図１】従来の実施形態によるＰＣＰＩ手順をまさに受けようとしている例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図２】ＰＣＰＩｉｎｏｄｅを含む従来の実施形態による図１の例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図３】データブロックが書き換えられた後の従来の実施形態による例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図４】従来の実施形態によるソースファイルサーバから宛先ファイルサーバへのネットワークを介した例示的リモートミラーリングを示す略ブロック図である。
【図５】従来の実施形態による、ブロックの変更をソースファイルサーバから宛先ファイルサーバへ伝送しなければならないか否かを判定するための、図４のブロックディフェレンサによって使用される判断テーブルを示す図である。
【図６】本発明の原理が内部で実施される例示的ネットワーク、並びに、ソースファイルサーバ及び宛先ファイルサーバを含むファイルサーバ環境を規定する略ブロック図である。
【図７】本発明の例示的実施形態による、図６のファイルサーバと共に使用される例示的ストレージオペレーティングシステムの略ブロック図である。
【図８】本発明の例示的実施形態に従って使用される、変更されたブロック及び関連情報の例示的ログを示す図である。
【図９Ａ】本発明の一実施形態による例示的ログエントリを示す図である。
【図９Ｂ】本発明の一実施形態によるＰＣＰＩ作成／消去の例示的ログエントリを示す図である。
【図１０】本発明の一実施形態によるログユーザに関連するレジストリエントリを示す図である。
【図１１】本発明の一実施形態によるログを使用してミラーを更新するための手順を示すフロー図である。
【図１２】本発明の一実施形態による、ブロックを伝送すべきか否かを判定するための手順のステップの詳細を示すフロー図である。
【図１３】本発明の一実施形態による、ブロック消去をアクティブファイルシステムに伝搬させることが出来るときを判定するための手順のステップの詳細を示すフロー図である。
【図１４】本発明の一実施形態による、ブロックを消去するための手順のステップの詳細を示すフロー図である。
【図１】
2007517290.tif 000003
【図２】
2007517290.tif 000004
【図３】
2007517290.tif 000005
【図４】
2007517290.tif 000006
【図５】
2007517290.tif 000007
【図６】
2007517290.tif 000008
【図７】
2007517290.tif 000009
【図８】
2007517290.tif 000010
【図９Ａ】
2007517290.tif 000011
【図９Ｂ】
2007517290.tif 000012
【図１０】
2007517290.tif 000013
【図１１】
2007517290.tif 000014
【図１２】
2007517290.tif 000015
【図１３】
2007517290.tif 000016
【図１４】
2007517290.tif 000017
【手続補正書】
【提出日】平成18年8月21日(2006.8.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソースから宛先ミラーへの更新データ識別子の伝送の効率を向上させるシステムであって、
時間経過による差分変化のエントリを記録するログと、
まだ割当てられていないデータ識別子であって、その後消去されるデータ識別子を、更新伝送サイクル内で伝送させる変更ブロック機能と
からなるシステム。
【請求項２】
前記変化のそれぞれに関連する前記エントリは、ボリュームブロック番号、及び、前記データ識別子のそれぞれの割当て及び消去のうちのいずれか一方を示すオペレーションフラグをそれぞれ含む、請求項１に記載のシステム。
【請求項３】
前記ログは、ＣＰ作成時刻の後、ＣＰ作成時間内において消去されたブロックを記憶するように構成され、その際に前記伝送は行われるが、前記消去されたブロックは消去されたものとしてストレージオペレーティングシステムのアクティブマップ上には示されず、それによって、前記消去されたブロックが不注意により再使用されることがないように構成される、請求項２に記載のシステム。
【請求項４】
前記ログのユーザのそれぞれは、該ユーザに関連する第１のコンシステンシ・ポイント及び第１のＣＰを含むレジスタ・エントリを有し、前記ストレージオペレーティングシステムは、前記ユーザによって、前記第１のコンシステンシ・ポイント及び前記第１のＣＰからスキャンを開始するように構成される、請求項３に記載のシステム。
【請求項５】
前記変更ブロック機能は、まだ割り当てられていないデータ識別子であって、その後消去されるデータ識別子を前記更新伝送サイクル内で伝送させるのみである、請求項１に記載のシステム。
【請求項６】
ストレージオペレーティングシステムにおけるデータ識別子の２つの離れたコンシステンシ・ポイント（ＣＰ）間における更新されたデータ識別子のソースから宛先ミラーへの伝送の効率を向上させる方法であって、
前記２つの離れたＣＰ間の変化のそれぞれに関連するエントリをログに記録するステップと、
前記ログをスキャンし、まだ割当てられていないデータ識別子であって、その後消去されるデータ識別子を、２つのコンシステンシ・ポイント終了時刻間の更新伝送サイクル内において生成するステップと
からなる方法。
【請求項７】
前記変化のそれぞれに関連する前記エントリは、ボリュームブロック番号、及び、前記データ識別子のそれぞれの割当て及び消去のうちのいずれか一方を示すオペレーションフラグをそれぞれ含む、請求項６に記載の方法。
【請求項８】
ＣＰ作成時刻の後、ＣＰ作成時間内において消去されたブロックをログに記憶することを更に含み、その際に前記伝送は行われるが、ストレージオペレーティングシステムのアクティブマップ上において、前記消去されたブロックの指示は消去されたものとして省略され、それによって、前記消去されたブロックが不注意により再使用されることがない、請求項７に記載の方法。
【請求項９】
前記ログのユーザのそれぞれは、該ユーザに関連する第１のコンシステンシ・ポイント及び第１のＣＰを含むレジスタ・エントリを有し、前記ストレージオペレーティングシステムは、前記ユーザによって前記第１のＣＰから開始されるように構成される、請求項８に記載の方法。
【請求項１０】
前記最も古い第１のＣＰより前に発生するエントリを前記ログから削除することを更に含む、請求項９に記載の方法。
【国際調査報告】
2007517290.tif 000018
2007517290.tif 000019