本発明の前述の特徴は、添付の図面を参照して、以下の詳細な説明を参照することによって容易に理解される。
(具体的な実施形態の詳細な説明)
定義。本明細書および添付の特許請求の範囲において使用されるように、文脈上特別な断りがない限り、以下の用語は指示された意味を有する。
オブジェクトの「チャンク」は、オブジェクトの抽象スライスであり、使用される物理的格納とは無関係に作られ、一般的にオブジェクトの隣接バイトの固定数である。
データ格納のための故障許容「パターン」は、データが一つ以上の格納デバイスにわたって冗長に分散される事項(particular)であり、なかでも、ミラリング(たとえばRAID1に類似した方法で)、ストライピング(たとえばRAID5に類似した方法で)、RAID6、二重パリティ、対角線パリティ、低密度パリティチェック(Low Density Parity Check)コード、ターボコード、または他の冗長スキーム、または冗長スキームの組み合わせであり得る。
所定のチャンクのハッシュ数は、該所定のチャンクが任意の他のチャンクのハッシュ数とは一般的に異なるハッシュ数を生成するときに、該他のチャンクが該所定のチャンクと同一のデータコンテンツを有するときを除いて、「一意」である。すなわち、2つのチャンクは、それらのコンテンツが同一でないときはいつでも、異なるハッシュ数を一般的に有する。以下に詳細に説明されるように、「一意」という用語は、この文脈において、同一でないチャンクに対して共通ハッシュ数をたまに生成するハッシュ関数から生成されるハッシュ数をカバーするように使用される。なぜなら、ハッシュ関数は、異なるチャンクについて異なる数を生成することにおいて、一般的に完全ではないからである。
「領域」は、格納媒体の上の隣接する物理ブロックのセットである(たとえばハードドライブ)。
「ゾーン」は、2つ以上の領域からなる。ゾーンを構成する領域は、一般的に隣接することが要求されない。以下に説明される例示的な実施形態において、ゾーンは、1GBのデータまたは制御情報と等価なものを格納する。
「クラスタ」は、ゾーンの中の単位サイズであり、圧縮(以下に説明される)の単位を表す。以下に説明される例示的な実施形態において、クラスタは、4KB(すなわち8つの512バイトセクタ)であり、本質的にチャンクと同じである。
「冗長セット」は、データのセットに冗長性を提供するセクタ/クラスタのセットである。
「領域をバックアップすること」は、一つの領域のコンテンツを別の領域にコピーすることを含む。
格納デバイスの「第1のペア」および「第2のペア」は、共通格納デバイスを含み得る。
「第1の複数の」および「第2の複数の」格納デバイスは、一つ以上の共通格納デバイスを含み得る。
格納デバイスの「第1の配置」および「第2の配置」または「異なる配置」は、一つ以上の共通格納デバイスを含み得る。
本発明の実施形態では、ファイルシステム認識格納システムは、ホストファイルシステムの格納方法を決定するために、ホストファイルシステムデータ構造を分析する。例えば、ブロック格納デバイスは、ホストファイルシステムデータ構造を解析して、使用されたブロック、未使用のブロック、およびデータ型等のようなものを決定してもよい。ブロック格納デバイスは、ホストファイルシステムの格納方法に基づいて物理的格納を管理する。
そのようなファイルシステム認識ブロック格納デバイスは、データの物理的格納について知的判定を行うことが可能である。例えば、ファイルシステム認識ブロック格納デバイスは、システムのデータ格納容量を効果的に拡張するために、ホストファイルシステムによって解放されたブロックを特定し、解放されたブロックを再利用することが可能である。以降で「ごみあさり(scavenging)」または「ガーベッジ収集」と呼んでもよい、解放されたブロックのそのような再利用は、仮想格納を実施する際に特に有用であってよく、その場合、ホストファイルシステムは、実際の物理的格納容量よりも多くの格納により構成される。ファイルシステム認識ブロック格納デバイスはまた、ファイルシステムによって格納されたオブジェクトのデータ型を特定し、データ型に基づいて異なる格納スキームを使用してオブジェクトを格納することも可能である(例えば、アクセス頻度の高いデータは、圧縮せず、かつ連続ブロックで格納することが可能である一方で、アクセス頻度の低いデータは、圧縮および/または不連続ブロックで格納することが可能であり、データ圧縮および暗号化等の異なる符号化スキームは、データ型に基づいて異なるオブジェクトに適用することが可能である)。
ファイルシステム認識ブロック格納デバイスは、概して、所定の一式のファイルシステムをサポートし、ファイルシステムに対し、基礎となるデータ構造(例えば、使用されていないブロックビットマップ)の場所を突き止めて利用するのに十分なほどに内部の働きを「理解」する。ファイルシステムタイプ(例えば、NTFS、FAT、ReiserFS、ext3)を決定するために、ファイルシステム認識ブロック格納デバイスは典型的に、パーティションテーブルを解析してオペレーティングシステム(OS)パーティションの場所を突き止め、次いでOSパーティションを解析してホストファイルシステムのスーパーブロックの場所を突き止めることによって、ファイルシステムタイプを特定する。ひとたびファイルシステムタイプが分かると、ファイルシステム認識ブロック格納デバイスは、スーパーブロックを解析してホストファイルシステムに対する使用されていないブロックビットマップを見出し、次いで使用されていないブロックビットマップを解析して、使用されたブロックおよび未使用のブロックを見出すことが可能である。
データ構造(例えば、使用されていないブロックビットマップ)の経時的変化を検出するために、ファイルシステム認識ブロック格納デバイスは、周期的にデータ構造のコピーを作成し(例えば、非公式の非冗長ゾーンで)、後で、現在アクティブなバージョンのデータ構造を初期に作成したコピーと比較して、変化を検出してもよい。例えば、割り当てられた状態から使用されていない状態へと移行する任意のビットマップエントリを特定することが可能であり、ガーベッジ収集操作が、再利用の良い候補であるクラスタに正確に向けられることを可能にする。各ビットマップが処理されるとき、ビットマッップ操作の経過の履歴を維持するために、履歴コピーを現在のコピーと置き換えることが可能である。時間が経つにつれて、使用されていないブロックビットマップのコピーは、時間的にばらばらなクラスタの寄せ集めとなるかもしれないが、使用されていないエントリの場所を突き止めるために現在のコピーが使用されるので、このことは何の問題も引き起こさないはずである。
以降、格納アレイシステムを参照して、例示的実施形態を説明する。
図1は、本発明の実施形態の図示であり、オブジェクト、この例においてはファイルが、格納のために一連のチャンクに分解される。最初に、ファイル11が格納ソフトウェアに渡され、そこでオブジェクト12として指定され、一意のオブジェクト識別番号、この場合は#007が割当てられる。新しいエントリ131は、オブジェクトテーブル13の中に作られ、この新しいオブジェクトの割当てを表す。オブジェクトは、今度はデータ121、122および123の「チャンク」に分解され、それらはオブジェクトの固定長セグメントである。各チャンクは、ハッシングアルゴリズムを通過させられ、ハッシングアルゴリズムはチャンクについて一意のハッシュ数を返す。このアルゴリズムは、リトライされたチャンクが格納されたチャンクと同一であることを保証するために、検索されたチャンクと、もともとのハッシュと比較された結果とに、後で適用され得る。各チャンクのハッシュ数は、後で完全なオブジェクトがチャンクの収集によって検索され得るように、オブジェクト132のエントリ行においてオブジェクトテーブル13の中に格納される。
図1においてさらに、チャンクハッシュは、今度はチャンクテーブル14の中の既存のエントリと比較される。既存のエントリ141と一致する任意のハッシュは、すでに格納されているので、行動はとられない(すなわち、データは再び格納されず、オブジェクトの自動的圧縮につながる)。新しいハッシュ(チャンクテーブル14の中に対応するエントリがないハッシュ)は、チャンクテーブル141の中に入力される。チャンクにおけるデータは、次に、故障許容格納のために最も効率的な方法で、利用可能な格納デバイス151、152および153の上に格納される。このアプローチは、チャンクデータが、たとえば、一つまたは2つのデバイスからなる格納システムの上にミラリングされた方法で、または3つ以上の格納デバイスを用いてシステムの上でパリティストライピングされた方法で格納されることにつながり得る。このデータは、物理的位置1511、1521および1531において格納デバイスの上に格納され、チャンクのすべての物理的部分が後で場所を突き止められ検索され得るように、これらの位置および位置の番号は、チャンクテーブルの列143および142に格納される。
図2は、より多くの格納デバイス(storage)の追加の結果として、チャンクのための故障許容格納のパターンがどのように動的に変化され得るかという同じ実施形態を示す。特に、図2は、追加の格納デバイスがシステム全体にひとたび追加されると、格納デバイスの上に物理的に格納されたチャンクが、新しいパターンにおいてどのようにレイアウトされ得るかを示す。図2aにおいて、格納システムは2つの格納デバイス221および222を備え、チャンクデータは、位置2211および2221において2つの格納デバイスの上に物理的にミラリングされ、故障許容を提供する。図2bにおいて、第3の格納デバイス223が追加され、チャンクをパリティストライピングした方法で格納することが可能になり、これは、ミラリングされたパターンよりも格納効率が良いパターンである。チャンクは、3つの物理的位置2311、2321および2331において、この新しいパターンにレイアウトされ、利用可能な格納デバイスにとる割合がはるかに低い。チャンクテーブル21はアップデートされて、新しいレイアウトが3つの位置212にすることと、新しいチャンクの物理的位置2311、2321および2331が213に記録されていることをも示す。
図3は、本発明の実施形態による、完成された(mature)格納システムを示し、ある期間にわたって機能していた。これは、可変格納容量を有する格納デバイスの上で、チャンクが、時間を経てどのように物理的に格納され得るかを図示する。この図は、40GB格納デバイス31と、80GB格納デバイス32と、120GB格納デバイス33とからなる格納システムを示す。最初に、チャンクは、40GB格納デバイス31が満杯になるまで、故障許容ストライプパターン34で格納される。次に、格納スペースの欠如のために、新しいデータは、80GB格納デバイス32および120GB格納デバイス33の上の利用可能なスペースの上に、ミラリングされたパターン36で格納される。80GB格納デバイス32がひとたび満杯になると、次に、新しいデータは単一のディスク故障許容パターン37でレイアウトされる。たとえ格納デバイスがデータ格納のための単一のプールを備えていても、チャンクにおいて格納されたようなデータそのものは、種々の別個のパターンで格納されている。
図4は、本発明の別の実施形態を図示し、非効率的な格納デバイスの使用と、故障許容の低いレベルとを警告するために、インジケータ状態が使用される。図4aにおいて、すべての3つの格納デバイス41、42および45は使用されていないスペースを有しており、効率的で故障許容の方法でデータが格納されていることを示すために、インジケータライト44は緑色である。図4bにおいて、40GB格納デバイス41は満杯になったので、新しいデータは、ミラリングされた冗長パターン46で、使用されていない残りのスペースを用いて2つの格納デバイス42および43の上のみに格納され得る。データは完全に冗長ではあるが、効率的に格納されていないことを示すために、インジケータライト44は琥珀色に変わった。図4cにおいて、120GB格納デバイス43のみが使用されていない残りのスペースを有しているので、すべての新しいデータは、この一つのデバイス43の上でミラリングされたパターンのみで格納され得る。故障許容はよりロバスト(robust)でなくなり、システムはスペースが非常に足りなくなっているので、より多くの格納デバイスの追加が必要であることを示すために、インジケータライト44は赤色に変わる。
一つの代替的な実施形態において、アレイにおけるそれぞれのドライブ/スロットに、たとえば3色(たとえば緑色、黄色、赤色)の形で、インジケータが提供される。一つの特定の実施形態において、ライトは、光る効果でディスクキャリアの前面全体を照らすように使用される。ライトは、システムの全体的な状態のみならず、(もしあれば)どのドライブ/スロットが注意を必要としているかを示すように制御される。それぞれの3色ライトは、少なくとも4つの状態に置かれ得、具体的には、オフ、緑色、黄色、赤色である。スロットが空であり、システムが十分な格納デバイスと冗長性をもって作動しているために、スロットにドライブがインストールされる必要がない場合には、特定のスロットのためのライトは、オフ状態に置かれ得る。特定のスロットのためのライトは、対応するドライブが十分であり、置き換えられる必要がない場合には、緑色状態に置かれ得る。特定のスロットのためのライトは、対応するドライブをより大きなドライブに置き換えることが推奨されるようにシステム操作が低下する場合には、黄色の状態に置かれ得る。特定のスロットのためのライトは、対応するドライブをインストールまたは置き換えなければならない場合には、赤色の状態に置かれ得る。必要または要求に応じて、たとえば、オンとオフとの状態の間でライトをフラッシュさせることによって、または2つの異なる色の間でライトをフラッシュさせる(たとえば、ドライブが置き換えられた後に、データの再レイアウトが進行中であるときに、赤色と緑色との間でフラッシュさせる)ことによって、追加の状態が示され得る。例示的な実施形態のさらなる詳細が、以下に説明される。
もちろん、システム状態とドライブ/スロット状態との両方を示すために、他の指示技術が使用され得る。たとえば、システム状態と、必要な場合には、注意を必要とするスロット番号とを示すために、LCDディスプレイが使用され得る。さらに、他の種類のインジケータ(たとえば、スロットインジケータまたは各スロット用のライトとともに、システムのための単一の状態インジケータ(たとえば緑色/黄色/赤色))が使用され得る。
図5は、図1〜3に関連して上述されたような、本発明の実施形態に従ったデータの格納、検索および再レイアウトにおいて使用される機能モジュールのブロック図である。通信のための入口点および出口点は、オブジェクトの格納または検索のためにオブジェクトをシステムに渡すオブジェクトインタフェース511と、格納システムを一つの大きな格納デバイスであるように見せるブロックインタフェース512と、格納システムをWindows(登録商標)ファイルシステムであるように見せるCIFSインタフェース513とである。これらのインタフェースがデータの格納を要求するとき、データはチャンクパーサ(Chunk Parser)52に渡され、チャンクパーサは、データのチャンクへの分解を実行し、オブジェクトテーブル512への最初のエントリを生成する(図1に関連して上述されたように)。これらのチャンクは、次にハッシュコード生成器53に渡され、ハッシュコード生成器は各チャンクについて関連するハッシュコードを生成し、それらをオブジェクトテーブルに入力するので、各オブジェクトに関連するチャンクは512で列挙される(図1に関連して上述されたように)。チャンクハッシュ数は、チャンクテーブル531におけるエントリと比較される。一致が見出された場合には、新しいチャンクは、格納システムにすでに格納されたチャンクと同一であるので、捨てられる。チャンクが新しい場合には、そのための新しいエントリがチャンクテーブル531の中に作成され、ハッシュされたチャンクは物理的格納マネージャ54に渡される。物理的格納マネージャは、利用可能な格納デバイス571、572および573の上で可能な最も効率的なパターンでチャンクを格納して、チャンクのコンテンツが後で512で検索され得るように(図1に関連して上述されたように)、チャンクの物理的格納がどこで発生したかを示すために、チャンクテーブル531の中に対応するエントリを作成する。
オブジェクトインタフェース511、ブロックインタフェース512、またはCIFSインタフェース513による、図5におけるデータの検索は、検索マネジャー56に対するリクエストによって実行され、検索マネージャは、どのチャンクがオブジェクトを含むかを決定するためにオブジェクトテーブル521を調べ、次にこれらのチャンクを物理的格納マネージャ54から要求する。物理的格納マネージャ54は、要求されたチャンクがどこに格納されているかを決定するためにチャンクテーブル531を調べ、次にそれらを検索し、完了したデータ(オブジェクト)を検索マネージャ56に返し、検索マネージャは、要求しているインタフェースにデータを返す。図5には、故障許容マネージャ(FTL)55も含まれ、チャンクが可能な最も効率的な方法で格納されているかどうかを決定するために、絶えずチャンクテーブルをスキャンする。(格納デバイス571、572および573が追加されたり取り外されたりすると、これらは変化し得る。)チャンクが可能な最も効率的な方法で格納されていない場合には、FTLは、物理的格納マネージャ54に、チャンクについて新しいレイアウトパターンを作成し、チャンクテーブル531をアップデートするように、要求する。このようにして、すべてのデータは、アレイを含む格納デバイスの数について可能な最も効率的な方法で格納されたままでいる(図2および3に関連して上述されたように)。
以下は、本発明の例示的な実施形態のさらなる詳細を提供する。
(データレイアウトスキーム−ゾーン)
なかでも、ゾーンは、ディスクの上に格納されている実際のデータから、冗長性とディスク再レイアウトとを隠す効果を有する。ゾーンは、ゾーンのユーザに影響することなく、追加のレイアウト方法が追加および変更されることを可能にする。
格納アレイは、ゾーンと呼ばれる仮想セクションにおけるディスクの上で、データをレイアウトする。ゾーンは、所定および固定の量(たとえば1Gバイト)のデータを格納する。ゾーンは、単一のディスクの上に存在し得るか、あるいは一つ以上のドライブにわたってまたがり得る。ゾーンの物理的レイアウトは、そのゾーンについて指定された形で冗長性を提供する。
図6は、2つ以上のドライブを含むアレイにおいてミラリングが使用される例を示す。図7は、データを格納するために異なるレイアウトスキームを使用するいくつかの例示的なゾーンを示す。図は、ゾーンが1GBのデータを格納することを想定する。以下の点に留意されたい。
i)複数のドライブにまたがるゾーンは、セットにわたるドライブの中に同じオフセットを必ずしも使用しない。
ii)単一ドライブミラリングは、1Gのデータを格納するために2Gの格納デバイスを必要とする。
iii)二重ドライブミラリングは、1Gのデータを格納するために2Gの格納デバイスを必要とする。
iv)3つのドライブストライピングは、1Gのデータを格納するために1.5Gの格納デバイスを必要とする。
v)4つのドライブストライピングは、1Gのデータを格納するために1.33Gの格納デバイスを必要とする。
vi)ゾーンA、ゾーンBなどは、任意のゾーン名である。実際のインプリメンテーションにおいて、それぞれのゾーンは一意の数によって識別され得る。
vii)図によって暗示されるものの、ゾーンは必ずしもディスクの上で隣接しない(後で領域を参照)。
viii)ミラリングが2つのドライブに制約される技術的理由はない。たとえば、3ドライブシステムにおいて、データの一つのコピーが一つのドライブの上に格納され得、ミラリングされたデータの半分が他の2つのドライブのそれぞれの上に格納され得る。同様に、データは3つのドライブにわたってミラリングされ得、データの半分が2つのドライブのそれぞれの上にミラリングされ、ミラリングの半分が他の2つのドライブの上にミラリングされる。
(データレイアウトスキーム−領域)
各ディスクは、均等なサイズの領域に分割される。領域のサイズはゾーンよりもはるかに小さく、ゾーンは一つ以上のディスクからの一つ以上の領域から構築される。ディスクスペースの効率的な使用のために、領域のサイズは一般的に、異なるゾーンサイズと、アレイによってサポートされる異なる数のディスクとの共通因子である。例示的な実施形態において、領域はゾーンの1/12のデータサイズである。以下の表は、本発明の例示的な実施形態に従って、種々のレイアウトについての、領域/ゾーンの数と、領域/ディスクの数とを列挙する。
個々の領域は、使用済み、使用されていない、または不良としてマークされ得る。ゾーンが作成されるときには、適切なディスクから使用されていない領域のセットが、テーブルにおいて選択されログをとられる。これらの領域は、任意の順序であり得、ディスクの上で隣接する必要はない。データがゾーンに書き込まれるかまたはゾーンから読み取られるときには、アクセスは適切な領域にリダイレクトされる。なかでも、このことは、データの再レイアウトが柔軟かつ効率的な方法で生ずることを可能にする。時間を経て、異なるサイズのゾーンは、おそらく断片化を発生させ、小さすぎて完全なゾーンを保持できない多くのディスクエリアを残す。適切な領域サイズを使用することによって、断片化によって残されたすべてのギャップは、サイズにおいて少なくとも一つの領域になり、ディスク全体を断片化解消(de−fragment)する必要なしに、これらの小さなギャップの容易な再使用を可能にする。
(データレイアウトスキーム−再レイアウト)
インプリメンテーションを容易にするために、固定シーケンスの拡張および縮小が強化され得る。たとえば、2つのドライブが急に追加される場合には、第2のドライブを組み込むために第2の拡張が実行される前に、あたかも一つのドライブが追加されたかのように、ゾーンの拡張が中間の拡張を経由し得る。代替的には、複数のドライブを含む拡張および縮小は、中間のステップなしに、アトミックに(atomically)処理され得る。
任意の再レイアウトが生じる前に、必要とされるスペースが利用可能でなければならない。このことは、不必要な再レイアウトが生じないことを確実にするために、再レイアウトを始める前に計算されるべきである。
(レイアウトスキーム−ドライブ拡張)
以下は、本発明の例示的な実施形態に従って、単一ドライブミラリングから二重ドライブミラリングに拡張する一般的なプロセスを説明する。
i)単一ドライブミラリングが、データ「A」とミラリング「B」とを有すると想定する。
ii)ゾーンを「C」へと拡張するために、ドライブの上に12の領域を割当てる。
iii)ミラリング「B」を領域セット「C」にコピーする。
iv)すでにコピーされたデータへのいかなる書き込みも、「C」における適切な場所にミラリングされなければならない。
v)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「B」へのポインタを「C」へのポインタに置き換える。
vi)「B」を構成する領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って二重ドライブミラリングからパリティを用いた三重ドライブストライピングへと拡張する、一般的なプロセスを説明する。
i)一つのドライブがデータ「A」を有し、第2のドライブがミラリング「B」を有すると想定する。
ii)パリティ情報「C」のために、第3のドライブの上に6つの領域を割当てる。
iii)「A」の第1の6領域と、「B」の第2の6領域とを使用して、パリティ情報を計算する。
iv)「C」にパリティ情報を置く。
v)すでに処理されたデータになされたいかなる書き込みも、「C」における適切な場所にパリティされなければならない。
vi)コピーが完了したら、新しいレイアウトタイプのポイントテーブルを用いて、ゾーンテーブルを、「A」の第1の半分と、「B」の第2の半分と、「C」とにアップデートする。
vii)「A」の第2の半分と「B」の第1の半分とを、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って三重ドライブストライピングからパリティを用いた四重ドライブストライピングに拡張する、一般的なプロセスを説明する。
i)一つのドライブがデータ「A」を有し、第2のドライブがデータ「B」を有し、第3のドライブがパリティ「P」を有すると想定する。
ii)ストライピングデータ「C」のために、第4のドライブの上に4つの領域を割当てる。
iii)「A」の最後の2領域を、「C」の最初の2領域にコピーする。
iv)「B」の最初の2領域を、「C」の最後の2領域にコピーする。
v)パリティドライブ「D」の上に4つの領域を割当てる。
vi)Aの最初の4領域と、Cと、Bの最後の4領域とを使用して、パリティ情報を計算する。
vii)パリティ情報を「D」に置く。
viii)すでに処理されたデータへのいかなる書き込みも、「D」における適切な場所にパリティされなければならない。
ix)新しいレイアウトタイプとポイントテーブルとを用いて、ゾーンテーブルを、「A」の第1の4領域と、「C」と、「B」の第2の4領域と、「D」とにアップデートする。
x)「A」の最後の2領域と、「B」の最初の2領域を、使用されていないとしてマークする。
(データレイアウトスキーム−ドライブ縮小)
ドライブ縮小は、ディスクが取り外されるかまたは故障するときに発生する。そのような場合には、アレイは、可能であればすべてのゾーンを冗長状態に戻すために、データを縮小する。ドライブ縮小は、拡張よりもやや複雑である。なぜなら、より多くの選択がなされるべきだからである。しかし、レイアウト方法の間の移行は、拡張と同様の方法で生じるが、逆の順序である。再生されるべきデータの量を最小限に保つことは、冗長性が可能な限り迅速に達成されることを可能にする。ドライブ縮小は、すべてのゾーンが再レイアウトされるまで、スペースが利用可能である間に、一般的に一度に1ゾーン先行する。一般的に言って、取り外されたかまたは故障したディスクの上に存在するデータのみが再構築される。
(どのように縮小するかの選択)
以下の表は、本発明の例示的な実施形態に従って、再レイアウトされる必要のある各ゾーンについての決定ツリーを説明する:
以下は、本発明の例示的な実施形態に従って、二重ドライブミラリングから単一ドライブミラリングに縮小する一般的なプロセスを説明する。
i)単一ドライブミラリングが、データ「A」と欠いているミラリング「B」とを有するか、またはその逆であると仮定する。
ii)「A」を「C」として含むドライブの上に12の領域を割当てる。
iii)データ「A」を領域セット「C」にコピーする。
iv)すでにコピーされたデータへのいかなる書き込みも、「C」における適切な場所にミラリングされなければならない。
v)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「B」へのポインタを「C」へのポインタに置き換える。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングから二重ドライブミラリングに縮小する一般的なプロセスを説明する(パリティを欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」および「C」からなると想定する。パリティ「C」が欠けている。
ii)「A」をゾーンの第1の半分を含むものとして定義し、「B」をゾーンの第2の半分を含むものとして定義する。
iii)「A」ドライブの上に6つの領域「D」を割当て、「B」ドライブの上に6つの領域「E」を割当てる。
iv)「A」を「E」にコピーする。
v)「B」を「D」にコピーする。すでにコピーされたデータへのいかなる書き込みも、「D」および「E」における適切な場所にミラリングされなければならない。
vii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「A」/「D」および「E」/「B」へのポインタを設定する。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングから二重ドライブミラリングに縮小する一般的なプロセスを説明する(データを欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」および「C」からなると想定する。データ「C」が欠けている。
ii)「A」をゾーンの第1の半分を含むものとして定義し、「C」をゾーンの第2の半分を含むものとして定義する。
iii)「A」ドライブの上に6つの領域「D」を割当て、「B」ドライブの上に12の領域「E」を割当てる。
iv)「A」を「E」の第1の半分にコピーする。
v)「A」および「B」から、欠けているデータを再構築する。データを「D」に書き込む。
vi)「D」を「E」の第2の半分にコピーする。
vii)すでにコピーされたデータへのいかなる書き込みも、「D」および「E」における適切な場所にミラリングされなければならない。
viii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「A」/「D」および「E」へのポインタを設定する。
ix)「B」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重ドライブストライピングから三重ドライブストライピングに縮小する一般的なプロセスを説明する(パリティを欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」、「C」および「D」からなると仮定する。パリティ「D」が欠けている。
ii)「A」をゾーンの第1の3分の1を含むものとして定義し、「B」を第2の3分の1を含むものとして定義し、「C」を第3の3分の1を含むものとして定義する。
iii)「A」ドライブの上に2領域「G」を割当て、「C」ドライブの上に2領域「E」を割当て、「B」ドライブの上に6領域「F」を割当てる。
iv)「B」の第1の半分を「G」にコピーする。
v)「B」の第2の半分を「E」にコピーする。
vi)「A」/「G」および「E」/「C」からパリティを構築し、「F」に書き込む。vii)すでにコピーされたデータへのいかなる書き込みも、「G」、「E」および「F」における適切な場所にミラリングされなければならない。
viii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「A」/「G」、「E」/「C」、および「F」へのポインタを設定する。ix)「B」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングに縮小する一般的なプロセスを説明する(最初の1/3を欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」、「C」および「D」からなると想定する。データ「A」が欠けている。
ii)「A」をゾーンの第1の3分の1を含むものとして定義し、「B」を第2の3分の1を含むものとして定義し、「C」を第3の3分の1を含むものとして定義し、「D」をパリティを含むものとして定義する。
iii)「B」ドライブの上に4領域「E」を割当て、「C」ドライブの上に2領域「F」を割当て、「D」ドライブの上に6領域「G」を割当てる。
iv)「B」の第2の半分を「F」にコピーする。
v)「B」、「C」および「D」から、欠けているデータを構築し、「E」に書き込む。vi)「E」/「Bの第1の半分」と、「F」/「C」とから新しいパリティを構築し、「G」に書き込む。
vii)すでにコピーされたデータへのいかなる書き込みも、「B」、「E」、「F」および「G」における適切な場所にミラリングされなければならない。
viii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「E」/「Bの第1の半分」、「F」/「C」、および「G」へのポインタを設定する。
ix)「B」の第2の半分および「D」の領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングに縮小する一般的なプロセスを説明する(第2の1/3を欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」、「C」および「D」からなると想定する。データ「B」が欠けている。
ii)「A」をゾーンの第1の3分の1を含むものとして定義し、「B」を第2の3分の1を含むものとして定義し、「C」を第3の3分の1を含むものとして定義し、「D」をパリティを含むものとして定義する。
iii)「A」ドライブの上に2領域「E」を割当て、「C」ドライブの上に2領域「F」を割当て、「D」ドライブの上に6領域「G」を割当てる。
iv)「A」の第1の半分、「C」の第1の半分、および「D」の第1の半分から、欠けているデータを構築し、「E」に書き込む。
v)「A」の第2の半分、「C」の第2の半分、および「D」の第2の半分から、欠けているデータを構築し、「F」に書き込む。
vi)「A」/「E」および「F」/「C」から新しいパリティを構築し、「G」に書き込む。
vii)すでにコピーされたデータへのいかなる書き込みも、「E」、「F」および「G」における適切な場所にミラリングされなければならない。
viii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「E」、「F」および「G」へのポインタを設定する。
ix)「D」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングへの縮小の一般的なプロセスを説明する(第3の1/3を欠いている)。
i)ストライピングは、異なるドライブの上のデータブロック「A」、「B」、「C」および「D」からなると想定する。データ「C」が欠けている。
ii)「A」をゾーンの第1の3分の1を含むものとして定義し、「B」を第2の3分の1を含むものとして定義し、「C」を第3の3分の1を含むものとして定義し、「D」をパリティを含むものとして定義する。
iii)「A」ドライブの上に2領域「E」を割当て、「B」ドライブの上に4領域「F」を割当て、「D」ドライブの上に6領域「G」を割当てる。
iv)「B」の第1の半分を「E」にコピーする。
v)「A」、「B」および「D」から、欠けているデータを構築し、「F」に書き込む。vi)「A」/「E」と、「B」/「F」の第2の半分とから新しいパリティを構築し、「G」に書き込む。
vii)すでにコピーされたデータへのいかなる書き込みも、「E」、「F」および「G」における適切な場所にミラリングされなければならない。
viii)コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「A」/「E」、「B」/「F」の第2の半分、および「G」へのポインタを設定する。
ix)「B」の第1の半分および「D」を、使用されていないとしてマークする。
たとえば、図3を再び参照して、ドライブ0またはドライブ1のいずれかが失われた場合には、ドライブ2の上に十分な利用可能なスペースがあるという条件で、二重ドライブミラリング(ゾーンB)はドライブ2の上で再構築され得る。同様に、ドライブ0〜2のいずれかが失われた場合には、ドライブ3の上に十分な利用可能なスペースがあるという条件で、ドライブストライピング(ゾーンC)は、ドライブ3を利用して再構築され得る。
(データレイアウトスキーム−ゾーン再構築)
ゾーン再構築は、ドライブが取り外されて、理想的なゾーン再レイアウトのために残りのドライブの上に十分なスペースがあるとき、あるいはドライブがより大きなサイズの新しいドライブと置き換えられたときに、生じる。
以下は、本発明の例示的な実施形態に従って、二重ドライブミラリングの再構築の一般的なプロセスを説明する。
i)単一ドライブミラリングが、データ「A」と欠けているミラリング「B」とを有すると想定する。
ii)「A」を含むドライブ以外のドライブの上に12の領域「C」を割当てる。
iii)データ「A」を「C」にコピーする。
iv)すでにコピーされたデータへのいかなる書き込みも、「C」における適切な場所にミラリングされなければならない。
v)コピーが完了したら、ゾーンテーブルをアップデートし、「B」へのポインタを「C」へのポインタにアップデートする。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングの再構築の一般的なプロセスを説明する。
i)一つのドライブがデータ「A」を有し、第2のドライブがデータ「B」を有し、第3のドライブがパリティ「P」を有すると想定する。「B」が欠けている。どの断片が欠けているかは問題ではなく、必要とされる行動はすべての場合において同じであることに留意されたい。
ii)「A」および「P」を含むドライブ以外のドライブの上に、6つの領域「D」を割当てる。
iii)「A」および「P」から、欠けているデータを構築する。データを「D」に書き込む。
iv)すでに処理されたデータへのいかなる書き込みも、「D」における適切な場所にパリティされなければならない。
v)「B」へのポインタを「D」へのポインタに置き換えることによって、ゾーンテーブルをアップデートする。
この例示的な実施形態において、取り外されたドライブが別のドライブと置き換えられる場合に、4ドライブ再構築のみが生じる。再構築は、新しいドライブの上に6つの領域を割当てることと、他の3つの領域セットから、欠けているデータを再構築することとからなる。
(データレイアウトスキーム−一時的に欠けるドライブの問題)
ドライブが取り外されて、再レイアウトのための余地がないときには、古いドライブが再び取り付けられるか、またはドライブが新しいドライブと置き換えられるまで、アレイは劣化したモードで作動し続ける。新しいドライブが取り付けられる場合には、ドライブセットが再構築されるべきである。この場合には、データが再レイアウトされる。古いディスクがアレイの中に戻して置かれる場合には、それはもはや現在のディスクセットの一部ではなく、新しいディスクとしてみなされる。しかし、新しいディスクがアレイに置かれるのではなく、古いディスクが戻される場合には、古いディスクは、たとえ古いメンバであろうとも、やはりディスクセットのメンバであるとして認識される。この場合には、すでに再レイアウトされた任意のゾーンが新しい構成を保ち、古いディスクの上の領域は解放される。再レイアウトされていない任意のゾーンは、やはり古いディスクの適切な領域をポインティングする。しかし、劣化したゾーンに何らかの書き込みが実行され得た場合には、これらのゾーンはリフレッシュされる必要がある。生じたすべての書き込みのログをとるのではなく、変更された劣化領域はマークされ得る。このようにして、ディスクが置き換えられるときには、変更された領域のみがリフレッシュされる必要がある。
さらに、書き込まれたゾーンは、再レイアウトのための優先リストにさらに置かれ得る。このことは、ディスクが置き換えられた場合に、リフレッシュされる必要がある領域の数を低減し得る。タイムアウトも使用され得、その時点の後で、ディスクはたとえ置き換えられても消去される(wiped)。しかし、このタイムアウトは非常に大きくあり得、場合によると数分ではなく数時間である。
(データレイアウトスキーム−データ保全性)
上述のように、標準的なRAIDシステムの一つの問題は、ディスクアレイのまれにしか使用されないエリアの上で、ディスク表面の破損が生じる可能性があることである。別のドライブが故障する場合には、破損が生じたことを決定することは必ずしも可能ではない。そのような場合には、RAIDアレイが故障したドライブを再構築するときに、破損したデータが伝播され保存され得る。
上述のハッシュメカニズムは、RAIDのもとで利用可能なメカニズムにわたってデータ破損検出の追加のメカニズムを提供する。他の場合に述べられるように、チャンクが格納されるときに、そのチャンクについて、ハッシュ値が計算され格納される。チャンクが読み出されるときはいつでも、検索されたチャンクについてのハッシュ値が計算され得、格納されたハッシュ値と比較され得る。ハッシュ値が一致しない場合には(破損したチャンクを示し)、チャンクデータは冗長データから回復され得る。
ディスクの上のデータ破損が生じ得る時間窓(time window)を最小化するために、破損したデータを可能な限り速やかに発見し修正するように、ディスクの定期的なスキャンが実行される。それは、オプションとして、アレイからの読み出しにおいてチェックが実行されることをも可能にする。
(データレイアウトスキーム−ボリューム)
スパースボリューム(sparse volume)において、アレイにおけるディスクの上で利用可能な格納スペースの量に関わりなく、アレイは固定サイズ(たとえばMテラバイト)であることをつねに求める。アレイはSバイトの実際の格納スペースを含み、ここでS<=Mであり、データは、Mテラバイトのスペースの中の位置L1、L2、L3などに格納されるように要求され得ると仮定する。要求された位置Ln>Sである場合には、Lnのためのデータは、位置Pn<Sに格納されなければならない。このことは、図8に示されるように、Lnに基づいてインデックスPnに対するルックアップテーブルを含むことによって管理される。この特徴は、Windows(登録商標)、Linux(登録商標)およびApple(登録商標)のオペレーティングシステムなどの、ボリューム拡張をサポートしないオペレーティングシステムとともに、アレイが作動することを可能にする。さらに、アレイは、複数のスパースボリュームを提供し得、そのすべては同一の物理格納を共有する。それぞれのスパースボリュームは、専用のルックアップテーブルを有するが、データ格納のために同一の物理スペースを共有する。
(ドライブスロットインジケータ)
上述のように、格納アレイは一つ以上のドライブスロットからなる。それぞれのドライブスロットは、空であり得るか、またはハードディスクドライブを含み得る。それぞれのドライブスロットは、4つの状態を示す能力のある専用インジケータを有する。すなわち、オフ、OK、劣化、および故障である。状態は、一般的に以下のように解釈される:
この例示的な実施形態において、赤色/琥珀色/緑色の発光ダイオード(LED)がインジケータとして使用される。LEDは、一般的に以下のように解釈される:
図9は、本発明の例示的な実施形態に従った、利用可能な格納スペースを有し、故障許容方法において作動する、例示的なアレイを示す。スロットB、CおよびDには、格納デバイスが配置され、追加のデータを冗長に格納するために利用可能な十分な格納スペースがある。スロットB、CおよびDのインジケータは緑色であり(これらの格納デバイスが正しく作動しており、アレイデータが冗長であり、アレイが利用可能なディスクスペースを有することを示す)、スロットAのインジケータはオフである(格納デバイスをスロットAに配置する必要がないことを示す)。
図10は、本発明の例示的な実施形態に従った、冗長データ格納を維持するために十分なスペースを有せず、より多くのスペースが追加されなければならない、例示的なアレイを示す。スロットB、CおよびDには、格納デバイスが配置される。スロットCおよびDにおける格納デバイスは満杯である。スロットB、CおよびDのインジケータは緑色であり(これらの格納デバイスが正しく作動していることを示す)、スロットAのインジケータは赤色である(アレイが、冗長データ格納を維持するための十分なスペースを有せず、スロットAに格納デバイスが配置されるべきであることを示す)。
図11は、本発明の例示的な実施形態に従った、故障の場合に冗長データを維持することができなくあり得る、例示的なアレイを示す。スロットA、B、CおよびDには、格納デバイスが配置される。スロットCおよびDにおける格納デバイスは満杯である。スロットA、BおよびCのインジケータは緑色であり(アレイが正しく作動していることを示す)、スロットDのインジケータは琥珀色である(スロットDにおける格納デバイスが、より大きな格納容量を有する格納デバイスに置き換えられるべきであることを示す)。
図12は、本発明の例示的な実施形態に従った、格納デバイスが故障した例示的なアレイを示す。スロットB、CおよびDには、格納デバイスが配置される。スロットCにおける格納デバイスが故障した。スロットBおよびDのインジケータは緑色であり(これらが正しく作動していることを示す)、スロットCのインジケータは赤色であり(スロットCにおける格納デバイスが置き換えられるべきであることを示す)、スロットAのインジケータはオフである(格納デバイスがスロットAに配置される必要がないことを示す)。
以下は、本発明の例示的な実施形態のためのソフトウェア設計の説明である。ソフトウェア設計は、6つのソフトウェアレイヤに基づき、ソフトウェアレイヤは、ディスクに物理的にアクセスすることから、ホストコンピューティングシステムと通信することまでの、論理アーキテクチャにわたる。
この例示的な実施形態において、ファイルシステムは、Windows(登録商標)、Linux(登録商標)またはApple(登録商標)などのホストサーバに常駐し、USBデバイスまたはiSCSIデバイスとして格納アレイにアクセスする。ホストインタフェースを介して到着する物理的ディスクリクエストは、ホストリクエストマネージャ(Host Request Manager)(HRM)によって処理される。ホストI/Oインタフェースは、ホストに対するホストUSBまたはiSCSIインタフェースのプレゼンテーションを調整し(coordinate)、HRMとインタフェースする。HRMは、ホストI/Oインタフェースからのデータ読み出し/書き込みリクエストを調整し、読み出しおよび書き込みリクエストをタスク指名し、これらのリクエストが完了したときに、これらのリクエストのホストへの回収(retiring)を調整する。
格納アレイの何よりも重要な目的は、ひとたびデータがシステムによって受け入れられると、システムが現在格納する冗長性の最大量を利用して、データが確実な方法で格納されることを保証することである。アレイが物理的構成を変化させると、データは冗長性を維持する(さらに場合によると最大化する)ために再編成される。さらに、使用される格納量を低減するために、単純なハッシュに基づいた圧縮が使用される。
最も基本的なレイヤは、データを異なるディスクに格納するディスクドライバからなる。ディスクは、USBインタフェースを介して通り抜けた(tunneled)ATAなどの種々のインタフェースを介して接続され得る。
ディスクの上のセクタは、領域、ゾーン、およびクラスタに編成され、それぞれが異なる論理的役割を有する。
領域は、ディスクの上の隣接する物理ブロックのセットを表す。4ドライブシステムにおいて、それぞれの領域は、サイズが1/12GBであり、冗長性の最小単位を表す。領域の中のセクタが物理的に損傷していることがわかった場合は、領域全体が放棄される。
ゾーンは、冗長性の単位を表す。ゾーンは、適切な量の冗長性を提供するために、場合により異なるディスクの上の、多数の領域からなる。ゾーンは、1GBのデータ容量を提供するが、冗長性を提供するためにより多くの領域を要求し得る。冗長性のない1GBは、1セットの12領域(1GB)を要求する;1GBのミラリングされたゾーンは、2セットの1GB領域(24領域)を要求する;1GBの3ディスクストライピングされたゾーンは、3セットの0.5GB領域(18領域)を要求する。異なるゾーンは、異なる冗長特性を有する。
クラスタは、圧縮の基本単位を表し、ゾーンの中の単位サイズである。クラスタのサイズは現在4KB、すなわち8×512バイトセクタである。ディスクの上の多くのクラスタは、おそらく同じデータを含む。クラスタアクセステーブル(CAT)は、ハッシュ関数を介してクラスタの利用を追跡するために使用される。CATは、論理ホストアドレスと、ゾーンにおける適切なクラスタの位置との間の変換をする。
ディスクに書き込むときに、データがディスクの上にすでに存在するかどうかを知るためにハッシュ関数が使用される。そうである場合には、CATテーブルにおける適切なエントリが、既存のクラスタを示すように設定される。
CATテーブルは、自らのゾーンの中に常駐する。CATテーブルがゾーンのサイズを超える場合には、追加のゾーンが使用され、CATのその部分のゾーンに論理アドレスをマッピングするために、テーブルが使用される。代替的には、ゾーンはCATテーブルを含むように事前に割当てられる。
ホスト書き込み待ち時間を低減し、データ信頼性を保証するために、ジャーナルマネージャが、(ディスクまたはNVRAMのいずれかに対する)すべての書き込みリクエストを記録する。システムが再起動される場合には、ジャーナルエントリは再起動に際してコミットされる。
ディスクは出入りし得、領域は、破損を有することがわかった場合には、使わなく(retire)され得る。これらの状況のいずれにおいても、レイアウトマネージャは、冗長タイプを変更するために、またはゾーンの領域的な構成を変化させるために(領域が破損した場合に)、
ゾーンの中の領域を再編成することが可能である。
格納アレイは、物理的ディスクスペースの変化するレベルによって支援されて、仮想ディスクアレイを提供し、それはブロックレベルのインタフェースを提供するので、いつクラスタがファイルシステムによってもはや使われなくなるかは、明らかではない。結果として、使用されるクラスタスペースは、拡張し続ける。ガーベッジコレクタ(ホストまたはファームウェアのいずれかに位置する)は、どのクラスタが解放されたかを決定するためにファイルシステムを分析し、それらをハッシュテーブルから取り除く。
以下の表は、本発明の例示的な実施形態に従った6つのソフトウェアレイヤを示す:
図13は、異なるソフトウェアレイヤと、それらが互いにどのように関連するかを表す、モジュール階層を示す。ソフトウェアレイヤリングは、明瞭なAPIおよび記述を提供するために、好ましくはリジッドである。
ガーベッジコレクタ(Garbage Collector)は、ホストファイルシステムによってもはや使われないクラスタを解放する。たとえば、ファイルが削除されるときに、そのファイルを含むために使用されたクラスタは、好ましくは解放される。
ジャーナルマネージャ(Journal Manager)は、書き込みの実行記録(journaling)の形を提供するので、電源異常または他のエラー状態の場合において、保留中の書き込みは失われない。
レイアウトマネージャ(Layout Manager)は、ゾーンの領域に対するゾーンのランタイム再レイアウトを提供する。このことは、ディスクの挿入/取り外しまたは故障の結果として生じ得る。
クラスタマネージャ(Cluster Manager)は、データゾーンのセットの中にクラスタを割当てる。ディスク利用デーモン(Disk Utilization Daemon)は、使用されていないディスクスペースを定期的にチェックする。
ロックテーブル(Lock Table)は、書き込み衝突発行(collision issues)の後で、読み出しを処理する。
ホストリクエストマネージャ(Host Request Manager)は、ホストおよびガーベッジコレクタからの読み出し/書き込みリクエストを処理する。書き込みはジャーナルマネージャに渡されるが、読み出しはクラスタアクセステーブル(CAT)管理レイヤを介して処理される。
上述のように、代表的なファイルシステムにおいて、ある量のデータが一般的に事実上反復される。ディスクスペース利用を低減させるために、このデータの複数のコピーはディスクに書き込まれない。代わりに、一つのインスタンスが書き込まれ、同じデータのすべての他のインスタンスが、この一つのインスタンスに対して参照される。
この例示的な実施形態において、システムはつねにデータのクラスタの上で作動し(たとえば8つの物理的セクタ)、これはハッシュされる単位である。SHA1アルゴリズムは、160ビットハッシュを生成するために使用される。このことは、良好な独特さ(uniqueness)を含む多数の利益を有し、多数のプロセッサにおいてオンチップでサポートされる。すべての160ビットがハッシュレコードに格納されるが、最下位の16ビットのみがハッシュテーブルへのインデックスとして使用される。最も低い16ビットと一致する他のインスタンスは、リンクされたリストを介して連鎖される。
この例示的な実施形態において、一度に一つの読み出し/書き込み操作のみが生じ得る。性能の目的のために、クラスタをディスクに書き込むときにハッシュ分析が生じることは許されない。代わりに、ハッシュ分析は、ハッシュマネージャによるバックグラウンド活動として生じる。
書き込みリクエストは、ジャーナルの書き込みキューから読み込まれ、完了に向けて処理される。データの一貫性を保証するために、書き込み操作がクラスタの上ですでに活動状態である場合には、書き込みは遅らせなければならない。他のクラスタの上の操作は、妨げられずに進行し得る。
クラスタ全体が書き込まれない限りは、書き込まれるデータは、クラスタに格納された既存のデータと併合される必要がある。論理セクタアドレス(LSA)に基づいて、クラスタのCATエントリが位置づけられる。ハッシュキー、ゾーン、およびクラスタオフセット情報は、このレコードから獲得され、次に、ハッシュテーブルを検索して一致を見出すために使用され得る。これがクラスタである。
正しいハッシュエントリのルックアップの速度を改善するために、一度はSHA1ダイジェストを介して、次にゾーン/クラスタオフセットによって、ハッシュテーブルを二重にハッシュすることは十分に必要であり得る。ハッシュレコードがすでに使用されている場合には、参照カウントが減少させられる。参照カウントが現在ゼロであり、かつハッシュエントリによって参照されるスナップショットがない場合には、ハッシュエントリおよびクラスタは、それぞれのフリーリストに解放し返され得る。
もともとのクラスタデータは、これでクラスタのアップデートセクションと併合させられ、データは再ハッシュされる。新しいクラスタはフリーリストから除去され、併合されたデータはクラスタに書き込まれ、新しいエントリはハッシュテーブルに追加され、CATテーブルにおけるエントリは新しいクラスタを指し示すようにアップデートされる。
ハッシュテーブルをアップデートする結果として、エントリも内部キューに追加されて、バックグラウンドタスクによって処理される。このタスクは、新たに追加されたクラスタおよびハッシュエントリと、ハッシュテーブル行アドレスに一致する他のハッシュエントリとを比較し、これらが重複している場合にはレコードを結合し、必要に応じてハッシュエントリおよびCATテーブルエントリを解放する。これは、この活動によって書き込み待ち時間に負荷がかけられないことを保証する。この処理の間に故障(たとえば電力の損失)が生じる場合には、種々のテーブルが削除され得、結果としてデータの損失になる。テーブルは、最終コミットがアトミックであるか、あるいはジャーナルエントリが完全に完了しなかった場合には再実行され得るような方法で、管理されるべきである。
以下は、書き込み論理の疑似コードである。
読み出しリクエストもまた、一度に一つのクラスタ(「セクタ」ではなく)で処理される。読み出しリクエストは、上記に概説されたハッシュ関連の処理を経ない。代わりに、ホスト論理セクタアドレスが、CATを参照するために使用され、ゾーン番号とゾーンの中へのクラスタオフセットとを獲得する。読み出しリクエストは、CATキャッシュにおけるCATテーブルエントリをルックアップすべきであり、書き込み進行中のビットが設定されることにおいて遅延されなければならない。他の読み出し/書き込みは、妨げられずに進行し得る。データ保全性のチェックを改善するために、クラスタは、読み出されるときにハッシュされ、そのハッシュは、ハッシュレコードに格納されたSHA1ハッシュ値と比較される。このことは、ハッシュテーブルの中への検索キーとして、ハッシュ、ゾーン、およびクラスタを使用することを必要とする。
クラスタは、可能な限り少ないゾーンを使用するように割当てられる。なぜなら、ゾーンは、ディスクドライブの使用に直接的に対応するからである。すべてのゾーンについて、ハードドライブアレイの上に2つ以上の領域がある。ゾーンの数を最小化することによって、物理的領域の数が最小化され、したがってハードドライブアレイの上のスペースの消費が低減される。
クラスタマネージャは、データゾーンのセットからクラスタを割当てる。ゾーンにおける使用されていないクラスタを把握するために、リンクされたリストが使用される。しかし、使用されていないクラスタの情報は、ディスクの上にビットマップ(ゾーンあたり32KB)として格納される。リンクされたリストは、ビットマップから動的に構築される。最初に、使用されていないクラスタの一定の数のリンクされたリストが、メモリの中で作成される。クラスタが割当てられると、リストは縮小する。所定の最低点において、使用されていないクラスタを表す新しいリンクされたリストのノードは、ディスクの上のビットマップから抽出される。このようにして、ビットマップは、割当て用に使用されていないクラスタを見出すために分析される必要はない。
この例示的な実施形態において、ハッシュテーブルは64Kのレコード(ハッシュのより下位の16ビットによって索引をつけられる)であり、以下のフォーマットを有する:
オールゼロ(all zero)のクラスタは、かなり一般的であり得るので、たとえば決して削除され得ないように、オールゼロの場合は特別な場合として扱われ得る(したがってカウントをラッピング(wrapping)することは問題ではあり得ない)。
複数のハッシュが同一の最下位ハッシュを有するとき、あるいは2つのハッシュエントリが異なるデータクラスタを指し示すときには、使用されていないハッシュレコードのリンクされたリストが使用される。いずれの場合においても、使用されていないハッシュレコードは、リストから取られ、pNextHashポインタを介してリンクされる。
ハッシュマネージャは、ハッシュテーブルに追加されたエントリを整頓し、ディスクの上の同一のクラスタを結合する。新しいハッシュレコードがハッシュテーブルに追加されると、メッセージがハッシュマネージャに通知される。これは、ハッシュマネージャによって自動的に行われる。バックグラウンド活動として、ハッシュマネージャはキューの上のエントリを処理する。ハッシュマネージャは、完全な(full)ハッシュ値が既存のハッシュレコードと一致するかどうかを知るために、完全なハッシュ値を比較する。そうする場合には、ハッシュマネージャは、完成した(complete)クラスタデータも比較する。クラスタが一致する場合には、新しいハッシュレコードは使用されていないキューに捨て戻され得、ハッシュレコードカウントは増加させられ、重複するクラスタはクラスタの使用されていないキューに戻される。ハッシュマネージャは、レコードを結合するときに、スナップショットビットを前に伝播させるように注意しなければならない。
クラスタアクセステーブル(CAT)は、間接的なポインタを含む。ポインタは、ゾーンの中のデータクラスタ(0が最初のデータクラスタである)を指し示す。一つのCATエントリは、単一のデータクラスタ(暫定的にサイズが4KB)を参照する。多くの反復データがあるときには、ディスク使用要件を低減するために、CATが(ハッシングとともに)使用される。単一のCATは、格納の隣接ブロックをつねに表す。CATは、非データゾーンの中に含まれる。それぞれのCATエントリは48ビットである。以下の表は、それぞれのエントリがどのようにレイアウトされるかを示す(それぞれのデータゾーンが1GBのデータを含むと想定する):
CATは64ビットの中に収まることが望ましいが、これは必要不可欠ではない。2TBアレイのためのCATテーブルは、現在、サイズが4GBまでである。それぞれのCATエントリは、データとゾーンの数とを含むゾーンを指し示す。
図14は、ゾーンにおけるデータクラスタにアクセスするために、CATがどのように使用されるかを示す。冗長データは、CATにおける2つ以上のエントリによって参照される。2つの論理クラスタが同じデータを含むので、それらのCATエントリは、同じ物理的クラスタに指し示される。
ハッシュキーエントリは、クラスタ全体の160ビットSHA1ハッシュ値の16ビット抽出を含む。このエントリは、書き込み操作の間にハッシュテーブルをアップデートするために使用される。
16TBのデータを参照するCATにおけるそれぞれのエントリにおいて、十分なビットがある。しかし、すべてのデータクラスタが互いに異なる場合には(コンテンツに関して)、2TBのデータを参照するために、ちょうど3ゾーン相当以上のCATエントリが必要とされる(それぞれのゾーンは、サイズが1GBであり、したがって1GBサイズのCATエントリを格納し得る。6バイトCATエントリを想定すると、178956970CATエントリ/ゾーンであり、すなわち、それぞれのクラスタが4Kである場合には、テーブルは約682GB/ゾーンを参照する)。
ホスト論理セクタ変換テーブルは、ホスト論理セクタアドレスをゾーン番号に変換するために使用される。ホスト論理セクタアドレスに対応するCATの部分は、このゾーンに常駐する。それぞれのCATエントリは、4096バイトのクラスタサイズを表すことに留意されたい。これは8つの512バイトセクタである。以下は、ホスト論理セクタ変換テーブルの表現を示す:
ゾーンは、CAT全体を保持するように事前に割当てられ得る。代替的に、CATに対してより多くのエントリが要求されるときには、ゾーンがCATに対して割当てられ得る。CATは、2TB仮想ディスクをホストセクタアドレススペースにマッピングするので、ホストによるハードディスクのパーティショニングまたはフォーマッティングの間に、おそらくCATの大部分が参照される。このことを理由として、ゾーンは事前に割当てられ得る。
CATは大きな1GB/ゾーンのテーブルである。使用されるクラスタのワーキングセットは、この大きなテーブルからのスパースセット(sparse set)である。性能の理由のために、活動状態のエントリは、ディスクから(おそらく時間的に)つねに読み込むのではなく、プロセッサメモリにおいてキャッシュされ得る。キャッシュを配置するために、少なくとも2つのオプションがあり、CATからの個々のエントリ、またはCATからの全体のクラスタである。
進行中の書き込みは、CATキャッシュテーブルと結合されるので、すべての未処理の書き込みがキャッシュの中に留まることを保証する必要がある。したがって、キャッシュは、少なくとも、未処理の書き込みリクエストの最大数と同じくらい大きい必要がある。
キャッシュにおけるエントリは、クラスタサイズ(すなわち4K)である。クラスタの上で作動中の進行中の書き込みがあるかどうかを知る必要がある。この指示は、クラスタについてのキャッシュエントリにおけるフラグとして格納され得る。以下の表は、CATキャッシュエントリのフォーマットを示す:
キャッシュエントリにおける進行中のフラグは、2つの意味を有する。第一に、書き込みが進行中であり、クラスタの上のいかなる書き込み(または追加の書き込み)も、書き込みが完了するまでは延期されなければならない、ということを示す。第二に、キャッシュにおけるこのエントリは、ビットが設定される間はフラッシュ(flush)されてはならない。このことは、部分的にはビットの状態を保護するためであり、このクラスタが現在使用されているという事実を反映させるためでもある。さらに、このことは、キャッシュのサイズが、少なくとも、未処理の書き込み操作の数と同じくらい大きくなければならないことを意味する。
進行中の書き込みのインジケータをクラスタについてのキャッシュエントリに格納することの一つの利点は、現在操作中であるという事実を反映し、別のテーブルを有することを不要にし、追加のハッシュベースのルックアップ、またはこのビットもチェックするためのテーブルウォーク(table walk)を不要にすることである。キャッシュは、書き込み遅延(write−delayed)キャッシュであり得る。より早く書き込ませることは有益であり得るが、書き込み操作が完了したときにキャッシュエントリをディスクに書き戻すのみでよい。ハッシュされ得る未処理の書き込みエントリの数を増加させるために、ハッシュ関数または他のメカニズムが使用され得る。
代替のアプローチは、CATのクラスタ全体をキャッシュすることである(すなわちエントリのうちの4Kエントリ)。このことは、アクセスの良好な空間的局所性がある場合に、一般的に性能を改善し得る。CATエントリは48ビット幅なので、注意が払われる必要があり、キャッシュにおけるエントリの全体の数はない。以下の表は、クラスタされたCATキャッシュエントリの例を示す:
テーブルサイズは、4096+996(4192バイト)であり得る。250エントリのキャッシュサイズを有する必要があると想定すると、キャッシュは約1MBを占め得る。
論理CATエントリアドレスの適切なマスキングによらずに、最初および最後のエントリが不完全であるかどうかを計算することは可能である。キャッシュするルックアップルーチンは、エントリのローディングの前にこれを行うべきであり、必要とされるCATクラスタをロードするべきである。
ホストがセクタ(またはクラスタ)読み出しリクエストを送信するときに、論理セクタアドレスを介して送信する。論理セクタアドレスは、ホストによって要求される実際のデータを含むゾーンにおけるクラスタのオフセットを獲得するために、CATの中へのオフセットとして使用される。その結果は、ゾーン番号と、そのゾーンの中へのオフセットとである。その情報は、レイヤ2(Layer 2)ソフトウェアに渡され、レイヤ2ソフトウェアは、次に、ドライブからロークラスタ(raw cluster)を抽出する。
ホストによっていまだかつて書き込まれていないクラスタを処理するために、すべてのCATエントリが、オールゼロを含む「デフォルト」クラスタを指し示すように初期化される。
ジャーナルマネージャは、二層の書き込み実行記録システムである。システムの目的は、書き込みリクエストがホストから受け入れられ得ることを確実にし、データが保全性を保証しながら受け入れられたことをホストに迅速に示し返すことである。さらに、システムは、任意のディスク書き込みの間のシステムリセットの場合において、ブロックレベルデータまたはシステムメタデータ(たとえばCATおよびハッシュテーブルエントリ)の破損または損失がないことを保証する必要がある。
J1ジャーナルマネージャは、すべての書き込みリクエストをホストからディスクへ可能な限り迅速にキャッシュする。ひとたび書き込みが首尾良く完了すると(すなわちデータがアレイによって受け入れられると)、ホストは、操作が完了したことを示すために信号を送られ得る。ジャーナルエントリは、故障から回復するときに、書き込みリクエストの回復を可能にする。ジャーナルレコードは、ディスクに書き込まれるべきデータと、書き込みトランザクションに関連するメタデータとからなる。
ディスク読み出し/書き込みを低減するために、書き込みに関連するデータが書き込まれて、クラスタを解放する。このことは、データを自動的にミラリングする。使用されていないクラスタは、使用されていないクラスタのリストから取られる。ひとたびデータが書き込まれると、使用されていないクラスタのリストは、ディスクに書き戻されなければならない。
ジャーナルレコードは、ミラリングされていないゾーンの上のジャーナルキューに対して書き込まれる。それぞれのレコードは、サイズにおいてセクタであり、ジャーナル書き込みの間の故障が以前のジャーナルエントリを破損し得るリスクを低減するために、セクタ境界に位置合わせされる。ジャーナルエントリは、レコードの終端において一意の増加するシーケンスカウントを含むので、キューの終端は容易に識別され得る。
ジャーナル書き込み操作は、スレッドを処理するホストキューの中で同期的に生じる。ジャーナル書き込みは、ディスクに書き込まれるときに順序づけられなければならないので、任意の時間において一つのスレッドのみがジャーナルに書き込み得る。J1テーブルにおけるジャーナルエントリのアドレスは、一意の識別子として使用され得るので、J1ジャーナルエントリは、J2ジャーナルにおけるエントリと相互に関連させられ得る。ひとたびジャーナルエントリが書き込まれると、トランザクション完了通知が、ホスト完了キューに対して通知される。今や書き込み操作が実行され得る。ジャーナル書き込みが完了する前の、クラスタに対するいかなる次の読み出しも、遅延されることを保証することが重要である。
以下の表は、J2ジャーナルレコードのフォーマットを示す:
それぞれのジャーナルレコードは、セクタ境界に位置合わせされる。ジャーナルレコードは、ゾーン/オフセット/サイズの組のアレイを含み得る。
図15は、本発明の例示的な実施形態に従ったジャーナルテーブルアップデートを示す。具体的には、ホスト書き込みリクエストが受信されるときに、ジャーナルテーブルがアップデートされ、一つ以上のクラスタが割当てられ、データがクラスタに書き込まれる。
ホストジャーナルリクエストが処理される。これらによって、クラスタは書き込まれ、ディスクにシャドウバック(shadow back)されなければならないメタデータ構造(たとえばCATテーブル)へのアップデートももたらされる。たとえシステムリセットが生じても、これらのメタデータ構造がディスクに正しく書き戻されることを保証することが重要である。低レベルディスクI/O書き込み(J2)ジャーナルは、このために使用される。
ホストインタフェースジャーナルエントリを処理するために、メタデータ構造の適切な操作が決定されるべきである。メモリにおいて変化が生じるべきであり、種々のディスクブロックへの変化のレコードが生成されるべきである。このレコードは、ディスクの上でなされるべき実際の変化を含む。アップデートされるそれぞれのデータ構造は、J2ジャーナルマネージャを用いて登録される。このレコードは、ディスクベースのジャーナルに記録されるべきであり、識別子を用いてスタンプされるべきである。レコードがJ1ジャーナルエントリと結びつけられる場合には、識別子がリンクされるべきである。ひとたびレコードが格納されると、ディスクへの変更がなされ得る(あるいはバックグラウンドタスクを介して行われ得る)。
J2ジャーナルは、論理的にレイヤ3において存在する。これは、ゾーンマネージャを介した書き込みを含み得るメタデータアップデートを実行記録(journal)するために使用される。ジャーナルエントリの再生が生じるときには、ゾーンマネージャの方法を使用する。ジャーナルそのものは、特殊な領域に格納され得る。ジャーナルエントリの短い寿命を考慮すれば、ジャーナルエントリはミラリングされない。
特に構造へのアップデートがアトミックである場合には、すべてのメタデータがJ2ジャーナルを経る必要はない。領域マネージャ構造は、J2ジャーナルを使用し得ない。たとえばバックグラウンドスレッドをチェックする保全性を用いて、領域マネージャビットマップにおける不整合を検出することが可能であり得る。
J2ジャーナルのための単純なアプローチは、単一のレコードを含むことである。レコードがディスクに対してコミットされるとすぐに、レコードは再生され、ディスクの上の構造をアップデートする。複数のJ2レコードを有することと、ディスクの上のレコードのアップデートをコミットするバックグラウンドタスクを有することとは可能である。この場合、ジャーナルと、種々のデータ構造に関連する任意のキャッシングアルゴリズムとの間の相互作用に、周到な注意が払われる必要がある。
最初のアプローチは、ジャーナルエントリがディスクに対してコミットされるとすぐに、ジャーナルエントリを実行する。原則としては、J2の複数の同時ユーザがあり得るが、J2ジャーナルは一度に一人のユーザに対してロックされ得る。たとえこの場合においても、ジャーナルエントリは、実行依頼されたらすぐにコミットされるべきである。
任意のより高いレベルのジャーナル活動が生じる前に、メタデータ構造が修復されることを保証することが重要である。システム再起動の際に、J2ジャーナルが分析され、任意のレコードが再生される。ジャーナルエントリがJ1ジャーナルエントリと相互に関連させられる場合には、J1エントリは、完成したものとしてマークされ、除去され得る。ひとたびすべてのJ2ジャーナルエントリが完成すると、メタデータは信頼性のある状態になり、任意の残りのJ1ジャーナルエントリが処理され得る。
J2ジャーナルレコードは、以下の情報を含む。
・操作の数
・各操作は以下を含む:
−J1レコードインジケータ
−書き込むべきゾーン/データオフセット
−書き込むべきデータ
−データのサイズ
−データクラスタの中へのオフセット
・ジャーナルレコード識別子
・終端マーカ
このスキームは、たとえばJ2ジャーナルエントリの終端を識別するためにシーケンス番号を用いて、J2ジャーナルエントリをセクタ境界に置いて、J1ジャーナルスキームと同様に作動し得る。
J1データポインタインジケータが設定される場合には、この特定の操作が、J1ジャーナルレコードを指し示し得る。ホストによって供給される書き込みデータは、われわれの(our)ジャーナルエントリにコピーされる必要はない。ジャーナルレコードにおける操作の最大数は十分に理解されると予想されるので、操作は固定サイズとして定義されることができるべきである。
低レベル書き込み操作の間におけるセクタの破損(たとえば電力の損失によるもの)からの回復を可能にするために、J2ジャーナルは、書き込まれたセクタ全体を格納し得るので、必要な場合にはこの情報からセクタが再書き込みされ得る。代替的にまたは追加的に、書き込み操作の再生が必要とされるかどうかを決定するために、それぞれの変更されたセクタについて計算されたCRCは、J2レコードに格納され得、ディスクの上のセクタから(たとえばゾーンマネージャによって)計算されたCRCと比較され得る。
異なるジャーナルが異なる位置に格納され得るので、ジャーナルレコードを補助格納デバイスに書き込むために提供されるインタフェースレイヤがある。位置は非揮発性であるべきである。2つの候補は、ハードディスクおよびNVRAMである。J1がハードディスクに格納される場合には、J1ジャーナルのミラリングされないゾーンに格納される。J1ジャーナルは、NVRAMに格納する候補である。J2ジャーナルは、特殊な領域に格納され得るが、ディスクの上に格納されるべきである(すなわち、短い寿命を有するので冗長ではない)。J2ジャーナルをディスクの上に格納する利点は、内部データ構造のアップデートの間にシステムリセットがある場合に、データ構造が一貫性のある状態に戻され得ることである(たとえユニットが長時間にわたって電源を入れられないままにされるとしても)。
ゾーンマネージャ(ZM)は、より高いレベルのソフトウェアによって必要とされるゾーンを割当てる。ZMへのリクエストは以下を含む:
a.ゾーンを割当てる
b.ゾーンを再割当て/解放する
c.L1に対してデータ読み出し/書き込みパススルーを制御する(?)
d.ゾーンにおけるクラスタの読み出し/書き込みをする(クラスタのオフセットとゾーン番号とを考慮して)
ZMは、冗長メカニズムを管理し(ドライブの数およびその相対的サイズの関数として)、ミラリング、ストライピング、およびデータの読み出し/書き込みのための他の冗長スキームを処理する。
ZMは、ゾーンを割当てる必要があるときには、2つ以上のセットの領域の割当てを要求する。たとえば、ゾーンは1GBのデータに対して割当てられ得る。このゾーンを構成する領域は、冗長データを含む1GBのデータを含むことができる。ミラリングメカニズムのために、ゾーンは、それぞれ1GBの2セットの領域からなる。別の例として、3ディスクストライピングメカニズムは、それぞれ1/2GBの3セットの領域を利用する。
ZMは、ゾーンを構成する領域の各セットの位置(ドライブ番号および開始領域番号)を見出すために、ZR変換テーブル(6)を使用する。1/12GBの領域サイズを想定すると、最大24領域が必要とされる。24領域は2×1GBゾーンを構成する。したがって、ZR変換テーブルは、ドライブ/領域データを提供する24列を含む。
ZMは一般的に以下のように働く:
a.SDM(単一ドライブミラリング)の場合には、24列が使用される。ドライブ番号はすべての列において同じである。それぞれのエントリは、ゾーンを構成する物理的ドライブの上の物理的領域に対応する。最初の12エントリは、データの一つのコピーを含む領域を指し示す。最後の12エントリは、データの第2のコピーを含む領域を指し示す。
b.DDM(二重ドライブミラリング)の場合は、最初の12エントリのドライブ番号が最後の12エントリのドライブ番号とは異なることを除いて、SDMと同じである。
c.ストライピングの場合には、3つ以上の列が使用され得る。たとえば、ストライピングが3つのドライブにわたって使用される場合には、6つの領域が3つの異なるドライブから必要とされ得(すなわち18エントリが使用される)、最初の6エントリが同じドライブ番号を含み、次の6エントリが別のドライブ番号を含み、それに続く6エントリが第3のドライブ番号を含み、未使用のエントリはゼロにされる。
以下は、ゾーン領域変換テーブルの表現を示す:
読み出し/書き込みリクエストが入ってくるときに、ZMは、ゾーン番号およびそのゾーンの中へのオフセットを提供される。ZMは、そのゾーンについての冗長メカニズムを見出すためにZR変換テーブルを調べ、どのドライブ/領域が読み出し/書き込みされなければならないセクタを含むかを計算するためにオフセットを使用する。ドライブ/領域情報は、次に、実際の読み出し/書き込みを行うL1レイヤに提供される。使用(Usage)の列における追加の可能なエントリは、「使用されていない」である。「使用されていない」は、ゾーンが定義されているものの、現在は使用中ではないことを示す。
クラスタマネージャは、データゾーンのセットの中のクラスタを割当ておよび再割当てする。
レイアウトマネージャは、ゾーンの領域に対するゾーンのランタイム再レイアウトを提供する。このことは、ディスクの挿入/取り外しまたは故障の結果として生じ得る。
レイヤ1(L1)ソフトウェアは、物理的なドライブおよび物理的なセクタについて知っている。なかでも、L1ソフトウェアは、ゾーンマネージャによる使用のために、物理的ドライブから領域を割当てる。この例示的な実施形態において、それぞれの領域は、4ドライブアレイシステムについて1/12GB(すなわち174763セクタ)のサイズを有する。より大きなドライブ最大数(8、12または16)を有するシステムは、異なる領域サイズを有する。
SD3(3つのドライブにわたるストライピング;パリティがプラスされた2データ)を用いて1GBのデータを含むゾーンを作成するためには、3つのドライブにおいてそれぞれ6つの領域を使用することになる(6×1/12=ドライブあたり1/2GB)。
この領域スキームの使用は、ゾーンが、たとえばミラリングからストライピングへと、移動または再構成されるときに、ディスクスペースのより良好な利用を提供することを可能にする。L1ソフトウェアは、領域のビットマップを用いて、物理的ドライブの上の利用可能なスペースを追跡する。それぞれのドライブは一つのビットマップを有する。それぞれの領域は、領域が使用されていないか、使用されているか、または不良であるかを追跡するために、ビットマップにおける2ビットによって表される。L2ソフトウェア(ZM)は、ゾーンを作成する必要があるときには、L1レイヤから領域のセットを得る。ゾーンを構成する領域は、ディスクの中で隣接しない。
L1へのリクエストは以下を含む:
a.データの読み出し/書き込みをする(領域のグループの中のクラスタに対して)
b.読み出し/書き込みを制御する(テーブル、データ構造、DICなど)
c.領域に対して物理的スペースを割当てる(1ドライブの中の実際の物理的セクタ)
d.領域を再割当てする
e.物理的ドライブの中の物理的クラスタに対してロー(Raw)読み出し/書き込みをする
f.領域から領域へデータをコピーする
g.領域を不良としてマークする
使用されていない領域ビットマップは大きくあり得、したがって、使用されていないエントリを見つけるための検索(最悪の場合、使用されていないエントリがない)は、遅くあり得る。性能を改善するために、ビットマップの一部がメモリの中に事前にロードされ得、使用されていない領域のリンクされたリストがメモリに格納され得る。活動状態のそれぞれのゾーンについてリストがある。リストの最低点に達した場合には、より多くの使用されていないエントリが、バックグランド活動としてディスクから読み出され得る。
ディスクマネージャ(Disk Manager)は、レイヤ0において作動する。以下の表に示されるように、2つのサブレイヤがあり、具体的には、抽象化レイヤと、物理的な格納アレイと通信するデバイスドライバとである。
デバイスドライバ(Device Driver)レイヤはまた、いくつかのレイヤを含む。たとえば、USBドライブを使用する格納アレイのために、USB移送レイヤの一番上にATAまたはSCSIスタックがある。抽象化レイヤは、格納アレイにおいて使用されるドライブの種類から独立した、基本的な読み出し/書き込み機能を提供する。
一つ以上のディスクアクセスキューが、ディスクアクセスリクエストをキューに入れるために使用され得る。ディスクアクセスレートは、われわれのシステムにおける重要な性能ボトルネックの一つである。われわれは、全般的なシステム待ち時間を低減し、性能を改善するために、ディスクインタフェースがつねに可能な限りビジーに保たれることを確実にしたい。ディスクインタフェースへのリクエストは、非同期インタフェースを有するべきであり、ディスク操作が終了したときには、コールバックハンドラが操作を完了する。一つのディスクリクエストの完了は、キューの上の次のリクエストを自動的に開始する。ドライブごとに一つのキュー、またはすべてのドライブに一つのキューがあり得る。
レイヤ1は、ドライブを論理ドライブ番号として参照する。レイヤ0は、論理ドライブ番号を、物理的ドライブ参照に変換する(たとえば、オープン()コールの結果として、/dev/sdaまたはファイルデバイス番号)。柔軟性のために(USBを介した拡張)、それぞれの論理ドライブについてキューがあるべきである。
以下は、一部の例示的なオブジェクト定義およびデータフローである:
以下は、物理的ディスクレイアウトの説明である。上述のように、それぞれのディスクは固定サイズの領域に分割される。この例示的な実施形態において、それぞれの領域は、4ドライブアレイシステムについて、1/12GB(すなわち174763セクタ)のサイズを有する。より大きなドライブ最大数(8、12または16)を有するシステムは、異なる領域サイズを有する。最初に、領域番号0および1は、領域マネージャによる使用のために予約され、割当てのためには使用されない。領域番号1は、領域番号0のミラリングである。所定のハードディスクについて領域マネージャによって使用されるすべての内部データは、このハードディスクの領域番号0および1に格納される。この情報は、他のドライブと重複(またはミラリング)されない。領域0または1のいずれかにエラーがある場合には、データを保持するために他の領域が割当てられ得る。ディスク情報構造(Disk Information Structure)は、これらの領域を指し示す。
それぞれのディスクは、ディスクと、ディスクが属するディスクセットと、ディスクについてのレイアウト情報とを識別する、DISを含む。ハードディスクの上の第1のセクタは予約されている。DISは、第1のセクタの後の、第1の不良でないクラスタに格納される。DISは、1KB相当のデータの中に含まれる。DISの2つのコピーがある。DISのコピーは、DISが属するディスクの上に格納される。さらに、システムにおけるすべてのディスクは、システムにおけるディスクのすべてのDISのコピーを含む。以下の表は、DISフォーマットを示す。
領域マネージャは、領域情報構造における内部データを格納する。以下の表は、領域情報構造フォーマットを示す。
ゾーン情報構造は、ゾーンマネージャがどこにゾーンテーブルを見出し得るかに関する情報を提供する。以下は、ゾーン情報構造フォーマットを示す。
高レベル情報ゾーンは、ハイレベルマネージャによって使用されるゾーンテーブルおよび他のテーブルを含む。これらは、ミラリングを使用して保護される。
以下の表は、ゾーンテーブルノードフォーマットを示す。
以下は、ゾーン情報のレイアウトの説明である。ゾーンテーブルノード(Zones Table Nodes)のリンクされたリストは、以下の方法でZISの後に置かれる。
この情報は、ゾーンテーブル領域(Zones Table Region)に格納される。
図16は、本発明の例示的な実施形態に従ったドライブレイアウトを示す。最初の2つの領域は、互いのコピーである。第3の(オプションの)ゾーンテーブル領域は、ゾーンテーブルを含む。一つ以上のドライブを有するシステムにおいて、ドライブのうちの2つのみがZTRを含む。一つのドライブのみを有するシステムにおいて、2つの領域は、ZTRの2つの(ミラリングされた)コピーを保持するために使用される。DISは、RISおよびZISの位置に関する情報を含む。RISの第1のコピーは、領域0の中にある必要はないことに留意されたい(たとえば、領域0が不良セクタを含む場合には、異なる領域に位置し得る)。
ゾーンマネージャは、システム起動時にゾーンテーブルをロードする必要がある。それを行うために、ゾーンマネージャは、領域番号およびオフセットをDISから抽出する。これは、ZISの開始を指し示す。
特定モジュール(たとえばCATマネージャ)は、制御構造およびデータテーブルをゾーンに格納する。レイヤ3以上におけるモジュールについてのすべての制御構造は、ゾーン0に格納される構造から参照される。このことは、たとえば、実際のCAT(クラスタ割当てテーブル)の位置が、ゾーン0に格納されたデータ構造から参照されることを意味する。
以下の表は、ゾーン0情報テーブルフォーマットを示す。
CATのリンクされたリストは、CATを含むゾーンを記述するノードのリンクされたリストである。以下の表は、CATのリンクされたリストのノードフォーマットを示す。
ハッシュテーブルのリンクされたリストは、ハッシュテーブルを保持するゾーンを記述するノードのリンクされたリストである。以下の表は、ハッシュテーブルのリンクされたリストのノードフォーマットを示す。
図17は、本発明の例示的な実施形態に従った、ゾーン0のレイアウトと、他のゾーンがどのように参照されるかとを示す。
上述のように、冗長セットは、データのセットに対して冗長性を提供するセクタ/クラスタのセットである。領域をバックアップすることは、一つの領域のコンテンツを別の領域にコピーすることを含む。
データ読み出しエラーの場合には、より低いレベルのソフトウェア(ディスクマネージャまたはデバイスドライバ)は、最初の失敗した試みの後に、追加の2回にわたって読み出しリクエストを再試行する。失敗状態は、ゾーンマネージャに返される。次に、ゾーンマネージャは、冗長クラスタから(読み出しによって)リクエストされるデータを、ディスクアレイにおいて再構築することを試みる。冗長データは、ミラリングされたクラスタ(SDM、DDMについて)、またはパリティを含むクラスタのセット(ストライピングされたインプリメンテーションについて)のいずれかであり得る。次に、再構築されたデータは、ホストに返される。ZMがデータを再構築することができない場合には、読み出しエラーがホストに返される。ゾーンマネージャは、エラー通知パケット(Error Notification Packet)をエラーマネージャ(Error Manager)に送信する。図18は、本発明の例示的な実施形態に従った読み出しエラー処理を示す。
データ書き込みエラーの場合には、より低いレベルのソフトウェア(ディスクマネージャまたはデバイスドライバ)は、最初の失敗した試みの後に、追加の2回にわたって書き込みリクエストを再試行する。失敗状態はゾーンマネージャに返される。ゾーンマネージャは、エラー通知パケットをエラーマネージャに送信する。
このレベルにおいてデータ書き込みが実行されるときに、冗長情報もディスクに書き込まれる。結果として、一つのみのクラスタが書き込みエラーを有する限りは、次の読み出しはデータを再構築することができる。複数のディスクエラーがあり、冗長情報が読み出しまたは書き込みされ得ない場合には、少なくとも二つの可能なアプローチがある。
a.書き込みエラー状態をホストに戻す。冗長セットに関連するすべての領域を、不良セクタを含まない、新たに割当てられた領域に、バックアップする。
b.書き込みを遅らせる。冗長セットに関連するすべての領域を、不良セクタを含まない、新たに割当てられた領域に、バックアップする。次に、新たに割当てられた領域における適切なクラスタに書き込みを行う(すべての冗長部分、たとえばパリティなどとともに)。別個の書き込みキューは、遅らせられた書き込みを含むように使用され得る。
アプローチ(a)は、問題がある。なぜなら、ジャーナルの成功した書き込みの結果として、書き込み状態がすでにホストに送信されている可能性があるので、ホストはエラーがあったことを知り得ないからである。代替策は、読み出しの失敗を報告するが、書き込みを可能にすることである。CATにおけるビットは、特定のLBAが不良読み出しを戻すべきであることを追跡するために使用され得る。
図19は、本発明の例示的な実施形態に従ったエラー処理を示す。
エラーマネージャ(EM)は、クラスタが本当に不良であるかどうかを知るためにクラスタをチェックする。そうである場合には、領域全体が不良であると考えられる。領域のコンテンツは、同じディスクの上の新たに割当てられた領域にコピーされる。次に、現在の領域はBAD(不良)とマークされる。領域にコピーする間に、エラーマネージャは、不良セクタに遭遇したときに、必要とあればデータを再構築する。図20は、本発明の例示的な実施形態に従った、エラーマネジャーによる不良領域のバックアップを示す論理フロー図である。
データ読み出しエラーがあり、エラーマネージャが所定のクラスタについてデータを再構築できない場合には(たとえば、冗長セットにわたる読み出しエラーの結果として)、再構築され得ないデータの代わりに、ゼロが使用される。この場合には、不良セクタを含む他のセクタ(冗長セットからの)もまた、バックアップされなければならない。この場合もやはり、再構築され得ないデータの代わりにゼロが使用される。
ひとたび冗長セットのコピーが行われると、EMはゾーンのこの部分に対応するクラスタへのアクセスを使用不能にする。次にEMは、新たに割当てられた領域を指し示すように、ゾーンテーブルをアップデートする。次に、クラスタへのアクセスが再び使用可能にされる。
この例示的な実施形態は、8つのスナップショットをサポートするように設計される(これは、ハッシュ/クラスタのエントリが特定のスナップショットインスタンスによって使用されるかどうかを示す1バイトの使用を可能にする)。スナップショットに含まれる2つのテーブルがある。
1.スナップショットあたりのCATテーブルは、論理セクタアドレスと、そのLASについてのデータを含むディスクの上のクラスタとの関係を捉えるように、存在する必要がある。究極的には、スナップショットあたりのCATは、スナップショットが取られた瞬間におけるCATのコピーでなければならない。
2.ハッシュ値とデータクラスタとの間のマッピングをするシステムハッシュテーブル。ハッシュ関数は、どのスナップショットが使用されているかに関わらず同じ結果を返し、結果としてすべてのスナップショットにわたって共通である。結果として、このテーブルは、一意にクラスタが任意のスナップショットによって使用されているかどうかを理解しなければならない。ハッシュエントリを使用するスナップショットがない限りは、ハッシュクラスタエントリは、解放され得ないか、または新しいデータと置き換えられ得ない。
現在のものでありなおかつ追加されつつあるスナップショットが、つねにある。ハッシュエントリが作成またはアップデートされるときに、現在のスナップショット番号をそのハッシュエントリに適用する必要がある。スナップショットが作られるときに、現在のスナップショット番号が増加させられる。
任意のスナップショットによってもはや必要とされないクラスタ/ハッシュのエントリは、ハッシュテーブルをざっと読むこと(walking through)によって解放され、リタイヤ(retire)したスナップショットビットセットで任意のハッシュエントリを見出し、そのビットをクリアする。スナップショットバイトがゼロである場合には、ハッシュエントリはテーブルから除去され得、クラスタは解放され得る。
ハッシュツリーに追加されつつある任意の新しいエントリとの衝突を防ぐために(新しいスナップショット番号は、リタイヤするスナップショット番号と同じであるから)、7つのスナップショットのみが取られることが可能にされ得、最後の(8番目の)スナップショットはリタイヤするスナップショットである。ハッシュテーブルは、バックグラウンド活動として調べられ(walked)得る。
スナップショットを作成するために、主たるCATがアップデートされているときはいつでも、第2のCATゾーンが書き込まれ得る。これらのアップデートはキューに入れられ得、シャドー(shadow)CATは別のタスクとしてアップデートされ得る。スナップショットするために、シャドーCATはスナップショットCATになる。
ひとたびスナップショットが行われると、新しいスナップショットCATになる新しいゾーンにこのスナップショットテーブルをコピーするために、バックグランドプロセスが開始され得る。CATのコピーが完了するまではシャドーCATキューが処理されないように、キューが使用され得る。万一、シャドーCATをアップデートする前に故障が生じた場合には(この場合にはキューにおけるエントリが失われ得る)、アレイがオンラインにされる前に、主たるCATテーブルからの再シャドーが実行され得る。
代替的に、スナップショットが必要とされるときに、最初のCATコピーがプラスされた「デルタ」の収集がスナップショットを構成し得る。次に、バックグランドタスクが、この情報から完全なスナップショットCATを再構成し得る。このことは、スナップショットを行うためにダウンタイムをほとんどあるいはまったく必要とし得ない。一方、デルタの別のセットが、次のスナップショットのために収集され得る。
(ファイルシステム認識格納システム)
上記のように、本発明の実施形態は、ホストファイルシステムの格納方法を決定し、ホストファイルシステムの格納方法に基づいて物理的格納を管理するために、ホストファイルシステムデータ構造(すなわち、メタデータ)を分析する。便宜上、この機能性は、以降で「スカベンジャ(scavenger)」と呼んでもよい。以降で「モニタ」と呼んでもよい同様の機能が含まれ、格納方法を監視することが可能であるが、必ずしも物理的格納を管理するわけではない。スカベンジャおよびモニタの両方について下記で論じる。
図27は、本発明の例示的実施形態に従ったコンピュータシステム2700の概念ブロック図である。コンピュータシステム2700は、とりわけ、ホストコンピュータ2710および格納システム2720を含む。ホストコンピュータ2710は、とりわけ、ホストオペレーティングシステム(OS)2712およびホストファイルシステム2711を含む。格納システム2720は、とりわけ、ファイルシステム認識格納制御装置2721および格納2722(例えば、1つ以上のデータ入力されたディスクドライブを含むアレイ)を含む。格納2722は、とりわけ、格納制御装置データ構造2726、ホストOSデータ構造2725、ホストファイルシステムデータ構造2723、およびユーザデータ2724を格納するために使用される。ファイルシステム認識格納制御装置2721は、OSパーティションの参照を含むパーティションテーブル(格納制御装置データ構造2726とホストOSデータ構造2725との間の破線によって表される)等の、様々な種類の情報を格納制御装置データ構造2726に格納する(ファイルシステム認識格納制御装置2721と格納制御装置データ構造2726との間の破線によって表される)。ホストOS2712は、様々な種類の情報をホストOSデータ構造2725に格納し(ホストOS2712とホストOSデータ構造2725との間の破線によって表される)、典型的にホストファイルシステムデータ構造2723へのポインタ/参照を含む(ホストOSデータ構造2725とホストファイルシステムデータ構造2723との間の破線によって表される)。ホストファイルシステム2711は、情報をユーザデータ2724に関するホストファイルシステムデータ構造2723に格納する(メタデータと呼ばれ、ホストファイルシステム2711とホストファイルシステムデータ構造2723との間の破線によって表される)。ファイルシステム認識格納制御装置2721は、ホストファイルシステム2711からの格納リクエストに対処し(ホストファイルシステム2711とファイルシステム認識格納制御装置2721との間の実線によって表される)、ホストファイルシステム2711の格納方法を決定するためにホストOSデータ構造2725およびホストファイルシステムデータ構造2723を利用し(ファイルシステム認識格納制御装置2721とホストOSデータ構造2725との間の破線、およびファイルシステム認識格納制御装置2721とホストファイルシステムデータ構造2723との間の破線によって表される)、ホストファイルシステム2711の格納方法に基づいてユーザデータ2724の格納を管理する(ファイルシステム認識格納制御装置2721とユーザデータ2724との間の破線によって表される)。具体的には、ファイルシステム認識格納制御装置2721は、下記のようにスカベンジャおよび/またはモニタを実装してもよい。
ファイルシステム認識格納制御装置2721は、概して、ホストファイルシステムデータ構造の場所を突き止めて分析するために、ホストファイルシステムの内部の働きを十分に理解する必要がある。もちろん、異なるファイルシステムには異なるデータ構造があり、異なる方法で動作し、これらの差異は、設計/実装の選択に影響し得る。一般的に言えば、ファイルシステム認識格納制御装置2721は、ホストファイルシステムデータ構造2723の場所を格納2722中で突き止め、ホストファイルシステムデータ構造2723を分析して、ホストファイルシステム2711の格納方法を決定する。次いで、ファイルシステム認識格納制御装置2721は、そのような格納方法に基づいてユーザデータ格納2724を管理することが可能である。
図28は、本発明の例示的実施形態に従った、ファイルシステム認識格納制御装置2721の高レベル論理フロー図である。ブロック2802において、ファイルシステム認識格納制御装置2721は、ホストファイルシステムデータ構造2723の場所を格納2722中で突き止める。ブロック2804において、ファイルシステム認識格納制御装置2721は、ホストファイルシステムデータ構造を分析して、ホストファイルシステム格納方法を決定する。ブロック2806において、ファイルシステム認識格納制御装置2721は、ホストファイルシステム格納方法に基づいてユーザデータ格納を管理する。
図29は、本発明の例示的実施形態に従った、ホストファイルシステムデータ構造2723の場所を突き止める論理フロー図である。ブロック2902において、ファイルシステム認識格納制御装置2721は、そのパーティションテーブルの場所を格納制御装置データ構造2726中で突き止める。ブロック2904において、ファイルシステム認識格納制御装置2721は、パーティションテーブルを解析して、ホストOSデータ構造2725を含むOSパーティションの場所を突き止める。ブロック2906において、ファイルシステム認識格納制御装置2721は、OSパーティションを解析して、ホストOS2712を特定し、ホストOSデータ構造2725の場所を突き止める。ブロック2908において、ファイルシステム認識格納制御装置2721は、ホストOSデータ構造2725を解析して、ホストファイルシステム2711を特定し、ホストファイルシステムデータ構造2723の場所を突き止める。
ひとたびファイルシステム認識格納制御装置2721がホストファイルシステムデータ構造2723の場所を突き止めると、それはデータ構造を分析して、ホストファイルシステム2711の格納方法を決定する。例えば、ファイルシステム認識格納制御装置2721は、ホストファイルシステム2711によってもはや使用されていない格納ブロックを特定するため、およびホストファイルシステム2711によって格納されたデータの種類を特定するため等に、ホストファイルシステムデータ構造2723を使用してもよい。次いで、ファイルシステム認識格納制御装置2721は、ホストファイルシステム2711によってもはや使用されていない格納スペースを動的に再利用し、および/またはデータ型に基づいてユーザデータ2724の格納を管理することが可能である(例えば、ほんの数例を挙げれば、アクセス頻度の高いデータを圧縮せず、かつ連続ブロックで保存してアクセスを促進し、アクセス頻度の低いデータを圧縮および/または不連続ブロックで保存して、データ型に基づいて異なる符号化スキームを適用する)。
図30は、本発明の例示的実施形態に従った、未使用の格納スペースを再利用するための論理フロー図である。ブロック3002において、ファイルシステム認識格納制御装置2721は、ホストファイルシステム2711によって使用されていないとしてマークされているブロックを特定する。ブロック3004において、ファイルシステム認識格納制御装置2721は、ホストファイルシステム2711によって使用されないとしてマークされているが、ファイルシステム認識格納制御装置2721によって使用されるとマークされている、あらゆるブロックを特定する。ブロック3006において、ファイルシステム認識格納制御装置2721は、ファイルシステム認識格納制御装置2721によって使用されるとしてマークされているが、ホストファイルシステム2711によってもはや使用されていない、あらゆるブロックを再利用し、再利用された格納スペースを追加格納に対して利用可能にする。
図31は、本発明の例示的実施形態に従った、データ型に基づいてユーザデータ2724の格納を管理するための論理フロー図である。ブロック3102において、ファイルシステム認識格納制御装置2721は、特定のユーザデータ2724と関連するデータ型を特定する。ブロック3104において、ファイルシステム認識格納制御装置2721は、任意で、データ型に基づいて選択された格納レイアウトを使用して、特定のユーザデータ2724を格納する。ブロック3106では、ファイルシステム認識格納制御装置2721は、任意で、データ型に基づいて選択された符号化スキーム(例えば、データ圧縮および/または暗号化)を使用して、特定のユーザデータ2724を符号化する。こうして、ファイルシステム認識格納制御装置2721は、データ型に合わせた異なるレイアウトおよび/または符号化スキームを使用して、異なる種類のデータを格納することが可能である。
スカベンジャの一例は、いわゆる「ガーベッジコレクタ(garbage collector)」である。上記のように、ガーベッジコレクタは、ホストファイルシステムによってもはや使用されないクラスタを解放するために使用してもよい(例えば、ファイルが削除される時に)。一般的に言えば、ガーベッジ収集は、使用されていないブロッックを見出し、それらのホストLSAを計算し、LSAに基づいてそれらのCATエントリの場所を突き止めることによって、機能する。特定LSAに対してCATエントリがない場合は、クラスタはすでに使用されていない。しかし、CATエントリの場所が突き止められた場合、参照カウントが減少され、カウントがゼロになればクラスタは解放される。
1つの懸案事項は、ホストファイルシステムが使用中のブロックと、以前に使用し、ある時点で使用されていないとマークされたブロックを、ガーベッジコレクタが区別することが難しい場合があることである。ホストファイルシステムがブロックを書き込むと、格納システムは、データに対するクラスタならびにそれを表すCATエントリを割り当てる。その時点より、たとえホストファイルシステムが後にそのブロックを使用しなくなるとしても、クラスタは、概して使用中であるように思われる(すなわち、クラスタは、有効なCATエントリにより、なおも使用中となる)。
たとえば、特定のホストファイルシステムは、使用されたディスクブロックを追跡するためにビットマップを使用する。最初は、ビットマップは、たとえばすべてのビットをクリアすることによって、すべてのブロックが使用されていないことを示す。ファイルシステムが使用されると、ホストファイルシステムは、使用されていないブロックビットマップを使用することによって、ブロックを割当てる。格納システムは、クラスタおよびCATエントリを以前に概略された(outlined)ものとして割当てることによって、物理的格納をこれらのファイルシステム割当てと関連づける。ホストファイルシステムが、一部のブロックを、使用されていないプールに解除するときに、使用されていないブロックビットマップにおける対応するビットをクリアする必要が単にある。格納システムの上で、このことは、ホストの使用されていないブロックビットマップの一部をたまたま含むクラスタへの書き込みとして、一般的に明らかにされ、おそらく解放された実際のクラスタに対するI/Oがない(しかし、たとえば、ホストファイルシステムが一部の強化されたセキュリティーモードで実行している場合には、解放されたクラスタに対するI/Oがあり得、その場合には、長期経過の(stale)クラスタコンテンツが攻撃者によって読み出され得る可能性を低減させるために、ゼロまたはランダムデータのクリプトストロングハッシュ(crypto strong hash)をクラスタにおそらく書き込み得る)。さらに、ホストファイルシステムが、新しい割当てリクエストを満たすときに以前に解放したブロックを再使用するという保証はない。したがって、ホストファイルシステムが、格納システムの観点から、新しい、すなわち以前に再使用されたブロックを割当て続ける場合には、格納システムは、使用されていないクラスタをすぐに使い果たしてしまい、圧縮によって再生され得るどんなスペースにも左右される。たとえば、ファイルシステムブロックが4kであると想定すると、ホストが、ファイルシステムブロック100〜500を割当て、次に使用されていないブロック300〜500を割当て、次にブロック1000〜1100を割当てる場合には、合計のファイルシステム使用は300ブロックになり、それでもアレイは500クラスタを使用する。
本発明の例示的な実施形態において、格納システムは、ホストファイルシステムのレイアウトにアクセスし、その使用されていないブロックビットマップを分析し、ファイルシステムによってもはや使用されていないクラスタを特定するためにその情報を使用することによって、ホストファイルシステムのディスクリソースの解放を検出し得る。格納システムが未使用のクラスタをこのように特定できるためには、格納システムは、ファイルシステムの使用されていないブロックビットマップの場所を突き止めて理解することができなければならない。したがって、格納システムは、所定のセットのファイルシステムを一般的にサポートし、格納システムは、ファイルシステムについて、使用されていないブロックビットマップの場所を突き止めて利用するのに十分なほど内部の働きを「理解」する。サポートされないファイルシステムについては、格納システムは、おそらくガーベッジ収集を実行することができず、したがって、過剰にコミットされることを回避するために、アレイの実際の物理的サイズの公示のみをするべきである。
ファイルシステムタイプ(たとえば、NTFS、FAT、ReiserFS、ext3)を決定するために、ファイルシステムのスーパーブロック(または同等の構造)の場所が突き止められる必要がある。スーパーブロックを見出すために、パーティションテーブルが分析されて、OSパーティションの場所を突き止める。OSパーティションの場所が突き止められると想定すると、スーパーブロックの場所を突き止める目的のために、OSパーティションが分析され、それによってファイルシステムタイプを特定する。ひとたびファイルシステムタイプがわかると、使用されていないブロックビットマップを見出すために、レイアウトが分析され得る。
使用されていないブロックの検索を容易にするために、たとえば、非公式の非冗長ゾーンに格納され得る使用されていないブロックビットマップのコピーを作り、そのコピーを使用して検索を実行することによって、ホストファイルシステムビットマップの履歴データが保たれ得る。ビットマップのサイズを考慮すれば、情報は、ビットマップ全体についてではなく、一度に比較的少数のクラスタについて保たれ得る。ガーベッジ収集が実行されるときに、現在の使用されていないブロックビットマップが、クラスタごとに履歴コピーと比較され得る。割当てられた状態から使用されない状態へと移行する任意のビットマップエントリが特定され得、ごみあさりをする(scavenging)操作が、再使用の良い候補であるクラスタに正確に向けられることを可能にする。それぞれのビットマップクラスタが処理されると、ビットマップ操作の経過する履歴を維持するために、履歴コピーが現在のコピーと置き換えられ得る。時間が経つにつれて、使用されていないブロックビットマップのコピーは、時間的にばらばらなクラスタの寄せ集めになるが、使用されていないエントリの場所を突き止めるために、現在のコピーがつねに使用されるので、このことは何の問題も引き起こさない。
特定の条件下で、たとえば、ホストファイルシステムが、使用されていないブロックビットマップを使用してディスクブロックを割当て、次にデータブロックを書き込み、次に変更されたビットマップをディスクに流し戻す場合には、使用されていないブロックビットマップに関する競争状態があり得る。そのような場合には、たとえファイルシステムがクラスタを使用中であるとしても、ガーベッジコレクタがクラスタを解放し得る。このことはファイルシステムの破損につながり得る。格納システムは、そのような条件を回避または処理するようにインプリメントされるべきである。
ガーベッジ収集はかなり高価な操作であり得、軽量のごみあさりがバックエンドI/O帯域幅を消費するので、ガーベッジ収集は過剰に使用されるべきではない。ガーベッジコレクタは、軽いバックグランドの遅いごみあさりから、積極的で重量の、または高優先度でさえあるごみあさりにわたる、いくつかのモードにおいて実行することができるべきである。たとえば、ガーベッジコレクタは、スペースの30%が使用されるときに、または少なくとも週に一回、軽く実行され得、スペースの50%が使用されるときに、やや激しく実行され得、ディスクスペースの90%以上が使用されるときに、すっかり高優先度のごみあさりで実行され得る。ガーベッジコレクタの積極性は、再利用するクラスタの目標数に限定することによって、およびおそらくそれぞれの収集実行について最大の許容できるI/Oカウントに限定することによって、制御され得る。たとえば、ガーベッジコレクタは、わずか10,000のI/Oを使用して1GBを再使用するように構成され得る。再利用リクエストを達成できなかったことは、次回に実行されるときにより積極的に操作するように、コレクタへのフィードバックとして使用され得る。ガーベッジコレクタがホストファイルシステム全体の使用されていないブロックビットマップを分析することと、おそらく可能なすべてのブロックを再使用することとの許可を、ガーベッジコレクタに与える、「すべて再使用」モードもあり得る。これは、アレイが(ほとんど)完全に満杯であるときに、クラスタを再使用する最後の試みとして行われ得る。ガーベッジコレクタは、そのルールを適用するために定期的に実行され得、ごみあさり操作を実行することを決定し得るかまたはし得ない。ごみあさり操作は、別のモジュール(たとえば領域マネージャが領域を構築するためにクラスタを見出そうと努力しているときの領域マネージャ)から明示的に要求されることもできるべきである。
ガーベッジ収集機能は、状態インジケータメカニズムの中に結びつけられ得る。たとえば、ある時点において、格納システムは「赤色」状態にあり得るが、進行中のガーベッジ収集操作は「赤色」状態を消去するのに十分なスペースを解放し得る。関連する状態情報を示すために、追加のインジケータ状態が使用され得る(たとえば、赤色インジケータは、ガーベッジ収集操作が進行中であることを示すように点滅させられ得る)。
図21は、本発明の例示的な実施形態に従った、格納アレイの関連するコンポーネントを示す模式的なブロック図である。なかでも、格納アレイは、シャーシ2502を含み、格納マネージャ2504はシャーシ2502を介して複数の格納デバイス25081〜2508Nと通信し、格納デバイス25081〜2508Nはそれぞれ複数のスロット25061〜2506Nを通してシャーシに結合される。それぞれのスロット25061〜2506Nは、一つ以上のインジケータ25071〜2507Nと関連づけられ得る。なかでも、格納マネージャ2504は、上述の機能性をインプリメントするための種々のハードウェアおよびソフトウェアのコンポーネントを一般的に含む。ハードウェアコンポーネントは、プログラムコード、データ構造、およびデータを格納するためのメモリ、ならびにプログラムコードを実行するためのマイクロプロセッサシステムを一般的に含む。
ファイルシステム認識格納制御装置2721を実装することに対する1つの懸案事項は、多くのホストファイルシステムがリアルタイムでデータ構造(すなわち、メタデータ)をアップデートしないことである。例えば、ファイルシステムのジャーナルレコードは通常、すでに起こったトランザクションに対するユーザデータのうちの全てを保存することを保証せず、または、そのようなトランザクションに対するメタデータのうちの全てを回復することを保証しないが、概して、一貫した状態に回復する能力のみを保証する。性能および効率に対して、ファイルシステムのジャーナルレコードはしばしば、ユーザデータ書き込みとメタデータ書き込みとの間の、ある程度の非同期性を備え持つ。特に、ディスクへのメタデータ書き込みは、ゆっくりと行われることが一般的であるため、ユーザデータアップデートと対応するメタデータアップデートとの間には遅延がある。ジャーナル書き込みもまた、一部のファイルシステム(Microsoft Windows(登録商標) InternalsのEd4によるNTFS等)においてゆっくりと行われることがある。さらに、ゆっくりとしたメタデータ書き込みは、トランザクションごとの方式でジャーナルのプレイアウトによって行われることがあり、それには、一時的にメタデータを、すでにディスク上にあるユーザデータと矛盾している状態に追い込む、かなりの可能性がある。このことの例は、ホストがクラスタを再割り当てし、その再割り当てされたクラスタに対応するユーザデータを送信した後に、割当解除を示すビットマップアップデートであろう。よって、格納システムは、概して、ユーザデータの現在の状態を確実に示さないメタデータアップデートに対処する必要がある。前の例では、そのことは、概して、クラスタが再利用可能でありユーザデータが廃棄可能であるということを意味する割当解除を、格納システムが解釈できなかったことを、意味し得る。
メタデータおよびジャーナルアップデートが、対応するユーザデータアップデートに完全に非同期であり、いつでも起こり得る場合、格納システムは、ファイルシステムの内部の働きを比較的詳細に理解する必要があり、したがって、適切な決定を行うために広範囲な状態情報を格納する必要があり得る。しかし、下記の本発明の具体的な実施形態は、メタデータアップデートがそれらに関連するユーザデータ書き込み後の比較的決定論的な時間窓以内(例えば、1分以内)で発生することを前提として、動作するように設計されている。そのような実施形態は、ファイルシステムの内部の働きの詳細な理解および広範囲な状態情報の格納を必要とされないが、操作中のそのような窓に準拠しないホストファイルシステム(VxFSが一例であってもよい)、またはユーザデータアップデートと対応するメタデータアップデートとの間の長い遅延をもたらす境界条件(例えば、概して格納システムの制御を越え、いずれにしてもデータ損失につながる場合がある、ホストからの機能の損失、または、格納システムが検出することにより、タイムリーなホスト活動を仮定する任意の挙動を抑制し得る、接続性の損失)に対処するために、特別な配慮を行う必要があり得るという点で本質的に複雑性と機能性との間のトレードオフであると理解される。
1つの例示的実施形態では、スカベンジャは、純粋に非同期方式で動作し得る。この実施形態では、スカベンジャは、全体または部分的のいずれかで、周期的にビットマップをスキャンし、ビットマップをCATに含まれる情報と比較して、格納アレイクラスタのうちのいずれかを再利用することが可能であるかどうかを決定する、純粋な非同期タスクであってもよい。ビットマップをチェックする前に、システムはまた、ビットマップが移動したかどうかを決定するために、ビットマップの位置を含むブロックをチェックしてもよい。
純粋な非同期スカベンジャの1つの利点は、主要データパス内のプロセッサオーバーヘッドに対する直接的影響が本質的にないことであるが、略非同期ディスクI/O(例えば、論理的に4kのクラスタに分割されて64MBビットマップを有する2TBボリュームに対しては、ビットマップ全体を読み出すことは、スカベンジャが実行する度に64+MBのディスクデータを読み出すことを伴う)を伴ってもよく、したがって、スカベンジャが実行する頻度に応じて全体的なシステム性能に影響してもよい。したがって、スカベンジャ頻度は、利用可能な格納スペースおよび/またはシステム負荷の量に応じて異なってもよい。例えば、利用可能な格納スペースが豊富であるか、またはシステム負荷が高いと、スカベンジャ機能はあまり頻繁に実行されない可能性がある。スカベンジャ頻度の低下は、概して、格納スペースが再利用される割合を減少させ、それは、概して格納スペースが豊富である時に容認可能である。一方、利用可能な格納スペースが乏しくシステム負荷が低いと、格納スペースが再利用される割合を増加させるために、スカベンジャ機能をさらに頻繁に実行することが可能である(追加された処理オーバーヘッドを犠牲にして)。
別の例示的実施形態では、スカベンジャは、部分的に同期で、部分的に非同期の方式で動作し得る。この実施形態では、スカベンジャは、例えば、主要書き込み対処パスに付加的チェックを追加することによって、ビットマップの変化が起こるとそれらを監視することが可能である。スカベンジャは、関心のLBA範囲を含むブート時におけるテーブルを構築することが可能である(以降、ビットマップロケータテーブル(Bitmap Locator Table)またはBLTと呼ばれる)。初期化されていないディスク、または初期化されているがパーティションされていないディスクに対しては、BLTは、概して、LBA0しか含まない。完全に初期化されフォーマットされたディスクに対しては、BLTは、概して、LBA0、全パーティションブートセクタのLBA、ビットマップメタデータを含むLBA、およびビットマップデータ自体を含むLBA範囲を含む。
主要書き込み対処パス(例えば、HRT)は典型的に、対処されている書き込みの詳細を伴うスカベンジャを呼び出し、その場合、呼び出しは、概して、関心のLBA範囲と重複する書き込みを特定する目的で、BLTと書き込みリクエストのLBAを内部で相互参照する。次いで、スカベンジャは、そのほとんどが非同期タスクで行われ得る書き込みを解析する必要があるが(その場合、主要な詳細は、概して、下記のように非同期タスクに対して格納される必要がある)、重要な書き込みは、インラインで解析される(例えば、アップデートが再配置されたビットマップを潜在的に示す場合、さらなる書き込みが相互参照される前にBLTをアップデートできるように、その書き込みをインラインで解析され得る)。純粋な非同期スカベンジャに関する上記のように、非同期タスクの頻度は、利用可能な格納スペースおよび/またはシステム負荷の量に応じて異なり得る。
非同期タスクに対する格納は、キューの形となり得る。しかし、単純なキューは、同じブロックに対する複数のリクエストをキューに入れることを可能にし、これは、書き込みのキャッシュの意味により、多数のリクエストがキャッシュ中の同じデータブロック(すなわち、最新のデータ)を指しやすくなるために起こり得、概して、同じLBAを表す複数のリクエストを保持する理由がないために、非効率的である。このことは、キューを調べ、同じブロックに対する以前のリクエストを除去することによって、緩和することが可能である。さらに、利用可能な格納スペースおよび/またはシステム負荷の量に応じて非同期タスクの頻度が異なると仮定すると、非同期タスクが抑制される激しい活動の期間(何日も持続される場合がある)の間に、その最大サイズに到達するという予期が、キューに提供されるべきである。システムが同じLBAに対する複数入力を許さないと仮定すると、キューの最大理論的サイズは、LBAのサイズおよびビットマップ内のLBAの数の積であり、それは非常に大きなキューサイズをもたらし得る(例えば、2TBボリュームは、64MBビットマップ(すなわち、128Kブロック)を有し、したがって約128K*4=512Kのキューサイズを必要とする場合があり、16TBボリュームは、約4MBのキューサイズを必要とする場合がある)。
非同期タスクに対する代替的格納は、ビットマップの形となり得て(以降、「ビットマップブロックアップデートビットマップ(Bitmap Block Updates Bitmap)」または「BBUB」と呼ばれる)、各ビットが実ビットマップの1ブロックを表す。同じビットがそのようなリクエストのそれぞれに対して設定されているため、BBUBは本質的に、同じブロックに対する複数のリクエストを回避するので、複数のリクエストはBBUBにおいて一度しか現れない。さらに、非同期タスクの頻度にかかわらず、BBUBのサイズは本質的に固定されており、概して、キューより少ないスペースを占める(例えば、BBUBは、2TBボリュームに対して16KBのメモリ、または16TBボリュームに対して128KBを占める)。実ビットマップが移動する場合、格納システムはBBUBにおけるビットのマッピングを容易に調整することが可能であるが、概して、ホストがデータをコピーし終わる前に保留中のリクエストを新しい位置にマップしないように配慮する必要がある(実際、ホストファイルシステムがいずれにしても全LBAを書き換えるという前提で、ビットマップを消去することが可能であり得る)。BBUBは、非揮発性メモリ(NVRAM)に配置され、現在のBBUBの損失を防いでもよく、または、現在のBBUBが失われる可能性があり、再起動の後しばらくしてビットマップの完全スキャンを実行し、失われた情報を回復する必要があることを理解して、揮発性メモリに配置してもよい。ビットマップは本質的に、リクエスト数の容易な指標を非同期タスクに提供しないため、非同期タスクがビットマップ全体を通してスキャンして、単に何もアップデートされていないと決定する必要がないように、格納システムは、ビットマップにおいて設定されたビット数についての統計を維持することが可能である。例えば、格納システムは、ビットマップ中にいくつのビットが設定されているかというカウントを維持する場合があり、カウントに基づいて非同期タスクの頻度を調整してもよい(例えば、カウントがユーザ設定可能であってもよい所定の閾値に到達できるまで、非同期タスクを実行しない)。そのような方策は、例えば、多数のマップセクション(例えば、1Kのチャンク)のそれぞれに対する設定ビットの別個のカウントを維持し、また最高カウントを有するマップセクションを把握することによって、さらに改良され得、それにより非同期タスクは、最大報酬を返す可能性があるマップセクションのみを解析することが可能である。
アップデートを解析することは、概して、異なるLBAに対する異なる論理を伴う。例えば、LBA0の変更は、概して、パーティションテーブルが追加されたこと、またはパーティションがテーブルに追加されたこと、またはパーティションが削除されたことを意味する。パーティションブートセクタのアップデートは、ビットマップメタデータが再配置されたことを意味する場合がある。ビットマップメタデータのアップデートは、ビットマップが除去されたこと、または拡張されたことを意味する場合がある。ビットマップ自体のアップデートは、クラスタの割当または割当解除を示す場合がある。アップデートが非同期的に解析される場合、非同期タスクが実行する時までに、新しいデータが古いデータを上書きしているかもしれないため、システムは、概して、古いデータを新しいデータと容易に比較することができない。この問題を回避するために、システムは、比較のために古いデータの別個のコピーを保持する場合があり、または、マップを通して反復し、未設定ビットをCATと比較する場合がある(これは、わずかに多くのプロセッサオーバーヘッドを必要とするが、より少ないディスクI/Oを必要とする場合がある)。上記のように、ビットマップの状態は、ユーザデータと同期しなくてもよいため、ビットマップをCATと単純に比較することは、概して、付加的な論理および状態情報を必要とする。さらに、ビットマップデータのコピーを保持することは、格納システムが新しいデータと古いデータと比較することを可能にすることにより、正確には何が変わったのかを決定するが、上記のように、格納システムは、概して、状態自体を信頼できる以上に、現在のユーザデータの正確なビュー(view)として状態遷移を信頼することはできない。
さらに別の例示的実施形態では、スカベンジャは、純粋な同期的方式で動作し得る。この実施形態では、スカベンジャは、書き込みが発生するとそれらを処理する。純粋な同期実施形態の1つの利点は、非同期タスクの操作およびその関連格納と関連する複雑性を回避することであるが、それはホストからの書き込みに対処する重要な時期の間にプロセッサ上でオーバーヘッドを差し挟み、非同期メタデータアップデートを補うために付加的なロジックおよび状態情報が必要とされる場合がある。
非同期ビットマップアップデートとの関連でクラスタを再利用することに対する1つの懸案事項は、ユーザデータの状態を正確に反映しないビットマップ値に基づいて、スカベンジャがクラスタを不適切に解放するかもしれないことである。そのような問題を防ぐために、格納システムは、それが行うクラスタアクセスの何らかの履歴(例えば、それがクラスタ中のユーザデータに最近アクセスしたか否か)を保持し、メタデータアップデートがそのクラスタに対して保留中ではないことを確実にするために、クラスタがある以前の時間間隔にわたって休止している場合にだけクラスタを再利用する。例えば、格納システムは、クラスタの再利用を行う前に、クラスタが少なくとも1分間休止することを必要とする場合がある(一般的に言えば、休止時間を増やすと、不適切な再利用の危険性が低減するが、データ削除への反応における待ち時間が増加するため、ここにはトレードオフがある)。格納システムは、クラスタ書き込みのみを追跡することが可能であるものの、格納システムは、加えて、追加ディスクI/Oを犠牲にするが、クラスタ活動を徹底的に評価するためにクラスタ読み出しを追跡することが可能である。休止時間は、固定値となり得るか、または異なるファイルシステムに対して異なり得る。
クラスタアクセスは、例えば、スカベンジャ実行に対するアクセス時間の指標として、スカベンジャサイクル数をCATに書き込むことによって、追跡することが可能である。
あるいは、クラスタアクセスは、データに書き込む前にビットをファイルシステムのビットマップに書き込むことによって、追跡することが可能である。しかし、ファイルシステム操作とのあらゆる不利な相互作用を回避するために、ファイルシステムのメタデータのそのような修正は、慎重に調整されなければならない。
あるいは、クラスタアクセスは、各クラスタ、ブロック、チャンク(どんなサイズでも)に対するビットを使用して、追跡することが可能である。ビットは、概して、そのエンティティがアクセスされた時に設定され、スカベンジャがその次の実行を完了する時、またはスカベンジャが次にクラスタを再利用しようとする時に、リセットされる場合がある。スカベンジャは、概して、再利用を行おうとする時にこのビットがすでにリセットされていた場合にだけ、クラスタを再利用し、再利用自体は、実ホストファイルシステムビットマップにおける対応ビットがクリアにされることによって駆動される。これらのビットは単純ビットマップとして一緒に保持することが可能であるか、または、分散ビットマップとしてCATに追加することが可能である(CATレコードごとにさらに1ビットを必要とする)。単純ビットマップアプローチは、ほとんどのデータ書き込み操作に対する付加的な読み出し−修正−書き込みを必要とし、ビットマップがメモリにキャッシュされない限り、主要データパスの性能の低下を潜在的に引き起こし得る(ビットマップは揮発性メモリにキャッシュすることが可能であり、これは、ビットマップが予期しない機能停止により失われた場合に問題となり得、または不揮発性メモリでは、メモリ制約のためにより小さいビットマップを余儀なくさせる場合があり、したがって粒度がより低くなる。)。CATアプローチは、概して、J2およびその使用されていないNVRAMキャッシングから利益を得る。
あるいは、クラスタアクセスは、ビットマップアップデートが受信される時、およびクラスタ修正が行われる時のタイムスタンプを維持することによって、追跡することが可能である。次いで、クラスタ修正にビットマップアップデートよりも後のタイムスタンプがある場合、システムは、概して、クラスタを解放しない。ビットアプローチを超えるこのアプローチの1つの利点は、スカベンジャが、どのくらい前に最後のアクセスが発生したかを決定し、十分に前であれば、クラスタを即時に再利用することが可能であるということである。タイムスタンプはまた、CATレコードに追加してもよい。あるいは、フィールドはスカベンジャ操作に対する経過時間を示すことしか本当に必要としないため、包括的識別子を各スカベンジャ実行に割り当ててもよい。そして、システムは、包括的識別子の値を示すために、CAT内の同様のフィールドを使用してもよい。包括的識別子は、どのスカベンジャ実行がごく最近完了したか、または次の予定であったか、またはクラスタが最後にアクセスされたのはいつだったかを特定してもよい。次いで、この情報は、経過時間の尺度としてスカベンジャによって使用され得る。CATレコード中のスペース消費を節約するために、識別子は、1バイトカウンタだけになり得る。カウンタラッピングによる間違った経過時間決定は、実際よりもはるかに新しく見える古いクラスタとなる。これらのクラスタは、次の実行で再利用される。フィールドは、NVRAMに格納され、一部のクラスタアクセスが早期に時間経過することを引き起こし得る、フィールドが再起動の度にゼロにリセットされることを防いでもよい。
よって、例えば、全スカベンジャ実行は、1バイト識別子値と関連付けられ、これは、スカベンジャに対する識別子が、カウンタの増分後の値となるように、スカベンジャが起動する度に増分するNVRAM中の包括的カウンタとして実装され得る。CATマネージャは、クラスタのアップデートを提供する時はいつでも、包括的カウンタの現在の値を使用することが可能であり、対応するCATレコード中にその値のコピーを格納することが可能である。そのような実装は、CATマネージャ論理の修正を必要とする。
あるいは、クラスタアクセスは、ラッピングリスト中にクラスタアップデートの短い履歴を保持することによって、追跡することが可能である。次いで、スカベンジャは、リストを検索して、それが解放しようとしていた任意のクラスタがホストによって最近アクセスされていなかったことを検証し得る。リストのサイズは、概して、実装固有となる。それがどれほど長くても、格納システムは、概して、リストが満杯になり得る前に非同期タスクを実行できることを保証しなければならず、それは平穏な期間までタスクを延期する能力を低下させる。
ごみあさりをサポートする格納システムでは、早期再利用、特に早期再利用のために失敗する読み出し(すなわち、スカベンジャによって解放されたクラスタから読み出す試み)、また、割り当てられていないクラスタへの書き込み(概して、単に割当をもたらし、したがって無害となるはずである)を特定して追跡することが望ましい場合がある。状況によっては、ファイルシステムビットマップに基づくエラーを特定することが可能である(例えば、ユーザデータ書き込みからのビットマップの相互参照、および適切なビットが設定されていることのチェック)が、それは、ユーザデータの前にビットマップアップデートが完了することが保証されている場合に限られ、常に可能ということではない。あるいは、ビットマップを解析する時に、スカベンジャは、割り当てられたビットが割り当てられたクラスタに実際に対応するかどうかをチェックし、対応しなければクラスタ、または少なくともCATレコードを割り当て、スカベンジャから強制的に行われた割当を示す、それぞれのそのようなCATレコードに、ビットを設定し、ビットが、クラスタに対するデータ書き込みによってリセットされ、そして次のスカベンジャ実行で再びビットをチェックし、それがなおも設定されていれば知らせる。この予防策により途中停止させられたクラスタ再利用の回数のカウント等の、自己診断法をさらに含み、どのファイルシステムがこれをどの程度行ったのかという尺度をもたらすことが可能である。
上記の3種類のスカベンジャは、例示的にすぎず、本発明をいずれの特定設計または実装にも限定しないことに注目すべきである。各スカベンジャの種類には、特定の実装に対してそれを特に適切または不適切にする場合がある、ある相対的利点および不利点がある。さらに、特定の実装はスカベンジャの種類のうちの2つ以上をサポートし、例えば、ホストファイルシステム、利用可能な格納スペースの量、およびシステム負荷等のようなものに基づいて、必要に応じてそれらを動的に切り替え得ることに注目すべきである。非同期タスクに対する情報を格納するためにBBUBを使用し、かつクラスタアクセスを追跡するためにCAT内のバイトサイズのスカベンジャ実行カウンタ(ある種のタイムスタンプとして)を使用する、部分的に同期性で、部分的に非同期性のスカベンジャが、特定の実装に対して検討される。
いくつのクラスタがホストファイルシステムによって使用されているかを把握するために、スカベンジャに加えて、またはその代わりに、別個のモニタを使用することが可能である(例えば、ホストファイルシステムが、新しいブロックを使用するよりもむしろ割当解除されたブロックを確実に再利用すると分かっていれば、スカベンジャは省略される場合があるため、再利用は必要とされず、監視が十分となる。例えば、スカベンジャを実装するシステムでは、モニタは、重複として省略される場合がある)。一般的に言えば、モニタは、いくつのビットがビットマップに設定されるのか決定する必要があるのみで、どのビットが設定され、どのビットがクリアであるかを正確に知る必要はない。さらに、モニタは、正確なビットカウントを必要としなくてもよいが、設定ビットの数がある閾値よりも大きい、または小さいかどうか、あるいは数が同じ領域に対する以前の値よりも大きいか、または小さいかどうかを決定する必要があるのみであってもよい。したがって、モニタは、ビットマップ全体を解析する必要がないかもしれない。上記のスカベンジャの実施形態については、モニタ機能は、非同期タスクを使用して全体または部分的に実装することが可能であり、それは、周期的に新しいデータをCATと比較するか、またはビットマップのコピーを維持して、コピーを新しいデータで上書きする前に、現在のビットマップ(新しいデータ)をコピー(古いデータ)と比較することが可能である。
便宜上、様々な設計および操作の考慮は、主にNTFSとの関連で、スカベンジャを参照して下記で論じる。しかし、設計および操作の考慮の多くは、同様にモニタに該当することを十分理解するべきである。
図32は、本発明の例示的実施形態に従った、スカベンジャ3210の関連構成要素を示す略ブロック図である。とりわけ、スカベンジャ3210は、ビットマップブロックアップデートモニタ(BBUM)3211、各LUNに対するBLTを含むビットマップロケータテーブル(BLT)3212の一群、各パーティションに対する1つのBBUBを含むBBUB3213の一群、非同期タスク3214、および割当解除スペーステーブル(De−allocated Space Table/DST)3215を含む。これらの構成要素のそれぞれを下記でさらに詳述する。同様に下記でさらに詳述するように、BBUM3211には、HRM3220から受信される呼び出しを通して書き込み操作が通知される。
スカベンジャ3210は、各LUNに対するBLT3212を含む。各BLT3212は、パーティション識別子、LBA範囲、LBA範囲の役割の表示、およびLBA範囲を同期または非同期的に分析するべきか否かを示すフラグを含む、一連のレコードを含む。各BLTは、パーティションに依存しないLBA0に対するエントリがある。BLTは、概して、そのLUN上に入って来る書き込みに対する高速LBAベースのルックアップを提供し(それらが最初にどのパーティションに属するのかをチェックせずに)、かつLBA0書き込みに対する比較的高速のパーティションベースのルックアップを提供する(例えば、格納に対しては選別されたベクタ、ルックアップに対しては、開始LBAの下限2分探索法および前の要素がルックアップされているLBAよりも高い最後のLBAを有するかどうかのチェックを使用して、達成され得る)ことが必要とされる。BLTは、概して、例えば、LoadDiskPack呼び出しの間、あらゆる通過するホスト書き込みの前にプログラムされる必要がある。BLTは、LBA0によりプログラムされ、これはパーティションテーブルの位置であるため、したがってパーティションの作成は、このLBAへの書き込みを伴う。LBA0は、アップデートが即時解析を必要とする位置として、このテーブル内でフラグを付けられる。
スカベンジャ3210は、格納システムによってサポートされる各パーティションに対するBBUB3213を含む。各BBUB3213は、それが関連するファイルシステムビットマップのサイズに対して適切にサイズ決定される。各BBUB3213は、ビットマップにいくつのビットが設定されているかを反映するカウンタと関連する。BBUB3213はまた、各ビットマップがその対応するファイルシステムビットマップにどのように関連するかを示す、何らかのマップ情報も含む。
スカベンジャ3210は、各LUNに対するDST3215を含む。各DST3215は、レコードにつき1つのLBA範囲を含む。テーブル中に存在する各LBA範囲は、CATから再利用される必要がある、削除または切断されたパーティションの一部である。BBUM3211は、例えば、同期処理中に再利用に対する未使用格納エリアを特定すると、DST3215をアップデートしてもよい(その場合、BBUM3211は、DST3215にLBA範囲を追加する)。同様に、非同期タスク3214は、非同期処理中に再利用に対する未使用格納エリアを特定すると、DST3215をアップデートしてもよい(その場合、DST3215にLBA範囲を追加する)。非同期タスク3214は、非同期的に未使用格納スペースを再利用するために、DST3215を使用する。DST3215は、クリーンではないシャットダウンに対して回復機能がある方法で持続的に格納してもよく、または、例えば、再起動後に完全スキャンを行って、いずれのボリュームにも属さない割り当てられたクラスタを見出すことによって、DST3215の損失から回復するように、付加的な論理が提供されてもよい。
BBUB3213およびDST3215の格納は、実装固有の決定である。例示的実施形態では、BBUB3213は、大きすぎてNVRAMに格納できないため、揮発性メモリまたはディスクに格納してもよい一方で、DST3215は、不揮発性メモリ、揮発性メモリ、またはディスクに格納してもよい。DST3215およびBBUB3213が完全に揮発性である場合、スカベンジャ3210は、概して、DST3215およびBBUB3213の損失(例えば、予期しないシャットダウンによる)から回復することが可能でなければならない。回復は、例えば、CAT全体を通してスキャンし、それを現在のパーティションおよびクラスタビットマップ情報と比較して、各クラスタが既知のパーティションにマップされているか、および対応するファイルシステムのクラスタビットマップにおいて割り当てられているかを確認することによって、達成される場合がある。別の可能性は、ボリューム外のディスクスペースに対する状態情報が、再起動にわたって保存されるように(潜在的に、パーティション外のクラスタについてのCATMのクエリを行う必要性を防ぐ)、DST3215をNVRAMに格納し、BBUB3213を揮発性メモリに残すことであるが、クラスタビットマップの現在の状態は失われ、全クラスタビットマップの完全スキャンを余儀なくする。そのようなビットマップスキャンは、例えば、全ての必要な状態情報をディスク上に格納し、それを再起動時に単にリロードすることによって、低減または排除することが可能である。スカベンジャ3210はシャットダウンの通知を予期できないため、同期的にアップデートすることによって、または数ミリ秒あるいは数秒以内に再び書き込むことによってのいずれかで、レコードをリアルタイム状態と密接に同期化させておく必要がある。たとえホストが実際にシャットダウンされなくても、ホストからの数秒の非活動の後に意図的なシャットダウンが起こると仮定することは合理的と思われるため、数秒以内にアップデートすることは、ほとんどの状況に対しておそらく適切であるが、I/Oの半ばで発生したシャットダウンは、なおも完全スキャンを必要とする可能性がある。レコードが同期的にアップデートされる場合(すなわち、ビットマップアップデートをディスクに書き込む前)、システムは、状態の損失、および対応する起動時の完全スキャンの必要性を完全に排除することが可能な場合がある(しかし、起動時にさらに良好な効率を獲得するように、定常操作中にさらなるディスクI/Oを必要とすることを犠牲にする)。別の選択肢は、再起動時に情報が利用可能となるように、システムシャットダウンン手順の間に、BBUB3213およびDST3215をディスクに書き込むことである(予期しない故障/シャットダウンの場合を除く。その場合、再起動時にクラスタの完全スキャンが必要であってもよい)。
一般的に言えば、スカベンジャ3210は、ディスクパックがロードされるまでは、あまりすることがないが、例示的実施形態では、CATマネージャ(CAT Manager)またはキャッシュマネジャ(Cache Manager)(ディスクパック(DiskPack)から読み出すため)、およびNVRAMマネージャ(NVRAM Manager)(カウンタを増分するため)等の、スカベンジャが依存するモジュールを初期化した後に、スカベンジャ3210がシステムマネジャによって初期化されることが検討される。あるいは、スカベンジャは、ゆっくりと、例えば、ディスクパックがロードされた後に、初期化され得る。スカベンジャは、ほぼ即時にディスクパックから読み出しを開始することが可能であるため、他の構成要素の準備ができて、それら自体にも同じディスクパックがロードされるまで、スカベンジャは、ディスクパックをロード(すなわち、「ディスクパックのロード(LordDiskPack)」)するように指示されるべきではない。
スカベンジャ3210の初期化の間(またはその他の何らかの適切な時において)、BBUM3211は、LBA0においてNTFSパーティションテーブル(NTFS Partition Table)を探す。NTFSパーティションテーブルは、マスタ起動レコード(Master Boot Record)と同じLBA、すなわちLBA0にある64バイトのデータ構造であり、NTFSプライマリパーティションについての情報を含む。各パーティションテーブルエントリは、長さ16バイトで、最大4つのエントリを利用可能にする。各エントリは、セクタの始まりからの所定のオフセット、および所定の構造において開始する。パーティションレコードは、パーティション種類がNTFSであるか否かを格納システムが決定することを可能にする、システム識別子を含む。パーティションテーブルの位置およびレイアウトは、それを書き込むオペレーティングシステムとは、概して多少無関係であることが分かっており、同じパーティションテーブル構造がNTFSだけでなく、かつMicrosoft形式だけでなく、一連のファイルシステム形式に役立つ(HFS+およびその他のファイルシステムは、そのパーティションの場所を突き止めるために異なる構造を使用してもよい)。
NTFSパーティションテーブルがLBA0にあると仮定すると、BBUM3211は、LBA0からパーティションテーブルを読み出し、次いで、パーティションテーブルにおいて特定された各NTFSパーティションに対して、パーティションのブートセクタ(パーティションの第1セクタ)、および、特に、マスタファイルテーブル(Master File Table/MFT)の位置を提供するNTFSパーティションに特有の構造である、拡張BIOSパーティションブロックを読み出す。次いで、BBUM3211は、MFTの常駐$ビットマップレコードを読み出して、ファイル属性、特に、実際のビットマップデータの位置および長さを獲得する。BBUM3211はまた、各パーティションのブートセクタLBA、ビットマップレコードのLBA、および実際のビットマップのLBAによりBLT3212をプログラムする。ブートセクタLBAおよびビットマップレコードLBAはまた、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。実際のビットマップは、概して、即時解析を必要とせず、それに応じてフラグを付けられる。LBA0にパーティションテーブルがない場合、BLT3212にさらなる位置は追加されない。
図33は、本発明の例示的実施形態に従った、ホストファイルシステムビットマップの場所を突き止めるための疑似コードである。ファイルシステム認識格納制御装置2721は、まずLBA0においてパーティションテーブルを探す。パーティションテーブルがあると仮定すると、ファイルシステム認識格納制御装置2721は、パーティションテーブルを読み出して、パーティションを特定する。次いで、各パーティションに対して、ファイルシステム認識格納制御装置2721は、パーティションのブートセクタを読み出してMFTを見出し、MFTの常駐$ビットマップレコードを読み出して、実際のビットマップデータの位置および長さ等の、ファイル属性を獲得する。ファイルシステム認識格納制御装置2721は、各パーティションのブートセクタLBA、ビットマップレコードのLBA、および実際のビットマップのLBAによりBLTをプログラムし、即時解析を必要とするようにブートセクタLBAおよびビットマップレコードLBAにフラグを付け、即時解析を必要としないように実際のビットマップにフラグを付ける。ファイルシステム認識格納制御装置2721がLBA0においてパーティションテーブルを見つけることができない場合は、BLTにさらなる位置を追加せずに、ファイルシステム認識格納制御装置2721が終了する。
定常状態操作中、全ての書き込みは、HRM3220からのBBUM3211への呼び出しを通して、BLT3212に対して相互参照される。LBA0宛てであると分かったあらゆる書き込みは、措置を指示するフラグのとおりに、即時に(同期的に)解析される。後の措置は、アップデートの性質に依存する。
パーティションが追加されていて、パーティションが認識された種類である場合、新しいパーティションの第1のLBAがBLT3212に追加され、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。クラスタ再利用を駆動する一連のアップデートを伴うビットマップがすぐに現れることを予期して、DST3215から、新しいパーティションの範囲内のあらゆるLBA範囲が除去される。1つの懸案事項は、パーティションテーブルアップデートよりも先にパーティションが書き出された場合、この情報はDST3215におけるブロックに書き込まれる可能性があり、スカベンジャスレッドによって不正に再利用され得ることである。このことは、例えば、DST3215における範囲との一致について、受信した全書き込みをチェックし、DST3215からブロックへの書き込みを除去することによって、緩和することが可能である。
パーティションが、パーティション識別子をWindows(登録商標)デフォルトからNTFSに変更するようにアップデートされている場合、BBUM3211は、パーティションブートセクタが書き込まれた後に識別子の変更が起こる傾向があるため、パーティションブートセクタの位置におけるLUNを即時に再調査する。このことは全くパーティション追加の一部にすぎない。
既存のパーティションが削除されている場合、削除されたパーティションに関するレコードがBLTから消去され、そのパーティションに対するBBUB3213が削除され、LBA範囲がクラスタの非同期再利用のためにDST3215に追加される。
既存のパーティションが移動されている場合、BLT3212における既存のブートセクタレコードは、監視する新しいブートセクタLBAと共にアップデートされる。すでに書き込まれている場合に備えて、新しい位置においてLUNが即時に再調査される可能性があるが、このことは大抵行われない。
既存のパーティションが切断されている場合、切除されたLBA範囲は、DST3215に追加される。新しいブートセクタがすでに書き込まれている場合に備えて、パーティションブートセクタの位置においてLUNが即時に再調査される可能性があるが、このことは大抵行われない。
既存のパーティションが拡大されている場合、DST3215から新しいパーティションの範囲内のあらゆるLBA範囲が除去される。新しいブートセクタがすでに書き込まれている場合に備えて、パーティションブートセクタの位置においてLUNが即時に再調査される可能性があるが、このことは大抵行われない。
パーティションの第1のLBA宛てであると分かったあらゆる書き込みは、措置を指示するフラグのとおりに、即時に(同期的に)解析される。ビットマップレコードの開始LBAは決定されてBLT3212に追加され、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。
図34は、本発明の例示的実施形態に従った、BBUM3211に対する高レベル疑似コードである。BBUM3211がクライアントのリクエストを受信すると、クライアントリクエスト(ClientRequest)からLUNを獲得し、LUNに基づいて適切なBLTを見出す。BBUM3211は、クライアントリクエストからLBAを獲得し、BLTにおいてこのLBAを探し、「即時の措置」フィールドをチェックして、このLBAに対して即時の措置が必要であるかどうかを確認する。即時の措置が必要であれば、BBUM3211は、クライアントのリクエストを同期的に処理する。しかし、即時の措置が必要とされない場合、BBUM3211は、非同期処理に対するLBAに対応するBBUBビットを設定する。
図35は、本発明の例示的実施形態に従った、新しいパーティションを作成するLBA0アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションテーブルであれば、BBUM3211は、新しいデータにおけるパーティションをBLTにおけるパーティションと比較する。新しいパーティションが追加されている場合、BBUM3211は、新しいデータからパーティションの開始および終了を獲得し、あらゆる重複LBA範囲についてDST3215をチェックしてそれらを除去し、パーティションの開始をBLTに追加し、即時の措置に対するエントリにフラグを付ける。
図36は、本発明の例示的実施形態に従った、パーティションを(再)フォーマットするLBA0アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションブートセクタである場合、BBUM3211は、新しいデータからMFTの開始を獲得し、ビットマップレコードの位置を計算する。このパーティションに対して、BLTにすでに同一のビットマップレコードエントリがある場合は、何も必要とされない。しかし、ビットマップレコードがBLTバージョンとは違う位置にある場合、BBUM3211は、BLTをアップデートして、ディスクから新しい位置を読み出す。その位置がビットマップレコードのようでない場合(すなわち、$ビットマップ列がない)は、何も必要としない。しかし、位置がビットマップレコードのようである場合、BBUM3211は、新しいビットマップ位置を獲得し、それらをBLTと比較する。新しいビットマップ位置が同一であれば、何も必要とされない。新しいビットマップが異なる位置にある場合、BBUM3211は、全てのBBUBビットを設定し、BBUBマッピングをアップデートし、BLTにおけるLBA範囲を移動する。新しいビットマップが既存のビットマップより小さい場合、BBUM3211はBBUBを縮小し、マップされていないLBA範囲をDST内に追加し、BLTにおけるLBA範囲を縮小する。新しいビットマップが既存のビットマップより大きい場合、BBUM3211は、全ての追加BBUBビットを設定し、BBUBを拡大し、BLTにおけるLBA範囲を拡大する。
図37は、本発明の例示的実施形態に従った、パーティションを削除するLBA0アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションテーブルである場合、BBUM3211は、新しいデータにおけるパーティションをBLTにおけるパーティションと比較する。パーティションが削除されている場合、BBUM3211は、BBUBを削除し、BLTからブートセクタを削除し、BLTからビットマップレコードを削除し、BLTからビットマップ範囲を削除しパーティション範囲をDSTに追加する。
図38は、本発明の例示的実施形態に従った、非同期タスク3214に対する高レベル疑似コードである。非同期タスク3214は、BBUBを解析し、次いで、BBUBにおいて設定された各ビットに対して、非同期タスク3214は、対応するクラスタがホストファイルシステムによって使用されていないとマークされているかどうかをチェックする。クラスタがホストファイルシステムによって使用されていないとマークされていれば、非同期タスク3214は、クラスタが格納制御装置によって使用されているとマークされているかどうかをチェックする。クラスタが格納制御装置によって使用されているとマークされていれば、非同期タスク3214は、LBA範囲をDSTに追加する。非同期タスク3214はまた、DSTにおける各LBA範囲に対する格納スペースを再利用する。
ブートセクタアップデートを受信した後、ビットマップレコードがすでにディスクに書き込まれているかもしれないため、ビットマップレコードの書き込みを待機することは、概して、十分ではない(概して、どの順序でNTFSフォーマットが発生するのかが分からず、いずれにしてもそれはマイナーパッチで変化し得る)。ビットマップレコードが拡張BPBの前に書き込まれる場合、位置がBLT3212に存在しないため、BBUM3211はそれを捕らえない。このことの例外は、ビットマップレコードの位置が変化していない場合である。例外にもかかわらず、BBUM3211は、概して、この時点でディスクからビットマップレコードの位置を即時に読み出して、ビットマップレコードが存在するかどうかを確認しなければならず、概して、ランダムノイズと初期化されたビットマップレコードを区別することが可能である必要がある($ビットマップユニコード列についてチェックすることがあり得る)。それが書き込まれていない場合、書き込みを待機することが可能である。すでにディスク上にあれば、概して、即時に解析しなければならない。解析は、概して、ビットマップの位置に対してレコードが解読されることを必要とし、それらの位置は、BLT3212に追加され、即時解析を必要しないとしてフラグを付けられる。解析は、概して、ビットマップのサイズが変化した場合、ビットマップの新しいサイズおよび位置に基づいて、新しいBBUB3213のインスタンスが作成されることも必要とし、そうでなければ、新しい位置で既存のBBUB3213をアップデートすることが概して十分である。概して、ビットマップレコードを書き込む前または後にホストが新しいビットマップを書き出すかどうかが分からないため、全てのビットを設定することが適切であるとも思われる(後である見込みがあるが、それが起こった場合、ビットマップ書き込みが入って来るにつれて、数秒以内にビットが害を及ぼされず2度目に設定される)。危険なのは前に書き込みが起こった場合であり、その場合、異なる位置にあるために書き込みが見逃されることとなる。全てのビットを設定することが、ビットマップが解析されることを保証する。
ブートセクタアップデート(例えば、パーティションの再フォーマットによる)の場合、ビットマップは、同じサイズとなり、同じ位置を占める可能性があるため、概して、BLT3212またはBBUB3213には変化がない。新しいビットマップはおそらく、ほとんどのブロックが全てゼロで書き直されるため、非同期タスク3214は、CATから割り当てられていないクラスタを再利用するために、それらの処理を進めることが可能であるはずである。ブートセクタのボリューム通し番号をチェックして、アップデートが再フォーマットの結果であったかどうかを決定することが可能である。
ビットマップレコードはまた、ブートセクタと無関係の理由でいつでもアップデートすることも可能である。スカベンジャ3210は、オンザイフライで移動する、またはサイズを変えるビットマップに対処することが可能である必要があるかもしれない。異なるサイズのパーティションを作成せずにビットマップがサイズを変え得るかどうかは明確ではないが、NTFSの将来のバージョンは、どのような理由であれ、このことをサポートしてもよい。この状況では、ビットマップの新しい位置は、概して、BLT3212にプログラムしなければならず、古いエントリは除去され、新しいエントリが追加される。BBUB3213は、それにしたがって拡大または縮小しなければならない。縮小によって解放されたあらゆるLBA範囲は、DST3215に追加することが可能であるが、厳密にそれらはなおもパーティションにマップする。
別の懸案事項は、ビットマップレコードの最後のアップデートフィールドの時間が、ビットマップの進行中の修正を反映するように頻繁に修正された場合に、結果が、相当量のインライン解析となり得ることである。
ビットマップ自体への全ての後の書き込みは、BBUB3213を介して非同期タスク3214へと押し進められる。
ここでの基本的方策は、全ての割り当てられたクラスタが、BBUB3213またはDST3215のいずれかにおいて表され、どちらにしても、割り当てられていないものが再利用されることである。代替的な解決法は、CATマネージャへと進み、そこでボリューム識別子がCATレコードに格納される前に、各書き込みがBBUM3211によってボリュームにマップされ、その識別子で標識されなければならないような、BBUM3211およびCATの両方に既知である、各ボリュームに対するボリューム識別子を有することである。新しいボリュームは典型的に、それが上書きしていた古いボリュームとは異なる識別子を獲得するため、非同期タスク3214は、新しいボリュームからのデータで上書きされたクラスタを再利用する危険なしで、古いボリューム識別子を伴うレコードを再利用することが可能である。明らかに、このことは、CATレコードにおけるスペースを消費する。これはまた、再フォーマットにおける書き込みの順番にも依存している。システムは、概して、新しいボリューム通し番号がブートパーティションに現れるまで新しいボリュームについて知ることができないため、これに先行するその他任意の書き込みは、古いボリューム識別子で標識される。
大部分の作業は、通常1分に1回起動し、BBUB3213から何らかの作業を収集し、キャッシュを通してビットマップブロックをページインしてビットをCATと比較することによって、それを実行する、専用スカベンジャタスク3214によって行われる。例示的実施形態では、BBUB3213は、論理的にセグメント化され(1kのセグメントサイズ)、そのセグメントのアップデート数を示す各セグメントに対するカウンタ、および任意のカウンタによって保持される最高値を反映する包括的カウンタがあり、これらのカウンタは、作業生成器(BBUM3211)によって増分され、作業消費器(スカベンジャタスク3214)によって減少される。スカベンジャタスク3214は、起動時に、包括的カウンタをチェックし、その中の値が、ビットマップのページインを正当化するのに十分高いかどうかを決定する。もしそうであれば、タスク3214は、どのセグメントにその値が対応するかを決定し(例えば、カウンタアレイを通して反復することによって)、次いで、適切なBBUBセグメントのビットを通して反復を開始する。設定されたビットを見出すと、ビットマップのそのブロックをページインし、それをCATと比較する。
上記のように、スカベンジャタスク3214の操作は、例えば、それが実行する頻度、またはそれが作業を行うことを決定する閾値を変更することによって、動的に調整することが可能である。しかし、本発明の例示的実施形態では、スカベンジャが実行する頻度にアーキテクチャが多少連結されているため、そのような調整は、概して、行われない。具体的には、最大時間窓(例えば、1分)以内にホストファイルシステム2711がそのメタデータを実行するという前提で、提案されたアーキテクチャが設計されているため、提案されたアーキテクチャは、現実的には最大時間窓よりも頻繁にスカベンジャタスク3214を実行することができない。提案されたアーキテクチャは、その規則を実際に破ることなく低い頻度で実行を行うことが可能であるが、それは、一部のクラスタアップデートを実際よりも最近であるように見せることによって、クラスタ再利用の効率を低下させる可能性がある(例えば、実行が毎分起こるが、実際には、例えば3分毎に起こるという前提で経過時間計算を設計した場合、経過時間計算は3の因数によってオフとなり得る)。さらに、タスク優先度は、概して、コンパイル時間で固定され、したがって、システム操作中に概して変更されない。
本発明の例示的実施形態では、格納システムは、4Kサイズのクラスタを実装することに注目するべきである。よって、ファイルシステムが4K以外のクラスタサイズでフォーマットされた場合、ファイルシステムビットマップにおけるビットは、格納システムにおけるクラスタとうまく相関しない。例えば、ファイルシステムクラスタサイズが4Kより小さい場合、ビットマップの複数のビットは、概して、CATとの相互参照を気遣いクリアされなければならない。しかし、ファイルシステムクラスタサイズが4Kより大きい場合、ビットマップの1つのクリアなビットは、概して、各4Kに対して1つずつ、CATへの複数のルックアップを必要とする。
別の懸案事項は、時期が早すぎて再利用できないクラスタにスカベンジャが遭遇する状況にどのように対処するかである。そのような状況において、スカベンジャは、BBUBにおいて設定されるビットを残すことによって、1つ以上の以降のスキャンを必要とし、512ビットの全体を通して再び解析することが可能である(例えば、次のスキャンが512ビットを調べて、単にクラスタの時期がまだ早すぎて再利用できないことが分かる場合がある)。あるいは、スカベンジャは、ビットをクリアして、再チェックを必要とする時期の早いブロック/ビットオフセットのリストにクラスタを追加することが可能である。実装の観点より、後者のアプローチは、リストを極めて小さく保つことが可能である場合にだけ、実用的となる。
実装の観点より、スカベンジャおよびBBUBは両方ともCATマネージャを通してディスクから読み出す。クラスタ再利用は、CATマネージャによって提供される特別なAPIを通して行われる。
(仮想ホットスペア)
上述のように、多くの格納システムにおいて、ホットスペア格納デバイスが作動可能状態において維持されるので、別の格納デバイスが故障した場合に迅速にオンラインにされ得る。本発明の特定の実施形態において、物理的に別個のホットスペアを維持するのではなく、複数の格納デバイスにわたる未使用の格納容量から、仮想ホットスペアが作成される。物理的なホットスペアとは異なり、この未使用の格納容量は、格納デバイスが残りの格納デバイスから回復されたデータを格納できない場合に利用可能である。
仮想ホットスペア機構は、ディスク故障の際にデータが冗長に再レイアウトされ得ることを保証するために、アレイの上に十分なスペースが利用可能であることを必要とする。したがって、進行中の方法で、格納システムは、一般的に、仮想ホットスペアのインプリメンテーションのために必要とされる未使用の格納容量の量を決定し(たとえば、格納デバイスの数、種々の格納デバイスの容量、格納されるデータの量、およびデータが格納される方法に基づいて)、仮想ホットスペアのために追加の格納容量が必要とされる場合に信号を発生する(たとえば、実質的に上述のような状態およびスロットを示す緑色/黄色/赤色のライトを使用して)。ゾーンが割当てられると、ディスクごとにそのゾーンを再レイアウトするためにいくつの領域が必要とされるかについてのレコードが保たれる。以下の表は、4つのドライブが使用される仮想ホットスペアを示す。
以下の表は、3つのドライブが使用される仮想ホットスペアを示す。
この例示的な実施形態において、仮想ホットスペアは、1つまたは2つのドライブのみを有するアレイの上では利用可能ではない。それぞれのゾーンと、アレイにおけるディスクの数とに関する情報に基づいて、アレイは、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定し、それぞれのシナリオについてそれぞれのドライブの上で十分なスペースが利用可能であることを保証する。生成される情報は、再レイアウトエンジンおよびゾーンマネージャにフィードバックされ得るので、データは、データ格納とホットスペア機構との間で正しくバランスを取られ得る。ホットスペア機構は、再レイアウトが生じ得るように、ゾーンレイアウトデータから計算されるものに加えて、十分なスペアワーキングスペース領域を必要とすることに留意されたい。
図22は、本発明の例示的な実施形態に従った、仮想ホットスペアを管理するための例示的な論理を示す論理フロー図である。ブロック2102において、論理は、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定する。ブロック2104において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトするためにそれぞれのドライブの上で必要とされるスペースの量を決定する。ブロック2106において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトするために必要とされるスペアワーキングスペース領域の量を決定する。ブロック2108において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトすることを可能にするためにそれぞれのドライブの上で必要とされるスペースの総量を決定する(基本的に、再レイアウトのために必要とされるスペースの量と、必要とされるスペアワーキングスペース領域の量との合計)。ブロック2110において、論理は、格納システムが適切な大きさの利用可能な格納デバイスを含むかどうかを決定する。適切な大きさの利用可能な格納デバイスがある場合には(ブロック2112における「はい」)、論理反復はブロック2199において終了する。しかし、不適切な大きさの利用可能な格納装置がある場合には(ブロック2112における「いいえ」)、論理は、ブロック2114において、どのドライブ/スロットがアップグレードを必要とするかを決定する。次に、ブロック2116において、論理は、追加の格納スペースが必要とされるという信号を出し、どのドライブ/スロットがアップグレードを必要とするかを示す。論理反復は、ブロック2199において終了する。
図23は、本発明の例示的な実施形態に従った、図22のブロック2102におけるような、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定するための例示的な論理を示す論理フロー図である。ブロック2202において、論理はゾーンを割当てる。次に、ブロック2204において、論理は、ディスクごとにそのゾーンを再レイアウトするためにいくつの領域が必要とされるかを決定する。論理反復は、ブロック2299において終了する。
図24は、本発明の例示的な実施形態に従った、仮想ホットスペア機能を呼び出すための例示的な論理を示す論理フロー図である。ブロック2302において、論理は、最悪の事態のシナリオの際にデータを冗長に再レイアウトすることを可能にするために利用可能な格納の十分な量を維持する。ブロック2304においてドライブの損失(たとえば取り外しまたは故障)を決定すると、論理は、ブロック2306において、データの故障許容を復元するために、一つ以上の残りのドライブを自動的に再構成する。論理反復は、ブロック2399において終了する。
図25は、本発明の例示的な実施形態に従った、図24のブロック2306におけるような、データの故障許容を復元するために一つ以上の残りのドライブを自動的に再構成するための例示的な論理を示す論理フロー図である。ブロック2402において、論理は、4つ以上の格納デバイスにわたる第1のストライピングパターンを、3つ以上の残りの格納デバイスにわたる第2のストライピングパターンに変換し得る。ブロック2404において、論理は、3つの格納デバイスにわたるストライピングパターンを、残りの2つの格納デバイスにわたるミラリングパターンに変換し得る。もちろん、論理は、ドライブの損失の後でデータを冗長に再レイアウトするために、他の方法でパターンを変換し得る。論理反復は、ブロック2499において終了する。
再び図21を参照すると、格納マネージャ2504は、上述のような仮想ホットスペア機能をインプリメントするための適切なコンポーネントおよび論理を一般的に含む。
(動的アップグレード)
格納の動的な拡大および縮小を処理するための上述の論理は、動的にアップグレード可能なシステムを提供するように延長され得る。該システムにおいて、格納デバイスは必要に応じてより大きな格納デバイスと置き換えられ得、冗長性が維持または拡張されて、なおかつより大きな格納デバイスによって提供される追加の格納スペースが、複数の格納デバイスにわたる利用可能な格納スペースのプールに含まれるように、既存のデータが格納デバイスにわたって自動的に再構成される。したがって、より小さな格納デバイスがより大きな格納デバイスに置き換えられるときに、すでに格納されたデータの冗長性を改善するため、ならびに追加のデータを格納するために、追加の格納スペースが使用され得る。より多くの格納スペースが必要とされるときはいつでも、適切な信号がユーザに提供され(たとえば実質的に上述のような緑色/黄色/赤色のライトを使用して)、ユーザは単に格納デバイスを取り外し得、それをより大きな格納デバイスと置き換え得る。
図26は、本発明の例示的な実施形態に従った、格納デバイスをアップグレードするための例示的な論理を示す論理フロー図である。ブロック2602において、論理は、第1の格納デバイスの上のデータを、その上に格納されたデータが他の格納デバイスの上で冗長に見えるように、格納する。ブロック2604において、論理は、第1の格納デバイスが、第1の格納デバイスよりも大きな格納容量を有する置換用デバイスと置き換えられたことを検出する。ブロック2606において、論理は、第1のデバイスの上に格納されたデータを、他のデバイスの上に冗長に格納されたデータを使用して、置換用デバイスの上に自動的に複写する。ブロック2608において、論理は、新しいデータを冗長に格納するために利用可能な置換用デバイスの上に、追加の格納スペースを作る。ブロック2610において、新しいデータに冗長性を提供するために利用可能な十分な量の格納容量を有するデバイスが他にない場合には、論理は、置換用デバイスの上の追加の格納スペースの中に、新しいデータを冗長に格納し得る。ブロック2612において、少なくとも一つの他のデバイスが、新しいデータに冗長性を提供するために利用可能な十分な量の格納容量を有する場合には、論理は、複数の格納デバイスにわたって新しいデータを冗長に格納し得る。
再び図21を参照すると、格納マネージャ2504は、上述のような動的アップグレード機能をインプリメントするための適切なコンポーネントおよび論理を一般的に含む。
(その他)
本発明の実施形態は、本明細書において全体が参照により援用されている、Geoffrey S.Barralの名義で2004年11月5日に出願された米国仮特許出願第60/625,495号に記述される態様で、周辺接続プロトコルを使用して、格納容量をホストコンピュータに提供するように使用され得る。
ハッシュアルゴリズムは、厳密に一意のハッシュ値を生成し得ないことが留意されるべきである。したがって、ハッシュアルゴリズムが、同一でないコンテンツを有するデータの2つのチャンクに対して、同じハッシュ値を生成することが考えられる。(ハッシュアルゴリズムを一般的に取り入れる)ハッシュ関数は、一意性を確認するメカニズムを一般的に含む。たとえば、上述のような本発明の例示的な実施形態において、一つのチャンクのハッシュ値が別のチャンクのハッシュ値と異なる場合には、これらのチャンクのコンテンツは同一でないと考えられる。しかし、一つのチャックのハッシュ値が別のチャンクのハッシュ値と同じである場合には、コンテンツが同一であるか同一でないかを決定するために、ハッシュ関数は、2つのチャンクのコンテンツを比較し得るか、または何らかの他のメカニズムを利用し得る(たとえば異なるハッシュ関数)。
論理フロー図は、本発明の種々の局面を示すために本明細書中で使用されるものであり、本発明を任意の特定の論理フローまたは論理インプリメンテーションに限定するものと解釈されるべきではないことが留意されるべきである。記載される論理は、全般的な結果を変化させることなく、またはさもなければ本発明の真の範囲から逸脱することなく、異なる論理ブロック(たとえば、プログラム、モジュール、機能、またはサブルーチン)に分割され得る。全般的な結果を変化させることなく、またはさもなければ本発明の真の範囲から逸脱することなく、しばしば、時間および論路要素が、追加され得、変更され得、省略され得、異なる順序で実行され得、または異なる論理構成を使用してインプリメントされ得る(たとえば、論理ゲート、ルーピング基本命令、条件付き論理、および他の論理構成)。
本発明は、プロセッサ(たとえば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ)とともに使用するコンピュータプログラム、プログラム可能論理デバイスとともに使用するプログラマブルロジック(たとえば、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array)(FPGA)、または他のPLD)、個別のコンポーネント、集積回路(たとえば、特定用途向けIC(Application Specific Integrated Circuit)(ASIC)、またはこれらの任意の組み合わせを含む任意の他の手段を含むが決してこれらに限定されない多くの異なる形で具体化され得る。
本明細書中にこれまで記載された機能性のすべてまたは一部をインプリメントするコンピュータプログラム論理は、ソースコードの形態、コンピュータ実行可能な形態、および種々の中間的な形態(たとえば、アセンブラ、コンパイラ、リンカ、またはロケータ)を含むが決してそれらに限定されない、種々の形において具体化され得る。ソースコードは、種々のオペレーティングシステムまたはオペレーティング環境とともに使用する、種々のプログラミング言語(たとえば、オブジェクトコード、アセンブリ言語、またはFortran、C、C++、JAVA(登録商標)、またはHTML)のいずれかにおいてインプリメントされる一連のコンピュータプログラム命令を含み得る。ソースコードは、種々のデータ構造および通信メッセージを定義および使用し得る。ソースコードはコンピュータ実行可能な形態(たとえば、インタプリタを介して)であり得、あるいはソースコードはコンピュータ実行可能な形態に変換され得る(たとえば、翻訳プログラム(translator)、アセンブラ、またはコンパイラを介して)。
コンピュータプログラムは、半導体メモリデバイス(たとえば、RAM、ROM、PROM、EEPROM、またはフラッシュプログラム可能RAM)、磁気メモリデバイス(たとえばディスケットまたは固定ディスク)、光メモリデバイス(たとえば、CD−ROM)、PCカード(たとえば、PCMCIAカード)、または他のメモリデバイスなどの有形の格納媒体において、永久的または一時的に、任意の形態(たとえば、ソースコードの形態、コンピュータ実行可能な形態、または中間的な形態)で固定され得る。コンピュータプログラムは、アナログテクノロジー、デジタルテクノロジー、光学テクノロジー、ワイヤレステクノロジー(たとえば、Bluetooth)、ネットワーキングテクノロジー、およびインターネットワーキングテクノロジーを含むが決してそれらに限定されない、種々の通信テクノロジーのいずれかを使用してコンピュータに送信可能な信号における任意の形態に固定され得る。コンピュータプログラムは、付随する印刷文書または電子文書とともに取り外し可能な格納媒体(たとえば、シュリンクラップソフトウェア)として任意の形態で配布され得るか、コンピュータシステム(たとえば、システムROMまたは固定ディスクの上)に事前ロードされ得るか、または通信システム(たとえば、インターネットまたはワールドワイドウェブ)を介してサーバまたは電子掲示板から配信され得る。
本明細書中にこれまで記載された機能性のすべてまたは一部をインプリメントするハードウェア論理(プログラム可能論理デバイスとともに使用するプログラマブルロジックを含む)は、従来のマニュアル方法を使用して設計され得るか、あるいは計算機援用設計(Computer Aided Design)(CAD)、ハードウェア記述言語(たとえば、VHDLまたはAHDL)、またはPLDプログラミング言語(たとえば、PALASM、ABEL、またはCUPL)などの種々のツールを使用して、設計、キャプチャ、シミュレーション、または電子的文書化をされ得る。
プログラマブルロジックは、半導体メモリデバイス(たとえば、RAM、ROM、PROM、EEPROM、またはフラッシュプログラム可能RAM)、磁気メモリデバイス(たとえば、ディスケットまたは固定ディスク)、光メモリデバイス(たとえば、CD−ROM)、または他のメモリデバイスなどの、有形の格納媒体において、永久的または一時的に固定され得る。プログラマブルロジックは、アナログテクノロジー、デジタルテクノロジー、光学テクノロジー、ワイヤレステクノロジー(たとえば、Bluetooth)、ネットワーキングテクノロジー、およびインターネットワーキングテクノロジーを含むが決してそれらに限定されない、種々の通信テクノロジーのいずれかを使用してコンピュータに送信可能な信号に固定され得る。プログラマブルロジックは、付随する印刷文書または電子文書とともに取り外し可能な格納媒体(たとえば、シュリンクラップ(shrink wrapped)ソフトウェア)として配布され得るか、コンピュータシステム(たとえば、システムROMまたは固定ディスクの上)に事前ロードされ得るか、または通信システム(たとえば、インターネットまたはワールドワイドウェブ)を介してサーバまたは電子掲示板から配信され得る。
本出願は、参照することによりそれらの全体が本願に組み込まれる、以下の米国特許出願に関連する。
代理人整理番号第2950/104号「Dynamically Upgradeable Fault−Tolerant Storage System Permitting Variously Sized Storage Devices and Method」、
代理人整理番号第2950/105号「Dynamically Expandable and Contractible Fault−Tolerant Storage System With Virtual Hot Spare」、および
代理人整理番号第2950/107号「Storage System Condition Indicator and Method」。
本発明は、本発明の真の範囲から逸脱することなく、他の特定の形において具体化され得る。記載された実施形態は、あらゆる点で、説明的なものとしてのみ考えられ、限定的なものとしては考えられない。