JP4779012B2 - 瞬時ボリューム復元のためのオン・デマンドでデータを復元するシステム、および方法 - Google Patents

Description

[発明の分野]
本発明はファイルシステムに関し、詳しくは、オン・デマンドで復元可能な不在ブロックを有する１以上のファイルを有するボリュームを含むファイルシステムに関する。

[発明の背景]
ストレージシステムは一般に、必要に応じて情報を入れたり、取り出したりすることが可能な１以上の記憶装置を備える。ストレージシステムは、とりわけ、当該システムによって提供されるストレージサービスを支援するストレージ・オペレーションを実施することにより、当該システムを機能的に編成するストレージ・オペレーティング・システムを含む。ストレージシステムは、種々のストレージ・アーキテクチャにしたがって実施することができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及び、クライアント又はホストコンピュータに直接取り付けられたディスクアセンブリのようなストレージ・アーキテクチャにしたがって実施される場合がある。記憶装置は通常、ディスクアレイとして編成されたディスクドライブであり、ここで、「ディスク」という用語は通常、内蔵型の回転磁気媒体記憶装置を意味する。この文脈におけるディスクという用語は、ハード・ディスク・ドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同じ意味で使用される。

ディスクアレイ上での情報の格納は、ディスク空間の全体的論理配置を規定する、複数の物理ディスクからなる１以上のストレージボリュームとして実施されることが好ましい。ボリューム内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ(Redundant Array of Independent Disks)として運用される場合がある。大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所与の数の物理ディスクにわたってデータストライプを冗長書き込みし、そのストライプ状データに対する冗長情報（パリティ）を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。各ＲＡＩＤグループの物理ディスクは、ストライプ状データを格納するように構成されたディスク（すなわち、データディスク）と、そのデータに関するパリティを格納するように構成されたディスク（すなわち、パリティディスク）とを含む。その後、ディスクが故障したときに、そのパリティを読み出すことで、失われたデータを復元することが可能になる。「ＲＡＩＤ」という用語、およびその種々の実施形態は既知のものであり、D. A. Patterson、G. A. Gibson、及びR. H. Katzによる「A Case for Redundant Arrays of Inexpensive Disks (RAID)」、１９８８年６月、データ管理に関する国際会議論文（ＳＩＧＭＯＤ）、に開示されている。

ストレージシステムのストレージ・オペレーティング・システムは、ディスク上に格納される情報をディレクトリ、ファイル、及びブロックの階層構造として論理編成するための、ファイルシステムのような高レベルモジュールを実施する場合がある。例えば、ディスク上の各ファイルは、そのファイルの実際のデータのような情報を記憶するように構成された一組のデータ構造（すなわち、ディスクブロック）として実施される場合がある。データブロックは、ファイルシステム内においてユーザデータの格納にも、メタデータの格納にも使用される場合がある。こうしたデータブロックは、ボリュームブロック番号（ｖｂｎ）空間の中で編成される。ファイルシステムは、ｖｂｎ空間内におけるブロックの使用と中身をコントロールし、データブロックをｖｂｎ空間の中で論理ボリュームとして編成する。必須ではないが、各論理ボリュームは、その論理ボリューム独自のファイルシステムに関連する場合がある。ファイルシステムのサイズをｎブロックとした場合、ファイルシステムは通常、ゼロからｎ−１までの連続した範囲のｖｂｎから構成される。

既知のタイプのファイルシステムの１つは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。データブロックからストレージシステムのメモリにデータブロックを取得（読み出し）し、新たなデータで「汚す」場合、書き込み性能を最適化するために、以後、そのデータブロックは、ディスク上の新たな位置に格納される。また、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上に実質的に連続的に配置されるように、最適に近いレイアウトを維持するように最適化される場合がある。この最適なディスクレイアウトにより、ディスクに対する効率的なアクセス・オペレーションが可能となり、特に、シーケンシャル読み出しオペレーションの場合に効率的なアクセス・オペレーションが可能となる。ストレージシステム上で動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＷｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＦＡＦＬ）ファイルシステムである。

ストレージ・オペレーティング・システムは更に、ＲＡＩＤシステムのようなストレージモジュールを実施し、入出力（Ｉ／Ｏ）処理にしたがって、ディスクに対する情報の記憶、及び読み出しを管理する場合がある。また、ＲＡＩＤシステムは、ストレージシステムにおけるパリティ操作にも責任を負う。なお、ファイルシステムは、自分のｖｂｎ空間内のデータディスクしか「参照」することができない。パリティディスクは、ファイルシステムから隠され、したがって、ＲＡＩＤシステムからしか参照することができない。ＲＡＩＤシステムは通常、すべてのＲＡＩＤグループのすべてのディスクにわたってディスクブロックが連結されるように、ＲＡＩＤグループを１つの大きな物理ディスク（すなわち、物理ボリューム）に編成する。そして、ファイルシステムによって管理される論理ボリュームは、ＲＡＩＤシステムによって管理される物理ボリューム「上に配置」（上に分散）される。

ストレージシステムは、情報配送のクライアント／サーバモデルにしたがって動作するように構成され、それによって、多くのクライアントが、システム上に格納されたディレクトリ、ファイル、及びブロックにアクセスすることができる場合がある。このモデルでは、クライアントは、例えば、ポイント・ツー・ポイントリンク、共有ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはインターネットのような公共ネットワーク上で実施される仮想私設ネットワークを介してストレージシステムに接続するために、データベース・アプリケーションのようなコンピュータ上で実行されるアプリケーションを含む場合がある。各クライアントは、それらのネットワークを介してファイルシステム・プロトコル・メッセージ（パケットの形をしている）をストレージシステムに対して発行することにより、ファイルシステムのサービスを要求することができる。従来のコモン・インターネット・ファイル・システム（ＣＩＦＳ）プロトコルやネットワーク・ファイル・システム（ＮＦＳ）プロトコルといった複数のファイルシステムプロトコルをサポートすることにより、ストレージシステムの利便性は向上する。

クライアント要求に応じてファイルのブロックをアクセスするとき、ファイルシステムはｖｂｎを指定する。ｖｂｎは、ファイルシステムとＲＡＩＤシステムの境界において、物理ボリュームのＲＡＩＤグループ内の特定ディスク（ディスク、ｄｂｎ）上のディスクブロック番号（ｄｂｎ）に変換される。なお、クライアント要求は通常、特定のファイルオフセットに送られ、ファイルシステムは、そのファイルオフセットをファイルブロック番号（ｆｂｎ）に変換する。ファイルブロック番号（ｆｂｎ）は、特定ファイル内のブロックオフセットを表わす。例えば、ファイルシステムが４ＫＢブロックを使用する場合、あるファイルのｆｂｎ６は、そのファイル内の２４ＫＢから始まり、２８ＫＢまでのデータブロックを表わし、２８ＫＢの所からｆｂｎ７が始まる。ファイルシステムは、ｆｂｎを適当なｖｂｎに変換する。ｖｂｎ空間内、およびｄｂｎ空間内の各ブロックは通常固定であり、例えば、４Ｋバイト（ＫＢ）のサイズを有する。したがって、ｄｂｎ空間においてディスク上に格納される情報と、ｖｂｎ空間においてファイルシステムによって編成される情報との間には、通常、一対一の対応がある。ＲＡＩＤシステムによって指定される（ｄｉｓｋ、ｄｂｎ）位置は更に、ストレージ・オペレーティング・システムのディスクドライバシステムによって、指定されたディスク上の複数のセクタに変換される（例えば、ＲＡＩＤヘッダを有する４ＫＢブロックは、５１２バイト、または５２０バイトの８個、または９個のディスクセクタに変換される）。

次に、要求されたブロックがディスクから読み出され、メモリのバッファ・キャッシュに、そのファイルのバッファ・ツリーの一部として格納される。バッファ・ツリーとは、バッファ・キャッシュに格納され、ファイルシステムによって管理されるファイルのブロックの内部表現である。簡単に言えば、バッファ・ツリーは、そのファイルのルート（トップレベル）にｉｎｏｄｅを有する。ｉｎｏｄｅは、ファイルに関するメタデータのような情報の格納に使用されるデータ構造である。一方、データブロックは、ファイルの実際のデータの格納に使用される構造である。ｉｎｏｄｅに格納される情報には、例えば、ファイルの所有者、ファイルのアクセス・パーミッション、ファイルのサイズ、ファイルタイプ、およびそのファイルのデータブロックのディスク上の位置を示すリファレンスなどが挙げられる。ファイルデータの位置を示すリファレンスは、ポインタによって提供され、ファイルに含まれるデータの量によっては、ポインタは、間接ブロックを参照し、更に、データブロックを参照する場合がある。ファイルシステムとＲＡＩＤシステムの間においてディスク上のデータをアクセスするときの効率を上げるために、各ポインタは、ｖｂｎとして実施される場合もある。

ＲＡＩＤシステムは、基礎となる物理ディスクのジオメトリに関する情報（例えば、各ディスクにおけるブロック数）を、ディスク上に格納されたＲＡＩＤラベル上に保持する。ＲＡＩＤシステムは、書き込みアロケーション・オペレーションを実施する際に使用されるｖｂｎからｄｉｓｋ、ｄｂｎへのマッピングを作成し、管理するために、そのジオメトリ情報をファイルシステムに提供し、読み出しオペレーションの際に、ｖｂｎをディスク位置に変換する。アクティブ・マップ、スナップマップ、空間マップ、及び概要マップのようなブロック・アロケーション・データ構造は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムのようなファイルシステム内におけるブロックの使用状況を表わす。これらのマッピングデータ構造は、ジオメトリとは無関係であり、ファイルシステムの書き込みアロケータによって論理ボリュームの既存のインフラストラクチャとして使用される。ブロック・アロケーション・データ構造の例については、２００２年６月２７日に刊行されたBlake Lewis他による「Instant Snapshot」と題する米国特許出願公開公報第ＵＳ２００２／００８３０３７Ａ１号に記載されており、この出願は、参照により本明細書に援用される。

ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは通常、ファイルシステムにおけるイベント（例えば、ファイル内のブロックが汚されることなど）に応答して、論理ボリューム中のブロックの書き込みアロケーションを実施する。書き込みアロケーションを行うとき、ファイルシステムは、ブロック・アロケーション・データ構造を使用して、汚れたブロックの書き込み先となる、自分のｖｂｎ空間内にある空きブロックを選択する。パリティディスクの使用を最適化するために、選択されるブロックは通常、各ＲＡＩＤグループについて複数のディスクにわたって同じ位置にあるものが選択される。例えば、パリティ・アップデート・オペレーションのオーバラッピングを可能にするために、位置的ブロックのストライプは、特にＲＡＩＤグループによって異なる場合がある。書き込みアロケーションを行うとき、ファイルシステムは、各ディスクの小さな部分（各ディスク内の深さ方向に並ぶ数ブロックに対応するもの）を走査し、実質的に、１つのＲＡＩＤグループにつき複数のストライプを規定する。具体的には、ファイルシステムは、書き込みアロケーションの際に、ｖｂｎからディスク、ｄｂｎへのマッピングを使用して、１つのＲＡＩＤグループにつき、同じストライプ上にある複数のｖｂｎを選択する。

ストレージシステムの動作中に、ボリューム（または、ファイルやディレクトリのような他のデータコンテナ）は損傷を受けることがあり、例えば、基礎となる記憶装置に対する物理的ダメージ、ストレージシステム上で実行されているストレージ・オペレーティング・システムにおけるソフトウェア・エラー、またはボリューム上のデータを変更する不適切に実行されたアプリケーション・プログラム等によって損傷を受けることがある。そのような状況では、管理者は、そのボリュームを即座にマウントし、エキスポートし、出来る限り迅速にそのボリュームをクライアントからアクセスできるようにしたい場合がある。そのためには、そのボリューム（かなり大きい場合もある）中のデータを可能な限り早く復元しなければならない。ボリューム中のデータの復元は、例えば、記憶装置がＲＡＩＤ構成で使用されている場合、記憶されたパリティ情報を使用してデータを復元することよりなされることが多い。その際、復元は、オン・ザ・フライで実施される場合があり、その結果、データにアクセスできない時間は、実質的に識別できないくらいになる場合がある。

状況によっては、データの復元が不可能な場合もある。その場合、管理者には幾つかの選択肢がある。その１つは、従来の完全復元オペレーションを開始し、他のストレージシステムに格納されたある時点におけるイメージから、ボリュームの直接コピーを実施することである。大抵の場合、アプリケーション一貫性を確保するために、通常動作を開始する前に、ボリュームデータとメタデータを全てコピーしなければならない。データの完全コピーを完了するまでに要する時間は、多くの場合、ビジネスとして重要なアプリケーションを動作させる機会を失う点で、犠牲を払う。ただし、例えばテラバイトといった相当な量のデータを転送するために要する時間は数日にわたることもあるため、そのような「力づく」のデータコピーは能率が悪い。同様の欠点は、テープデバイスや他のオフラインデータ記憶装置からのデータの復元にも存在する。管理者がボリュームを即座にマウントし、エキスポートすることを可能にするもう１つの選択肢は、ボリュームの中身がホール（穴）であるホール充填ボリュームを生成することである。この文脈において、ホールとは、ゼロのブロック全体、またはボリュームのバッファツリー構造内に格納された他の所定のポインタ値を意味する。そのようなホールの使用の一例は、Vijayan Rajanによる「WRITABLE READ-ONLY SNAPSHOTS」と題する米国特許出願第１０／４１２，４７８号に記載されており、その内容は、参照により本明細書に援用される。

ホール充填環境では、クライアントから要求があるまで、実際のデータが外部記憶装置から読み出されることはない。ただし、そのようなホール充填技術の顕著な欠点は、ボリュームのディスク上に適当な数のゼロ充填ブロックを生成するために、反復書き込みオペレーションを必要とすることである。つまり、データの読み出しのために追加の読み出しオペレーションを必要とするデータコンテナを実施するためにホールを使用した場合、ファイル、および／またはボリュームのバッファ・ツリー全体を作成中にディスクに書き込まなければならない。必要な書き込みオペレーションを実施するために必要となる時間は、実質的に、そのボリューム、またはファイルのサイズによって左右される。したがって、ホール充填ボリュームの作成は、ボリュームに対する迅速なデータアクセスを必要とすることから、現実的でないことが多い。

ボリュームを迅速に取り戻す（復元する）ことが必要とされるストレージ環境は、通常、ニア・ライン・ストレージサーバの使用を必要とする。本明細書において、「ニア・ライン・ストレージサーバ」という用語は一般に、長期アーカイブのために、１以上の一次ストレージシステムから転送されたデータを格納するように構成された二次ストレージシステムを意味する。ニア・ライン・ストレージサーバは、各一次ストレージシステムによって提供されるデータストレージ（例えば、ボリューム）のバックアップを提供するために、そのようなストレージ環境において使用される場合がある。その結果、ニア・ライン・ストレージサーバは通常、バルクデータ復元オペレーションを実施するように最適化されるが、個々のデータアクセス要求に対するサービスを提供するときには、性能低下を受ける。後者の状況は、一次ストレージシステムが故障に遭い、一次ストレージシステムのボリュームが損傷し、クライアントがそのボリュームのデータをアクセスするために、データアクセス要求をサーバへ送らなければならなくなったときに発生する。また、この状況では、そのようなデータアクセスを可能にするために、ニア・ライン・ストレージサーバに関連する適当なネットワークアドレスを有するようにクライアントを再設定しなければならない。

[発明の概要]
本発明は、二次ストレージシステム（外部記憶装置）からデータをオン・デマンドで復元するために使用される、ストレージシステムのファイルシステム内の散在ボリュームをインスタンス化するシステム、および方法を提供することによって、従来技術の欠点を克服する。本明細書に記載されるように、散在ボリュームは、ストレージシステムに接続されたディスク上に（すなわち、ローカルボリューム上に）ローカルに格納されていない少なくとも１つのブロック（すなわち、不在ブロック）を有する１以上のファイルを格納する。データブロック（または、ホール環境におけるゼロのブロック）を即座に読み出さないことにより、最小限の書き込みオペレーションしか必要とせずに、散在ボリュームを生成し、迅速にエキスポートすることができる。不在ブロックの欠落データは、代替の（大抵はリモートの）外部記憶装置に格納され、例えば、リモート・フェッチ・オペレーションを使用して取得される。復元されたボリュームが有効化された後、そのボリュームは、新たな書き込みオペレーションを含むいかなるファイルオペレーションについても、アクセス可能になる。受信した書き込みオペレーションは、新たなブロックを割り当て、その新たに割り当てられたブロックを参照するようにブロックポインタを変更することにより、普通に処理される。

ブロックポインタが以前に不在としてマーキングされていた場合、そのブロックポインタは、リモートに格納された古いデータがアップデータされたときに上書きされる。その結果、ストレージシステムは、そのデータをリモートに取得する必要がなくなる。

例示的実施形態として、散在ボリュームは、外部記憶装置上のデータを指し示す特殊なポインタを使用するボリューム・インフラストラクチャ・メタデータを使用して初期化される。一実施形態では、特殊なポインタ（ＡＢＳＥＮＴポインタ）を使用して、データの読み出しに特殊な読み出しオペレーションが必要であることを分かるようにする場合がある。そのようなＡＢＳＥＮＴポインタの使用は、「瞬時」の完全復元であるかのような錯覚をクライアントのようなユーザに与え、それによって、従来の完全復元オペレーションに伴う長い待ち時間を回避する。その後、そのデータは「オン・デマンドで復元」することができる。本明細書では、この用語は、データ要求が発行されるのを待ってから、ストレージシステム、及びネットワークリソースを消費して、データを取得することを意味する。そのようなデータ復元は、クライアントがストレージシステムに対して発行するデータアクセス要求に応答して達成され、または、例えばバックグラウンドプロセスの実行中にデータ要求を生成する当該システムの復元モジュールによって達成される。

本発明の１つの特徴は、復元が開始された後は、例えば、散在ボリュームに対する新たな変更（書き込みオペレーション）の受け入れを含むあらゆる処理について、散在ボリュームを利用できる点にある。そのような書き込みオペレーションは散在ボリュームに書き込まれ、ＡＢＳＥＮＴポインタはいずれも、何らかの新たなポインタによって上書きされ、それによって、読み出しオペレーションを受信したときに、データを外部記憶装置から取得するのではなく、散在ボリュームから取得しなければならないことを示すことができる。したがって、特定ブロックにＳＰＡＲＳＥ（散在）というラベルが付されていて、書き込みオペレーションがそのブロックに対するものであった場合、そのブロックはもはや、ＳＰＡＲＳＥというラベルを持たなくなる。後続の読み出しオペレーションはいずれも、新たに書き込まれたデータを返すことになり、リモート・フェッチ・オペレーションを必要としない。

本発明の一態様によれば、復元モジュールは、散在ボリュームをスキャンし、ＡＢＳＥＮＴポインタを有するブロックを探すように構成された新規の要求発生器として実施される。そのようなブロックを探すとき、要求発生器は、リモート・フェッチ・オペレーションを開始し、各ＡＢＳＥＮＴポインタによって参照される欠落データを外部記憶装置から取得する。次に、取得されたデータは、散在ボリュームに入れるために、書き込みアロケーションされる。欠落データを有する散在ボリュームを埋める動作は、ファイルシステム上に不在ブロックがなくなるまで、マルチフェイズ計画シーケンスに関連して行われることが望ましい。例えば、それらのフェイズは、ｉｎｏｄｅファイル、特殊なデータコンテナ、ディレクトリ、及びファイルを含む。代替実施形態において、それらのフェイズは、ｉｎｏｄｅファイル、特殊なデータコンテナ、ディレクトリ、及びファイルである場合がある。特殊なデータコンテナは、例えば、特殊なディレクトリのような、隠しメタデータコンテナ、またはファイルシステムメタデータコンテナからなる。この時点で、散在ボリュームは、完全に復元された独立したローカルボリュームに変わる。また、要求発生器は、そのキャッシュをクライアントが現在必要としていない取得データによって汚さないようにするために、ストレージシステムのバッファ・キャッシュをバイパスする特殊なロードパスを使用するように構成される場合がある。さらに、要求発生器は、一連のリモート・フェッチ・オペレーションに関連するデータ読み出しを改善するために、先読み機能を実施する場合がある。

本発明の他の態様によれば、ストレージシステムのポンプモジュールは、要求発生器に対するフロー制御を提供する。散在ボリューム中の欠落したデータを求める未処理の要求の数が所定の閾値に達すると、ポンプモジュールは、要求発生器を調節し、要求発生器が生成する要求の数を低速化させるか、または要求の生成を一時的に中断させる。ポンプモジュールは更に、優先順位決定ポリシーを実施する場合があり、例えば、利用可能なシステムリソースが限られているときに欠落データを求めて生成された要求よりも、クライアントが発行した要求に優先順位を与えるような優先順位決定ポリシーを実施する場合がある。

有利なことに、故障したローカルボリュームを迅速に復元するために、ストレージシステムの散在ボリュームは、インスタンス化される場合がある。その目的のために、要求発生器とポンプモジュールは協働し、ストレージシステムに物理的に記憶されていないデータに対する効率的アクセスを可能にする。データアクセス要求に応じる前に、ローカルボリューム全体のコピーを転送する必要はない。また、それらの新規のモジュールによれば、欠落ブロックを最終的に全て散在ボリューム上に確実に復元することができ、そのボリュームを効率的な方法で完全に独立したボリューム状態にすることができる。

本発明の他の利点は、復元オペレーションの最中にも、リモート外部記憶装置へのバックアップオペレーションを再開できることである。その結果、新たなクライアントアップデートをバックアップすることができ、その結果、万が一、二次災害復元オペレーションを開始しなければならない場合でも、後で復元することが可能になる。

本発明の上記の利点、及び他の利点は、添付の図面と併せて下記の説明を読むことで明らかになるであろう。図中、同じ符号は、同一の構成要素、または機能的に類似の構成要素であることを意味する。

[例示的実施形態の詳細な説明]
Ａ．ネットワーク環境
図１は、本発明とともに有利に使用されるストレージシステム１２０ａを含む環境１００を示す略ブロック図である。ストレージシステムは、ディスクアレイ１６０のディスク１３０のような記憶装置上での情報の編成に関するストレージサービスを提供するコンピュータである。ストレージシステム１２０ａは、システムバス１２５によって相互接続されたプロセッサ１２２、メモリ１２４、ネットワークアダプタ１２６、及びストレージアダプタ１２８を含む。ストレージシステム１２０ａは、ストレージ・オペレーティング・システム２００を更に含み、ストレージ・オペレーティング・システム２００は、ファイルシステムのような高レベルモジュールを実施し、情報をディレクトリ、ファイル、および仮想ディスクと呼ばれる特殊なタイプのファイル（以後、「ブロック」）の階層構造としてディスク上に論理編成する。

図示の実施形態において、メモリ１２４は、ソフトウェア・プログラム・コードを記憶するために、プロセッサ、及びアダプタによってアドレス指定可能な複数の記憶場所を有する。メモリの一部は、本発明に関連する特定のデータ構造を記憶するためにバッファ・キャッシュ１７０として更に編成される。さらに、プロセッサ、及びアダプタは、そのソフトウェア・コードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む。ストレージ・オペレーティング・システム２００は、その一部が通常、メモリに常駐し、それらの処理要素によって実行され、とりわけ、ストレージシステムにより実行されるストレージ・オペレーションを実施することにより、システム１２０ａを機能的に編成する。当業者には明らかなように、本明細書に記載する本発明の技術に関連するプログラム命令の記憶、及び実行には、他の処理手段や、種々のコンピュータ読み取り可能媒体を含む他の記憶手段を使用してもよい。

ネットワークアダプタ１２６は、コンピュータネットワーク１４０を介してストレージシステム１２０ａをクライアント１１０に接続するために必要とされる機械的、電気的、及び信号的回路を含む。コンピュータネットワーク１４０は、ポイント・ツー・ポイント接続であってもよいし、ローカル・エリア・ネットワーク（ＬＡＮ）やワイド・エリア・ネットワーク（ＷＡＮ）のような共有媒体であってもよい。例えば、コンピュータネットワーク１４０は、イーサネット(R)・ネットワークやファイバ・チャネル（ＦＣ）・ネットワークとして実施される場合がある。クライアント１１０は、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のような所定のプロトコルにしたがって、データフレーム、またはデータパケットをやりとりすることにより、ネットワーク１４０を介してストレージシステムと通信することができる。

クライアント１１０は、アプリケーション１１２を実行するように構成された汎用コンピュータであってもよい。さらに、クライアント１１０は、情報配送のクライアント／サーバモデルにしたがって、ストレージシステム１２０ａと通信する場合がある。すなわち、クライアントがストレージシステムのサービスを要求すると、ストレージシステムは、ネットワーク１４０を介してパケット１５０をやりとりすることにより、クライアントによって要求されたサービスの結果を返すことができる。クライアントは、ファイルやディレクトリの形をした情報にアクセスする場合、ＴＣＰ／ＩＰ上で実施されるコモン・インターネット・ファイル・システム（ＣＩＦＳ）プロトコルやネットワーク・ファイル・システム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを有するパケットを発行する場合がある。あるいは、クライアントは、ブロックの形をした情報にアクセスする場合、「ＳＣＳＩ ｏｖｅｒ ＴＣＰ（ｉＳＣＳＩ）」プロトコルや、「ＳＣＳＩ ｏｖｅｒ ＦＣ（ＦＣＰ）」プロトコルのようなブロックベースのアクセスプロトコルを有するパケットを発行する場合がある。

ストレージアダプタ１２８は、システム１２０ａ上で実行されるストレージ・オペレーティング・システム２００と協働し、ユーザ（またはクライアント）によって要求された情報を取得する。この情報は、ビデオテープ、光学媒体、ＤＶＤ、磁気テープ、バブルメモリ、電気的ランダムアクセスメモリ、及びＭＥＭＳのような書き込み可能なストレージデバイス媒体、及びその他、データやパリティ情報を記憶するように構成された任意の同様の媒体のような、書き込み可能なストレージデバイス媒体の任意のタイプのアタッチド・アレイに格納することができる。ただし、本明細書に例示されるように、情報は、アレイ１６０のＨＤＤ、及び／又はＤＡＳＤのようなディスク１３０に記憶することが好ましい。ストレージアダプタは、従来の高性能ＦＣシリアルリンク・トポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を含む。

アレイ１６０上での情報の格納は、一群の物理的ストレージディスク１３０を含む１以上のストレージ「ボリューム」として実施されることが好ましく、それらのディスクストレージ１３０が協働して、ボリューム上のボリュームブロック番号（ｖｂｎ）空間の全体的論理配置を決定する。

各論理ボリュームは一般に、必須ではないが、そのボリューム独自のファイルシステムを有する。論理ボリューム／ファイル内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent Disks）として運用される場合がある。ＲＡＩＤ−４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所与の数の物理ディスクにわたってデータストライプを冗長書き込みし、そのストライプ状データに関するパリティ情報を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例は、ＲＡＩＤ−４レベル実施形態である。ただし、当然ながら、他のタイプ、及び他のレベルのＲＡＩＤ実施形態を本明細書に記載する本発明の原理にしたがって使用することも可能である。

さらに、第２のストレージシステム１２０ｂがネットワーク１４０に相互接続される。第２のストレージシステム１２０ｂは、ニア・ライン・ストレージサーバとして構成される場合がある。ストレージシステム１２０ｂは通常、ストレージシステム１２０ａと同様のハードウェアを備える。ただし、ストレージシステム１２０ｂは、当該ストレージシステムをニア・ライン・ストレージサーバとして使用するための改変されたストレージ・オペレーティング・システムを実行する。代替実施形態として、環境１００は、複数のさらに別のストレージシステム（本明細書では、まとめて１２０と記す）を有する場合がある。

Ｂ．ストレージ・オペレーティング・システム
ディスク１３０へのアクセスを可能にするために、ストレージ・オペレーティング・システム２００は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、仮想化モジュールと協働し、ディスク１３０によって提供される記憶空間を仮想化する。ファイルシステムは、情報を名前付きのディレクトリ、及びファイルの階層構造としてディスク上に論理編成する。ディスク上の各ファイルは、データのような情報を格納するように構成された一組のディスクブロックとして実施される一方、ディレクトリは、特殊なフォーマットのファイルとして実施され、その中に他のファイルやディレクトリの名前、及びそれらへのリンクを格納する。仮想化モジュールにより、ファイルシステムは、情報をブロックの階層構造としてディスク上に更に論理編成することができ、それを名前付き論理ユニット番号（ＬＵＮ）としてエキスポートすることができる。

例示的実施形態として、ストレージ・オペレーティング・システムは、カリフォルニア州、サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰオペレーティングシステムとして実施されることが好ましい。このオペレーティングシステムは、Ｗｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＦＡＦＬ）ファイルシステムを実施する。ただし、当然ながら、任意の適当なストレージ・オペレーティング・システムを本明細書に記載する本発明の原理にしたがって使用するために拡張し、使用してもよい。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のファイルシステムを指すものとして、広い意味で解釈しなければならない。

図２は、本発明とともに有利に使用されるストレージ・オペレーティング・システム２００を示す略ブロック図である。ストレージ・オペレーティング・システムは、統合ネットワーク・プロトコルスタックを形成するように編成された一連のソフトウェア層を含み、詳しくは、ストレージシステムに格納された情報をクライアントがブロックアクセスプロトコルとファイルアクセスプロトコルを使用してアクセスするためのデータパスを提供するマルチプロトコルエンジンを含む。プロトコルスタックは、ＩＰ層２１２、並びにそれを支持する搬送機構であるＴＣＰ層２１４、及びユーザ・データグラム・プロトコル（ＵＤＰ）層２１６のようなネットワークプロトコル層に対するインタフェースを提供する、ネットワークドライバ（例えば、ギガビットイーサネットドライバ）のメディアアクセス層２１０を含む。ファイルシステムプロトコル層は、マルチプロトコルファイルアクセスを提供し、その目的のために、ダイレクト・アクセス・ファイル・システム（ＤＡＦＳ）プロトコル２１８、ＮＦＳプロトコル２２０、ＣＩＦＳプロトコル２２２、及びハイパー・テキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル２２４を含む。ＶＩ層２２６は、ＶＩアーキテクチャを実施し、ＤＡＦＳプロトコル２１８に必要とされるＲＤＭＡのようなダイレクト・アクセス・トランスポート（ＤＡＴ）機能を提供する。

ｉＳＣＳＩドライバ層２２８は、ＴＣＰ／ＩＰネットワークプロトコルを介したブロック・プロトコル・アクセスを提供する一方、ＦＣドライバ層２３０は、ストレージシステムに対するブロックアクセス要求の送受信、及び応答の送受信を提供する。ＦＣドライバ、及びｉＳＣＳＩドライバは、ブロックに対するＦＣ固有のアクセスコントロール、及びｉＳＣＳＩ固有のアクセスコントロールを提供し、したがって、ストレージシステム上のブロックにアクセスするときに、ｉＳＣＳＩとＦＣＰのいずれか一方への、あるいはいｉＳＣＳＩとＦＣＰの両方へのＬＵＮのエキスポートを管理する。さらに、ストレージ・オペレーティング・システムは、Ｉ／Ｏオペレーションにしたがってボリューム／ディスクに対する情報の記憶、及び読み出しを管理するＲＡＩＤシステム２４０として実施されるストレージモジュール、及び、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施するディスクドライバシステム２５０を含む。

ストレージ・オペレーティング・システム２００は、ファイルシステム２８０に対するインタフェースを提供するＮＲＶプロトコル層２９５をさらに含む。ネットワーク・アプライアンス・リモート・ボリューム（ＮＲＶ）・プロトコルは一般に、ディスク上にローカルに格納されていないデータブロックをリモートフェッチするために使用される。ただし、本明細書に記載するように、本発明の原理によれば、ＮＲＶプロトコルは、散在ボリューム中の不在ブロックをフェッチするためのストレージシステム間通信にも使用される場合がある。なお、代替実施形態では、ＮＲＶプロトコルの代わりに、ＮＦＳプロトコルや他の所有権のあるブロック・フェッチ・プロトコルのような従来のファイル／ブロックレベルプロトコルも、本発明の教示の範囲内で、使用される場合がある。

本発明によれば、後で詳しく説明するように、ストレージ・オペレーティング・システム２００の要求発生器２９６は、ディスク上にローカルに格納されていないデータブロック、すなわち、ストレージシステム１２０ａのローカルボリューム上に格納されていないデータブロックをシステム的に取得するために使用される。一方、ポンプモジュール２９８は、それらのデータブロックの読み出しを調節するために使用される場合がある。本明細書では、要求発生器２９６とポンプモジュール２９８が、個別のソフトウェアモジュールとして図示説明されているが、それらは、代わりに、ストレージ・オペレーティング・システム中の単一のモジュールとして一体化させてもよい。また、要求発生器とポンプモジュールは、ハードウェアで実施しても、ソフトウェアで実施しても、ファームウェアで実施してもよく、また、それらの如何なる組み合わせによって実施してもよい。

ディスクソフトウェア層を統合ネットワークプロトコルスタック層に橋渡するのは、ファイルシステム２８０によって実施される仮想化システムである。ファイルシステム２８０は、例えば、ｖｄｉｓｋモジュール２９０、及びＳＣＳＩターゲットモジュール２７０として実施される仮想化モジュールと通信する。ｖｄｉｓｋモジュール２９０は、ファイルシステム２８０の上に層として形成され、ユーザ（例えば、システム管理者）がストレージシステムに対して発行したコマンドに応答して、ユーザ・インタフェース（ＵＩ）２７５のような管理インタフェースによるアクセスを可能にする。ＳＣＳＩターゲットモジュール２７０は、ＦＣドライバ２３０、ｉＳＣＳＩドライバ２２８と、ファイルシステム２８０との間に配置され、ブロック（ＬＵＮ）空間とファイルシステム空間との間の仮想化システムの変換層として機能する。その際、ＬＵＮは、ブロックとして表わされる。ＵＩ２７５は、それらの種々の層、及びシステムに対する管理者、又はユーザによるアクセスが可能となるような態様で、ストレージ・オペレーティング・システムの上に配置される。

ファイルシステムは、例えば、ディスクのような記憶装置に格納された情報にアクセスするための論理ボリューム管理機能を提供するメッセージベースのシステムである。すなわち、ファイルシステム２８０は、ファイルシステム・セマンティックを提供するだけでなく、通常ならばボリューム・マネージャに関連する機能も提供する。そのような機能には、（１）ディスクの集合化、（２）ディスクの記憶帯域幅の集合化、（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証が挙げられる。ファイルシステム２８０は、ＷＡＦＬファイルシステム（以後、「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム」）を実施する場合がある。このファイルシステムは、例えば、４キロバイト（ＫＢ）ブロックを使用し、インデックス・ノード（「ｉｎｏｄｅ」）を使用してファイル、及びファイル属性（例えば、作成時刻、アクセス・パーミッション、サイズ、及びブロック位置など）を識別するオン・ディスク・フォーマット表現を有する。ファイルシステムは、ファイルを使用して、ファイルシステムのレイアウトを表わすメタデータを記憶する。そのようなメタデータファイルには、とりわけ、ｉｎｏｄｅファイルがある。ディスクからｉｎｏｄｅを読み出すために、ファイルハンドル、すなわち、ｉｎｏｄｅ番号を含む識別子が使用される。

簡単に言えば、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムのｉｎｏｄｅは全て、ｉｎｏｄｅファイルの中に編成される。ファイルシステム（ｆｓ）ｉｎｆｏブロックは、ファイルシステム上の情報のレイアウトを指定するためのものであり、ファイルシステムのすべての他のｉｎｏｄｅを含むファイルのｉｎｏｄｅを含む。各論理ボリューム（ファイルシステム）はｆｓｉｎｆｏブロックを有し、ｆｓｉｎｆｏブロックは、例えばＲＡＩＤグループ内の固定位置に記憶されることが好ましい。ルートｆｓｉｎｆｏブロックのｉｎｏｄｅは、ｉｎｏｄｅファイルのブロックを直接参照（指し示す）場合もあれば、ｉｎｏｄｅファイルの間接ブロックを参照し、さらに、その間接ブロックが、ｉｎｏｄｅファイルのブロックを直接参照する場合もある。ｉｎｏｄｅファイルの各直接ブロックの中にはｉｎｏｄｅが埋め込まれ、各ｉｎｏｄｅは、間接ブロックを参照し、さらに、その間接ブロックが、ファイルのデータブロックを参照する場合がある。

動作時には、クライアント１１０からの要求は、コンピュータネットワーク１４０を介してパケット１５０としてストレージシステム１２０ａに転送され、そこで、その要求はネットワークアダプタ１２６により受信される。（層２１０、又は層２３０の）ネットワークドライバは、そのパケットを処理し、必要に応じて、それをネットワークプロトコル層、及びファイルアクセス層に渡して更なる処理を施した後、それをｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム２８０に渡す。ここで、ファイルシステムは、要求されたデータが「コア内」になければ、すなわち、バッファ・キャッシュ１７０内になければ、要求されたデータをディスク１３０からロード（読み出し）するためのオペレーションを生成する。このオペレーションは例えば、ファイルシステム２８０のＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４として実施される場合がある。

情報がキャッシュ内になければ、ファイルシステム２８０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイル内を検索し、適当なエントリにアクセスし、論理ｖｂｎを取得する。そして、ファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム２４０に渡す。論理ｖｂｎは、ディスク識別子、及びディスクブロック番号（ディスク、ｄｂｎ）にマッピングされ、ディスクドライバシステム２５０の適当なドライバ（例えば、ＳＣＳＩ）に送信される。ディスクドライバは、指定されたディスク１３０からそのｄｂｎをアクセスし、要求されたデータブロック（複数の場合もあり）をバッファ・キャッシュ１７０にロードし、ストレージシステムによって処理する。要求が完了すると、ストレージシステム（及び、オペレーティング・システム）は、ネットワーク１４０を介してクライアント１１０に返答を返す。

ファイルシステム２８０は通常、ディスクから１以上のブロックを読み出すためのＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４を備える。これらのブロックは、読み出し要求に応答して読み出される場合もあれば、例えばファイルに対する先読みアルゴリズムによって読み出される場合もある。後で詳しく説明するように、ファイルのバッファツリー内の要求されたブロックの中に、特殊なＡＢＳＥＮＴ（不在）値（不在ブロックを意味する）を有するものがあれば、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、例えばＮＲＶプロトコルを使用してその不在ブロックを適当な外部記憶装置から読み出すためのフェッチ・オペレーションを開始する。ブロック（何らかのデータブロックを含む）を読み出した後、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、要求されたデータを返す。ＮＲＶプロトコルの詳細については、Jason Lango 他による「ARCHITECTURE FOR SUPPORT OF SPARSE VOLUMES」と題する、上で参照した米国特許出願に記載されている。ただし、リモート外部記憶装置からデータを読み出すことが可能なものであれば、例えば、ＮＦＳプロトコルを含めて、任意の他の適当なファイルベース、又はブロックベースのプロトコルを本発明とともに有利に使用することが可能である。また、ファイルシステムは、例えば、ファイルを最初にアクセスするときにｉｎｏｄｅ、及びファイル・ジオメトリを読み出すためのＬｏａｄ＿Ｉｎｏｄｅ（）関数２９２をさらに含む場合がある。

また、クライアント要求がストレージシステムにおいて受信されたときにデータストレージアクセスを実施するために必要となる上記のストレージ・オペレーティング・システム層の中を通るソフトウェアパスは、代わりに、ハードウェアで実施してもよい。すなわち、本発明の代替実施形態では、ストレージアクセス要求データパスは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の中に実現される論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１１０により発行された要求に応答してストレージシステム１０によって提供されるストレージサービスの性能を向上させることができる。また、本発明のさらに別の実施形態では、アダプタ１２６、１２８の処理要素は、プロセッサ１２２からパケット処理オペレーションやストレージアクセスオペレーションの負荷の一部、または全部を取り除くように構成され、それによって、システムにより提供されるストレージサービスの性能を向上させる場合がある。当然ながら、本明細書に記載する種々の処理、アーキテクチャ、及び手順は、ハードウェアで実施しても、ファームウェアで実施しても、ソフトウェアで実施してもよい。

本明細書では、「ストレージ・オペレーティング・システム」という用語は、ストレージシステムにおいてストレージ機能を、例えばデータアクセスを管理する機能を実施するためのコンピュータ実行可能コードを意味し、ファイルサーバの場合、このコードは、ファイルシステム・セマンティックを実施する場合がある。その意味で、ＯＮＴＡＰソフトウェアは、マイクロカーネルとして実施されるそのようなストレージ・オペレーティング・システムの一例であり、ＷＡＦＬファイルシステムセマンティックを実施し、データアクセスを管理するためのＷＡＦＬ層を有している。ストレージ・オペレーティング・システムは、ＵＮＩＸやＷｉｎｄｏｗｓ ＮＴのような汎用オペレーティングシステム上で動作するアプリケーションとして実施してもよいし、あるいは、機能設定機能を備えた汎用オペレーティングシステムにおいて、その機能を本明細書に記載するストレージ・アプリケーションにあわせて設定したものであってもよい。

さらに、当業者には明らかなように、本明細書に記載する本発明のシステム、及び方法は、ストレージシステム１２０として実施され、又は、ストレージシステム１２０を含むように実施される、スタンドアロンのコンピュータ、及びその一部を含めて、いかなるタイプの特殊目的（例えば、ファイルサーバ、ファイラ、またはマルチプロトコル・ストレージ・アプライアンス）のコンピュータ、及び汎用コンピュータにも適用できるものと考えられる。本発明とともに有利に使用されるマルチプロトコル・ストレージ・アプライアンスの一例は、２００２年８月８日に出願された「MULTI-PROTOCOL STORAGE APPLIANCE THAT PROVIDES INTEGRATED SUPPORT FOR FILE AND BLOCK ACCESS PROTOCOLS」と題する米国特許出願第１０／２１５，９１７号に記載されている。さらに、本発明の教示は、種々のストレージシステムアーキテクチャに適合させることができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアント又はホストコンピュータに直接取り付けされたディスクアセンブリに適合させることができる。したがって、「ストレージシステム」という用語は、ストレージ機能を実施するように構成され、他の装置またはシステムに関連する任意のサブシステムだけでなく、それらの構成も含むものとして広い意味で解釈しなければならない。

Ｃ．ファイルシステムの編成
例示的実施形態として、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムでは、ファイルは、ディスク１３０に格納されるように構成されたｉｎｏｄｅデータ構造として表現される。図３は、ｉｎｏｄｅ３００を示す略ブロック図である。ｉｎｏｄｅ３００は、メタデータ部３１０、及びデータ部３５０を有することが好ましい。各ｉｎｏｄｅ３００のメタデータ部３１０に格納される情報は、ファイルを表わし、したがって、そのファイルのタイプ（例えば、通常、ディレクトリ、仮想ディスク）３１２、そのファイルのサイズ３１４、そのファイルのタイムスタンプ（例えば、アクセス、及び／又は変更）３１６、及びそのファイルの所有者、すなわちユーザ識別子（ＵＩＤ３１８）、及びグループＩＤ（ＧＩＤ３２０）を含む。ただし、各ｉｎｏｄｅのデータ部３５０の中身は、タイプフィールド３１２に規定されたファイル（ｉｎｏｄｅ）のタイプに応じて、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部３５０は、ファイルシステムによってコントロールされるメタデータを有する一方、通常ｉｎｏｄｅのデータ部は、ファイルシステムデータを有する。後者の場合、データ部３５０は、そのファイルに関連するデータの表現を含む。

具体的には、通常のオン・ディスクｉｎｏｄｅのデータ部３５０は、ファイルシステムデータ、又はポインタを含む場合があり、後者は、そのファイルシステムデータの格納に使用されるディスク上の４ＫＢデータブロックを参照する。ディスク上のデータをアクセスするときのファイルシステムとＲＡＩＤシステム２４０の間の効率を高めるために、各ポインタは、論理ｖｂｎであることが望ましい。ｉｎｏｄｅのサイズが限られている場合（例えば、１２８バイト）、６４バイト以下のサイズのファイルシステムデータは、その全部が、そのｉｎｏｄｅのデータ部の中に表現される。ただし、ファイルシステムデータのサイズが６４バイトよりも大きく、かつ６４ＫＢ以下である場合、そのｉｎｏｄｅ（第１レベルｉｎｏｄｅ）のデータ部は、最大で１６個のポインタを有し、各ポインタが、ディスク上の４ＫＢブロックを参照する。

また、データのサイズが６４ＫＢよりも大きく、且つ６４メガバイト（ＭＢ）以下である場合、ｉｎｏｄｅ（例えば、第２レベルｉｎｏｄｅ）のデータ部３５０における各ポインタは、最大で１０２４個のポインタを有する間接ブロック（例えば、第１レベルブロック）を参照し、各ポインタが、ディスク上の４ＫＢデータブロックを参照する。６４ＭＢよりも大きなサイズのファイルシステムデータの場合、ｉｎｏｄｅ（例えば、第３レベルｉｎｏｄｅ）のデータ部３５０における各ポインタは、最大で１０２４個のポインタを有する二重間接ブロック（例えば、第２レベルブロック）を参照し、各ポインタが、間接ブロック（例えば、第１レベルブロック）を参照する。さらに、その間接ブロックは、１０２４個のポインタを有し、各ポインタが、ディスク上の４ＫＢデータブロックを参照する。ファイルをアクセスするときに、ファイルの各ブロックは、ディスク１３０からバッファ・キャッシュ１７０へロードされる場合がある。

オン・ディスクｉｎｏｄｅ（又は、ブロック）をディスク１３０からバッファ・キャッシュ１７０へロードするとき、それに対応するコア内構造が、そのオン・ディスクｉｎｏｄｅに埋め込まれる。例えば、点線で囲まれたｉｎｏｄｅ３００（図３）は、オン・ディスクｉｎｏｄｅ構造のコア内表現を示している。このコア内表現は、そのオン・ディスク構造にメモリ上のデータ（ただし、ディスク上にはない）の管理に必要な補足的情報を加えたものを格納するための、メモリブロックである。補足的情報は、例えば、ダーティビット３６０を含む場合がある。例えば、書き込みオペレーションによる命令にしたがってｉｎｏｄｅ（またはブロック）内のデータが更新／変更された後、変更されたデータは、ダーティビット３６０を使用して、汚れたデータとしてマーキングされ、その後、そのｉｎｏｄｅ（ブロック）はディスク上に「フラッシュ」（書き込み）することができるようになる。ｉｎｏｄｅ、及びｉｎｏｄｅファイルを含む、ＷＡＦＬファイルシステムのコア内フォーマット構造、及びオンディスクフォーマット構造については、１９９８年１０月６日に発行されたDavid Hitz 他による「METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM」と題する、上で援用した米国特許第５，８１９，２９２号に開示、及び記載されている。

図４は、本発明とともに有利に使用されるファイルのバッファ・ツリーの一実施形態を示す略ブロック図である。バッファ・ツリーは、バッファ・キャッシュ１７０の中にロードされ、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム２８０によって管理されるファイル（例えば、ファイル４００）のブロックの内部表現である。埋め込みｉｎｏｄｅのようなルート（トップレベル）ｉｎｏｄｅ４０２は、間接（例えば、レベル１）ブロック４０４を参照する。なお、ファイルのサイズによっては、更に別のレベルの間接ブロック（例えば、レベル２やレベル３）が存在する場合もある。間接ブロック（及び、ｉｎｏｄｅ）は、そのファイルの実際のデータの格納に使用されるデータブロックを最終的に参照するポインタ４０５を有する。すなわち、ファイル４００のデータはデータブロックに格納され、それらのデータブロックの位置が、そのファイルの間接ブロックに格納される。各レベル１間接ブロック４０４は、１０２４個ものデータブロックを参照するポインタを有する場合がある。ファイルシステムの「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅ」な性質によれば、それらのブロックは、ディスク１３０上のどこに置かれる場合もありうる。

基礎となる物理ボリュームをストレージシステムの１以上の仮想ボリューム（ｖｖｏｌ）に割り当てるファイルシステムレイアウトが与えられる。そのようなファイルシステムレイアウトの一例は、John K. Edwards他により出願され、ネットワーク・アプライアンス・インコーポレイテッドに譲渡された「EXTENSION OF WRITE ANYWHERE FILE SYSTEM LAYOUT」と題する米国特許出願第１０／８３６，８１７号に記載されている。基礎となる物理ボリュームは、ストレージシステムの例えばＲＡＩＤグループのような１以上のディスクグループからなる集合体である。集合体は、その集合体独自の物理ボリュームブロック番号（ｐｖｂｎ）空間を有し、そのｐｖｂｎ空間内においてブロックアロケーション構造のようなメタデータを管理する。各ｖｖｏｌは、そのｖｖｏｌ独自の仮想ボリュームブロック番号（ｖｖｂｎ)空間を有し、そのｖｖｂｎ空間内においてブロックアロケーション構造のようなメタデータを管理する。各ｖｖｏｌは、コンテナファイルに関連するファイルシステムであり、コンテナファイルは、ｖｖｏｌによって使用されるすべてのブロックを有する、集合体内のファイルである。また、各ｖｖｏｌは、データブロック、及び、他の間接ブロック又はデータブロックを指し示すブロックポインタを含む。

一実施形態として、ｐｖｂｎは、ｖｖｏｌに格納されたファイル（例えば、ファイル４００）のバッファツリー内で、ブロックポインタとして使用される。この「ハイブリッド」ｖｖｏｌ実施形態は、親間接ブロック（例えば、ｉｎｏｄｅ、又は間接ブロック）にｐｖｂｎを挿入することしか必要としない。論理ボリュームの読み出しパス上において、「論理」ボリューム（ｖｏｌ）ｉｎｆｏブロックは、１以上のｆｓｉｎｆｏブロックを参照する１以上のポインタを有し、さらに、各ｆｓｉｎｆｏブロックが、ｉｎｏｄｅファイル、及びそれに対応するｉｎｏｄｅバッファ・ツリーを指し示す。ブロックの適当な位置を見付けるためのｐｖｂｎ（ｖｖｂｎではなく）にしたがって、ｖｖｏｌ上の読み出しパスも、一般に同じである。この文脈において、ｖｖｏｌの読み出しパス（及び、対応する読み出し性能）は、物理ボリュームのものと実質的に同じである。ｐｖｂｎからディスク、ｄｂｎへの変換は、ストレージ・オペレーティング・システム２００のファイルシステム／ＲＡＩＤシステム境界において行われる。

例示するデュアルｖｂｎハイブリッド（「フレキシブル」）ｖｖｏｌ実施形態では、ｐｖｂｎとそれに対応するｖｖｂｎとの両方が、ファイルのバッファ・ツリー内の親間接ブロックに挿入される。すなわち、他のブロック、例えば、レベル１（Ｌ１）間接ブロックやレベル０（Ｌ０）ブロックのような他のブロックへのポインタ有する大半のバッファ・ツリー構造では、各ブロックポインタについて、ｐｖｂｎとｖｖｂｎが、ペアとして記憶される。図５は、本発明とともに有利に使用されるファイル５００のバッファ・ツリーの一実施形態を示す略ブロック図である。埋め込みｉｎｏｄｅのようなルート（トップレベル）ｉｎｏｄｅ５０２は、間接（例えば、レベル１）ブロック５０４を参照する。なお、ファイルのサイズによっては、更に別のレベル（例えば、レベル２やレベル３）の間接ブロックが存在する場合もある。間接ブロック（及び、ｉｎｏｄｅ）は、ファイルの実際のデータの格納に使用されるデータブロック５０６を最終的に参照するｐｖｂｎ／ｖｖｂｎポインタ対構造５０８を有する。

ｐｖｂｎは、集合体のディスク上の位置を参照する一方、ｖｖｂｎは、ｖｖｏｌのファイル内の位置を参照する。間接ブロック５０４内のブロックポインタ５０８のようなｐｖｂｎを使用は、読み出しパスにおける効率を提供する一方、ｖｖｂｎブロックポインタの使用は、必要なメタデータに対する効率的なアクセスを提供する。すなわち、ファイルのブロックを開放するとき、ファイル内の親間接ブロックは、直ぐに利用可能なｖｖｂｎブロックポインタを有し、それによって、ｐｖｂｎからｖｖｂｎへの変換を行うための所有者マップに対するアクセスに要する待ち時間を回避することができ、それでも、読み出しパス上において、ｐｖｂｎを利用することができる。

上記のように、ｉｎｏｄｅファイルのサイズによっては（例えば、６４バイトよりも大きなデータの場合）、各ｉｎｏｄｅは、自分のデータ部の中に、それらが他のブロックへのブロックポインタとして機能する６４バイトを有する場合がある。従来のハイブリッドボリュームでは、それらの６４バイトは、１６個のブロックポインタ、すなわち、１６個の４バイトブロックポインタとして実施される。例示するデュアルｖｂｎフレキシブルボリュームの場合、ｉｎｏｄｅの６４バイトは、８対の４バイトブロックポインタとして実施され、各対が、ｖｖｂｎ／ｐｖｂｎ対になっている。また、従来のボリューム、すなわち、ハイブリッドボリュームの各間接ブロックは、最大で１０２４個の（ｐｖｂｎ）ポインタを有する場合がある。一方、デュアルｖｂｎフレキシブルボリュームの各間接ブロックは、最大で５１０（ｐｖｂｎ／ｖｖｂｎ）対のポインタを有する。

さらに、１以上のポインタ５０８は、それらのポインタ（複数の場合もあり）によて参照されるオブジェクト（複数の場合もあり）（例えば、間接ブロックやデータブロック）が、ローカルに記憶されていない（すなわち、そのボリューム上に記憶されていないこと）こと、したがって、それらのポインタを別の外部記憶装置からフェッチしなければならないことを示す特殊なＡＢＳＥＮＴ（不在）値を有する場合がある。例示的実施形態として、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数は、各ポインタの中身を解釈し、要求されたブロックがＡＢＳＥＮＴであれば、例えばＮＲＶプロトコルを使用して、そのデータの適当な要求（例えば、リモート・フェッチ・オペレーション）の外部記憶装置への送信を開始する。

図６は、本発明とともに有利に使用される集合体６００の一実施形態を示す略ブロック図である。ＬＵＮ（ブロック）６０２、ディレクトリ６０４、ｑｔｒｅｅ６０６、及びファイル６０８は、デュアルｖｂｎフレキシブルｖｖｏｌのようなｖｖｏｌ６１０の中に格納され、さらに、集合体６００の中に格納される。集合体６００は、例えば、少なくとも１つのＲＡＩＤプレックス６５０により表現されるＲＡＩＤシステムの最上部に層として形成され（ストレージ構成がミラーリングであるか否かに応じて）、各プレックス６５０は、少なくとも１つのＲＡＩＤグループ６６０を含む。各ＲＡＩＤグループは、例えば１以上のデータ（Ｄ）ディスク、及び少なくとも１つのパリティ（Ｐ）ディスクのような複数のディスク６３０を更に含む。

集合体６００は、従来のストレージシステムの物理ボリュームに似ている一方、ｖｖｏｌは、その物理ボリューム内のファイルに似ている。すなわち、集合体６００は、１以上のファイルを含む場合があり、各ファイルはｖｖｏｌ６１０を含み、ｖｖｏｌによって消費される記憶空間の合計は、物理ボリューム全体のサイズよりも物理的に小さい（又はそれに等しい）。集合体は、「物理的」ｐｖｂｎ空間を使用して、物理ボリュームのディスクによって提供されるブロックの記憶空間を規定する一方、（ファイル内の）各埋め込みｖｖｏｌは、「論理的」ｖｖｂｎ空間を使用して、例えばファイルのようなそれらのブロックを編成する。各ｖｖｂｎ空間は、ファイル内の位置に対応する独立した一組の数値であり、それらの位置は、ディスク上のｄｂｎに変換される。ｖｖｏｌ６１０もまた論理ボリュームであるため、ｖｖｏｌ６１０は、自分のｖｖｂｎ空間内に、独自のブロックアロケーション構造（例えば、アクティブマップ、空間マップ、及び概要マップ）を有する。

コンテナファイルは、ｖｖｏｌによって使用されるすべてのブロックを有する、集合体中のファイルである。コンテナファイルは、ｖｖｏｌをサポートする（集合体の）内部機能であり、例えば、１つのｖｖｏｌあたり１つのコンテナファイルが存在する。ファイルアプローチにおける純粋な論理ボリュームと同様に、コンテナファイルもまた、ｖｖｏｌによって使用されるすべてのブロックを有する、集合体中の隠しファイル（ユーザがアクセスすることのできない）である。集合体は、ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイルやストレージラベルファイルのようなｖｖｏｌのサブディレクトリを保持する隠しメタデータルートディレクトリを含む。

具体的には、物理的ファイルシステム（ＷＡＦＬ）ディレクトリは、集合体中の各ｖｖｏｌについてサブディレクトリを有し、サブディレクトリの名前は、ｖｖｏｌのファイルシステム識別子（ｆｓｉｄ）になっている。各ｆｓｉｄサブディレクトリ（ｖｖｏｌ）は、少なくとも２つのファイル、すなわち、ファイルシステムファイルとストレージラベルファイルを有する。ストレージラベルファイルは、例えば、従来のＲＡＩＤラベルに格納されているものと同様のメタデータを有する４ｋＢファイルである。言い換えれば、ストレージラベルファイルは、ＲＡＩＤラベルに似たものであり、したがって、例えば、ｖｖｏｌの名前、ｖｖｏｌの世界的に一意な識別子（ｕｕｉｄ）及びｆｓｉｄ、ｖｖｏがオンラインであるか、作成中であるか、又は破壊中であるか等のｖｖｏｌの状態に関する情報を有する。

図７は、集合体７００のオン・ディスク表現を示す略ブロック図である。例えばＲＡＩＤシステム２４０のようなストレージ・オペレーティング・システム２００は、集合体７００を作成するために、ｐｖｂｎの物理ボリュームを組み立てる。ｐｖｂｎ１、及びｐｖｂｎ２は、集合体に関する「物理的」ｖｏｌｉｎｆｏブロック７０２を有する。ｖｏｌｉｎｆｏブロック７０２は、ｆｓｉｎｆｏブロック７０４へのブロックポインタを有し、各ｆｓｉｎｆｏブロック７０４は、集合体のスナップショットを表わす場合がある。各ｆｓｉｎｆｏブロック７０４は、ｉｎｏｄｅファイル７０６へのブロックポインタを含む。ｉｎｏｄｅファイル７０６は、所有者マップ７１０、アクティブマップ７１２、概要マップ７１４、及び空間マップ７１６、並びに他の特殊なメタデータファイルのような複数のファイルのｉｎｏｄｅを含む。ｉｎｏｄｅファイル７０６は、ルートディレクトリ７２０、及び「隠し」メタデータルートディレクトリ７３０を更に含み、後者は、ユーザが内部のファイルを見ることができないｖｖｏｌに関連するファイルを有する名前空間を含む。この隠しメタデータルートディレクトリは、ファイルシステムファイル７４０、及びストレージラベルファイル７９０を有するＷＡＦＬ／ｆｓｉｄ／ディレクトリ構造をさらに含む。なお、集合体中のルートディレクトリ７２０は空であり、集合体に関連するファイルはすべて、隠しメタデータルートディレクトリ７３０の中に編成される。

ファイルシステムファイル７４０は、コンテナマップとして編成されたレベル１ブロックを有するコンテナファイルとして実施されるだけでなく、ｖｖｏｌ７５０として実施される種々のファイルシステムを参照するブロックポインタを更に含む。集合体７００は、それらのｖｖｏｌ７５０を特殊な予約されたｉｎｏｄｅ番号に維持する。各ｖｖｏｌ７５０は、とりわけ、ビットマップアロケーションビットマップ構造に使用される自分のｖｖｏｌ空間の中に、特殊な予約されたｉｎｏｄｅ番号を更に有する。上記のように、ブロックアロケーションビットマップ構造、例えば、アクティブマップ７６２、概要マップ７６４、及び空間マップ７６６が、各ｖｖｏｌに配置される。

具体的には、各ｖｖｏｌ７５０は、集合体と同じｉｎｏｄｅファイル構造／内容を有する。ただし、隠しメタデータルートディレクトリ７８０の中に、所有者マップ、ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイル、及びストレージラベルファイルディレクトリ構造は存在しない。その目的のために、各ｖｖｏｌ７５０は、１以上のｆｓｉｎｆｏブロック８００を指し示すｖｏｌｉｎｆｏブロック７５２を有し、各ｆｓｉｎｆｏブロック８００は、そのｖｖｏｌのアクティブファイルシステムとともに、スナップショットを表わす場合がある。さらに、各ｆｓｉｎｆｏブロックは、ｉｎｏｄｅファイル７６０を指し示し、上記のような例外を除き、集合体と同じｉｎｏｄｅ構造／中身を有する。各ｖｖｏｌ７５０は、そのｖｖｏｌ独自のｉｎｏｄｅファイル７６０、及び対応するｉｎｏｄｅ番号を有する独立したｉｎｏｄｅ空間を有し、さらに、独自のルート（ｆｓｉｄ）ディレクトリ７７０、及び他のｖｖｏｌとは無関係にエキスポートすることが可能なファイルのサブディレクトリを有する。

集合体の隠しメタデータルートディレクトリ７３０内に格納されるストレージラベルファイル７９０は、従来のＲＡＩＤラベルと同様の働きをする小さなファイルである。ＲＡＩＤラベルは、ボリューム名のようなストレージシステムに関する物理的情報を有し、その情報は、ストレージラベルファイル７９０にロードされる。例えば、ストレージラベルファイル７９０は、関連するｖｖｏｌ７５０の名前７９２、ｖｖｏｌのオンライン／オフライン状態７９４、関連ｖｖｏｌの状態情報７９６（ボリュームが作成中であるか、破壊中であるか）を含む。

Ｄ．散在ボリューム
本発明は、二次記憶装置（外部記憶装置）からオン・デマンドでデータを復元するために使用される、ストレージシステムのファイルシステム内の散在ボリュームをインスタンス化するシステム、及び方法を提供することにより、従来技術の欠点を克服する。本明細書に記載するように、散在ボリュームは、ストレージシステムに接続されたディスク上にローカルに格納されていない（すなわち、ローカルボリューム上に格納されていない）少なくとも１つのデータブロック（すなわち、不在ブロック）を有する１以上のファイルを含む。データブロック（または、ホール環境におけるようなゼロのブロック）を記憶しないことにより、最小限の書き込みオペレーションで散在ボリュームを生成し、迅速にエキスポートすることができる。不在ブロックの欠落データは、代わりに、（場合によってはリモートの）外部記憶装置に格納され、例えば、リモート・フェッチ・オペレーションを使用して読み出される。

散在ボリュームは、不在ブロックを有するファイルが含まれていることを示す、ボリューム（ｖｖｏｌ）中のオン・ディスク構造の特殊なマーキングによって識別される。図８は、オン・ディスク構造を示す略ブロック図である。このオン・ディスク構造は、例えば、ｆｓｉｎｆｏブロック８００であってもよい。


ｆｓｉｎｆｏブロック８００は、ＰＣＰＩ（Permanent Consistency Point Image）ポインタ８０５、散在ボリュームフラグフィールド８１０、及びそのｉｎｏｄｅファイルのｉｎｏｄｅ８１５を有し、代替実施形態では、更に別のフィールド８２０を有する場合がある。ＰＣＰＩポインタ８０５は、ファイルシステムに関連するＰＣＰＩ（スナップショット）へのポインタのデュアルｄｂｎ（ｖｖｂｎ／ｐｖｂｎ）対である。散在ボリュームフラグフィールド８１０は、ｆｓｉｎｆｏブロックによって表わされるｖｖｏｌが、散在するものであるか否かを識別する。図示の実施形態では、フィールド８１０においてフラグがアサートされ、そのボリュームが散在するものであることを示している。散在ボリュームフラグフィールド８１０は、ｆｓｉｎｆｏブロックに関連するｖｖｏｌのタイプを識別するタイプフィールドとして実施される場合がある。ｉｎｏｄｅファイル８１５のｉｎｏｄｅは、ｆｓｉｎｆｏブロックに関連するファイルシステムのｉｎｏｄｅファイル７６０（図７）へのルートレベルポインタを含むｉｎｏｄｅを含む。

データブロックや間接ブロックのような、散在ボリューム中の特定ブロック（複数の場合もあり）が、そのボリュームを提供するストレージシステム上に置かれていないことを示すために、ファイルの適当なブロックポインタ（複数の場合もあり）は、特殊なＡＢＳＥＮＴ（不在）値（複数の場合もあり）によってマーキングされる。この特殊なＡＢＳＥＮＴ値は、ファイルシステムに対し、そのデータを別のソース、すなわち、外部記憶装置、（例えばニア・ライン・ストレージ・サーバ１２０ｂ）から取得すべきことを更に警告する。データアクセス要求に応答し、ファイルシステム２８０のＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、ファイルの適当なブロックポインタが、ＡＢＳＥＮＴとしてマーキングされているか否かを判定し、マーキングされていた場合、要求されたデータをフェッチするために、ストレージシステムからリモートの外部記憶装置へリモート・フェッチ（読み出し）・オペレーションを送信する。このフェッチ・オペレーションは、例えば、外部記憶装置に格納されたファイルの１以上のファイルブロック番号（ｆｂｎｓ）を要求するものである。なお、本明細書の説明は、単一の外部記憶装置を例として記載しているが、本発明の原理は、単一の散在ボリュームが複数の外部記憶装置によりサポートされ、各外部記憶装置がその散在ボリュームの全部、又は一部をサポートするような環境にも適用することができる。したがって、本明細書の教示を単一の外部記憶装置に限定されるものとして解釈してはならない。

外部記憶装置は、要求されたデータを自分の所有する記憶装置から読み出し、そのデータをストレージシステムに返す。ストレージシステムは、データアクセス要求を処理し、返されたデータを自分のメモリに格納する。次に、ファイルシステムは、書き込みアロケーション手順の間に、メモリに格納されたデータをローカルディスクに「フラッシュ」（書き込み）する。これは、「ダーティ」としてマーキングされているデータに応答して実施されるか、または、そのデータを書き込みアロケーションしなければならないことをファイルシステムに伝える他の記述に応答して実施される場合がある。この手順の例示的ｗｒｉｔｅ−ａｎｙｗｈｅｒｅポリシーによれば、ファイルシステムは、ファイルの間接ブロック（複数の場合もあり）にポインタ値（ＡＢＳＥＮＴ値ではなく）を割り当てることにより、ローカルボリューム内にローカルに格納されたデータの位置（複数の場合もあり）を識別する。したがって、データアクセスのために、リモート・フェッチ・オペレーションはもはや必要とされない。

本発明とともに有利に使用される書き込みアロケーション手順の一例は、John K. Edwardsによる「EXTENSION OF WRITE ANYWHERE FILE LAYOUT WRITE ALLOCATION」と題する米国特許出願第１０／８３６，０９０号に記載されており、この出願は、参照により本明細書に援用される。簡単に言えば、ｖｖｏｌ内のブロックを書き込みアロケーションするとき、ブロックアロケーションは、フレキシブルｖｖｏｌと集合体の両方に対して並列に進められ、その際、書き込みアロケータプロセス２８２は、集合体中の実際のｐｖｂｎ、及びｖｖｏｌ中のｖｖｂｎを選択する。書き込みアロケータは、集合体のアクティブマップや空間マップのようなブロックアロケーションビットマップ構造を調節し、選択されたｐｖｂｎを記録するとともに、ｖｖｏｌの同様の構造を調節し、選択されたｖｖｂｎを記録する。ｖｖｏｌのｖｖｉｄ（ｖｖｏｌ識別子）、及びｖｖｂｎは、集合体中の所有者マップ７１０の中の選択されたｐｖｂｎによって決まるエントリに挿入される。また、選択されたｐｖｂｎは、宛先ｖｖｏｌのコンテナマップ（図示せず）の中にも挿入される。最後に、間接ブロック、または割り当てられたブロックのｉｎｏｄｅファイル親を、その割り当てられたブロックへの１以上のブロックポインタで更新する。更新オペレーションの内容は、ｖｖｏｌ環境によって異なる。デュアルｖｂｎハイブリッドｖｖｏｌ環境の場合、ｐｖｂｎとｖｖｂｎの両方がブロックポインタとして、間接ブロック、またはｉｎｏｄｅに挿入される。

図９は、散在ボリュームに対するデータアクセス要求（例えば、読み出し要求）に応じる手順９００のステップの詳細を示すフロー図である。手順はステップ９０５から開始され、ステップ９１０へ進み、そこで、ストレージシステムは、クライアントからデータアクセス要求を受信する。ステップ９１５において、ファイルシステムは、そのデータアクセス要求を処理し、例えば、その要求を一組のファイルシステム・プリミティブ・オペレーションに変換する。次に、ステップ９１７において、適当なファイル・ジオメトリ、及びｉｎｏｄｅデータがロードされる。これは、Ｌｏａｄ＿Ｉｎｏｄｅ（）２９２関数を使用して行うことができる。この関数の詳細については、Jason Lango 他による「SYSTEM AND METHOD FOR CREATING AND USING SPARSE VOLUMES」と題する上で援用した米国特許出願第（代理人文書番号第１１２０５６−０１９６号）、及びJason Lango 他による「ARCHITECTURE FOR SUPPORT OF SPARSE VOLUMES」と題する米国特許出願第（代理人文書番号第１１２０５６−００１９９号）に記載されている。一般に、ストレージシステムは、ＡＢＳＥＮＴブロックを有するファイル（又は、他のデータコンテナ）を復元するときに予約すべき適当な量の空間を、ファイルシステム・ジオメトリ、及びｉｎｏｄｅデータから識別することができる。

ステップ９２０において、ファイルシステムは、ロードすべき１以上のブロックを識別し、ステップ９２５において、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数を実行し、識別されたブロックのうちの１以上をロードする。ステップ９３０では、ブロック（複数の場合もあり）がＡＢＳＥＮＴとしてマーキングされているか否かの判定がなされる。この判定は、例えば、ブロックを参照するブロックポインタを検査することによって行われる場合がある。ブロックが不在でなければ、手順はステップ９３５へと分岐し、そこでそのブロックをディスクから読み出し、次いで、ステップ９４０において、データアクセス要求を実施する。読み出し要求の場合、読み出し性能には、読み出されたデータをクライアントへ返すことも含まれる。そして、手順はステップ９６５において終了する。

一方、ブロックが不在であれば（ステップ９３０）、手順はステップ９４５へと続き、そこで、リモートデータアクセス(フェッチ）要求を外部記憶装置に送信し、要求されたブロック（複数の場合もあり）をフェッチする。このフェッチ要求は、本明細書に記載されたＮＲＶプロトコルのような、ストレージ・オペレーティング・システムのフェッチモジュールによって発行することができる。上記のように、複数の外部記憶装置が、１つの散在ボリュームとともに使用される場合がある。複数の外部記憶装置を備えた環境の例の場合、散在設定メタデータファイル７３２に格納されたメタデータによって、使用すべき適当な外部記憶装置が識別される。外部記憶装置は、リモートデータアクセス要求を受信すると、ステップ９５０において、要求されたデータを返す。ステップ９５５では、外部記憶装置から読み出されたデータを用いて、データアクセス要求を実施する。次に、ステップ９６０において、書き込みアロケーションを実施し、読み出されたデータを１以上のローカル記憶装置に格納する。そして、手順はステップ９６５において終了する。

Ｅ．オン・デマンド復元（ＲＯＤ）
例示的実施形態において、散在ボリュームは、外部記憶装置に格納されたデータを指し示すポインタ（例えば、ＡＢＳＥＮＴポインタ）を利用するボリューム・インフラストラクチャ・メタデータを使用して初期化される。このようなＡＢＳＥＮＴポインタの使用は、「瞬時」の完全な復元であるかのような錯覚をクライアントのようなユーザに与え、それによって、従来の完全復元オペレーションに要する長い待ち時間を回避する。次に、データは、「オン・デマンドで復元」される場合がある。本明細書では、この用語は、データ要求の発行を待ってから、ストレージシステム・リソースを消費して、データを取得することを意味する。このようなデータ復元は、クライアントがストレージシステムに対して発行したデータアクセス要求に応答して実施してもよいし、または、例えば、バックグラウンド処理中に、そのデータの要求（「要望」）を生成する、システムの復元モジュールによって実施してもよい。本発明によれば、故障したローカルボリュームを迅速に復元するために、散在ボリュームはインスタンス化される場合がある。なお、散在ボリュームの復元がいったん開始されれば、その散在ボリュームは、例えば新たな変更（書き込みオペレーション）のようなすべてのファイルシステムオペレーションで利用することが可能になる。オン・デマンド復元が開始された後は、散在ボリュームに対していかなるオペレーションを行ってもよい。例えば、散在ボリュームに対し、バックアップオペレーションが開始される場合がある。

図１０は、故障したローカルボリュームを散在ボリュームを使用して迅速に復元する手順１０００の詳細なステップを示すフロー図である。手順はステップ１００５から開始され、ステップ１０１０へ進み、そこで、ストレージシステムのローカルボリュームが故障していることが判定される。故障したボリュームは、ストレージシステムの複数のボリュームのうちのいずれのボリュームであってもよい。ステップ１０１５では、管理者が散在ボリュームに関連する特定の情報(例えば、ボリューム名）をＵＩ２７５を介してシステムに入力することにより、または自動的なプロセスにより、散在ボリュームがインスタンス化（作成）される。ステップ１０２０において、ストレージシステムは、その散在ボリュームを初期化するために必要なボリューム・インフラストラクチャ・メタデータを外部記憶装置からフェッチする。通常、外部記憶装置は、故障したボリュームに関するこのメタデータの最新のコピーを有することになるが、このメタデータは、ＰＣＰＩ、またはスナップショットから復元した方が望ましい場合もある。フェッチされたボリューム・インフラストラクチャ・メタデータは、現在のファイルシステムのバージョン、そのボリュームのトータルサイズ（ｉｎｏｄｅ数、及び／又はブロック数）、ルートファイルシステムディレクトリ（ｒｏｏｔ＿ｄｉｒ）の中身、及び、例えばｖｏｌｉｎｆｏデータ構造やｆｓｉｎｆｏデータ構造の中にあるファイルシステム固有のメタデータなどを含む。なお、ステップ１０２５においてＡＢＳＥＮＴポインタが入れられた（初期化された）ｉｎｏｄｅファイルのブロックの一部のブロックから明らかなように、散在ボリュームのファイルシステムデータは不在である。

ステップ１０３０において、散在ボリュームのインフラストラクチャが作成された後、そのボリュームは、いかなるクライアントアクセスについても利用可能になる。なお、ローカルボリュームの故障の後、クライアントは、復元された（散在）ボリュームが、以前キャッシュされたバージョンの「古くなった」データではなく、有効なデータで動作していることを確認するために、復元された（散在）ボリュームをアンマウントし、再マウントしなければならない場合がある。クライアントが発行した要求に対し、任意のファイルシステムデータ、及びメタデータを含むデータの復元は、図９を参照して上で説明したような方法で達成することができる。そのようなデータの復元（読み出し）には、ファイル識別（ファイルＩＤ）番号、ファイルハンドル、およびオフセット値のような論理的ファイル情報だけを、ストレージシステム（一次）と、外部記憶装置（二次）との間で転送すれば足りる。次に、外部記憶装置は、要求されたデータをストレージシステムに返し、ストレージシステムは、そのデータに対する書き込みアロケーションを実施する。その結果、上で説明した書き込みアロケーション手順にしたがって、ｐｖｂｎ、及びｖｖｂｎを含む「新たな」ブロックアロケーション情報が、散在ボリュームに対して作成される。したがって、システム間で何らかの書き込みアロケーションファイル（ｉｎｏｄｅマップ、概要マップ、アクティブマップなど）を転送する必要はない。そして、手順はステップ１０３５で終了する。

下記の例は、散在ボリュームがインスタンス化された後、故障したローカルボリュームを迅速に復元するために、クライアントシステムがデータをオン・デマンドでアクセスする方法を説明するものである。クライアントが、ストレージシステム１２０ａによって提供される自分のディレクトリから、「ｄｏｃｕｍｅｎｔ．ｄｏｃ」というファイルをアクセスしたいものと仮定する。ファイルシステムは、ルートディレクトリにアクセスし、そのファイルを従来の方法で探す。ファイルシステムが、そのファイルのバッファ・ツリー内において何らかの不在ブロックに遭遇した場合、それらのブロックは、本明細書に記載されるように、外部記憶装置から復元される。例えば、ｄｏｃｕｍｅｎｔ．ｄｏｃが、「・・・／ｕｓｅｒｓ／ｃｌｉｅｎｔ／・・・」ディレクトリにあり、それらがいずれも、散在ボリューム上に存在しないものと仮定する。ファイルシステム２８０は、「ｃｌｉｅｎｔ／」ディレクトリを見付けるために、ＮＲＶモジュール２９５と協働し、「ｕｓｅｒｓ／」ディレクトリに入れるために必要なデータを外部記憶装置から取得するためのフェッチ要求を発行し、次いで、ｄｏｃｕｍｅｎｔ．ｄｏｃファイルを置くために、「ｕｓｅｒｓ／」ディレクトリを入れる。なお、「ｃｌｉｅｎｔ／」ディレクトリは埋められるが、「ｕｓｅｒｓ／」ディレクトリの中に見付かった他のディレクトリは、埋められることはなく、後で必要になるまで不在のままにされる（したがって、残りのディレクトリのために空間が予約される）。次に、ｄｏｃｕｍｅｎｔ．ｄｏｃのファイルＩＤ、およびファイルハンドルを使用して、一次は、本発明にしたがってそのファイルを二次から復元することができる。一次ストレージシステムは、要求されたファイルの特定のブロック（複数の場合もあり）だけをフェッチし、ファイル全体をフェッチしないことも可能である。これが発生するのは、マイクロソフトＷＩＮＤＯＷＳ環境においてファイルのサムネイルを求めるクライアント要求に応じるときである。

要求発生器
クライアント要求に応答して散在ボリューム上の不在データを復元するだけでなく、そのボリュームの中身全体を可能な限り迅速に復元し、かつ、ファイルサービスの中断を最小限に抑えることが望ましい場合がある。ボリューム全体の復元が望ましい理由は、リモートの外部記憶装置に対する各クライアントアクセスは、読み出し遅延を生じるからである。ボリュームデータがすべてローカルに復元されると、この遅延はもはや存在しなくなる。また、外部記憶装置が利用不可能になった場合、一次ストレージシステム上にまだ復元されていないデータは失われる場合がある。この脆弱性の窓は、ストレージ・オペレーティング・システム２００の復元モジュールをバックグラウンドプロセスとして実施することによって低減することができる。なお、外部記憶装置が利用不可能になった場合でも、一次ストレージシステムは、外部記憶装置が利用可能になり、オン・デマンド復元プロセスが再開されるまで、データアクセスオペレーションに対するサービスを提供し続けることができる。一次ストレージシステムは、すでに復元されたデータに対する書き込みオペレーションや読み出しオペレーションを処理することができるようになる。

本発明の一態様によれば、復元モジュールは、散在モジュールをスキャンし、ＡＢＳＥＮＴポインタを有するブロックを探すように構成された新規な要求発生器２９６として実施される。そのようなブロックを見付けると、要求発生器は、リモート・フェッチ・オペレーションを発行し、各ＡＢＳＥＮＴポインタによって参照される欠落ブロックを外部記憶装置から取得する。次に、散在ボリュームに入れるために、取得されたデータは、書き込みアロケーションされる。欠落ブロックを有する散在ボリュームにデータを入れる処理は、マルチ・フェイズ・計画シーケンスにしたがって、ファイルシステム中の不在ブロックが無くなるまで行うことが好ましい。この時点で、散在ボリュームは、完全に復元された独立したローカルボリュームに変わる。

図１１は、本発明による要求発生器を動作させる手順１１００を示すフロー図である。この手順はステップ１１０５から開始され、ステップ１１１０へ進み、そこでボリュームが散在ボリュームであるか否かの判定がなされる。例示的実施形態として、この判定は、上記のようにファイルシステム２８０によって実施されることが好ましく、そのボリュームのｆｓｉｎｆｏブロック８００の散在ボリュームフラグフィールド８１０に置かれた特殊なインジケータ、又はフラグによって実施されることが好ましい。ボリュームが散在するものではない場合、手順はステップ１１５５で終了する。一方、ボリュームが散在ボリュームであった場合、手順はステップ１１１２へ進み、そこでファイルシステムは要求発生器と協働し、不在ブロックを探すために散在ボリュームの中を「探索」する。このとき、要求発生器は例えば、ファイルシステムのスキャナプロセス２８６を実施し、ボリューム全体を探索する。具体的には、スキャナは、ｉｎｏｄｅファイルのｉｎｏｄｅのような最上位レベルのｉｎｏｄｅから開始して、ファイルシステムの最後のファイルまで、その計画されたシーケンスをトラバースする。ステップ１１１５において、ファイルシステムの最初のファイルに所望のファイル識別子（ＩＤ）を設定することにより、スキャナは、計画されたシーケンスの最初のファイルに対して初期化される。なお、図示のＷＡＦＬファイルシステムにおいて、最初のファイルのＩＤは、すでに復元の済んだはずの特定のファイルシステムファイル（ｒｏｏｔ＿ｄｉｒ、アクティブマップ、など）に属する場合があり、したがって、最初の実際のファイルのファイルＩＤは、ゼロ（又は１）よりも大きな値になる場合がある。

ステップ１１２０において、スキャナは、ファイルのバッファ・ツリーのブロックをスキャンし、ステップ１１２５において、ＡＢＳＥＮＴポインタを有するブロックがあるか否かを、すなわち、ファイルの幾つかのブロックが不在であることが示されている否かを判定する。ブロックがＡＢＳＥＮＴポインタを有していない場合、ステップ１１２８において、それが、散在ボリューム中の最後のファイルであるか否かを判定する。最後のファイルであれば、手順はステップ１１５５で終了する。最後のファイルでなければ、例えば、ステップ１１３０においてファイルＩＤ番号をインクリメントすることにより、スキャナは次のファイルへと移る。そして、手順はステップ１１２０へと戻る。

一方、ステップ１１２５において不在ブロックに遭遇した場合、スキャナは、要求発生器に信号を送り、不在ブロックのデータを外部記憶装置に積極的に要求させる。他の実施形態において、スキャナは、そのデータを対象とする従来の読み出し要求を発行する場合がある。この読み出し要求は、要求発生器を呼び出すことなく、フェッチオペレーションを開始させる。ステップ１１３５において、要求発生器は、リモートデータアクセス（フェッチ）要求を外部記憶装置に対して発行し、要求したデータブロックをフェッチする。外部記憶装置は、リモートデータアクセス要求を受信すると、ステップ１１４０において、要求されたデータを返す。

次に、ステップ１１４５において、読み出したデータを散在ボリュームの１以上の記憶装置に格納するために、読み出したデータに対して書き込みアロケーションを実施する。通常の書き込みアロケーションの実行中に、そのファイルのバッファ・ツリーの残りの部分が作成される。次に、ステップ１１２８において、そのファイルが散在ボリューム中の最後のファイルであるか否かが判定される。最後のファイルであれば、手順はステップ１１５５で終了する。最後のファイルでなければ、ステップ１１３０において、スキャナは、ファイルＩＤをインクリメントすることによって次のファイルへ移り、ステップ１１２０へ戻って、そのファイルのブロックをスキャンする。このプロセスは、すべての不在ブロックの復元が完了するまで継続され、または、手順が手動で停止されるまで継続される。散在ボリューム中の最後のファイルに到達する前に、ファイルシステムは、散在ボリューム指示フィールドなどによって、最後の不在ブロックの復元が完了したことを知らされる場合がある。その場合、ファイルシステムは処理を終了する。

図１２は、散在ボリュームをスキャンするときにスキャナによってトラバースされる計画シーケンスの一実施形態を示すフロー図である。ここで、スキャナは、欠落データを有する散在ボリュームを埋めるために、例えば、マルチフェイズ計画シーケンスをトラバースする場合がある。手順１２００はステップ１２０５から開始され、ステップ１２１０へ進み、そこでスキャナは要求発生器と協働し、ｉｎｏｄｅファイルのブロックを復元する。その後、ステップ１２１５において、ディレクトリを復元し、次に、ステップ１２２０においてファイルを復元する。当業者には分かるように、ファイルシステムが出来る限り早く矛盾の無い状態に到達できるようにするために、ｉｎｏｄｅファイルとディレクトリは最初に復元される。そして、手順はステップ１２２５で終了する。

また、要求発生器は、ストレージシステム１２０Ａのバッファ・キャッシュ１７０をバイパスする特殊なロードパスを使用するように構成され、それによって、クライアントが現在必要としていない取得データがバッファ・キャッシュ１７０に入らないようにする。

例えば、ファイルシステム２８０は、ＮＲＶプロトコルモジュール２９５と協働し、クライアントがアプリケーション１１２のために現在アクセスしている可能性があるファイルを復元するが、迅速で絶え間ないアクセスを可能にするために、それらのファイルをキャッシュしなければならない場合があり、要求発生器２９６は、クライアントが現在必要としていないファイルの復元を更に要求する場合がある。したがって、ローカルボリュームに対する書き込みアローケーションの後、それらのファイルをバッファ・キャッシュ１７０に格納しておく必要はない。さらに、重要なことに、クライアント要求を補助的な外部記憶装置のキャッシュに格納しておく必要はない。なぜなら、日付の復元が済めば、一次ストレージシステムは、二次上のクライアント要求をアクセスする必要はもはやないからである。

この特殊なロードパスを実施する１つの方法は、バッファ・キャッシュ中にある要求発生器によって生成されたデータを不要なものとしてマーキングし、そのデータがディスクに書き込まれた後、直ぐにそのデータをキャッシュから取り除くことができるようにすることである。不要なデータのマーキングは、ＬＲＵ（Least Recently Used)アルゴリズムに変更を加えたものによって実施することができる。データを不要なものとしてマーキングする場合、そのデータを格納しているキャッシュブロック（バッファ）は、ＬＲＵスタックの末尾ではなく先頭に置かれ、そのキャッシュブロックが、再使用される最初のバッファになるようにする。あるいは、不要なキャッシュをすべてバイパスする新たなロードパス伝送リンクを作成してもよい。ただし、この代替策は、ハードウェアの変更を必要とする。当業者には分かるように、本発明の範囲内で、キャッシュ汚染を防止するための他の方法を使用することも可能である。

また、要求発生器２９６は、一連のリモート・フェッチ・オペレーションに関連するデータの取得を改良するために、先読み機能を実施する場合がある。要求発生器によって有利に使用される先読みアルゴリズムについては、Robert L. Fairによる「ADAPTIVE FILE READAHEAD TECHNIQUE FOR MULTIPLE READ STREAMS」と題する同時係属の米国特許出願第１０／７２１，５９６号、及びRobert L. Fairによる「ADAPTIVE FILE READAHEAD BASED ON MULTIPLE FACTORS」と題する米国特許出願第１０／７５３，６０８号に記載されており、これらの特許出願はいずれも、参照により本明細書に援用される。要求発生器は、ファイルシステム２８０と協働し、後続のフェッチオペレーションによって要求される可能性があるブロックを読み出すための推測的先読みオペレーションを実施する。例えば、一連のブロックを読み出すための読み出し要求に応答して、ファイルシステムは先読みオペレーションを実施し、その一連のブロックの後に続くブロックが要求発生器によってまだ要求されていなくても、それら後続のブロックを読み出すための先読みオペレーションを実施する場合がある。これは、例えば、一連の不在ブロックを読み出すときに有用な場合がある。

さらに別の実施形態として、ストレージ・オペレーティング・システム上で実行される複数の要求発生器を使用して、データ復元の効率を高めることも可能である。その際、各要求発生器は、散在ボリューム中のブロックの一部だけを担当する。例えば、２つの要求発生器は、１つのタスクを等しい部分に分割し、第１の要求発生器は、一連のアドレスのうちの最初の半分を担当し、第２の要求発生器は、次の半分を担当する場合がある。当業者には分かるように、複数の要求発生器の代替構成には多数の構成が考えられ、それらの変形構成もまた、本発明の範囲、及び保護対象に含まれる。

ポンプモジュール
本発明の他の実施形態によれば、ポンプモジュール２９８は、要求発生器２９６によって生成された要求、及びクライアント１１０によって発行された要求の処理を調節するためのフロー制御を提供する。フロー制御が必要になることがある理由は、スキャナ、及び要求発生器は、外部記憶装置からブロックをフェッチし、復元するために要する時間よりも実質的に高速に、ファイルシステムのブロックを求めるアクセス要求を発行、及び生成することが出来るからであり、その主たる理由は、フェッチオペレーションや復元オペレーションが、ネットワーク遅延やディスクアクセス遅延（データが二次外部記憶装置のキャッシュ上にない場合があるため）、あるいは他の外部遅延による影響を強く受けるからである。したがって、そのようなフェッチオペレーションや復元オペレーションは、システム性能の「ボトルネック」になることがあり、その結果、未処理のデマンド、及び要求の「バックログ（残務）」が発生することがある。

散在ボリューム中の欠落データを求める未処理のデマンド、及び要求の数が、所定の閾値に達すると、ポンプモジュール２９８は、要求発生器２９６を調節し、要求発生器が生成する要求の数を低速化させるか、または一時的に中断させる。ポンプモジュールはさらに、優先順位決定ポリシーを実施する場合がある。優先順位決定ポリシーは、例えば、
空きのシステムリソースが限られているときに、クライアントが発行した要求に対し、欠落ブロックを求めて生成された要求よりも高い優先順位を与えるものである。

図１３は、ポンプモジュールを使用してフロー制御を実施するための手順１３００を示すフロー図である。手順はステップ１３０５から開始され、ステップ１３１０へ進み、そこで、クライアントからのデータアクセス要求を監視する。例えば、そうした要求のサイズ、及び数をポンプモジュールによって記録する。ステップ１３１５において、ポンプモジュールはさらに、要求発生器によって生成されたデータアクセス要求（デマンド）を監視する。ステップ１３２０において、要求発生器からの要求／デマンドの数が所定の閾値（例えば、要求発生器にとって許容される要求の最大数）に達すると、ステップ１３２５において、ポンプモジュールは要求発生器を調節し、生成される要求の数を低速化、すなわち減少させる。この文脈における「調節」は、多数の方法で実施することができ、例えば、復元トラフィックの速度（例えば、最大１００ｋＢ／秒）を調節し、またはスキャナを一時的に停止させ（後で処理を再開できるようになるまで）、スキャナの減速させることによって達成することができる。

また、ポンプモジュールは、要求発生器により生成された要求、及びクライアントにより発行されたデータアクセス要求に関する優先順位決定手段としての機能をさらに有する場合がある。オン・デマンド復元オペレーションの実行中に通常オペレーションであるかのように見せかけるために、要求発生器は、遅延過多のファイルアクセス時間を有するクライアントをそのままにして、復元に利用可能な帯域幅を消費してはならない。この状況を確実に回避するために、ポンプモジュールは、クライアントからの要求に対し、要求発生器からの要求に与えられる優先順位よりも高い優先順位を与える。具体的には、要求発生器が、ステップ１３２０においてまだ最大閾値に達していない場合、又は、ステップ１３２５において調節された場合、ステップ１３３０においてポンプモジュールは、要求発生器が、クライアントデータアクセス要求のための空きリソースを制限する形でリソースを過剰使用（消費）しているか否かを判定する。過剰使用している場合、ステップ１３３５において、ポンプモジュールは、クライアントデータアクセス要求に優先権を与える。これは例えば、要求発生器を保留状態してから、ステップ１３１０へ戻り、要求を更に監視することによってなされる。貴重なリソースが大量に消費されてはいなかった場合、要求発生器は引き続き無視され、手順はステップ１３１０へ戻る。要求のタイプによっては、異なるレベルの優先順位が与えられる場合もある。例えば、特殊なファイルシステムコマンドには、高い優先順位が与えられ、先読みには低い優先順位が与えられる場合がある。

本発明の一実施形態において、ポンプモジュールは、ある種のキューとして機能するように編成された複数のスレッドとして実施され、そのキューを通して全てのデータフェッチ要求が、二次フローへと送られる場合がある。ポンプモジュールは、例えば、例示的なＮＲＶプロトコルを使用して、実際のフェッチ要求を生成する場合がある。各スレッドは、一度に１つの要求を処理し（すなわち、生成し、送信し）、次の要求を処理する前に、その要求に対する応答を待つように命じられる。さらに、複数のスレッドを使用することにより、要求を順不同で完了させることが可能になる。これは、当該技術分野におけるいわゆるリーキー・バケット・アルゴリズムと呼ばれるものに似ている。さらに、所定数のスレッドが使用可能であれば、要求発生器は、ポンプモジュールに対して要求を発行することができる。例えば、ポンプモジュールは、千個のスレッドを有するように構成される場合があり（すなわち、要求キューの長さが千である）、それによって、クライアントが発行した要求に対しては実質的に無制限のサービスを提供できるが、要求発生器が発行した要求に対しては、少なくとも１０個のスレッドが空いていないと、サービスを提供できないという制限を有する場合がある。したがって、クライアント要求が何も発行されなければ、要求発生器は、任意のある時点において最大で９０個の要求を送信することができる。

なお、本発明の教示は、まばらに構成されたボリュームとともに使用することもできる。例えば、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルレイアウト（ＷＡＦＬ）ファイルシステムのように、ファイルシステムによっては、まばらに構成されたデータコンテナを生成する機能を有するものがあり、まばらに構成されたデータコンテナは、コンテナ作成時にディスクに完全には書き込まれない。

本明細書では、データコンテナという用語は通常、ファイルシステム、ディスクファイル、ボリューム、または論理番号（ＬＵＮ）などのデータを格納するための記憶単位を意味する。論理番号は、例えば独自の一意の識別子によってアドレス指定することができる。ディスク上のまばらに構成されたデータコンテナのデータ内容を収容するために必要とされる記憶空間は、まだ使用されていない。まばらに構成されたデータコンテナの詳細については、Vijajan Rajan他による「SYSTEM AND METHOD FOR RECLAIMING UNUSED SPACE FROM A THINLY PROVISIONED DATA CONTAINER」と題する米国特許出願第１０／９６６，６０５号に記載されている。

オン・デマンド復元環境において、まばらに構成されたデータコンテナの使用は、災害復旧時に、一次ストレージシステムに使用される場合がある。一次ボリュームの総量のうちの一部についてしか物理記憶を持たないまばらに構成された一次データコンテナを使用することにより、管理者は、二次のトータルサイズの物理記憶を調達する必要はなくなるが、使用されることになるファイル／データコンテナに必要とされる空間の大きさだけは、決めることができる。

もう一度まとめると、本発明は、ストレージシステムのようなコンピュータの散在ボリュームに対するオン・デマンド復元（ＲＯＤ）オペレーションを実施するシステム、及び方法に関する。散在ボリュームは、コンテナ内部に格納された１以上のファイルが、データを得るために特殊な読み出し処理を必要とするデータコンテナ、すなわちボリュームである。本発明によれば、ローカル記憶装置が故障したときに、ローカル記憶装置の使用を迅速に復旧するために、散在ボリュームを使用する場合がある。ボリュームは不在ブロックを有し、その後、そのデータが、オン・デマンドで復元される。データの復元は、クライアントデータアクセス要求を受信したときに達成され、または、要求発生器によって達成される。また、上記のように、要求発生器は、ポンプモジュールによって調節される場合がある。さらに、上記のように、散在ボリュームの復元が開始された後、そのボリュームは、全てのデータアクセスオペレーションについて使用可能になり、その結果、例えば、書き込みオペレーションを実施したり、バックアップオペレーションを開始したりすることができるようになる。

上記の説明は、本発明の特定の幾つかの実施形態に関するものである。しかしながら、当然ながら、記載した実施形態の利点の一部、または全部を維持したまま、記載した実施形態に対し他の改変、及び変更を施すことも可能である。例えば、当然ながら、本発明の教示は、コンピュータ上で実行されるプログラム命令を有するコンピュータ読み取り可能媒体を含むソフトウェアでも、ハードウェアでも、ファームウェアでも実施することができ、また、それらの組み合わせとして実施してもよい。したがって、本明細書の説明は、例として捉えるべきものであり、本発明の範囲を制限するものではない。添付の特許請求の範囲の目的は、そうした改変や変更も本発明の真の思想、及び範囲に含めることにある。

本発明一実施形態による例示的ネットワーク環境を示す略ブロック図である。 本発明の一実施形態による例示的ストレージ・オペレーティング・システムを示す略ブロック図である。 本発明の一実施形態による例示的ｉｎｏｄｅを示す略ブロック図である。 本発明の一実施形態による例示的バッファ・ツリーを示す略ブロック図である。 本発明とともに有利に使用されるファイルのバッファ・ツリーの一実施形態を示す略ブロック図である。 本発明の一実施形態による例示的集合体を示す略ブロック図である。 本発明の一実施形態による例示的オン・ディスク・レイアウトを示す略ブロック図である。 本発明の一実施形態による例示的ｆｓｉｎｆｏブロックを示す略ブロック図である。 本発明の一実施形態によるデータアクセス要求を処理する手順のステップの詳細を示すフロー図である。 本発明の一実施形態による故障したボリュームを復元する手順のステップの詳細を示すフロー図である。 本発明の一実施形態による要求発生器を動作させる手順のステップの詳細を示すフロー図である。 本発明の一実施形態によるスキャナによりトラバースされる計画されたシーケンスのステップの詳細を示すフロー図である。 本発明の一実施形態によるポンプモジュールにおいてフロー制御を実施するための手順のステップの詳細を示すフロー図である。

Claims (10)

1. 第１の記憶装置とともに使用される方法であって、
   第１のストレージシステムに接続された第１の記憶装置に記憶された故障したボリュームを検出するステップであって、前記故障したボリュームのバックアップコピーが、故障前に第２のストレージシステムに接続された第２の記憶装置に記憶されている、第１のストレージシステムに接続された第１の記憶装置に記憶された故障したボリュームを検出するステップを検出するステップと、
   新たなボリュームを作成するステップであって、ファイルシステムのバージョン、故障したボリュームのトータルサイズ、及びルートファイルシステムディレクトリの中身のうちの少なくとも１つを含む新たなボリュームのためのインフラストラクチャメタデータを前記第２のストレージシステムからフェッチし、１以上のブロックのデータが、前記第２の記憶装置に置かれていることを示す前記１以上のブロックへのポインタを新たなボリュームに入れることにより、新たなボリュームを前記インフラストラクチャメタデータで初期化することを含む、新たなボリュームを作成するステップと、
   前記故障したボリュームを前記新たなボリュームに置き換えるステップと、
   前記１以上のブロックのデータを前記新たなボリュームの中に復元するステップであって、前記第２のストレージシステムに対しフェッチ要求を発行し、前記第２の記憶装置から前記１以上のブロックのデータをフェッチすることを含む、前記１以上のブロックのデータを前記新たなボリュームの中に復元するステップと
   を含み、前記新たなボリュームに対するデータアクセスオペレーションは、前記１以上のブロックのデータを前記新たなボリュームの中に復元する前に可能にされる、方法。
2. 前記フェッチ要求は、前記１以上のブロックのデータをアクセスするためのクライアント要求に応答して発行される、請求項１に記載の方法。
3. 前記フェッチ要求は、前記１以上のブロックを探すように構成された要求発生器によって発行される、請求項１に記載の方法。
4. リモート・バックアップ・ボリュームへの前記新たなボリュームのバックアップ・オペレーションを開始することを更に含む、請求項１〜３のうちのいずれか一項に記載の方法。
5. 第１の記憶装置とともに使用されるシステムであって、
   第１の記憶装置に記憶された第１のボリュームを有する第１のストレージシステムであって、前記第１の記憶装置が、第１のストレージシステムに接続される、第１のストレージシステムと、
   前記第１のボリュームのバックアップ・コピーを有するように構成された第２のストレージシステムであって、前記バックアップ・コピーが、第２のストレージシステムに接続された第２の記憶装置に記憶される、第２のストレージシステムと
   を含み、
   前記第１のストレージシステムは、前記第１のボリュームの故障に応答し、前記第１の記憶装置に記憶される散在ボリュームを作成するように構成され、前記第１のストレージシステムは、ファイルシステムのバージョン、前記第１のボリュームのトータルサイズ、及びルートファイルシステムディレクトリの中身のうちの少なくとも１つを含む前記散在ボリュームのためのインフラストラクチャメタデータを前記第２のストレージシステムからフェッチし、前記第２のストレージシステムに記憶されたバックアップ・コピー上のデータを指す複数のポインタを前記散在ボリュームに入れることにより、前記散在ボリュームを前記インフラストラクチャメタデータで初期化し、前記第２のストレージシステムに対しフェッチ要求を発行し、前記第２のストレージシステムから前記データをフェッチすることにより、前記データを前記散在ボリュームに復元するように構成され、
   前記散在ボリュームに対するデータアクセスオペレーションは、前記データを前記散在ボリュームに復元する前に可能にされる、システム。
6. 前記フェッチ要求は、前記データに対するクライアント要求に応答して発行される、請求項５に記載のシステム。
7. 前記フェッチ要求は、要求発生器によって発行され、前記要求発生器は、ＡＢＳＥＮＴポインタを有するブロックを探し、ＡＢＳＥＮＴポインタを有するブロックを特定することに応答して、欠落データを前記第２のストレージシステムから取得するためのリモート・フェッチ・オペレーションを開始する、請求項６に記載のシステム。
8. 前記第１のストレージシステムは、前記要求発生器のフロー制御を実施するためのポンプモジュールを備えるように更に構成される、請求項７に記載のシステム。
9. 前記ポンプモジュールは、クライアントが発行した要求に対し、前記要求発生器によって発行された要求よりも高い優先順位を与える優先順位決定ポリシーを実施する、請求項８に記載のシステム。
10. 前記第１のボリュームは複数のオブジェクトを含み、該オブジェクトは、ＬＵＮ、ディレクトリ、ｑｔｒｅｅ、特殊なデータコンテナ、又はファイルからなる、請求項５〜９のうちのいずれか一項に記載のシステム。

Images