(57)【要約】ストレージシステムの内容参照ストレージアレイ要素（ＣＡＳＡＥ）は、ストレージリソース上に重複データが格納されることを防止するように構成される。ＣＡＳＡＥは単独で、書き込み処理に関連するデータが、ストレージリソース上のいずれかの位置に既に書き込まれているか否かを判定する。その目的のために、ＣＡＳＡＥは、同じデータを有する２以上のブロックの格納を防止するために、それらのリソースに書き込まれる各データブロックに対して内容参照ストレージ計算を実施する。データブロックがリソースに既に書き込まれていた場合、ＣＡＳＡＥは、格納されているデータを複製するかわりに、システム上で実行されているファイルシステムと協働し、そのデータブロックへの参照（ブロックポインタ）を生成する。あるいは、ＣＡＳＡＥは、リソース上の新たな位置にそのデータブロックを格納し、その位置へのブロックポインタを生成する。
2009524882.tif 000002
【特許請求の範囲】
【請求項１】
ストレージシステムのストレージリソースを管理する方法であって、
内容参照ストレージ計算を実施し、前記リソースに書き込まれた第１のデータブロックの中身から、キーを計算するステップと、
計算されたキーを、マッピングテーブル内のエントリーのキーと比較し、一致するものがあるか否かを判定するステップと、
一致するものがあった場合、前記第１のデータブロックの中身を、前記リソースに以前に格納された第２のデータブロックの中身と比較するステップと、
前記データブロックの中身の比較の結果、一致するものがあった場合、以前に格納されたデータブロックに対する参照カウントをインクリメントし、それによって、ストレージリソース上に重複データブロックの中身の格納を防止するステップと
からなる方法。
【請求項２】
前記以前に格納されたデータブロックのブロック番号位置を前記ストレージシステムに提供するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記キーのうちの１つが一致せず、かつ、データブロックの中身が一致しない場合に、
前記第１のデータブロックを前記ストレージリソース上の次の空きブロック位置に書き込むステップと、
前記次の空き位置のブロック番号を前記ストレージシステムに提供するステップとをさらに含む、請求項１に記載の方法。
【請求項４】
前記内容参照ストレージ計算を実施するステップは、ハッシュ関数を使用して前記キーを計算するステップを含む、請求項１に記載の方法。
【請求項５】
ストレージシステムのストレージリソースを管理するように構成されたシステムであって、
(i)前記リソースに書き込まれた第１のデータブロックの中身に基づいてキーを計算し、(ii)前記リソースに以前に格納された第２のデータブロックに対して前記キーが生成されているか否かを判定し、(iii)生成されている場合、前記データブロックの中身を比較し、(iv)一致するものがあれば、前記以前に格納されたデータブロックに対する参照カウントをインクリメントするように構成された内容参照ストレージアレイ要素を含む、システム。
【請求項６】
前記内容参照ストレージアレイ要素は、前記以前に格納されたデータブロックのブロック番号位置を、前記要素に接続されたストレージシステムに返すようにさらに構成される、請求項５に記載のシステム。
【請求項７】
前記ブロック番号位置は、前記ストレージリソースに格納された論理ユニットの物理ブロック番号である、請求項６に記載のシステム。
【請求項８】
前記リソース上に以前に格納された第２のデータブロックに対し、前記キーの１つがまだ生成されたことがなく、且つ、前記データブロックの中身の間に一致するものがなかった場合、前記内容参照ストレージアレイ要素は、前記第１のデータブロックを前記ストレージリソース上の次の空きブロック位置に書き込み、前記次の空き位置のブロック番号を、前記要素に接続されたストレージシステムに返すようにさらに構成される、請求項５に記載のシステム。
【請求項９】
前記キーは、ハッシュ関数を使用して計算される、請求項５に記載のシステム。
【請求項１０】
前記ハッシュ関数は、ＭＤ５ハッシュアルゴリズムを含む、請求項９に記載のシステム。
【請求項１１】
前記第２のデータブロックに対して前記キーが生成されているか否かを判定するために、前記内容参照ストレージアレイ要素によって使用されるマッピングデータ構造をさらに含む、請求項５に記載のシステム。
【請求項１２】
前記マッピングデータ構造は、複数のエントリを有するテーブルであり、各エントリは、ハッシュキー、前記ストレージリソースに以前に格納されたデータブロックを参照するように構成されたポインタ、及び参照カウントを含む、請求項１１に記載のシステム。
【請求項１３】
前記内容参照ストレージアレイ要素は、前記ストレージリソース上に重複データブロックの中身が記憶されることを防止するようにさらに構成される、請求項５に記載のシステム。
【請求項１４】
ストレージシステムのストレージリソースを管理するように構成された装置であって、
内容参照ストレージ計算を実施し、前期リソースに書き込まれた第１のデータブロックの中身からキーを計算する手段と、
計算されたキーをマッピングテーブル中のエントリのキーと比較し、一致するものがあるか否かを判定する手段と、
一致するものがあった場合、前記第１のデータブロックの中身を前記リソースに以前に格納された第２のデータブロックの中身と比較する手段と、
前記データブロックの中身の比較の結果、一致するものがあった場合、前記以前に格納されたデータブロックに対する参照カウントをインクリメントし、それによって、前記ストレージリソース上に重複データブロックの中身が格納されることを防止する手段と
からなる装置。
【請求項１５】
前記以前に格納されたデータブロックのブロック番号位置を前記ストレージシステムに提供する手段をさらに含む、請求項１４に記載の装置。
【請求項１６】
前記キーのうちの１つが一致せず、且つ、前記データブロックの中身が一致しない場合に、
前記第１のデータブロックを前記ストレージリソース上の次の空きブロック位置に書き込む手段と、
前記次の空き位置のブロック番号を前記ストレージシステムに提供する手段と
をさらに含む、請求項１４に記載の装置。
【請求項１７】
前記内容参照ストレージ計算を実施する手段は、ハッシュキーを使用して前記きーを計算する手段を含む、請求項１４に記載の装置。
【請求項１８】
ストレージシステムのストレージリソースを管理する実行可能プログラム命令を含むコンピュータ読取可能媒体であって、前記実行可能プログラム命令が、
内容参照ストレージ計算を実施し、前記リソースに書き込まれた第１のデータブロックの中身に基づいてキーを計算し、
計算されたキーをマッピングテーブル上のエントリのキーと比較し、一致するものがあるか否かを判定し、
一致するものがあった場合、前記第１のデータブロックの中身を前記リソースに以前に格納された第２のデータブロックの中身と比較し、
前記データブロックの中身の比較の結果、一致するものがあった場合、前記以前に格納されたデータブロックに対する参照カウントをインクリメントし、それによって、前記ストレージリソースに重複データブロックの中身が格納されることを防止するための１以上のプログラム命令からなる、コンピュータ読取可能媒体。
【請求項１９】
前記以前に格納されたデータブロックのブロック番号位置を前記ストレージシステムに提供するための１以上のプログラム命令を更に含む、請求項１８に記載のコンピュータ読取可能媒体。
【請求項２０】
前記キーのうちの１つが一致せず、且つ、前記データブロックの中身が一致しない場合に、
前記ストレージリソース上の次の空きブロック位置に前記第１のデータブロックを書き込み、
前記次の空き位置のブロック番号を前記ストレージシステムに提供するための１以上のプログラム命令を更に含む、請求項１８に記載のコンピュータ読取可能媒体。
【請求項２１】
前記内容参照ストレージ計算を実施するための１以上のプログラム命令は、ハッシュ関数を使用して前記キーを計算するための１以上のプログラム命令を含む、請求項１８に記載のコンピュータ読取可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[発明の分野]
本発明は概して、データストレージ圧縮に関し、より具体的には、ストレージリソースに重複データが格納されることを抑制するように構成されたストレージシステムの内容参照ストレージアレイ要素に関する。
【背景技術】
【０００２】
[発明の背景]
ストレージシステムは通常、１以上のストレージデバイスを備え、要望に応じてその中に情報を格納したり、その中から情報を取り出したりすることができる。ストレージシステムは、とりわけ、システムによって実施されるストレージサービスをサポートする記憶処理を実施することにより、システムを機能的に編成するストレージオペレーティングシステムを備える。ストレージシステムは、種々のストレージアーキテクチャに従って実施され、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、あるいはクライアント又はホストコンピュータに直接取り付けられたディスクアセンブリとして実施される場合がある。ストレージデバイスは一般にディスクドライブであり、それらがディスクアレイとして編成される。ただし、「ディスク」という用語は一般に、内蔵型回転磁気媒体記憶装置を表す。この文脈におけるディスクという用語は、ハードディスクドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージデバイス（ＤＡＳＤ）と同じ意味で使用される。
【０００３】
ディスクアレイへの情報の格納は、好ましくは、ディスク空間の全体的論理構成を決める、物理ディスクの１以上のストレージ「ボリューム」として実施される。ボリューム内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent or Inexpensive Disks）として運用されることがある。大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理ディスクにわたるデータ「ストライプ」に冗長書き込みを行い、そのストライプ化されたデータに対する冗長情報（パリティ）を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。各ＲＡＩＤグループの物理ディスクには、ストライプ化されたデータを記憶するように構成されたディスク（すなわち、データディスク）と、そのデータに関するパリティを記憶するように構成されたディスク（すなわち、パリティディスク）とがある。その後、ディスク故障時に失われたデータの復元を可能にするために、パリティは読み出されることがある。「ＲＡＩＤ」という用語、及びその種々の実施形態は既知のものであり、１９８８年６月、D.A. Patterson、G.A. Gibson、及びR.H. Katz著、国際会議予稿集論文「A Case for Redundant Arrays of Inexpensive Disks (RAID)」に開示されている。
【０００４】
ストレージシステムのストレージオペレーティングシステムは、ディスク上に格納される情報をディレクトリ、ファイル、及びブロックのような名前付きデータコンテナの階層構造として論理編成するための、ファイルシステムのような高レベルモジュールとして実施される場合がある。例えば、「ディスク上」の各ファイルは、ファイルの実際のデータのような情報を格納するように構成された一組のデータ構造、すなわちディスクブロックとして実施される場合がある。これらのデータブロックは、ファイルシステムによって管理されるボリュームブロック番号（ｖｂｎ）空間の中に編成される。ファイルシステムは、それらのデータブロックを「論理ボリューム」としてｖｂｎ空間の中に編成し、必須ではないが、各論理ボリュームは、独自のファイルシステムに関連する。ｎ−１ブロックのサイズのファイルシステムの場合、ファイルシステムは通常、ゼロからｎまでの連続的範囲のｖｂｎから構成される。
【０００５】
ファイルシステムの１つの既知のタイプは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。ディスクからストレージシステムのメモリへデータブロックを取り出し（読み出し）、新たなデータで「汚す」場合、書き込み性能を最適化するために、以後、そのデータブロックはディスク上の新たな場所に書き込まれる。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データが複数のディスクにわたって実質的に連続的に配置されるような最適レイアウトを最初に仮定する。最適レイアウトによって、ディスクに対する効率的なアクセスが可能となり、とりわけ、シーケンシャル読み出しオペレーションの場合に、効率的なアクセスが可能となる。ストレージシステム上で動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッド社から入手可能なＷｒｉｔｅ  Ａｎｙｗｈｅｒｅ  Ｆｉｌｅ  Ｌａｙｏｕｔ（ＷＡＦＬ）である。
【０００６】
ストレージオペレーティングシステムは、入出力（Ｉ／Ｏ）オペレーションにしたがってディスクに対する情報の格納や読み出しを管理するための、ＲＡＩＤシステムのようなストレージモジュールをさらに実施する場合がある。また、ＲＡＩＤシステムは、ストレージシステム中のＲＡＩＤグループに対してパリティオペレーションを実施する役割も有する。ＲＡＩＤシステムは通常、全てのＲＡＩＤグループの全てのディスクにわたってディスクブロックが連結されるように、ＲＡＩＤグループを１つの大きな「物理」ディスク（すなわち、物理ボリューム）に編成する。ファイルシステムによって管理される論理ボリュームは、次に、ＲＡＩＤシステムによって管理される物理ボリューム全体に「配置」（分散）される。
【０００７】
ストレージシステムは、情報配送のクライアント／サーバモデルに従って動作するように構成され、その結果、多数のクライアントが、システムに格納されたディレクトリ、ファイル、及びブロックにアクセスすることが可能になる。このモデルでは、クライアントは、ポイント・ツー・ポイントリンク、共有ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはインターネットのような公共ネットワーク上で実施される仮想私設ネットワークのようなコンピュータネットワークを介してストレージシステムに「接続」するために、データベースアプリケーションのようなアプリケーションをコンピュータ上で実施する場合がある。各クライアントは、ネットワークを介して、ファイルシステムプロトコルメッセージ（パケットの形をしている）をストレージシステムへ発行することにより、ファイルシステムのサービスを要求する。従来のコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルやネットワーク・ファイル・システム（ＮＦＳ）プロトコルのような複数のファイルシステムプロトコルをサポートすることにより、ストレージシステムの利便性は向上する。
【０００８】
クライアント要求に応答して１ブロックのファイルをアクセスするとき、ファイルシステムは、ｖｂｎを指定する。このｖｂｎは、ＲＡＩＤシステムにより、物理ボリュームのＲＡＩＤグループ内の特定ディスク（ディスク、ｐｂｎ）上の物理ブロック番号（ｐｂｎ）位置に変換される。ｖｂｎ空間においてもｐｂｎ空間においても、各ブロックのサイズは通常、例えば４キロバイトに固定されている。従って、ｐｂｎ空間においてディスクに格納される情報と、ｖｂｎ空間においてファイルシステムにより編成される情報との間には、一対一のマッピングが存在する。ＲＡＩＤシステムにより指定される位置（ディスク、ｐｂｎ）はさらに、ストレージオペレーティングシステムのディスクドライバシステムにより、指定されたディスク上の複数のセクタに変換される場合がある。
【０００９】
次に、要求されたブロックはディスクから読み出され、メモリのバッファキャッシュに、そのファイルのバッファツリーの一部として格納される。バッファツリーは、ファイルのブロックの内部表現であり、バッファキャッシュに格納され、ファイルシステムによって管理される。一般に、バッファツリーは、ファイルのルート（最上層）にあるｉｎｏｄｅを有する。ｉｎｏｄｅは、ファイルに関するメタデータのような情報の格納に使用されるデータ構造であり、データブロックは、ファイルの実際のデータの格納に使用されるデータ構造である。ｉｎｏｄｅに格納される情報には、例えば、そのファイルのデータブロックのディスク上の位置への参照がある。ファイルデータの位置への参照は、ブロックポインタとして提供され、さらに、ファイル内のデータ量によっては、ブロックポインタは更に、間接ブロックを参照し、次いで、データブロックを参照することがある。
【００１０】
ＲＡＩＤシステムは、基礎物理ディスクの幾何構成に関する情報（例えば、各ディスク内のブロック数）を、ＲＡＩＤラベルのような、ディスク上に格納されるデータ構造として管理する。ＲＡＩＤシステムは、書き込みアロケーションオペレーションを実施する際にファイルシステムによって使用されるｖｂｎからディスク、ｐｂｎへのマッピングを作成・管理するときや、読み出しオペレーションの際にｖｂｎをディスク位置へ変換するときに使用されるディスク幾何構成情報を、ファイルシステムに提供する。アクティブマップ、スナップマップ、空間マップ、及び要約マップのようなブロックアロケーションデータ構造は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムのようなファイルシステム中でのブロック使用状況を表わすデータ構造である。これらのマッピングデータ構造は、幾何構成とは関係なく、ファイルシステムの書き込みアロケータにより、論理ボリュームの既存のインフラストラクチャとして使用される。
【００１１】
データ記憶は、銀行、政府施設／請負業者、及びセキュリティ委託業者のような文書保管や規則順守に係る環境において運用される多くの産業の中心部である。これらの環境の多くは、特定データ（例えば、電子メール）、金融文書、あるいは取引記録を不変的に、且つ書き換え不能な形で記憶することを必要とし、場合によっては、長期にわたって記憶することを必要とする。一般に、データバックアップオペレーションは、故障発生時にそれらのデータの保護、及び復元を可能にするために実施される。しかしながら、バックアップオペレーションは、しばしば、ディスクのようなバックアップストレージリソース上にデータの複製を生じることがあり、その結果、ストレージリソース上の記憶空間は十分に消費されないことがある。従って、ストレージリソース上の複製データの発生を防止し、データの実体を１つだけ確実に記憶することにより、ストレージ圧縮を達成することが望まれている。
【００１２】
データストレージ圧縮を提供する１つの既知のアプローチとして、内容参照ストレージシステムを使用するものがある。内容参照ストレージシステムは、書き込むべきデータが、バックアップストレージリソース上に既に存在しているか否かを、ハッシュを使用して判定する。内容参照ストレージシステムにおいてハッシュを計算するプロセスは一般にファイルレベルで実施され（論理ユニットレベルやＬＵＮレベルではなく）、データが既に格納されているか否かを判定するために相当な量の計算が必要になるため、比較的遅い。従って、書き込み処理は通常、遅いプロセスとなる。これが、内容参照ストレージシステムの産業上の致命的な欠点である。
【００１３】
もう１つの既知のアプローチは、ＣＭＵ（カーネギー・メロン大学）・パラレル・デベロップメント研究所により開発されたカーネギー・メロン大学ネットワーク・アタッチド・セキュア・ディスク（ＮＡＳＤ）システムである。ＮＡＳＤは、ダイレクト・アタッチド・ディスクを使用する代わりに、「スマート」ディスクをネットワークに取り付ける。ただし、汎用システムで使用する場合、このアプローチは、一次記憶としては不十分な性能や、予測可能な能力を提供するだけの十分な信頼性を持たない公共ネットワークの使用からの影響に悩まされる。
【発明の開示】
【課題を解決するための手段】
【００１４】
[発明の概要]
本発明は、ストレージシステムのストレージリソース上への重複データの格納を防止するように構成されたストレージシステムの内容参照ストレージアレイ要素（ＣＡＳＡＥ）に関する。本発明によれば、ＣＡＳＡＥは単独で、書き込み処理に関連するデータが、ストレージシステムのストレージリソース上のいずれかの位置に既に書き込まれているか否かを判定する。その目的のために、ＣＡＳＡＥは、同じデータを有する２以上のブロックの格納を防止するために、それらのリソースに書き込まれる各データブロックに対し、内容参照ストレージ計算を実施する。あるブロックのデータが、リソース上に既に書き込まれていた場合、ＣＡＳＡＥは、格納されたデータを複製する代わりに、当該システム上で実行されているファイルシステムと協働し、そのデータブロックへの参照（ブロックポインタ）を提供する。あるいは、ＣＡＳＡＥは、そのデータブロックをリソース上の新たな位置に格納し、その位置へのブロックポインタを提供する。
【００１５】
例示的実施形態として、ＣＡＳＡＥは、とりわけ、内容参照ストレージ計算を実施するように構成されたコントローラ、複数のディスクポート、並びに切り替え装置を介してストレージシステムに接続されるように構成された複数のネットワークポートを含む、ブロック志向の要素である。さらに、ディスクポートは、ＣＡＳＡＥのストレージリソース（例えばディスク）に接続され、それによって、「ストレージ・ブリック」を形成する。ＣＡＳＡＥストレージブリックのディスクは、論理ユニット（ＬＵＮ）としてエキスポートされ、ディスクの信頼性を向上させるように構成された単一のＲＡＩＤレベル実施形態グループに編成される。
【００１６】
ＬＵＮにデータを書き込むためのクライアント要求に応答し、ファイルシステムは、特殊なブロック番号（例えば、ゼロ）を使用して、ＣＡＳＡＥに対し、各データブロックに対する内容参照ストレージ計算の実行を命じ、そのデータがＬＵＮ上のいずれかの位置に既に書き込まれているか否かを判定する。このストレージ計算には、例えば、ハッシュ関数が必要とされる。なぜなら、ディスクへのデータの格納に、相当な量のドメイン空間が必要になるからである。具体的には、ＣＡＳＡＥは、データブロックの内容に基づいてハッシュキーを計算し、次に、そのキーが、以前に格納されたデータブロックに対して計算されているか否かを判定する。計算されている場合、同様のキーを有するデータブロックの中身の比較を行い、中身が一致すれば、以前に格納されたデータブロックに対する参照カウントをインクリメントする。そして、その以前に格納されたデータブロックのブロック番号（位置）をファイルシステムに返す。一方、そのハッシュキーが以前に生成されたことがないものであった場合、又はデータの中身が一致しなかった場合、そのデータは、ＬＵＮ上の次の空きブロック位置に書き込まれ、その位置が、ファイルシステムに返される。
【００１７】
本発明の上記の利点、及び他の利点は、添付の図面とともに下記の説明を読むことで、より深く理解できるであろう。図中、類似の参照符号は、同一の要素、又は機能的に類似の構成要素を示している。
【発明を実施するための最良の形態】
【００１８】
[例示的実施形態の詳細な説明]
本発明は、ストレージリソースに重複データが格納されることを防止するように構成された内容参照ストレージシステム（ＣＡＳＳ）のようなストレージシステムの内容参照ストレージアレイ要素（ＣＡＳＡＥ）に関する。本発明によれば、ＣＡＳＡＥは単独で、書き込み処理に関連するデータが、ストレージリソース上のいずれかの位置に既に格納されているか否かを判定する。その目的のために、ＣＡＳＡＥは、同じデータを有する２以上のブロックの格納を防止するために、それらのリソースに格納される各データブロックに対し、内容参照ストレージ計算を実施する。あるブロックのデータが、以前からリソースに既に格納されていた場合、ＣＡＳＡＥは、その既に格納されているデータを複製するかわりに、当該システム上で実行されているファイルシステムと協働し、そのデータブロックへの参照（ブロックポインタ）を提供する。あるいは、ＣＡＳＡＥは、リソース上の新たな位置にそのデータブロックを格納し、その位置へのブロックポインタを提供する。
【００１９】
図１は、本発明とともに有利に使用される内容参照ストレージシステム（ＣＡＳＳ）を示す略ブロック図である。ＣＡＳＳ１００は、切り替え装置１５０を介して１以上のＣＡＳＡＥ４００に接続されたストレージシステム２００を含む。切り替え装置１５０（例えば、イーサネットスイッチ）は、例えば、ストレージシステム２００と各ＣＡＳＡＥ４００との接続に使用され、ＣＡＳＳ１００の低コストな、ホットプラグ可能なネットワークインフラストラクチャを提供する。クライアント１１０は、コンピュータネットワーク１２０を介してストレージシステム２００に接続される。コンピュータネットワーク１２０には、例えば、ポイント・ツー・ポイント接続や、ローカル・エリア・ネットワークのような共有媒体が含まれる。例えば、コンピュータネットワーク１２０は、イーサネット(R)ネットワーク、又はファイバチャネル（ＦＣ）ネットワークとして実施される場合がある。各クライアント１１０は、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のような所定のプロトコルに従ってネットワーク１２０を介して個々のデータフレーム、又はデータパケットをやりとりすることにより、ストレージシステムと通信することができる。
【００２０】
クライアント１１０は、アプリケーションを実行するように構成され、情報配送のクライアント／サーバ・モデルに従ってストレージシステム２００と通信するように構成された汎用コンピュータであってもよい。つまり、ネットワーク１２０を介してパケットをやりとりすることによって、クライアントは、ストレージシステムのサービスを要求することができ、システムは、クライアントから要求されたサービスの結果を返すことができる。ファイルやディレクトリの形をしたデータのような情報をアクセスする場合、クライアントは、コモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルやネットワーク・ファイル・システム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを含むパケットを発行する場合がある。一方、ブロックの形をした情報をアクセスする場合、クライアントは、「ＳＣＳＩ  ｏｖｅｒ  ＴＣＰ（ｉＳＣＳＩ）」プロトコルや「ＳＣＳＩ  ｏｖｅｒ  ＦＣ（ＦＣＰ）」プロトコルのようなブロックベースのアクセスプロトコルを含むパケットを発行する場合がある。
【００２１】
本明細書に記載するように、ストレージシステム２００は、ＣＡＳＳ１００によって提供される例えばディレクトリ、ファイル、及び論理ユニット（ＬＵＮ）のようなデータコンテナを表わす高レベルメタディレクトリを格納するように構成されたローカルストレージアレイ２６０の、例えばディスクのようなストレージリソースに接続される。また、各ＣＡＳＡＥ４００は、ＣＡＳＳ１００によって提供されるそれらのデータコンテナのユーザデータ（データブロック）を格納するように構成されたリモートストレージアレイ４６０のディスクに接続される。なお、ＣＡＳＡＥは、自身に関連するリモートストレージアレイと通信し、ＣＡＳＡＥ「ストレージブリック」１８０を形成する。本明細書に記載するように、ストレージブリックとは、比較的少ない記憶容量しか持たない、あまり賢くない一組のディスクを意味する。各ＣＡＳＡＥストレージブリック１８０のリモートストレージアレイ４６０の記憶容量は、ストレージシステム２００のローカルストレージアレイ２６０の記憶容量と協働し、ＣＡＳＳ１００の拡張記憶空間を提供する。
【００２２】
幾つかのブリックにわたる書き込み処理のストライピングを可能にするために、更に別のＣＡＳＡＥストレージブリック１８０が、ＣＡＳＳ１００に挿入される場合もある。これら複数のストレージブリック１８０は並列に動作し、ブリック間でのリソースのアグレゲーションを可能とし、それによって、書き込み処理に関連する高速で十分な能力の内容参照ストレージ計算が可能となる。従って、１以上のＣＡＳＡＥストレージブリック１８０の編成によれば、ＣＡＳＳ１００はグリッドアーキテクチャを形成することが可能となる。さらに、ＣＡＳＡＥストレージブリック１８０を追加すれば、データへのアクセスを妥協することなく、ストレージのスケーリング（増加）、及び複数のディスクの提供が可能となる。リモートストレージアレイ４６０をＣＡＳＳに追加するたびに、例えば、（比較的小さな）アレイ全体にわたるストレージ計算を実施することが可能なＣＡＳＡＥブリック１８０の別の計算要素が追加される。その結果、複数のブリック間での計算のバランスをとることができるため、劣化なしにスケーラブルシステムを実現することができる。つまり、ＣＡＳＡＥ４００は、例えば、ストレージシステム２００によって提供されるローカルストレージアレイ２６０上に、通常どおりに多数（例えば、１６、３２、又は６４）のディスクを提供する代わりに、比較的少数（例えば、８台）のディスクしか提供しない。ローカルストレージアレイ２６０のディスク上で実施される内容参照ストレージに対し、ストレージシステム２００によってストレージ計算が実施される場合、性能は制限される（すなわち、低下する）ことになるであろう。なぜなら、記憶容量が大きくなるのに従って、データのコピーが存在するか否かを判定するために、より広いドメイン空間を調べなければならなくなるからである。
【００２３】
ＣＡＳＳの信頼性、及び利用可能性を向上させるために、ストレージブリック１８０は、１つのグループに編成され、ＲＡＩＤ（Redundant Array of Independent or Inexpensive Disks）として運用される場合がある。ＲＡＩＤ４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所与の数の物理ディスクにわたってデータを「ストライプ状」に冗長書き込みし、そのストライプ化されたデータに対するパリティ情報を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。ここで、ＲＡＩＤレベル４実施形態は、ＣＡＳＳ１００の複数のストレージブリック１８０にわたって配置され、ブリックの１つはパリティブリックに指定される場合がある。事実上、各ストレージブリック１８０は、ＲＡＩＤグループ内の１つのディスクとして扱われ、パリティブリック上のディスクは、従来のＲＡＩＤ４構成におけるパリティディスクと同様の働きをする。当業者には明らかなように、ストレージブリック上で他のＲＡＩＤ実施形態を配置することもでき、例えば、二重故障を検出し、訂正するように構成された二重パリティＲＡＩＤ６実施形態を配置してもよい。そのようなＲＡＩＤ６実施形態では、例えば、２つのストレージブリック１８０が、パリティブリックとして指定、及び構成される。例えば故障により、１つ、又は２つのストレージブリックが失われた場合でも、ＲＡＩＤ実施形態によれば、故障ディスク（複数の場合もあり）の復元と同様の仕方で、故障したブリック（複数の場合もあり）を復元することが可能となる。故障したストレージブリックのディスクからデータを取り出す（読み出す）ことも可能であるが、書き込みオペレーションの処理を可能にするためには、ブリックを修復しなければならない。
【００２４】
図２は、本発明とともに有利に使用されるストレージシステム２００を示す略ブロック図である。ストレージシステム２００は、ローカルストレージ（ディスク）アレイ２６０のディスク２３０のようなストレージデバイス上での情報の編成に関するストレージサービスを提供するコンピュータである。ストレージシステム２００は、システムバス２２５によって相互接続されたプロセッサ２２２、メモリ２２４、１以上のネットワークアダプタ２２６、１以上のストレージアダプタ２２８、及び不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ２２９）を含む。ＮＶＲＡＭ２２９は、例えば、バックアップバッテリを備えた固体メモリアレイであってもよいし、メモリアレイに対する何らかの電力供給のロスが発生したときに、メモリアレイを最後の状態に維持するための内蔵最終状態保持機能を備えた半導体メモリアレイでってもよい。各ネットワークアダプタ２２６は、コンピュータネットワーク１２０を介してストレージシステム２００をクライアント１１０に接続するための機械的、電気的、及び信号的回路を含む。また、ストレージシステム２００は、ストレージオペレーティングシステム３００をさらに含む。ストレージオペレーティングシステム３００は、ディスク上のディレクトリ、ファイル、及び仮想ディスク（ｖｄｉｓｋ）と呼ばれる特殊なタイプのファイルの階層構造として情報を論理編成するために、ファイルシステムのような高レベルモジュールを実施することが好ましい。
【００２５】
例示的実施形態として、メモリ２２４は、ソフトウェアプログラムコードを格納する際にプロセッサによってアドレス指定可能な多数の記憶位置を備える。メモリの一部は、本発明に関連する特定のデータ構造を格納するために、「バッファキャッシュ（２７０）」としてさらに編成される。さらに、プロセッサ、及びアダプタは、ソフトウェアコードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む場合がある。ストレージオペレーティングシステム３００は、その一部が通常、メモリに常駐し、それらの処理要素によって実行され、とりわけ、ストレージシステムによって実行されるストレージ処理を実施することにより、システム２００を機能的に編成する。当業者には明らかなように、本明細書に記載する本発明の技術に関連するプログラム命令の実行、及び格納には、種々のコンピュータ読取可能媒体を含む、他の処理手段や他の記憶手段が使用される場合もある。
【００２６】
ストレージアダプタ２２８は、システム２００上で実行されているストレージオペレーティングシステム３００と協働し、ユーザ（すなわち、クライアント）から要求された情報をアクセスする。情報は、ビデオテープ、光学媒体、ＤＶＤ、磁気テープ、バブルメモリ、電気的ランダムアクセスメモリ、微小電気機械、及び、データやパリティ情報のような情報を格納するように構成された他の同様の媒体のような、書き込み可能なストレージデバイス媒体のいかなるタイプのアタッチド・アレイに格納してもよい。ただし、本明細書に例示するように、情報は、好ましくは、ローカルストレージアレイ２６０のＨＤＤ、及び／又はＤＡＳＤのようなディスク２３０に格納される。ストレージアダプタは、従来の高性能ＦＣシリアルリンクトポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続されるように構成された入出力（Ｉ／Ｏ）インタフェース回路を含む。
【００２７】
アレイ２６０への情報の格納は、好ましくは、１以上のストレージ「ボリューム」として実施される。ストレージボリュームは、一群の物理ストレージディスク２３０を含み、それらが協働して、ボリューム（複数の場合もあり）上のボリュームブロック番号（ｖｂｎ）の全体的論理構成が規定される。各論理ボリュームは通常、必須ではないが、独自のファイルシステムに関連する。論理ボリューム／ファイルシステム内のディスクは通常、１以上のグループに編成され、各グループが、ＲＡＩＤグループとして運用される。ＲＡＩＤ実施形態の一例は、ＲＡＩＤ４実施形態である。ただし、本明細書に記載する本発明の原理によれば、他のタイプ、及び他のレベルのＲＡＩＤ実施形態を使用してもよいと考えられる。
【００２８】
ディスク２３０へのアクセスを容易にするために、ストレージオペレーティングシステム３００は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、仮想化モジュールと協働し、ディスク２３０によって提供される記憶空間を「仮想化」する。ファイルシステムは、情報をディレクトリ、及びファイルの階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を格納するように構成された一組のディスクブロックとして実施される一方、ディレクトリは、特殊なフォーマットのファイルとして実施され、その中に、他のファイルやディレクトリの名前、あるいはそれらへのリンクが格納される場合がある。仮想化モジュールによれば、ファイルシステムは更に、ＬＵＮとしてエキスポートされるディスク上に、その情報をｖｄｉｓｋのようなさらに別のデータコンテナの階層構造として論理編成することができる。
【００２９】
例示的実施形態として、ストレージオペレーティングシステムは、好ましくは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッド社から入手可能なＮｅｔＡｐｐ  Ｄａｔａ  ＯＮＴＡＰオペレーティングシステムである。このオペレーティングシステムは、Ｗｒｉｔｅ  Ａｎｙｗｈｅｒｅ  Ｆｉｌｅ  Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムを実施する。ただし、本明細書に記載する本発明の原理によれば、任意の適当なストレージオペレーティングシステムを拡張して使用することも可能であると考えられる。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のストレージオペレーティングシステムを指すものとして広い意味で捉えなければならない。
【００３０】
図３は、本発明とともに有利に使用されるストレージオペレーティングシステム３００を示す略ブロック図である。ストレージオペレーティングシステムは、統合ネットワークプロトコルスタックを形成するように編成された一連のソフトウェア層を含み、より一般的に言えば、ストレージオペレーティングシステムは、クライアントがブロックアクセスプロトコル、及びファイルアクセスプロトコルを使用してストレージシステムに格納された情報をアクセスするためのデータパスを提供するマルチプロトコルエンジンを含む。プロトコルスタックは、ＩＰ層３１２、並びにその支援搬送機構であるＴＣＰ層３１４、及びユーザデータグラム（ＵＤＰ）層３１６のようなネットワークプロトコル層に対するインタフェースを提供するネットワークドライバ（例えば、ギガビットイーサネット（R）ドライバ）のメディアアクセス層３１０を含む。ファイルシステムプロトコル層は、マルチプロトコルファイルアクセスを提供し、その目的のために、ダイレクト・アクセス・ファイルシステム（ＤＡＦＳ）プロトコル３１８、ＮＦＳプロトコル３２０、ＣＩＦＳプロトコル３２２、及びハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル３２４をサポートする。ＶＩ層３２６は、ＶＩアーキテクチャを実施し、ＤＡＦＳプロトコル３１８に必要とされるＲＤＭＡのようなダイレクト・アクセス・トランスポート（ＤＡＴ）機能を提供する。
【００３１】
ｉＳＣＳＩドライバ層３２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを提供する一方、ＦＣドライバ層３３０は、ストレージシステムに対するブロックアクセス要求、及び応答の送受信を行う。ＦＣドライバ、及びｉＳＣＳＩドライバは、ストレージシステムのブロックをアクセスするときに、ブロックに対するＦＣ固有の、又はｉＳＣＳＩ固有のアクセス制御を提供する。すなわち、それらのドライバは、ｉＳＣＳＩ、又はＦＣＰ、あるいはそれら両方に対するＬＵＮのエキスポートを管理する。さらに、ストレージオペレーティングシステムは、Ｉ／Ｏ処理に従ってボリューム／ディスクに対する情報の格納、及び読み出しを管理するためにＲＡＩＤ３４０として実施されるディスクストレージモジュール、及び例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施するディスクドライバシステム３５０を含む。
【００３２】
ディスクソフトウェア層と統合ネットワークプロトコルスタック層の間を橋渡しするのは、仮想化システム３５５である。仮想化システム３５５は、例えばｖｄｉｓｋモジュール３７０、及びＳＣＳＩターゲットモジュールのような仮想化モジュールと通信するファイルシステム３６５によって実施される。ｖｄｉｓｋモジュール３７０は、例えば、ファイルシステム３６５の上に層として形成され、ユーザ（システム管理者）がストレージシステムに対して発行するコマンドに応答して、ユーザインタフェース（図示せず）のような管理インタフェースによるアクセスを可能にする。ＳＣＳＩターゲットモジュール３６０は、ＦＣ、ｉＳＣＳＩドライバ３２８、３３０と、ファイルシステム３６５との間に配置され、ブロック（ＬＵＮ）空間と、ＬＵＮがブロックとして表現されるファイルシステム空間との間に、仮想化システム３５５の変換層を提供する。
【００３３】
ファイルシステムは例えば、ディスクのようなストレージデバイスに格納された情報にアクセスする際に使用される論理ボリューム管理機能を備えたメッセージベースのシステムである。すなわち、ファイルシステム３６５は、ファイルシステムセマンティックを提供するだけでなく、通常ならばボリュームマネージャに関連する機能も提供する。そうした機能には例えば、（１）ディスクのアグレゲーション、（２）ディスクの記憶帯域幅のアグレゲーション、並びに（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証がある。ファイルシステム３６５は例えば、４キロバイト（ｋＢ）ブロックとインデックス・ノード（「ｉｎｏｄｅ」）を使用してファイルやファイル属性（作成時刻、アクセスパーミッション、サイズ、及びブロック位置など）を指定するブロックベースのオンディスク・フォーマット表現を有するＷＡＦＬファイルシステム（以後、一般に「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム」と呼ぶ）を実施する。ファイルシステムは、ファイルを使用して、当該ファイルシステムのレイアウトを表わすメタデータを格納する。こうしたメタデータファイルには、とりわけ、ｉｎｏｄｅファイルがある。ディスクからのｉｎｏｄｅの読み出しには、ファイルハンドル、すなわち、ｉｎｏｄｅ番号を含む識別子が使用される。
【００３４】
簡単に言えば、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムのｉｎｏｄｅは全て、ｉｎｏｄｅファイルとして編成される。ファイルシステム（ＦＳ）ｉｎｆｏブロックは、ファイルシステム内の情報のレイアウトを指定し、そのファイルシステムの他の全てのｉｎｏｄｅを含むファイルのｉｎｏｄｅを含む。各論理ボリューム（ファイルシステム）はＦＳｉｎｆｏブロックを有し、ＦＳｉｎｆｏブロックは例えばＲＡＩＤグループ内の定位置に格納されることが好ましい。ルートＦＳｉｎｆｏブロックのｉｎｏｄｅは、ｉｎｏｄｅファイルのブロックを直接参照する（指し示す）場合もあれば、ｉｎｏｄｅファイルの間接ブロックを参照し、さらに、ｉｎｏｄｅファイルの間接ブロックを参照する場合もある。ｉｎｏｄｅファイルの直接ブロックにはそれぞれ、ｉｎｏｄｅが埋め込まれ、各ｉｎｏｄｅは、間接ブロックを参照し、さらに、ファイルのデータブロックを参照する場合がある。
【００３５】
動作的には、クライアント１１０からの要求は、コンピュータネットワーク１２０を介してパケットとしてストレージシステム２００へ転送され、そこで、ネットワークアダプタ２２６により受信される。（層３１０、又は層３３０の）ネットワークドライバは、そのパケットを処理し、必要であれば、それをネットワークプロトコル層、及びファイルアクセス層に渡して更なる処理を行った後、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６５へと転送する。このとき、要求されたデータが「コア内」に無ければ、すなわち、バッファキャッシュ２７０中に無ければ、ファイルシステムは、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイル内を検索し、適当なエントリにアクセスし、論理ｖｂｎを読み出す。そしてファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム３４０に渡す。そして、この論理ｖｂｎは、ディスク識別子と物理ブロック番号（ディスク、ｖｂｎ）にマッピングされ、ディスクドライバシステム３５０の適当なドライバ（例えば、ＳＣＳＩ）に送られる。ディスクドライバは、指定されたディスクからそのｐｂｎを取得し、要求されたデータブロック（複数の場合もあり）をキャッシュ２７０にロードし、ストレージシステムにより処理する。要求の処理が完了すると、ストレージシステム（及び、オペレーティングシステム）は、ネットワーク１２０を介してクライアント１１０に応答を返す。
【００３６】
なお、ストレージシステムによって受信されたクライアント要求に応じてデータストレージアクセスを実施するために必要となる上記のストレージオペレーティングシステムの種々の層を通るソフトウェア「パス」は、代替として、ハードウェアで実施してもよい。すなわち、本発明の代替実施形態として、ストレージアクセス要求データパスは、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）として実施され、又は特定用途向けＩＣ（ＡＳＩＣ）の中に論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１１０が発行した要求に応答してストレージシステム２００により提供されるストレージサービスの性能を向上させることができる。また、本発明の更に別の実施形態によれば、アダプタ２２６、２２８の処理要素は、プロセッサ２２２から、パケット処理やストレージアクセスオペレーションの負荷の一部、又は全部を取り除くように構成される場合があり、それによって、システムにより提供されるストレージサービスの性能が向上する場合がある。当然ながら、本明細書に記載する種々のプロセス、アーキテクチャ、及び手順は、ハードウェアで実施しても、ファームウェアで実施しても、ソフトウェアで実施してもよい。
【００３７】
本明細書に記載するように、「ストレージオペレーティングシステム」という用語は一般に、ストレージシステムにおいてストレージ機能を実施する働きをするコンピュータ実行可能コードを意味する。ストレージシステムは、例えば、データアクセスを管理し、ファイルサーバの場合、ファイルシステムセマンティックを実施する場合もある。その意味において、ＯＮＴＡＰソフトウェアは、マイクロカーネルとして実施され、ＷＡＦＬファイルシステムセマンティックを実施し、データアクセスを管理するためのＷＡＦＬ層を含む、そのようなストレージオペレーティングシステムの一例である。また、ストレージオペレーティングシステムは、ＵＮＩＸやＷｉｎｄｏｗｓ(R)  ＮＴのような汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施してもよいし、あるいは、本明細書に記載するようなストレージアプリケーションにあわせて構成された構成変更機能を備えた汎用オペレーティングシステムとして実施してもよい。
【００３８】
さらに、当業者には明らかなように、本明細書に記載する本発明の技術は、いかなるタイプの特殊目的（例えば、ファイルサーバ、ファイラ、又はマルチプロトコルストレージアプライアンス）のコンピュータにも、汎用コンピュータにも適用することができ、例えば、ストレージシステム２００として構成され、又はストレージシステム２００を含むように構成されたスタンドアロンのコンピュータ、あるいはその一部に適用される場合もある。本発明とともに有利に使用されるマルチプロトコルストレージアプライアンスの一例は、２００２年８月８日に出願された「Multi-Protocol Storage Appliance that provides Integrated Support for File and Block Access Protocols」と題する米国特許出願第１０／２１５，９１７号に記載されている。この発明の教示は、種々のストレージシステムアーキテクチャに適合し、限定はしないが例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアントやホストコンピュータに直接取り付けられたディスクアセンブリにも適合する。したがって、「ストレージシステム」という用語を使用した場合であっても、この用語は、ストレージ機能を実施し、他の装置、又はシステムに関連するように構成された任意のサブシステムだけでなく、そのような構成も含むものとして広い意味で捉えなければならない。
【００３９】
図４は、本発明の一実施形態によるＣＡＳＡＥ４００を示す略ブロック図である。ＣＡＳＡＥは、ＣＡＳＡＥは例えば、ブロック志向のＡＳＩＣ素子として実施され、とりわけ、複数（例えば、８個）のディスクポート４２５を備えたディスクポート・アダプタ４２０、及びギガビット・イーサネット(R)・ポートのような複数（例えば、２個）のネットワークポート４３５を備えたネットワークポート・アダプタ４３０に接続されたコントローラ（例えば、プロセッサ４１０、及びメモリ４１５）を含む。プロセッサ４１０は、本発明による内容参照ストレージ計算を実施するように構成される。ネットワークポート４３５は、切り替え装置１５０を介してＣＡＳＡＥ４００をストレージシステム２００に接続するように構成される。更に、ディスクポート４２５は、ストレージリソース（例えば、ディスク４５０）をＣＡＳＡＥに接続するように構成され、それによって、ＣＡＳＡＥ「ストレージブリック」１８０が形成される。
【００４０】
ＣＡＳＡＥストレージブリック１８０のディスク４５０は、ＬＵＮ４７０としてエキスポートされ、その種々の部分が、例えば、ファームウェア、アカウンティング（本明細書に記載するマッピングテーブルを含む）、及びユーザデータ（データブロック）に割り当てられる。また、ＬＵＮ４７０のディスクは、ディスク４５０の信頼性を向上させるように構成された単一のＲＡＩＤレベル実施形態（例えば、ＲＡＩＤ６）グループとして編成される。ディスクの１つ、又は２つが故障した場合でも、ＲＡＩＤ６実施形態の機能により、ストレージブリック１８０は動作を継続し、故障したディスク（複数の場合もあり）は、計画された次のダウンタイムに交換、又は修理される。ただし、プロセッサ４１０の故障は、緊急事態を引き起こす。なぜなら、プロセッサの構成要素は、ＲＡＩＤ実施形態によって保護されていないからである。ディスクからデータをまだ読み出せることもあるが、故障した構成要素が交換されるまで、ストレージブリックは、書き込みオペレーションを処理しない。
【００４１】
例示的実施形態として、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムでは、ファイルは、ディスクへの格納に適したｉｎｏｄｅデータ構造として表現される。図５は、ｉｎｏｄｅ５００を示す略ブロック図である。ｉｎｏｄｅ５００は、好ましくは、メタデータ部５１０、及びデータ部５５０を備える。各ｉｎｏｄｅ５００のメタデータ部５１０に格納される情報は、ファイルを表わす。つまり、この情報は、ファイルのタイプ（例えば、普通、ディレクトリ、ｖｄｉｓｋ）５１２、ファイルのサイズ５１４、ファイルのタイムスタンプ（例えば、アクセス、及び／又は変更）５１６、及び所有者、すなわち、ファイルのユーザＩＤ（ＵＩＤ５１８）、及びグループＩＤ（ＧＩＤ５２０）を含む。ただし、タイプフィールド５１２に規定されたファイル（ｉｎｏｄｅ）のタイプによって、各ｉｎｏｄｅのデータ部５５０の中身は、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部５５０は、ファイルシステムによって制御されるメタデータを有するのに対し、通常ｉｎｏｄｅのデータ部は、ユーザ（ファイルシステム）データを有する。後者の場合、データ部５５０は、ファイルに関連するデータの表現を含む。
【００４２】
具体的には、普通のオンディスクｉｎｏｄｅのデータ部５５０は、ファイルシステムデータ、又はポインタを含む場合があり、後者は、ファイルシステムデータの格納に使用されるディスク上の４ｋＢデータブロックを参照する。ｉｎｏｄｅのサイズには制限があるため（例えば、１２８バイト）、ファイルシステムデータのサイズが６４バイト以下である場合、データ全体が、そのｉｎｏｄｅのデータ部の中に表現される。しかしながら、ファイルシステムデータのサイズが、６４バイトより大きく、且つ６４ｋＢ以下である場合、そのｉｎｏｄｅ（すなわち、第１レベルｉｎｏｄｅ）のデータ部は、最大で１６個までのブロックポインタを含み、各ブロックポインタが、ディスク上の４ｋＢブロックのデータを参照する。
【００４３】
さらに、ファイルシステムデータのサイズが６４ｋＢより大きく、且つ６４メガバイト（ＭＢ）以下である場合、そのｉｎｏｄｅ（例えば、第２レベルｉｎｏｄｅ）のデータ部５５０にある各ポインタは、１０２４個のポインタを含む間接ブロック（例えば、第１レベルブロック）を参照し、各ポインタが、ディスク上の４ｋＢデータブロックを参照する。ファイルシステムファイルシステムデータのサイズが６４ＭＢよりも大きい場合、そのｉｎｏｄｅ（例えば、第３レベルｉｎｏｄｅ）のデータ部５５０にある各ポインタは、１０２４個のポインタを含む二重間接ブロック（例えば、第２レベルブロック）を参照し、各ポインタが、間接（例えば、第１レベル）ブロックを参照する。さらに、その間接ブロックは、１０２４個のポインタを含み、各ポインタは、ディスク上の４ｋＢブロックを参照する。ファイルをアクセスするとき、そのファイルの各ブロックは、ディスクからバッファキャッシュ２７０へロードされる場合がある。
【００４４】
オンディスクｉｎｏｄｅ（又はブロック）をディスクからバッファキャッシュ２７０へロードするとき、それに対応するコア内構造が、そのオンディスク構造に埋め込まれる。例えば、ｉｎｏｄｅ５００を取り囲む破線は、オンディスクｉｎｏｄｅ構造のコア内表現を示している。コア内構造は、オンディスク構造だけでなく、メモリ上のデータ（ただし、ディスク上に無い）の管理に必要となる他の情報も格納する。この他の情報には、例えば、「ダーティ」ビット５６０がある。例えば書き込みオペレーションに従って、ｉｎｏｄｅ（又はブロック）中のデータが更新／変更された後、変更されたデータは、ダーティビット５６０を使用して「ダーティ」としてマーキングされ、以後、そのｉｎｏｄｅ（ブロック）をディスクに「フラッシュ」（格納）できるようにする。ｉｎｏｄｅ、及びｉｎｏｄｅファイルを含むＷＡＦＬファイルシステムのコア内構造、及びオンディスクフォーマット構造については、１９９８年１０月６日に発行された「Method for Maintaining Consistent States of a File System and for Creating User-Accessible Read-Only Copies of a File System」と題する、既に援用された米国特許第５、８１９，２９２号に、Davit Hitz他により開示、及び記載されている。
【００４５】
図６は、本発明と共に有利に使用されるファイルのバッファツリーを示す略ブロック図である。バッファツリーは、バッファキャッシュ２７０にロードされ、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６５によって管理されるファイルのブロックの内部表現である。埋め込みｉｎｏｄｅのようなルート（最上位）ｉｎｏｄｅ６０２は、間接（例えば、レベル１）ブロック６０４を参照する。なお、ファイルのサイズによっては、さらに別のレベル（例えば、レベル２やレベル３）の間接ブロックが存在する場合もある。これらの間接ブロック（及び、ｉｎｏｄｅ）は、そのファイルの実際のデータの格納に使用されるデータブロック６０６を最終的に参照する幾つかのポインタ６０５を含む。つまり、ファイル６００のデータは、幾つかのデータブロックに格納され、それらのブロックの位置が、そのファイルの間接ブロックに格納される。各レベル１間接ブロック６０４は、１０２４個ものデータブロックへのブロックポインタを含む場合がある。ファイルシステムの「ｗｒｉｔｅ  ａｎｙｗｈｅｒｅ」な性質によれば、それらのデータブロックは、ディスク上のどこに配置される場合もありうる（例えば、ディスク４５０）。
【００４６】
上記のように、ローカルストレージアレイ２６０のディスク２３０は、例えば、ＣＡＳＳ１００によって提供されるディレクトリ、ファイル、及びＬＵＮのようなデータコンテナを表わす高レベルメタディレクトリを格納するように構成されるのに対し、リモートストレージアレイ４６０のディスク４５０は、それらのコンテナの実際のデータブロックを格納するように構成される。図７は、本発明による、メタディレクトリとデータブロックのオンディスクストレージレイアウト７００を示す略ブロック図である。具体的には、ローカルストレージアレイ２６０は、ファイルｉｎｏｄｅ７２０を参照する（指し示す）ポインタを有する１以上のｉｎｏｄｅ７１２を有するディレクトリブロック７１０を含む。さらに、それらのファイルｉｎｏｄｅは、例えば、間接ブロック７２４を指し示すポインタを有し、さらに、その間接ブロック７２４は、リモートストレージアレイ４６０に格納される実際のデータブロック７２６を参照するブロックポインタを有する。このように、ファイル(及び、ｖｄｉｓｋ）のバッファツリーのメタデータ、すなわち、ｉｎｏｄｅと間接ブロックは全て、ストレージシステム２００のローカルストレージアレイ２６０のディスク２３０上に存在する一方、データブロックは全て、ＣＡＳＡＥストレージブリック１８０のリモートストレージアレイ４６０のディスク４５０上に存在する。換言すれば、ローカルストレージアレイ４５０上のディスク（及び、ボリューム）は、データコンテナのｉｎｏｄｅ、及び間接ブロックを全て格納し、ローカルストレージアレイには、データブロックが何も存在しない。それらのｉｎｏｄｅ、又は間接ブロック中のブロックポインタは全て、リモートストレージアレイ４６０の幾つかに格納されたデータブロックを参照する。
【００４７】
ストレージシステム２００と各ＣＡＳＡＥストレージブリック１８０との間の通信は、例えば、ＳＣＳＩコマンド記述子ブロック（ＣＤＢ）メッセージを利用するストレージプロトコル交換を使用して実施される。クライアントから発行された、或るブリックのＬＵＮ４７０に格納されたデータコンテナ（例えば、ファイル）に対する書き込み要求に応答し、ファイルシステム３６５は、ＲＡＩＤシステム３４０と協働し、オペレーション（例えば、読み出し、又は書き込み）、ブロック番号、ステータス、及びデータ（例えば、書き込みデータ）を含むメッセージを生成する。次に、このメッセージは、ディスクドライバシステム３５０に渡され、ＳＣＳＩ  ＣＤＢメッセージとして、ストレージブリック１８０のＣＡＳＡＥ４００に転送され、ストレージブリック１８０のＣＡＳＡＥ４００は、そのＬＵＮ４７０上に何らかの重複データブロックがあるか否かを探すためのストレージ計算プロセスを実施する。これに応答し、ＣＡＳＡＥは、ＬＵＮ４７０上の書き込みデータの位置の実際のｐｂｎを含むＳＣＳＩ  ＣＤＢメッセージを、ストレージシステム（ファイルシステム）に返す。
【００４８】
本発明によれば、ファイルシステム３６５は、特殊なブロック番号、例えば、ブロックゼロを使用して、ＣＡＳＡＥ４００に対し、各データブロックに対する内容参照ストレージ計算を命じ、それによって、そのデータがＬＵＮ上のいずれかの位置に既に書き込まれているか否かを判定する。ディスクへのデータの格納に、相当な量のドメイン空間が必要となることから、このストレージ計算は、例えば、ハッシュ関数、例えば、ＭＤ５を使用して行われる。本明細書に記載する実施形態は、例えば、ＭＤ５ハッシュアルゴリズムを使用してハッシュキーを計算しているが、当業者には明らかなように、パリティや巡回検査（ＣＲＣ）のような他のハッシュアルゴリズムを本発明とともに使用することも可能である。使用されるハッシュアルゴリズムによっては、最終的なハッシュキーを得るための計算に時間を要する場合もある。ハッシュアルゴリズムによっては（例えば、パリティやＣＲＣのように）、他のハッシュアルゴリズム（例えば、ＭＤ５）に比べて実行に時間を要しないものもあり、後者のアルゴリズムを使用すれば、ドメインが極端に広くない限り、コリジョンの機会は減少する。
【００４９】
具体的には、ＣＡＳＡＥは、データブロックの中身に基づいてハッシュキー、例えば１２８ビットアドレスを計算し、次いで、そのキーが、以前に格納されたデータブロックに対して生成されているか否かを判定する。理論上、一意の（重複しない）データブロックからは全て、新たなハッシュキーが算出されるが、ブロックによっては、同じハッシュキーが算出されることもあり、その結果、コリジョンが発生することもある。もし、そのハッシュキーが以前に生成されているものであった場合、同じキーを有するデータブロックの中身の比較を行い、中身が一致すれば、以前に格納されたデータブロックに対する参照カウントをインクリメントする。そして、以前に格納されたデータブロックのブロック番号（位置）をファイルシステムに返す。一方、そのハッシュキーが以前に生成されたことがないものであった場合、又は、データの中身が一致しなかった場合、そのデータは、ＬＵＮ上の次の空きブロック位置に書き込まれ、その位置が、ファイルシステムに返される。
【００５０】
図８は、ＣＡＳＳ１００におけるストレージシステム２００の動作を示す手順のフロー図である。手順は、ステップ８００から開始され、ステップ８０２へ進み、そこで、ファイルベース、又はブロックベースの書き込み要求が、クライアント１１０により発行され、ストレージシステム２００のネットワークプロトコルスタックで受信される。ステップ８０４において、その書き込み要求はファイルシステム３６５に渡され、ファイルシステム３６５は、その要求に関連する書き込みデータを例えばＮＶＲＡＭ２２９にロギングする。ステップ８０６において、ストレージシステムは、要求の完了を示す確認メッセージをクライアントに返す。その後、書き込みアロケーションの際に、ファイルシステムの書き込みアロケータ３６８は、ブロックアロケーションデータ構造をサーチし、その書き込みデータを格納するための空き記憶空間を識別し（ステップ８０８）、その目的のために、その書き込み要求に関連する書き込みデータの格納に使用されるデータブロックを識別するブロックレイアウトメッセージを作成する（ステップ８１０）。ただし、本発明の一態様によれば、ステップ８１２において、ファイルシステム３６５は、特殊なブロック番号、例えばゼロをそのメッセージに挿入し、ステップ８１４において、そのメッセージをＲＡＩＤシステム３４０に渡す場合がある。
【００５１】
なお、ＲＡＩＤシステムは、ブリック１８０、すなわち、自身のストレージレイアウトをＲＡＩＤシステムにエキスポートしていないブリック１８０上のリモートストレージアレイ４６０の幾何構成を知らない。したがって、ＲＡＩＤシステム３４０は、全てのブリック１８０にわたって均一になるように、書き込みアロケーション（書き込みデータ）のバランスをとろうとする。例えば、各ブリック１８０は、１テラバイト（ＴＢ）のストレージを提供し、ＲＡＩＤシステムは、ＣＡＳＳ１００の複数のブリックにわたって書き込みデータをバランスの取れた状態になるようにストライピングしようとする。その目的のために、ＲＡＩＤシステムは、ディスクドライバシステム３５０と協働し、書き込みオペレーション、及び書き込みデータを含むＳＣＳＩ  ＣＤＢメッセージを作成し、適当なＣＡＳＡＥへ転送する（ステップ８１６）。書き込みデータを受信すると、ＣＡＳＡＥ４００は、本明細書に記載する内容参照ストレージ計算を実施し、その書き込みデータを格納すべきＬＵＮ４７０上の位置を判定する（ステップ８１８）。すなわち、ＣＡＳＡＥ４００は、そのデータを有する重複データブロックがあるか否かを判定する。そして、ステップ８２０において、ＣＡＳＡＥ４００は、そのブロックが存在するＬＵＮ上の場所を示すｐｂｎを返す。
【００５２】
ｐｂｎを受信すると、ステップ８２２において、ファイルシステム３６５は、「修復」オペレーションを実施し、初期に想定した書き込みアロケーションを訂正する。すなわち、ファイルシステムは、最初に、書き込みデータを特殊なブロック番号、ゼロに割り当てたが、修復オペーれションの際に、その特殊なブロック番号をブリック上の実際のｐｂｎ位置に変更する。ステップ８２４において、ファイルシステムは、そのデータブロックのｐｂｎ位置を参照するようにするように、（ローカルストレージアレイ２６０上の）ＬＵＮ４７０に関するバッファツリー（例えば、ｉｎｏｄｅ  及び／又は間接ブロック）ポインタを更新する。そして、手順はステップ８２８において終了する。
【００５３】
図９は、本発明によるＣＡＳＡＥによって実施される内容参照ストレージ計算を示す機能ブロック図である。図示のように、ＣＡＳＡＥのプロセッサ４１０は、ハッシュ関数９３０を使用して、書き込みデータブロック９４０の中身からハッシュキー９２０を計算する。次に、得られたハッシュキー９２０を、内容参照マッピングデータ構造の中から「検索」し、ＣＡＳＡＥストレージブリック１８０のリモートストレージアレイ４６０上に、重複データブロックが格納されているか否かを判定する。このマッピングデータ構造は、バイナリツリー（Ｂツリー）を含む種々の形態に編成される場合がある。ただし、説明、及び理解を簡単にするために、マッピング構造は表形態で描かれ、例えば、ハッシュキーを使用して検索される複数のエントリ９１０を有するマッピングテーブル９００として描かれている。
【００５４】
マッピングテーブル９００の各エントリ９１０は、例えば、ハッシュキーフィールド９１２、リモートストレージアレイ４６０のディスク４５０上に以前に格納されたデータブロックを参照するように構成されたｐｂｎポインタフィールド９１４（すなわち、データブロックの実際の中身を持たないフィールド）、及び参照カウントフィールド９１６を含む。なお、参照データブロックは同じでない場合もあるが、生成されたハッシュキー９２０に一致するハッシュキー９１２を有する複数のエントリ９１０が存在する場合がある。ハッシュキー９２０と、エントリ９１０ａのハッシュキー９１２ａが一致したものと仮定する。コンパレータ９５０は、書き込みデータブロック９４０の中身を、ディスク４５０（エントリ９１０ａ中のｐｂｎポインタ９１４ａによって指し示される）から読み出された書き込みデータブロックの中身と比較する。２つのブロックの中身が一致すれば、そのデータは重複しているため、エントリ９１０ａ中の参照カウント９１６ａがインクリメントされる。上記のように、次に、ＣＡＳＡＥ４００は、あたかもデータブロック９４０が、その位置に実際に格納された書き込みデータブロック９４０であるかのように、ｐｂｎポインタ９１４ａのコピーをファイルシステム３６５に返す。
【００５５】
インクリメントされた参照カウント９１６は、ローカルストレージアレイ２６０に格納される適当なｉｎｏｄｅ７２２、又は間接ブロック７２４にも反映される。ｐｂｎポインタ９１４ａのコピーを使用して、ファイルシステム３６５は、ＲＡＩＤシステム３４０と協働して修復処理を実施し、ＬＵＮ４７０に関するバッファツリー内のその適当なｉｎｏｄｅ、又は間接ブロックに対する参照カウントを更新する。事実上、ローカルストレージアレイ２６０において、ＬＵＮ４７０に関する１以上のバッファツリー（例えば、ｉｎｏｄｅ、及び／又は間接ブロック）ポインタが、そのデータブロックのｐｂｎ位置を参照するように更新される。
【００５６】
一方、ハッシュキー９２０が、エントリ９１０のハッシュキー９１２と一致しなかった場合、あるいは、キーは一致したが、データブロックの中身が一致しなかった場合、そのデータは複製されていないので、書き込みデータブロック９４０は、ＬＵＮ４７０上の次の空きｐｂｎブロック位置に書き込まれ、その位置がファイルシステムに返される。なお、データブロックの中身が一致しなかった場合は、テーブル９００の他のエントリ９１０は検査されない。このとき、絶対データ圧縮と、パフォーマンスとの間のトレードオフがなされる。他に重複データブロックが存在しなかったとしても、そのような重複が存在する機会は非常に低い（特に、ＭＤ５ハッシュアルゴリズムを使用した場合）。したがって、内容参照マッピングテーブル９００の検索は、最初のハッシュキーが「発見」された時点で中止される。そして、書き込みデータブロック９４０は、新たなｐｂｎ位置に格納され、テーブル９００上に新たなエントリ９１０ｂが作成される。具体的には、この新たなエントリのハッシュキーフィールド９１２ｂには、得られたハッシュキー９２０が格納され、ｐｂｎポインタフィールド９１４ｂには、次の空き位置のｐｂｎポインタが格納される。また、参照カウントフィールド９１６ｂは、単一の書き込みデータブロック９４０だけを参照するようにセットされる（例えば、参照カウント１にセットされる）。
【００５７】
図１０は、ＣＡＳＳ１００におけるＣＡＳＡＥ４００の動作を示す手順のフロー図である。手順はステップ１０００から開始され、ステップ１００２へ進み、そこで、ＣＡＳＡＥは、ストレージシステムから、書き込みオペレーション、及び書き込みデータを含むＳＣＳＩ  ＣＤＢメッセージを受信する。ステップ１００４において、ＣＡＳＡＥプロセッサは、内容参照ストレージ計算を実施し、書き込みデータブロックの中身から、ハッシュキーを計算する。なお、このハッシュキーは、４ｋバイト単位で実施され、すなわち、書き込みデータの各データブロックの中身に対して実施される。次に、得られたハッシュキーをマッピングテーブルの中から「検索」し、ＣＡＳＡＥのリモートストレージアレイ上に重複ブロックが存在するか否かを判定する。
【００５８】
具体的には、計算されたハッシュキーは、テーブル上のエントリのハッシュキーと比較され、一致するか否かが判定される（ステップ１００６）。一致した場合（ステップ１００８）、ステップ１０１０において、そのデータブロックの中身を、以前に格納されたブロックの中身と比較する。データの中身の比較の結果、両者が一致した場合（ステップ１０１２）、書き込みデータは重複しているため、ステップ１０１６において、ＣＡＳＡＥは、データをＬＵＮに格納するときのその書き込みデータブロックのｐｂｎ位置（この場合、ｐｂｎ位置は、一致した書き込みデータブロックの以前の位置である）を（ストレージシステムに）に返す。あるいは、書き込みデータが重複するものでなかった場合、ステップ１０１４において、その書き込みデータブロックは、ＬＵＮ上の次の空きｐｂｎブロック位置に格納され、ステップ１０１６において、データをＬＵＮに格納するときのブロックのｐｂｎ位置が、ストレージシステムに返される。そして、手順はステップ１０１８において終了する。
【００５９】
本明細書に記載する例示的実施形態として、各ストレージブリック１８０は、自分の記憶空間をデータ圧縮（重複除去）することができるが、他のブリックの空間を重複除去することはできない。すなわち、もし、第１のブリックに書き込まれたデータブロックが、第２のブリックに以前に書き込まれたものと同じブロックであった場合、そのブロックの２つのコピーが存在することになる。各ブリックが、自分の記憶空間だけを管理できるようにすることで、コリジョンの範囲は、１ブリック、すなわち１テラバイトのストレージに格納可能な４ｋブロックの数に制限される。また、有利なことに、ストレージ計算が、全てのストレージブリックにわたって分散される。例えば、各ブリックについてＭＤ５ハッシュキーの計算に１ミリ秒を要するものと仮定する。８個のブリックを使用した場合、３２ｋバイトの書き込みデータに対する計算は、１ミリ秒程度で実施することができるが、１つのブリックに対して何回かの計算を順番に実施する場合は、計算に８ミリ秒程度の時間を要する。
【００６０】
ストレージリソース上に重複データが格納されることを防止するように構成されたストレージシステムのＣＡＳＡＥの幾つかの実施形態について図示説明したが、本発明の思想、及び範囲内で、他にも変更や修正が施される場合があるものと考えられる。例えば、代替実施形態として、本発明は、ストレージブリック１８０においてｐｂｎから実際のｐｂｎへのマッピングを行う更に別の層にも拡張することができ、その結果、ブリックに書き込まれたあらゆるデータブロックに対し、ブリックは、一意のブロック番号を返すことができる場合がある（幾つかのブロックが、内部的に同じブロックを指し示していても）。このように、ファイルシステムは、書き込みデータブロックが常に新たに割り当てられることを前提としている。
【００６１】
上記の説明は、本発明の特定の幾つかの実施形態に関するものである。しかしながら、当業者には明らかなように、記載した実施形態の利点の一部、又は全部を維持しながら、記載した実施形態に対し、種々の変更、及び修正を施してもよい。例えば、本発明の教示は、コンピュータ上で実行されるプログラム命令を有するコンピュータ読取可能媒体を含むソフトウェアとして実施しても、ハードウェアとして実施しても、ファームウェアとして実施してもよく、あるいは、それらの組み合わせとして実施してもよい。したがって、本明細書の説明は、単なる例として捉えるべきものであり、本発明の範囲を何ら制限するものではない。従って、添付の特許請求の範囲の目的は、そのような変更や修正も全て、本発明の真の思想、及び範囲内に収めることにある。
【図面の簡単な説明】
【００６２】
【図１】本発明とともに有利に使用される内容参照ストレージシステム（ＣＡＳＳ）を示す略ブロック図である。
【図２】本発明とともに有利に使用されるＣＡＳＳのストレージオペレーティングシステムを示す略ブロック図である。
【図３】本発明とともに有利に使用されるストレージオペレーティングシステムの略ブロック図である。
【図４】本発明によるＣＡＳＳの内容参照ストレージアレイ要素（ＣＡＳＡＥ）の略ブロック図である。
【図５】本発明とともに有利に使用されるｉｎｏｄｅを示す略ブロック図である。
【図６】本発明とともに有利に使用されるファイルのバッファツリーを示す略ブロック図である。
【図７】本発明によるメタディレクトリ、及びデータブロックのオンディスクストレージレイアウトを示す略ブロック図である。
【図８】ＣＡＳＳにおけるストレージシステムの動作を示す手順のフロー図である。
【図９】本発明による、ＣＡＳＡＥにより実施される内容参照ストレージ計算を示す機能ブロック図である。
【図１０】ＣＡＳＳにおけるＣＡＳＡＥの動作を示す手順のフロー図である。
【図１】
2009524882.tif 000003
【図２】
2009524882.tif 000004
【図３】
2009524882.tif 000005
【図４】
2009524882.tif 000006
【図５】
2009524882.tif 000007
【図６】
2009524882.tif 000008
【図７】
2009524882.tif 000009
【図８】
2009524882.tif 000010
【図９】
2009524882.tif 000011
【図１０】
2009524882.tif 000012
【国際調査報告】
2009524882.tif 000013
2009524882.tif 000014
2009524882.tif 000015