JP4824085B2 - ネットワークファイルシステムをキャッシュするシステム、及び方法 - Google Patents

Description

[発明の分野]
本発明はキャッシュシステムに関し、詳しくは、コンピュータネットワークを介してマルチプロトコルクライアントによって発行されたデータアクセス要求に応答する、キャッシング・ファイラにより提供されるデータのストレージ仮想化に関する。

[発明の背景]
遠隔地を保有する組織は、しばしば、エンジニアリングアプリケーションやライブラリなどの重要なデータを別の場所に複製しなければならないことがある。ネットワーク遅延を受けることなく、そのような重要なデータを遠隔地にいるユーザが利用できるようにするために、組織は、相当なリソース（例えば、ファイルサーバで実行されるファイルシステムなど）を消費して、複雑な複製インフラストラクチャ、及びシステムを管理することがある。データ複製は一般に、読み出し専用データセットに対する分散オンラインアクセスを可能にする既知の技術である。従来のデータ複製は、データセットの読み出し専用コピー全体を分散サーバ上に作成するために、ファイルシステムミラーリングに大きく依存することが多い。

ファイルシステムミラーリングにより生成されるミラーは一般に、大量の管理コストを必要とする。例えば管理者は、複製しなければならないデータを判断しなければならないだけでなく、各ミラーに使用される実際のリソース（ファイルシステムやファイルサーバなど）も管理しなければならない。データセットが大きくなると、この種のデータ複製は、次第に現実的でなくなる。また、複製インフラストラクチャは、複製データを格納するために、遠隔地にサーバの存在を必要とする。そのため組織は、自分達のサーバインフラストラクチャを中央位置に集約することができない。したがって、重要データに対する迅速なアクセスの利点を損なうことなく、高価な複製インフラストラクチャ、及びプロセスを不要にすることが、いまだに必要とされている。

データ複製ミラーリングに代わる１つの代替策が、プロキシキャッシングである。プロキシキャッシングシステムは通常、データセットをオンデマンドで透過的に複製する目的で使用される。一般的なプロキシキャッシュシステムは、フロントエンド・ストレージシステム、またはローカルストレージ（すなわち、「キャッシュ」）を備えた「プロキシデバイス」を備え、フロントエンド・ストレージシステムは、バックエンドストレージシステムに、すなわちリモートストレージを備えた「起源サーバ」に接続される。クライアント要求がキャッシュにより満たされない場合、そのクライアント要求は、起源サーバに渡される。そして、サーバ応答が、要求元クライアントへ返送され、関連データはすべて、ローカルストレージにキャッシュされる。この種のトランザクションは、「キャッシュ・ミス」と呼ばれる。キャッシュ・ミスの結果、一般に、ファイルシステムデータのようなデータがキャッシュに「入れられる」ことになる。クライアント要求を満たすために必要なデータがキャッシュ上にあれば、プロキシデバイスは、関連サーバと通信することなく、応答を構築し、送信することができる。そのようなトランザクションは、「キャッシュ・ヒット」と呼ばれる。キャッシュ・ミス・トランザクションを使用して、プロキシデバイスは、クライアントに対し、プロキシデバイス上のファイルシステムの状態の変更を許可する。その結果、標準的な複製とは違い、クライアントを読み出し専用アクセスに制限することなく、自動的複製が可能となる。

従来のプロキシキャッシング解決策によれば、絶え間ない実地的管理を必要とせずに、例えばファイルのようなデータを遠隔地に配布する機能が得られる。そのようなプロキシキャッシング解決策の一例は、E. Ackaouyにより出願され、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドに譲渡された「Apparatus and Method for a Proxy Cache」と題する米国特許出願第（Ｐ０１−１５０９）号に記載されている。キャッシュを備えたプロキシ・ストレージシステム、またはアプライアンスが、サーバ・ストレージシステムに接続される。ファイルシステムは、プロキシアプライアンスが提供する一組のファイルを管理する。そして、それらのファイルは、ネットワーク・ファイル・システム（ＮＦＳ）プロトコル、および／またはコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルのようなファイルシステムプロトコルを使用して、クライアントからアクセスされる。これに応答し、プロキシ・アプライアンスは、ファイルハンドルに基づくファイル・インデックス・ハッシュ手段を使用して、ファイルを提供する。

簡単に言えば、プロキシ・アプライアンスは、クライアントが発行するＮＦＳ／ＣＩＦＳデータアクセス要求を「監視（listen）」し、ローカル・ハッシュ手段を使用してその要求に応じることが出来るか否かを判断する。その目的のために、プロキシ・アプライアンスは、クライアント要求を自分のファイルシステムに渡してキャッシュ判断を行う前に、そのクライアント要求を一意のキャッシュ名に変換する。ファイルハンドルに対して実施されるハッシュ機能は、ファイルシステムがキャッシュファイル、またはオブジェクト記憶識別子を取得し、ファイルがキャッシュ上にあるか否かを判定するために使用されるキャッシュ名を生成する。ファイルがキャッシュ上にあれば、クライアントによって要求されたデータがすべてキャッシュ上にあるか否かの判定がなされる。キャッシュ上に無い場合、プロキシ・アプライアンスは、その要求を代わりにサーバに渡す。要求されたデータ、または確認メッセージがサーバから返送されると、プロキシ・アプライアンスは、そのサーバ応答をクライアントに渡す。また、プロキシ・アプライアンスは、そのサーバ応答を自分のキャッシュに「入れ」、次のクライアント要求を当該プロキシ・アプライアンスによって処理できるようにする。

本発明は、１つには、キャッシュシステムによって提供されるデータをクライアントからマルチプロトコルアクセスすることが可能な改良型キャッシュシステムに関する。また、本発明は、１つには、キャッシュシステムによって提供されるデータを、ファイルシステムデータ構造、及び名前を使用して、クライアントから効率よくアクセスすることが可能な改良型キャッシュシステムに関する。さらに、本発明は、１つには、クライアントによって発行されたマルチプロトコルデータアクセス要求に応答して、キャッシュシステムによって提供されるデータをストレージ仮想化することが可能な改良型キャッシュシステムに関する。この文脈において、ストレージ仮想化とは、通常、ネットワーク全体にわたる複数のストレージシステムからのストレージリソースを協働させるクライアントに対し、ストレージの透過的ビューを提供することを意味する。

［発明の概要］
本発明は、起源サーバに接続され、コンピュータネットワークを介してマルチプロトコル・クライアントから発行されたデータアクセス要求に応答して、ファイラにより提供されるデータをストレージ仮想化するための、マルチプロトコル・キャッシング・ストレージシステムを備えたネットワーク・キャッシング・システムに関する。このマルチプロトコル・キャッシング・ファイラは、散在ボリュームを管理するように構成されたファイルシステムを含み、それによって、マルチプロトコル・クライアントによるデータアクセスを可能にするキャッシュ機能を提供する。その目的のために、キャッシング・ファイラは、マルチプロトコル・クライアントデータアクセス要求を、キャッシング・ファイラと起源サーバのどちらによっても実行可能な汎用的なファイルシステム・プリミティブ・オペレーションに変換する。

例示的実施形態として、このキャッシュ機能の一部は、キャッシング・ファイラに接続された１以上のディスクからなるキャッシュ・ボリュームを含むキャッシング・ファイラの「ローカル・キャッシュ」によって提供される。本発明の一態様によれば、キャッシュ・ボリュームは、例えば、クライアントから要求されたデータを例えばファイルのような１以上のストレージ・オブジェクトから提供するように構成された散在ボリュームとして実施され、キャッシュボリューム中の少なくとも１つのブロックは抜けている場合がある（すなわち、不在ブロック）。この不在ブロックの抜けデータは、起源サーバに格納され、例えば、リモート・フェッチ・オペレーションを使用して、クライアントに対して透過的な態様で取得（「」）される。

有利なことに、本発明によれば、マルチプロトコル・キャッシング・ファイラの空き記憶空間を利用して、ネットワーク・キャッシング・システムにより提供されるデータに対する高速かつ効率的なクライアントアクセスが可能なする。ファイルハンドルからオブジェクト記憶への明示的な変換が必要な従来のキャッシュシステムとは違い、この新規なマルチプロトコル・キャッシング・ファイラによれば、ファイルシステムを使用することで、具体的には、ファイルシステムによって編成されたストレージ・オブジェクト（ファイル）の実際の名前を使用することで、ネットワーク・キャッシング・システムが提供するデータに対する効率的なクライアントアクセスが可能になる。さらに、ファイルシステムは、キャッシング・ファイラの散在ボリュームと協働し、マルチプロトコルクライアントに対して透過的な態様で、提供されたデータのストレージ空間仮想化を行うことができる。

本発明の上記の利点、および他の利点は、添付の図面を参照し、下記の説明を読めれば更によく分かるであろう。図中、同じ参照符号は、同一の、または機能的に同一の要素であることを意味している。

［例示的実施形態の詳細な説明］
Ａ．ネットワーク環境
図１は、バックエンド・ストレージシステムから伝送された情報（データ）に対するキャッシュ機能を提供するように構成されたフロントエンド・ストレージシステムを含むネットワーク・キャッシュ・システム環境１００を示す略ブロック図である。その目的のために、フロントエンド・ストレージシステムは、例えば、ディスクアレイ１６０のディスク１３０のような記憶装置上での情報の編成に関するストレージサービスを提供するキャッシング・ファイラ１２０として実施されるコンピュータである。キャッシング・ファイラ１２０は、システムバス１２５によって相互接続されたプロセッサ１２２、メモリ１２４、１以上のネットワークアダプタ１２６ａ，ｂ、およびストレージアダプタ１２８を含む。また、キャッシング・ファイラ１２０は、ストレージ・オペレーティング・システム２００を更に含み、ストレージ・オペレーティング・システム２００は、ファイルシステムのような高レベルモジュールを実施し、情報を名前付きファイル、ディレクトリ、および仮想ディスク（以後、特殊ファイル、または「ブロック」と呼ぶ）ストレージ・オブジェクトとしてディスク上に論理編成する。

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

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

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

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

アレイ１６０への情報の格納は、１以上のストレージ「ボリューム」として実施されることが好ましい。ストレージボリュームは、一群の物理ストレージディスク１３０を含み、それらが協働して、ボリューム（複数の場合もあり）上のボリュームブロック番号（ｖｂｎ）空間の全体的論理構成を規定する。必須ではないが、各論理ボリュームは一般に、そのボリューム独自のファイルシステムに関連する。論理ボリューム、および／またはファイルシステム内のディスクは通常、１以上のグループとして編成され、各グループが、ＲＡＩＤ(Redundant Array of Independent Disks)として運用される場合がある。ＲＡＩＤ−４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理的ディスクにわたってデータストライプを冗長書き込みし、そのストライプ状データに関するパリティ情報を適切に格納することによって、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例は、ＲＡＩＤ−４レベル実施形態である。ただし、他のタイプ、または他のレベルのＲＡＩＤ実施形態を本明細書に記載する本発明の原理にしたがって使用することも可能である。

一実施形態として、キャッシング・ファイラ１２０のキャッシュ機能は、１つには、「ローカル・キャッシュ」によって与えられる。この文脈において、ローカル・キャッシュとは、（１）高レベルプロセッサ・キャッシュ１２３、（２）中間レベルバッファ・キャッシュ１７０、および（３）キャッシング・ファイラに接続された１以上のディスク１３０からなる低レベル「第３」キャッシュボリューム１５０を含むキャッシュメモリ階層を意味する。本明細書に記載する本発明の一態様によれば、キャッシュ・ボリューム１５０は例えば、クライアント１５０によって要求されたデータを例えばファイルのような１以上のストレージ・オブジェクトから提供するように構成された散在ボリュームとして実施され、キャッシュ・ボリューム１５０中の少なくとも１つのブロック（すなわち、不在ブロック）は抜けている（すなわち、そのボリュームのローカルディスクに記憶されていない）場合がある。この不在ブロックの抜けているデータは、外部記憶装置に記憶され、例えば、リモート・フェッチ・オペレーションを使用して、クライアントに対して透過的な態様で取得される。

外部記憶装置は、キャッシング・ファイラ１２０と同様の、例えば起源サーバ１８０として実施されるコンピュータであり、ディスク上に起源ボリューム１８５として編成される情報の編成に関するストレージサービスを提供するコンピュータである。起源サーバ１８０は、ネットワーク１４０を介してキャッシング・ファイラ１２０に相互接続され、一般に、ファイラ１２０と同様のハードウェアを備える。ただし、起源サーバ１８０は、ストレージシステムを起源サーバとしての使用に適合される改変されたストレージ・オペレーティング・システムを実行する。本明細書に記載する代替実施形態では、複数のキャッシング・ファイラ１２０が、ネットワーク・キャッシングシステム環境１００中の起源サーバ１８０に接続される場合がある。

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

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

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

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

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

後で詳しく説明するように、ストレージ・オペレーティング・システム２００の要求発生器２９６は、ローカルディスク上に格納されていないデータブロック、すなわち、キャッシング・ファイラ１２０のキャッシュボリューム１５０に格納されていないデータブロックをシステムが取得するために使用される。一方、ポンプブロック２９８は、要求されたそれらのブロック、および他のブロックの起源サーバ１８０からの取得を調節するためにも使用される場合がある。また、本発明によれば、トランケータ２９４は、ローカル・キャッシュ（例えば、キャッシュ・ボリューム１５０）が一杯になったときに、記憶空間を返還要求するためのキャッシュ破棄ポリシーを実施し、リモート・アップデート・エンジン（ＲＵＥ２９２）は、キャッシュボリューム１５０に変更を加えると思われるファイルシステムオペレーションを起源サーバ１８０へ転送するために使用される。要求発生器２９６、ポンプ２９８、トランケータ２９４、およびＲＵＥ２９２は、本明細書では個別のソフトウェアモジュールとして図示説明されているが、それらは、オペレーティングシステム２００の単一のモジュールとして一体化してもよい。さらに、それらのモジュールは、ハードウェアとして実施しても、ソフトウェアとして実施しても、ファームウェアとして実施してもよく、あるいは、それらの任意の組み合わせとして実施してもよい。

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

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

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

動作としては、クライアント１１０からの要求は、コンピュータネットワーク１４０を介してパケットとしてキャッシング・ファイラ１２０に転送され、そこで、ネットワークアダプタ１２６によって受信される。（層２１０、または層２３０の）ネットワークドライバは、必要に応じてそのパケットを処理し、ネットワークプロトコル、およびファイルアクセス層に渡し、更なる処理を施した後、それをｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム２８０へ転送する。後で詳しく説明するように、要求が、キャッシュボリューム１５０に格納されたデータを変更するものであった場合、キャッシング・ファイラ１２０は、ＮＲＶ書き込み要求を介して、その要求を起源サーバ１８０に送る。一方、その要求が、ボリューム１５０上のデータを変更するものでなかった場合、その要求はファイルシステム２８０へ直接渡され、ファイルシステム２８０は、その要求に応じることを試みる。データがローカル・キャッシュ上になければ（「キャッシュミス」になる場合）、キャッシング・ファイラは、ＮＲＶ読み出し要求を起源サーバ１８０に送り、無かったデータをフェッチする。サーバ１８０から応答を受け取ると、キャッシング・ファイラは、フェッチしたデータを自分のローカル・キャッシュに格納し、要求されたデータを含む応答を作成し、その応答をクライアント１１０へ返す。

一方、要求されたデータがローカル・キャッシュ上にあれば、キャッシング・ファイラ（ファイルシステム２８０）は、その要求に応じる。その目的のために、ファイルシステムは、要求されたデータが「コア内」に、すなわち、バッファ・キャッシュ１７０上になければ、要求されたデータをディスク１３０から読み出すオペレーションを生成する。このオペレーションは例えば、ファイルシステム２８０のＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４として実施される場合がある。情報がキャッシュ１７０上になければ、ファイルシステム２８０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイル内を検索し、適当なエントリにアクセスし、論理ｖｂｎを取得する。次に、ファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム２４０に渡す。そして、論理ｖｂｎは、ディスク識別子、およびディスクブロック番号（ディスク、ｄｂｎ）にマッピングされ、ディスクドライバシステム２５０の適当なドライバ（例えばＳＣＳＩドライバ）へと送られる。ディスクドライバは、指定されたディスク１３０からそのｄｂｎをアクセスし、要求されたデータブロック（複数の場合もあり）をバッファキャッシュ１７０にロードし、ファイラによって更なる処理を施す。要求が完了すると、キャッシング・ファイラ（および、オペレーティングシステム）は、ネットワーク１４０を介してクライアント１１０に返答を返す。

ファイルシステム２８０は一般に、ディスクから１以上のブロックを読み出すためのＬｏａｄ＿Ｂｌｏｃｋ（）関数を有する。それらのブロックは、読み出し要求に応答して読み出される場合もあれば、例えばファイルに対する先読みアルゴリズムに応答して読み出される場合もある。後で詳しく説明するように、ファイルのバッファ・ツリー内の何らかの要求されたブロックが特殊なＡＢＳＥＮＴ値を有している場合（すなわち、不在ブロックであることを意味している場合）、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、例えばＮＲＶプロトコル２９５を使用して、適当な外部記憶装置（例えば、起源サーバ１８０）からその不在ブロックを取得するためのフェッチ動作を開始する。不在ブロック（任意のデータブロックを含む）の取得が済むと、Ｌｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、要求されたデータを返す。ＮＲＶプロトコルの詳細については、「Architecture for Supporting of Sparse Volumes」と題するJason Lango他による上で参照した米国特許出願に記載されている。ただし、遠隔の外部記憶装置からデータを取得できる適当なプロトコルであれば、例えばＮＦＳプロトコルのようないかなるファイルベース、またはブロックベースのプロトコルでも、本発明とともに有利に使用することができる。また、ファイルシステムは、例えば、ファイルを最初にアクセスするときにｉｎｏｄｅ、およびファイルジオメトリを取得するＬｏａｄ＿Ｉｎｏｄｅ（）関数２８８をさらに含む場合がある。

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

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

さらに、当業者には分かるように、本明細書に記載する本発明のシステム、および方法は、ストレージシステムとして実施される、またはストレージシステムを含むスタンドアロンのコンピュータや、その一部を含め、いかなるタイプの特殊目的のコンピュータ（例えば、ファイルサーバ、ファイラ、またはマルチプロトコル・ストレージ・アプライアンス）、または汎用コンピュータにも適用することが可能である。本発明とともに有利に使用されるマルチプロトコル・ストレージ・アプライアンスの一例は、２００２年８月８日に出願された「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」と題する米国特許出願第１０／８３６，８１７号に記載されている。基礎物理ボリュームは、キャッシング・ファイラのＲＡＩＤグループのような１以上のディスクグループの集合体である。この集合体は、独自の物理的ボリュームブロック番号（ｐｖｂｎ）空間を有し、そのｐｖｂｎ空間内において、ブロックアロケーション構造のようなメタデータを管理する。各ｖｖｏｌは、独自の仮想ボリュームブロック番号（ｖｖｂｎ）空間を有し、そのｖｖｂｎ空間内において、ブロックアロケーション構造のようなメタデータを有する。各ｖｖｏｌは、コンテナファイルに関連するファイルシステムであり、コンテナファイルは、ｖｖｏｌによって使用される全てのブロックを含む、集合内のファイルである。また、各ｖｖｏｌは、データブロック、および間接ブロックを含み、間接ブロックは、他の間接ブロック、またはデータブロックを指すブロックポインタを含む。

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

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

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

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

さらに、ポインタ５０８のうちの幾つかは、それらのポインタ（複数の場合もあり）によって参照されるオブジェクト（複数の場合もあり）（例えば、間接ブロック、またはデータブロック）がローカルに記憶されていないことを示す特殊なＡＢＳＥＮＴ値を有する場合がある。その場合、それらのオブジェクトは、起源サーバ１８０の起源ボリューム１８５からフェッチ（取得）しなければならない。例示的実施形態として、ファイルシステム２８０のＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、各ポインタの中身を解釈し、要求されたブロックが「不在（ＡＢＳＥＮＴ）」であれば、例えばＮＲＶプロトコルを使用して、そのデータの適当な要求（例えば、リモートフェッチオペレーション）を起源サーバ１８０に送信する。

なお、キャッシュボリューム１５０は、例えばフレキシブルｖｖｏｌとして実施される一方、起源ボリューム１８５は、フレキシブルｖｖｏｌとして実施される場合も、従来のボリュームとして実施される場合もある。その主たる理由は、論理ファイルプロトコル（ＮＲＶ）を使用するためである。上記のように、従来のボリュームとフレキシブルｖｖｏｌの間には、間接ブロックフォーマットに違いがある。ただし、ネットワーク・キャッシュ・システムにおいて、間接ブロックフォーマットの違いは無意味である。換言すれば、キャッシュボリュームと起源ボリュームの間には物理的関係が何も存在しないので、起源ボリュームのタイプは無意味である。

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

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

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

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

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

また、ｖｖｏｌが散在ボリュームである場合、隠しメタデータディレクトリ７３０は更に、１つのｖｖｏｌあたり１つの散在設定メタファイル（「散在設定ファイル」７３２）を有する。したがって、散在設定ファイル７３２は、散在ボリュームに関連し、その目的のために、（中でもとりわけ）起源サーバ１８０のホスト名、および起源ボリューム１８５を識別する。散在ボリュームのマウント処理の際、散在設定ファイル７３２が取得され、コア内フォーマットに変換される。特に、散在設定ファイルは、散在ボリュームがキャッシュ・ボリューム１５０であるか否かを示す識別子をさらに含む。それらの識別子により、後で詳しく説明するように、キャッシング・ファイラ１２０は、種々のクライアント要求に対し、リモートアップデート、又はローカルアップデートを実施しなければならないか否かを判定することが可能になる。例えば、ネットワーク・キャッシュ・システム環境１００のキャッシング・ファイラは、リモートアップデートを実施する場合がある。

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

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

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

Ｄ．散在ボリューム
上記のように、キャッシュボリューム１５０は、例えば散在ボリュームとして実施される。したがって、「キャッシュボリューム１５０」という用語と「散在ボリューム１５０」という用語は、以後、同じ意味で使用される場合がある。散在ボリューム１５０は、不在ブロックを含むファイルが含まれることを示す、ボリューム（ｖｖｏｌ）のオンディスク構造の特殊なマーキングによって識別される。図８は、オンディスク構造を示す略ブロック図であり、このオンディスク構造は、例としてｆｓｉｎｆｏブロック８００になっている。ｆｓｉｎｆｏブロック８００は、ＰＣＰＩ（Persistent Consistency Point Image）ポインタ８０５、および散在ボリュームフラグフィールド８１０、ｉｎｏｄｅファイル８１５のｉｎｏｄｅを含み、代替実施形態では、さらに別のフィールド８２０を有する場合がある。ＰＣＰＩポインタ８０５は、ファイルシステムに関連するＰＣＰＩ（スナップショット）へのポインタのデュアルｖｂｎ（ｖｖｂｎ／ｐｖｂｎ）対である。散在ボリュームフラグフィールド８１０は、ｆｓｉｎｆｏブロックによって表わされるｖｖｏｌが散在するものであるか否かを識別する。例示的実施形態では、ボリュームが散在するものであることを示すためにフィールド８１０内にフラグがアサートされる。散在ボリュームフラグフィールド８１０は、ｆｓｉｎｆｏブロックに関連するｖｖｏｌのタイプを識別するタイプフィールドとしてさらに実施される場合がある。ｉｎｏｄｅファイル８１５のｉｎｏｄｅは、ｆｓｉｎｆｏブロックに関連するファイルシステムのｉｎｏｄｅファイル７６０（図７）へのルートレベルポインタを含むｉｎｏｄｅを含む。

散在ボリューム１５０内のデータブロックや間接ブロックのような特定のブロック（複数の場合もあり）が、ボリュームを提供しているキャッシング・ファイラ上に物理的に置かれていないことを示すために、ファイルの適当なブロックポインタ（複数の場合もあり）が、特殊なＡＢＳＥＮＴ（不在）値によってマーキング（ラベリング）される。この特殊なＡＢＳＥＮＴ値は、そのデータを代わりのソース、すなわち起源サーバ１８０から取得しなければならないことをファイルシステムに警告する。

データアクセス要求に応答して、ファイルシステム２８０のＬｏａｄ＿Ｂｌｏｃｋ（）関数２８４は、ファイルの適当なブロックポインタがＡＢＳＥＮＴとしてマーキングされているか否かを判定し、マーキングされている場合、リモートＮＲＶフェッチ（例えば、読み出し）オペレーションメッセージをキャッシング・ファイラから起源サーバへ送信し、要求されたデータをフェッチする。このフェッチ・オペレーションは例えば、起源ボリューム１８５に格納されたファイルの１以上のファイルブロック番号（ｆｂｎ）を要求する。なお、この説明は、単一の起源ボリュームに関するものになっているが、本発明の原理は、単一の散在ボリュームが複数の起源ボリュームによって支援され、各起源ボリュームが、散在ボリュームの全体、または一部を支援するような環境にも適用することが可能である。したがって、本明細書の教示を単一の起源ボリュームに限定されるものとして解釈してはならない。

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

なお、キャッシング・ファイラ１２０と起源サーバ１８０との間でネットワーク１４０を介して伝送されるＮＲＶメッセージはすべて、物理ディスクアドレスではなく、論理ファイルアドレスを含む。したがって、起源サーバストレージに対していかなる関係にあるキャッシング・ファイラストレージであっても、そのサイズを調節する必要はない。要求されたデータがキャッシング・ファイラに渡されると、そのデータは、適当なｖｖｂｎ（および／またはｐｖｂｎ）ブロック番号にしたがって、書き込みアロケーションされる。言い換えれば、キャッシュ・ボリューム１５０の書き込みアロケーションは、起源ボリューム１８５上での書き込みアロケーションからは、完全に独立している。

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

Ｅ．ネットワーク・キャッシュ・システムの動作
本発明は、起源サーバ１８０に接続されたマルチプロトコル・キャッシング・ファイラ１２０を有するネットワーク・キャッシュ・システム１００に関し、コンピュータネットワーク１４０を介してマルチプロトコルクライアント１１０によって発行されたデータアクセス要求に応答して、ファイラによって提供されるデータのストレージ仮想化を提供する、ネットワーク・キャッシュ・システム１００に関する。マルチプロトコル・キャッシング・ファイラ１２０は、散在ボリュームを管理し、データの記憶空間を「仮想化」するように構成されたファイルシステム２８０を含み、それによってキャッシュ機能を提供し、マルチプロトコル・クライアントによるデータへのアクセスを可能にする。その目的のために、キャッシング・ファイラは、マルチプロトコル・クライアント・データアクセス要求をキャッシング・ファイラと起源サーバ１８０の両方によって実行可能な汎用ファイルシステムプリミティブに変換するように構成されたストレージ・オペレーティング・システム２００のマルチプロトコルエンジンをさらに含む。

図９は、本発明の一実施形態による、データ変更アクセス要求を処理する手順９００のステップを示すフロー図である。本明細書において、データ変更アクセス要求とは、キャッシング・ファイラ１２０のキャッシュ・ボリューム１５０を変更する任意のオペレーションを含むアクセス要求である。そのような変更オペレーションの例には、例えば、作成（ファイル）、属性設定、および書き込みオペレーションがある。手順９００は、ステップ９０２から開始され、ステップ９０４へ進み、そこでクライアント書き込みをキャッシング・ファイラ１２０で受信する。ステップ９０６において、マルチプロトコルエンジンの適当なプロトコル層は、その書き込み要求をファイルシステム２８０へ転送するために、汎用ファイルシステム書き込みメッセージに変換する。

ステップ９０８において、ファイルシステムは、そのファイルシステム書き込みメッセージがキャッシュ・ボリューム１５０へ送られたものであるか否か、すなわち、そのメッセージが、リモートアップデートオペレーションを支援するように構成された散在ボリュームへ送られたものであるか否かを判定する。例えば、ファイルシステムは、ｆｓｉｎｆｏブロック８００、および散在設定ファイル７３２を検査することによって、この判定を実施する。上記のように、ｆｓｉｎｆｏブロック８００は、散在ボリュームフラグ８１０を有し、それがアサートされていれば、そのボリュームが散在ボリュームであることを示す。また、散在設定ファイル７３２は、適当なタイプの散在ボリュームを識別する、すなわち、データ変更アクセス要求のためのリモートアップデートがサポートされているか否かを示す識別子を含む。書き込みメッセージがキャッシュ・ボリュームへ送られたものでなかった場合、ファイルシステムは、そのファイルシステム書き込みメッセージをファイルシステムの従来の書き込みハンドラに渡し、プリミティブ書き込みオペレーション要求として処理し（ステップ９１０）、手順はステップ９２２で終了する。

一方、書き込みメッセージがキャッシュボリューム１５０へ送られたものであった場合、ステップ９１２において、ファイルシステムは、その書き込み要求をＲＵＥ２９２に転送する。ステップ９１４において、ＲＵＥ２９２は、その汎用ファイルシステム書き込みメッセージをリモートアップデート要求に変換し、ステップ９１６において、そのアップデート要求をポンプモジュール２９８へ送る。例示的実施形態において、ポンプモジュールのポンプ・ワーカー・スレッドは、その要求を受信すると、他の要求の中におけるその要求の優先順位を決める。ステップ９１８において、リモートアップデート要求は、ＮＲＶ書き込みメッセージに変換され、ステップ９２０において、ＮＲＶ書き込みメッセージは、ネットワーク１４０を介して起源サーバ１８０に送信され、サーバ上のファイルシステムによって実行される。そして、手順はステップ９２２において終了する。

図１０は、本発明の一実施形態による非データ変更アクセス要求を処理する手順１０００のステップを示すフロー図である。本明細書において、非データ変更アクセス要求とは、キャッシング・ファイラ１２０のキャッシュ・ボリューム１５０を変更しない任意のオペレーションを必要とするアクセス要求である。非変更オペレーションの一例は、読み出しオペレーションである。手順１０００はステップ１００２から開始され、ステップ１００４へ進み、そこで、クライアント読み出し要求は、キャッシング・ファイラ１２０によって受信される。ステップ１００６において、マルチプロトコルエンジンの適当なプロトコル層が、その読み出し要求をファイルシステム２８０へ転送するための汎用ファイルシステム読み出しメッセージに変換する。ステップ１００８において、ファイルシステム２８０は、そのメッセージをファイルシステムの従来の読み出しハンドラに渡し、プリミティブ読み出しオペレーション要求として処理する。

ステップ１０１０では、要求されたデータがキャッシング・ファイラのローカル・キャッシュ上にあるか否かの判定がなされる。例えば、ファイルシステムは、Ｌｏａｄ＿Ｂｌｏｃｋ（）２８４関数を使用して１以上のブロックをロードし、各ブロックのブロックポインタを検査し、そのブロックがＡＢＳＥＮＴ（不在）としてマークされているか否かを判定することにより、その判定を行う場合がある。ブロックが不在でなければ、すなわち、要求されたデータがローカル・キャッシュ上にあれば、ステップ１０１２において、ファイルシステム２８０は、読み出しメッセージ／要求（上に記載したようなもの）に応じ、手順はステップ１０３２において終了する。

一方、ブロックが不在であれば、すなわち、要求されたデータがローカル・キャッシュ上になければ、ステップ１０１４において、ファイルシステムは、その読み出しメッセージをフェッチ要求に変換し、それをポンプモジュール２９８に送信する。ポンモジュールのポンプ・ワーカー・スレッドは、その要求を受信し、他の要求の中におけるその要求の優先順位を決める。ステップ１０１６において、ポンプスレッドは、応答を受信するまで、フェッチ要求を格納するためのプレースホルダーを維持し続ける。ステップ１０１８において、ポンプスレッドは、ＮＲＶモジュール２９５と協働し、フェッチ要求をＮＲＶ読み出しメッセージに変換し、ステップ１０２０において、そのＮＲＶ読み出し要求をネットワーク１４０を介して起源サーバ１８０へ送信し、起源サーバにより実行させる。

ステップ１０２２において、起源サーバは、フェッチされたデータをキャッシング・ファイラ（ポンプスレッド）に返し、ステップ１０２４において、ポンプスレッドは、ファイルシステムのフィルハンドラと協働し、例えば、フェッチされたデータを使用してフィル・オペレーションを実施することにより、ポンプモジュールにおいてプレースホルダ上に維持されている未処理の読み出し／フェッチ要求に応じる。ステップ１０２６において、ファイルシステムは要求されたデータを含む応答を生成し、ステップ１０２８において、その応答をクライアントに返す。次に、ステップ１０３０において、ファイルシステムにおいて書き込みアロケーションを実施し、フェッチされたデータをキャッシング・ファイラの１以上のローカル記憶装置に格納する。そして、手順はステップ１０３２において終了する。

Ｆ．キャッシュ・コヒーレンシ
本発明の一般的ネットワーク・キャッシュ・システムでは、複数のクライアント１１０が、複数のキャッシング・ファイラ１２０のそれぞれに接続される場合があり、クライアントとファイラの両方が、起源サーバ１８０に接続される場合がある。したがって、この一般的システム実施形態では、起源ボリューム１８５は、クライアント、および／またはキャッシング・ファイラ１２０によって変更される場合がある。そのため、起源サーバ１８０からクライアントによって直接アクセスされるか、またはキャッシング・ファイラ１２０を介してクライアントによってアクセスされるデータが、常に一貫性のあるものにするために、キャッシュ・コヒーレンシ・ポリシーが必要となる。本発明によれば、ネットワーク・キャッシュ・システム１００において使用されるキャッシュ・コヒーレンシ・ポリシーは、キャッシング・ファイラ１２０が、起源サーバ１８０に問い合わせ、データがクライアント１１０へ送られる前にそのデータに変更が発生したか否かを判定するように構成されることを指定する。

例えばファイルのような特定のストレージ・オブジェクトに対する例えば読み出し要求のようなクライアントデータアクセス要求に応答して、キャッシング・ファイラ１２０のファイルシステム２８０は、例えば、変更時刻、リンクの数、作成時刻といったそのファイルの属性の最新のコピーを要求するフェッチ・オン・デマンド（ＦＯＤ）要求を起源サーバ１８０に送信する。これらの属性のいずれかにおける変化は、そのファイルがファイラに最後にキャッシュされた後、そのファイルが変更されたことを示す。したがって、その変化に応じて、キャッシング・ファイラは、自分のローカル・キャッシュに格納された現在のファイルを破棄する。そして、キャッシング・ファイラは、ＮＲＶ読み出しメッセージを使用して適当なフェッチ・オペレーションを生成し、要求されたデータを起源サーバから読み出す。

図１１は、本発明の一実施形態によるキャッシュ・コヒーレンシ・ポリシーを実施するための手順１１００のステップを示すフロー図である。手順１１００は、ステップ１１０２から開始され、ステップ１１０４へ進み、そこで、クライアント・データアクセス要求（例えば読み出し要求）が、キャッシング・ファイラーにおいて受信される。ステップ１１０６において、その要求はファイルシステム読み出しメッセージに変換され、ファイルシステム２８０に転送され、ステップ１１０８において、そのメッセージは、ファイルシステムの従来の読み出しハンドラに渡され、プリミティブ・読み出しオペレーション要求として処理される。ステップ１１１０において、読み出しハンドラは、読み出し要求／メッセージに含まれるファイルのｉｎｏｄｅを例えばＬｏａｄ＿Ｉｎｏｄｅ（）２８８関数を使用して読み出す。

ステップ１１１２において、ファイルシステムは更に、その読み出しメッセージをＦＯＤ要求としてポンプモジュールに渡し、そのｉｎｏｄｅの属性を起源サーバから読み出す。ステップ１１１４において、ポンプスレッドは、そのＦＯＤ要求を格納するためのプレースホルダを、応答が受信まで維持し続ける。ステップ１１１６において、ポンプスレッドは、ＮＲＶモジュールと協働し、そのＦＯＤ要求をＮＲＶ読み出しメッセージに変換し、ステップ１１１８において、そのＮＲＶ読み出しメッセージを、ネットワーク１４０を介して起源サーバ１８０に送信し、起源サーバによって実行させる。ステップ１１２０において、起源サーバは、それらの属性をキャッシング・ファイラ（ポンプスレッド）に応答し、ステップ１１２２において、ポンプスレッドは、ファイルシステムのフィル・ハンドラと協働し、例えばその応答を使用してフィル・オペレーションを実施することにより、ポンプモジュールにおいてプレースホルダ上に維持されている未処理の読み出し／ＦＯＤ要求に応じる。

なお、データを有しないフィル・オペレーション（すなわち、長さゼロの読み出し、または「確認」）は、それらの属性しか有しない。したがって、ステップ１１２４において、フィル・ハンドラは、要求されたファイルに関する属性（起源サーバから受信されるようなもの）が、キャッシング・ファイラに現在格納されているファイルの属性と異なるか否かを判定する。後者の場合、キャッシング・ファイラに格納されているファイルの属性の状態が、例えば、そのファイルのｉｎｏｄｅ３００に格納されているアクセススタンプ、および／または変更時刻スタンプ３１６を検査することによって判定される。なお、ＮＲＶ読み出しメッセージは、ＮＲＶ応答において返されるデータがいずれも、そのファイルの最新の属性も含むという性質を持つ。したがって、長さゼロの読み出し（確認）は、データを何もフェッチせずに、ファイルの最新の属性を読み出すことに等しい。

属性に何も違いがなければ（属性に変化がなければ）、それに応じて、フィル・ハンドラは、そのｉｎｏｄｅ（ファイル）属性の確認が済んでいるか否かを確認する（ステップ１１２６）。したがって、キャッシング・ファイラ１２０と起源サーバ１８０との間のＮＲＶ交換は、実質的に、余分なレイテンシをシステムにもたらしていた「オペレーションを持たない」（少なくとも最も単純なキャッシュ・コヒーレンシ・ポリシーでは）。ステップ１１２８において、ファイルシステムは、ローカル・キャッシュをサーチし、クライアントの要求するデータがキャッシング・ファイラ上にあるか否かを判定する。キャッシング・ファイラ上にあれば、ファイルシステムは、ステップ１１３０において、その（前述のような）読み出し要求／メッセージに応じ、手順はステップ１１３６において終了する。

一方、要求されたデータ（または、その一部）がローカル・キャッシュ上に無ければ（すなわち、データが欠落していれば）、ステップ１１３２において、ファイルシステムは、その読み出しメッセージをフェッチ要求に変換し、欠落したデータを取得するために、そのフェッチ要求を最終的に起源サーバへと送る。なお、起源サーバからの応答は、欠落したデータと、そのファイルの最新の属性とを含む。また、（ステップ１１２４において判定されるような）属性に違いがあれば、手順は、ステップ１１３２を続ける。ステップ１１３４では、それらの属性が変化したか否か（すなわち、属性がキャッシング・ファイラ上で最初に確認された時点と、欠落したデータが取得された時点との間において、属性に変更があったか否か）に関する判定がなされる。属性に変化があった場合、手順はステップ１１３２へ戻る。そうでなければ、手順はステップ１１３０へ続く。

なお、クライアントによって要求されたデータは、そのデータがキャッシング・ファイラ１２０上に存在するか否かを判定する前に、確認される。その理由は、もし、要求されたデータがキャッシング・ファイラ上に存在していれば、仮にそのデータを確認した時点から、そのデータがクライアントに提供される時点までの間において、起源サーバ１８０においてそのデータの更新が行われたとしても、何も問題ないからである。後者の場合、そうしたオペレーションは「重複オペレーション」とみなされ、読み出し要求が先に発生したものとみなすことにより、それらのオペレーションは直列化される。なお、複数のキャッシング・ファイラ、および／または起源サーバにアクセスする複数のクライアントを有するネットワーク・キャッシュ・システム・デプロイメントを考慮すれば、属性は変更されることもあり得る。

例示的実施形態として、ネットワーク・キャッシュ・システム・デプロイメントには、明示的なロッキング手段が存在しない。ただし、書き込みオペレーションが読み出しオペレーションにオーバラップした場合、ネットワーク・キャッシュ・システムは、書き込みよりも先に読み出しに応答してよいというセマンティックにしたがって動作する（すなわち、確認の前に書き込みが行われることはない）。言い換えれば、確認応答は、ファイルの属性に変化がなく、ファイルデータをキャッシング・ファイラのキャッシュ・ボリューム１５０から提供してよいことを示す（可能であれば）。その後、キャッシュ・ボリュームからデータを提供するとき、キャッシング・ファイラ１２０は、読み出しオペレーションが書き込みオペレーションよりも先に発生したものであるかのように動作する。

当然ながら、キャッシュ・ヒットの場合も、ネットワーク・キャッシュ・システム１００は、このセマンティックを順守する。部分的なキャッシュ・ミスの場合、ネットワーク・キャッシュ・システムは、実質的にスクラッチから開始して、そのセマンティックを順守する。後者に関し、クライアントが３２ｋＢの読み出し要求を発行し、キャッシング・ファイラが、その要求のうちの４ｋＢブロックだけを欠落している（欠落データがキャッシュ・ボリューム上にない）ものと仮定する。この状況に対する普通の応答は、キャッシング・ファイラが、欠落データを埋めるために、４ｋＢのＮＲＶ読み出しメッセージを、暗示的な確認とともに送信することである（なぜなら、あらゆる読み出しが、ファイル属性を返すからである）。前回の明示的な確認が、データに対する変更が何もないことを示すものであり、その明示的な確認と、４ｋＢのＮＲＶ読み出しメッセージの送信との間に、書き込みオペレーションが発生するものとさらに仮定する。キャッシング・ファイラは、読み出し応答に含まれる属性が変化していることから（その応答に付随する暗示的な確認によって分かる）、それらの間に介在する書き込みオペレーションを検出する。次に、それによって、キャッシング・ファイラ１２０は、そのファイルのコピーを自分のキャッシュ・ボリューム１５０上に排出し、ＮＲＶ読み出しメッセージを使用して適当なフェッチ・オペレーションを生成し、要求されたデータを起源サーバ１８０から取得する。この状況は、書き込みオペレーションが過剰に発生し、無駄な読み出しオペレーションが発生する状況を表わしている。

本発明の一態様によれば、ポンプモジュール２９８を使用することにより、そのような欠乏が軽減される。ポンプモジュールはフローコントロールを実施し、新規なネットワーク・キャッシュ・システムは、通常のファイルシステム読み出しハンドラによってクライアント要求に応じる代わりに、クライアント要求を起源サーバ１８０へ渡す働きをする別の形のフローコントロールを提供する。すなわち、クライアント要求に応じるためにファイルをローカル・キャッシュにロードすることが困難である場合、キャッシング・ファイラ１２０は、そのファイルに対する読み出しオペレーションを、ファイルシステム２８０を通して読み出しハンドラへ渡す代わりに、ＲＵＥ２９２へ渡し、起源サーバ１８０に格納する。そして、起源サーバが、標準的なフローコントロール、およびアトミック性メカニズムを使用して、その読み出しオペレーションに対する単一の応答を返す。

Ｇ．優先順位の決定
本発明の一態様によれば、キャッシング・ファイラによって先読みオペレーションが実施される。そのため、キャッシング・ファイラは、クライアント要求と、推測的先読み要求との間に違いがある場合、優先順位付けを実施する。ネットワーク・キャッシュ・システム実施形態に対するこの機能の利点は、起源サーバは、すべてのクライアント要求を「見る」ことはできないため、キャッシング・ファイラが通常、先読み判定を行うときに得られるほどの情報が得られないことである。キャッシング・ファイラ上ではマルチプロトコルエンジンが実行されているため、キャッシング・ファイラは、ファイラとサーバとの間にキャッシュ・ボリュームが存在したとしても、起源サーバによって通常なされるものと同じ先読み判定を行うことができる。特に、キャッシング・ファイラは、起源サーバで使用されるものと同じ先読みエンジンを使用するため、起源サーバと同じ先読み要求を生成する。要求の優先順位付けに関し、ネットワーク・キャッシュ・システム実施形態は、要求を２つの異なる優先順位バンドとして扱い、クライアント要求は、推測的先読みよりも優先的に優先順位付けされ、システムが飽和すると、推測的先読み要求は破棄される。

Ｈ．キャッシュ破棄
上記のように、ローカル・キャッシュ（例えば、キャッシュ・ボリューム１５０）が一杯になると、トランケータ２９４は、キャッシュ破棄ポリシーをエンコードし、記憶空間の返還を要求する。キャッシング・ファイラ１２０のキャッシュ・ボリューム１５０が、起源サーバ１８０の起源ボリューム１８５上に記憶されているワーキングセットよりも小さい状況では、キャッシュ破棄判定が頻繁に行われる。キャッシング・ファイラは、それらの要求をキャッシュ（記憶）するために、ボリューム記憶空間を開放しなければならない。例示的実施形態において、トランケータ２９４は、空きの空間が必要になったときに、（１）キャッシュ・ボリューム１５０を「くまなく調べ」、キャッシュ・ボリューム１５０に格納されたファイルのバッファツリーをスキャンし、（２）以前記憶されたデータのうちのどのデータを破棄すべきかに関する判断を行うように構成されたスキャナとして実施される場合がある。

例えば、キャッシュ破棄ポリシーは、ｉｎｏｄｅファイル全体を調べるラウンドロビン・プロセスであってもよい。ラウンドロビン・プロセスは、大域的なＬＲＵ（Least Recently Used）リストを維持する必要がない点で有利である。その目的のために、トランケータ２９４は、ｉｎｏｄｅファイルをラウンドロビン方式でスキャンし、例えば、ｉｎｏｄｅファイルの先頭から開始して、最後まで進み、さらに、そのファイルの先頭から再開して、遭遇したファイルを適宜自由に強制破棄する場合がある（必要な空き空間が出来るまで）。したがって、このポリシーによれば、空間が必要になったときにファイルがランダムに強制破棄されるが、このポリシーは、ｉｎｏｄｅファイル全体の検査が済むまで、同じファイルが２度強制破棄されることはないという性質を持つ。キャッシュ・ボリュームが使用中である場合、任意の所与の時刻において、大量のワーキングセットが、キャッシュされる可能性が高い。ただし、「よく使用される」ファイルが間違って強制破棄される場合、このポリシーは、トランケータがｉｎｏｄｅファイル全体を検査し終えるまで、そのファイルを強制破棄しないことが望ましい。

図１２は、本発明の一実施形態によるキャッシュ破棄ポリシーを実施するための手順１２００のステップを示すフロー図である。手順はステップ１２０２から開始され、ステップ１２０４へ進み、そこで、トランケータが、ｉｎｏｄｅファイルの第１のｉｎｏｄｅに対して初期化される。ステップ１２０６では、例えば、キャッシュ・ボリュームが一杯になったことに応答して、トランケータが、起動される（呼び出される）。ステップ１２０８で、トランケータは、第１のｉｎｏｄｅを「強制破棄」し、ステップ１２１０で、ボリューム上に十分な空き記憶空間が得られるまで、後続のｉｎｏｄｅ（ファイル）を強制破棄し続ける。実際には、トランケータが起動され、ｉｎｏｄｅファイルが走査されるのは、キャッシュ・ボリューム上の記憶空間を返還要求しなければならないときだけである。ｉｎｏｄｅ、またはファイル（すなわち、より具体的には、ファイルのｉｎｏｄｅバッファツリー）の強制破棄は、例えば、そのバッファツリーを「ゾンビ」システムに渡すことによって行われる。ゾンビシステムは、既存のブロックを消去した後、そのｉｎｏｄｅを、ｉｎｏｄｅのトップレベルに「穴」を有するｉｎｏｄｅに置き換える。この文脈において、穴とは、キャッシュ・ボリューム上のｉｎｏｄｅの未割り当てセクションとして規定される（割り当て済みの不在ブロックとは違う）。そして、手順はステップ１２１２において終了する。

キャッシュ破棄ポリシーの最適化は、ｉｎｏｄｅのブロック全体を強制破棄（消去）し、例えば、ｉｎｏｄｅファイルブロック中の全てのｉｎｏｄｅを消去し、そのｉｎｏｄｅファイルブロックを空にし、ｉｎｏｄｅファイル内のその位置に穴を挿入する（新たな空きｉｎｏｄｅファイルブロックを割り当てる）ことである。キャッシュ・ボリューム上の穴（すなわち、ｉｎｏｄｅファイルの未割り当てセクション）は、実際にｉｎｏｄｅが割り当てられることになる起源サーバ上のｉｎｏｄｅファイルブロックによって決まる。この後者の場合、キャッシング・ファイラは、クライアントが特定ファイルへのアクセスを要求したときに、ｉｎｏｄｅファイルブロックの割り当てだけを行い、そのｉｎｏｄｅファイルブロックを割り当てるときに、ファイルの中身を取得するためのフェッチを開始する。このキャッシュ固有フォーマットによれば、ｉｎｏｄｅファイル中の穴に新たな未割り当てのｉｎｏｄｅを入れるための、ファイルシステム・デフォルト・ポリシーを使用することが可能になる。

例示的実施形態では、トランケータ２９４を起動するトリガは２つある。一方のトリガは、フィル時に発生する（ここで、「フィル」とは、キャッシング・ファイラが起源サーバから応答を受信したときに行われるアクションを意味する）。フィル時には、キャッシング・ファイラは、返還データをいずれも、自分が有するファイルのバッファツリーの中に挿入することが望ましい。しかしながら、そのデータを収容するだけの十分な物理的ディスク空間がない場合、ファイルシステム上の空き空間を考慮して、トランケータが起動される。例えば、集合体中の空きブロックの数を検査し、高−低水位線（例えば、８５〜９５％）に基づいて、トランケータを起動すべきか否かの判定がなされる。

トランケータを起動するもう一方のトリガは、ＣＰ（File System Consistency Point）時間である。キャッシュ・ボリュームはフレキシブルｖｖｏｌであるため、従来のボリュームと一緒に、同じ集合体上に共存させることもできる。従来の（すなわち、仮想）ボリュームが膨張し、ディスク空間の消費が増してくると、ディスク空間の消費を抑えるために、そのボリュームに対してトランケータが起動される。ディスク空間の量（集合体中の空き物理空間）は、ＣＰ時間においてテストされる（例えば、毎１０秒ごとに、ただし、ＣＰは頻繁に発生する）。その際、書き込みアロケータ２８２は、トランケータ２９４に信号を送ってトランケータ２９４を再始動させ、空き空間が所定の低水位未満になるまで、集合体記憶空間を開放させる。

Ｉ．むすび
有利なことに、本発明によれば、マルチプロトコル・キャッシング・ファイラの記憶空間を仮想化し、ネットワーク・キャッシュ・システムにより提供されるデータに対する高速かつ効率的なクライアントアクセスが可能になる。ファイルハンドルからオブジェクト記憶への明示的な変換が必要な従来のキャッシュシステムと違い、新規なマルチプロトコル・キャッシング・ファイラによれば、ファイルシステムの使用によって、特に、ファイルシステムによって編成されるストレージ・オブジェクト（ファイル）の実際の名前の使用によって、ネットワーク・キャッシュ・システムにより提供されるデータに対する効率的なクライアントアクセスが可能になる。また、ファイルシステムは、キャッシング・ファイラの散在ボリュームと協働し、提供されたデータをマルチプロトコル・クライアントに対して透過的な態様でストレージ空間仮想化することができる。

起源サーバに接続され、コンピュータネットワークを介してマルチプロトコル・クライアントによって発行されたデータアクセス要求に応答して、ファイラにより提供されるデータのストレージ仮想化を提供するマルチプロトコル・キャッシング・ファイラを備えたネットワーク・キャッシュ・システムの実施形態について図示説明したが、本発明の思想、および範囲の中で、種々の変更、および改変を施すことも可能であるものと考えられる。例えば、本発明の代替実施形態では、キャッシュ・ボリュームにあらかじめ入れておくために、要求発生器２９６を使用して、ローカルディスク上に格納されていないデータブロックをシステム的に取得する場合がある。なお、キャッシュ・デプロイメントが、起源ボリューム１８５よりもはるかに小さいキャッシュ・ボリューム１５０を有すること（例えば、純粋な複製を上回る利点を得るために）は一般的である。したがって、そのような小さなキャッシュ・ボリュームに事前にデータを入れておくためには、ローカル・キャッシュ上に存在しなければならないデータに関するインテリジェントな判定を実施するように構成された特殊な要求発生器が必要である。なぜなら、元のデータをすべてキャッシュに収容することはできないからである。

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

本発明の一実施形態による例示的ネットワーク環境を示す略ブロック図である。 本発明の一実施形態による例示的ストレージ・オペレーティング・システムを示す略ブロック図である。 本発明の一実施形態による例示的ｉｎｏｄｅを示す略ブロック図である。 本発明の一実施形態にょる例示的バッファツリーを示す略ブロック図である。 本発明とともに有利に使用されるファイルのバッファツリーの一実施形態を示す略ブロック図である。 本発明の一実施形態による例示的集合を示す略ブロック図である。 本発明の一実施形態による例示的オンディスクレイアウトを示す略ブロック図である。 本発明の一実施形態による例示的ｆｓｉｎｆｏブロックを示す略ブロック図である。 本発明の一実施形態によるデータ変更アクセス要求を処理するための手順のステップを示すフロー図である。 本発明の一実施形態による非データ変更アクセス要求を処理するための手順のステップを示すフロー図である。 本発明の一実施形態によるキャッシュコヒーレンシポリシーを実施するための手順のステップを示すフロー図である。 本発明の一実施形態によるキャッシュ破棄ポリシーを実施するための手順のステップを示すフロー図である。

Claims (9)

1. バックエンドストレージシステムとしての起源サーバであって、自身が有する起源ボリュームにおける情報の編成に関連するストレージサービスを提供する起源サーバと、
   前記起源サーバに接続されたキャッシング・ファイラであって、前記起源ボリュームに記憶されたデータをキャッシュするキャッシング・ファイラと
   を含み、前記キャッシング・ファイラは、
   マルチプロトコル・クライアントにより発行され、前記キャッシング・ファイラにより受信されたマルチプロトコルのファイルベースのデータアクセス要求を、前記キャッシング・ファイラ、及び前記起源サーバにより実行可能な汎用ファイルシステムプリミティブオペレーションに変換し、それによって、第１のファイルベースのプロトコルを利用して前記起源ボリュームに記憶された前記情報を、クライアントが第２のファイルベースのプロトコルを使用してアクセス出来るようにするマルチプロトコル・エンジンと、
   前記マルチプロトコル・クライアントによって発行されたマルチプロトコル・データアクセス要求に応答し、前記キャシング・ファイラの物理的ストレージリソースを論理的に表現することによってデータの記憶空間を仮想化し、それによって前記キャッシング・ファイラにより提供されるデータのストレージ仮想化を提供する散在ボリュームと、
   前記散在ボリュームを管理するように構成されたファイルシステムと
   を含み、前記散在ボリュームは、前記散在ボリューム中のファイルから少なくとも１つのデータブロックが抜けており、前記少なくとも１つの抜けているブロックは、前記起源サーバによって前記起源ボリュームに記憶される、ネットワーク・キャッシュ・システム。
2. 前記キャッシング・ファイラのローカルキャッシュを更に含み、該ローカルキャッシュは、１以上のクライアントによって要求されたデータを、前記散在ボリュームから抜けている前記所与のファイルの前記少なくとも１つのデータブロックに相当する少なくとも１つの不在ブロックを有する１以上のストレージ・オブジェクトから提供するように構成された前記散在ボリュームを含み、前記不在ブロックの抜けているデータは、リモート・フェッチ・オペレーションを使用して、前記クライアントから見えない形で読み出される、請求項１に記載のネットワーク・キャッシュ・システム。
3. 前記ストレージ・オブジェクトは、ファイル、及び論理ユニット番号のうちのいずれか一方である、請求項２に記載のネットワーク・キャッシュ・システム。
4. 前記散在ボリュームは、前記キャッシング・ファイラに接続された１以上の記憶装置を含むキャッシュ・ボリュームである、請求項２に記載のネットワーク・キャッシュ・システム。
5. 前記キャッシング・ファイラのリモート・アップデート・エンジン（ＲＵＥ）を更に含み、該ＲＵＥは、前記キャッシュ・ボリュームを変更するファイルシステム・オペレーションを全て前記起源サーバへ転送するように構成される、請求項４に記載のネットワーク・キャッシュ・システム。
6. 前記キャッシング・ファイラのトランケータを更に含み、該トランケータは、前記キャッシュ・ボリュームが満杯になると、キャッシュ破棄ポリシーを実施して、記憶空間を返還要求するように構成される、請求項５に記載のネットワーク・キャッシュ・システム。
7. キャッシング・ファイラ、及び前記キャッシング・ファイラに接続された１以上の記憶装置にわたって記憶された散在ボリュームのキャッシュ・ボリュームを含むネットワーク・キャッシュ・システムを動作させる方法であって、前記散在ボリュームの少なくとも１つのブロックが起源サーバに記憶され、該起源サーバが、バックエンドストレージシステムとして、自身が有する記憶ボリュームにおける情報の編成に関連するストレージサービスを提供するものにおいて、
   前記キャッシング・ファイラにより、当該システムの前記キャッシング・ファイラにあるストレージ・オブジェクトに対するファイルベースのデータアクセス要求を受信するステップと、
   前記キャッシング・ファイラのマルチプロトコル・エンジンにより、前記ファイルベースのデータアクセス要求を、前記キャッシング・ファイラ、及び前記起源サーバにより実行可能な汎用ファイルシステムプリミティブオペレーションに変換し、それによって、第１のファイルベースのプロトコルを利用して前記起源ボリュームに記憶された情報を、クライアントが第２のファイルベースのプロトコルを使用してアクセス出来るようにするステップと、
   前記データアクセス要求が、前記キャッシング・ファイラの前記キャッシュ・ボリュームに記憶されたデータを変更するものであるか否かを、前記キャッシング・ファイラにより判定するステップと、
   変更するものであった場合、変換されたデータアクセス要求を、前記キャッシング・ファイラにより前記キャッシング・ファイラから当該システムの前記起源サーバへ運ぶステップと、
   前記変換されたデータアクセス要求を前記起源サーバによって処理するステップと
   からなる方法。
8. 前記データアクセス要求が、前記キャッシュ・ボリュームに記憶されたデータを変更しないものである場合、前記キャッシング・ファイラにより、前記要求を前記キャッシング・ファイラのファイルシステムに渡すステップと、
   前記要求により要求されたデータが、前記キャッシュ・ボリューム上に有るか否かを、前記キャッシング・ファイラにより判定するステップと、
   前記キャッシュ・ボリューム上に無ければ、前記要求されたデータを前記起源サーバから取得するための１以上のフェッチ・オペレーションを、前記キャッシング・ファイラにより生成するステップと、
   前記キャッシング・ファイラにより、前記起源サーバから応答を受信したときに、取得した前記データを前記キャッシュ・ボリュームに記憶するステップと
   を更に含む、請求項７に記載の方法。
9. 要求されたデータが前記キャッシュ・ボリューム上に無い場合、前記キャッシング・ファイラにより、前記キャッシング・ファイラにおいて前記要求に対するサービスを提供するステップを更に含む、請求項８に記載の方法。

Images