JP2009536414A - ファイルシステム認識ブロック格納システム、装置、および方法 - Google Patents

ファイルシステム認識ブロック格納システム、装置、および方法 Download PDF

Info

Publication number
JP2009536414A
JP2009536414A JP2009510073A JP2009510073A JP2009536414A JP 2009536414 A JP2009536414 A JP 2009536414A JP 2009510073 A JP2009510073 A JP 2009510073A JP 2009510073 A JP2009510073 A JP 2009510073A JP 2009536414 A JP2009536414 A JP 2009536414A
Authority
JP
Japan
Prior art keywords
data
storage
file system
cluster
host file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009510073A
Other languages
English (en)
Other versions
JP2009536414A5 (ja
JP4954277B2 (ja
Inventor
ジュリアン エム． テリー，
ニール エー． クラークソン，
ジェフリー エス． バーラル，
Original Assignee
データ ロボティクス， インク．
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by データ ロボティクス， インク． filed Critical データ ロボティクス， インク．
Publication of JP2009536414A publication Critical patent/JP2009536414A/ja
Publication of JP2009536414A5 publication Critical patent/JP2009536414A5/ja
Application granted granted Critical
Publication of JP4954277B2 publication Critical patent/JP4954277B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

ファイルシステム認識格納システムは、ホストファイルシステムの格納方法を決定するために、ホストファイルシステムデータ構造の場所を突き止め、分析する。この目的のために、格納システムは、オペレーティングシステムパーティションの場所を突き止め、そのデータ構造の場所を突き止めるためにオペレーティングシステムパーティションを解析し、ホストファイルシステムデータ構造の場所を突き止めるためにオペレーティングシステムデータ構造を解析する場合がある。格納システムは、ホストファイルシステムの格納方法に基づいてデータ格納を管理する。格納システムは、ホストファイルシステムによってもはや使用されていない格納エリアを特定し、追加データ格納容量に対してそれらのエリアを再利用するために、格納方法情報を使用することが可能である。

Description

（優先権）
本ＰＣＴ出願は、米国仮特許出願第６０／７９７，１２７号（２００６年３月３日出願、出願人：Ｊｕｌｉａｎ Ｍ．Ｔｅｒｒｙ，Ｎｅｉｌ Ａ．Ｃｌａｒｋｓｏｎ，およびＧｅｏｆｆｒｅｙ Ｓ．Ｂａｒｒａｌｌ、名称「Ｆｉｌｅｓｙｓｔｅｍ−Ａｗａｒｅ Ｂｌｏｃｋ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ，Ａｐｐａｒａｔｕｓ，ａｎｄ Ｍｅｔｈｏｄ」）の優先権を主張する。
本願は、米国特許出願第１１／２６７，９３８（２００５年１１月４日出願、出願人：Ｇｅｏｆｆｒｅｙ Ｓ．Ｂａｒｒａｌｌ、名称「Ｄｙｎａｍｉｃａｌｌｙ Ｅｘｐａｎｄａｂｌｅ ａｎｄ Ｃｏｎｔｒａｃｔｉｂｌｅ Ｆａｕｌｔ−Ｔｏｌｅｒａｎｔ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｐｅｒｍｉｔｔｉｎｇ Ｖａｒｉｏｕｓｌｙ Ｓｉｚｅｄ Ｓｔｏｒａｇｅ Ｄｅｖｉｃｅｓ ａｎｄ Ｍｅｔｈｏｄ」）にも関連し、該出願は、米国仮特許出願第６０／６２５，４９５号（２００４年１１月５日出願）および米国仮特許出願第６０／７１８，７６８号（２００５年９月２０日出願）の優先権を主張する。
上記出願のすべてが、その全体において本明細書において参考として援用される。
本発明は、デジタルデータ格納システムおよび方法に関連し、より具体的には、故障許容格納を提供するシステムおよび方法に関連する。
種々のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）のいずれか一つに従って、一定のパターンの冗長ディスク格納を提供することは、従来技術において公知である。一般的に、ＲＡＩＤパターンを使用したディスクアレイは、経験豊かな情報技術者による管理を必要とする複雑な構造である。さらに、ＲＡＩＤパターンを使用した多くのアレイ設計において、アレイにおけるディスクドライブの容量が均一でない場合には、設計は、アレイにおける最小のドライブの容量を超えるドライブの上で、いかなる容量を使用することもでき得ない。
標準的なＲＡＩＤシステムの一つの問題は、ディスクアレイのまれにしか使用されないエリアの上で、ディスク表面の破損が生じる可能性があることである。別のドライブが故障する場合には、破損が生じたことを決定することは必ずしも可能ではない。そのような場合には、破損されたデータは、ＲＡＩＤアレイが故障したドライブを再構築するときに、伝播および保存され得る。
多くの格納システムにおいて、スペアの格納デバイスが使用可能状態で維持されるので、別の格納デバイスが故障した場合にそれが使用され得る。そのようなスペアの格納デバイスは、しばしば「ホットスペア」と呼ばれる。ホットスペアは、格納システムの通常の作動中は、データを格納するようには使用されない。活動状態の格納デバイスが故障するときには、故障した格納デバイスはホットスペアと論理的に置き換えられ、データはホットスペアの上に移動されるかまたはさもなければ再作成される。故障した格納デバイスが修復されるかまたは置き換えられる場合には、データは一般的に、（再）作動させられた格納デバイスの上に移動させられるかまたはさもなければ再作成されるので、別の故障の場合にそれが容易に使用される。ホットスペアディスクの維持は一般的に複雑であるので、熟練した管理者によって一般的に処理される。ホットスペアディスクは、追加の費用をも意味する。
一般的に言えば、ホストファイルシステムが格納システムにデータのブロックを書き込むとき、格納システムは、データに対する格納ブロックを割り当ててそのデータ構造をアップデートし、格納ブロックが使用中であることを示す。その時点より、格納システムは、たとえホストファイルシステムが後にそのブロックを使用しなくなるとしても、格納ブロックを使用中と考える。
ホストファイルシステムは、概して、その使用されたディスクブロックを追跡するために、ビットマップを使用する。ボリューム作成直後、ビットマップは、概して、典型的に全ビットをクリアにすることによって、ほとんどのブロックが使用されていないことを示す。ファイルシステムが使用される場合、ホストファイルシステムは、単にその使用されていないブロックビットマップを使用することによって、ブロックを割り当てる。
ホストファイルシステムが一部のブロックをその使用されていないプールに解除し戻すとき、その使用されていないブロックビットマップにおける対応するビットを単純にクリアする。格納システム上では、このことは、ホストの使用されていないブロックビットマップの一部を偶然含むクラスタへの書き込み、およびおそらく解放された実際のクラスタに対する入出力（Ｉ／Ｏ）がほぼ確実にないジャーナルファイルヘの書き込みとして現れる。ホストファイルシステムが強化されたセキュリティモードで実行している場合には、長期経過の（ｓｔａｌｅ）クラスタコンテンツが攻撃者によって読み出され得る可能性を低減するための、ホストによる現在のディスク上のデータの上書きによる解放されたブロックへのＩ／Ｏが存在する場合があるが、そのような書き込みを削除過程として特定する方法はない。よって、格納デバイスには、ホストファイルシステムが使用中のブロックと、以前使用して、後に使用されていないとマークされたものを区別する方法がない。
このように格納システムが解放されたブロックを特定不能であることは、多数のマイナスの結果につながり得る。例えば、格納システムは、使用されている格納の量を著しく過大に報告する可能性があり、早期に格納スペースがなくなる可能性がある。
本発明の一側面に従って、ホストファイルシステムの制御下でデータを保存するブロックレベル格納システムによってデータを保存する方法が提供される。該方法は、ホストファイルシステムに対して格納されたホストファイルシステムデータ構造の場所をブロックレベル格納システム中で突き止めることと、格納されるデータと関連するデータ型を特定するためにホストファイルシステムデータ構造を分析することと、データ型に基づいて選択された格納スキームを使用してデータを格納することとを伴い、それにより、異なるデータ型を有するデータは、データ型に基づいて選択された異なる格納スキームを使用して格納することが可能である。
本発明の別の側面に従って、ホストファイルシステムの制御下でデータを保存するブロックレベル格納システムが提供される。該システムは、ホストファイルシステムデータ構造がホストファイルシステムに対して格納される、ブロックレベル格納と、ブロックレベル格納に格納されたホストファイルシステムデータ構造の場所を突き止め、格納されるデータと関連するデータ型を特定するようにホストファイルシステムデータ構造を分析し、かつデータ型に基づいて選択された格納スキームを使用してデータを格納するための、ブロックレベル格納に動作可能に連結される格納制御装置とを備え、それにより、異なるデータ型を有するデータは、前記データ型に基づいて選択された異なる格納スキームを使用して格納することが可能である。
様々な代替的実施形態では、データは、データ型に基づいて選択された格納レイアウトおよび／または符号化スキームを使用して格納してもよい。例えば、アクセス頻度の高いデータは、強化されたアクセスのしやすさを提供するように保存してもよい（例えば、非圧縮形式およびシーケンシャル格納で）一方で、アクセス頻度の低いデータは、強化された格納効率を提供するように保存してもよい（例えば、データ圧縮および／またはノンシーケンシャル格納を使用して）。加えて、または代案として、データは、データ型に応じて圧縮および／または暗号化してもよい。
様々な代替的実施形態では、ホストファイルシステムデータ構造の場所は、パーティションテーブルを維持し、オペレーティングシステムパーティションの場所を突き止めるためにパーティションテーブルを解析し、オペレーティングシステムを特定してオペレーティングシステムデータ構造の場所を突き止めるためにオペレーティングシステムパーティションを解析し、ホストファイルシステムを特定してホストファイルシステムデータ構造の場所を突き止めるためにオペレーティングシステムデータ構造を解析することによって、突き止めてもよい。オペレーティングシステムデータ構造は、スーパーブロックを含んでもよく、その場合、オペレーティングシステムデータ構造を解析することは、スーパーブロックを解析することを含んでもよい。ホストファイルシステムデータ構造は、ホストファイルシステムデータ構造のワーキングコピーを作成し、ワーキングコピーを解析することによって、解析してもよい。
本発明の前述の特徴は、添付の図面を参照して、以下の詳細な説明を参照することによって容易に理解される。
（具体的な実施形態の詳細な説明）
定義。本明細書および添付の特許請求の範囲において使用されるように、文脈上特別な断りがない限り、以下の用語は指示された意味を有する。
オブジェクトの「チャンク」は、オブジェクトの抽象スライスであり、使用される物理的格納とは無関係に作られ、一般的にオブジェクトの隣接バイトの固定数である。
データ格納のための故障許容「パターン」は、データが一つ以上の格納デバイスにわたって冗長に分散される事項（ｐａｒｔｉｃｕｌａｒ）であり、なかでも、ミラリング（たとえばＲＡＩＤ１に類似した方法で）、ストライピング（たとえばＲＡＩＤ５に類似した方法で）、ＲＡＩＤ６、二重パリティ、対角線パリティ、低密度パリティチェック（Ｌｏｗ Ｄｅｎｓｉｔｙ Ｐａｒｉｔｙ Ｃｈｅｃｋ）コード、ターボコード、または他の冗長スキーム、または冗長スキームの組み合わせであり得る。
所定のチャンクのハッシュ数は、該所定のチャンクが任意の他のチャンクのハッシュ数とは一般的に異なるハッシュ数を生成するときに、該他のチャンクが該所定のチャンクと同一のデータコンテンツを有するときを除いて、「一意」である。すなわち、２つのチャンクは、それらのコンテンツが同一でないときはいつでも、異なるハッシュ数を一般的に有する。以下に詳細に説明されるように、「一意」という用語は、この文脈において、同一でないチャンクに対して共通ハッシュ数をたまに生成するハッシュ関数から生成されるハッシュ数をカバーするように使用される。なぜなら、ハッシュ関数は、異なるチャンクについて異なる数を生成することにおいて、一般的に完全ではないからである。
「領域」は、格納媒体の上の隣接する物理ブロックのセットである（たとえばハードドライブ）。
「ゾーン」は、２つ以上の領域からなる。ゾーンを構成する領域は、一般的に隣接することが要求されない。以下に説明される例示的な実施形態において、ゾーンは、１ＧＢのデータまたは制御情報と等価なものを格納する。
「クラスタ」は、ゾーンの中の単位サイズであり、圧縮（以下に説明される）の単位を表す。以下に説明される例示的な実施形態において、クラスタは、４ＫＢ（すなわち８つの５１２バイトセクタ）であり、本質的にチャンクと同じである。
「冗長セット」は、データのセットに冗長性を提供するセクタ／クラスタのセットである。
「領域をバックアップすること」は、一つの領域のコンテンツを別の領域にコピーすることを含む。
格納デバイスの「第１のペア」および「第２のペア」は、共通格納デバイスを含み得る。
「第１の複数の」および「第２の複数の」格納デバイスは、一つ以上の共通格納デバイスを含み得る。
格納デバイスの「第１の配置」および「第２の配置」または「異なる配置」は、一つ以上の共通格納デバイスを含み得る。
本発明の実施形態では、ファイルシステム認識格納システムは、ホストファイルシステムの格納方法を決定するために、ホストファイルシステムデータ構造を分析する。例えば、ブロック格納デバイスは、ホストファイルシステムデータ構造を解析して、使用されたブロック、未使用のブロック、およびデータ型等のようなものを決定してもよい。ブロック格納デバイスは、ホストファイルシステムの格納方法に基づいて物理的格納を管理する。
そのようなファイルシステム認識ブロック格納デバイスは、データの物理的格納について知的判定を行うことが可能である。例えば、ファイルシステム認識ブロック格納デバイスは、システムのデータ格納容量を効果的に拡張するために、ホストファイルシステムによって解放されたブロックを特定し、解放されたブロックを再利用することが可能である。以降で「ごみあさり（ｓｃａｖｅｎｇｉｎｇ）」または「ガーベッジ収集」と呼んでもよい、解放されたブロックのそのような再利用は、仮想格納を実施する際に特に有用であってよく、その場合、ホストファイルシステムは、実際の物理的格納容量よりも多くの格納により構成される。ファイルシステム認識ブロック格納デバイスはまた、ファイルシステムによって格納されたオブジェクトのデータ型を特定し、データ型に基づいて異なる格納スキームを使用してオブジェクトを格納することも可能である（例えば、アクセス頻度の高いデータは、圧縮せず、かつ連続ブロックで格納することが可能である一方で、アクセス頻度の低いデータは、圧縮および／または不連続ブロックで格納することが可能であり、データ圧縮および暗号化等の異なる符号化スキームは、データ型に基づいて異なるオブジェクトに適用することが可能である）。
ファイルシステム認識ブロック格納デバイスは、概して、所定の一式のファイルシステムをサポートし、ファイルシステムに対し、基礎となるデータ構造（例えば、使用されていないブロックビットマップ）の場所を突き止めて利用するのに十分なほどに内部の働きを「理解」する。ファイルシステムタイプ（例えば、ＮＴＦＳ、ＦＡＴ、ＲｅｉｓｅｒＦＳ、ｅｘｔ３）を決定するために、ファイルシステム認識ブロック格納デバイスは典型的に、パーティションテーブルを解析してオペレーティングシステム（ＯＳ）パーティションの場所を突き止め、次いでＯＳパーティションを解析してホストファイルシステムのスーパーブロックの場所を突き止めることによって、ファイルシステムタイプを特定する。ひとたびファイルシステムタイプが分かると、ファイルシステム認識ブロック格納デバイスは、スーパーブロックを解析してホストファイルシステムに対する使用されていないブロックビットマップを見出し、次いで使用されていないブロックビットマップを解析して、使用されたブロックおよび未使用のブロックを見出すことが可能である。
データ構造（例えば、使用されていないブロックビットマップ）の経時的変化を検出するために、ファイルシステム認識ブロック格納デバイスは、周期的にデータ構造のコピーを作成し（例えば、非公式の非冗長ゾーンで）、後で、現在アクティブなバージョンのデータ構造を初期に作成したコピーと比較して、変化を検出してもよい。例えば、割り当てられた状態から使用されていない状態へと移行する任意のビットマップエントリを特定することが可能であり、ガーベッジ収集操作が、再利用の良い候補であるクラスタに正確に向けられることを可能にする。各ビットマップが処理されるとき、ビットマッップ操作の経過の履歴を維持するために、履歴コピーを現在のコピーと置き換えることが可能である。時間が経つにつれて、使用されていないブロックビットマップのコピーは、時間的にばらばらなクラスタの寄せ集めとなるかもしれないが、使用されていないエントリの場所を突き止めるために現在のコピーが使用されるので、このことは何の問題も引き起こさないはずである。
以降、格納アレイシステムを参照して、例示的実施形態を説明する。
図１は、本発明の実施形態の図示であり、オブジェクト、この例においてはファイルが、格納のために一連のチャンクに分解される。最初に、ファイル１１が格納ソフトウェアに渡され、そこでオブジェクト１２として指定され、一意のオブジェクト識別番号、この場合は＃００７が割当てられる。新しいエントリ１３１は、オブジェクトテーブル１３の中に作られ、この新しいオブジェクトの割当てを表す。オブジェクトは、今度はデータ１２１、１２２および１２３の「チャンク」に分解され、それらはオブジェクトの固定長セグメントである。各チャンクは、ハッシングアルゴリズムを通過させられ、ハッシングアルゴリズムはチャンクについて一意のハッシュ数を返す。このアルゴリズムは、リトライされたチャンクが格納されたチャンクと同一であることを保証するために、検索されたチャンクと、もともとのハッシュと比較された結果とに、後で適用され得る。各チャンクのハッシュ数は、後で完全なオブジェクトがチャンクの収集によって検索され得るように、オブジェクト１３２のエントリ行においてオブジェクトテーブル１３の中に格納される。
図１においてさらに、チャンクハッシュは、今度はチャンクテーブル１４の中の既存のエントリと比較される。既存のエントリ１４１と一致する任意のハッシュは、すでに格納されているので、行動はとられない（すなわち、データは再び格納されず、オブジェクトの自動的圧縮につながる）。新しいハッシュ（チャンクテーブル１４の中に対応するエントリがないハッシュ）は、チャンクテーブル１４１の中に入力される。チャンクにおけるデータは、次に、故障許容格納のために最も効率的な方法で、利用可能な格納デバイス１５１、１５２および１５３の上に格納される。このアプローチは、チャンクデータが、たとえば、一つまたは２つのデバイスからなる格納システムの上にミラリングされた方法で、または３つ以上の格納デバイスを用いてシステムの上でパリティストライピングされた方法で格納されることにつながり得る。このデータは、物理的位置１５１１、１５２１および１５３１において格納デバイスの上に格納され、チャンクのすべての物理的部分が後で場所を突き止められ検索され得るように、これらの位置および位置の番号は、チャンクテーブルの列１４３および１４２に格納される。
図２は、より多くの格納デバイス（ｓｔｏｒａｇｅ）の追加の結果として、チャンクのための故障許容格納のパターンがどのように動的に変化され得るかという同じ実施形態を示す。特に、図２は、追加の格納デバイスがシステム全体にひとたび追加されると、格納デバイスの上に物理的に格納されたチャンクが、新しいパターンにおいてどのようにレイアウトされ得るかを示す。図２ａにおいて、格納システムは２つの格納デバイス２２１および２２２を備え、チャンクデータは、位置２２１１および２２２１において２つの格納デバイスの上に物理的にミラリングされ、故障許容を提供する。図２ｂにおいて、第３の格納デバイス２２３が追加され、チャンクをパリティストライピングした方法で格納することが可能になり、これは、ミラリングされたパターンよりも格納効率が良いパターンである。チャンクは、３つの物理的位置２３１１、２３２１および２３３１において、この新しいパターンにレイアウトされ、利用可能な格納デバイスにとる割合がはるかに低い。チャンクテーブル２１はアップデートされて、新しいレイアウトが３つの位置２１２にすることと、新しいチャンクの物理的位置２３１１、２３２１および２３３１が２１３に記録されていることをも示す。
図３は、本発明の実施形態による、完成された（ｍａｔｕｒｅ）格納システムを示し、ある期間にわたって機能していた。これは、可変格納容量を有する格納デバイスの上で、チャンクが、時間を経てどのように物理的に格納され得るかを図示する。この図は、４０ＧＢ格納デバイス３１と、８０ＧＢ格納デバイス３２と、１２０ＧＢ格納デバイス３３とからなる格納システムを示す。最初に、チャンクは、４０ＧＢ格納デバイス３１が満杯になるまで、故障許容ストライプパターン３４で格納される。次に、格納スペースの欠如のために、新しいデータは、８０ＧＢ格納デバイス３２および１２０ＧＢ格納デバイス３３の上の利用可能なスペースの上に、ミラリングされたパターン３６で格納される。８０ＧＢ格納デバイス３２がひとたび満杯になると、次に、新しいデータは単一のディスク故障許容パターン３７でレイアウトされる。たとえ格納デバイスがデータ格納のための単一のプールを備えていても、チャンクにおいて格納されたようなデータそのものは、種々の別個のパターンで格納されている。
図４は、本発明の別の実施形態を図示し、非効率的な格納デバイスの使用と、故障許容の低いレベルとを警告するために、インジケータ状態が使用される。図４ａにおいて、すべての３つの格納デバイス４１、４２および４５は使用されていないスペースを有しており、効率的で故障許容の方法でデータが格納されていることを示すために、インジケータライト４４は緑色である。図４ｂにおいて、４０ＧＢ格納デバイス４１は満杯になったので、新しいデータは、ミラリングされた冗長パターン４６で、使用されていない残りのスペースを用いて２つの格納デバイス４２および４３の上のみに格納され得る。データは完全に冗長ではあるが、効率的に格納されていないことを示すために、インジケータライト４４は琥珀色に変わった。図４ｃにおいて、１２０ＧＢ格納デバイス４３のみが使用されていない残りのスペースを有しているので、すべての新しいデータは、この一つのデバイス４３の上でミラリングされたパターンのみで格納され得る。故障許容はよりロバスト（ｒｏｂｕｓｔ）でなくなり、システムはスペースが非常に足りなくなっているので、より多くの格納デバイスの追加が必要であることを示すために、インジケータライト４４は赤色に変わる。
一つの代替的な実施形態において、アレイにおけるそれぞれのドライブ／スロットに、たとえば３色（たとえば緑色、黄色、赤色）の形で、インジケータが提供される。一つの特定の実施形態において、ライトは、光る効果でディスクキャリアの前面全体を照らすように使用される。ライトは、システムの全体的な状態のみならず、（もしあれば）どのドライブ／スロットが注意を必要としているかを示すように制御される。それぞれの３色ライトは、少なくとも４つの状態に置かれ得、具体的には、オフ、緑色、黄色、赤色である。スロットが空であり、システムが十分な格納デバイスと冗長性をもって作動しているために、スロットにドライブがインストールされる必要がない場合には、特定のスロットのためのライトは、オフ状態に置かれ得る。特定のスロットのためのライトは、対応するドライブが十分であり、置き換えられる必要がない場合には、緑色状態に置かれ得る。特定のスロットのためのライトは、対応するドライブをより大きなドライブに置き換えることが推奨されるようにシステム操作が低下する場合には、黄色の状態に置かれ得る。特定のスロットのためのライトは、対応するドライブをインストールまたは置き換えなければならない場合には、赤色の状態に置かれ得る。必要または要求に応じて、たとえば、オンとオフとの状態の間でライトをフラッシュさせることによって、または２つの異なる色の間でライトをフラッシュさせる（たとえば、ドライブが置き換えられた後に、データの再レイアウトが進行中であるときに、赤色と緑色との間でフラッシュさせる）ことによって、追加の状態が示され得る。例示的な実施形態のさらなる詳細が、以下に説明される。
もちろん、システム状態とドライブ／スロット状態との両方を示すために、他の指示技術が使用され得る。たとえば、システム状態と、必要な場合には、注意を必要とするスロット番号とを示すために、ＬＣＤディスプレイが使用され得る。さらに、他の種類のインジケータ（たとえば、スロットインジケータまたは各スロット用のライトとともに、システムのための単一の状態インジケータ（たとえば緑色／黄色／赤色））が使用され得る。
図５は、図１〜３に関連して上述されたような、本発明の実施形態に従ったデータの格納、検索および再レイアウトにおいて使用される機能モジュールのブロック図である。通信のための入口点および出口点は、オブジェクトの格納または検索のためにオブジェクトをシステムに渡すオブジェクトインタフェース５１１と、格納システムを一つの大きな格納デバイスであるように見せるブロックインタフェース５１２と、格納システムをＷｉｎｄｏｗｓ（登録商標）ファイルシステムであるように見せるＣＩＦＳインタフェース５１３とである。これらのインタフェースがデータの格納を要求するとき、データはチャンクパーサ（Ｃｈｕｎｋ Ｐａｒｓｅｒ）５２に渡され、チャンクパーサは、データのチャンクへの分解を実行し、オブジェクトテーブル５１２への最初のエントリを生成する（図１に関連して上述されたように）。これらのチャンクは、次にハッシュコード生成器５３に渡され、ハッシュコード生成器は各チャンクについて関連するハッシュコードを生成し、それらをオブジェクトテーブルに入力するので、各オブジェクトに関連するチャンクは５１２で列挙される（図１に関連して上述されたように）。チャンクハッシュ数は、チャンクテーブル５３１におけるエントリと比較される。一致が見出された場合には、新しいチャンクは、格納システムにすでに格納されたチャンクと同一であるので、捨てられる。チャンクが新しい場合には、そのための新しいエントリがチャンクテーブル５３１の中に作成され、ハッシュされたチャンクは物理的格納マネージャ５４に渡される。物理的格納マネージャは、利用可能な格納デバイス５７１、５７２および５７３の上で可能な最も効率的なパターンでチャンクを格納して、チャンクのコンテンツが後で５１２で検索され得るように（図１に関連して上述されたように）、チャンクの物理的格納がどこで発生したかを示すために、チャンクテーブル５３１の中に対応するエントリを作成する。
オブジェクトインタフェース５１１、ブロックインタフェース５１２、またはＣＩＦＳインタフェース５１３による、図５におけるデータの検索は、検索マネジャー５６に対するリクエストによって実行され、検索マネージャは、どのチャンクがオブジェクトを含むかを決定するためにオブジェクトテーブル５２１を調べ、次にこれらのチャンクを物理的格納マネージャ５４から要求する。物理的格納マネージャ５４は、要求されたチャンクがどこに格納されているかを決定するためにチャンクテーブル５３１を調べ、次にそれらを検索し、完了したデータ（オブジェクト）を検索マネージャ５６に返し、検索マネージャは、要求しているインタフェースにデータを返す。図５には、故障許容マネージャ（ＦＴＬ）５５も含まれ、チャンクが可能な最も効率的な方法で格納されているかどうかを決定するために、絶えずチャンクテーブルをスキャンする。（格納デバイス５７１、５７２および５７３が追加されたり取り外されたりすると、これらは変化し得る。）チャンクが可能な最も効率的な方法で格納されていない場合には、ＦＴＬは、物理的格納マネージャ５４に、チャンクについて新しいレイアウトパターンを作成し、チャンクテーブル５３１をアップデートするように、要求する。このようにして、すべてのデータは、アレイを含む格納デバイスの数について可能な最も効率的な方法で格納されたままでいる（図２および３に関連して上述されたように）。
以下は、本発明の例示的な実施形態のさらなる詳細を提供する。
（データレイアウトスキーム−ゾーン）
なかでも、ゾーンは、ディスクの上に格納されている実際のデータから、冗長性とディスク再レイアウトとを隠す効果を有する。ゾーンは、ゾーンのユーザに影響することなく、追加のレイアウト方法が追加および変更されることを可能にする。
格納アレイは、ゾーンと呼ばれる仮想セクションにおけるディスクの上で、データをレイアウトする。ゾーンは、所定および固定の量（たとえば１Ｇバイト）のデータを格納する。ゾーンは、単一のディスクの上に存在し得るか、あるいは一つ以上のドライブにわたってまたがり得る。ゾーンの物理的レイアウトは、そのゾーンについて指定された形で冗長性を提供する。
図６は、２つ以上のドライブを含むアレイにおいてミラリングが使用される例を示す。図７は、データを格納するために異なるレイアウトスキームを使用するいくつかの例示的なゾーンを示す。図は、ゾーンが１ＧＢのデータを格納することを想定する。以下の点に留意されたい。
ｉ）複数のドライブにまたがるゾーンは、セットにわたるドライブの中に同じオフセットを必ずしも使用しない。
ｉｉ）単一ドライブミラリングは、１Ｇのデータを格納するために２Ｇの格納デバイスを必要とする。
ｉｉｉ）二重ドライブミラリングは、１Ｇのデータを格納するために２Ｇの格納デバイスを必要とする。
ｉｖ）３つのドライブストライピングは、１Ｇのデータを格納するために１．５Ｇの格納デバイスを必要とする。
ｖ）４つのドライブストライピングは、１Ｇのデータを格納するために１．３３Ｇの格納デバイスを必要とする。
ｖｉ）ゾーンＡ、ゾーンＢなどは、任意のゾーン名である。実際のインプリメンテーションにおいて、それぞれのゾーンは一意の数によって識別され得る。
ｖｉｉ）図によって暗示されるものの、ゾーンは必ずしもディスクの上で隣接しない（後で領域を参照）。
ｖｉｉｉ）ミラリングが２つのドライブに制約される技術的理由はない。たとえば、３ドライブシステムにおいて、データの一つのコピーが一つのドライブの上に格納され得、ミラリングされたデータの半分が他の２つのドライブのそれぞれの上に格納され得る。同様に、データは３つのドライブにわたってミラリングされ得、データの半分が２つのドライブのそれぞれの上にミラリングされ、ミラリングの半分が他の２つのドライブの上にミラリングされる。
（データレイアウトスキーム−領域）
各ディスクは、均等なサイズの領域に分割される。領域のサイズはゾーンよりもはるかに小さく、ゾーンは一つ以上のディスクからの一つ以上の領域から構築される。ディスクスペースの効率的な使用のために、領域のサイズは一般的に、異なるゾーンサイズと、アレイによってサポートされる異なる数のディスクとの共通因子である。例示的な実施形態において、領域はゾーンの１／１２のデータサイズである。以下の表は、本発明の例示的な実施形態に従って、種々のレイアウトについての、領域／ゾーンの数と、領域／ディスクの数とを列挙する。
Figure 2009536414
Figure 2009536414
 個々の領域は、使用済み、使用されていない、または不良としてマークされ得る。ゾーンが作成されるときには、適切なディスクから使用されていない領域のセットが、テーブルにおいて選択されログをとられる。これらの領域は、任意の順序であり得、ディスクの上で隣接する必要はない。データがゾーンに書き込まれるかまたはゾーンから読み取られるときには、アクセスは適切な領域にリダイレクトされる。なかでも、このことは、データの再レイアウトが柔軟かつ効率的な方法で生ずることを可能にする。時間を経て、異なるサイズのゾーンは、おそらく断片化を発生させ、小さすぎて完全なゾーンを保持できない多くのディスクエリアを残す。適切な領域サイズを使用することによって、断片化によって残されたすべてのギャップは、サイズにおいて少なくとも一つの領域になり、ディスク全体を断片化解消（ｄｅ−ｆｒａｇｍｅｎｔ）する必要なしに、これらの小さなギャップの容易な再使用を可能にする。
（データレイアウトスキーム−再レイアウト）
インプリメンテーションを容易にするために、固定シーケンスの拡張および縮小が強化され得る。たとえば、２つのドライブが急に追加される場合には、第２のドライブを組み込むために第２の拡張が実行される前に、あたかも一つのドライブが追加されたかのように、ゾーンの拡張が中間の拡張を経由し得る。代替的には、複数のドライブを含む拡張および縮小は、中間のステップなしに、アトミックに（ａｔｏｍｉｃａｌｌｙ）処理され得る。
任意の再レイアウトが生じる前に、必要とされるスペースが利用可能でなければならない。このことは、不必要な再レイアウトが生じないことを確実にするために、再レイアウトを始める前に計算されるべきである。
（レイアウトスキーム−ドライブ拡張）
以下は、本発明の例示的な実施形態に従って、単一ドライブミラリングから二重ドライブミラリングに拡張する一般的なプロセスを説明する。
ｉ）単一ドライブミラリングが、データ「Ａ」とミラリング「Ｂ」とを有すると想定する。
ｉｉ）ゾーンを「Ｃ」へと拡張するために、ドライブの上に１２の領域を割当てる。
ｉｉｉ）ミラリング「Ｂ」を領域セット「Ｃ」にコピーする。
ｉｖ）すでにコピーされたデータへのいかなる書き込みも、「Ｃ」における適切な場所にミラリングされなければならない。
ｖ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ｂ」へのポインタを「Ｃ」へのポインタに置き換える。
ｖｉ）「Ｂ」を構成する領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って二重ドライブミラリングからパリティを用いた三重ドライブストライピングへと拡張する、一般的なプロセスを説明する。
ｉ）一つのドライブがデータ「Ａ」を有し、第２のドライブがミラリング「Ｂ」を有すると想定する。
ｉｉ）パリティ情報「Ｃ」のために、第３のドライブの上に６つの領域を割当てる。
ｉｉｉ）「Ａ」の第１の６領域と、「Ｂ」の第２の６領域とを使用して、パリティ情報を計算する。
ｉｖ）「Ｃ」にパリティ情報を置く。
ｖ）すでに処理されたデータになされたいかなる書き込みも、「Ｃ」における適切な場所にパリティされなければならない。
ｖｉ）コピーが完了したら、新しいレイアウトタイプのポイントテーブルを用いて、ゾーンテーブルを、「Ａ」の第１の半分と、「Ｂ」の第２の半分と、「Ｃ」とにアップデートする。
ｖｉｉ）「Ａ」の第２の半分と「Ｂ」の第１の半分とを、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って三重ドライブストライピングからパリティを用いた四重ドライブストライピングに拡張する、一般的なプロセスを説明する。
ｉ）一つのドライブがデータ「Ａ」を有し、第２のドライブがデータ「Ｂ」を有し、第３のドライブがパリティ「Ｐ」を有すると想定する。
ｉｉ）ストライピングデータ「Ｃ」のために、第４のドライブの上に４つの領域を割当てる。
ｉｉｉ）「Ａ」の最後の２領域を、「Ｃ」の最初の２領域にコピーする。
ｉｖ）「Ｂ」の最初の２領域を、「Ｃ」の最後の２領域にコピーする。
ｖ）パリティドライブ「Ｄ」の上に４つの領域を割当てる。
ｖｉ）Ａの最初の４領域と、Ｃと、Ｂの最後の４領域とを使用して、パリティ情報を計算する。
ｖｉｉ）パリティ情報を「Ｄ」に置く。
ｖｉｉｉ）すでに処理されたデータへのいかなる書き込みも、「Ｄ」における適切な場所にパリティされなければならない。
ｉｘ）新しいレイアウトタイプとポイントテーブルとを用いて、ゾーンテーブルを、「Ａ」の第１の４領域と、「Ｃ」と、「Ｂ」の第２の４領域と、「Ｄ」とにアップデートする。
ｘ）「Ａ」の最後の２領域と、「Ｂ」の最初の２領域を、使用されていないとしてマークする。
（データレイアウトスキーム−ドライブ縮小）
ドライブ縮小は、ディスクが取り外されるかまたは故障するときに発生する。そのような場合には、アレイは、可能であればすべてのゾーンを冗長状態に戻すために、データを縮小する。ドライブ縮小は、拡張よりもやや複雑である。なぜなら、より多くの選択がなされるべきだからである。しかし、レイアウト方法の間の移行は、拡張と同様の方法で生じるが、逆の順序である。再生されるべきデータの量を最小限に保つことは、冗長性が可能な限り迅速に達成されることを可能にする。ドライブ縮小は、すべてのゾーンが再レイアウトされるまで、スペースが利用可能である間に、一般的に一度に１ゾーン先行する。一般的に言って、取り外されたかまたは故障したディスクの上に存在するデータのみが再構築される。
（どのように縮小するかの選択）
以下の表は、本発明の例示的な実施形態に従って、再レイアウトされる必要のある各ゾーンについての決定ツリーを説明する：
Figure 2009536414
Figure 2009536414
 以下は、本発明の例示的な実施形態に従って、二重ドライブミラリングから単一ドライブミラリングに縮小する一般的なプロセスを説明する。
ｉ）単一ドライブミラリングが、データ「Ａ」と欠いているミラリング「Ｂ」とを有するか、またはその逆であると仮定する。
ｉｉ）「Ａ」を「Ｃ」として含むドライブの上に１２の領域を割当てる。
ｉｉｉ）データ「Ａ」を領域セット「Ｃ」にコピーする。
ｉｖ）すでにコピーされたデータへのいかなる書き込みも、「Ｃ」における適切な場所にミラリングされなければならない。
ｖ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ｂ」へのポインタを「Ｃ」へのポインタに置き換える。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングから二重ドライブミラリングに縮小する一般的なプロセスを説明する（パリティを欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」および「Ｃ」からなると想定する。パリティ「Ｃ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の半分を含むものとして定義し、「Ｂ」をゾーンの第２の半分を含むものとして定義する。
ｉｉｉ）「Ａ」ドライブの上に６つの領域「Ｄ」を割当て、「Ｂ」ドライブの上に６つの領域「Ｅ」を割当てる。
ｉｖ）「Ａ」を「Ｅ」にコピーする。
ｖ）「Ｂ」を「Ｄ」にコピーする。すでにコピーされたデータへのいかなる書き込みも、「Ｄ」および「Ｅ」における適切な場所にミラリングされなければならない。
ｖｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ａ」／「Ｄ」および「Ｅ」／「Ｂ」へのポインタを設定する。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングから二重ドライブミラリングに縮小する一般的なプロセスを説明する（データを欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」および「Ｃ」からなると想定する。データ「Ｃ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の半分を含むものとして定義し、「Ｃ」をゾーンの第２の半分を含むものとして定義する。
ｉｉｉ）「Ａ」ドライブの上に６つの領域「Ｄ」を割当て、「Ｂ」ドライブの上に１２の領域「Ｅ」を割当てる。
ｉｖ）「Ａ」を「Ｅ」の第１の半分にコピーする。
ｖ）「Ａ」および「Ｂ」から、欠けているデータを再構築する。データを「Ｄ」に書き込む。
ｖｉ）「Ｄ」を「Ｅ」の第２の半分にコピーする。
ｖｉｉ）すでにコピーされたデータへのいかなる書き込みも、「Ｄ」および「Ｅ」における適切な場所にミラリングされなければならない。
ｖｉｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ａ」／「Ｄ」および「Ｅ」へのポインタを設定する。
ｉｘ）「Ｂ」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重ドライブストライピングから三重ドライブストライピングに縮小する一般的なプロセスを説明する（パリティを欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」、「Ｃ」および「Ｄ」からなると仮定する。パリティ「Ｄ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の３分の１を含むものとして定義し、「Ｂ」を第２の３分の１を含むものとして定義し、「Ｃ」を第３の３分の１を含むものとして定義する。
ｉｉｉ）「Ａ」ドライブの上に２領域「Ｇ」を割当て、「Ｃ」ドライブの上に２領域「Ｅ」を割当て、「Ｂ」ドライブの上に６領域「Ｆ」を割当てる。
ｉｖ）「Ｂ」の第１の半分を「Ｇ」にコピーする。
ｖ）「Ｂ」の第２の半分を「Ｅ」にコピーする。
ｖｉ）「Ａ」／「Ｇ」および「Ｅ」／「Ｃ」からパリティを構築し、「Ｆ」に書き込む。ｖｉｉ）すでにコピーされたデータへのいかなる書き込みも、「Ｇ」、「Ｅ」および「Ｆ」における適切な場所にミラリングされなければならない。
ｖｉｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ａ」／「Ｇ」、「Ｅ」／「Ｃ」、および「Ｆ」へのポインタを設定する。ｉｘ）「Ｂ」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングに縮小する一般的なプロセスを説明する（最初の１／３を欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」、「Ｃ」および「Ｄ」からなると想定する。データ「Ａ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の３分の１を含むものとして定義し、「Ｂ」を第２の３分の１を含むものとして定義し、「Ｃ」を第３の３分の１を含むものとして定義し、「Ｄ」をパリティを含むものとして定義する。
ｉｉｉ）「Ｂ」ドライブの上に４領域「Ｅ」を割当て、「Ｃ」ドライブの上に２領域「Ｆ」を割当て、「Ｄ」ドライブの上に６領域「Ｇ」を割当てる。
ｉｖ）「Ｂ」の第２の半分を「Ｆ」にコピーする。
ｖ）「Ｂ」、「Ｃ」および「Ｄ」から、欠けているデータを構築し、「Ｅ」に書き込む。ｖｉ）「Ｅ」／「Ｂの第１の半分」と、「Ｆ」／「Ｃ」とから新しいパリティを構築し、「Ｇ」に書き込む。
ｖｉｉ）すでにコピーされたデータへのいかなる書き込みも、「Ｂ」、「Ｅ」、「Ｆ」および「Ｇ」における適切な場所にミラリングされなければならない。
ｖｉｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ｅ」／「Ｂの第１の半分」、「Ｆ」／「Ｃ」、および「Ｇ」へのポインタを設定する。
ｉｘ）「Ｂ」の第２の半分および「Ｄ」の領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングに縮小する一般的なプロセスを説明する（第２の１／３を欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」、「Ｃ」および「Ｄ」からなると想定する。データ「Ｂ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の３分の１を含むものとして定義し、「Ｂ」を第２の３分の１を含むものとして定義し、「Ｃ」を第３の３分の１を含むものとして定義し、「Ｄ」をパリティを含むものとして定義する。
ｉｉｉ）「Ａ」ドライブの上に２領域「Ｅ」を割当て、「Ｃ」ドライブの上に２領域「Ｆ」を割当て、「Ｄ」ドライブの上に６領域「Ｇ」を割当てる。
ｉｖ）「Ａ」の第１の半分、「Ｃ」の第１の半分、および「Ｄ」の第１の半分から、欠けているデータを構築し、「Ｅ」に書き込む。
ｖ）「Ａ」の第２の半分、「Ｃ」の第２の半分、および「Ｄ」の第２の半分から、欠けているデータを構築し、「Ｆ」に書き込む。
ｖｉ）「Ａ」／「Ｅ」および「Ｆ」／「Ｃ」から新しいパリティを構築し、「Ｇ」に書き込む。
ｖｉｉ）すでにコピーされたデータへのいかなる書き込みも、「Ｅ」、「Ｆ」および「Ｇ」における適切な場所にミラリングされなければならない。
ｖｉｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ｅ」、「Ｆ」および「Ｇ」へのポインタを設定する。
ｉｘ）「Ｄ」領域を、使用されていないとしてマークする。
以下は、本発明の例示的な実施形態に従って、四重のドライブストライピングから三重のドライブストライピングへの縮小の一般的なプロセスを説明する（第３の１／３を欠いている）。
ｉ）ストライピングは、異なるドライブの上のデータブロック「Ａ」、「Ｂ」、「Ｃ」および「Ｄ」からなると想定する。データ「Ｃ」が欠けている。
ｉｉ）「Ａ」をゾーンの第１の３分の１を含むものとして定義し、「Ｂ」を第２の３分の１を含むものとして定義し、「Ｃ」を第３の３分の１を含むものとして定義し、「Ｄ」をパリティを含むものとして定義する。
ｉｉｉ）「Ａ」ドライブの上に２領域「Ｅ」を割当て、「Ｂ」ドライブの上に４領域「Ｆ」を割当て、「Ｄ」ドライブの上に６領域「Ｇ」を割当てる。
ｉｖ）「Ｂ」の第１の半分を「Ｅ」にコピーする。
ｖ）「Ａ」、「Ｂ」および「Ｄ」から、欠けているデータを構築し、「Ｆ」に書き込む。ｖｉ）「Ａ」／「Ｅ」と、「Ｂ」／「Ｆ」の第２の半分とから新しいパリティを構築し、「Ｇ」に書き込む。
ｖｉｉ）すでにコピーされたデータへのいかなる書き込みも、「Ｅ」、「Ｆ」および「Ｇ」における適切な場所にミラリングされなければならない。
ｖｉｉｉ）コピーが完了したら、新しいレイアウトタイプを用いてゾーンテーブルをアップデートし、「Ａ」／「Ｅ」、「Ｂ」／「Ｆ」の第２の半分、および「Ｇ」へのポインタを設定する。
ｉｘ）「Ｂ」の第１の半分および「Ｄ」を、使用されていないとしてマークする。
たとえば、図３を再び参照して、ドライブ０またはドライブ１のいずれかが失われた場合には、ドライブ２の上に十分な利用可能なスペースがあるという条件で、二重ドライブミラリング（ゾーンＢ）はドライブ２の上で再構築され得る。同様に、ドライブ０〜２のいずれかが失われた場合には、ドライブ３の上に十分な利用可能なスペースがあるという条件で、ドライブストライピング（ゾーンＣ）は、ドライブ３を利用して再構築され得る。
（データレイアウトスキーム−ゾーン再構築）
ゾーン再構築は、ドライブが取り外されて、理想的なゾーン再レイアウトのために残りのドライブの上に十分なスペースがあるとき、あるいはドライブがより大きなサイズの新しいドライブと置き換えられたときに、生じる。
以下は、本発明の例示的な実施形態に従って、二重ドライブミラリングの再構築の一般的なプロセスを説明する。
ｉ）単一ドライブミラリングが、データ「Ａ」と欠けているミラリング「Ｂ」とを有すると想定する。
ｉｉ）「Ａ」を含むドライブ以外のドライブの上に１２の領域「Ｃ」を割当てる。
ｉｉｉ）データ「Ａ」を「Ｃ」にコピーする。
ｉｖ）すでにコピーされたデータへのいかなる書き込みも、「Ｃ」における適切な場所にミラリングされなければならない。
ｖ）コピーが完了したら、ゾーンテーブルをアップデートし、「Ｂ」へのポインタを「Ｃ」へのポインタにアップデートする。
以下は、本発明の例示的な実施形態に従って、三重ドライブストライピングの再構築の一般的なプロセスを説明する。
ｉ）一つのドライブがデータ「Ａ」を有し、第２のドライブがデータ「Ｂ」を有し、第３のドライブがパリティ「Ｐ」を有すると想定する。「Ｂ」が欠けている。どの断片が欠けているかは問題ではなく、必要とされる行動はすべての場合において同じであることに留意されたい。
ｉｉ）「Ａ」および「Ｐ」を含むドライブ以外のドライブの上に、６つの領域「Ｄ」を割当てる。
ｉｉｉ）「Ａ」および「Ｐ」から、欠けているデータを構築する。データを「Ｄ」に書き込む。
ｉｖ）すでに処理されたデータへのいかなる書き込みも、「Ｄ」における適切な場所にパリティされなければならない。
ｖ）「Ｂ」へのポインタを「Ｄ」へのポインタに置き換えることによって、ゾーンテーブルをアップデートする。
この例示的な実施形態において、取り外されたドライブが別のドライブと置き換えられる場合に、４ドライブ再構築のみが生じる。再構築は、新しいドライブの上に６つの領域を割当てることと、他の３つの領域セットから、欠けているデータを再構築することとからなる。
（データレイアウトスキーム−一時的に欠けるドライブの問題）
ドライブが取り外されて、再レイアウトのための余地がないときには、古いドライブが再び取り付けられるか、またはドライブが新しいドライブと置き換えられるまで、アレイは劣化したモードで作動し続ける。新しいドライブが取り付けられる場合には、ドライブセットが再構築されるべきである。この場合には、データが再レイアウトされる。古いディスクがアレイの中に戻して置かれる場合には、それはもはや現在のディスクセットの一部ではなく、新しいディスクとしてみなされる。しかし、新しいディスクがアレイに置かれるのではなく、古いディスクが戻される場合には、古いディスクは、たとえ古いメンバであろうとも、やはりディスクセットのメンバであるとして認識される。この場合には、すでに再レイアウトされた任意のゾーンが新しい構成を保ち、古いディスクの上の領域は解放される。再レイアウトされていない任意のゾーンは、やはり古いディスクの適切な領域をポインティングする。しかし、劣化したゾーンに何らかの書き込みが実行され得た場合には、これらのゾーンはリフレッシュされる必要がある。生じたすべての書き込みのログをとるのではなく、変更された劣化領域はマークされ得る。このようにして、ディスクが置き換えられるときには、変更された領域のみがリフレッシュされる必要がある。
さらに、書き込まれたゾーンは、再レイアウトのための優先リストにさらに置かれ得る。このことは、ディスクが置き換えられた場合に、リフレッシュされる必要がある領域の数を低減し得る。タイムアウトも使用され得、その時点の後で、ディスクはたとえ置き換えられても消去される（ｗｉｐｅｄ）。しかし、このタイムアウトは非常に大きくあり得、場合によると数分ではなく数時間である。
（データレイアウトスキーム−データ保全性）
上述のように、標準的なＲＡＩＤシステムの一つの問題は、ディスクアレイのまれにしか使用されないエリアの上で、ディスク表面の破損が生じる可能性があることである。別のドライブが故障する場合には、破損が生じたことを決定することは必ずしも可能ではない。そのような場合には、ＲＡＩＤアレイが故障したドライブを再構築するときに、破損したデータが伝播され保存され得る。
上述のハッシュメカニズムは、ＲＡＩＤのもとで利用可能なメカニズムにわたってデータ破損検出の追加のメカニズムを提供する。他の場合に述べられるように、チャンクが格納されるときに、そのチャンクについて、ハッシュ値が計算され格納される。チャンクが読み出されるときはいつでも、検索されたチャンクについてのハッシュ値が計算され得、格納されたハッシュ値と比較され得る。ハッシュ値が一致しない場合には（破損したチャンクを示し）、チャンクデータは冗長データから回復され得る。
ディスクの上のデータ破損が生じ得る時間窓（ｔｉｍｅ ｗｉｎｄｏｗ）を最小化するために、破損したデータを可能な限り速やかに発見し修正するように、ディスクの定期的なスキャンが実行される。それは、オプションとして、アレイからの読み出しにおいてチェックが実行されることをも可能にする。
（データレイアウトスキーム−ボリューム）
スパースボリューム（ｓｐａｒｓｅ ｖｏｌｕｍｅ）において、アレイにおけるディスクの上で利用可能な格納スペースの量に関わりなく、アレイは固定サイズ（たとえばＭテラバイト）であることをつねに求める。アレイはＳバイトの実際の格納スペースを含み、ここでＳ＜＝Ｍであり、データは、Ｍテラバイトのスペースの中の位置Ｌ１、Ｌ２、Ｌ３などに格納されるように要求され得ると仮定する。要求された位置Ｌｎ＞Ｓである場合には、Ｌｎのためのデータは、位置Ｐｎ＜Ｓに格納されなければならない。このことは、図８に示されるように、Ｌｎに基づいてインデックスＰｎに対するルックアップテーブルを含むことによって管理される。この特徴は、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）およびＡｐｐｌｅ（登録商標）のオペレーティングシステムなどの、ボリューム拡張をサポートしないオペレーティングシステムとともに、アレイが作動することを可能にする。さらに、アレイは、複数のスパースボリュームを提供し得、そのすべては同一の物理格納を共有する。それぞれのスパースボリュームは、専用のルックアップテーブルを有するが、データ格納のために同一の物理スペースを共有する。
（ドライブスロットインジケータ）
上述のように、格納アレイは一つ以上のドライブスロットからなる。それぞれのドライブスロットは、空であり得るか、またはハードディスクドライブを含み得る。それぞれのドライブスロットは、４つの状態を示す能力のある専用インジケータを有する。すなわち、オフ、ＯＫ、劣化、および故障である。状態は、一般的に以下のように解釈される：
Figure 2009536414
 この例示的な実施形態において、赤色／琥珀色／緑色の発光ダイオード（ＬＥＤ）がインジケータとして使用される。ＬＥＤは、一般的に以下のように解釈される：
Figure 2009536414
 図９は、本発明の例示的な実施形態に従った、利用可能な格納スペースを有し、故障許容方法において作動する、例示的なアレイを示す。スロットＢ、ＣおよびＤには、格納デバイスが配置され、追加のデータを冗長に格納するために利用可能な十分な格納スペースがある。スロットＢ、ＣおよびＤのインジケータは緑色であり（これらの格納デバイスが正しく作動しており、アレイデータが冗長であり、アレイが利用可能なディスクスペースを有することを示す）、スロットＡのインジケータはオフである（格納デバイスをスロットＡに配置する必要がないことを示す）。
図１０は、本発明の例示的な実施形態に従った、冗長データ格納を維持するために十分なスペースを有せず、より多くのスペースが追加されなければならない、例示的なアレイを示す。スロットＢ、ＣおよびＤには、格納デバイスが配置される。スロットＣおよびＤにおける格納デバイスは満杯である。スロットＢ、ＣおよびＤのインジケータは緑色であり（これらの格納デバイスが正しく作動していることを示す）、スロットＡのインジケータは赤色である（アレイが、冗長データ格納を維持するための十分なスペースを有せず、スロットＡに格納デバイスが配置されるべきであることを示す）。
図１１は、本発明の例示的な実施形態に従った、故障の場合に冗長データを維持することができなくあり得る、例示的なアレイを示す。スロットＡ、Ｂ、ＣおよびＤには、格納デバイスが配置される。スロットＣおよびＤにおける格納デバイスは満杯である。スロットＡ、ＢおよびＣのインジケータは緑色であり（アレイが正しく作動していることを示す）、スロットＤのインジケータは琥珀色である（スロットＤにおける格納デバイスが、より大きな格納容量を有する格納デバイスに置き換えられるべきであることを示す）。
図１２は、本発明の例示的な実施形態に従った、格納デバイスが故障した例示的なアレイを示す。スロットＢ、ＣおよびＤには、格納デバイスが配置される。スロットＣにおける格納デバイスが故障した。スロットＢおよびＤのインジケータは緑色であり（これらが正しく作動していることを示す）、スロットＣのインジケータは赤色であり（スロットＣにおける格納デバイスが置き換えられるべきであることを示す）、スロットＡのインジケータはオフである（格納デバイスがスロットＡに配置される必要がないことを示す）。
以下は、本発明の例示的な実施形態のためのソフトウェア設計の説明である。ソフトウェア設計は、６つのソフトウェアレイヤに基づき、ソフトウェアレイヤは、ディスクに物理的にアクセスすることから、ホストコンピューティングシステムと通信することまでの、論理アーキテクチャにわたる。
この例示的な実施形態において、ファイルシステムは、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）またはＡｐｐｌｅ（登録商標）などのホストサーバに常駐し、ＵＳＢデバイスまたはｉＳＣＳＩデバイスとして格納アレイにアクセスする。ホストインタフェースを介して到着する物理的ディスクリクエストは、ホストリクエストマネージャ（Ｈｏｓｔ Ｒｅｑｕｅｓｔ Ｍａｎａｇｅｒ）（ＨＲＭ）によって処理される。ホストＩ／Ｏインタフェースは、ホストに対するホストＵＳＢまたはｉＳＣＳＩインタフェースのプレゼンテーションを調整し（ｃｏｏｒｄｉｎａｔｅ）、ＨＲＭとインタフェースする。ＨＲＭは、ホストＩ／Ｏインタフェースからのデータ読み出し／書き込みリクエストを調整し、読み出しおよび書き込みリクエストをタスク指名し、これらのリクエストが完了したときに、これらのリクエストのホストへの回収（ｒｅｔｉｒｉｎｇ）を調整する。
格納アレイの何よりも重要な目的は、ひとたびデータがシステムによって受け入れられると、システムが現在格納する冗長性の最大量を利用して、データが確実な方法で格納されることを保証することである。アレイが物理的構成を変化させると、データは冗長性を維持する（さらに場合によると最大化する）ために再編成される。さらに、使用される格納量を低減するために、単純なハッシュに基づいた圧縮が使用される。
最も基本的なレイヤは、データを異なるディスクに格納するディスクドライバからなる。ディスクは、ＵＳＢインタフェースを介して通り抜けた（ｔｕｎｎｅｌｅｄ）ＡＴＡなどの種々のインタフェースを介して接続され得る。
ディスクの上のセクタは、領域、ゾーン、およびクラスタに編成され、それぞれが異なる論理的役割を有する。
領域は、ディスクの上の隣接する物理ブロックのセットを表す。４ドライブシステムにおいて、それぞれの領域は、サイズが１／１２ＧＢであり、冗長性の最小単位を表す。領域の中のセクタが物理的に損傷していることがわかった場合は、領域全体が放棄される。
ゾーンは、冗長性の単位を表す。ゾーンは、適切な量の冗長性を提供するために、場合により異なるディスクの上の、多数の領域からなる。ゾーンは、１ＧＢのデータ容量を提供するが、冗長性を提供するためにより多くの領域を要求し得る。冗長性のない１ＧＢは、１セットの１２領域（１ＧＢ）を要求する；１ＧＢのミラリングされたゾーンは、２セットの１ＧＢ領域（２４領域）を要求する；１ＧＢの３ディスクストライピングされたゾーンは、３セットの０．５ＧＢ領域（１８領域）を要求する。異なるゾーンは、異なる冗長特性を有する。
クラスタは、圧縮の基本単位を表し、ゾーンの中の単位サイズである。クラスタのサイズは現在４ＫＢ、すなわち８×５１２バイトセクタである。ディスクの上の多くのクラスタは、おそらく同じデータを含む。クラスタアクセステーブル（ＣＡＴ）は、ハッシュ関数を介してクラスタの利用を追跡するために使用される。ＣＡＴは、論理ホストアドレスと、ゾーンにおける適切なクラスタの位置との間の変換をする。
ディスクに書き込むときに、データがディスクの上にすでに存在するかどうかを知るためにハッシュ関数が使用される。そうである場合には、ＣＡＴテーブルにおける適切なエントリが、既存のクラスタを示すように設定される。
ＣＡＴテーブルは、自らのゾーンの中に常駐する。ＣＡＴテーブルがゾーンのサイズを超える場合には、追加のゾーンが使用され、ＣＡＴのその部分のゾーンに論理アドレスをマッピングするために、テーブルが使用される。代替的には、ゾーンはＣＡＴテーブルを含むように事前に割当てられる。
ホスト書き込み待ち時間を低減し、データ信頼性を保証するために、ジャーナルマネージャが、（ディスクまたはＮＶＲＡＭのいずれかに対する）すべての書き込みリクエストを記録する。システムが再起動される場合には、ジャーナルエントリは再起動に際してコミットされる。
ディスクは出入りし得、領域は、破損を有することがわかった場合には、使わなく（ｒｅｔｉｒｅ）され得る。これらの状況のいずれにおいても、レイアウトマネージャは、冗長タイプを変更するために、またはゾーンの領域的な構成を変化させるために（領域が破損した場合に）、
ゾーンの中の領域を再編成することが可能である。
格納アレイは、物理的ディスクスペースの変化するレベルによって支援されて、仮想ディスクアレイを提供し、それはブロックレベルのインタフェースを提供するので、いつクラスタがファイルシステムによってもはや使われなくなるかは、明らかではない。結果として、使用されるクラスタスペースは、拡張し続ける。ガーベッジコレクタ（ホストまたはファームウェアのいずれかに位置する）は、どのクラスタが解放されたかを決定するためにファイルシステムを分析し、それらをハッシュテーブルから取り除く。
以下の表は、本発明の例示的な実施形態に従った６つのソフトウェアレイヤを示す：
Figure 2009536414
 図１３は、異なるソフトウェアレイヤと、それらが互いにどのように関連するかを表す、モジュール階層を示す。ソフトウェアレイヤリングは、明瞭なＡＰＩおよび記述を提供するために、好ましくはリジッドである。
ガーベッジコレクタ（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｏｒ）は、ホストファイルシステムによってもはや使われないクラスタを解放する。たとえば、ファイルが削除されるときに、そのファイルを含むために使用されたクラスタは、好ましくは解放される。
ジャーナルマネージャ（Ｊｏｕｒｎａｌ Ｍａｎａｇｅｒ）は、書き込みの実行記録（ｊｏｕｒｎａｌｉｎｇ）の形を提供するので、電源異常または他のエラー状態の場合において、保留中の書き込みは失われない。
レイアウトマネージャ（Ｌａｙｏｕｔ Ｍａｎａｇｅｒ）は、ゾーンの領域に対するゾーンのランタイム再レイアウトを提供する。このことは、ディスクの挿入／取り外しまたは故障の結果として生じ得る。
クラスタマネージャ（Ｃｌｕｓｔｅｒ Ｍａｎａｇｅｒ）は、データゾーンのセットの中にクラスタを割当てる。ディスク利用デーモン（Ｄｉｓｋ Ｕｔｉｌｉｚａｔｉｏｎ Ｄａｅｍｏｎ）は、使用されていないディスクスペースを定期的にチェックする。
ロックテーブル（Ｌｏｃｋ Ｔａｂｌｅ）は、書き込み衝突発行（ｃｏｌｌｉｓｉｏｎ ｉｓｓｕｅｓ）の後で、読み出しを処理する。
ホストリクエストマネージャ（Ｈｏｓｔ Ｒｅｑｕｅｓｔ Ｍａｎａｇｅｒ）は、ホストおよびガーベッジコレクタからの読み出し／書き込みリクエストを処理する。書き込みはジャーナルマネージャに渡されるが、読み出しはクラスタアクセステーブル（ＣＡＴ）管理レイヤを介して処理される。
上述のように、代表的なファイルシステムにおいて、ある量のデータが一般的に事実上反復される。ディスクスペース利用を低減させるために、このデータの複数のコピーはディスクに書き込まれない。代わりに、一つのインスタンスが書き込まれ、同じデータのすべての他のインスタンスが、この一つのインスタンスに対して参照される。
この例示的な実施形態において、システムはつねにデータのクラスタの上で作動し（たとえば８つの物理的セクタ）、これはハッシュされる単位である。ＳＨＡ１アルゴリズムは、１６０ビットハッシュを生成するために使用される。このことは、良好な独特さ（ｕｎｉｑｕｅｎｅｓｓ）を含む多数の利益を有し、多数のプロセッサにおいてオンチップでサポートされる。すべての１６０ビットがハッシュレコードに格納されるが、最下位の１６ビットのみがハッシュテーブルへのインデックスとして使用される。最も低い１６ビットと一致する他のインスタンスは、リンクされたリストを介して連鎖される。
この例示的な実施形態において、一度に一つの読み出し／書き込み操作のみが生じ得る。性能の目的のために、クラスタをディスクに書き込むときにハッシュ分析が生じることは許されない。代わりに、ハッシュ分析は、ハッシュマネージャによるバックグラウンド活動として生じる。
書き込みリクエストは、ジャーナルの書き込みキューから読み込まれ、完了に向けて処理される。データの一貫性を保証するために、書き込み操作がクラスタの上ですでに活動状態である場合には、書き込みは遅らせなければならない。他のクラスタの上の操作は、妨げられずに進行し得る。
クラスタ全体が書き込まれない限りは、書き込まれるデータは、クラスタに格納された既存のデータと併合される必要がある。論理セクタアドレス（ＬＳＡ）に基づいて、クラスタのＣＡＴエントリが位置づけられる。ハッシュキー、ゾーン、およびクラスタオフセット情報は、このレコードから獲得され、次に、ハッシュテーブルを検索して一致を見出すために使用され得る。これがクラスタである。
正しいハッシュエントリのルックアップの速度を改善するために、一度はＳＨＡ１ダイジェストを介して、次にゾーン／クラスタオフセットによって、ハッシュテーブルを二重にハッシュすることは十分に必要であり得る。ハッシュレコードがすでに使用されている場合には、参照カウントが減少させられる。参照カウントが現在ゼロであり、かつハッシュエントリによって参照されるスナップショットがない場合には、ハッシュエントリおよびクラスタは、それぞれのフリーリストに解放し返され得る。
もともとのクラスタデータは、これでクラスタのアップデートセクションと併合させられ、データは再ハッシュされる。新しいクラスタはフリーリストから除去され、併合されたデータはクラスタに書き込まれ、新しいエントリはハッシュテーブルに追加され、ＣＡＴテーブルにおけるエントリは新しいクラスタを指し示すようにアップデートされる。
ハッシュテーブルをアップデートする結果として、エントリも内部キューに追加されて、バックグラウンドタスクによって処理される。このタスクは、新たに追加されたクラスタおよびハッシュエントリと、ハッシュテーブル行アドレスに一致する他のハッシュエントリとを比較し、これらが重複している場合にはレコードを結合し、必要に応じてハッシュエントリおよびＣＡＴテーブルエントリを解放する。これは、この活動によって書き込み待ち時間に負荷がかけられないことを保証する。この処理の間に故障（たとえば電力の損失）が生じる場合には、種々のテーブルが削除され得、結果としてデータの損失になる。テーブルは、最終コミットがアトミックであるか、あるいはジャーナルエントリが完全に完了しなかった場合には再実行され得るような方法で、管理されるべきである。
以下は、書き込み論理の疑似コードである。
Figure 2009536414
Figure 2009536414
 読み出しリクエストもまた、一度に一つのクラスタ（「セクタ」ではなく）で処理される。読み出しリクエストは、上記に概説されたハッシュ関連の処理を経ない。代わりに、ホスト論理セクタアドレスが、ＣＡＴを参照するために使用され、ゾーン番号とゾーンの中へのクラスタオフセットとを獲得する。読み出しリクエストは、ＣＡＴキャッシュにおけるＣＡＴテーブルエントリをルックアップすべきであり、書き込み進行中のビットが設定されることにおいて遅延されなければならない。他の読み出し／書き込みは、妨げられずに進行し得る。データ保全性のチェックを改善するために、クラスタは、読み出されるときにハッシュされ、そのハッシュは、ハッシュレコードに格納されたＳＨＡ１ハッシュ値と比較される。このことは、ハッシュテーブルの中への検索キーとして、ハッシュ、ゾーン、およびクラスタを使用することを必要とする。
クラスタは、可能な限り少ないゾーンを使用するように割当てられる。なぜなら、ゾーンは、ディスクドライブの使用に直接的に対応するからである。すべてのゾーンについて、ハードドライブアレイの上に２つ以上の領域がある。ゾーンの数を最小化することによって、物理的領域の数が最小化され、したがってハードドライブアレイの上のスペースの消費が低減される。
クラスタマネージャは、データゾーンのセットからクラスタを割当てる。ゾーンにおける使用されていないクラスタを把握するために、リンクされたリストが使用される。しかし、使用されていないクラスタの情報は、ディスクの上にビットマップ（ゾーンあたり３２ＫＢ）として格納される。リンクされたリストは、ビットマップから動的に構築される。最初に、使用されていないクラスタの一定の数のリンクされたリストが、メモリの中で作成される。クラスタが割当てられると、リストは縮小する。所定の最低点において、使用されていないクラスタを表す新しいリンクされたリストのノードは、ディスクの上のビットマップから抽出される。このようにして、ビットマップは、割当て用に使用されていないクラスタを見出すために分析される必要はない。
この例示的な実施形態において、ハッシュテーブルは６４Ｋのレコード（ハッシュのより下位の１６ビットによって索引をつけられる）であり、以下のフォーマットを有する：
Figure 2009536414
Figure 2009536414
 オールゼロ（ａｌｌ ｚｅｒｏ）のクラスタは、かなり一般的であり得るので、たとえば決して削除され得ないように、オールゼロの場合は特別な場合として扱われ得る（したがってカウントをラッピング（ｗｒａｐｐｉｎｇ）することは問題ではあり得ない）。
複数のハッシュが同一の最下位ハッシュを有するとき、あるいは２つのハッシュエントリが異なるデータクラスタを指し示すときには、使用されていないハッシュレコードのリンクされたリストが使用される。いずれの場合においても、使用されていないハッシュレコードは、リストから取られ、ｐＮｅｘｔＨａｓｈポインタを介してリンクされる。
ハッシュマネージャは、ハッシュテーブルに追加されたエントリを整頓し、ディスクの上の同一のクラスタを結合する。新しいハッシュレコードがハッシュテーブルに追加されると、メッセージがハッシュマネージャに通知される。これは、ハッシュマネージャによって自動的に行われる。バックグラウンド活動として、ハッシュマネージャはキューの上のエントリを処理する。ハッシュマネージャは、完全な（ｆｕｌｌ）ハッシュ値が既存のハッシュレコードと一致するかどうかを知るために、完全なハッシュ値を比較する。そうする場合には、ハッシュマネージャは、完成した（ｃｏｍｐｌｅｔｅ）クラスタデータも比較する。クラスタが一致する場合には、新しいハッシュレコードは使用されていないキューに捨て戻され得、ハッシュレコードカウントは増加させられ、重複するクラスタはクラスタの使用されていないキューに戻される。ハッシュマネージャは、レコードを結合するときに、スナップショットビットを前に伝播させるように注意しなければならない。
クラスタアクセステーブル（ＣＡＴ）は、間接的なポインタを含む。ポインタは、ゾーンの中のデータクラスタ（０が最初のデータクラスタである）を指し示す。一つのＣＡＴエントリは、単一のデータクラスタ（暫定的にサイズが４ＫＢ）を参照する。多くの反復データがあるときには、ディスク使用要件を低減するために、ＣＡＴが（ハッシングとともに）使用される。単一のＣＡＴは、格納の隣接ブロックをつねに表す。ＣＡＴは、非データゾーンの中に含まれる。それぞれのＣＡＴエントリは４８ビットである。以下の表は、それぞれのエントリがどのようにレイアウトされるかを示す（それぞれのデータゾーンが１ＧＢのデータを含むと想定する）：
Figure 2009536414
 ＣＡＴは６４ビットの中に収まることが望ましいが、これは必要不可欠ではない。２ＴＢアレイのためのＣＡＴテーブルは、現在、サイズが４ＧＢまでである。それぞれのＣＡＴエントリは、データとゾーンの数とを含むゾーンを指し示す。
図１４は、ゾーンにおけるデータクラスタにアクセスするために、ＣＡＴがどのように使用されるかを示す。冗長データは、ＣＡＴにおける２つ以上のエントリによって参照される。２つの論理クラスタが同じデータを含むので、それらのＣＡＴエントリは、同じ物理的クラスタに指し示される。
ハッシュキーエントリは、クラスタ全体の１６０ビットＳＨＡ１ハッシュ値の１６ビット抽出を含む。このエントリは、書き込み操作の間にハッシュテーブルをアップデートするために使用される。
１６ＴＢのデータを参照するＣＡＴにおけるそれぞれのエントリにおいて、十分なビットがある。しかし、すべてのデータクラスタが互いに異なる場合には（コンテンツに関して）、２ＴＢのデータを参照するために、ちょうど３ゾーン相当以上のＣＡＴエントリが必要とされる（それぞれのゾーンは、サイズが１ＧＢであり、したがって１ＧＢサイズのＣＡＴエントリを格納し得る。６バイトＣＡＴエントリを想定すると、１７８９５６９７０ＣＡＴエントリ／ゾーンであり、すなわち、それぞれのクラスタが４Ｋである場合には、テーブルは約６８２ＧＢ／ゾーンを参照する）。
ホスト論理セクタ変換テーブルは、ホスト論理セクタアドレスをゾーン番号に変換するために使用される。ホスト論理セクタアドレスに対応するＣＡＴの部分は、このゾーンに常駐する。それぞれのＣＡＴエントリは、４０９６バイトのクラスタサイズを表すことに留意されたい。これは８つの５１２バイトセクタである。以下は、ホスト論理セクタ変換テーブルの表現を示す：
Figure 2009536414
Figure 2009536414
 ゾーンは、ＣＡＴ全体を保持するように事前に割当てられ得る。代替的に、ＣＡＴに対してより多くのエントリが要求されるときには、ゾーンがＣＡＴに対して割当てられ得る。ＣＡＴは、２ＴＢ仮想ディスクをホストセクタアドレススペースにマッピングするので、ホストによるハードディスクのパーティショニングまたはフォーマッティングの間に、おそらくＣＡＴの大部分が参照される。このことを理由として、ゾーンは事前に割当てられ得る。
ＣＡＴは大きな１ＧＢ／ゾーンのテーブルである。使用されるクラスタのワーキングセットは、この大きなテーブルからのスパースセット（ｓｐａｒｓｅ ｓｅｔ）である。性能の理由のために、活動状態のエントリは、ディスクから（おそらく時間的に）つねに読み込むのではなく、プロセッサメモリにおいてキャッシュされ得る。キャッシュを配置するために、少なくとも２つのオプションがあり、ＣＡＴからの個々のエントリ、またはＣＡＴからの全体のクラスタである。
進行中の書き込みは、ＣＡＴキャッシュテーブルと結合されるので、すべての未処理の書き込みがキャッシュの中に留まることを保証する必要がある。したがって、キャッシュは、少なくとも、未処理の書き込みリクエストの最大数と同じくらい大きい必要がある。
キャッシュにおけるエントリは、クラスタサイズ（すなわち４Ｋ）である。クラスタの上で作動中の進行中の書き込みがあるかどうかを知る必要がある。この指示は、クラスタについてのキャッシュエントリにおけるフラグとして格納され得る。以下の表は、ＣＡＴキャッシュエントリのフォーマットを示す：
Figure 2009536414
 キャッシュエントリにおける進行中のフラグは、２つの意味を有する。第一に、書き込みが進行中であり、クラスタの上のいかなる書き込み（または追加の書き込み）も、書き込みが完了するまでは延期されなければならない、ということを示す。第二に、キャッシュにおけるこのエントリは、ビットが設定される間はフラッシュ（ｆｌｕｓｈ）されてはならない。このことは、部分的にはビットの状態を保護するためであり、このクラスタが現在使用されているという事実を反映させるためでもある。さらに、このことは、キャッシュのサイズが、少なくとも、未処理の書き込み操作の数と同じくらい大きくなければならないことを意味する。
進行中の書き込みのインジケータをクラスタについてのキャッシュエントリに格納することの一つの利点は、現在操作中であるという事実を反映し、別のテーブルを有することを不要にし、追加のハッシュベースのルックアップ、またはこのビットもチェックするためのテーブルウォーク（ｔａｂｌｅ ｗａｌｋ）を不要にすることである。キャッシュは、書き込み遅延（ｗｒｉｔｅ−ｄｅｌａｙｅｄ）キャッシュであり得る。より早く書き込ませることは有益であり得るが、書き込み操作が完了したときにキャッシュエントリをディスクに書き戻すのみでよい。ハッシュされ得る未処理の書き込みエントリの数を増加させるために、ハッシュ関数または他のメカニズムが使用され得る。
代替のアプローチは、ＣＡＴのクラスタ全体をキャッシュすることである（すなわちエントリのうちの４Ｋエントリ）。このことは、アクセスの良好な空間的局所性がある場合に、一般的に性能を改善し得る。ＣＡＴエントリは４８ビット幅なので、注意が払われる必要があり、キャッシュにおけるエントリの全体の数はない。以下の表は、クラスタされたＣＡＴキャッシュエントリの例を示す：
Figure 2009536414
 テーブルサイズは、４０９６＋９９６（４１９２バイト）であり得る。２５０エントリのキャッシュサイズを有する必要があると想定すると、キャッシュは約１ＭＢを占め得る。
論理ＣＡＴエントリアドレスの適切なマスキングによらずに、最初および最後のエントリが不完全であるかどうかを計算することは可能である。キャッシュするルックアップルーチンは、エントリのローディングの前にこれを行うべきであり、必要とされるＣＡＴクラスタをロードするべきである。
ホストがセクタ（またはクラスタ）読み出しリクエストを送信するときに、論理セクタアドレスを介して送信する。論理セクタアドレスは、ホストによって要求される実際のデータを含むゾーンにおけるクラスタのオフセットを獲得するために、ＣＡＴの中へのオフセットとして使用される。その結果は、ゾーン番号と、そのゾーンの中へのオフセットとである。その情報は、レイヤ２（Ｌａｙｅｒ ２）ソフトウェアに渡され、レイヤ２ソフトウェアは、次に、ドライブからロークラスタ（ｒａｗ ｃｌｕｓｔｅｒ）を抽出する。
ホストによっていまだかつて書き込まれていないクラスタを処理するために、すべてのＣＡＴエントリが、オールゼロを含む「デフォルト」クラスタを指し示すように初期化される。
ジャーナルマネージャは、二層の書き込み実行記録システムである。システムの目的は、書き込みリクエストがホストから受け入れられ得ることを確実にし、データが保全性を保証しながら受け入れられたことをホストに迅速に示し返すことである。さらに、システムは、任意のディスク書き込みの間のシステムリセットの場合において、ブロックレベルデータまたはシステムメタデータ（たとえばＣＡＴおよびハッシュテーブルエントリ）の破損または損失がないことを保証する必要がある。
Ｊ１ジャーナルマネージャは、すべての書き込みリクエストをホストからディスクへ可能な限り迅速にキャッシュする。ひとたび書き込みが首尾良く完了すると（すなわちデータがアレイによって受け入れられると）、ホストは、操作が完了したことを示すために信号を送られ得る。ジャーナルエントリは、故障から回復するときに、書き込みリクエストの回復を可能にする。ジャーナルレコードは、ディスクに書き込まれるべきデータと、書き込みトランザクションに関連するメタデータとからなる。
ディスク読み出し／書き込みを低減するために、書き込みに関連するデータが書き込まれて、クラスタを解放する。このことは、データを自動的にミラリングする。使用されていないクラスタは、使用されていないクラスタのリストから取られる。ひとたびデータが書き込まれると、使用されていないクラスタのリストは、ディスクに書き戻されなければならない。
ジャーナルレコードは、ミラリングされていないゾーンの上のジャーナルキューに対して書き込まれる。それぞれのレコードは、サイズにおいてセクタであり、ジャーナル書き込みの間の故障が以前のジャーナルエントリを破損し得るリスクを低減するために、セクタ境界に位置合わせされる。ジャーナルエントリは、レコードの終端において一意の増加するシーケンスカウントを含むので、キューの終端は容易に識別され得る。
ジャーナル書き込み操作は、スレッドを処理するホストキューの中で同期的に生じる。ジャーナル書き込みは、ディスクに書き込まれるときに順序づけられなければならないので、任意の時間において一つのスレッドのみがジャーナルに書き込み得る。Ｊ１テーブルにおけるジャーナルエントリのアドレスは、一意の識別子として使用され得るので、Ｊ１ジャーナルエントリは、Ｊ２ジャーナルにおけるエントリと相互に関連させられ得る。ひとたびジャーナルエントリが書き込まれると、トランザクション完了通知が、ホスト完了キューに対して通知される。今や書き込み操作が実行され得る。ジャーナル書き込みが完了する前の、クラスタに対するいかなる次の読み出しも、遅延されることを保証することが重要である。
以下の表は、Ｊ２ジャーナルレコードのフォーマットを示す：
Figure 2009536414
 それぞれのジャーナルレコードは、セクタ境界に位置合わせされる。ジャーナルレコードは、ゾーン／オフセット／サイズの組のアレイを含み得る。
図１５は、本発明の例示的な実施形態に従ったジャーナルテーブルアップデートを示す。具体的には、ホスト書き込みリクエストが受信されるときに、ジャーナルテーブルがアップデートされ、一つ以上のクラスタが割当てられ、データがクラスタに書き込まれる。
ホストジャーナルリクエストが処理される。これらによって、クラスタは書き込まれ、ディスクにシャドウバック（ｓｈａｄｏｗ ｂａｃｋ）されなければならないメタデータ構造（たとえばＣＡＴテーブル）へのアップデートももたらされる。たとえシステムリセットが生じても、これらのメタデータ構造がディスクに正しく書き戻されることを保証することが重要である。低レベルディスクＩ／Ｏ書き込み（Ｊ２）ジャーナルは、このために使用される。
ホストインタフェースジャーナルエントリを処理するために、メタデータ構造の適切な操作が決定されるべきである。メモリにおいて変化が生じるべきであり、種々のディスクブロックへの変化のレコードが生成されるべきである。このレコードは、ディスクの上でなされるべき実際の変化を含む。アップデートされるそれぞれのデータ構造は、Ｊ２ジャーナルマネージャを用いて登録される。このレコードは、ディスクベースのジャーナルに記録されるべきであり、識別子を用いてスタンプされるべきである。レコードがＪ１ジャーナルエントリと結びつけられる場合には、識別子がリンクされるべきである。ひとたびレコードが格納されると、ディスクへの変更がなされ得る（あるいはバックグラウンドタスクを介して行われ得る）。
Ｊ２ジャーナルは、論理的にレイヤ３において存在する。これは、ゾーンマネージャを介した書き込みを含み得るメタデータアップデートを実行記録（ｊｏｕｒｎａｌ）するために使用される。ジャーナルエントリの再生が生じるときには、ゾーンマネージャの方法を使用する。ジャーナルそのものは、特殊な領域に格納され得る。ジャーナルエントリの短い寿命を考慮すれば、ジャーナルエントリはミラリングされない。
特に構造へのアップデートがアトミックである場合には、すべてのメタデータがＪ２ジャーナルを経る必要はない。領域マネージャ構造は、Ｊ２ジャーナルを使用し得ない。たとえばバックグラウンドスレッドをチェックする保全性を用いて、領域マネージャビットマップにおける不整合を検出することが可能であり得る。
Ｊ２ジャーナルのための単純なアプローチは、単一のレコードを含むことである。レコードがディスクに対してコミットされるとすぐに、レコードは再生され、ディスクの上の構造をアップデートする。複数のＪ２レコードを有することと、ディスクの上のレコードのアップデートをコミットするバックグラウンドタスクを有することとは可能である。この場合、ジャーナルと、種々のデータ構造に関連する任意のキャッシングアルゴリズムとの間の相互作用に、周到な注意が払われる必要がある。
最初のアプローチは、ジャーナルエントリがディスクに対してコミットされるとすぐに、ジャーナルエントリを実行する。原則としては、Ｊ２の複数の同時ユーザがあり得るが、Ｊ２ジャーナルは一度に一人のユーザに対してロックされ得る。たとえこの場合においても、ジャーナルエントリは、実行依頼されたらすぐにコミットされるべきである。
任意のより高いレベルのジャーナル活動が生じる前に、メタデータ構造が修復されることを保証することが重要である。システム再起動の際に、Ｊ２ジャーナルが分析され、任意のレコードが再生される。ジャーナルエントリがＪ１ジャーナルエントリと相互に関連させられる場合には、Ｊ１エントリは、完成したものとしてマークされ、除去され得る。ひとたびすべてのＪ２ジャーナルエントリが完成すると、メタデータは信頼性のある状態になり、任意の残りのＪ１ジャーナルエントリが処理され得る。
Ｊ２ジャーナルレコードは、以下の情報を含む。
・操作の数
・各操作は以下を含む：
−Ｊ１レコードインジケータ
−書き込むべきゾーン／データオフセット
−書き込むべきデータ
−データのサイズ
−データクラスタの中へのオフセット
・ジャーナルレコード識別子
・終端マーカ
このスキームは、たとえばＪ２ジャーナルエントリの終端を識別するためにシーケンス番号を用いて、Ｊ２ジャーナルエントリをセクタ境界に置いて、Ｊ１ジャーナルスキームと同様に作動し得る。
Ｊ１データポインタインジケータが設定される場合には、この特定の操作が、Ｊ１ジャーナルレコードを指し示し得る。ホストによって供給される書き込みデータは、われわれの（ｏｕｒ）ジャーナルエントリにコピーされる必要はない。ジャーナルレコードにおける操作の最大数は十分に理解されると予想されるので、操作は固定サイズとして定義されることができるべきである。
低レベル書き込み操作の間におけるセクタの破損（たとえば電力の損失によるもの）からの回復を可能にするために、Ｊ２ジャーナルは、書き込まれたセクタ全体を格納し得るので、必要な場合にはこの情報からセクタが再書き込みされ得る。代替的にまたは追加的に、書き込み操作の再生が必要とされるかどうかを決定するために、それぞれの変更されたセクタについて計算されたＣＲＣは、Ｊ２レコードに格納され得、ディスクの上のセクタから（たとえばゾーンマネージャによって）計算されたＣＲＣと比較され得る。
異なるジャーナルが異なる位置に格納され得るので、ジャーナルレコードを補助格納デバイスに書き込むために提供されるインタフェースレイヤがある。位置は非揮発性であるべきである。２つの候補は、ハードディスクおよびＮＶＲＡＭである。Ｊ１がハードディスクに格納される場合には、Ｊ１ジャーナルのミラリングされないゾーンに格納される。Ｊ１ジャーナルは、ＮＶＲＡＭに格納する候補である。Ｊ２ジャーナルは、特殊な領域に格納され得るが、ディスクの上に格納されるべきである（すなわち、短い寿命を有するので冗長ではない）。Ｊ２ジャーナルをディスクの上に格納する利点は、内部データ構造のアップデートの間にシステムリセットがある場合に、データ構造が一貫性のある状態に戻され得ることである（たとえユニットが長時間にわたって電源を入れられないままにされるとしても）。
ゾーンマネージャ（ＺＭ）は、より高いレベルのソフトウェアによって必要とされるゾーンを割当てる。ＺＭへのリクエストは以下を含む：
ａ．ゾーンを割当てる
ｂ．ゾーンを再割当て／解放する
ｃ．Ｌ１に対してデータ読み出し／書き込みパススルーを制御する（？）
ｄ．ゾーンにおけるクラスタの読み出し／書き込みをする（クラスタのオフセットとゾーン番号とを考慮して）
ＺＭは、冗長メカニズムを管理し（ドライブの数およびその相対的サイズの関数として）、ミラリング、ストライピング、およびデータの読み出し／書き込みのための他の冗長スキームを処理する。
ＺＭは、ゾーンを割当てる必要があるときには、２つ以上のセットの領域の割当てを要求する。たとえば、ゾーンは１ＧＢのデータに対して割当てられ得る。このゾーンを構成する領域は、冗長データを含む１ＧＢのデータを含むことができる。ミラリングメカニズムのために、ゾーンは、それぞれ１ＧＢの２セットの領域からなる。別の例として、３ディスクストライピングメカニズムは、それぞれ１／２ＧＢの３セットの領域を利用する。
ＺＭは、ゾーンを構成する領域の各セットの位置（ドライブ番号および開始領域番号）を見出すために、ＺＲ変換テーブル（６）を使用する。１／１２ＧＢの領域サイズを想定すると、最大２４領域が必要とされる。２４領域は２×１ＧＢゾーンを構成する。したがって、ＺＲ変換テーブルは、ドライブ／領域データを提供する２４列を含む。
ＺＭは一般的に以下のように働く：
ａ．ＳＤＭ（単一ドライブミラリング）の場合には、２４列が使用される。ドライブ番号はすべての列において同じである。それぞれのエントリは、ゾーンを構成する物理的ドライブの上の物理的領域に対応する。最初の１２エントリは、データの一つのコピーを含む領域を指し示す。最後の１２エントリは、データの第２のコピーを含む領域を指し示す。
ｂ．ＤＤＭ（二重ドライブミラリング）の場合は、最初の１２エントリのドライブ番号が最後の１２エントリのドライブ番号とは異なることを除いて、ＳＤＭと同じである。
ｃ．ストライピングの場合には、３つ以上の列が使用され得る。たとえば、ストライピングが３つのドライブにわたって使用される場合には、６つの領域が３つの異なるドライブから必要とされ得（すなわち１８エントリが使用される）、最初の６エントリが同じドライブ番号を含み、次の６エントリが別のドライブ番号を含み、それに続く６エントリが第３のドライブ番号を含み、未使用のエントリはゼロにされる。
以下は、ゾーン領域変換テーブルの表現を示す：
Figure 2009536414
 読み出し／書き込みリクエストが入ってくるときに、ＺＭは、ゾーン番号およびそのゾーンの中へのオフセットを提供される。ＺＭは、そのゾーンについての冗長メカニズムを見出すためにＺＲ変換テーブルを調べ、どのドライブ／領域が読み出し／書き込みされなければならないセクタを含むかを計算するためにオフセットを使用する。ドライブ／領域情報は、次に、実際の読み出し／書き込みを行うＬ１レイヤに提供される。使用（Ｕｓａｇｅ）の列における追加の可能なエントリは、「使用されていない」である。「使用されていない」は、ゾーンが定義されているものの、現在は使用中ではないことを示す。
クラスタマネージャは、データゾーンのセットの中のクラスタを割当ておよび再割当てする。
レイアウトマネージャは、ゾーンの領域に対するゾーンのランタイム再レイアウトを提供する。このことは、ディスクの挿入／取り外しまたは故障の結果として生じ得る。
レイヤ１（Ｌ１）ソフトウェアは、物理的なドライブおよび物理的なセクタについて知っている。なかでも、Ｌ１ソフトウェアは、ゾーンマネージャによる使用のために、物理的ドライブから領域を割当てる。この例示的な実施形態において、それぞれの領域は、４ドライブアレイシステムについて１／１２ＧＢ（すなわち１７４７６３セクタ）のサイズを有する。より大きなドライブ最大数（８、１２または１６）を有するシステムは、異なる領域サイズを有する。
ＳＤ３（３つのドライブにわたるストライピング；パリティがプラスされた２データ）を用いて１ＧＢのデータを含むゾーンを作成するためには、３つのドライブにおいてそれぞれ６つの領域を使用することになる（６×１／１２＝ドライブあたり１／２ＧＢ）。
この領域スキームの使用は、ゾーンが、たとえばミラリングからストライピングへと、移動または再構成されるときに、ディスクスペースのより良好な利用を提供することを可能にする。Ｌ１ソフトウェアは、領域のビットマップを用いて、物理的ドライブの上の利用可能なスペースを追跡する。それぞれのドライブは一つのビットマップを有する。それぞれの領域は、領域が使用されていないか、使用されているか、または不良であるかを追跡するために、ビットマップにおける２ビットによって表される。Ｌ２ソフトウェア（ＺＭ）は、ゾーンを作成する必要があるときには、Ｌ１レイヤから領域のセットを得る。ゾーンを構成する領域は、ディスクの中で隣接しない。
Ｌ１へのリクエストは以下を含む：
ａ．データの読み出し／書き込みをする（領域のグループの中のクラスタに対して）
ｂ．読み出し／書き込みを制御する（テーブル、データ構造、ＤＩＣなど）
ｃ．領域に対して物理的スペースを割当てる（１ドライブの中の実際の物理的セクタ）
ｄ．領域を再割当てする
ｅ．物理的ドライブの中の物理的クラスタに対してロー（Ｒａｗ）読み出し／書き込みをする
ｆ．領域から領域へデータをコピーする
ｇ．領域を不良としてマークする
使用されていない領域ビットマップは大きくあり得、したがって、使用されていないエントリを見つけるための検索（最悪の場合、使用されていないエントリがない）は、遅くあり得る。性能を改善するために、ビットマップの一部がメモリの中に事前にロードされ得、使用されていない領域のリンクされたリストがメモリに格納され得る。活動状態のそれぞれのゾーンについてリストがある。リストの最低点に達した場合には、より多くの使用されていないエントリが、バックグランド活動としてディスクから読み出され得る。
ディスクマネージャ（Ｄｉｓｋ Ｍａｎａｇｅｒ）は、レイヤ０において作動する。以下の表に示されるように、２つのサブレイヤがあり、具体的には、抽象化レイヤと、物理的な格納アレイと通信するデバイスドライバとである。
Figure 2009536414
 デバイスドライバ（Ｄｅｖｉｃｅ Ｄｒｉｖｅｒ）レイヤはまた、いくつかのレイヤを含む。たとえば、ＵＳＢドライブを使用する格納アレイのために、ＵＳＢ移送レイヤの一番上にＡＴＡまたはＳＣＳＩスタックがある。抽象化レイヤは、格納アレイにおいて使用されるドライブの種類から独立した、基本的な読み出し／書き込み機能を提供する。
一つ以上のディスクアクセスキューが、ディスクアクセスリクエストをキューに入れるために使用され得る。ディスクアクセスレートは、われわれのシステムにおける重要な性能ボトルネックの一つである。われわれは、全般的なシステム待ち時間を低減し、性能を改善するために、ディスクインタフェースがつねに可能な限りビジーに保たれることを確実にしたい。ディスクインタフェースへのリクエストは、非同期インタフェースを有するべきであり、ディスク操作が終了したときには、コールバックハンドラが操作を完了する。一つのディスクリクエストの完了は、キューの上の次のリクエストを自動的に開始する。ドライブごとに一つのキュー、またはすべてのドライブに一つのキューがあり得る。
レイヤ１は、ドライブを論理ドライブ番号として参照する。レイヤ０は、論理ドライブ番号を、物理的ドライブ参照に変換する（たとえば、オープン（）コールの結果として、／ｄｅｖ／ｓｄａまたはファイルデバイス番号）。柔軟性のために（ＵＳＢを介した拡張）、それぞれの論理ドライブについてキューがあるべきである。
以下は、一部の例示的なオブジェクト定義およびデータフローである：
Figure 2009536414
Figure 2009536414
Figure 2009536414
 以下は、物理的ディスクレイアウトの説明である。上述のように、それぞれのディスクは固定サイズの領域に分割される。この例示的な実施形態において、それぞれの領域は、４ドライブアレイシステムについて、１／１２ＧＢ（すなわち１７４７６３セクタ）のサイズを有する。より大きなドライブ最大数（８、１２または１６）を有するシステムは、異なる領域サイズを有する。最初に、領域番号０および１は、領域マネージャによる使用のために予約され、割当てのためには使用されない。領域番号１は、領域番号０のミラリングである。所定のハードディスクについて領域マネージャによって使用されるすべての内部データは、このハードディスクの領域番号０および１に格納される。この情報は、他のドライブと重複（またはミラリング）されない。領域０または１のいずれかにエラーがある場合には、データを保持するために他の領域が割当てられ得る。ディスク情報構造（Ｄｉｓｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｔｒｕｃｔｕｒｅ）は、これらの領域を指し示す。
それぞれのディスクは、ディスクと、ディスクが属するディスクセットと、ディスクについてのレイアウト情報とを識別する、ＤＩＳを含む。ハードディスクの上の第１のセクタは予約されている。ＤＩＳは、第１のセクタの後の、第１の不良でないクラスタに格納される。ＤＩＳは、１ＫＢ相当のデータの中に含まれる。ＤＩＳの２つのコピーがある。ＤＩＳのコピーは、ＤＩＳが属するディスクの上に格納される。さらに、システムにおけるすべてのディスクは、システムにおけるディスクのすべてのＤＩＳのコピーを含む。以下の表は、ＤＩＳフォーマットを示す。
Figure 2009536414
Figure 2009536414
Figure 2009536414
 領域マネージャは、領域情報構造における内部データを格納する。以下の表は、領域情報構造フォーマットを示す。
Figure 2009536414
 ゾーン情報構造は、ゾーンマネージャがどこにゾーンテーブルを見出し得るかに関する情報を提供する。以下は、ゾーン情報構造フォーマットを示す。
Figure 2009536414
Figure 2009536414
 高レベル情報ゾーンは、ハイレベルマネージャによって使用されるゾーンテーブルおよび他のテーブルを含む。これらは、ミラリングを使用して保護される。
以下の表は、ゾーンテーブルノードフォーマットを示す。
Figure 2009536414
Figure 2009536414
 以下は、ゾーン情報のレイアウトの説明である。ゾーンテーブルノード（Ｚｏｎｅｓ Ｔａｂｌｅ Ｎｏｄｅｓ）のリンクされたリストは、以下の方法でＺＩＳの後に置かれる。
Figure 2009536414
 この情報は、ゾーンテーブル領域（Ｚｏｎｅｓ Ｔａｂｌｅ Ｒｅｇｉｏｎ）に格納される。
図１６は、本発明の例示的な実施形態に従ったドライブレイアウトを示す。最初の２つの領域は、互いのコピーである。第３の（オプションの）ゾーンテーブル領域は、ゾーンテーブルを含む。一つ以上のドライブを有するシステムにおいて、ドライブのうちの２つのみがＺＴＲを含む。一つのドライブのみを有するシステムにおいて、２つの領域は、ＺＴＲの２つの（ミラリングされた）コピーを保持するために使用される。ＤＩＳは、ＲＩＳおよびＺＩＳの位置に関する情報を含む。ＲＩＳの第１のコピーは、領域０の中にある必要はないことに留意されたい（たとえば、領域０が不良セクタを含む場合には、異なる領域に位置し得る）。
ゾーンマネージャは、システム起動時にゾーンテーブルをロードする必要がある。それを行うために、ゾーンマネージャは、領域番号およびオフセットをＤＩＳから抽出する。これは、ＺＩＳの開始を指し示す。
特定モジュール（たとえばＣＡＴマネージャ）は、制御構造およびデータテーブルをゾーンに格納する。レイヤ３以上におけるモジュールについてのすべての制御構造は、ゾーン０に格納される構造から参照される。このことは、たとえば、実際のＣＡＴ（クラスタ割当てテーブル）の位置が、ゾーン０に格納されたデータ構造から参照されることを意味する。
以下の表は、ゾーン０情報テーブルフォーマットを示す。
Figure 2009536414
 ＣＡＴのリンクされたリストは、ＣＡＴを含むゾーンを記述するノードのリンクされたリストである。以下の表は、ＣＡＴのリンクされたリストのノードフォーマットを示す。
Figure 2009536414
Figure 2009536414
 ハッシュテーブルのリンクされたリストは、ハッシュテーブルを保持するゾーンを記述するノードのリンクされたリストである。以下の表は、ハッシュテーブルのリンクされたリストのノードフォーマットを示す。
Figure 2009536414
 図１７は、本発明の例示的な実施形態に従った、ゾーン０のレイアウトと、他のゾーンがどのように参照されるかとを示す。
上述のように、冗長セットは、データのセットに対して冗長性を提供するセクタ／クラスタのセットである。領域をバックアップすることは、一つの領域のコンテンツを別の領域にコピーすることを含む。
データ読み出しエラーの場合には、より低いレベルのソフトウェア（ディスクマネージャまたはデバイスドライバ）は、最初の失敗した試みの後に、追加の２回にわたって読み出しリクエストを再試行する。失敗状態は、ゾーンマネージャに返される。次に、ゾーンマネージャは、冗長クラスタから（読み出しによって）リクエストされるデータを、ディスクアレイにおいて再構築することを試みる。冗長データは、ミラリングされたクラスタ（ＳＤＭ、ＤＤＭについて）、またはパリティを含むクラスタのセット（ストライピングされたインプリメンテーションについて）のいずれかであり得る。次に、再構築されたデータは、ホストに返される。ＺＭがデータを再構築することができない場合には、読み出しエラーがホストに返される。ゾーンマネージャは、エラー通知パケット（Ｅｒｒｏｒ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐａｃｋｅｔ）をエラーマネージャ（Ｅｒｒｏｒ Ｍａｎａｇｅｒ）に送信する。図１８は、本発明の例示的な実施形態に従った読み出しエラー処理を示す。
データ書き込みエラーの場合には、より低いレベルのソフトウェア（ディスクマネージャまたはデバイスドライバ）は、最初の失敗した試みの後に、追加の２回にわたって書き込みリクエストを再試行する。失敗状態はゾーンマネージャに返される。ゾーンマネージャは、エラー通知パケットをエラーマネージャに送信する。
このレベルにおいてデータ書き込みが実行されるときに、冗長情報もディスクに書き込まれる。結果として、一つのみのクラスタが書き込みエラーを有する限りは、次の読み出しはデータを再構築することができる。複数のディスクエラーがあり、冗長情報が読み出しまたは書き込みされ得ない場合には、少なくとも二つの可能なアプローチがある。
ａ．書き込みエラー状態をホストに戻す。冗長セットに関連するすべての領域を、不良セクタを含まない、新たに割当てられた領域に、バックアップする。
ｂ．書き込みを遅らせる。冗長セットに関連するすべての領域を、不良セクタを含まない、新たに割当てられた領域に、バックアップする。次に、新たに割当てられた領域における適切なクラスタに書き込みを行う（すべての冗長部分、たとえばパリティなどとともに）。別個の書き込みキューは、遅らせられた書き込みを含むように使用され得る。
アプローチ（ａ）は、問題がある。なぜなら、ジャーナルの成功した書き込みの結果として、書き込み状態がすでにホストに送信されている可能性があるので、ホストはエラーがあったことを知り得ないからである。代替策は、読み出しの失敗を報告するが、書き込みを可能にすることである。ＣＡＴにおけるビットは、特定のＬＢＡが不良読み出しを戻すべきであることを追跡するために使用され得る。
図１９は、本発明の例示的な実施形態に従ったエラー処理を示す。
エラーマネージャ（ＥＭ）は、クラスタが本当に不良であるかどうかを知るためにクラスタをチェックする。そうである場合には、領域全体が不良であると考えられる。領域のコンテンツは、同じディスクの上の新たに割当てられた領域にコピーされる。次に、現在の領域はＢＡＤ（不良）とマークされる。領域にコピーする間に、エラーマネージャは、不良セクタに遭遇したときに、必要とあればデータを再構築する。図２０は、本発明の例示的な実施形態に従った、エラーマネジャーによる不良領域のバックアップを示す論理フロー図である。
データ読み出しエラーがあり、エラーマネージャが所定のクラスタについてデータを再構築できない場合には（たとえば、冗長セットにわたる読み出しエラーの結果として）、再構築され得ないデータの代わりに、ゼロが使用される。この場合には、不良セクタを含む他のセクタ（冗長セットからの）もまた、バックアップされなければならない。この場合もやはり、再構築され得ないデータの代わりにゼロが使用される。
ひとたび冗長セットのコピーが行われると、ＥＭはゾーンのこの部分に対応するクラスタへのアクセスを使用不能にする。次にＥＭは、新たに割当てられた領域を指し示すように、ゾーンテーブルをアップデートする。次に、クラスタへのアクセスが再び使用可能にされる。
この例示的な実施形態は、８つのスナップショットをサポートするように設計される（これは、ハッシュ／クラスタのエントリが特定のスナップショットインスタンスによって使用されるかどうかを示す１バイトの使用を可能にする）。スナップショットに含まれる２つのテーブルがある。
１．スナップショットあたりのＣＡＴテーブルは、論理セクタアドレスと、そのＬＡＳについてのデータを含むディスクの上のクラスタとの関係を捉えるように、存在する必要がある。究極的には、スナップショットあたりのＣＡＴは、スナップショットが取られた瞬間におけるＣＡＴのコピーでなければならない。
２．ハッシュ値とデータクラスタとの間のマッピングをするシステムハッシュテーブル。ハッシュ関数は、どのスナップショットが使用されているかに関わらず同じ結果を返し、結果としてすべてのスナップショットにわたって共通である。結果として、このテーブルは、一意にクラスタが任意のスナップショットによって使用されているかどうかを理解しなければならない。ハッシュエントリを使用するスナップショットがない限りは、ハッシュクラスタエントリは、解放され得ないか、または新しいデータと置き換えられ得ない。
現在のものでありなおかつ追加されつつあるスナップショットが、つねにある。ハッシュエントリが作成またはアップデートされるときに、現在のスナップショット番号をそのハッシュエントリに適用する必要がある。スナップショットが作られるときに、現在のスナップショット番号が増加させられる。
任意のスナップショットによってもはや必要とされないクラスタ／ハッシュのエントリは、ハッシュテーブルをざっと読むこと（ｗａｌｋｉｎｇ ｔｈｒｏｕｇｈ）によって解放され、リタイヤ（ｒｅｔｉｒｅ）したスナップショットビットセットで任意のハッシュエントリを見出し、そのビットをクリアする。スナップショットバイトがゼロである場合には、ハッシュエントリはテーブルから除去され得、クラスタは解放され得る。
ハッシュツリーに追加されつつある任意の新しいエントリとの衝突を防ぐために（新しいスナップショット番号は、リタイヤするスナップショット番号と同じであるから）、７つのスナップショットのみが取られることが可能にされ得、最後の（８番目の）スナップショットはリタイヤするスナップショットである。ハッシュテーブルは、バックグラウンド活動として調べられ（ｗａｌｋｅｄ）得る。
スナップショットを作成するために、主たるＣＡＴがアップデートされているときはいつでも、第２のＣＡＴゾーンが書き込まれ得る。これらのアップデートはキューに入れられ得、シャドー（ｓｈａｄｏｗ）ＣＡＴは別のタスクとしてアップデートされ得る。スナップショットするために、シャドーＣＡＴはスナップショットＣＡＴになる。
ひとたびスナップショットが行われると、新しいスナップショットＣＡＴになる新しいゾーンにこのスナップショットテーブルをコピーするために、バックグランドプロセスが開始され得る。ＣＡＴのコピーが完了するまではシャドーＣＡＴキューが処理されないように、キューが使用され得る。万一、シャドーＣＡＴをアップデートする前に故障が生じた場合には（この場合にはキューにおけるエントリが失われ得る）、アレイがオンラインにされる前に、主たるＣＡＴテーブルからの再シャドーが実行され得る。
代替的に、スナップショットが必要とされるときに、最初のＣＡＴコピーがプラスされた「デルタ」の収集がスナップショットを構成し得る。次に、バックグランドタスクが、この情報から完全なスナップショットＣＡＴを再構成し得る。このことは、スナップショットを行うためにダウンタイムをほとんどあるいはまったく必要とし得ない。一方、デルタの別のセットが、次のスナップショットのために収集され得る。
（ファイルシステム認識格納システム）
上記のように、本発明の実施形態は、ホストファイルシステムの格納方法を決定し、ホストファイルシステムの格納方法に基づいて物理的格納を管理するために、ホストファイルシステムデータ構造（すなわち、メタデータ）を分析する。便宜上、この機能性は、以降で「スカベンジャ（ｓｃａｖｅｎｇｅｒ）」と呼んでもよい。以降で「モニタ」と呼んでもよい同様の機能が含まれ、格納方法を監視することが可能であるが、必ずしも物理的格納を管理するわけではない。スカベンジャおよびモニタの両方について下記で論じる。
図２７は、本発明の例示的実施形態に従ったコンピュータシステム２７００の概念ブロック図である。コンピュータシステム２７００は、とりわけ、ホストコンピュータ２７１０および格納システム２７２０を含む。ホストコンピュータ２７１０は、とりわけ、ホストオペレーティングシステム（ＯＳ）２７１２およびホストファイルシステム２７１１を含む。格納システム２７２０は、とりわけ、ファイルシステム認識格納制御装置２７２１および格納２７２２（例えば、１つ以上のデータ入力されたディスクドライブを含むアレイ）を含む。格納２７２２は、とりわけ、格納制御装置データ構造２７２６、ホストＯＳデータ構造２７２５、ホストファイルシステムデータ構造２７２３、およびユーザデータ２７２４を格納するために使用される。ファイルシステム認識格納制御装置２７２１は、ＯＳパーティションの参照を含むパーティションテーブル（格納制御装置データ構造２７２６とホストＯＳデータ構造２７２５との間の破線によって表される）等の、様々な種類の情報を格納制御装置データ構造２７２６に格納する（ファイルシステム認識格納制御装置２７２１と格納制御装置データ構造２７２６との間の破線によって表される）。ホストＯＳ２７１２は、様々な種類の情報をホストＯＳデータ構造２７２５に格納し（ホストＯＳ２７１２とホストＯＳデータ構造２７２５との間の破線によって表される）、典型的にホストファイルシステムデータ構造２７２３へのポインタ／参照を含む（ホストＯＳデータ構造２７２５とホストファイルシステムデータ構造２７２３との間の破線によって表される）。ホストファイルシステム２７１１は、情報をユーザデータ２７２４に関するホストファイルシステムデータ構造２７２３に格納する（メタデータと呼ばれ、ホストファイルシステム２７１１とホストファイルシステムデータ構造２７２３との間の破線によって表される）。ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム２７１１からの格納リクエストに対処し（ホストファイルシステム２７１１とファイルシステム認識格納制御装置２７２１との間の実線によって表される）、ホストファイルシステム２７１１の格納方法を決定するためにホストＯＳデータ構造２７２５およびホストファイルシステムデータ構造２７２３を利用し（ファイルシステム認識格納制御装置２７２１とホストＯＳデータ構造２７２５との間の破線、およびファイルシステム認識格納制御装置２７２１とホストファイルシステムデータ構造２７２３との間の破線によって表される）、ホストファイルシステム２７１１の格納方法に基づいてユーザデータ２７２４の格納を管理する（ファイルシステム認識格納制御装置２７２１とユーザデータ２７２４との間の破線によって表される）。具体的には、ファイルシステム認識格納制御装置２７２１は、下記のようにスカベンジャおよび／またはモニタを実装してもよい。
ファイルシステム認識格納制御装置２７２１は、概して、ホストファイルシステムデータ構造の場所を突き止めて分析するために、ホストファイルシステムの内部の働きを十分に理解する必要がある。もちろん、異なるファイルシステムには異なるデータ構造があり、異なる方法で動作し、これらの差異は、設計／実装の選択に影響し得る。一般的に言えば、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステムデータ構造２７２３の場所を格納２７２２中で突き止め、ホストファイルシステムデータ構造２７２３を分析して、ホストファイルシステム２７１１の格納方法を決定する。次いで、ファイルシステム認識格納制御装置２７２１は、そのような格納方法に基づいてユーザデータ格納２７２４を管理することが可能である。
図２８は、本発明の例示的実施形態に従った、ファイルシステム認識格納制御装置２７２１の高レベル論理フロー図である。ブロック２８０２において、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステムデータ構造２７２３の場所を格納２７２２中で突き止める。ブロック２８０４において、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステムデータ構造を分析して、ホストファイルシステム格納方法を決定する。ブロック２８０６において、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム格納方法に基づいてユーザデータ格納を管理する。
図２９は、本発明の例示的実施形態に従った、ホストファイルシステムデータ構造２７２３の場所を突き止める論理フロー図である。ブロック２９０２において、ファイルシステム認識格納制御装置２７２１は、そのパーティションテーブルの場所を格納制御装置データ構造２７２６中で突き止める。ブロック２９０４において、ファイルシステム認識格納制御装置２７２１は、パーティションテーブルを解析して、ホストＯＳデータ構造２７２５を含むＯＳパーティションの場所を突き止める。ブロック２９０６において、ファイルシステム認識格納制御装置２７２１は、ＯＳパーティションを解析して、ホストＯＳ２７１２を特定し、ホストＯＳデータ構造２７２５の場所を突き止める。ブロック２９０８において、ファイルシステム認識格納制御装置２７２１は、ホストＯＳデータ構造２７２５を解析して、ホストファイルシステム２７１１を特定し、ホストファイルシステムデータ構造２７２３の場所を突き止める。
ひとたびファイルシステム認識格納制御装置２７２１がホストファイルシステムデータ構造２７２３の場所を突き止めると、それはデータ構造を分析して、ホストファイルシステム２７１１の格納方法を決定する。例えば、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム２７１１によってもはや使用されていない格納ブロックを特定するため、およびホストファイルシステム２７１１によって格納されたデータの種類を特定するため等に、ホストファイルシステムデータ構造２７２３を使用してもよい。次いで、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム２７１１によってもはや使用されていない格納スペースを動的に再利用し、および／またはデータ型に基づいてユーザデータ２７２４の格納を管理することが可能である（例えば、ほんの数例を挙げれば、アクセス頻度の高いデータを圧縮せず、かつ連続ブロックで保存してアクセスを促進し、アクセス頻度の低いデータを圧縮および／または不連続ブロックで保存して、データ型に基づいて異なる符号化スキームを適用する）。
図３０は、本発明の例示的実施形態に従った、未使用の格納スペースを再利用するための論理フロー図である。ブロック３００２において、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム２７１１によって使用されていないとしてマークされているブロックを特定する。ブロック３００４において、ファイルシステム認識格納制御装置２７２１は、ホストファイルシステム２７１１によって使用されないとしてマークされているが、ファイルシステム認識格納制御装置２７２１によって使用されるとマークされている、あらゆるブロックを特定する。ブロック３００６において、ファイルシステム認識格納制御装置２７２１は、ファイルシステム認識格納制御装置２７２１によって使用されるとしてマークされているが、ホストファイルシステム２７１１によってもはや使用されていない、あらゆるブロックを再利用し、再利用された格納スペースを追加格納に対して利用可能にする。
図３１は、本発明の例示的実施形態に従った、データ型に基づいてユーザデータ２７２４の格納を管理するための論理フロー図である。ブロック３１０２において、ファイルシステム認識格納制御装置２７２１は、特定のユーザデータ２７２４と関連するデータ型を特定する。ブロック３１０４において、ファイルシステム認識格納制御装置２７２１は、任意で、データ型に基づいて選択された格納レイアウトを使用して、特定のユーザデータ２７２４を格納する。ブロック３１０６では、ファイルシステム認識格納制御装置２７２１は、任意で、データ型に基づいて選択された符号化スキーム（例えば、データ圧縮および／または暗号化）を使用して、特定のユーザデータ２７２４を符号化する。こうして、ファイルシステム認識格納制御装置２７２１は、データ型に合わせた異なるレイアウトおよび／または符号化スキームを使用して、異なる種類のデータを格納することが可能である。
スカベンジャの一例は、いわゆる「ガーベッジコレクタ（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｏｒ）」である。上記のように、ガーベッジコレクタは、ホストファイルシステムによってもはや使用されないクラスタを解放するために使用してもよい（例えば、ファイルが削除される時に）。一般的に言えば、ガーベッジ収集は、使用されていないブロッックを見出し、それらのホストＬＳＡを計算し、ＬＳＡに基づいてそれらのＣＡＴエントリの場所を突き止めることによって、機能する。特定ＬＳＡに対してＣＡＴエントリがない場合は、クラスタはすでに使用されていない。しかし、ＣＡＴエントリの場所が突き止められた場合、参照カウントが減少され、カウントがゼロになればクラスタは解放される。
１つの懸案事項は、ホストファイルシステムが使用中のブロックと、以前に使用し、ある時点で使用されていないとマークされたブロックを、ガーベッジコレクタが区別することが難しい場合があることである。ホストファイルシステムがブロックを書き込むと、格納システムは、データに対するクラスタならびにそれを表すＣＡＴエントリを割り当てる。その時点より、たとえホストファイルシステムが後にそのブロックを使用しなくなるとしても、クラスタは、概して使用中であるように思われる（すなわち、クラスタは、有効なＣＡＴエントリにより、なおも使用中となる）。
たとえば、特定のホストファイルシステムは、使用されたディスクブロックを追跡するためにビットマップを使用する。最初は、ビットマップは、たとえばすべてのビットをクリアすることによって、すべてのブロックが使用されていないことを示す。ファイルシステムが使用されると、ホストファイルシステムは、使用されていないブロックビットマップを使用することによって、ブロックを割当てる。格納システムは、クラスタおよびＣＡＴエントリを以前に概略された（ｏｕｔｌｉｎｅｄ）ものとして割当てることによって、物理的格納をこれらのファイルシステム割当てと関連づける。ホストファイルシステムが、一部のブロックを、使用されていないプールに解除するときに、使用されていないブロックビットマップにおける対応するビットをクリアする必要が単にある。格納システムの上で、このことは、ホストの使用されていないブロックビットマップの一部をたまたま含むクラスタへの書き込みとして、一般的に明らかにされ、おそらく解放された実際のクラスタに対するＩ／Ｏがない（しかし、たとえば、ホストファイルシステムが一部の強化されたセキュリティーモードで実行している場合には、解放されたクラスタに対するＩ／Ｏがあり得、その場合には、長期経過の（ｓｔａｌｅ）クラスタコンテンツが攻撃者によって読み出され得る可能性を低減させるために、ゼロまたはランダムデータのクリプトストロングハッシュ（ｃｒｙｐｔｏ ｓｔｒｏｎｇ ｈａｓｈ）をクラスタにおそらく書き込み得る）。さらに、ホストファイルシステムが、新しい割当てリクエストを満たすときに以前に解放したブロックを再使用するという保証はない。したがって、ホストファイルシステムが、格納システムの観点から、新しい、すなわち以前に再使用されたブロックを割当て続ける場合には、格納システムは、使用されていないクラスタをすぐに使い果たしてしまい、圧縮によって再生され得るどんなスペースにも左右される。たとえば、ファイルシステムブロックが４ｋであると想定すると、ホストが、ファイルシステムブロック１００〜５００を割当て、次に使用されていないブロック３００〜５００を割当て、次にブロック１０００〜１１００を割当てる場合には、合計のファイルシステム使用は３００ブロックになり、それでもアレイは５００クラスタを使用する。
本発明の例示的な実施形態において、格納システムは、ホストファイルシステムのレイアウトにアクセスし、その使用されていないブロックビットマップを分析し、ファイルシステムによってもはや使用されていないクラスタを特定するためにその情報を使用することによって、ホストファイルシステムのディスクリソースの解放を検出し得る。格納システムが未使用のクラスタをこのように特定できるためには、格納システムは、ファイルシステムの使用されていないブロックビットマップの場所を突き止めて理解することができなければならない。したがって、格納システムは、所定のセットのファイルシステムを一般的にサポートし、格納システムは、ファイルシステムについて、使用されていないブロックビットマップの場所を突き止めて利用するのに十分なほど内部の働きを「理解」する。サポートされないファイルシステムについては、格納システムは、おそらくガーベッジ収集を実行することができず、したがって、過剰にコミットされることを回避するために、アレイの実際の物理的サイズの公示のみをするべきである。
ファイルシステムタイプ（たとえば、ＮＴＦＳ、ＦＡＴ、ＲｅｉｓｅｒＦＳ、ｅｘｔ３）を決定するために、ファイルシステムのスーパーブロック（または同等の構造）の場所が突き止められる必要がある。スーパーブロックを見出すために、パーティションテーブルが分析されて、ＯＳパーティションの場所を突き止める。ＯＳパーティションの場所が突き止められると想定すると、スーパーブロックの場所を突き止める目的のために、ＯＳパーティションが分析され、それによってファイルシステムタイプを特定する。ひとたびファイルシステムタイプがわかると、使用されていないブロックビットマップを見出すために、レイアウトが分析され得る。
使用されていないブロックの検索を容易にするために、たとえば、非公式の非冗長ゾーンに格納され得る使用されていないブロックビットマップのコピーを作り、そのコピーを使用して検索を実行することによって、ホストファイルシステムビットマップの履歴データが保たれ得る。ビットマップのサイズを考慮すれば、情報は、ビットマップ全体についてではなく、一度に比較的少数のクラスタについて保たれ得る。ガーベッジ収集が実行されるときに、現在の使用されていないブロックビットマップが、クラスタごとに履歴コピーと比較され得る。割当てられた状態から使用されない状態へと移行する任意のビットマップエントリが特定され得、ごみあさりをする（ｓｃａｖｅｎｇｉｎｇ）操作が、再使用の良い候補であるクラスタに正確に向けられることを可能にする。それぞれのビットマップクラスタが処理されると、ビットマップ操作の経過する履歴を維持するために、履歴コピーが現在のコピーと置き換えられ得る。時間が経つにつれて、使用されていないブロックビットマップのコピーは、時間的にばらばらなクラスタの寄せ集めになるが、使用されていないエントリの場所を突き止めるために、現在のコピーがつねに使用されるので、このことは何の問題も引き起こさない。
特定の条件下で、たとえば、ホストファイルシステムが、使用されていないブロックビットマップを使用してディスクブロックを割当て、次にデータブロックを書き込み、次に変更されたビットマップをディスクに流し戻す場合には、使用されていないブロックビットマップに関する競争状態があり得る。そのような場合には、たとえファイルシステムがクラスタを使用中であるとしても、ガーベッジコレクタがクラスタを解放し得る。このことはファイルシステムの破損につながり得る。格納システムは、そのような条件を回避または処理するようにインプリメントされるべきである。
ガーベッジ収集はかなり高価な操作であり得、軽量のごみあさりがバックエンドＩ／Ｏ帯域幅を消費するので、ガーベッジ収集は過剰に使用されるべきではない。ガーベッジコレクタは、軽いバックグランドの遅いごみあさりから、積極的で重量の、または高優先度でさえあるごみあさりにわたる、いくつかのモードにおいて実行することができるべきである。たとえば、ガーベッジコレクタは、スペースの３０％が使用されるときに、または少なくとも週に一回、軽く実行され得、スペースの５０％が使用されるときに、やや激しく実行され得、ディスクスペースの９０％以上が使用されるときに、すっかり高優先度のごみあさりで実行され得る。ガーベッジコレクタの積極性は、再利用するクラスタの目標数に限定することによって、およびおそらくそれぞれの収集実行について最大の許容できるＩ／Ｏカウントに限定することによって、制御され得る。たとえば、ガーベッジコレクタは、わずか１０，０００のＩ／Ｏを使用して１ＧＢを再使用するように構成され得る。再利用リクエストを達成できなかったことは、次回に実行されるときにより積極的に操作するように、コレクタへのフィードバックとして使用され得る。ガーベッジコレクタがホストファイルシステム全体の使用されていないブロックビットマップを分析することと、おそらく可能なすべてのブロックを再使用することとの許可を、ガーベッジコレクタに与える、「すべて再使用」モードもあり得る。これは、アレイが（ほとんど）完全に満杯であるときに、クラスタを再使用する最後の試みとして行われ得る。ガーベッジコレクタは、そのルールを適用するために定期的に実行され得、ごみあさり操作を実行することを決定し得るかまたはし得ない。ごみあさり操作は、別のモジュール（たとえば領域マネージャが領域を構築するためにクラスタを見出そうと努力しているときの領域マネージャ）から明示的に要求されることもできるべきである。
ガーベッジ収集機能は、状態インジケータメカニズムの中に結びつけられ得る。たとえば、ある時点において、格納システムは「赤色」状態にあり得るが、進行中のガーベッジ収集操作は「赤色」状態を消去するのに十分なスペースを解放し得る。関連する状態情報を示すために、追加のインジケータ状態が使用され得る（たとえば、赤色インジケータは、ガーベッジ収集操作が進行中であることを示すように点滅させられ得る）。
図２１は、本発明の例示的な実施形態に従った、格納アレイの関連するコンポーネントを示す模式的なブロック図である。なかでも、格納アレイは、シャーシ２５０２を含み、格納マネージャ２５０４はシャーシ２５０２を介して複数の格納デバイス２５０８１〜２５０８Ｎと通信し、格納デバイス２５０８１〜２５０８Ｎはそれぞれ複数のスロット２５０６１〜２５０６Ｎを通してシャーシに結合される。それぞれのスロット２５０６１〜２５０６Ｎは、一つ以上のインジケータ２５０７１〜２５０７Ｎと関連づけられ得る。なかでも、格納マネージャ２５０４は、上述の機能性をインプリメントするための種々のハードウェアおよびソフトウェアのコンポーネントを一般的に含む。ハードウェアコンポーネントは、プログラムコード、データ構造、およびデータを格納するためのメモリ、ならびにプログラムコードを実行するためのマイクロプロセッサシステムを一般的に含む。
ファイルシステム認識格納制御装置２７２１を実装することに対する１つの懸案事項は、多くのホストファイルシステムがリアルタイムでデータ構造（すなわち、メタデータ）をアップデートしないことである。例えば、ファイルシステムのジャーナルレコードは通常、すでに起こったトランザクションに対するユーザデータのうちの全てを保存することを保証せず、または、そのようなトランザクションに対するメタデータのうちの全てを回復することを保証しないが、概して、一貫した状態に回復する能力のみを保証する。性能および効率に対して、ファイルシステムのジャーナルレコードはしばしば、ユーザデータ書き込みとメタデータ書き込みとの間の、ある程度の非同期性を備え持つ。特に、ディスクへのメタデータ書き込みは、ゆっくりと行われることが一般的であるため、ユーザデータアップデートと対応するメタデータアップデートとの間には遅延がある。ジャーナル書き込みもまた、一部のファイルシステム（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ＩｎｔｅｒｎａｌｓのＥｄ４によるＮＴＦＳ等）においてゆっくりと行われることがある。さらに、ゆっくりとしたメタデータ書き込みは、トランザクションごとの方式でジャーナルのプレイアウトによって行われることがあり、それには、一時的にメタデータを、すでにディスク上にあるユーザデータと矛盾している状態に追い込む、かなりの可能性がある。このことの例は、ホストがクラスタを再割り当てし、その再割り当てされたクラスタに対応するユーザデータを送信した後に、割当解除を示すビットマップアップデートであろう。よって、格納システムは、概して、ユーザデータの現在の状態を確実に示さないメタデータアップデートに対処する必要がある。前の例では、そのことは、概して、クラスタが再利用可能でありユーザデータが廃棄可能であるということを意味する割当解除を、格納システムが解釈できなかったことを、意味し得る。
メタデータおよびジャーナルアップデートが、対応するユーザデータアップデートに完全に非同期であり、いつでも起こり得る場合、格納システムは、ファイルシステムの内部の働きを比較的詳細に理解する必要があり、したがって、適切な決定を行うために広範囲な状態情報を格納する必要があり得る。しかし、下記の本発明の具体的な実施形態は、メタデータアップデートがそれらに関連するユーザデータ書き込み後の比較的決定論的な時間窓以内（例えば、１分以内）で発生することを前提として、動作するように設計されている。そのような実施形態は、ファイルシステムの内部の働きの詳細な理解および広範囲な状態情報の格納を必要とされないが、操作中のそのような窓に準拠しないホストファイルシステム（ＶｘＦＳが一例であってもよい）、またはユーザデータアップデートと対応するメタデータアップデートとの間の長い遅延をもたらす境界条件（例えば、概して格納システムの制御を越え、いずれにしてもデータ損失につながる場合がある、ホストからの機能の損失、または、格納システムが検出することにより、タイムリーなホスト活動を仮定する任意の挙動を抑制し得る、接続性の損失）に対処するために、特別な配慮を行う必要があり得るという点で本質的に複雑性と機能性との間のトレードオフであると理解される。
１つの例示的実施形態では、スカベンジャは、純粋に非同期方式で動作し得る。この実施形態では、スカベンジャは、全体または部分的のいずれかで、周期的にビットマップをスキャンし、ビットマップをＣＡＴに含まれる情報と比較して、格納アレイクラスタのうちのいずれかを再利用することが可能であるかどうかを決定する、純粋な非同期タスクであってもよい。ビットマップをチェックする前に、システムはまた、ビットマップが移動したかどうかを決定するために、ビットマップの位置を含むブロックをチェックしてもよい。
純粋な非同期スカベンジャの１つの利点は、主要データパス内のプロセッサオーバーヘッドに対する直接的影響が本質的にないことであるが、略非同期ディスクＩ／Ｏ（例えば、論理的に４ｋのクラスタに分割されて６４ＭＢビットマップを有する２ＴＢボリュームに対しては、ビットマップ全体を読み出すことは、スカベンジャが実行する度に６４＋ＭＢのディスクデータを読み出すことを伴う）を伴ってもよく、したがって、スカベンジャが実行する頻度に応じて全体的なシステム性能に影響してもよい。したがって、スカベンジャ頻度は、利用可能な格納スペースおよび／またはシステム負荷の量に応じて異なってもよい。例えば、利用可能な格納スペースが豊富であるか、またはシステム負荷が高いと、スカベンジャ機能はあまり頻繁に実行されない可能性がある。スカベンジャ頻度の低下は、概して、格納スペースが再利用される割合を減少させ、それは、概して格納スペースが豊富である時に容認可能である。一方、利用可能な格納スペースが乏しくシステム負荷が低いと、格納スペースが再利用される割合を増加させるために、スカベンジャ機能をさらに頻繁に実行することが可能である（追加された処理オーバーヘッドを犠牲にして）。
別の例示的実施形態では、スカベンジャは、部分的に同期で、部分的に非同期の方式で動作し得る。この実施形態では、スカベンジャは、例えば、主要書き込み対処パスに付加的チェックを追加することによって、ビットマップの変化が起こるとそれらを監視することが可能である。スカベンジャは、関心のＬＢＡ範囲を含むブート時におけるテーブルを構築することが可能である（以降、ビットマップロケータテーブル（Ｂｉｔｍａｐ Ｌｏｃａｔｏｒ Ｔａｂｌｅ）またはＢＬＴと呼ばれる）。初期化されていないディスク、または初期化されているがパーティションされていないディスクに対しては、ＢＬＴは、概して、ＬＢＡ０しか含まない。完全に初期化されフォーマットされたディスクに対しては、ＢＬＴは、概して、ＬＢＡ０、全パーティションブートセクタのＬＢＡ、ビットマップメタデータを含むＬＢＡ、およびビットマップデータ自体を含むＬＢＡ範囲を含む。
主要書き込み対処パス（例えば、ＨＲＴ）は典型的に、対処されている書き込みの詳細を伴うスカベンジャを呼び出し、その場合、呼び出しは、概して、関心のＬＢＡ範囲と重複する書き込みを特定する目的で、ＢＬＴと書き込みリクエストのＬＢＡを内部で相互参照する。次いで、スカベンジャは、そのほとんどが非同期タスクで行われ得る書き込みを解析する必要があるが（その場合、主要な詳細は、概して、下記のように非同期タスクに対して格納される必要がある）、重要な書き込みは、インラインで解析される（例えば、アップデートが再配置されたビットマップを潜在的に示す場合、さらなる書き込みが相互参照される前にＢＬＴをアップデートできるように、その書き込みをインラインで解析され得る）。純粋な非同期スカベンジャに関する上記のように、非同期タスクの頻度は、利用可能な格納スペースおよび／またはシステム負荷の量に応じて異なり得る。
非同期タスクに対する格納は、キューの形となり得る。しかし、単純なキューは、同じブロックに対する複数のリクエストをキューに入れることを可能にし、これは、書き込みのキャッシュの意味により、多数のリクエストがキャッシュ中の同じデータブロック（すなわち、最新のデータ）を指しやすくなるために起こり得、概して、同じＬＢＡを表す複数のリクエストを保持する理由がないために、非効率的である。このことは、キューを調べ、同じブロックに対する以前のリクエストを除去することによって、緩和することが可能である。さらに、利用可能な格納スペースおよび／またはシステム負荷の量に応じて非同期タスクの頻度が異なると仮定すると、非同期タスクが抑制される激しい活動の期間（何日も持続される場合がある）の間に、その最大サイズに到達するという予期が、キューに提供されるべきである。システムが同じＬＢＡに対する複数入力を許さないと仮定すると、キューの最大理論的サイズは、ＬＢＡのサイズおよびビットマップ内のＬＢＡの数の積であり、それは非常に大きなキューサイズをもたらし得る（例えば、２ＴＢボリュームは、６４ＭＢビットマップ（すなわち、１２８Ｋブロック）を有し、したがって約１２８Ｋ＊４＝５１２Ｋのキューサイズを必要とする場合があり、１６ＴＢボリュームは、約４ＭＢのキューサイズを必要とする場合がある）。
非同期タスクに対する代替的格納は、ビットマップの形となり得て（以降、「ビットマップブロックアップデートビットマップ（Ｂｉｔｍａｐ Ｂｌｏｃｋ Ｕｐｄａｔｅｓ Ｂｉｔｍａｐ）」または「ＢＢＵＢ」と呼ばれる）、各ビットが実ビットマップの１ブロックを表す。同じビットがそのようなリクエストのそれぞれに対して設定されているため、ＢＢＵＢは本質的に、同じブロックに対する複数のリクエストを回避するので、複数のリクエストはＢＢＵＢにおいて一度しか現れない。さらに、非同期タスクの頻度にかかわらず、ＢＢＵＢのサイズは本質的に固定されており、概して、キューより少ないスペースを占める（例えば、ＢＢＵＢは、２ＴＢボリュームに対して１６ＫＢのメモリ、または１６ＴＢボリュームに対して１２８ＫＢを占める）。実ビットマップが移動する場合、格納システムはＢＢＵＢにおけるビットのマッピングを容易に調整することが可能であるが、概して、ホストがデータをコピーし終わる前に保留中のリクエストを新しい位置にマップしないように配慮する必要がある（実際、ホストファイルシステムがいずれにしても全ＬＢＡを書き換えるという前提で、ビットマップを消去することが可能であり得る）。ＢＢＵＢは、非揮発性メモリ（ＮＶＲＡＭ）に配置され、現在のＢＢＵＢの損失を防いでもよく、または、現在のＢＢＵＢが失われる可能性があり、再起動の後しばらくしてビットマップの完全スキャンを実行し、失われた情報を回復する必要があることを理解して、揮発性メモリに配置してもよい。ビットマップは本質的に、リクエスト数の容易な指標を非同期タスクに提供しないため、非同期タスクがビットマップ全体を通してスキャンして、単に何もアップデートされていないと決定する必要がないように、格納システムは、ビットマップにおいて設定されたビット数についての統計を維持することが可能である。例えば、格納システムは、ビットマップ中にいくつのビットが設定されているかというカウントを維持する場合があり、カウントに基づいて非同期タスクの頻度を調整してもよい（例えば、カウントがユーザ設定可能であってもよい所定の閾値に到達できるまで、非同期タスクを実行しない）。そのような方策は、例えば、多数のマップセクション（例えば、１Ｋのチャンク）のそれぞれに対する設定ビットの別個のカウントを維持し、また最高カウントを有するマップセクションを把握することによって、さらに改良され得、それにより非同期タスクは、最大報酬を返す可能性があるマップセクションのみを解析することが可能である。
アップデートを解析することは、概して、異なるＬＢＡに対する異なる論理を伴う。例えば、ＬＢＡ０の変更は、概して、パーティションテーブルが追加されたこと、またはパーティションがテーブルに追加されたこと、またはパーティションが削除されたことを意味する。パーティションブートセクタのアップデートは、ビットマップメタデータが再配置されたことを意味する場合がある。ビットマップメタデータのアップデートは、ビットマップが除去されたこと、または拡張されたことを意味する場合がある。ビットマップ自体のアップデートは、クラスタの割当または割当解除を示す場合がある。アップデートが非同期的に解析される場合、非同期タスクが実行する時までに、新しいデータが古いデータを上書きしているかもしれないため、システムは、概して、古いデータを新しいデータと容易に比較することができない。この問題を回避するために、システムは、比較のために古いデータの別個のコピーを保持する場合があり、または、マップを通して反復し、未設定ビットをＣＡＴと比較する場合がある（これは、わずかに多くのプロセッサオーバーヘッドを必要とするが、より少ないディスクＩ／Ｏを必要とする場合がある）。上記のように、ビットマップの状態は、ユーザデータと同期しなくてもよいため、ビットマップをＣＡＴと単純に比較することは、概して、付加的な論理および状態情報を必要とする。さらに、ビットマップデータのコピーを保持することは、格納システムが新しいデータと古いデータと比較することを可能にすることにより、正確には何が変わったのかを決定するが、上記のように、格納システムは、概して、状態自体を信頼できる以上に、現在のユーザデータの正確なビュー（ｖｉｅｗ）として状態遷移を信頼することはできない。
さらに別の例示的実施形態では、スカベンジャは、純粋な同期的方式で動作し得る。この実施形態では、スカベンジャは、書き込みが発生するとそれらを処理する。純粋な同期実施形態の１つの利点は、非同期タスクの操作およびその関連格納と関連する複雑性を回避することであるが、それはホストからの書き込みに対処する重要な時期の間にプロセッサ上でオーバーヘッドを差し挟み、非同期メタデータアップデートを補うために付加的なロジックおよび状態情報が必要とされる場合がある。
非同期ビットマップアップデートとの関連でクラスタを再利用することに対する１つの懸案事項は、ユーザデータの状態を正確に反映しないビットマップ値に基づいて、スカベンジャがクラスタを不適切に解放するかもしれないことである。そのような問題を防ぐために、格納システムは、それが行うクラスタアクセスの何らかの履歴（例えば、それがクラスタ中のユーザデータに最近アクセスしたか否か）を保持し、メタデータアップデートがそのクラスタに対して保留中ではないことを確実にするために、クラスタがある以前の時間間隔にわたって休止している場合にだけクラスタを再利用する。例えば、格納システムは、クラスタの再利用を行う前に、クラスタが少なくとも１分間休止することを必要とする場合がある（一般的に言えば、休止時間を増やすと、不適切な再利用の危険性が低減するが、データ削除への反応における待ち時間が増加するため、ここにはトレードオフがある）。格納システムは、クラスタ書き込みのみを追跡することが可能であるものの、格納システムは、加えて、追加ディスクＩ／Ｏを犠牲にするが、クラスタ活動を徹底的に評価するためにクラスタ読み出しを追跡することが可能である。休止時間は、固定値となり得るか、または異なるファイルシステムに対して異なり得る。
クラスタアクセスは、例えば、スカベンジャ実行に対するアクセス時間の指標として、スカベンジャサイクル数をＣＡＴに書き込むことによって、追跡することが可能である。
あるいは、クラスタアクセスは、データに書き込む前にビットをファイルシステムのビットマップに書き込むことによって、追跡することが可能である。しかし、ファイルシステム操作とのあらゆる不利な相互作用を回避するために、ファイルシステムのメタデータのそのような修正は、慎重に調整されなければならない。
あるいは、クラスタアクセスは、各クラスタ、ブロック、チャンク（どんなサイズでも）に対するビットを使用して、追跡することが可能である。ビットは、概して、そのエンティティがアクセスされた時に設定され、スカベンジャがその次の実行を完了する時、またはスカベンジャが次にクラスタを再利用しようとする時に、リセットされる場合がある。スカベンジャは、概して、再利用を行おうとする時にこのビットがすでにリセットされていた場合にだけ、クラスタを再利用し、再利用自体は、実ホストファイルシステムビットマップにおける対応ビットがクリアにされることによって駆動される。これらのビットは単純ビットマップとして一緒に保持することが可能であるか、または、分散ビットマップとしてＣＡＴに追加することが可能である（ＣＡＴレコードごとにさらに１ビットを必要とする）。単純ビットマップアプローチは、ほとんどのデータ書き込み操作に対する付加的な読み出し−修正−書き込みを必要とし、ビットマップがメモリにキャッシュされない限り、主要データパスの性能の低下を潜在的に引き起こし得る（ビットマップは揮発性メモリにキャッシュすることが可能であり、これは、ビットマップが予期しない機能停止により失われた場合に問題となり得、または不揮発性メモリでは、メモリ制約のためにより小さいビットマップを余儀なくさせる場合があり、したがって粒度がより低くなる。）。ＣＡＴアプローチは、概して、Ｊ２およびその使用されていないＮＶＲＡＭキャッシングから利益を得る。
あるいは、クラスタアクセスは、ビットマップアップデートが受信される時、およびクラスタ修正が行われる時のタイムスタンプを維持することによって、追跡することが可能である。次いで、クラスタ修正にビットマップアップデートよりも後のタイムスタンプがある場合、システムは、概して、クラスタを解放しない。ビットアプローチを超えるこのアプローチの１つの利点は、スカベンジャが、どのくらい前に最後のアクセスが発生したかを決定し、十分に前であれば、クラスタを即時に再利用することが可能であるということである。タイムスタンプはまた、ＣＡＴレコードに追加してもよい。あるいは、フィールドはスカベンジャ操作に対する経過時間を示すことしか本当に必要としないため、包括的識別子を各スカベンジャ実行に割り当ててもよい。そして、システムは、包括的識別子の値を示すために、ＣＡＴ内の同様のフィールドを使用してもよい。包括的識別子は、どのスカベンジャ実行がごく最近完了したか、または次の予定であったか、またはクラスタが最後にアクセスされたのはいつだったかを特定してもよい。次いで、この情報は、経過時間の尺度としてスカベンジャによって使用され得る。ＣＡＴレコード中のスペース消費を節約するために、識別子は、１バイトカウンタだけになり得る。カウンタラッピングによる間違った経過時間決定は、実際よりもはるかに新しく見える古いクラスタとなる。これらのクラスタは、次の実行で再利用される。フィールドは、ＮＶＲＡＭに格納され、一部のクラスタアクセスが早期に時間経過することを引き起こし得る、フィールドが再起動の度にゼロにリセットされることを防いでもよい。
よって、例えば、全スカベンジャ実行は、１バイト識別子値と関連付けられ、これは、スカベンジャに対する識別子が、カウンタの増分後の値となるように、スカベンジャが起動する度に増分するＮＶＲＡＭ中の包括的カウンタとして実装され得る。ＣＡＴマネージャは、クラスタのアップデートを提供する時はいつでも、包括的カウンタの現在の値を使用することが可能であり、対応するＣＡＴレコード中にその値のコピーを格納することが可能である。そのような実装は、ＣＡＴマネージャ論理の修正を必要とする。
あるいは、クラスタアクセスは、ラッピングリスト中にクラスタアップデートの短い履歴を保持することによって、追跡することが可能である。次いで、スカベンジャは、リストを検索して、それが解放しようとしていた任意のクラスタがホストによって最近アクセスされていなかったことを検証し得る。リストのサイズは、概して、実装固有となる。それがどれほど長くても、格納システムは、概して、リストが満杯になり得る前に非同期タスクを実行できることを保証しなければならず、それは平穏な期間までタスクを延期する能力を低下させる。
ごみあさりをサポートする格納システムでは、早期再利用、特に早期再利用のために失敗する読み出し（すなわち、スカベンジャによって解放されたクラスタから読み出す試み）、また、割り当てられていないクラスタへの書き込み（概して、単に割当をもたらし、したがって無害となるはずである）を特定して追跡することが望ましい場合がある。状況によっては、ファイルシステムビットマップに基づくエラーを特定することが可能である（例えば、ユーザデータ書き込みからのビットマップの相互参照、および適切なビットが設定されていることのチェック）が、それは、ユーザデータの前にビットマップアップデートが完了することが保証されている場合に限られ、常に可能ということではない。あるいは、ビットマップを解析する時に、スカベンジャは、割り当てられたビットが割り当てられたクラスタに実際に対応するかどうかをチェックし、対応しなければクラスタ、または少なくともＣＡＴレコードを割り当て、スカベンジャから強制的に行われた割当を示す、それぞれのそのようなＣＡＴレコードに、ビットを設定し、ビットが、クラスタに対するデータ書き込みによってリセットされ、そして次のスカベンジャ実行で再びビットをチェックし、それがなおも設定されていれば知らせる。この予防策により途中停止させられたクラスタ再利用の回数のカウント等の、自己診断法をさらに含み、どのファイルシステムがこれをどの程度行ったのかという尺度をもたらすことが可能である。
上記の３種類のスカベンジャは、例示的にすぎず、本発明をいずれの特定設計または実装にも限定しないことに注目すべきである。各スカベンジャの種類には、特定の実装に対してそれを特に適切または不適切にする場合がある、ある相対的利点および不利点がある。さらに、特定の実装はスカベンジャの種類のうちの２つ以上をサポートし、例えば、ホストファイルシステム、利用可能な格納スペースの量、およびシステム負荷等のようなものに基づいて、必要に応じてそれらを動的に切り替え得ることに注目すべきである。非同期タスクに対する情報を格納するためにＢＢＵＢを使用し、かつクラスタアクセスを追跡するためにＣＡＴ内のバイトサイズのスカベンジャ実行カウンタ（ある種のタイムスタンプとして）を使用する、部分的に同期性で、部分的に非同期性のスカベンジャが、特定の実装に対して検討される。
いくつのクラスタがホストファイルシステムによって使用されているかを把握するために、スカベンジャに加えて、またはその代わりに、別個のモニタを使用することが可能である（例えば、ホストファイルシステムが、新しいブロックを使用するよりもむしろ割当解除されたブロックを確実に再利用すると分かっていれば、スカベンジャは省略される場合があるため、再利用は必要とされず、監視が十分となる。例えば、スカベンジャを実装するシステムでは、モニタは、重複として省略される場合がある）。一般的に言えば、モニタは、いくつのビットがビットマップに設定されるのか決定する必要があるのみで、どのビットが設定され、どのビットがクリアであるかを正確に知る必要はない。さらに、モニタは、正確なビットカウントを必要としなくてもよいが、設定ビットの数がある閾値よりも大きい、または小さいかどうか、あるいは数が同じ領域に対する以前の値よりも大きいか、または小さいかどうかを決定する必要があるのみであってもよい。したがって、モニタは、ビットマップ全体を解析する必要がないかもしれない。上記のスカベンジャの実施形態については、モニタ機能は、非同期タスクを使用して全体または部分的に実装することが可能であり、それは、周期的に新しいデータをＣＡＴと比較するか、またはビットマップのコピーを維持して、コピーを新しいデータで上書きする前に、現在のビットマップ（新しいデータ）をコピー（古いデータ）と比較することが可能である。
便宜上、様々な設計および操作の考慮は、主にＮＴＦＳとの関連で、スカベンジャを参照して下記で論じる。しかし、設計および操作の考慮の多くは、同様にモニタに該当することを十分理解するべきである。
図３２は、本発明の例示的実施形態に従った、スカベンジャ３２１０の関連構成要素を示す略ブロック図である。とりわけ、スカベンジャ３２１０は、ビットマップブロックアップデートモニタ（ＢＢＵＭ）３２１１、各ＬＵＮに対するＢＬＴを含むビットマップロケータテーブル（ＢＬＴ）３２１２の一群、各パーティションに対する１つのＢＢＵＢを含むＢＢＵＢ３２１３の一群、非同期タスク３２１４、および割当解除スペーステーブル（Ｄｅ−ａｌｌｏｃａｔｅｄ Ｓｐａｃｅ Ｔａｂｌｅ／ＤＳＴ）３２１５を含む。これらの構成要素のそれぞれを下記でさらに詳述する。同様に下記でさらに詳述するように、ＢＢＵＭ３２１１には、ＨＲＭ３２２０から受信される呼び出しを通して書き込み操作が通知される。
スカベンジャ３２１０は、各ＬＵＮに対するＢＬＴ３２１２を含む。各ＢＬＴ３２１２は、パーティション識別子、ＬＢＡ範囲、ＬＢＡ範囲の役割の表示、およびＬＢＡ範囲を同期または非同期的に分析するべきか否かを示すフラグを含む、一連のレコードを含む。各ＢＬＴは、パーティションに依存しないＬＢＡ０に対するエントリがある。ＢＬＴは、概して、そのＬＵＮ上に入って来る書き込みに対する高速ＬＢＡベースのルックアップを提供し（それらが最初にどのパーティションに属するのかをチェックせずに）、かつＬＢＡ０書き込みに対する比較的高速のパーティションベースのルックアップを提供する（例えば、格納に対しては選別されたベクタ、ルックアップに対しては、開始ＬＢＡの下限２分探索法および前の要素がルックアップされているＬＢＡよりも高い最後のＬＢＡを有するかどうかのチェックを使用して、達成され得る）ことが必要とされる。ＢＬＴは、概して、例えば、ＬｏａｄＤｉｓｋＰａｃｋ呼び出しの間、あらゆる通過するホスト書き込みの前にプログラムされる必要がある。ＢＬＴは、ＬＢＡ０によりプログラムされ、これはパーティションテーブルの位置であるため、したがってパーティションの作成は、このＬＢＡへの書き込みを伴う。ＬＢＡ０は、アップデートが即時解析を必要とする位置として、このテーブル内でフラグを付けられる。
スカベンジャ３２１０は、格納システムによってサポートされる各パーティションに対するＢＢＵＢ３２１３を含む。各ＢＢＵＢ３２１３は、それが関連するファイルシステムビットマップのサイズに対して適切にサイズ決定される。各ＢＢＵＢ３２１３は、ビットマップにいくつのビットが設定されているかを反映するカウンタと関連する。ＢＢＵＢ３２１３はまた、各ビットマップがその対応するファイルシステムビットマップにどのように関連するかを示す、何らかのマップ情報も含む。
スカベンジャ３２１０は、各ＬＵＮに対するＤＳＴ３２１５を含む。各ＤＳＴ３２１５は、レコードにつき１つのＬＢＡ範囲を含む。テーブル中に存在する各ＬＢＡ範囲は、ＣＡＴから再利用される必要がある、削除または切断されたパーティションの一部である。ＢＢＵＭ３２１１は、例えば、同期処理中に再利用に対する未使用格納エリアを特定すると、ＤＳＴ３２１５をアップデートしてもよい（その場合、ＢＢＵＭ３２１１は、ＤＳＴ３２１５にＬＢＡ範囲を追加する）。同様に、非同期タスク３２１４は、非同期処理中に再利用に対する未使用格納エリアを特定すると、ＤＳＴ３２１５をアップデートしてもよい（その場合、ＤＳＴ３２１５にＬＢＡ範囲を追加する）。非同期タスク３２１４は、非同期的に未使用格納スペースを再利用するために、ＤＳＴ３２１５を使用する。ＤＳＴ３２１５は、クリーンではないシャットダウンに対して回復機能がある方法で持続的に格納してもよく、または、例えば、再起動後に完全スキャンを行って、いずれのボリュームにも属さない割り当てられたクラスタを見出すことによって、ＤＳＴ３２１５の損失から回復するように、付加的な論理が提供されてもよい。
ＢＢＵＢ３２１３およびＤＳＴ３２１５の格納は、実装固有の決定である。例示的実施形態では、ＢＢＵＢ３２１３は、大きすぎてＮＶＲＡＭに格納できないため、揮発性メモリまたはディスクに格納してもよい一方で、ＤＳＴ３２１５は、不揮発性メモリ、揮発性メモリ、またはディスクに格納してもよい。ＤＳＴ３２１５およびＢＢＵＢ３２１３が完全に揮発性である場合、スカベンジャ３２１０は、概して、ＤＳＴ３２１５およびＢＢＵＢ３２１３の損失（例えば、予期しないシャットダウンによる）から回復することが可能でなければならない。回復は、例えば、ＣＡＴ全体を通してスキャンし、それを現在のパーティションおよびクラスタビットマップ情報と比較して、各クラスタが既知のパーティションにマップされているか、および対応するファイルシステムのクラスタビットマップにおいて割り当てられているかを確認することによって、達成される場合がある。別の可能性は、ボリューム外のディスクスペースに対する状態情報が、再起動にわたって保存されるように（潜在的に、パーティション外のクラスタについてのＣＡＴＭのクエリを行う必要性を防ぐ）、ＤＳＴ３２１５をＮＶＲＡＭに格納し、ＢＢＵＢ３２１３を揮発性メモリに残すことであるが、クラスタビットマップの現在の状態は失われ、全クラスタビットマップの完全スキャンを余儀なくする。そのようなビットマップスキャンは、例えば、全ての必要な状態情報をディスク上に格納し、それを再起動時に単にリロードすることによって、低減または排除することが可能である。スカベンジャ３２１０はシャットダウンの通知を予期できないため、同期的にアップデートすることによって、または数ミリ秒あるいは数秒以内に再び書き込むことによってのいずれかで、レコードをリアルタイム状態と密接に同期化させておく必要がある。たとえホストが実際にシャットダウンされなくても、ホストからの数秒の非活動の後に意図的なシャットダウンが起こると仮定することは合理的と思われるため、数秒以内にアップデートすることは、ほとんどの状況に対しておそらく適切であるが、Ｉ／Ｏの半ばで発生したシャットダウンは、なおも完全スキャンを必要とする可能性がある。レコードが同期的にアップデートされる場合（すなわち、ビットマップアップデートをディスクに書き込む前）、システムは、状態の損失、および対応する起動時の完全スキャンの必要性を完全に排除することが可能な場合がある（しかし、起動時にさらに良好な効率を獲得するように、定常操作中にさらなるディスクＩ／Ｏを必要とすることを犠牲にする）。別の選択肢は、再起動時に情報が利用可能となるように、システムシャットダウンン手順の間に、ＢＢＵＢ３２１３およびＤＳＴ３２１５をディスクに書き込むことである（予期しない故障／シャットダウンの場合を除く。その場合、再起動時にクラスタの完全スキャンが必要であってもよい）。
一般的に言えば、スカベンジャ３２１０は、ディスクパックがロードされるまでは、あまりすることがないが、例示的実施形態では、ＣＡＴマネージャ（ＣＡＴ Ｍａｎａｇｅｒ）またはキャッシュマネジャ（Ｃａｃｈｅ Ｍａｎａｇｅｒ）（ディスクパック（ＤｉｓｋＰａｃｋ）から読み出すため）、およびＮＶＲＡＭマネージャ（ＮＶＲＡＭ Ｍａｎａｇｅｒ）（カウンタを増分するため）等の、スカベンジャが依存するモジュールを初期化した後に、スカベンジャ３２１０がシステムマネジャによって初期化されることが検討される。あるいは、スカベンジャは、ゆっくりと、例えば、ディスクパックがロードされた後に、初期化され得る。スカベンジャは、ほぼ即時にディスクパックから読み出しを開始することが可能であるため、他の構成要素の準備ができて、それら自体にも同じディスクパックがロードされるまで、スカベンジャは、ディスクパックをロード（すなわち、「ディスクパックのロード（ＬｏｒｄＤｉｓｋＰａｃｋ）」）するように指示されるべきではない。
スカベンジャ３２１０の初期化の間（またはその他の何らかの適切な時において）、ＢＢＵＭ３２１１は、ＬＢＡ０においてＮＴＦＳパーティションテーブル（ＮＴＦＳ Ｐａｒｔｉｔｉｏｎ Ｔａｂｌｅ）を探す。ＮＴＦＳパーティションテーブルは、マスタ起動レコード（Ｍａｓｔｅｒ Ｂｏｏｔ Ｒｅｃｏｒｄ）と同じＬＢＡ、すなわちＬＢＡ０にある６４バイトのデータ構造であり、ＮＴＦＳプライマリパーティションについての情報を含む。各パーティションテーブルエントリは、長さ１６バイトで、最大４つのエントリを利用可能にする。各エントリは、セクタの始まりからの所定のオフセット、および所定の構造において開始する。パーティションレコードは、パーティション種類がＮＴＦＳであるか否かを格納システムが決定することを可能にする、システム識別子を含む。パーティションテーブルの位置およびレイアウトは、それを書き込むオペレーティングシステムとは、概して多少無関係であることが分かっており、同じパーティションテーブル構造がＮＴＦＳだけでなく、かつＭｉｃｒｏｓｏｆｔ形式だけでなく、一連のファイルシステム形式に役立つ（ＨＦＳ＋およびその他のファイルシステムは、そのパーティションの場所を突き止めるために異なる構造を使用してもよい）。
ＮＴＦＳパーティションテーブルがＬＢＡ０にあると仮定すると、ＢＢＵＭ３２１１は、ＬＢＡ０からパーティションテーブルを読み出し、次いで、パーティションテーブルにおいて特定された各ＮＴＦＳパーティションに対して、パーティションのブートセクタ（パーティションの第１セクタ）、および、特に、マスタファイルテーブル（Ｍａｓｔｅｒ Ｆｉｌｅ Ｔａｂｌｅ／ＭＦＴ）の位置を提供するＮＴＦＳパーティションに特有の構造である、拡張ＢＩＯＳパーティションブロックを読み出す。次いで、ＢＢＵＭ３２１１は、ＭＦＴの常駐＄ビットマップレコードを読み出して、ファイル属性、特に、実際のビットマップデータの位置および長さを獲得する。ＢＢＵＭ３２１１はまた、各パーティションのブートセクタＬＢＡ、ビットマップレコードのＬＢＡ、および実際のビットマップのＬＢＡによりＢＬＴ３２１２をプログラムする。ブートセクタＬＢＡおよびビットマップレコードＬＢＡはまた、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。実際のビットマップは、概して、即時解析を必要とせず、それに応じてフラグを付けられる。ＬＢＡ０にパーティションテーブルがない場合、ＢＬＴ３２１２にさらなる位置は追加されない。
図３３は、本発明の例示的実施形態に従った、ホストファイルシステムビットマップの場所を突き止めるための疑似コードである。ファイルシステム認識格納制御装置２７２１は、まずＬＢＡ０においてパーティションテーブルを探す。パーティションテーブルがあると仮定すると、ファイルシステム認識格納制御装置２７２１は、パーティションテーブルを読み出して、パーティションを特定する。次いで、各パーティションに対して、ファイルシステム認識格納制御装置２７２１は、パーティションのブートセクタを読み出してＭＦＴを見出し、ＭＦＴの常駐＄ビットマップレコードを読み出して、実際のビットマップデータの位置および長さ等の、ファイル属性を獲得する。ファイルシステム認識格納制御装置２７２１は、各パーティションのブートセクタＬＢＡ、ビットマップレコードのＬＢＡ、および実際のビットマップのＬＢＡによりＢＬＴをプログラムし、即時解析を必要とするようにブートセクタＬＢＡおよびビットマップレコードＬＢＡにフラグを付け、即時解析を必要としないように実際のビットマップにフラグを付ける。ファイルシステム認識格納制御装置２７２１がＬＢＡ０においてパーティションテーブルを見つけることができない場合は、ＢＬＴにさらなる位置を追加せずに、ファイルシステム認識格納制御装置２７２１が終了する。
定常状態操作中、全ての書き込みは、ＨＲＭ３２２０からのＢＢＵＭ３２１１への呼び出しを通して、ＢＬＴ３２１２に対して相互参照される。ＬＢＡ０宛てであると分かったあらゆる書き込みは、措置を指示するフラグのとおりに、即時に（同期的に）解析される。後の措置は、アップデートの性質に依存する。
パーティションが追加されていて、パーティションが認識された種類である場合、新しいパーティションの第１のＬＢＡがＢＬＴ３２１２に追加され、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。クラスタ再利用を駆動する一連のアップデートを伴うビットマップがすぐに現れることを予期して、ＤＳＴ３２１５から、新しいパーティションの範囲内のあらゆるＬＢＡ範囲が除去される。１つの懸案事項は、パーティションテーブルアップデートよりも先にパーティションが書き出された場合、この情報はＤＳＴ３２１５におけるブロックに書き込まれる可能性があり、スカベンジャスレッドによって不正に再利用され得ることである。このことは、例えば、ＤＳＴ３２１５における範囲との一致について、受信した全書き込みをチェックし、ＤＳＴ３２１５からブロックへの書き込みを除去することによって、緩和することが可能である。
パーティションが、パーティション識別子をＷｉｎｄｏｗｓ（登録商標）デフォルトからＮＴＦＳに変更するようにアップデートされている場合、ＢＢＵＭ３２１１は、パーティションブートセクタが書き込まれた後に識別子の変更が起こる傾向があるため、パーティションブートセクタの位置におけるＬＵＮを即時に再調査する。このことは全くパーティション追加の一部にすぎない。
既存のパーティションが削除されている場合、削除されたパーティションに関するレコードがＢＬＴから消去され、そのパーティションに対するＢＢＵＢ３２１３が削除され、ＬＢＡ範囲がクラスタの非同期再利用のためにＤＳＴ３２１５に追加される。
既存のパーティションが移動されている場合、ＢＬＴ３２１２における既存のブートセクタレコードは、監視する新しいブートセクタＬＢＡと共にアップデートされる。すでに書き込まれている場合に備えて、新しい位置においてＬＵＮが即時に再調査される可能性があるが、このことは大抵行われない。
既存のパーティションが切断されている場合、切除されたＬＢＡ範囲は、ＤＳＴ３２１５に追加される。新しいブートセクタがすでに書き込まれている場合に備えて、パーティションブートセクタの位置においてＬＵＮが即時に再調査される可能性があるが、このことは大抵行われない。
既存のパーティションが拡大されている場合、ＤＳＴ３２１５から新しいパーティションの範囲内のあらゆるＬＢＡ範囲が除去される。新しいブートセクタがすでに書き込まれている場合に備えて、パーティションブートセクタの位置においてＬＵＮが即時に再調査される可能性があるが、このことは大抵行われない。
パーティションの第１のＬＢＡ宛てであると分かったあらゆる書き込みは、措置を指示するフラグのとおりに、即時に（同期的に）解析される。ビットマップレコードの開始ＬＢＡは決定されてＢＬＴ３２１２に追加され、アップデートが常に即時解析を必要とする位置として、フラグを付けられる。
図３４は、本発明の例示的実施形態に従った、ＢＢＵＭ３２１１に対する高レベル疑似コードである。ＢＢＵＭ３２１１がクライアントのリクエストを受信すると、クライアントリクエスト（ＣｌｉｅｎｔＲｅｑｕｅｓｔ）からＬＵＮを獲得し、ＬＵＮに基づいて適切なＢＬＴを見出す。ＢＢＵＭ３２１１は、クライアントリクエストからＬＢＡを獲得し、ＢＬＴにおいてこのＬＢＡを探し、「即時の措置」フィールドをチェックして、このＬＢＡに対して即時の措置が必要であるかどうかを確認する。即時の措置が必要であれば、ＢＢＵＭ３２１１は、クライアントのリクエストを同期的に処理する。しかし、即時の措置が必要とされない場合、ＢＢＵＭ３２１１は、非同期処理に対するＬＢＡに対応するＢＢＵＢビットを設定する。
図３５は、本発明の例示的実施形態に従った、新しいパーティションを作成するＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションテーブルであれば、ＢＢＵＭ３２１１は、新しいデータにおけるパーティションをＢＬＴにおけるパーティションと比較する。新しいパーティションが追加されている場合、ＢＢＵＭ３２１１は、新しいデータからパーティションの開始および終了を獲得し、あらゆる重複ＬＢＡ範囲についてＤＳＴ３２１５をチェックしてそれらを除去し、パーティションの開始をＢＬＴに追加し、即時の措置に対するエントリにフラグを付ける。
図３６は、本発明の例示的実施形態に従った、パーティションを（再）フォーマットするＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションブートセクタである場合、ＢＢＵＭ３２１１は、新しいデータからＭＦＴの開始を獲得し、ビットマップレコードの位置を計算する。このパーティションに対して、ＢＬＴにすでに同一のビットマップレコードエントリがある場合は、何も必要とされない。しかし、ビットマップレコードがＢＬＴバージョンとは違う位置にある場合、ＢＢＵＭ３２１１は、ＢＬＴをアップデートして、ディスクから新しい位置を読み出す。その位置がビットマップレコードのようでない場合（すなわち、＄ビットマップ列がない）は、何も必要としない。しかし、位置がビットマップレコードのようである場合、ＢＢＵＭ３２１１は、新しいビットマップ位置を獲得し、それらをＢＬＴと比較する。新しいビットマップ位置が同一であれば、何も必要とされない。新しいビットマップが異なる位置にある場合、ＢＢＵＭ３２１１は、全てのＢＢＵＢビットを設定し、ＢＢＵＢマッピングをアップデートし、ＢＬＴにおけるＬＢＡ範囲を移動する。新しいビットマップが既存のビットマップより小さい場合、ＢＢＵＭ３２１１はＢＢＵＢを縮小し、マップされていないＬＢＡ範囲をＤＳＴ内に追加し、ＢＬＴにおけるＬＢＡ範囲を縮小する。新しいビットマップが既存のビットマップより大きい場合、ＢＢＵＭ３２１１は、全ての追加ＢＢＵＢビットを設定し、ＢＢＵＢを拡大し、ＢＬＴにおけるＬＢＡ範囲を拡大する。
図３７は、本発明の例示的実施形態に従った、パーティションを削除するＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。具体的には、即時の措置が必要とされ、ブロックがパーティションテーブルである場合、ＢＢＵＭ３２１１は、新しいデータにおけるパーティションをＢＬＴにおけるパーティションと比較する。パーティションが削除されている場合、ＢＢＵＭ３２１１は、ＢＢＵＢを削除し、ＢＬＴからブートセクタを削除し、ＢＬＴからビットマップレコードを削除し、ＢＬＴからビットマップ範囲を削除しパーティション範囲をＤＳＴに追加する。
図３８は、本発明の例示的実施形態に従った、非同期タスク３２１４に対する高レベル疑似コードである。非同期タスク３２１４は、ＢＢＵＢを解析し、次いで、ＢＢＵＢにおいて設定された各ビットに対して、非同期タスク３２１４は、対応するクラスタがホストファイルシステムによって使用されていないとマークされているかどうかをチェックする。クラスタがホストファイルシステムによって使用されていないとマークされていれば、非同期タスク３２１４は、クラスタが格納制御装置によって使用されているとマークされているかどうかをチェックする。クラスタが格納制御装置によって使用されているとマークされていれば、非同期タスク３２１４は、ＬＢＡ範囲をＤＳＴに追加する。非同期タスク３２１４はまた、ＤＳＴにおける各ＬＢＡ範囲に対する格納スペースを再利用する。
ブートセクタアップデートを受信した後、ビットマップレコードがすでにディスクに書き込まれているかもしれないため、ビットマップレコードの書き込みを待機することは、概して、十分ではない（概して、どの順序でＮＴＦＳフォーマットが発生するのかが分からず、いずれにしてもそれはマイナーパッチで変化し得る）。ビットマップレコードが拡張ＢＰＢの前に書き込まれる場合、位置がＢＬＴ３２１２に存在しないため、ＢＢＵＭ３２１１はそれを捕らえない。このことの例外は、ビットマップレコードの位置が変化していない場合である。例外にもかかわらず、ＢＢＵＭ３２１１は、概して、この時点でディスクからビットマップレコードの位置を即時に読み出して、ビットマップレコードが存在するかどうかを確認しなければならず、概して、ランダムノイズと初期化されたビットマップレコードを区別することが可能である必要がある（＄ビットマップユニコード列についてチェックすることがあり得る）。それが書き込まれていない場合、書き込みを待機することが可能である。すでにディスク上にあれば、概して、即時に解析しなければならない。解析は、概して、ビットマップの位置に対してレコードが解読されることを必要とし、それらの位置は、ＢＬＴ３２１２に追加され、即時解析を必要しないとしてフラグを付けられる。解析は、概して、ビットマップのサイズが変化した場合、ビットマップの新しいサイズおよび位置に基づいて、新しいＢＢＵＢ３２１３のインスタンスが作成されることも必要とし、そうでなければ、新しい位置で既存のＢＢＵＢ３２１３をアップデートすることが概して十分である。概して、ビットマップレコードを書き込む前または後にホストが新しいビットマップを書き出すかどうかが分からないため、全てのビットを設定することが適切であるとも思われる（後である見込みがあるが、それが起こった場合、ビットマップ書き込みが入って来るにつれて、数秒以内にビットが害を及ぼされず２度目に設定される）。危険なのは前に書き込みが起こった場合であり、その場合、異なる位置にあるために書き込みが見逃されることとなる。全てのビットを設定することが、ビットマップが解析されることを保証する。
ブートセクタアップデート（例えば、パーティションの再フォーマットによる）の場合、ビットマップは、同じサイズとなり、同じ位置を占める可能性があるため、概して、ＢＬＴ３２１２またはＢＢＵＢ３２１３には変化がない。新しいビットマップはおそらく、ほとんどのブロックが全てゼロで書き直されるため、非同期タスク３２１４は、ＣＡＴから割り当てられていないクラスタを再利用するために、それらの処理を進めることが可能であるはずである。ブートセクタのボリューム通し番号をチェックして、アップデートが再フォーマットの結果であったかどうかを決定することが可能である。
ビットマップレコードはまた、ブートセクタと無関係の理由でいつでもアップデートすることも可能である。スカベンジャ３２１０は、オンザイフライで移動する、またはサイズを変えるビットマップに対処することが可能である必要があるかもしれない。異なるサイズのパーティションを作成せずにビットマップがサイズを変え得るかどうかは明確ではないが、ＮＴＦＳの将来のバージョンは、どのような理由であれ、このことをサポートしてもよい。この状況では、ビットマップの新しい位置は、概して、ＢＬＴ３２１２にプログラムしなければならず、古いエントリは除去され、新しいエントリが追加される。ＢＢＵＢ３２１３は、それにしたがって拡大または縮小しなければならない。縮小によって解放されたあらゆるＬＢＡ範囲は、ＤＳＴ３２１５に追加することが可能であるが、厳密にそれらはなおもパーティションにマップする。
別の懸案事項は、ビットマップレコードの最後のアップデートフィールドの時間が、ビットマップの進行中の修正を反映するように頻繁に修正された場合に、結果が、相当量のインライン解析となり得ることである。
ビットマップ自体への全ての後の書き込みは、ＢＢＵＢ３２１３を介して非同期タスク３２１４へと押し進められる。
ここでの基本的方策は、全ての割り当てられたクラスタが、ＢＢＵＢ３２１３またはＤＳＴ３２１５のいずれかにおいて表され、どちらにしても、割り当てられていないものが再利用されることである。代替的な解決法は、ＣＡＴマネージャへと進み、そこでボリューム識別子がＣＡＴレコードに格納される前に、各書き込みがＢＢＵＭ３２１１によってボリュームにマップされ、その識別子で標識されなければならないような、ＢＢＵＭ３２１１およびＣＡＴの両方に既知である、各ボリュームに対するボリューム識別子を有することである。新しいボリュームは典型的に、それが上書きしていた古いボリュームとは異なる識別子を獲得するため、非同期タスク３２１４は、新しいボリュームからのデータで上書きされたクラスタを再利用する危険なしで、古いボリューム識別子を伴うレコードを再利用することが可能である。明らかに、このことは、ＣＡＴレコードにおけるスペースを消費する。これはまた、再フォーマットにおける書き込みの順番にも依存している。システムは、概して、新しいボリューム通し番号がブートパーティションに現れるまで新しいボリュームについて知ることができないため、これに先行するその他任意の書き込みは、古いボリューム識別子で標識される。
大部分の作業は、通常１分に１回起動し、ＢＢＵＢ３２１３から何らかの作業を収集し、キャッシュを通してビットマップブロックをページインしてビットをＣＡＴと比較することによって、それを実行する、専用スカベンジャタスク３２１４によって行われる。例示的実施形態では、ＢＢＵＢ３２１３は、論理的にセグメント化され（１ｋのセグメントサイズ）、そのセグメントのアップデート数を示す各セグメントに対するカウンタ、および任意のカウンタによって保持される最高値を反映する包括的カウンタがあり、これらのカウンタは、作業生成器（ＢＢＵＭ３２１１）によって増分され、作業消費器（スカベンジャタスク３２１４）によって減少される。スカベンジャタスク３２１４は、起動時に、包括的カウンタをチェックし、その中の値が、ビットマップのページインを正当化するのに十分高いかどうかを決定する。もしそうであれば、タスク３２１４は、どのセグメントにその値が対応するかを決定し（例えば、カウンタアレイを通して反復することによって）、次いで、適切なＢＢＵＢセグメントのビットを通して反復を開始する。設定されたビットを見出すと、ビットマップのそのブロックをページインし、それをＣＡＴと比較する。
上記のように、スカベンジャタスク３２１４の操作は、例えば、それが実行する頻度、またはそれが作業を行うことを決定する閾値を変更することによって、動的に調整することが可能である。しかし、本発明の例示的実施形態では、スカベンジャが実行する頻度にアーキテクチャが多少連結されているため、そのような調整は、概して、行われない。具体的には、最大時間窓（例えば、１分）以内にホストファイルシステム２７１１がそのメタデータを実行するという前提で、提案されたアーキテクチャが設計されているため、提案されたアーキテクチャは、現実的には最大時間窓よりも頻繁にスカベンジャタスク３２１４を実行することができない。提案されたアーキテクチャは、その規則を実際に破ることなく低い頻度で実行を行うことが可能であるが、それは、一部のクラスタアップデートを実際よりも最近であるように見せることによって、クラスタ再利用の効率を低下させる可能性がある（例えば、実行が毎分起こるが、実際には、例えば３分毎に起こるという前提で経過時間計算を設計した場合、経過時間計算は３の因数によってオフとなり得る）。さらに、タスク優先度は、概して、コンパイル時間で固定され、したがって、システム操作中に概して変更されない。
本発明の例示的実施形態では、格納システムは、４Ｋサイズのクラスタを実装することに注目するべきである。よって、ファイルシステムが４Ｋ以外のクラスタサイズでフォーマットされた場合、ファイルシステムビットマップにおけるビットは、格納システムにおけるクラスタとうまく相関しない。例えば、ファイルシステムクラスタサイズが４Ｋより小さい場合、ビットマップの複数のビットは、概して、ＣＡＴとの相互参照を気遣いクリアされなければならない。しかし、ファイルシステムクラスタサイズが４Ｋより大きい場合、ビットマップの１つのクリアなビットは、概して、各４Ｋに対して１つずつ、ＣＡＴへの複数のルックアップを必要とする。
別の懸案事項は、時期が早すぎて再利用できないクラスタにスカベンジャが遭遇する状況にどのように対処するかである。そのような状況において、スカベンジャは、ＢＢＵＢにおいて設定されるビットを残すことによって、１つ以上の以降のスキャンを必要とし、５１２ビットの全体を通して再び解析することが可能である（例えば、次のスキャンが５１２ビットを調べて、単にクラスタの時期がまだ早すぎて再利用できないことが分かる場合がある）。あるいは、スカベンジャは、ビットをクリアして、再チェックを必要とする時期の早いブロック／ビットオフセットのリストにクラスタを追加することが可能である。実装の観点より、後者のアプローチは、リストを極めて小さく保つことが可能である場合にだけ、実用的となる。
実装の観点より、スカベンジャおよびＢＢＵＢは両方ともＣＡＴマネージャを通してディスクから読み出す。クラスタ再利用は、ＣＡＴマネージャによって提供される特別なＡＰＩを通して行われる。
（仮想ホットスペア）
上述のように、多くの格納システムにおいて、ホットスペア格納デバイスが作動可能状態において維持されるので、別の格納デバイスが故障した場合に迅速にオンラインにされ得る。本発明の特定の実施形態において、物理的に別個のホットスペアを維持するのではなく、複数の格納デバイスにわたる未使用の格納容量から、仮想ホットスペアが作成される。物理的なホットスペアとは異なり、この未使用の格納容量は、格納デバイスが残りの格納デバイスから回復されたデータを格納できない場合に利用可能である。
仮想ホットスペア機構は、ディスク故障の際にデータが冗長に再レイアウトされ得ることを保証するために、アレイの上に十分なスペースが利用可能であることを必要とする。したがって、進行中の方法で、格納システムは、一般的に、仮想ホットスペアのインプリメンテーションのために必要とされる未使用の格納容量の量を決定し（たとえば、格納デバイスの数、種々の格納デバイスの容量、格納されるデータの量、およびデータが格納される方法に基づいて）、仮想ホットスペアのために追加の格納容量が必要とされる場合に信号を発生する（たとえば、実質的に上述のような状態およびスロットを示す緑色／黄色／赤色のライトを使用して）。ゾーンが割当てられると、ディスクごとにそのゾーンを再レイアウトするためにいくつの領域が必要とされるかについてのレコードが保たれる。以下の表は、４つのドライブが使用される仮想ホットスペアを示す。
Figure 2009536414
Figure 2009536414
 以下の表は、３つのドライブが使用される仮想ホットスペアを示す。
Figure 2009536414
 この例示的な実施形態において、仮想ホットスペアは、１つまたは２つのドライブのみを有するアレイの上では利用可能ではない。それぞれのゾーンと、アレイにおけるディスクの数とに関する情報に基づいて、アレイは、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定し、それぞれのシナリオについてそれぞれのドライブの上で十分なスペースが利用可能であることを保証する。生成される情報は、再レイアウトエンジンおよびゾーンマネージャにフィードバックされ得るので、データは、データ格納とホットスペア機構との間で正しくバランスを取られ得る。ホットスペア機構は、再レイアウトが生じ得るように、ゾーンレイアウトデータから計算されるものに加えて、十分なスペアワーキングスペース領域を必要とすることに留意されたい。
図２２は、本発明の例示的な実施形態に従った、仮想ホットスペアを管理するための例示的な論理を示す論理フロー図である。ブロック２１０２において、論理は、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定する。ブロック２１０４において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトするためにそれぞれのドライブの上で必要とされるスペースの量を決定する。ブロック２１０６において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトするために必要とされるスペアワーキングスペース領域の量を決定する。ブロック２１０８において、論理は、最悪の事態のシナリオにおいてデータを冗長に再レイアウトすることを可能にするためにそれぞれのドライブの上で必要とされるスペースの総量を決定する（基本的に、再レイアウトのために必要とされるスペースの量と、必要とされるスペアワーキングスペース領域の量との合計）。ブロック２１１０において、論理は、格納システムが適切な大きさの利用可能な格納デバイスを含むかどうかを決定する。適切な大きさの利用可能な格納デバイスがある場合には（ブロック２１１２における「はい」）、論理反復はブロック２１９９において終了する。しかし、不適切な大きさの利用可能な格納装置がある場合には（ブロック２１１２における「いいえ」）、論理は、ブロック２１１４において、どのドライブ／スロットがアップグレードを必要とするかを決定する。次に、ブロック２１１６において、論理は、追加の格納スペースが必要とされるという信号を出し、どのドライブ／スロットがアップグレードを必要とするかを示す。論理反復は、ブロック２１９９において終了する。
図２３は、本発明の例示的な実施形態に従った、図２２のブロック２１０２におけるような、それぞれのあり得るディスク故障について再レイアウトのシナリオを決定するための例示的な論理を示す論理フロー図である。ブロック２２０２において、論理はゾーンを割当てる。次に、ブロック２２０４において、論理は、ディスクごとにそのゾーンを再レイアウトするためにいくつの領域が必要とされるかを決定する。論理反復は、ブロック２２９９において終了する。
図２４は、本発明の例示的な実施形態に従った、仮想ホットスペア機能を呼び出すための例示的な論理を示す論理フロー図である。ブロック２３０２において、論理は、最悪の事態のシナリオの際にデータを冗長に再レイアウトすることを可能にするために利用可能な格納の十分な量を維持する。ブロック２３０４においてドライブの損失（たとえば取り外しまたは故障）を決定すると、論理は、ブロック２３０６において、データの故障許容を復元するために、一つ以上の残りのドライブを自動的に再構成する。論理反復は、ブロック２３９９において終了する。
図２５は、本発明の例示的な実施形態に従った、図２４のブロック２３０６におけるような、データの故障許容を復元するために一つ以上の残りのドライブを自動的に再構成するための例示的な論理を示す論理フロー図である。ブロック２４０２において、論理は、４つ以上の格納デバイスにわたる第１のストライピングパターンを、３つ以上の残りの格納デバイスにわたる第２のストライピングパターンに変換し得る。ブロック２４０４において、論理は、３つの格納デバイスにわたるストライピングパターンを、残りの２つの格納デバイスにわたるミラリングパターンに変換し得る。もちろん、論理は、ドライブの損失の後でデータを冗長に再レイアウトするために、他の方法でパターンを変換し得る。論理反復は、ブロック２４９９において終了する。
再び図２１を参照すると、格納マネージャ２５０４は、上述のような仮想ホットスペア機能をインプリメントするための適切なコンポーネントおよび論理を一般的に含む。
（動的アップグレード）
格納の動的な拡大および縮小を処理するための上述の論理は、動的にアップグレード可能なシステムを提供するように延長され得る。該システムにおいて、格納デバイスは必要に応じてより大きな格納デバイスと置き換えられ得、冗長性が維持または拡張されて、なおかつより大きな格納デバイスによって提供される追加の格納スペースが、複数の格納デバイスにわたる利用可能な格納スペースのプールに含まれるように、既存のデータが格納デバイスにわたって自動的に再構成される。したがって、より小さな格納デバイスがより大きな格納デバイスに置き換えられるときに、すでに格納されたデータの冗長性を改善するため、ならびに追加のデータを格納するために、追加の格納スペースが使用され得る。より多くの格納スペースが必要とされるときはいつでも、適切な信号がユーザに提供され（たとえば実質的に上述のような緑色／黄色／赤色のライトを使用して）、ユーザは単に格納デバイスを取り外し得、それをより大きな格納デバイスと置き換え得る。
図２６は、本発明の例示的な実施形態に従った、格納デバイスをアップグレードするための例示的な論理を示す論理フロー図である。ブロック２６０２において、論理は、第１の格納デバイスの上のデータを、その上に格納されたデータが他の格納デバイスの上で冗長に見えるように、格納する。ブロック２６０４において、論理は、第１の格納デバイスが、第１の格納デバイスよりも大きな格納容量を有する置換用デバイスと置き換えられたことを検出する。ブロック２６０６において、論理は、第１のデバイスの上に格納されたデータを、他のデバイスの上に冗長に格納されたデータを使用して、置換用デバイスの上に自動的に複写する。ブロック２６０８において、論理は、新しいデータを冗長に格納するために利用可能な置換用デバイスの上に、追加の格納スペースを作る。ブロック２６１０において、新しいデータに冗長性を提供するために利用可能な十分な量の格納容量を有するデバイスが他にない場合には、論理は、置換用デバイスの上の追加の格納スペースの中に、新しいデータを冗長に格納し得る。ブロック２６１２において、少なくとも一つの他のデバイスが、新しいデータに冗長性を提供するために利用可能な十分な量の格納容量を有する場合には、論理は、複数の格納デバイスにわたって新しいデータを冗長に格納し得る。
再び図２１を参照すると、格納マネージャ２５０４は、上述のような動的アップグレード機能をインプリメントするための適切なコンポーネントおよび論理を一般的に含む。
（その他）
本発明の実施形態は、本明細書において全体が参照により援用されている、Ｇｅｏｆｆｒｅｙ Ｓ．Ｂａｒｒａｌの名義で２００４年１１月５日に出願された米国仮特許出願第６０／６２５，４９５号に記述される態様で、周辺接続プロトコルを使用して、格納容量をホストコンピュータに提供するように使用され得る。
ハッシュアルゴリズムは、厳密に一意のハッシュ値を生成し得ないことが留意されるべきである。したがって、ハッシュアルゴリズムが、同一でないコンテンツを有するデータの２つのチャンクに対して、同じハッシュ値を生成することが考えられる。（ハッシュアルゴリズムを一般的に取り入れる）ハッシュ関数は、一意性を確認するメカニズムを一般的に含む。たとえば、上述のような本発明の例示的な実施形態において、一つのチャンクのハッシュ値が別のチャンクのハッシュ値と異なる場合には、これらのチャンクのコンテンツは同一でないと考えられる。しかし、一つのチャックのハッシュ値が別のチャンクのハッシュ値と同じである場合には、コンテンツが同一であるか同一でないかを決定するために、ハッシュ関数は、２つのチャンクのコンテンツを比較し得るか、または何らかの他のメカニズムを利用し得る（たとえば異なるハッシュ関数）。
論理フロー図は、本発明の種々の局面を示すために本明細書中で使用されるものであり、本発明を任意の特定の論理フローまたは論理インプリメンテーションに限定するものと解釈されるべきではないことが留意されるべきである。記載される論理は、全般的な結果を変化させることなく、またはさもなければ本発明の真の範囲から逸脱することなく、異なる論理ブロック（たとえば、プログラム、モジュール、機能、またはサブルーチン）に分割され得る。全般的な結果を変化させることなく、またはさもなければ本発明の真の範囲から逸脱することなく、しばしば、時間および論路要素が、追加され得、変更され得、省略され得、異なる順序で実行され得、または異なる論理構成を使用してインプリメントされ得る（たとえば、論理ゲート、ルーピング基本命令、条件付き論理、および他の論理構成）。
本発明は、プロセッサ（たとえば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）とともに使用するコンピュータプログラム、プログラム可能論理デバイスとともに使用するプログラマブルロジック（たとえば、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）（ＦＰＧＡ）、または他のＰＬＤ）、個別のコンポーネント、集積回路（たとえば、特定用途向けＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）（ＡＳＩＣ）、またはこれらの任意の組み合わせを含む任意の他の手段を含むが決してこれらに限定されない多くの異なる形で具体化され得る。
本明細書中にこれまで記載された機能性のすべてまたは一部をインプリメントするコンピュータプログラム論理は、ソースコードの形態、コンピュータ実行可能な形態、および種々の中間的な形態（たとえば、アセンブラ、コンパイラ、リンカ、またはロケータ）を含むが決してそれらに限定されない、種々の形において具体化され得る。ソースコードは、種々のオペレーティングシステムまたはオペレーティング環境とともに使用する、種々のプログラミング言語（たとえば、オブジェクトコード、アセンブリ言語、またはＦｏｒｔｒａｎ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、またはＨＴＭＬ）のいずれかにおいてインプリメントされる一連のコンピュータプログラム命令を含み得る。ソースコードは、種々のデータ構造および通信メッセージを定義および使用し得る。ソースコードはコンピュータ実行可能な形態（たとえば、インタプリタを介して）であり得、あるいはソースコードはコンピュータ実行可能な形態に変換され得る（たとえば、翻訳プログラム（ｔｒａｎｓｌａｔｏｒ）、アセンブラ、またはコンパイラを介して）。
コンピュータプログラムは、半導体メモリデバイス（たとえば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュプログラム可能ＲＡＭ）、磁気メモリデバイス（たとえばディスケットまたは固定ディスク）、光メモリデバイス（たとえば、ＣＤ−ＲＯＭ）、ＰＣカード（たとえば、ＰＣＭＣＩＡカード）、または他のメモリデバイスなどの有形の格納媒体において、永久的または一時的に、任意の形態（たとえば、ソースコードの形態、コンピュータ実行可能な形態、または中間的な形態）で固定され得る。コンピュータプログラムは、アナログテクノロジー、デジタルテクノロジー、光学テクノロジー、ワイヤレステクノロジー（たとえば、Ｂｌｕｅｔｏｏｔｈ）、ネットワーキングテクノロジー、およびインターネットワーキングテクノロジーを含むが決してそれらに限定されない、種々の通信テクノロジーのいずれかを使用してコンピュータに送信可能な信号における任意の形態に固定され得る。コンピュータプログラムは、付随する印刷文書または電子文書とともに取り外し可能な格納媒体（たとえば、シュリンクラップソフトウェア）として任意の形態で配布され得るか、コンピュータシステム（たとえば、システムＲＯＭまたは固定ディスクの上）に事前ロードされ得るか、または通信システム（たとえば、インターネットまたはワールドワイドウェブ）を介してサーバまたは電子掲示板から配信され得る。
本明細書中にこれまで記載された機能性のすべてまたは一部をインプリメントするハードウェア論理（プログラム可能論理デバイスとともに使用するプログラマブルロジックを含む）は、従来のマニュアル方法を使用して設計され得るか、あるいは計算機援用設計（Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ）（ＣＡＤ）、ハードウェア記述言語（たとえば、ＶＨＤＬまたはＡＨＤＬ）、またはＰＬＤプログラミング言語（たとえば、ＰＡＬＡＳＭ、ＡＢＥＬ、またはＣＵＰＬ）などの種々のツールを使用して、設計、キャプチャ、シミュレーション、または電子的文書化をされ得る。
プログラマブルロジックは、半導体メモリデバイス（たとえば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュプログラム可能ＲＡＭ）、磁気メモリデバイス（たとえば、ディスケットまたは固定ディスク）、光メモリデバイス（たとえば、ＣＤ−ＲＯＭ）、または他のメモリデバイスなどの、有形の格納媒体において、永久的または一時的に固定され得る。プログラマブルロジックは、アナログテクノロジー、デジタルテクノロジー、光学テクノロジー、ワイヤレステクノロジー（たとえば、Ｂｌｕｅｔｏｏｔｈ）、ネットワーキングテクノロジー、およびインターネットワーキングテクノロジーを含むが決してそれらに限定されない、種々の通信テクノロジーのいずれかを使用してコンピュータに送信可能な信号に固定され得る。プログラマブルロジックは、付随する印刷文書または電子文書とともに取り外し可能な格納媒体（たとえば、シュリンクラップ（ｓｈｒｉｎｋ ｗｒａｐｐｅｄ）ソフトウェア）として配布され得るか、コンピュータシステム（たとえば、システムＲＯＭまたは固定ディスクの上）に事前ロードされ得るか、または通信システム（たとえば、インターネットまたはワールドワイドウェブ）を介してサーバまたは電子掲示板から配信され得る。
本出願は、参照することによりそれらの全体が本願に組み込まれる、以下の米国特許出願に関連する。
代理人整理番号第２９５０／１０４号「Ｄｙｎａｍｉｃａｌｌｙ Ｕｐｇｒａｄｅａｂｌｅ Ｆａｕｌｔ−Ｔｏｌｅｒａｎｔ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｐｅｒｍｉｔｔｉｎｇ Ｖａｒｉｏｕｓｌｙ Ｓｉｚｅｄ Ｓｔｏｒａｇｅ Ｄｅｖｉｃｅｓ ａｎｄ Ｍｅｔｈｏｄ」、
代理人整理番号第２９５０／１０５号「Ｄｙｎａｍｉｃａｌｌｙ Ｅｘｐａｎｄａｂｌｅ ａｎｄ Ｃｏｎｔｒａｃｔｉｂｌｅ Ｆａｕｌｔ−Ｔｏｌｅｒａｎｔ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｗｉｔｈ Ｖｉｒｔｕａｌ Ｈｏｔ Ｓｐａｒｅ」、および
代理人整理番号第２９５０／１０７号「Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｃｏｎｄｉｔｉｏｎ Ｉｎｄｉｃａｔｏｒ ａｎｄ Ｍｅｔｈｏｄ」。
本発明は、本発明の真の範囲から逸脱することなく、他の特定の形において具体化され得る。記載された実施形態は、あらゆる点で、説明的なものとしてのみ考えられ、限定的なものとしては考えられない。
図１は、格納のためにオブジェクトが一連のチャンクに分析される、本発明の実施形態の図示である。 図２ａおよび図２ｂは、同じ実施形態において、より多くの格納デバイスの追加の結果として、チャンクのための故障許容格納のパターンがどのように動的に変化させられ得るかを図示する。 図２ａおよび図２ｂは、同じ実施形態において、より多くの格納デバイスの追加の結果として、チャンクのための故障許容格納のパターンがどのように動的に変化させられ得るかを図示する。 図３は、本発明のさらなる実施形態において、異なるサイズの格納デバイスを使用して構築された格納システムの上の異なる故障許容パターンにおけるチャンクの格納を図示する。 図４ａ、図４ｂおよび図４ｃは、非効率な格納の使用および低レベルの故障許容を警告するためにインジケータ状態が使用される、本発明の別の実施形態を図示する。 図４ａ、図４ｂおよび図４ｃは、非効率な格納の使用および低レベルの故障許容を警告するためにインジケータ状態が使用される、本発明の別の実施形態を図示する。 図４ａ、図４ｂおよび図４ｃは、非効率な格納の使用および低レベルの故障許容を警告するためにインジケータ状態が使用される、本発明の別の実施形態を図示する。 図５は、本発明の実施形態に従った、データの格納、検索および再レイアウトにおいて使用される機能性モジュールのブロック図である。 図６は、２つ以上のドライブを含むアレイにおいてミラリングが使用される例を示す。 図７は、異なるレイアウトスキームを使用してデータを格納するいくつかの例示的なゾーンを示す。 図８は、スパースボリュームをインプリメントするためのルックアップテーブルを示す。 図９は、本発明の例示的な実施形態に従った、利用可能な格納スペースを有し、かつ故障許容の方法で作動する、例示的なアレイのための、状態インジケータを示す。 図１０は、本発明の例示的な実施形態に従った、冗長データ格納を維持するために十分なスペースを有せず、より多くのスペースが追加されなければならない、例示的なアレイの状態インジケータを示す。 図１１は、本発明の例示的な実施形態に従った、故障の際に冗長データを維持することができ得ない例示的なアレイの状態インジケータを示す。 図１２は、本発明の例示的な実施形態に従った、格納デバイスが故障した例示的なアレイの状態インジケータを示す。スロットＢ、ＣおよびＤに、格納デバイスが配置されている。 図１３は、例示的な実施形態の異なるソフトウェアレイヤを表すモジュール階層と、それらが互いにどのように関係するかとを示す。 図１４は、本発明の例示的な実施形態に従って、ゾーンにおけるデータクラスタにアクセスするためにクラスタアクセステーブルがどのように使用されるかを示す。 図１５は、本発明の例示的な実施形態に従ったジャーナルテーブルアップデートを示す。 図１６は、本発明の例示的な実施形態に従ったドライブレイアウトを示す。 図１７は、本発明の例示的な実施形態に従った、ゾーン０のレイアウトと、他のゾーンがどのように参照されるかとを示す。 図１８は、本発明の例示的な実施形態に従った読み出しエラー処理を示す。 図１９は、本発明の例示的な実施形態に従った書き込みエラー処理を示す。 図２０は、本発明の例示的な実施形態に従った、エラーマネージャによる不良領域のバックアップを示す論理フロー図である。 図２１は、本発明の例示的な実施形態に従った格納アレイの関連コンポーネントを示す模式的なブロック図である。 図２２は、本発明の例示的な実施形態に従った、仮想ホットスペアを管理するための例示的な論理を示す論理フロー図である。 図２３は、本発明の例示的な実施形態に従った、図２２のブロック２１０２におけるような、それぞれのあり得るディスク故障について再レイアウトシナリオを決定するための例示的な論理を示す論理フロー図である。 図２４は、本発明の例示的な実施形態に従った、仮想ホットスペア機能を呼び出すための例示的な論理を示す論理フロー図である。 図２５は、本発明の例示的な実施形態に従った、図２４のブロック２３０６におけるような、データの故障許容を復元する一つ以上の残りのドライブを自動的に再構成するための例示的な論理を示す論理フロー図である。 図２６は、本発明の例示的な実施形態に従った、格納デバイスをアップグレードするための例示的な論理を示す論理フロー図である。 図２７は、本発明の例示的実施形態に従った、コンピュータシステムの概念ブロック図である。 図２８は、本発明の例示的実施形態に従った、ファイルシステム認識格納制御装置の高レベル論理フロー図である。 図２９は、本発明の例示的実施形態に従った、ホストファイルシステムデータ構造の場所を突き止めるための論理フロー図である。 図３０は、本発明の例示的実施形態に従った、未使用格納スペースを再利用するための論理フロー図である。 図３１は、本発明の例示的実施形態に従った、データ型に基づいてユーザデータの格納を管理するための論理フロー図である。 図３２は、本発明の例示的実施形態に従った、スカベンジャの関連構成要素を示す略ブロック図である。 図３３は、本発明の例示的実施形態に従った、ホストファイルシステムビットマップの場所を突き止めるための疑似コードである。 図３４は、本発明の例示的実施形態に従った、ＢＢＵＭに対する高レベル疑似コードである。 図３５は、本発明の例示的実施形態に従った、新しいパーティションを作成するＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。 図３６は、本発明の例示的実施形態に従った、パーティションを（再）フォーマットするＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。 図３７は、本発明の例示的実施形態に従った、パーティションを削除するＬＢＡ０アップデートの同期処理に対する高レベル疑似コードである。 図３８は、本発明の例示的実施形態に従った、非同期タスクに対する高レベル疑似コードである。

Claims (22)

  1. ホストファイルシステムの制御下でデータを格納するブロックレベル格納システムによってデータを格納する方法であって、
    該ホストファイルシステムに対して格納されたホストファイルシステムデータ構造の場所を該ブロックレベル格納システム中で突き止めることと、
    格納される該データと関連するデータ型を特定するために該ホストファイルシステムデータ構造を分析することと、
    該データ型に基づいて選択された格納スキームを使用して該データを格納することとを包含し、
    それにより、異なるデータ型を有するデータは、該データ型に基づいて選択された異なる格納スキームを使用して格納することが可能である、方法。
  2. 前記データ型に基づいて選択された格納スキームを使用して前記データを格納することは、該データ型に基づいて選択された格納レイアウトを使用して該データを格納することを包含する、請求項１に記載の方法。
  3. 前記データ型に基づいて選択された格納レイアウトを使用して前記データを格納することは、強化されたアクセスのしやすさを提供するようにアクセス頻度の高いデータを格納することを包含する、請求項２に記載の方法。
  4. 強化されたアクセスのしやすさを提供するようにアクセス頻度の高いデータを格納することは、前記アクセス頻度の高いデータを圧縮せず、かつシーケンシャル格納で格納することを包含する、請求項３に記載の方法。
  5. 前記データ型に基づいて選択された格納レイアウトを使用して前記データを格納することは、強化された格納効率を提供するようにアクセス頻度の低いデータを格納すること
    を包含する、請求項２に記載の方法。
  6. 強化された格納効率を提供するようにアクセス頻度の低いデータを格納することは、
    データ圧縮およびノンシーケンシャル格納のうちの少なくとも１つを使用して前記アクセス頻度の低いデータを格納することを包含する、請求項５に記載の方法。
  7. 前記データ型に基づいて選択された格納スキームを使用して前記データを格納することは、該データ型に基づいて選択された符号化スキームを使用して該データを格納することを包含する、請求項１に記載の方法。
  8. 前記符号化スキームは、データ圧縮と、暗号化とのうちの少なくとも１つを包含する、請求項７に記載の方法。
  9. ホストファイルシステムデータ構造の場所を格納中で突き止めることは、
    パーティションテーブルを維持することと、
    オペレーティングシステムパーティションの場所を突き止めるために該パーティションテーブルを解析することと、
    前記オペレーティングシステムを特定し、オペレーティングシステムデータ構造の場所を突き止めるために該オペレーティングシステムパーティションを解析することと、
    前記ホストファイルシステムを特定し、前記ホストファイルシステムデータ構造の場所を突き止めるために該オペレーティングシステムデータ構造を解析することと
    を包含する、請求項１に記載の方法。
  10. 前記オペレーティングシステムデータ構造は、スーパーブロックを含み、かつ該オペレーティングシステムデータ構造を解析することは、該スーパーブロックを解析することを含む、請求項９に記載の方法。
  11. 前記ホストファイルシステムデータ構造を解析することは、ホストファイルシステムデータ構造のワーキングコピーを作成することと、該ワーキングコピーを解析することとを備える、請求項９に記載の方法。
  12. ホストファイルシステムの制御下でデータを格納するブロックレベル格納システムであって、
    ホストファイルシステムデータ構造が該ホストファイルシステムに対して格納される、ブロックレベル格納と、
    該ブロックレベル格納に動作可能に連結された格納制御装置であって、
    該ブロックレベル格納に格納された該ホストファイルシステムデータ構造の場所を突き止め、
    格納される該データと関連するデータ型を特定するために該ホストファイルシステムデータ構造を分析し、
    該データ型に基づいて選択された格納スキームを使用して該データを格納する、
    格納制御装置と
    を備え、
    それにより、異なるデータ型を有するデータは、該データ型に基づいて選択された異なる格納スキームを使用して格納することが可能である、システム。
  13. 前記格納制御装置は、動作可能に連結され、前記データ型に基づいて選択された格納レイアウトを使用して該データを格納する、請求項１２に記載のシステム。
  14. 前記格納制御装置は、強化されたアクセスのしやすさを提供するために、アクセス頻度の高いデータを格納するように動作可能に連結される、請求項１３に記載のシステム。
  15. 前記格納制御装置は、前記アクセス頻度の高いデータを圧縮せず、かつシーケンシャル格納で格納するように動作可能に連結される、請求項１４に記載のシステム。
  16. 前記格納制御装置は、強化された格納効率を提供するために、アクセス頻度の低いデータを格納するように動作可能に連結される、請求項１３に記載のシステム。
  17. 前記格納制御装置は、データ圧縮およびノンシーケンシャル格納のうちの少なくとも１つを使用してアクセス頻度の低いデータを格納するように動作可能に連結される、請求項１６に記載のシステム。
  18. 前記格納制御装置は、前記データ型に基づいて選択された符号化スキームを使用して前記データを格納するように動作可能に連結される、請求項１２に記載のシステム。
  19. 前記符号化スキームは、データ圧縮と、暗号化とのうちの少なくとも１つを備える、請求項１８に記載のシステム。
  20. 前記格納制御装置は、
    パーティションテーブルを維持し、
    オペレーティングシステムパーティションの場所を突き止めるために該パーティションテーブルを解析し、
    オペレーティングシステムを特定してオペレーティングシステムデータ構造の場所を突き止めるために該オペレーティングシステムパーティションを解析し、
    前記ホストファイルシステムを特定して前記ホストファイルシステムデータ構造の場所を突き止めるために該オペレーティングシステムデータ構造を解析し、
    前記データ型を特定するために前記ホストファイルシステムデータ構造を解析する
    ように動作可能に連結される、請求項１２に記載のシステム。
  21. 前記オペレーティングシステムデータ構造は、スーパーブロックを含み、かつ格納制御装置は、前記スーパーブロックを解析するように動作可能に連結される、請求項２０に記載のシステム。
  22. 前記格納制御装置は、ホストファイルシステムデータ構造のワーキングコピーを作成し、前記ワーキングコピーを解析するように動作可能に連結される、請求項２０に記載のシステム
JP2009510073A 2006-05-03 2007-05-03 ファイルシステム認識ブロック格納システム、装置、および方法 Expired - Fee Related JP4954277B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US79712706P 2006-05-03 2006-05-03
US60/797,127 2006-05-03
PCT/US2007/068139 WO2007128005A2 (en) 2006-05-03 2007-05-03 Filesystem-aware block storage system, apparatus, and method

Publications (3)

Publication Number Publication Date
JP2009536414A true JP2009536414A (ja) 2009-10-08
JP2009536414A5 JP2009536414A5 (ja) 2011-11-04
JP4954277B2 JP4954277B2 (ja) 2012-06-13

Family

ID=38610547

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009510073A Expired - Fee Related JP4954277B2 (ja) 2006-05-03 2007-05-03 ファイルシステム認識ブロック格納システム、装置、および方法

Country Status (7)

Country Link
EP (2) EP2372520B1 (ja)
JP (1) JP4954277B2 (ja)
KR (1) KR101362561B1 (ja)
CN (1) CN101501623B (ja)
AU (1) AU2007244671B9 (ja)
CA (1) CA2651757A1 (ja)
WO (1) WO2007128005A2 (ja)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8386537B2 (en) * 2009-12-15 2013-02-26 Intel Corporation Method for trimming data on non-volatile flash media
KR101656102B1 (ko) * 2010-01-21 2016-09-23 삼성전자주식회사 컨텐츠 파일 생성/제공 장치 및 방법
CN102622184A (zh) * 2011-01-27 2012-08-01 北京东方广视科技股份有限公司 数据存储***和方法
CN102270161B (zh) * 2011-06-09 2013-03-20 华中科技大学 一种基于纠删码的多等级容错数据存储、读取和恢复方法
KR102147359B1 (ko) 2012-06-29 2020-08-24 삼성전자 주식회사 비휘발성 메모리 장치의 관리 방법 및 비휘발성 메모리 장치
US20140129526A1 (en) 2012-11-06 2014-05-08 International Business Machines Corporation Verifying data structure consistency across computing environments
GB2527529B (en) * 2014-06-24 2021-07-14 Advanced Risc Mach Ltd A device controller and method for performing a plurality of write transactions atomically within a non-volatile data storage device
KR101744685B1 (ko) * 2015-12-31 2017-06-09 한양대학교 산학협력단 파일의 메타데이터에 대한 보호 방법 및 보호 장치
US10126962B2 (en) * 2016-04-22 2018-11-13 Microsoft Technology Licensing, Llc Adapted block translation table (BTT)
CN108062200B (zh) * 2016-11-08 2019-12-20 杭州海康威视数字技术股份有限公司 一种磁盘数据读写方法及装置
US11301433B2 (en) * 2017-11-13 2022-04-12 Weka.IO Ltd. Metadata journal in a distributed storage system
CN107885492B (zh) * 2017-11-14 2021-03-12 中国银行股份有限公司 主机中数据结构动态生成的方法及装置
CN110019097B (zh) * 2017-12-29 2021-09-28 ***通信集团四川有限公司 虚拟逻辑副本管理方法、装置、设备及介质
KR102090374B1 (ko) * 2018-01-29 2020-03-17 엄희정 Gpu를 이용한 파일 시스템 레벨 암호화 장치 및 방법
CN108829345B (zh) * 2018-05-25 2020-02-21 华为技术有限公司 日志文件的数据处理方法和终端设备
KR20200035592A (ko) * 2018-09-27 2020-04-06 삼성전자주식회사 스토리지 장치의 구동 방법, 이를 수행하는 스토리지 장치 및 이를 포함하는 스토리지 시스템
TWI682296B (zh) * 2018-12-06 2020-01-11 啓碁科技股份有限公司 映像檔打包方法及映像檔打包系統
CN109783398B (zh) * 2019-01-18 2020-09-15 上海海事大学 一种基于相关感知页面级ftl固态硬盘性能优化方法
US10809927B1 (en) 2019-04-30 2020-10-20 Microsoft Technology Licensing, Llc Online conversion of storage layout
CN110532262B (zh) * 2019-07-30 2021-02-05 北京三快在线科技有限公司 一种数据存储规则自动推荐方法、装置、设备及可读存储介质
US11347698B2 (en) * 2019-10-04 2022-05-31 Target Brands, Inc. Garbage collection for hash-based data structures
CN110750495A (zh) * 2019-10-14 2020-02-04 Oppo（重庆）智能科技有限公司 文件管理方法、装置、存储介质以及终端
CN112804071A (zh) * 2019-11-13 2021-05-14 中兴通讯股份有限公司 在线升级方法、升级文件提供方法、设备及存储介质
KR20210108749A (ko) 2020-02-26 2021-09-03 삼성전자주식회사 가속기, 가속기의 동작 방법 및 이를 포함한 가속기 시스템
CN113535942B (zh) * 2021-07-21 2022-08-19 北京海泰方圆科技股份有限公司 一种文本摘要生成方法、装置、设备及介质
CN113934691B (zh) * 2021-12-08 2022-05-17 荣耀终端有限公司 访问文件的方法、电子设备及可读存储介质
CN114691698B (zh) * 2022-04-24 2022-11-08 山西中汇数智科技有限公司 一种计算机***的数据处理***及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0695955A (ja) * 1992-09-09 1994-04-08 Ricoh Co Ltd フラッシュ・ファイル・システム
WO2001024010A1 (fr) * 1999-09-29 2001-04-05 Hitachi, Ltd. Procede de partage de fichiers et systeme de stockage
JP2004295457A (ja) * 2003-03-27 2004-10-21 Hitachi Ltd 記憶装置
JP2005122439A (ja) * 2003-10-16 2005-05-12 Sharp Corp デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6606651B1 (en) * 2000-05-03 2003-08-12 Datacore Software Corporation Apparatus and method for providing direct local access to file level data in client disk images within storage area networks
US20020161982A1 (en) * 2001-04-30 2002-10-31 Erik Riedel System and method for implementing a storage area network system protocol
US20040078641A1 (en) * 2002-09-23 2004-04-22 Hewlett-Packard Company Operating system-independent file restore from disk image
US7523140B2 (en) 2004-03-01 2009-04-21 Sandisk Il Ltd. File system that manages files according to content
US7603532B2 (en) * 2004-10-15 2009-10-13 Netapp, Inc. System and method for reclaiming unused space from a thinly provisioned data container

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0695955A (ja) * 1992-09-09 1994-04-08 Ricoh Co Ltd フラッシュ・ファイル・システム
WO2001024010A1 (fr) * 1999-09-29 2001-04-05 Hitachi, Ltd. Procede de partage de fichiers et systeme de stockage
JP2004295457A (ja) * 2003-03-27 2004-10-21 Hitachi Ltd 記憶装置
JP2005122439A (ja) * 2003-10-16 2005-05-12 Sharp Corp デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法

Also Published As

Publication number Publication date
EP2372520B1 (en) 2014-03-19
EP2024809A2 (en) 2009-02-18
EP2372520A1 (en) 2011-10-05
CN101501623B (zh) 2013-03-06
AU2007244671A1 (en) 2007-11-08
WO2007128005A2 (en) 2007-11-08
WO2007128005A3 (en) 2008-01-24
AU2007244671A2 (en) 2009-01-08
KR101362561B1 (ko) 2014-02-13
JP4954277B2 (ja) 2012-06-13
KR20090009300A (ko) 2009-01-22
AU2007244671B2 (en) 2012-12-13
CA2651757A1 (en) 2007-11-08
CN101501623A (zh) 2009-08-05
AU2007244671B9 (en) 2013-01-31

Similar Documents

Publication Publication Date Title
JP4954277B2 (ja) ファイルシステム認識ブロック格納システム、装置、および方法
JP5116151B2 (ja) 仮想ホットスペアを用いて動的に拡張可能かつ縮小可能な故障許容格納システム
US7873782B2 (en) Filesystem-aware block storage system, apparatus, and method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100316

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110314

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110912

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20110916

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20111005

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111007

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20120106

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20120116

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120213

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120313

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150323

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees