JP2009020858A - データデデュプリケーションを用いる電力効率のよいストレージ - Google Patents

Abstract

【課題】ストレージシステムでの電力消費を減らす。
【解決手段】ストレージシステム内の電力消費は、ストレージデバイスに供給される電力を選択的に制御すると同時に、必要な記憶容量の量を減らすためにデデュプリケーション機能をも組み込むことによって減らされる。第１ストレージデバイスは、当初に、パワーオン状態であり、第２ストレージデバイスは、パワーオフ状態である。コントローラによって受け取られた書込データは、当初に、第１ストレージデバイスから割り振られた第１ボリュームに格納される。第２ストレージデバイスがパワーオンされている間に、第１ボリュームに格納された書込データの内容が、第２ストレージデバイス上で割り振られた第２ボリュームに格納されたすべての既存データの内容と比較される。比較の結果が、書込データの内容が既存データの内容と一致しないことを示すときには、書込データが、第２ボリュームに格納される。
【選択図】図２

Description

[0002] 本発明は、全般的にはストレージシステムでの電力消費および容量消費の削減に関する。

[0004] ストレージ産業の最近の傾向によれば、エンタープライズデータの量はすばやく増加しつつあるが、それと同時に、情報テクノロジ予算は制約されつつある。したがって、現在、格納されなければならないデータの量を減らすテクノロジへの高い関心がある。そのようなテクノロジの１つであるデータデデュプリケーション（ｄａｔａ ｄｅ−ｄｕｐｌｉｃａｔｉｏｎ）は、既に特定のストレージ環境に格納された大量のデータが、やはりそのストレージ環境内に格納された冗長な部分を有するという事実に頼る。データ書込処理中に、通常のデデュプリケーション機能は、データストリームをより小さいデータのチャンクに分解し、データの各チャンクの内容を、そのストレージ環境に以前に格納されたチャンクと比較する。同一のチャンクが既に格納されている場合には、ストレージシステムは、同一の内容を有する新しいチャンクを格納するのではなく、既に格納されているチャンクへの新しいリンクだけを作る。この機能は、ストレージ環境に格納されるデータの総サイズを減らし、したがって、このテクノロジは、ＶＴＬ（仮想テープライブラリ）製品またはＣＡＳ（Ｃｏｎｔｅｎｔｓ Ａｄｄｒｅｓｓｅｄ Ｓｔｏｒａｇｅ）製品など、多数のストレージシステムで採用されてきた。Ｚｈｕ他の２００５年５月２４日出願の米国特許出願公告第２００５／０２１６６６９号、名称「Ｅｆｆｉｃｉｅｎｔ Ｄａｔａ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ」は、その開示全体が参照によって本明細書に組み込まれているが、デデュプリケーション機能を用いてデータを格納する通常の方法を教示している。

[0005] さらに、格納されるデータの量の増加に起因して、データを格納するのに必要な電力消費も増えてきた。ストレージデバイスおよびそのストレージデバイスを冷却するのに必要な関連する冷却システムによって直接に消費される電力は、データセンタを運営するコストの大きい要因になりつつある。さらに、近い将来に、一部のデータセンタが、追加される機器の高い密度に起因して、不十分な電力容量を有する可能性があると予測されている。したがって、より高い電力効率を達成することが、多くのデータセンタにとってクリティカルな問題になりつつある。したがって、データセンタ内のストレージデバイスを動作させるのに必要な電力の量を減らし、これによってデータセンタの運営の総合コストを減らすことが望ましい。さらに、上で述べたデデュプリエーションテクノロジの使用を介するなど、格納されるデータの量をも減らすと同時に電力消費を減らすことが望ましい。しかし、従来技術は、データに対するデデュプリケーション処理を実行することによってデータをより効率的に格納すると同時に、ストレージシステムの電力消費を減らすテクノロジを教示せず、提案していない。

[0006] 本発明は、ストレージ環境で必要な記憶容量の量を減らすためにデデュプリケーション機能をも組み込みながら、ストレージデバイスに供給される電力を選択的に制御することによってストレージシステムでの電力消費を減らす。本発明の上記および他の目的および利益は、好ましい実施形態の次の詳細な説明に鑑みて、当業者に明白になるであろう。

[0007] 添付図面は、上で与えた全般的な説明および下で与える好ましい実施形態の詳細な説明と共に、現在企図されている本発明の最良の態様の好ましい実施形態の原理を図示し、説明するように働く。

[0028] 本発明の次の詳細な説明では、本開示の一部を形成する添付図面を参照し、添付図面では、限定ではなく例として、本発明を実践できる特定の実施形態を示す。図面では、類似する符号が、複数の図面を通じて実質的に類似する構成要素を示す。さらに、図面、前述の議論、および次の説明は、例示的かつ説明的であるのみであって、いかなる形でも本発明または本願の範囲を限定することは意図されていない。

[0029] 本発明の実施形態は、ある種の産業での格納されるデータの量の爆発に対処するデデュプリケーション解決策を提供する方法および装置を開示し、本発明の実施形態は、ストレージデバイスによって消費される電力の量を減らすディスク電力制御テクノロジをも導入する。本発明人は、ある種のストレージ環境で、格納される大量のデータが、頻繁にアクセスされる必要がないバックアップまたはアーカイブされるデータであり、実際に、大量のデータが、格納され、絶対に二度とアクセスされないと判定した。本発明は、ストレージデバイスが常時アクティブである必要がない場合にディスクスピンドルをオフにする最適の情況を判定し、これによってストレージデバイスの電力消費を減らすことによって、この現象を利用する。さらに、デデュプリケーションテクノロジが、データバックアップおよびアーカイビングのますます広がる領域で使用されるストレージシステムにますます採用されつつある。しかし、デデュプリケーションテクノロジは、新たに入ってくるデータチャンクの内容を以前に格納されたデータチャンクの内容と常に比較するので、膨大なサイズを有する可能性があるボリュームまたはディスクが、この目的のために常にパワーオンされている必要がある。これが必要なのは、以前に格納されたデータチャンクのいずれかが、新たに入ってくるチャンクとビット対ビットの基礎で直接に比較される必要がある可能性があり、ディスクに格納されたデータの特定の部分が、ある時間期間中に比較に使用される必要がないという保証がないからでる。

[0030] 本発明で開示されるストレージシステムは、クライアントホスト入出力（Ｉ／Ｏ）動作のターゲットとして、クライアントホストに見かけのストレージリソースとして仮想ボリュームを公開する。本発明の仮想ボリュームは、実際には、２つの別々のタイプの論理ボリュームすなわち、バッファボリュームおよびベースボリュームからなるが、この仮想ボリュームは、ホストがアクセスできる単一のボリュームであるかのようにクライアントホストに提示される。したがって、バッファボリュームとベースボリュームとの両方が、デデュプリケーション機能によって整理統合されるデータチャンクを格納するターゲットボリュームである。しかし、本発明のベースボリュームは、ストレージシステム内のストレージデバイスに対して格納された完全に一意のチャンクを保持するのに使用され、本発明のバッファボリュームは、クライアントホストによって格納を最近に要求されたチャンクを一時的に保持するのに使用される。

[0031] ベースボリュームの電力供給（すなわち、ベースボリュームを構成する１つまたは複数のストレージデバイスへの電力）は、通常はパワーオフ状態である。したがって、ストレージシステム内のストレージデバイスのほとんどは、通常は電力を消費しない。クライアントホストが、データを仮想ボリュームに書き込むことを要求する時に、デデュプリケーションモジュールが、バッファボリュームを利用することによってデデュプリケーション処理を実行する。すべての書込要求に含まれるデータが、一時的にバッファボリュームに格納され、一時格納期間中に、ベースボリュームは、パワーオフのままになる。フラッシュコマンドが受け取られる時（ストレージ管理者によってトリガされる時、データ読取要求の時、またはある他のトリガする機構によってなど）、デデュプリケートするモジュールは、ベースボリュームのデータを含むストレージデバイスの電力をオンにし、デデュプリケーションテクノロジを使用してバッファボリュームに格納されたチャンクをベースボリュームとマージし、これによって、デデュプリケーション処理を同時に実行する。チャンクのマージの終了後に、デデュプリケーションモジュールは、ベースボリュームへの電力供給をオフにし、バッファボリューム上のチャンクおよび関連するテーブルを初期化する。したがって、本発明の利益は、ストレージデバイス電力供給を制御することによってストレージシステムでの電力消費を減らすと同時に、必要な記憶容量の量を減らすためにシステム上でデデュプリケーション機能を利用することである。デデュプリケーションチャンクを格納するボリュームの複数のレイヤを有することと、ベースボリュームの電力供給制御をチャンクをフラッシュする処理と一体化することによって、ストレージデバイスの大きい部分をほとんどの時間にパワーオフすることが可能になり、これを、十分な量のエネルギの節約につなげることができる。本発明のさまざまな例の実施形態を、下で図面を参照して説明する。

[0032] 第１実施形態−ハードウェアアーキテクチャ
[0033] 図１に、第１実施形態の情報システムの物理的ハードウェアアーキテクチャの例を示す。これらの実施形態の情報システムは、ストレージシステム１００、１つまたは複数のクライアントホスト１１０、およびストレージ管理サーバ１３０からなる。クライアントホスト１１０およびストレージシステム１００は、ＳＡＮ １２０（ストレージエリアネットワーク）を介して通信のために接続される。さらに、ＳＡＮが図示されているが、この接続を、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、直接接続、または類似物など、さまざまなタイプの接続のいずれかとすることができる。また、ストレージ管理サーバ１３０およびストレージシステム１００は、ＬＡＮ １４０を介して通信のために接続されるが、このＬＡＮ １４０も、任意の代替の接続タイプとすることができる。

[0034] ストレージシステム１００は、記憶媒体１０６など、複数のストレージデバイスへのアクセスを制御するコントローラ１０１を含む。コントローラ１０１は、ＣＰＵ １０２、メモリ１０３、ＳＡＮ １２０との接続用のポート１０４、およびＬＡＮ １４０との接続用のネットワークインターフェース（ＮＩＣ）１０５を含む。記憶媒体１０６は、コントローラ１０１との通信のために接続され、好ましい実施形態ではハードディスクドライブとすることができるが、他の実施形態では、その代わりに、フラッシュメモリ、光ディスク、テープ、および類似物など、さまざまな他のタイプのストレージデバイスのいずれかとすることができる。

[0035] 各クライアントホスト１１０は、ＣＰＵ １１１、メモリ１１２、およびクライアントホスト１１０をＳＡＮ １２０に接続するホストバスアダプタ（ＨＢＡ）１１３を含むコンピュータとすることができる。クライアントホスト１１０は、ストレージサービスユーザ用の端末コンピュータとして働くことができる。

[0036] ストレージ管理サーバ１３０は、ＣＰＵ １３１、メモリ１３２、およびＬＡＮ １４０との通信用のネットワークインターフェースカード（ＮＩＣ）１３３を含むコンピュータサーバとすることができる。ストレージ管理サーバ１３０は、ストレージ管理者がストレージシステム１００を管理することを可能にする端末サーバとして働くことができる。

[0037] 論理要素の構造
[0038] 図２に、第１実施形態のソフトウェアおよび論理要素の構造を示す。記憶媒体１０６は、アレイグループ２５０−１および２５０−２などの複数のアレイグループ２５０に論理的に構成され、アレイグループ２５０−１および２５０−２などは、各アレイグループから１つまたは複数の論理ボリュームを形成するための論理記憶容量を構成するのに使用することができる。さらに、各アレイグループ２５０は、好ましくはＲＡＩＤ（ｒｅｄｕｎｄａｎｔ ａｒｒａｙ ｏｆ ｉｎｄｅｐｅｎｄｅｎｔ ｄｉｓｋｓ）グループまたは類似物に構成される複数の物理記憶媒体１０６からなる。たとえば、複数の記憶媒体１０６を、４つのディスクのうちの任意の３つがデータを格納し、残りのディスクがパリティ情報を格納するＲＡＩＤ ５アレイとして構成することができる。他のＲＡＩＤ構成を使用することもでき、あるいはその代わりに、本発明をＲＡＩＤ保護なしで実践することができる。

[0039] バッファボリューム２２０およびベースボリューム２３０は、その記憶容量がそれぞれアレイグループ２５０−１および２５０−２から切り分けられる論理ストレージエクステントを含む。したがって、図２では、バッファボリューム２２０は、アレイグループ２５０−１によって提供される物理ストレージから生成された論理ストレージエリアであり、バッファボリューム２２０に格納されるデータは、アレイグループ２５０−１を構成するのに使用される記憶媒体１０６に物理的に格納されるようになっている。同様に、ベースボリューム２３０は、アレイグループ２５０−２から生成された論理ストレージエリアであり、ベースボリューム２３０に格納されるデータは、アレイグループ２５０−２を構成する記憶媒体１０６に物理的に格納される。本発明によれば、アレイグループ２５０−１を構成する記憶媒体１０６は、アレイグループ２５０−２を構成する記憶媒体１０６とは異なり、記憶媒体に電力を与える別々に制御可能な電力供給を使用し、その結果、アレイグループ２５０−１を構成する記憶媒体１０６がパワーオンのままであることができる間に、アレイグループ２５０−２を構成する記憶媒体１０６を、エネルギを節約するために長い時間期間にわたってパワーオフできるようになっている。好ましい実施形態では、アレイグループ２５０−２を構成する記憶媒体１０６を、アレイグループ２５０−１を構成する記憶媒体とは別々のアレイエンクロージャ内に配置することができ、これは、そのエンクロージャ全体をパワーオフすることを可能にすることができ、その結果、冷却に必要なエネルギをも節約できるようになる（しかし、本発明がそのような構成に限定されないことに留意されたい）。

[0040] バッファボリューム２２０とベースボリューム２３０との両方が、データチャンク２４０を格納することができる。チャンク２４０は、クライアントホスト１１０がストレージシステム１００に格納を要求したデータの一部である。しかし、デデュプリケーションモジュール２００は、データ書込処理中にバイトの同一のパターンを有するチャンクを整理統合するので、格納される各チャンク２４０は、少なくともめいめいのボリューム（すなわち、バッファボリューム２２０またはベースボリューム２３０）内で、一意の内容を有する。好ましい実施形態では、チャンクは、複数のストレージブロック２６０からなり、各チャンクは、同一個数のブロックから構成される。１つのチャンク内のブロック２６０の最大個数は制限されているが、１つのチャンク内のブロックのすべてにデータを充填する必要はない。

[0041] ベースボリューム２３０は、クライアントホストから格納するよう要求されたチャンクを、ボリュームの開始からある時点まで保持する。本発明によれば、ベースボリューム２３０は、エネルギを節約するためにほとんどの時間にオフにされる（すなわち、ベースボリューム２３０を構成する記憶媒体がオフにされる）。ベースボリューム２３０がパワーオフされる時間中には、バッファボリューム２２０が、仮想ボリューム２１０への格納を最近に要求されたすべてのチャンクを一時的に格納する。クライアントホストの観点からは、バッファボリュームとベースボリュームとの両方が、仮想ボリューム２１０によってカプセル化され、クライアントホストは、仮想ボリューム２１０を、ストレージシステム１００に存在する単一の通常のストレージボリューム（すなわち、論理ユニット）があるかのように見る。したがって、クライアントホスト１１０は、仮想ボリューム１１０にデータを書き込み、仮想ボリューム１１０からデータを読み取り、ストレージシステムのコントローラ１０１は、バッファボリューム２２０およびベースボリューム２３０を管理して、クライアントホストからの要求に応答すると同時に、本発明によるエネルギ節約およびデータデデュプリケーションをも実行する。

[0042] コントローラ上のソフトウェア
[0043] ストレージコントローラ１０１は、デデュプリケーションモジュール２００を含み、デデュプリケーションモジュール２００は、クライアントホスト１１０にデデュプリケーションサービスを提供し、ベースボリューム２３０への電力供給をも制御する、本発明によるソフトウェアプログラムである。デデュプリケーションモジュール２００および本発明の他のソフトウェアは、ＣＰＵ １０２による実行のために、メモリ１０３などのコンピュータ可読媒体に格納される。デデュプリケーションモジュール２００は、クライアントホストによって仮想ボリューム２１０に向けられる読取要求および書込要求を受け入れる。データ書込要求が受け取られる時に、デデュプリケーションモジュール２００は、書込データを１つまたは複数のチャンク２４に分解し、これらのチャンクをバッファボリューム２２０に既に格納されているすべてのチャンク２４０と比較する。既存のチャンクとの一致が見つからない場合には、そのチャンクは、新しいデータパターンであり、デデュプリケーションモジュール２００は、その新しいチャンクをバッファボリューム２２０に格納する。データ読取要求が受け取られる時に、デデュプリケーションモジュール２００は、バッファボリューム２２０またはベースボリューム２３０から、要求されたデータを構成するチャンクを集め、集められたチャンクを一緒に正しい順序で単一のデータストリームとして連結し、要求されたデータをクライアントホストに返す。ストレージ管理者が、ストレージシステムにフラッシュコマンドを送る時に、デデュプリケーションモジュール２００は、ベースボリューム２３０の電力をオンにし、デデュプリケーション処理を同時に実行することによって、バッファボリューム２２０に格納されたチャンクをベースボリューム２３０にマージする。バッファボリュームからベースボリュームへのチャンクのマージが完了した後に、デデュプリケーションモジュール２００は、ベースボリュームへの電力供給をオフにし、バッファボリューム上のチャンクおよび関連するテーブルを初期化する。

[0044] やはり図２に示されているのが、本発明を実行するのに使用される複数のテーブルである。アレイグループテーブル２０１は、デデュプリケーションモジュール２００が、あるアレイグループを構成する記憶媒体１０６の組を突き止めることを可能にするために、アレイグループ情報のレコードを保持する。ボリュームテーブル２０２は、各バッファボリュームおよびベースボリュームと各ボリュームがそこから切り分けられたアレイグループとの間の関係を示すレコードを保持する。さらに、各バッファボリュームおよび各ベースボリュームに関する情報を保持するテーブルの組、すなわち、ハッシュテーブル、ビットマップテーブル、およびマッピングテーブルがある。ハッシュテーブル２０３および２０６は、格納される新しいデータの既存チャンクとの初期比較での使用のために、チャンクごとに生成されるハッシュ値を保持する。ビットマップテーブル２０４および２０７は、各チャンクがバッファボリュームまたはベースボリューム内に実際に格納される位置（たとえば、論理ブロックアドレス）に関する情報を保持する。マッピングテーブル２０５および２０８は、仮想ボリューム上の各論理ブロックアドレス（ＬＢＡ）およびバッファボリュームまたはベースボリューム内の実際のストレージ位置に関するマッピング情報を保持する。これらのテーブルのそれぞれを、下でより詳細に説明する。

[0045] 図３に、アレイグループの識別を提供する、アレイグループＩＤ ５１０を含むアレイグループテーブル２０１の例のデータ構造を示す。媒体ＩＤ ５２０は、アレイグループに含まれる各記憶媒体を識別する。たとえば、行５９１、５９２、および５９３は、アレイグループ「Ａ１」が少なくとも部分的に記憶媒体「Ｍ１」、「Ｍ２」、および「Ｍ３」から構成されることを示すレコードを表す。テーブル２０１は、あるアレイグループ２５０を構成する記憶媒体１０６の組を判定するために、デデュプリケーションモジュール２００によって参照される。

[0046] 図４に、ボリュームのタイプ（たとえば、ボリュームがバッファボリュームまたはベースボリュームのどちらとして使用されるか）を示すタイプ６１０を含む、ボリュームテーブル２０２の例のデータ構造を示す。ボリュームテーブル２０２は、ボリュームの識別を示すボリュームＩＤ ６２０およびボリュームが最初にそこから切り分けられたアレイグループの識別を示すアレイグループＩＤ ６３０をも含む。たとえば、行６９１は、ボリュームＩＤとして「Ｖ１」を有する「ベースボリューム」であり、アレイグループ「Ａ１」から切り分けられたボリュームのレコードを示す。また、行６９２は、ボリュームＩＤとして「Ｖ２」を有し、アレイグループ「Ａ２」から切り分けられた「バッファボリューム」のレコードを示す。テーブル２０２は、特にボリュームへの電力供給を制御する時にベースボリュームについて、ボリュームの起点アレイグループを判定するためにデデュプリケーションモジュール２００によって参照され、電力供給をオフにすることができる記憶媒体を判定するために、アレイグループテーブル２０１と共に使用することができる。

[0047] 図５に、バッファボリュームハッシュテーブル２０３およびベースボリュームハッシュテーブル２０６の例のデータ構造を示す。各ハッシュテーブル２０３および２０６は、下でさらに詳細に説明するように、データ書込処理またはフラッシュ処理中にデデュプリケーションモジュール２００によってめいめいのチャンクから生成されるハッシュ値を示すハッシュ値７１０フィールドおよびハッシュ値に関連するチャンクを識別するチャンクＩＤ ７２０を含む。たとえば、行７９１は、ハッシュ値としての「ＨＶ１」および「Ｃｈ１」のチャンクＩＤを有するチャンクのレコードを表す。希な場合に、同一のハッシュ値が、異なる実際のデータ内容を有するチャンクから生成される可能性がある。たとえば、「Ｃｈ２」の行７９２と「Ｃｈ３」の行７９３との両方に示されたものなどのチャンクが、同一のハッシュ値「ＨＶ２」を有して図示されている。ハッシュテーブル２０３および２０６は、クライアントホストによって格納を新たに要求されたチャンクとバッファボリュームまたはベースボリュームの既存チャンクとの間の初期比較を行う際に使用するためにデデュプリケーションモジュールによって更新され、参照される。

[0048] 図６に、チャンクを識別するチャンクＩＤフィールド８１０を含むビットマップテーブル２０４および２０７の例のデータ構造を示す。このデータ構造には、チャンクの開始アドレスのボリューム上のＬＢＡを与える開始ＬＢＡ ８２０およびチャンク内の有効なブロックの個数をリストするブロック数フィールド８３０も含まれる。たとえば、行８９１は、チャンクＩＤとして「Ｃｈ１」を有し、ボリュームのＬＢＡ「０」から格納され、先頭から「３２個」の有効なブロックを含むチャンクのレコードを示す。デデュプリケーション処理中に、書込要求のデータバイトは、最大個数のブロック（この例では３２個のブロックと仮定する）を有するチャンクに分解される。しかし、されるデータの終りの部分が、この境界に正確におさまらない場合があり、したがって、しばしば、チャンク内に最大ブロック未満の長さがある。したがって、ブロック数８３０は、デデュプリケーションに関する比較処理中にデータをそこまで比較すべき終点を示す。テーブル２０４および２０７は、クライアントホストからの格納を新たに要求されたチャンクとバッファボリュームまたはベースボリューム上の既存チャンクとの間の比較中に各チャンクの内容にアクセスするためにデデュプリケーションモジュール２００によって更新され、参照される。

[0049] 図７に、クライアントホストが書込データを格納することを意図した仮想ボリューム内のＬＢＡを示すＬＢＡフィールド９１０を示すマッピングテーブル２０５および２０８の例のデータ構造を示す。このデータ構造には、チャンクを識別するチャンクＩＤ ９２０およびターゲットブロックがボリュームに格納されるチャンク内のブロックのオフセット数を示すオフセット９３０も含まれる。たとえば、行９９１は、「１００」の仮想ボリュームＬＢＡに格納されたブロックが実際にはチャンク「Ｃｈ１」に格納され、ターゲットブロックが「０」オフセットに置かれることのレコードを表す。また、行９９２は、仮想ボリューム内のＬＢＡ「１０１」が、同一のチャンク「Ｃｈ１」にマッピングされるが、今回は「１」ブロックオフセットにあることを示す。これらのテーブルは、クライアントホストがバッファボリュームまたはベースボリュームに格納されたデータを読み取る要求を行う時に、デデュプリケーションモジュール２００によって更新され、参照される。デデュプリケーションモジュールは、マッピングテーブル２０５および２０８を参照することによって、読取要求によって要求されたすべてのブロックを集める。

[0050] データをバッファボリュームに書き込む処理
[0051] 図８Ａから８Ｃに、バッファボリューム２２０にデータを書き込むためにデデュプリケーションモジュール２００によって実行される処理の例示的実施形態を示す。要約では、この処理は、（ａ）要求されたデータをチャンクサイズの片に分解し、（ｂ）まずハッシュ値を使用することによってチャンクを比較し、（ｃ）一致するハッシュ値が見つかった時には実際のチャンク内容と比較し、（ｄ）内容が新しい場合には新しいチャンクを保存し、（ｅ）仮想ボリュームＬＢＡとバッファボリューム上の実際の位置との間でマッピングするためにマッピングテーブルを更新する。したがって、バッファボリュームにデータを書き込む例示的処理には、次のステップを含めることができる。

[0052] ステップ１５００ 変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」に、クライアントホストによってデータ書込コマンドで指定された仮想ボリューム上の最初のＬＢＡをセットし、ここで、変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」は、仮想ボリューム上の現在のＬＢＡである。この変数は、書込動作および読取動作中に使用するためにデデュプリケーションモジュール２００によって維持される。

[0053] ステップ１５１０ データストリームをチャンクのサイズに分解する。たとえば、上で述べたように、チャンクが３２個のブロックである場合に、書込データは、新しいチャンクを３２ブロックおきに開始することによって分割される。しかし、本発明が、どの特定のサイズのチャンクにも限定されないことに留意されたい。

[0054] ステップ１５２０ ステップ１５１０で分解された分割されたデータ（潜在的な新しいチャンク）の１チャンクサイズの部分を処理のために選択する。新しい書込データのすべての潜在的な新しいチャンクが既に処理されている場合には、この処理は終了し、そうでない場合には、この処理はステップ１５３０に進む。

[0055] ステップ１５３０ ステップ１５２０で選択された潜在的な新しいチャンクからハッシュ値を生成する。使用される特定のハッシュ関数は、本発明にとって本質的ではなく、たとえばＭＤ５など、さまざまな既知のハッシュ関数のどれであっても使用することができる。

[0056] ステップ１５４０ ステップ１５３０で生成されたハッシュ値と同一のハッシュ値（すなわち、新しいデータチャンクと同一のハッシュ値）を有するすべてのレコードをバッファハッシュテーブル２０３から選択する。生成されたハッシュ値と一致するレコードがない場合、またはすべてのレコードを既に処理し終えている場合には、新しいチャンクを生成し、バッファボリュームに格納する必要があり、この処理は、図８Ｂのステップ１５７０に進む。そうではなく、一致するハッシュ値が見つかる場合には、この処理は、直接比較のためにステップ１５５０に進む。

[0057] ステップ１５５０ ステップ１５４０で突き止められた選択されたレコード内で見つかるチャンクＩＤを使用することによって、バッファビットマップテーブル２０４からターゲットチャンク（すなわち、潜在的な新しいチャンクと比較される、既に格納されているチャンク）の開始ＬＢＡおよびブロック数を入手する。この情報は、潜在的な新しいチャンクと同一のハッシュ値を有する既に格納されているチャンクの実際のチャンク内容の場所および長さを示す。

[0058] ステップ１５６０ 潜在的な新しいデータチャンクバイトストリームを、ステップ１５５０で見つかったチャンクと比較する。バイトパターンが一致する場合には、ステップ１６１０に進み、そうでない場合には、ステップ１５４０に戻る。２つのチャンクの内容を互いに直接に（すなわち、バイト対バイト、ビット対ビットなど）比較するさまざまなアルゴリズムおよび／またはハードウェアを、本発明に従って提供することができ、本発明は、直接比較を実行するどの特定の方法または装置にも限定されない。直接比較が、２つのチャンクの内容の間の一致を判定する場合に、これは、バッファボリュームに以前に格納されたチャンクを共用できることと、新しいチャンクを、検査されている分割されたデータの部分（潜在的な新しいチャンク）について作成し、格納する必要がないこととを意味する。したがって、この処理は、この場合に、検査されている分割されたデータの部分（潜在的な新しいチャンク）について、仮想ボリュームＬＢＡから既存チャンクへのマッピング情報を作成するだけでよい。

[0059] ステップ１５７０ ステップ１５４０で、新しいチャンクを作成する必要があると判定されたときには、この処理は、図８Ｂに示されているように、新しいチャンクを追加する。したがって、ステップ１５７０で、この処理は、新しいチャンクのチャンクＩＤ（または、デデュプリケーションモジュールが新しいチャンクの任意の一意のＩＤを作成することができる）およびバッファボリューム内の開始ＬＢＡと共に空のチャンク（未使用チャンク）を入手する。めいめいのチャンクへのボリューム容量の提供は、さまざまな方法によって実行することができる。たとえば、バッファボリュームが当初に割り振られる時に、容量全体のうちの一部またはすべてを、チャンクの最大ブロック数サイズに従ってチャンクに事前に分割することができる。その後、各境界アドレスが、新しい空のチャンクが要求される時に、１つずつ、開始ＬＢＡとして供給される。

[0060] ステップ１５８０ バッファボリューム上のステップ１５７０で入手された開始ＬＢＡによって指定される場所に、新しいチャンクの新しいデータ内容を格納する。

[0061] ステップ１５９０ ステップ１５３０で生成されたハッシュ値およびステップ１５７０で入手されたチャンクＩＤを用いて、バッファハッシュテーブル２０３に新しいレコードを挿入する。

[0062] ステップ１６００ ステップ１５７０で入手されたチャンクＩＤおよび開始ＬＢＡとブロック数に関する格納されたデータ内容の長さとを用いてバッファビットマップテーブル２０４に新しいレコードを挿入する。

[0063] 図８Ｃに示されているように、ステップ１６３０から１６８０は、クライアントホストによって指定された仮想ボリューム上のＬＢＡに従って、マッピングテーブル２０５のレコードを作成し、または更新する。たとえば、ＬＢＡ １００から１３１までの、仮想ボリュームＬＢＡと、チャンクＩＤ ９２０およびオフセット９３０を使用することによるデータが実際の格納された場所との間のマッピング情報を示すレコードである。この処理は、新しいチャンクが作成された場合と、潜在的なチャンクが既存チャンクと一致する内容を有することがわかった場合との両方に使用されるので、ステップ１６３０から１６８０までは、両方の場合に使用される。

[0064] ステップ１６１０ 潜在的な新しいチャンクが、バッファボリューム上の既存チャンクと一致する場合に、この処理は、既存チャンクのチャンクＩＤになるように変数「ｖ＿ｃｈｕｎｋＩＤ」をセットする。変数「ｖ＿ｃｈｕｎｋＩＤ」は、現在処理されているチャンクのチャンクＩＤを追跡するためにデデュプリケーションモジュール２００によって維持される変数である。

[0065] ステップ１６２０ その一方で、新しいチャンクが既存チャンクのどれとも一致しなかった場合には、この処理は、ステップ１５７０で入手されたチャンクＩＤを変数「ｖ＿ｃｈｕｎｋＩＤ」にセットする。

[0066] ステップ１６３０ 変数「ｖ＿Ｏｆｆｓｅｔ」を０に初期化する。変数「ｖ＿Ｏｆｆｓｅｔ」は、現在処理されているチャンクのオフセットを追跡するためにデデュプリケーションモジュール２００によって維持される変数である。

[0067] ステップ１６４０ ＬＢＡが変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」（当初にステップ１５００でセットされた）と一致するレコードをバッファボリュームマッピングテーブル２０５から選択する。レコードが既に存在する場合には、この処理は、ステップ１６６０にスキップして、マッピング情報を変更する。そうでない場合には、この処理は、新しいレコードを作成するために、まずステップ１６５０に進む。

[0068] ステップ１６５０「ｖ＿ＬＢＡｏｎＶＶｏｌ」の値を新しいレコードの「ＬＢＡ」列に置くことによって、バッファマッピングテーブルに新しいレコードを挿入する。

[0069] ステップ１６６０ ステップ１６４０で見つかったレコードまたはステップ１６５０で作成されたレコードのどちらについても、場合に応じてステップ１６１０またはステップ１６２０のいずれかで格納された「ｖ＿ｃｈｕｎｋＩＤ」の値として「チャンクＩＤ」９２０をセットし、ステップ１６３０で確立された「ｖ＿Ｏｆｆｓｅｔ」の値として「オフセット」をもセットする。

[0070] ステップ１６７０「ｖ＿ＬＢＡｏｎＶＶｏｌ」の値を次のＬＢＡブロックに増分し、「ｖ＿Ｏｆｆｓｅｔ」の値をチャンク内の次のブロックに増分する。

[0071] ステップ１６８０ チャンク内のすべてのブロックをマッピングし終えている場合には、この処理は、ステップ１５２０に戻り、新しいデータの次のチャンクを検査する。そうではなく、すべてのブロックがマッピングに関して残っている場合には、この処理は、バッファボリュームマッピングテーブル２０５の次のレコードを更新するためにステップ１６４０に戻る。

[0072] データを読み取る処理
[0073] 図９および１０に、デデュプリケーションモジュール２００によって実行される、バッファボリューム２２０またはベースボリューム２３０のいずれかからデータを読み取る例の処理を示す。この処理は、（ａ）所望のブロックが格納されているボリュームを見つけ、（ｂ）ターゲットブロックがバッファボリューム上にある場合には、バッファボリュームから内容を読み取り、（ｃ）そうではなく、ターゲットブロックがベースボリューム上にある場合には、この処理は、ベースボリュームを構成するストレージデバイスへの電力をオンにし、ベースボリュームから内容を読み取り、（ｄ）読取要求によって要求されたすべてのブロックを集め、データをクライアントホストに返す。

[0074] ステップ１７００ 変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」に、クライアントホストによってデータ読取コマンドで指定された仮想ボリューム上の最初のＬＢＡをセットする。

[0075] ステップ１７１０「ＬＢＡ」が変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」と一致するレコードをバッファマッピングテーブル２０５から選択する。レコードが存在する場合には、これは、ターゲットブロックがバッファボリュームに格納されていることを意味し、ステップ１７２０で、この処理は、図１０に関して下で説明するサブルーチン「特定のボリュームからブロックデータを読み取る」に進む。そうでない場合には、ターゲットブロックは、ベースボリュームに格納されており、この処理は、ステップ１７３０に進む。

[0076] ステップ１７２０ ターゲットブロックがバッファボリューム内に格納されている場合に、この処理は、サブルーチン「特定のボリュームからブロックデータを読み取る」にジャンプして、図１０に示されているように、バッファボリュームから指定されたブロックを読み取るために、バッファボリュームからブロック内容を読み取る。

[0077] ステップ１７３０「ＬＢＡ」が変数ｖ＿ＬＢＡｏｎＶＶｏｌと一致するレコードをベースマッピングテーブル２０８から選択する。このステップは、チャンクＩＤとターゲットブロックがベースボリューム内に格納されているオフセットとを見つけるためのものである（レコードが存在する場合には、ステップ１７１０で、バッファボリュームに関する同一の情報が見つかる）。

[0078] ステップ１７４０ ベースボリューム２３０がパワーオフされている場合には、この処理は、ベースボリュームを構成する記憶媒体１０６の電力をオンにする。オンにする必要がある記憶媒体１０６の判定は、まずベースボリュームのアレイグループＩＤを見つけるためにボリュームテーブル２０２を参照し、次に識別されたアレイグループを構成する記憶媒体１０６を判定するためにアレイグループテーブル２０１を参照することによって実行することができる。

[0079] ステップ１７５０ ベースボリュームがパワーオンされたならば、この処理は、ベースボリューム２３０からブロック内容を読み取るために、図１０に示されたサブルーチン「特定のボリュームからブロックデータを読み取る」にジャンプする。

[0080] ステップ１７６０ 変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」の値を次のＬＢＡに増分する。

[0081] ステップ１７７０ すべてのターゲットブロックが見つかっている場合には、この処理はステップ１７８０に進む。そうでない場合には、この処理は、ステップ１７１０に戻って、読取要求の次のブロックを集める。

[0082] ステップ１７８０ 集められたブロックを、読取要求に応答してクライアントホストに返す。

[0083] ステップ１７９０ ベースボリューム２３０が読取要求に応答するためにパワーオンされた場合には、指示を送って、ベースボリューム２３０を構成する記憶媒体１０６をオフにする。

[0084] 図１０は、バッファボリュームまたはベースボリュームからデータを読み取る、図９の処理内のサブルーチンである。したがって、図１０の処理は、特定のボリュームから（すなわち、バッファボリューム２２０またはベースボリューム２３０のいずれかから）ブロックデータを読み取る。バッファボリュームからブロックを読み取る場合のステップとベースボリュームからブロックを読み取る場合のステップとの間には差がないので、図１０に示されたステップは、両方の場合にあてはまる。このサブルーチンが呼び出される前に、ターゲットブロックのチャンクＩＤ ９２０およびオフセット９３０を保持するマッピングテーブル２０５および２０８のレコードが、前のステップ（すなわち、ステップ１７１０または１７３０）で見つけられている。

[0085] ステップ１８００ それぞれステップ１７１０または１７３０で選択されたマッピングテーブル２０５または２０８の選択されたレコードから「チャンクＩＤ」９２０および「オフセット」値９３０を入手する。

[0086] ステップ１８１０ ステップ１８００で入手されたものと同一のチャンクＩＤを有するレコードをめいめいのビットマップテーブル２０４または２０７から選択する。

[0087] ステップ１８２０ ステップ１８１０でのビットマップテーブル２０４または２０７の選択されたレコードから「開始ＬＢＡ」値を入手し、ステップ１８００で入手された「オフセット」値を加算する。これは、特定のボリュームすなわちバッファボリュームまたはベースボリューム上のターゲットブロックのアドレスになる。

[0088] ステップ１８３０ オフセットを使用して判定される計算されたＬＢＡのブロックからデータを読み取る。データは、ＬＢＡから読み取られ、好ましくは、コントローラ１０１のメモリ１０３などのキャッシュに格納されて、要求された読取データの残りと正しい順序で連結される。

[0089] バッファをフラッシュする処理
[0090] 図１１Ａから１１Ｃに、デデュプリケーションモジュール２００によって実行される、バッファボリューム上のバッファリングされたチャンクをフラッシュする例の処理を示す。この処理は、（１）ベースボリュームをオンにし、（２）バッファボリューム上でバッファリングされたチャンクごとに、ハッシュ値をベースボリュームに既に格納されているチャンクのハッシュ値と比較し、（３）一致が見つかる場合には、チャンクの内容を既に格納されているチャンクの実際の内容と比較し、（４）バッファボリュームからの新しいチャンクがベースボリューム上のどのチャンクとも一致しない場合には、新しいチャンクをベースボリュームに追加し、（５）ベースボリュームのマッピングテーブル２０８を更新し、（６）ベースボリュームをオフにし、（７）フラッシュの後にバッファボリュームおよび関連するテーブルを初期化する。

[0091] ステップ１９００ ベースボリューム２３０を構成するのに使用される記憶媒体をオンにする。たとえば、バッファボリュームがアレイグループから作成される場合には、そのアレイグループを構成する記憶媒体が、コントローラ１０１によってパワーオンされる。

[0092] ステップ１９１０ バッファハッシュテーブル２０３からレコードを選択する。すべてのレコードを処理し終えた場合には、この処理はステップ２０７０に進み、そうでない場合には、この処理は、現在のレコードを処理するためにステップ１９２０に進む。

[0093] ステップ１９２０ ステップ１９１０で入手されたレコード（バッファボリュームから選択されたレコード）と同一のハッシュ値を有するすべてのレコードをベースハッシュテーブル２０６から検索し、選択する。ベースハッシュテーブル内のどのレコードも、バッファハッシュテーブルから選択された現在のレコードのハッシュ値と一致しない場合、または一致するすべてのレコードを処理し終えている場合には、この処理は図１１Ｂのステップ１９６０に進み（すなわち、この処理は、ベースボリューム上で新しいチャンクを作成する必要がある）、そうでない場合には、この処理はステップ１９３０に進む。

[0094] ステップ１９３０ ステップ１９２０でベースハッシュテーブルから入手されたレコードと同一のチャンクＩＤ ８１０を有するレコードからのベースビットマップテーブル２０７から開始ＬＢＡ８２０およびブロック数８３０を入手する。

[0095] ステップ１９４０ 同一の形で、ステップ１９１０でバッファハッシュテーブル２０３から選択されたレコードと同一のチャンクＩＤ ８１０を有するレコードからのバッファビットマップテーブル２０４から開始ＬＢＡ８２０およびブロック数８３０を入手する。

[0096] ステップ１９５０ ベースボリュームから選択されたチャンク（そのアドレスはステップ１９３０で判定された）およびバッファボリュームから選択されたチャンク（そのアドレスはステップ１９４０で判定された）の内容を比較する。上で述べたように、任意の複数の方法を、ビット対ビット比較、バイト対バイトなど、チャンクの内容の直接比較に使用することができる。２つのチャンクの内容が一致する場合には、新しいチャンクを格納する必要はなく、この処理は、マッピングテーブル２０８を更新するために図１１Ｃのステップ２０１０に進む。そうではなく、２つのチャンクの内容が一致しない場合には、この処理は、いずれかの他の一致するハッシュ値（通常は希な発生）との比較のためにステップ１９２０に戻る。バッファボリュームから現在選択されているチャンクのハッシュ値と一致するハッシュ値を有するベースボリュームハッシュテーブル２０６内の他のレコードがない場合には、この処理は、図１１Ｂのステップ１９６０に進むが、このステップを次に説明する（図１１Ａのステップ２０７０から２０９０までは、下で説明する）。

[0097] ステップ１９６０ 図１１Ｂを参照すると、この処理は、空のチャンクと、選択された空のチャンクのチャンクＩＤ（またはその代わりに、デデュプリケーションモジュールがチャンクＩＤとして使用される任意の一意のＩＤを作成することができる）およびベースボリューム上の選択された空のチャンクの開始ＬＢＡとを入手する。

[0098] ステップ１９８０ バッファボリュームチャンク（その開始ＬＢＡおよびブロック数はステップ１９４０で入手された）のデータ内容をステップ１９６０で入手されたベースボリュームの空のチャンクにコピーする。

[0099] ステップ１９９０ ステップ１９１０で選択された（バッファハッシュテーブル２０３から）バッファボリュームレコードのハッシュ値７１０およびステップ１９６０で入手されたチャンクＩＤを用いて、新しいレコードをベースボリュームハッシュテーブル２０６に挿入する。

[0100] ステップ２０００ ステップ１９６０で入手されたチャンクＩＤおよび開始ＬＢＡとブロック数に関するステップ１９８０からの格納されたデータ内容ブロック長とを用いてベースビットマップテーブル２０７に新しいレコードを挿入する。その後、この処理は図１１Ｃに進む。図１１Ｃには、２つの場合すなわち、（ａ）ベースボリュームに既に格納されているチャンクと一致するチャンクがあった場合、および（ｂ）新しいチャンクを格納しなければならない場合の、マッピングテーブルを更新する処理が示されている。

[0101] ステップ２０１０ 選択されたバッファボリュームチャンクが、既に格納されているベースボリュームチャンクと一致する場合には、この処理は、ステップ１９２０で入手されたチャンクＩＤを変数「ｖ＿ＢａｓｅＣｈｕｎｋＩＤ」にセットする。これは、デデュプリケーションモジュール２００によって維持される変数である。

[0102] ステップ２０２０ その一方で、バッファボリュームチャンクが、ベースボリュームに既に格納されているどのチャンクとも一致しない場合には、この処理は、ステップ１９６０で入手されたチャンクＩＤ（すなわち、新しい空のチャンクＩＤ）を変数「ｖ＿ＢａｓｅＣｈｕｎｋＩＤ」にセットする。

[0103] ステップ２０３０「チャンクＩＤ」がステップ１９１０で入手されたレコード（バッファハッシュテーブル２０３からの）と同一であるレコードをバッファマッピングテーブルから選択する。現在のチャンクのすべてのレコードが処理済みである場合には、この処理は図１１Ａのステップ１９１０に戻って、バッファボリューム上の次のチャンクを処理する。そうでない場合には、この処理は、ステップ２０４０に継続する。さらに、ステップ２０３０は、チャンク内の最大個数のブロックと同一の個数のレコードを必ず集めるわけではない。たとえば、バッファボリューム上のチャンクのバッファリング中に、ＬＢＡ １００、１０１、および１０２がチャンクＸにマッピングされるが、少し後に、別のチャンクＹが、ＬＢＡ １０１、１０２、および１０３のマッピング情報を更新することによって、このマッピング情報の一部を上書きする場合がある。この場合に、ＬＢＡ １００のレコードだけが、チャンクＸのチャンクＩＤを有する。したがって、ステップ２０３０の結果が、可能な最大値より少ない個数のレコードになる場合がある。これが重要なのは、ステップ２０６０で、下で説明するように、ベースボリュームの有効なマッピング情報だけが更新されるからである。

[0104] ステップ２０４０「ＬＢＡ」がステップ２０３０で選択されたレコードと同一であるレコードをベースマッピングテーブル２０８から検索する。レコードが既に存在する場合には、この処理はステップ２０６０に進んで、突き止められたＬＢＡのマッピング情報を変更する。そうではなく、レコードがまだ存在しない場合には、この処理は、新しいレコードを作成するためにステップ２０５０に進む。

[0105] ステップ２０５０ ステップ２０３０で選択されたレコードの「ＬＢＡ」値を追加することによって、ベースマッピングテーブル２０８に新しいレコードを挿入する。

[0106] ステップ２０６０ ステップ２０４０で見つかったレコードまたはステップ２０５０で作成されたレコードのいずれかについて、この処理は、場合に応じてステップ２０１０またはステップ２０２０のいずれかで格納された「ｖ＿ＢａｓｅＣｈｕｎｋＩＤ」の値になるように「チャンクＩＤ」をセットし、また、ステップ２０３０で選択されたレコードの値（すなわち、そのレコードのバッファマッピングテーブル２０５に格納された値）になるように「オフセット」をセットする。２０６０の完了に続いて、この処理は、選択されたレコードと同一のチャンクＩＤを有するバッファマッピングテーブル２０５からのさらなるレコードの処理のためにステップ２０３０に戻る。レコードがもうないときには、この処理は、図１１Ａのステップ２０７０から２０９０に戻る。

[0107] ステップ２０７０ この処理は、コントローラに、ベースボリュームに関連する記憶媒体をオフにするように指示する。

[0108] ステップ２０８０ バッファボリュームを初期サイズに縮小する。好ましい実施形態では、縮小可能なボリュームが、本発明のバッファボリューム２２０に使用される。たとえば、その開示が参照によって本明細書に組み込まれている２００４年２月２３日出願のＫａｎｏ他の米国特許出願公告第２００４／０１６２９５８号、名称「Ａｕｔｏｍａｔｅｄ Ｏｎ−Ｌｉｎｅ Ｃａｐａｃｉｔｙ Ｅｘｐａｎｓｉｏｎ Ｍｅｔｈｏｄ ｆｏｒ Ｓｔｏｒａｇｅ Ｄｅｖｉｃｅ」で教示されているように、使用時割振り（ａｌｌｏｃａｔｉｏｎ−ｏｎ−ｕｓｅ）テクノロジを使用して、バッファボリュームのサイズを管理することができる。バッファリングされたチャンクのすべてが、フラッシュ動作中にベースボリュームの容量にマージされるので、バッファボリューム２２０の容量を、適切な最小限の初期容量に大幅に減らすことができる。

[0109] ステップ２０９０ バッファボリューム上の対応するチャンクのすべてが、ベースボリューム２３０にマージされているので、バッファハッシュテーブル２０３、バッファビットマップテーブル２０４、およびバッファマッピングテーブル２０５上のレコードを削除する。

[0110] 第２実施形態
[0111] 上で示した第１実施形態では、バッファボリュームからバッファリングされたチャンクをフラッシュする処理は、ストレージ管理者の判断によって、あるいは所定の時間期間の経過、バッファボリュームが所定のサイズ限度に達すること、または他のそのようなイベントなどのある他のトリガするイベントによって明示的にトリガされる。下で説明する第２実施形態では、バッファボリュームは、ベースボリュームからデータを読み取る処理が開始される時に必ず自動的にフラッシュされ、この読取は、ある種のストレージシステム環境では非常に頻繁には発生しない可能性がある。ベースボリュームに対するデータ読取動作が行われる時に、ストレージコントローラは、ベースボリュームをオンにする必要がある。ディスクドライイブのスピンアップは、その間にそれに比例して最大量の電力が必要になる時間なので、ディスクアレイをオンにし、オフにすることを繰り返さないことが望ましい。したがって、これは、バッファボリュームフラッシュ処理を実行するのに効率的な時でもある。というのは、エネルギが、システムパワーアップで既に消費されているからである。構成要素および挙動のほとんどは、第１実施形態で説明したものと同一である。したがって、下では相違を説明する。

[0112] データ読取と共にバッファをフラッシュする処理
[0113] 図１２に、デデュプリケーションモジュール２００によって実行される、データ読取処理と共にバッファリングされたチャンクをフラッシュする処理の例を示す。処理のほとんど（すなわち、ステップ１７００から１７８０まで）は、第１実施形態の図９に示されたものと同一であるが、最後の部分は、フラッシュ処理を呼び出すためにわずかに変更されている。フラッシュ処理自体は、ステップ２１１０で実行されるが、第１実施形態で図１１Ａから１１Ｃに示した処理と異ならない。したがって、フラッシュ処理を呼び出すべき時だけが、図１２に示された処理に示されている。

[0114] ステップ２１００ ステップ１７８０で集められたブロックを読取要求に応答して返した後に、この処理は、ベースボリュームがパワーオンされているかどうかを判定する。ベースボリュームがパワーオンされている（すなわち、いくつかのデータがベースボリュームから読み取られた）場合には、この処理は、ステップ２１１０に進んでバッファをフラッシュする。そうではなく、ベースボリュームが、読取要求に応答してパワーオンされてはいない場合には、この処理は終了する。

[0115] ステップ２１１０ バッファボリューム上のすべてのバッファリングされたチャンクのフラッシュは、第１実施形態で図１１Ａ〜１１Ｃに関して上で説明したように行われる。

[0116] ステップ２１２０ フラッシュ処理の完了の後に、この処理は、コントローラに、ベースボリュームを構成するのに使用される記憶媒体をオフにするように指示する。

[0117] 第３実施形態
[0118] 第３実施形態では、図１３に示されているように、それぞれ別々のアレイグループ２５０−１、２５０−２…２５０−Ｎ上に、複数のベースボリューム２３０−１、２３０−２…２３０−Ｎが設けられる。これらの実施形態は、たとえば、格納されるチャンクの個数がますます多くなり、その結果、複数のベースボリュームが、膨大な量の格納されるチャンクを処理するのに必要になる可能性がある情況で適用可能とすることができる。ベースボリュームが非常に大きく、多数のストレージデバイスを必要とする情況では、新しいチャンクコピーがその代わりに比例して少数の記憶媒体を有し、したがってより少ないエネルギ使用量を有する、複数のベースボリュームのうちの１つだけに対して実行できる場合に、フラッシュ処理および／または読取処理中にベースボリュームをオンにすることは、電力効率がよくはない。したがって、第３実施形態では、特定の時にバッファリングされたチャンクのコピーのターゲットになる特定のベースボリュームだけをオンにし、残りのベースボリュームをオフにされたままにする方法の例を説明する。構成要素および挙動のほとんどは、第１実施形態で説明したものと同一である。したがって、下では相違を説明する。

[0119] 論理要素の構造
[0120] 図１３に、第３実施形態のソフトウェアおよび論理要素の構造を示す。第３実施形態では、大量のチャンクのストレージを処理するために複数のベースボリューム２３０−１…２３０−Ｎがある。各ベースボリュームは、それぞれ別々のアレイグループ２５０−１…２５０−Ｎに属さなければならず、これは、各ベースボリュームへの電力供給を独立に制御できるようにするために、記憶媒体１０６の別々の組がベースボリュームごとに使用されることを意味する。さらに、バッファボリュームは、第１実施形態と同様に、別々のアレイグループ２５０−０上でも構成される。他の実施形態では複数のバッファボリューム２２０を設けることもできるが、１つのバッファボリューム２２０だけが、図示の実施形態に十分であると仮定する。フラッシュ処理中に、バッファボリューム２２０上のチャンクが、ベースボリューム２３０のうちの、通常はすべてではなく、１つまたはいくつかにマージされる。デデュプリケーションモジュール２００によって使用されるコントローラ１０１上のテーブルに関して、異なるボリュームテーブル２９０が設けられ、ベースハッシュテーブル、ベースビットマップテーブル、およびベースマッピングテーブルの複数の組は、めいめいのベースボリュームについて必要ではない。そうではなく、変更されたベースハッシュテーブル２９３およびベースビットマップテーブル２９２が、すべてのベースボリューム２３０の統合された情報を保持する。第１実施形態のベースマッピングテーブル２０８を、本実施形態で使用することができる。

[0121] データ構造
[0122] 図１４に、第３実施形態のボリュームテーブル２９０の例のデータ構造を示す。すべての列６１０、６２０、および６３０が、第１実施形態で図４に関して上で説明したものと同一の意味を有する。しかし、この実施形態では、ベースボリュームの複数のレコードがある。たとえば、行２２９２は、ベースボリューム「Ｖ１」のレコードであり、それと同時に、テーブル２９０には、レコード２２９３に示されているように、ベースボリューム「Ｖ２」など、システム内に存在する他のベースボリュームがあることが示されている。

[0123] 図１５に、この実施形態のバッファボリュームハッシュテーブル２９１およびベースボリュームハッシュテーブル２９３の例のデータ構造を示す。バッファハッシュテーブル２９１とベースハッシュテーブル２９３との両方が、同一のデータ構造を有し、したがって単一の図に示されている。しかし、新たに追加された列であるベースボリュームＩＤ ２３３０の使用法は、これらの間で異なるが、他の列７１０および７２０は、第１実施形態で図５を参照して上で説明したものと同一の意味を有する。

[0124] バッファハッシュテーブル２９１は、このレコードのバッファボリュームチャンクと同一のハッシュ値７１０を有するチャンクを格納するベースボリュームを識別するのにベースボリュームＩＤ列２２３０を使用する。この情報は、フラッシュ処理中に、パワーオンすべきベースボリュームを選択するのに使用される。というのは、バッファリングされたチャンクとの比較に使用されるベースボリューム２３０だけがオンにされ、残りのベースボリュームは、この実施形態ではオフにされたままに保たれるからである。ベースボリュームＩＤは、バッファリングされたチャンクのハッシュ値が既にベースハッシュテーブルに格納されている場合に、データをバッファボリュームに書き込むデータ書込処理中にセットされる。また、新しいバッファボリュームチャンクのために生成されたハッシュ値が、どのベースハッシュテーブルレコードとも一致しない場合に、この値は、ベースボリュームＩＤ列２３３０でＮＵＬＬとしてセットされる。

[0125] ベースハッシュテーブル２９３は、対応するチャンクが格納される特定のベースボリューム２３０を識別するのにベースボリュームＩＤ列２３３０を使用する。たとえば、行２３９１は、ハッシュ値７１０としての「ＨＶ１」および「Ｃｈ１」のチャンクＩＤ ７２０を有する、ベースボリュームに格納されたチャンクのレコードを表すが、このチャンクはベースボリューム「ＢＶ１」に格納される。さらに、異なるベースボリューム２３０上の複数のチャンクが、いくつかの場合に同一のハッシュ値を有することができることに留意されたい。たとえば、行２３９２および２３９３は、これらの両方が同一のハッシュ値「Ｈ２」およびバッファリングされたチャンクＩＤを有するが、そのベースボリュームＩＤは、可能な一致するチャンクが存在する場合に、ベースボリュームＩＤ「ＢＶ３」および「ＢＶ５」として異なることを示す。また、「ベースボリュームＩＤ」列に「ＮＵＬＬ」値を有することは、バッファハッシュテーブル２９１に固有の事例なので、これは図１５には示されていない。

[0126] 図１６に、この実施形態のベースボリュームビットマップテーブル２９２の例のデータ構造を示す。チャンクＩＤ ８１０およびブロック数８３０の列は、第１実施形態で上で説明したものと同一の意味を有する。さらに、バッファビットマップテーブル２０４のデータ構造は、第１実施形態で示されたものからの相違を有しない。図１６では、ベースビットマップテーブル２９２は、識別されたチャンクが格納されているベースボリュームの識別をもたらすベースボリュームＩＤ列２４１０を含む。開始ＬＢＡ列２４２０は、特定のベースボリューム上の識別されたチャンクの開始アドレスを示す。たとえば、行２４９１は、チャンクＩＤ ８１０として「Ｃｈ１」を有するチャンクのレコードを表し、このチャンクは、ベースボリューム「ＢＶ１」のＬＢＡ「０」から開始して格納され、ブロックの有効な個数は、先頭から「３２」個のブロックである。その一方で、行２４９３は、やはり「０」から始まる「開始ＬＢＡ」を有するが、これは、ベースボリューム「ＢＶ３」に関する。

[0127] データをバッファボリュームに書き込む処理
[0128] 図１７に、デデュプリケーションモジュール２００によって実行される、バッファボリューム２２０にデータを書き込む例の処理を示す。この処理のほとんどは、第１実施形態の図８Ａ、８Ｂ、および８Ｃで示したものと同一のステップを使用する。したがって、新しいデータがバッファボリューム上の空のチャンクに格納された後に新しいチャンクを追加する部分の間など、異なる部分だけを説明すればよい。

[0129] ステップ１５００〜１５８０は、図８Ａおよび８Ｂに関して上で説明したものと同一である。したがって、空のチャンクが入手されており、書込データの内容が、バッファボリューム２２０上の空のチャンクに格納される。

[0130] ステップ２５００ この処理は、図８Ａのステップ１５３０で入手されたものと同一のハッシュ値（すなわち、現在検査されている新しい書込データから生成されたハッシュ値）を有するレコードをベースハッシュテーブル２９３から検索する。一致するハッシュ値を有するレコードが見つからない場合には、この処理はステップ２５３０に進む。そうではなく、一致するハッシュ値が見つかる場合には、この処理はステップ２５１０に進む。

[0131] ステップ２５１０ ステップ１５３０で生成されたハッシュ値、ステップ１５７０で入手されたチャンクＩＤ、およびステップ２５００で選択されたレコードから入手されたベースボリュームＩＤを使用して、新しいレコードをバッファハッシュテーブル２９１に挿入する。

[0132] ステップ２５２０ ステップ２５００で突き止められたすべてのレコードを処理し終えた場合には、この処理は１６００に進む。そうではなく、ハッシュ値と一致するベースボリュームハッシュテーブル内の別のレコードがある場合には、この処理は、ステップ２５００に戻って、残りのレコードを処理する。

[0133] ステップ２５３０ 一致するレコードが、ステップ２５００でハッシュ値に関して突き止められない場合に、この処理は、ステップ２５３０に進んで、ステップ１５３０で生成されたハッシュ値、ステップ１５７０で入手されたチャンクＩＤについて、ベースボリュームＩＤに「ＮＵＬＬ」を使用して（これによって、同一のハッシュ値を有する対応するチャンクがどのベースボリュームにも以前に格納されていないことを示す）バッファハッシュテーブル２９１に新しいレコードを挿入する。

[0134] ステップ２５２０またはステップ２５３０の完了の後に、この処理は、上で第１実施形態で説明した、バッファビットマップテーブル２０４に新しいレコードを挿入するステップ１６００に進み、この処理の残りは、上で図８Ｃで説明した通りである。

[0135] データを読み取る処理
[0136] 図１８および１９に、デデュプリケーションモジュール２００によって実行される、バッファボリューム２２０またはベースボリューム２３０のうちの１つのいずれかからデータを読み取る処理の例を示す。ステップのほとんどは、上で図９および１０に関して説明したものと同一である。

[0137] ステップ１７００ 変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」に、クライアントホストによってデータ読取コマンドで指定された仮想ボリューム上の最初のＬＢＡをセットする。

[0138] ステップ１７１０「ＬＢＡ」が変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」と一致するレコードをバッファマッピングテーブル２０５から選択する。レコードが存在する場合には、これは、ターゲットブロックがバッファボリュームに格納されていることを意味し、ステップ１７２０で、この処理は、図１０に関して上で説明したサブルーチン「特定のボリュームからブロックデータを読み取る」に進む。そうでない場合には、ターゲットブロックは、ベースボリュームに格納されており、この処理は、ステップ２６００に進む。

[0139] ステップ１７２０ ターゲットブロックがバッファボリューム内に格納されている場合に、この処理は、サブルーチン「バッファボリュームからブロックデータを読み取る」にジャンプして、バッファボリュームからブロック内容を読み取る。このサブルーチンは、図１０に示され、バッファボリュームからの指定されたブロックの読取についてその図に関して上で説明したものと同一である。

[0140] ステップ２６００ ターゲットブロックがベースボリューム２３０のうちの１つに格納されている場合には、この処理は、「ＬＢＡ」が変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」と一致するレコードをベースマッピングテーブル２０８から選択する。このステップは、ターゲットブロックがベースボリューム内に格納されているチャンクＩＤおよびオフセットを見つけるためのものである。

[0141] ステップ２６１０「チャンクＩＤ」８１０がステップ２６００で見つかった値と同一であるレコードの「ベースボリュームＩＤ」をベースビットマップテーブル２９２から選択する。

[0142] ステップ２６２０ 記憶媒体が、ステップ２６１０で突き止められた「ベースボリュームＩＤ」によって識別される特定のベースボリューム２３０についてパワーオフされている場合に、これらの記憶媒体をオンにするために指示をコントローラ１０１に送る。オンにする必要がある記憶媒体を判定するために、この処理は、まずその特定のベースボリュームの特定のアレイグループＩＤを見つけるためにボリュームテーブル２９０を参照し、この処理は、次にアレイグループテーブル２０１からその特定のアレイグループを構成する記憶媒体を見つける。

[0143] ステップ２６３０ 図１９に示されたサブルーチン「ベースボリュームからブロックデータを読み取る」にジャンプして、ベースボリュームからブロック内容を読み取る。このサブルーチンは、図１９に関して下で詳細に説明する。

[0144] ステップ１７６０ 変数「ｖ＿ＬＢＡｏｎＶＶｏｌ」の値を次のＬＢＡに増分する。

[0145] ステップ１７７０ すべてのターゲットブロックが見つかっている場合には、この処理はステップ１７８０に進む。そうでない場合には、この処理は、ステップ１７１０に戻って、読取要求の次のブロックを集める。

[0146] ステップ１７８０ 集められたブロックを、読取要求に応答してクライアントホストに返す。

[0147] ステップ１７９０ ベースボリューム２３０のいずれかが読取要求に応答するためにパワーオンされた場合には、指示を送って、パワーオンされたベースボリューム２３０を構成する記憶媒体１０６をオフにする。この実施形態では、複数のベースボリュームのうちの１つまたは一部だけがオンにされる場合がある。

[0148] 図１９は、ベースボリュームの１つからデータを読み取る、上で説明した処理内のステップ２６３０中に実行されるサブルーチンである。ステップ１８００〜１８２０は、図１０に示され、第１実施形態に関して上で説明したものと同一である。したがって、最後のステップすなわちステップ２７００だけが異なる。

[0149] ステップ２７００ この処理が、開始ＬＢＡを判定し、オフセットを加算して、特定のベースボリュームの実際のＬＢＡを入手されたならば、この処理は、図１８のステップ２６１０で見つかった特定のベースボリュームからステップ１８２０で計算されたＬＢＡのブロックからデータを読み取る。

[0150] バッファをフラッシュする処理
[0151] 図２０Ａから２０Ｄに、デデュプリケーションモジュール２００によって実行される、第３実施形態でバッファリングされたチャンクをバッファボリュームからフラッシュする処理の例を示す。第３実施形態では、ベースボリュームをオンにする処理が、第１実施形態と異なる。というのは、バッファリングされたチャンクと比較される必要があるチャンクを有する特定のベースボリュームだけをオンにする必要があるからである。上で述べたように、バッファボリュームのフラッシュは、管理者指示の結果として、あるいは、所定の時間期間の経過またはバッファボリュームの容量が所定の量を超えることなど、ある他のトリガイベントの際に行うことができる。

[0152] ステップ２８００ 図２０Ａを参照すると、この処理は、バッファハッシュテーブル２９１から「ベースボリュームＩＤ」を選択する。これは、この処理が、一致するチャンクを有する候補としてマークされたベースボリュームがあることを示すレコードを選択することを意味する。候補ベースボリュームがパワーオンされている場合には、この処理はステップ２８２０に進む。そうでない場合には、この処理はステップ２８１０に進んで、バッファハッシュテーブル２９１にリストされた候補ベースボリュームをパワーオンする。

[0153] ステップ２８１０ ステップ２８００で選択されたレコードの「ベースボリュームＩＤ」によって指定されるベースボリュームがパワーオフされている場合には、指示をコントローラ１０１に送って、その候補ベースボリュームをオンにする。

[0154] さらに、バッファハッシュテーブル２９１の１つまたは複数のエントリが「ＮＵＬＬ」である場合、または直接データ比較が、チャンクがまだどのベースボリュームにも格納されていないことを示す場合に、これは、１つまたは複数の新しいチャンクをベースボリュームに保存する必要があることを意味し、適切なベースボリュームを選択しなければならない。この例では、ベースボリュームがほぼ同一のサイズを有すると仮定して、最も利用されていないベースボリュームが、新しいチャンクを格納するために選択される（すなわち、最小量のデータが現在格納されているベースボリューム）。他の実施形態では、ベースボリュームが総容量においてかなり異なるときなど、最大の残り容量を有するベースボリュームを選択することができる。代替メトリックスを使用して、新しいチャンクの格納に使用すべきベースボリュームを決定することもできる。ステップ２８２０から２８４０は、最低の利用度を有するベースボリュームを突き止めることを対象とする。

[0155] ステップ２８２０ タイプ６１０が「ベース」であるレコードの「ボリュームＩＤ」をボリュームテーブルから選択する。ボリュームテーブル２９０内のすべてのベースボリュームの利用度が既に検査済みである場合には、この処理は、ステップ２８５０に進み、そうでない場合には、この処理はステップ２８３０に進む。

[0156] ステップ２８３０ 選択されたベースボリュームの使用済みサイズを入手する。ボリュームに既に格納されているデータの量を入手する能力は、従来からほとんどのストレージシステムに備わっている能力である。

[0157] ステップ２８４０ ステップ２８３０で見つけたサイズが、これまでで最小のサイズである場合には、この処理は、新しいチャンクを格納する候補としてそのベースボリュームＩＤを保持する。

[0158] ステップ２８５０ ステップ２８４０で最終的に選択されたベースボリュームが、パワーオンされていない場合には、この処理は、指示を送ってこのベースボリュームをオンにし、そのボリュームＩＤを変数「ｖ＿ＬｏｗＵｓａｇｅＶｏｌ」にセットするが、この変数は、デデュプリケーションモジュール２００によって維持される変数である。「ハッシュ値を用いて比較する」および「チャンクを用いて比較する」の間のステップ１９１０、１９２０、１９４０、および２０７０〜２０９０は、上で図１１Ａを参照して第１実施形態で説明したものと同一である。したがって、異なるステップすなわち、ステップ２９００および２９１０だけを、下で説明する。この実施形態では、チャンク内容の比較のために実行される処理中のターゲットとして特定のベースボリュームを選択することが必要である。

[0159] ステップ２９００ ステップ１９２０で入手されたレコードと同一のチャンクＩＤを有するレコードのベースビットマップテーブル２９２から、開始ＬＢＡ ２４２０、ブロック数８３０、およびベースボリュームＩＤ ２４１０をも入手する。

[0160] ステップ２９１０ バッファボリューム内のチャンクの内容を、ステップ２９００で見つかったベースボリュームＩＤによって指定されるベースボリューム上のチャンクの内容と比較する。内容が一致する場合には、マッピングテーブル２０８を更新するためにステップ２０１０に進む。そうではなく、内容が一致しない場合には、この処理は、ステップ１９２０に戻って、次のレコードと比較する。このチャンクと比較するレコードがもうない場合には、この処理は、ステップ３０００に進んで新しいチャンクを追加する。ベースボリュームに新しいチャンクを追加するステップ中に、この実施形態は、この例では、上のステップ２８２０から２８４０で選択された最低利用度ボリュームを使用する。

[0161] ステップ３０００ ステップ２８５０で突き止められ、セットされた変数「ｖ＿ＬｏｗＵｓａｇｅＶｏｌ」によって指定されるベースボリュームから、空のチャンク、チャンクＩＤ（または、デデュプリケーションモジュールが空のチャンクの任意の一意のＩＤを作成することができる）、およびその開始ＬＢＡを入手する。

[0162] ステップ１９８０ バッファボリュームチャンク（その開始ＬＢＡおよびブロック数はステップ１９４０で入手された）のデータ内容をステップ３０００で入手されたベースボリュームの空のチャンクにコピーする。

[0163] ステップ３０１０ ステップ１９１０で選択された（バッファハッシュテーブル２０３から）レコードのハッシュ値およびステップ３０００で入手されたチャンクＩＤと、変数「ｖ＿ＬｏｗＵｓａｇｅＶｏｌ」からのベースボリュームＩＤをも用いて、新しいレコードをベースハッシュテーブル２９３に挿入する。

[0164] ステップ３０２０ ステップ３０００で入手されたチャンクＩＤおよび開始ＬＢＡとブロック数に関するステップ１９８０から入手された格納されたデータ内容長と変数「ｖ＿ＬｏｗＵｓａｇｅＶｏｌ」からのベースボリュームＩＤとを用いてベースビットマップテーブル２９２に新しいレコードを挿入する。

[0165] 最後に、ベースマッピングテーブル２０８を更新するステップ中に、下で説明するステップ３１００を除いて、ステップ２０１０および２０３０〜２０６０は、上で図１１Ｃを参照して第１実施形態で説明したものと同一である。

[0166] ステップ３１００ ステップ２９１０でのチャンク内容の比較が一致しなかった場合には、この処理は、上のステップ３０００で入手されたチャンクＩＤを変数「ｖ＿ＢａｓｅｃｈｕｎｋＩＤ」にセットする。

[0167] ベースボリュームのうちの１つに対する読取要求中が、第３実施形態では必ずしもフラッシュ処理を行うのに効率的な時ではないことに留意されたい。というのは、ベースボリュームのうちの１つだけがそのような要求に応答してオンにされ、他のベースボリュームがパワーオフされたままである場合があるからである。しかし、上で第３実施形態に関して示した処理の代替案では、フラッシュ処理を、オンにされているベースボリューム内のチャンクだけと比較される必要があるバッファボリューム内のチャンクだけに適用することができる。バッファボリューム内のチャンクが新しいチャンクである場合に、その新しいチャンクを、オンにされているベースボリュームに格納することができ、あるいは、別のベースボリュームが次にオンにされる時にその別のベースボリュームに格納するためにマークすることができる。

[0168] したがって、本発明が、データデデュプリケーションの機能性を有するストレージシステム上で使用されることがわかる。ベースボリュームすなわちベースボリュームの基礎になる記憶媒体に関する電力供給が、常態ではオフにされる。したがって、ある種のストレージ環境では、ストレージシステム内のストレージデバイスの大多数が、通常は電力を消費していなくなる。

[0169] 本発明は、ストレージ位置が、格納されるデータの実際の内容に関連する、ある形のｃｏｎｔｅｎｔｓ−ａｄｄｒｅｓｓｅｄ ｓｔｏｒａｇｅ（ＣＡＳ）を使用するストレージシステムに組み込まれる時に、特に有用である可能性がある。関連技術に、その開示全体が参照によって本明細書に組み込まれている、Ｃａｒｐｅｎｔｉｅｒ他の米国特許第６８０７６３２号、名称「Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｅｎｃａｐｓｕｌａｔｉｏｎ，Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ，ａｎｄ Ｔｒａｎｓｆｅｒ」が含まれる。

[0170] 前述から、本発明が、格納されるデータの量を減らすと同時に電力消費も減らす方法および装置を提供することは明白である。さらに、特定の実施形態を本明細書で図示し、説明したが、当業者は、同一の目的を達成するように計画された任意の配置によって、開示された特定の実施形態を置換できることを了解する。本開示は、本発明のすべての適合または変形形態を含むことが意図されており、上の説明が、制限的な形ではなく例示的な形で行われたことを理解されたい。したがって、本発明の範囲は、添付の特許請求の範囲を参照して、そのような特許請求の範囲が権利を与えられる同等物の範囲全体と共に正しく決定されなければならない。

[0008]本発明の方法および装置を適用できるハードウェア構成の例を示す図である。 [0009]図１のアーキテクチャに適用される本発明の論理構成の例を示す図である。 [0010]アレイグループテーブルの例示的なデータ構造を示す図である。 [0011]ボリュームテーブルの例示的なデータ構造を示す図である。 [0012]ハッシュテーブルの例示的なデータ構造を示す図である。 [0013]ビットマップテーブルの例示的なデータ構造を示す図である。 [0014]マッピングテーブルの例示的なデータ構造を示す図である。 [0015]バッファボリュームにデータを書き込む処理を示す図である。 バッファボリュームにデータを書き込む処理を示す図である。 バッファボリュームにデータを書き込む処理を示す図である。 [0016]本発明に従ってデータを読み取る処理を示す図である。 [0017]特定のボリュームからブロックデータを読み取る処理を示す図である。 [0018]バッファボリュームをベースボリュームにフラッシュする処理を示す図である。 バッファボリュームをベースボリュームにフラッシュする処理を示す図である。 バッファボリュームをベースボリュームにフラッシュする処理を示す図である。 [0019]データ読取処理中にバッファボリュームをベースボリュームにフラッシュする処理を含む、本発明の第２実施形態を示す図である。 [0020]第３実施形態での本発明の論理構成を示す図である。 [0021]本発明の第３実施形態のボリュームテーブルの例示的データ構造を示す図である。 [0022]第３実施形態のハッシュテーブルの例示的データ構造を示す図である。 [0023]第３実施形態のベースビットマップテーブルの例示的データ構造を示す図である。 [0024]第３実施形態でバッファボリュームにデータを書き込む処理を示す図である。 [0025]第３実施形態でデータを読み取る処理を示す図である。 [0026]第３実施形態でベースボリュームからブロックデータを読み取る処理を示す図である。 [0027]第３実施形態でバッファボリュームをベースボリュームにフラッシュする処理を示す図である。 第３実施形態でバッファボリュームをベースボリュームにフラッシュする処理を示す図である。 第３実施形態でバッファボリュームをベースボリュームにフラッシュする処理を示す図である。 第３実施形態でバッファボリュームをベースボリュームにフラッシュする処理を示す図である。

Claims (20)

1. １つまたは複数の第１記憶媒体および１つまたは複数の第２記憶媒体と通信するコントローラと、
   前記１つまたは複数の第１記憶媒体から割り振られた記憶容量を有する第１ボリュームと、
   前記１つまたは複数の第２記憶媒体から割り振られた記憶容量を有する第２ボリュームと
   を含み、
   当初に、前記１つまたは複数の第１記憶媒体は、パワーオン状態で構成され、前記１つまたは複数の第２記憶媒体は、パワーオフ状態で構成され、
   前記コントローラによって受け取られた書込データは、前記第１ボリュームに格納され、
   前記１つまたは複数の第２記憶媒体がパワーオン状態で構成されている間に、フラッシュ処理は、実行され、これによって、前記第１ボリュームに格納された前記書込データの内容は、前記第２ボリュームに格納されたすべての既存データの内容と比較され、
   前記比較の結果が、前記書込データの前記内容が前記既存データの前記内容と一致しないことを示す時に、前記書込データは、前記第２ボリュームに格納される
   ストレージシステム。
2. 前記比較の前記結果が、前記書込データの前記内容が前記既存データの前記内容と一致することを示す時に、前記書込データの論理ブロックアドレスを前記既存データにリンクするレコードは、格納され、前記書込データは、破棄される
   請求項１に記載のストレージシステム。
3. 前記内容が一致しない時の前記書込データの前記第２ボリュームへの格納または前記内容が一致する時の前記レコードの格納の後に、前記１つまたは複数の第２記憶媒体は、パワーオフされ、前記書込データは、前記第１ボリュームから削除される
   請求項２に記載のストレージシステム。
4. ホストコンピュータからのターゲットとして前記書込データを受け取る前記コントローラによって提示される仮想ボリュームであって、前記仮想ボリュームをターゲットとする前記書込データは、当初に前記第１ボリュームに格納される、仮想ボリューム
   をさらに含む、請求項１に記載のストレージシステム。
5. 第１ハッシュ値は、前記書込データの前記内容について計算され、前記比較中に、前記第１ハッシュ値は、前記既存データとの前記書込データの前記内容の直接比較を行わなければならないかどうかを判定するために、前記第２ボリュームに格納されたすべての既存データの内容について計算された第２ハッシュ値と比較される
   請求項１に記載のストレージシステム。
6. 前記第１ボリュームに格納されるデータは、所定のサイズのチャンクとして格納され、
   前記第２ボリュームに格納されるデータは、前記所定のサイズのチャンクとして格納され、
   前記コントローラによって受け取られた前記書込データは、分割された部分に分割され、各分割された部分の内容は、前記第１ボリュームに既に格納されているすべての既存チャンクと比較され、
   各分割された部分について、前記分割された部分の前記比較の結果が、前記分割された部分の前記内容が前記第１ボリューム上の前記既存チャンクの内容と一致しないことを示す時に、前記分割された部分は、新しいチャンクとして前記第１ボリュームに格納され、
   前記分割された部分の前記比較の前記結果が、前記分割された部分の前記内容が前記第１ボリューム上の前記既存チャンクの１つの内容と一致することを示す時に、前記分割された部分の論理ブロックアドレスを前記第１ボリューム上の前記既存チャンクにリンクするレコードは、格納され、前記分割された部分は、破棄される
   請求項１に記載のストレージシステム。
7. 第１ハッシュ値は、各前記分割された部分の前記内容について計算され、前記分割された部分の前記比較中に、前記第１ハッシュ値は、前記既存データとの前記書込データの前記内容の直接比較を行わなければならないかどうかを判定するために、前記第１ボリュームに格納されたすべての既存データの内容について計算された第２ハッシュ値と比較される
   請求項６に記載のストレージシステム。
8. 前記１つまたは複数の第２記憶媒体は、前記ストレージコントローラによって受け取られた読取要求に応答してパワーオンされ、前記フラッシュ処理は、開始され、前記比較は、前記読取要求の完了に続いて行われる
   請求項１に記載のストレージシステム。
9. 前記フラッシュ処理は、管理者からの指示、前記第１ボリュームが所定の容量に達すること、または所定の時間期間の経過のうちの１つを含むトリガするイベントによって開始され、
   前記１つまたは複数の第２記憶媒体は、前記比較を実行できるようにするために、前記フラッシュ処理の開始に応答してパワーオンされる
   請求項１に記載のストレージシステム。
10. 複数の前記第１記憶媒体があり、前記第１記憶媒体は、第１アレイグループに構成され、前記第１ボリュームは、前記第１アレイグループから割り振られた記憶容量を有し、
    複数の前記第２記憶媒体があり、前記第２記憶媒体は、第２アレイグループに構成され、前記第２ボリュームは、前記第２アレイグループから割り振られた記憶容量を有し、
    前記第２アレイグループは、前記コントローラによって、前記第１アレイグループと独立にパワーオンされ、パワーオフされるように構成される
    請求項１に記載のストレージシステム。
11. 前記コントローラと通信する１つまたは複数の第３記憶媒体と、
    前記第３アレイグループから割り振られた記憶容量を有する第３ボリュームと
    をさらに含み、
    前記コントローラが、前記書込データについて計算された第１ハッシュ値が前記第２ボリュームまたは前記第３ボリュームのうちの１つに格納された既存データについて計算された第２ハッシュ値と同一であると判定する時に、前記コントローラは、前記既存データの前記内容を前記書込データの前記内容と比較するために、前記第２または第３のボリュームのうちで前記一致するハッシュ値を有する前記既存データが格納されているボリュームの前記記憶媒体をパワーオンすると同時に、前記第２または第３のボリュームの他方の前記記憶媒体をパワーオフされたままにする
    請求項１に記載のストレージシステム。
12. 第１アレイグループに配置された複数の第１記憶媒体および第２アレイグループに配置された複数の第２記憶媒体に対する入出力（Ｉ／Ｏ）動作を制御するコントローラと、
    前記第１アレイグループから割り振られた記憶容量を有するバッファボリュームであって、前記バッファボリュームに格納されるデータは、所定のサイズのチャンクとして格納される、バッファボリュームと、
    前記第２アレイグループから割り振られた記憶容量を有するベースボリュームであって、前記ベースボリュームに格納されるデータは、前記所定のサイズのチャンクとして格納される、ベースボリュームと、
    前記Ｉ／Ｏ動作のターゲットとして前記コントローラによって提示される仮想ボリュームと
    を含み、
    前記第１記憶媒体は、当初にパワーオン状態であり、前記第２記憶媒体は、パワーオフ状態であり、
    前記コントローラによって受け取られた前記仮想ボリュームをターゲットとする書込データは、各分割された部分の内容を前記バッファボリュームに既に格納されているすべての既存チャンクの内容と比較するために前記書込データを前記所定のサイズの分割された部分に分割することと、前記分割された部分の前記内容がどの既存チャンクの前記内容とも一致しない時に前記分割された部分を新しいチャンクとして格納することとによって、当初に前記バッファボリュームに格納され、
    前記１つまたは複数の第２記憶媒体がパワーオンされている間に、前記バッファボリュームに格納されたチャンクの内容は、前記ベースボリュームに格納されたすべてのチャンクの内容と比較され、
    前記バッファボリュームの各チャンクの前記比較の結果が、前記バッファボリュームの前記チャンクの前記内容が前記ベースボリューム上の前記チャンクのいずれの前記内容とも一致しないことを示す時に、前記バッファボリュームからの前記チャンクは、前記ベースボリュームに格納される
    ストレージシステム。
13. 前記チャンクの前記比較の前記結果が、前記バッファボリュームデータの前記チャンクの前記内容が前記ベースボリューム上のいずれかのチャンクの前記内容と一致することを示す時に、前記バッファボリューム上の前記チャンクの論理ブロックアドレスを前記ベースボリューム上の一致する既存チャンクにリンクするレコードは、格納され、前記バッファボリューム上の前記チャンクは、破棄される
    請求項１２に記載のストレージシステム。
14. 前記バッファボリューム内の前記チャンクの、前記ベースボリューム内に格納されたすべての既存チャンクの前記内容との前記比較と、前記内容が一致しない場合の前記ベースボリュームへの前記チャンクの格納または前記内容が一致する場合の前記レコードの格納との後に、前記１つまたは複数の第２記憶媒体は、パワーオフされ、前記チャンクは、前記バッファボリュームから削除される
    請求項１３に記載のストレージシステム。
15. 第１ハッシュ値は、前記バッファボリューム上の前記チャンクの前記内容について計算され、チャンクの前記比較中に、前記第１ハッシュ値は、前記ベースボリューム上の前記チャンクとの前記バッファボリューム上の前記チャンクの前記内容の直接比較を行わなければならないかどうかを判定するために、前記ベースボリュームに格納されたすべての既存チャンクの前記内容について以前に計算された第２ハッシュ値と比較される
    請求項１２に記載のストレージシステム。
16. 前記ベースボリュームは、複数のベースボリュームのうちの第１ベースボリュームであり、前記ストレージシステムは、さらに、
    第３アレイグループに配置された複数の第３記憶媒体であって、前記コントローラは、前記第３記憶媒体に対するＩ／Ｏ動作を制御する、複数の第３記憶媒体と、
    前記第３アレイグループから割り振られた記憶容量を有する前記複数のベースボリュームのうちの第２ベースボリュームであって、前記第２ベースボリュームに格納されるデータは、前記所定のサイズのチャンクとして格納される、第２ベースボリュームと
    をさらに含み、
    前記コントローラが、前記バッファボリューム上の前記チャンクの１つについて計算された第１ハッシュ値が前記第１ベースボリュームまたは前記第２ベースボリュームのうちの１つに格納された既存チャンクについて以前に計算された第２ハッシュ値と同一であると判定する時に、前記コントローラは、前記既存チャンクの前記内容を前記ベースボリューム上の前記チャンクの前記内容と比較するために、前記一致するハッシュ値を有する前記既存チャンクが格納されている前記第１ベースボリュームまたは前記第２ベースボリュームのうちの前記１つの前記記憶媒体をパワーオンすると同時に、前記第１ベースボリュームまたは前記第２ベースボリュームのうちの他方の前記記憶媒体をパワーオフされたままにする
    請求項１２に記載のストレージシステム。
17. １つまたは複数の第１記憶媒体、１つまたは複数の第２記憶媒体、および１つまたは複数の第３記憶媒体と通信するコントローラと、
    前記１つまたは複数の第１記憶媒体から割り振られた記憶容量を有する第１ボリュームと、
    前記１つまたは複数の第２記憶媒体から割り振られた記憶容量を有する第２ボリュームと、
    前記１つまたは複数の第３記憶媒体から割り振られた記憶容量を有する第３ボリュームと
    を含み、
    前記１つまたは複数の第１記憶媒体は、当初にパワーオン状態であり、前記１つまたは複数の第２記憶媒体および前記１つまたは複数の第３記憶媒体は、パワーオフ状態であり、
    前記コントローラによって受け取られた書込データは、当初に前記第１ボリュームに格納され、
    前記コントローラが、前記書込データについて計算された第１ハッシュ値が前記第２ボリュームまたは前記第３ボリュームのうちの１つに格納された既存データについて計算された第２ハッシュ値と同一であると判定する時に、前記コントローラは、前記既存データの前記内容を前記書込データの前記内容と比較するために、前記一致するハッシュ値を有する前記既存データが格納されている前記第２または第３のボリュームのうちの前記１つの前記記憶媒体をパワーオンすると同時に、前記第２または第３のボリュームのうちの他方の前記記憶媒体をパワーオフされたままにするように構成される
    ストレージシステム。
18. 前記比較の結果が、前記書込データの前記内容が前記既存データの前記内容と一致しないことを示す時に、前記書込データは、前記第２ボリュームまたは前記第３ボリュームのうちで最大の残り使用可能容量を有するボリュームに格納される
    請求項１７に記載のストレージシステム。
19. 前記比較の前記結果が、前記書込データの前記内容が前記既存データの前記内容と一致することを示す時に、前記書込データの論理ブロックアドレスを前記既存データにリンクするレコードは、格納され、前記書込データは、破棄される
    請求項１７に記載のストレージシステム。
20. 前記第１ボリュームに格納されるデータは、所定のサイズのチャンクとして格納され、
    前記第２ボリュームおよび前記第３ボリュームに格納されるデータは、前記所定のサイズのチャンクとして格納され、
    前記コントローラによって受け取られた前記書込データは、分割された部分に分割され、各分割された部分の内容は、前記第１ボリュームに既に格納されているすべての既存チャンクと比較され、
    各分割された部分について、前記分割された部分の前記比較の結果が、前記分割された部分の前記内容が前記第１ボリュームに格納された前記既存チャンクの前記内容と一致しないことを示す時に、前記分割された部分は、新しいチャンクとして前記第１ボリュームに格納され、
    前記分割された部分の前記比較の前記結果が、前記分割された部分の前記内容が前記第１ボリューム上の前記既存チャンクの１つの前記内容と一致することを示す時に、前記分割された部分の論理ブロックアドレスを前記第１ボリューム上の前記既存チャンクにリンクするレコードは、格納され、前記分割された部分は、破棄される
    請求項１７に記載のストレージシステム。

Images