JP2014525073A - エクステント・ベース・アーキテクチャにおける重複排除 - Google Patents
エクステント・ベース・アーキテクチャにおける重複排除 Download PDFInfo
- Publication number
- JP2014525073A JP2014525073A JP2014516967A JP2014516967A JP2014525073A JP 2014525073 A JP2014525073 A JP 2014525073A JP 2014516967 A JP2014516967 A JP 2014516967A JP 2014516967 A JP2014516967 A JP 2014516967A JP 2014525073 A JP2014525073 A JP 2014525073A
- Authority
- JP
- Japan
- Prior art keywords
- extent
- entry
- reference count
- log data
- donor
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1748—De-duplication implemented within the file system, e.g. based on file segments
-
- 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/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/064—Management of blocks
- G06F3/0641—De-duplication techniques
-
- 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/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
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)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
重複データを除去するリクエストを受け取る。ストレージ・サーバ内のストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスする。ログ・データ・コンテナは複数のエントリを含んでいる。各エントリはストレージ・サーバと関係づけられたボリュームに格納されたデータ構造内のエクステント識別子により識別される。ログ・データ・コンテナの各エントリについて、エントリがログ・データ・コンテナ内の別のエントリと一致するか判断する。エントリがログ・データ・コンテナ内の別のエントリと一致すれば、ドナー・エクステントとレシピエント・エクステントとを決定する。レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第1所定値と等しければ、ドナー・エクステントおよびレシピエント・エクステントについてブロック共有を行う。ドナー・エクステントのリファレンス・カウントが第2所定値と等しいか判断する。ドナー・エクステントのリファレンス・カウントが第2所定値と等しければ、ドナー・エクステントを解放する。
Description
本発明は、一般に、データ・ストレージ・システムに関し、特に、エクステント・ベース・データ・ストレージ・システム(extent-based data storage system)における重複排除(deduplication)に関する。
著作権表示/許諾
この特許文献の開示は一部、著作権にもとづく保護の対象となる内容を含んでいる。著作権者は、何者かによる、特許商標庁のファイルまたは記録に記されているとおりの本特許ドキュメントおよび特許情報の開示(patent disclosure)の複製(facsimile reproduction)についてこれに異存がない。だが、そのような場合を除き著作権者はいかなる著作権についてもこれを留保する。次の表示 Copyright (C) 2011, NetApp, Inc., All Rights Reserved (著作権(C)2011、ネットアップ・インコーポレーテッド、著作権所有)は、以下に記載・添付の図面に示されるソフトウェアおよびデータに適用される。
この特許文献の開示は一部、著作権にもとづく保護の対象となる内容を含んでいる。著作権者は、何者かによる、特許商標庁のファイルまたは記録に記されているとおりの本特許ドキュメントおよび特許情報の開示(patent disclosure)の複製(facsimile reproduction)についてこれに異存がない。だが、そのような場合を除き著作権者はいかなる著作権についてもこれを留保する。次の表示 Copyright (C) 2011, NetApp, Inc., All Rights Reserved (著作権(C)2011、ネットアップ・インコーポレーテッド、著作権所有)は、以下に記載・添付の図面に示されるソフトウェアおよびデータに適用される。
背景
今日、ネットワーク・ベースのストレージ・システム(network-based storage systems)には、様々な形態が存在する。これらには、ネットワークアタッチトストレージ(network attached storage)(NAS)、ストレージエリアネットワーク(storage area networks)(SAN’s)などが含まれる。通例、ネットワーク・ベースのストレージ・システムの利用目的は様々である。例えば、複数のユーザに対し共有データに対するアクセスを与えたり、(データのミラーリングすることにより)大切なデータをバックアップしたり、といった用途に用いられる。
今日、ネットワーク・ベースのストレージ・システム(network-based storage systems)には、様々な形態が存在する。これらには、ネットワークアタッチトストレージ(network attached storage)(NAS)、ストレージエリアネットワーク(storage area networks)(SAN’s)などが含まれる。通例、ネットワーク・ベースのストレージ・システムの利用目的は様々である。例えば、複数のユーザに対し共有データに対するアクセスを与えたり、(データのミラーリングすることにより)大切なデータをバックアップしたり、といった用途に用いられる。
ネットワーク・ベースのストレージ・システムは、通例、少なくとも1つのストレージ・サーバを備え、このサーバが処理システム(processing system)となって、1つまたは複数のクライアント処理システム(client processing system)(クライアント(clients))に代わってデータの格納(store)および読み出し(retrieve)を行う。NASに関し、ストレージ・サーバは、ファイル・サーバでよく、このサーバは時折、「ファイラ(filer)」と呼ばれる。ファイラは、1つまたは複数のクライアントの代わりに共有ファイル(shared file)を格納し管理(manage)するための動作を行う。ファイルは、レイド(RAID)(リダンダント・アレイ・オブ・インエクスペンシブ・ディスクズ(Redundant Array of Inexpensive Disks))といったデータ格納スキームを用いて、1つまたは複数の、磁気もしくは光学ディスクまたはテープといった大容量(マス)ストレージ・デバイス(mass storage devices)のアレイを備えるストレージ・システムに格納されればよい。さらに、各アレイの大容量ストレージ・デバイスは、1つまたは複数の別個のRAIDグループに組織されてよい。SANに関し、ストレージ・サーバは、格納されているデータに対する、ファイル・レベルのアクセスでない、ブロック・レベルでのアクセスをクライアントに提供する。カリフォルニア州サニーヴェイルのネットアップ・インコーポレーテッド(NetApp(登録商標))が製作している特定のストレージ・サーバのような、ある種のストレージ・サーバであれば、ファイル・レベルのアクセスと、ブロック・レベルのアクセスとの両方を、クライアントに提供することも可能である。
図1は先行技術例としてのライト・エニウェア・ファイル・レイアウト(Write Anywhere File Layout)(WAFL)ファイルシステムの実施例を示す。図1を参照すると、WAFLアグリゲート100は、WAFLファイルシステムのインスタンスである。WAFLアグリゲート100は、1つまたは複数のフレキシブル・ボリューム110と、1つまたは複数のボリューム・コンテナ120と、物理ストレージ130と、を備える。
WAFLアグリゲート100は、WAFLファイルシステムでデータを格納することができる物理ストレージ・コンテナである。フレキシブル・ボリューム110は、物理ストレージ130上においてボリュームのアロケーションの仮想化を可能にする論理ボリュームである。これにより、従属的に管理されるフレキシブル・ボリューム110は、同一の物理ストレージ(例えば、物理ストレージ130)を共有することができる。物理ストレージ130に格納されたデータにアクセスするために、この仮想化では、フレキシブル・ボリューム110が使用する仮想ボリュームのブロックナンバー(VVBNs)と、WAFLアグリゲート100が使用する物理ボリュームのブロックナンバー(PVBNs)とのマッピングが必要である。本明細書では、PVBNは、アグリゲート(集合体)内の線的な単一のシークエンス(a single linear sequence)に抽象化されたディスクのブロックを指す。ボリューム・コンテナ120は、それぞれ、フレキシブル・ボリューム110と対応する。ボリューム・コンテナ120は、対応するフレキシブル・ボリューム110に関する全てのデータ・ブロックを含んでいる。
本明細書では、ブロック・オフセット、または、オフセットは、ボリューム、ファイル、エクステント等といったストレージのオブジェクトの始まりからの(from beginning)ブロック単位での距離(a distance in blocks)を指す。フレキシブル・ボリューム110内で用いられるブロック・アドレスは、ボリューム・コンテナ120内でのブロック・オフセットを指す。ボリューム・コンテナ120は、フレキシブル・ボリューム110内のあらゆるブロックを含むため、特定のブロックのロケーション(位置)の参照には2通りの方法がある。PVBNは、WAFLアグリゲート100内でのブロックのロケーションを規定する。VVBNは、コンテナ・ファイル内でのブロックのオフセットを規定する。あるファイルの中のあるブロックが要求(リクエスト)されると、フレキシブル・ボリューム110は、ファイルのオフセットを、VVBNにトランスレート(変換)する。VVBNは、フレキシブル・ボリューム110からボリューム・コンテナ120へ渡される(パスされる)。ボリューム・コンテナ120は、VVBNを、PVBNへトランスレートする。そして、PVBNが用いられて物理ストレージ130内のリクエストされたブロックにアクセスする。また、PVBNが初めて(initially)書き込まれるときは、フレキシブル・ボリューム110内のPVBNに対するブロック・ポインタが、VVBNについてのPVBNを(例えばキャッシュに)収録(include)するようにして、書き込まれる。そうすることで、リクエストされたブロックを必要とするときに、フレキシブル・ボリューム110は、格納されたPVBNを用いて物理ストレージ130にアクセスすることが可能になる。
現行のWAFLの実装では、ファイルは、間接的なブロック(indirect blocks)のツリーとして定義される。ツリーに含まれる間接的なブロックはそれぞれが固定的な長さ(スパン、span)を有し、これは、固定された数のエントリ(entries)であって、それぞれがツリーに含まれる別のブロックをポイントする。その規模(エクステント、extents)は、当該エクステントに含まれるブロックそれぞれのエントリを用いて表現される。本明細書では、エクステント(extent)は、1つまたは複数の隣接するブロックからなるグループ(a contiguous group of one or more blocks)を指す。結果的には、間接的なブロックのメタデータの量(アマウント、amount)がファイルのサイズに比例(linear)する。また、セグメントのクリーニング(segment cleaning)やファイルの再割り当て(ファイル・リアロケーション、file reallocation)といったディスク・ガーデニング(disk gardening)の技術は、VVBNブロックにおけるPVBNポインタをキャッシュするため、複雑である。
ストレージ・システムは、しばしば、全ての内的操作(internal operations)に予め定めたブロックサイズを用いる。ちょうど、クライアント側(client-side)のファイルシステム(file system)が、ファイル・ブロック数(ファイル・ブロック・ナンバー、file block numbers)(FBN)についてするように、例えば、WAFLは、VVBNおよびPVBNの両方について4KBの(例えば4096バイトの)ブロックを用いる。ブロックの境界(ブロック・バウンダリ、block boundaries)は、最初のオフセット(例えば、FBN 0)から、4KB毎に生じることが予想される。ファイルシステムは通例、個々のファイルのブロック・バウンダリに基づいて個々のファイルのオフセットを設けるため、アプリケーションの書き込み手段(ライタ、writers)は、ファイルシステムのブロックサイズおよび配置(アラインメント)を巧みに利用して入出力(「I/O」)のための操作のパフォーマンスを向上させている。例えば、常時、4KBの倍数でI/O操作を行ったり、常時、それらの操作をファイルの開始部(beginning)に合わせたりしている。仮想マシン(ヴァーチャル・マシン、virtual machine)のような他のファイルシステムやアプリケーションでは、異なるサイズのブロック・バウンダリを用いることも可能である。(例えば、仮想マシン環境においては、512バイトからなる初期マスター・ブート・レコード・ブロックの後に4KBのブロックが複数続く。)これによってFBNのそれとPVBNのそれとの間にずれ(ミスアラインメント、misalignment)が発生する。また、複数の仮想マシンが、単一のボリューム・コンテナ120を共有することも可能であるから、個々の仮想マシンにおいて異なる大きさのずれが生じる可能性がある。
ストレージ・サーバは、重複排除アルゴリズム(デダプリケーション・アルゴリズム、deduplication algorithm)を実装可能である。デダプリケーションによりデータ・ストレージ内に格納された冗長なデータのコピーが解消される。デダプリケーションは、様々な方法で実行される。その中には、階層的重複排除(hierarchical deduplication)、インライン重複排除(in-line deduplication)、バックグラウンド重複排除(background deduplication)が含まれる。
階層的重複排除には、別のファイルから或るファイルを得る過程を含んでいる。通例、ファイルが他方のコピーとして始まっているファイルを用いるが、ゼロのバイトあるいはほぼゼロのバイト群のデータも実際にコピーされたり移動されたりする。その代わり、2つのファイルが、データ・ストレージ内の同じブロックを共有する。その例としてはスナップショット(snapshot)がある。スナップショットは、ファイルシステムで構成されており、スナップショットが作成された時点においてスナップショットと動作中のファイルシステムとは同じであって同一のデータ・ストレージを共有する。よって、データの移動をゼロまたはほぼゼロのままに抑えつつ効率よくコピーされる。もとの(ソースとなった、source)ファイルシステムが変更されると、データ・ストレージにおいて共有されるブロックの数は減少する。この例は、ファイルシステムを取り込む、書き込み可能スナップショット(writable snapshot)である(クローン(clone)とも称される)。この例では、ソースのファイルシステムおよびクローンのファイルシステムが変更を受けるにつれ、共有されるブロックが減少する。
インライン重複排除は、書き込み操作によりコンテントを作成するストレージ・アクセス・プロトコル・イニシエータ(storage access protocol initiator)(例えば、NFSクライアント)を備え、ストレージ・アクセス・プロトコルのターゲットは、書き込まれようとしているコンテントが、ターゲットのストレージ上のどこか別の場所と重複しているかどうか、をチェックする。もし重複しているならば、データは書き込まれない。あるいは、(例えば、メタデータ、ポインタ等のような)論理コンテント(logical content)が当該重複に言及する。
バックグラウンド重複排除は、重複ブロックをスキャンし、1つを除く全ての重複を解放し(freeing)、これから解放するブロックから残っている重複への対応するポインタ(またはその他の論理コンテント)のマッピングを行う、(ストレージ・アクセス・プロトコルのターゲットに対する)バックグラウンド・タスクを備える。
しかしながら、現行の重複排除アルゴリズムでは、データ・ストレージの共有は可能であるものの、システムのパフォーマンスに対するインパクトがある。なぜなら、データを受け取ると処理を行わなければならないからである。加えて、動作中のファイルシステムが使用するメタデータおよびスナップショットについての重複排除はなされない。そのため、動作中のファイルシステムおよびスナップショットの空間効率を最大化するには至らない。
エクステント・ベース・アーキテクチャ(extent-based architecture)における重複排除は、重複データ(duplicate data)の除去(リムーブ、remove)にかかるリクエストを受けて実行される。ストレージ・サーバ内のストレージ・ボリューム(storage volume)と関連づけされたログ・データ・コンテナ(log data container)がアクセスされる。ログ・データ・コンテナは、複数のエントリ(entries)を含んでいる。各エントリは、ストレージ・サーバと関連づけされたボリューム内に格納されたデータ・ストラクチャ(data structure)のエクステント識別子(エクステント・アイデンティファイア、extent identifier)により特定される。ログ・データ・コンテナの各エントリについて、エントリがログ・データ・コンテナ内の別のエントリと一致(マッチ、matches)するかどうか、判断される。もし、当該エントリが、ログ・データ・コンテナ内の別のエントリと一致しているなら、提供者エクステント(ドナー・エクステント、donor extent)および被提供者エクステント(レシピエント・エクステント、recipient extent)が決定される。もしレシピエント・エクステントに関連づけされた外部参照カウント(エクスターナル・リファレンス・カウント、external reference count)が予め定められた第1の値に等しいならば、当該ドナー・エクステントおよびレシピエント・エクステントの間でブロック共有(ブロック・シェアリング、block sharing)が実行される。ドナー・エクステントにかかる上記のリファレンス・カウントが予め定められた第2の値と等しいかどうか、判断される。もし、ドナー・エクステントのリファレンス・カウントが、当該予め定められた第2の値と等しいならば、当該ドナー・エクステントは解放される。
本発明は、添付図面の図により例示的に説明されるものであって、それらに限定されない。
以下の本発明の実施形態にかかる詳細な説明においては、添付の図面を参照する。該図面においては、類似の要素に同様の参照記号を付す。また、該図面は、本発明を実施することが可能な特定の実施形態を例示するものである。これらの実施形態については、当業者が本発明を実施するのに十分な程度に詳細に説明される。だが、その他の実施形態や、論理的、機械的、電気的、機能的な変更、および、その他の変更も、本発明の範囲を逸脱することなく実施することができる。それゆえ、以下の詳細な説明を限定的な意味に捉えることは適当でなく、本発明の範囲はクレームによってのみ規定される。
実施形態では、エクステント・ベース・アーキテクチャにおける重複排除について記載する。本明細書中の「ある実施形態」、「ある1つの実施形態」等といった言及は、記載された特定の特徴、構造、特性が本発明の少なくとも1つの実施形態に含まれることを意味する。上述の文言は、本明細書においては、必ずしも同一の実施形態を指すものではなく、相互排他的(mutually exclusive)でもない。
エクステント・ベース・アーキテクチャにおける重複排除は、ストレージ・サーバ中の重複データを除去する要求(リクエスト)を受けて実行される。ストレージ・サーバ内のストレージ・ボリュームに関連づけされたログ・データ・コンテナがアクセスされる。ログ・データ・コンテナには、複数のエントリが含まれている。各エントリは、ストレージ・サーバと関連づけされたボリュームに格納されたデータ・ストラクチャ内のエクステント識別子(エクステント・アイデンティファイア、extent identifier)により識別される。ログ・データ・コンテナ内の各エントリに関し、当該ログ・データ・コンテナ内の別のエントリと一致するかどうかが判断される。エントリが、ログ・データ・コンテナ内の別のエントリと一致すれば、提供者エクステント(ドナー・エクステント)および被提供者エクステント(レシピエント・エクステント)が決定される。レシピエント・エクステントと関連づけされた外部参照カウント(エクスターナル・リファレンス・カウント)が、予め定められた第1の値と等しいならば、ドナー・エクステントおよびレシピエント・エクステントについて、ブロック共有(ブロック・シェアリング)が実行される。ドナー・エクステントのリファレンス・カウントが、予め定められた第2の値と等しいかどうかが判断される。ドナー・エクステントのリファレンス・カウントが、予め定められた第2の値と等しければ、当該ドナー・エクステントは解放される(freed)。エクステント・ベース・アーキテクチャにおける重複排除は、データの到来に対しインラインで実行される必要はない。それゆえ、エクステント・ベース・アーキテクチャにおける重複排除は、データが書き込まれた後で実行される。また、エクステントといった、当該データに付随するメタデータについても重複排除可能であり、よって、さらなるスペース効率(space efficiency)の向上が可能である。
図2Aは、ある1つの実施形態により重複排除が実装されたネットワーク・ストレージ・システムの図である。ストレージ・サーバ210(ストレージ・サーバ210A,210B)はそれぞれ、複数の、大容量ストレージ・デバイスを擁するストレージ・ユニット(ストレージ270A,270B)を管理する。これらストレージ・サーバは、1つまたは複数のクライアント202に対し、ネットワーク230を介してストレージ・サービスを提供する。ネットワーク230は、例えば、ローカル・エリア・ネットワーク(LAN)、ワイド・エリア・ネットワーク(WAN)、メトロポリタン・エリア・ネットワーク(MAN)、インターネットのようなグローバル・エリア・ネットワーク、ファイバーチャネルのファブリック、あるいは、これらの相互接続からなる結合体、でよい。各クライアント202は、例えば、従来型のパーソナル・コンピュータ(PC)、サーバクラスのコンピュータ、ワークステーション、ハンドヘルド型のコンピューティングもしくは通信のためのデバイス、その他の専用もしくは汎用コンピュータ、でよい。
ストレージ・ユニット270におけるデータの格納(ストレージ)は、ストレージ・サーバ210によって管理される。ストレージ・サーバ210は、ストレージ・ユニット270に格納されているデータもしくは格納されるべきデータに対するクライアントからの様々な読み出しおよび書き込み要求(リード・リクエストおよびライト・リクエスト)を受け、これに答える。ストレージ・ユニット270は、大容量ストレージ・デバイスを構成する。大容量ストレージ・デバイスは、例えば、フラッシュ・メモリ、磁気もしくは光学ディスク、または、テープ・ドライブ、を含むことができ、ディスク271(271A,271B)として示される。ストレージ・デバイス271は、さらに、(図示しない)アレイ状に組織化されてレイド・スキーム(Redundant Array of Inexpensive Disks/Devices scheme、RAID scheme)を実装することも可能であり、そうすることにより、ストレージ・サーバ210は、当技術分野において周知の1つまたは複数のRAIDプロトコルを用いてストレージ・ユニット270にアクセスする。
ストレージ・サーバ210は、ネットワークアタッチトストレージ(NAS)環境で用いられるようなファイル・レベルのサービスや、ストレージエリアネットワーク(SAN)環境で用いられるようなブロック・レベルのサービスや、ファイル・レベルおよびブロック・レベルのサービスの両方を提供可能なサービスや、別のデータ・アクセス・サービスを提供可能な他のサービスを、提供可能である。図2Aにおいては、ストレージ・サーバ210は、それぞれ単一のユニットのように示されているが、別の実施形態においては、ストレージ・サーバは、別個のネットワーク要素もしくはモジュール(「N−モジュール」)ならびにディスク要素もしくはモジュール(「D−モジュール」)を構成することもできる。ある1つの実施形態においては、D−モジュールは、クライアントのリクエストにサービス(servicing)するストレージ・アクセス・コンポーネント(storage access components)を備える。対照的に、N−モジュールは、クライアントがストレージ・アクセス・コンポーネント(例えば、D−モジュール)にアクセスすることを可能にする機能を備え、さらに、コモン・インターネット・ファイルシステム(CIFS、Common Internet File System)、ネットワーク・ファイルシステム(NFS、Network File System)、といったプロトコル・コンポーネントや、インターネット・プロトコル(IP)モジュールを備えて接続性を向上させてもよい。D−モジュールやN−モジュールを含む分散型アーキテクチャ環境の詳細については、以下で図2Bに関して説明し、D−モジュールおよびN−モジュールに関する実施形態については、図4に関してさらに詳細に説明する。
さらに別の実施形態においては、ストレージ・サーバ210はネットワーク・ストレージ・サブシステム(network storage subsystems)と称される。ネットワーク・ストレージ・サブシステムは、特定のアプリケーションまたは目的について、ネットワーク化されたストレージ・サービスを提供する。ここでのアプリケーションの例としては、データベース・アプリケーション、ウェブ・アプリケーション、企業資源計画(EPR、Enterprise Resource Planning)アプリケーション等を含み、これらは例えばクライアント内に実装される。ここでの目的の例としては、ファイルのアーカイビング、バックアップ、ミラーリング等を含み、これらは、例えば、主ストレージ・サーバ(プライマリ・ストレージ・サーバ)に接続されたアーカイブ用、バックアップ用、あるいは、副次的ストレージ・サーバ(セカンダリ・ストレージ・サーバ)上で実現される。ネットワーク・ストレージ・サブシステムは、複数のストレージ・サーバおよび/またはストレージ・ユニットから横断的に集められたネットワーク・リソースの集合体により実装することも可能である。
図2Aの実施形態においては、ストレージ・サーバの1つ(例えば、ストレージ・サーバ210A)が、クライアント202に対する、データ・ストレージ・サービスの主たる提供者(primary provider)として機能する。1つもしくは複数のストレージ・オブジェクトとして組織化されたディスク271Aを用いて、クライアント202からのデータ格納要求(データ・ストレージ・リクエスト)に対するサービスが行われる。セカンダリ・ストレージ・サーバ(例えば、ストレージ・サーバ210B)は、プライマリ・ストレージ・サーバとのミラー関係における交代要員(standby role)として動作し、プライマリ・ストレージ・サーバからのストレージ・オブジェクトを、セカンダリ・ストレージ・サーバ(例えば、ディスク270B)のディスク上に編成されたストレージ・オブジェクトに複製(レプリケート、replicating)する。動作中、セカンダリ・ストレージ・サーバは、プライマリ・ストレージ・サーバが災害(disaster)見舞われるような、プライマリ・ストレージ・オブジェクトのデータに対するアクセス不能になるまで、クライアント202からのリクエストに対しサービスを提供しない。このような事象は、プライマリ・ストレージ・サーバにおける障害(failure)とみなされる。プライマリ・ストレージ・サーバに障害が発生すると、プライマリ・ストレージ・オブジェクトに向けられたクライアント202からのリクエストについては、複製データ(レプリケーテッド・データ)(つまり、セカンダリ・ストレージ・オブジェクト)を用いてセカンダリ・ストレージ・サーバがサービスを行う。
明らかなことだが、他の実施形態では、ネットワーク・ストレージ・システム200は、2よりも多くのストレージ・サーバを備えてよい。その場合、システム200内の様々なストレージ・サーバ間で、保護関係(プロテクション・リレーションシップ、protection relationships)を稼働させることができ、そうすることで、ストレージ・サーバ210Aの1つまたは複数のプライマリ・ストレージ・オブジェクトが、ストレージ・サーバ210B以外のストレージサーバ(不図示)に複製可能である。さらに、セカンダリ・ストレージ・オブジェクトが他のストレージ・オブジェクトと保護関係を結び、当該セカンダリ・ストレージ・オブジェクトが例えば三次的ストレージ・オブジェクト(ターシャリ・ストレージ・オブジェクト、tertiary storage objects)に複製されるようにして、セカンダリ・ストレージ・オブジェクトにかかる障害からの保護を設けてもよい。よって、ストレージ・サーバ210のプライマリおよびセカンダリ・ストレージ・オブジェクトの間の単段的(single-tier)保護関係の説明は、例示のみを目的としていると解すべきである。
図2Bは、分散型もしくはクラスタ型のネットワーク・ストレージ・システム220のブロック図である。当該システムは、ある1つの実施形態において高速クローニング(ラピッド・クローニング、rapid cloning)を実装することができる。システム220は、ノード210(ノード210A,210B)として実装されるストレージ・サーバを備えることができる。各ノードは、ストレージ・デバイス271に対するアクセスを提供する。図2Bにおいて、ノード210は、クラスタ・スイッチング・ファブリック225により相互接続されている。クラスタ・スイッチング・ファブリックは、イーサネット・スイッチ(Ethernet switch)で実現されてよい。
ノード210は、多機能コンポーネントとして動作することができ、該コンポーネントによって、システム220にかかる分散型アーキテクチャが実現されている。当該目的のため、各ノード210は、ネットワークの要素もしくはモジュール(N−モジュール221A,221B)、ディスク要素もしくはモジュール(D−モジュール222A,222B)、ならびに、管理(マネージメント)要素もしくはモジュール(M−ホスト(host)223A,223B)として構造化(オーガナイズ)されてよい。ある1つの実施形態においては、各モジュールは、モジュールそれぞれの作用を実現するために、プロセッサおよびメモリを備えている。例えば、N−モジュール221は、ノード210をネットワーク230越しにクライアント202と接続可能にする機能を有してよく、かつ、メディア・アクセス層(メディア・アクセス・レイヤ、media access layer)、インターネット・プロトコル(IP)層(インターネット・プロトコル・レイヤ、Internet Protocol layer)、トランスポート・コントロール・プロトコル(TCP)層(トランスポート・コントロール・プロトコル・レイヤ、Transport Control Protocol)、ユーザ・データグラム・プロトコル(UDP)層(ユーザ・データグラム・プロトコル・レイヤ、User Datagram Protocol layer)、ならびに、当技術分野において周知の他のプロトコルといった、プロトコル・コンポーネントを備えてよい。
対照的に、D−モジュール222は、クラスタ・スイッチング・ファブリック225を介して1つまたは複数のストレージ・デバイス271と接続することが可能であり、かつ、デバイス270に対するアクセス・リクエストに対するサービスを提供するために動作可能である。ある1つの実施形態においては、D−モジュール222は、エクステント・ベース・ストレージ・アーキテクチャ495を実装する。これについては、後で詳述する。ある1つの実施形態においては、D−モジュール222は、多プロトコル・データ・アクセス(multi-protocol data access)(例えば、コモン・インターネット・ファイルシステム・プロトコル(Common Internet File System protocol)、ネットワーク・ファイルシステム・プロトコル(Network File System protocol)、ハイパーテキスト・トランスファー・プロトコル(Hypertext Transfer Protocol))をサポートするストレージ抽象化層(ストレージ・アブストラクション・レイヤ、storage abstraction layer)、ストレージ・プロトコル(storage protocol)(例えば、RAIDプロトコル)を実装するストレージ層(ストレージ・レイヤ、storage layer)、ストレージ・デバイス・プロトコル(storage device protocol)(例えば、スモール・コンピュータ・システムズ・インタフェース・プロトコル(Small Computer Systems Interface protocol))を実装するドライバ層(ドライバ・レイヤ、driver layer)といった、ストレージ・アクセスのための工程を支援する動作を行うストレージ・アクセス・コンポーネント(storage access components)を備える。図2Bに示す実施形態においては、D−モジュールのストレージ・アブストラクション・レイヤ(例えば、ファイルシステム)は、デバイス270の物理ストレージを複数のストレージ・オブジェクトに分割(ディバイド、divides)する。ノード210が(例えば、N−モジュール221を介して)受け取ったリクエストには、リクエストが実行されるべきストレージ・オブジェクトを示すストレージ・オブジェクト識別子(アイデンティファイア)が含まれてよい。
他にノード210上で動作可能なものにM−ホスト223がある。これは、例えばシステム220全体にわたる、分散化ストレージ・システム・イメージを支援する動作を行うことによりノード210に関するクラスタ・サービスを提供する。RDB224(RDB224A,224B)といった、どのD−モジュール222が各ストレージ・オブジェクト「を所有している」("owns")(のサービスを提供している)のかを判断するためにN−モジュール221が使用する情報を含んだデータ構造(データ・ストラクチャ、data structure)をM−ホスト223が管理することで、M−ホスト223はクラスタ・サービスを提供する。複数のノード210それぞれにかかるRDB224の様々なインスタンスは、M−ホストが(例えば、ネットワーク230全体にわたって)M−ホスト同士の間で動作する従来型のプロトコルを用いて互いを同期化することで定期的に更新されればよい。N−モジュール221が受け取ったクライアントのリクエストは、分散型ストレージ・システム・イメージの提供サービスを行う適当なD−モジュール222へルーティングされる。
注記するが、図2Bには例示のシステム内のノードを構成する同数のN−モジュールおよびD−モジュールが図示されるが、高速クローニングの様々な実施形態においては、ノードを構成するN−モジュールおよびD−モジュールの数が異なってもよい。例えば、ノード210Aを構成するN−モジュールおよびD−モジュールの数が、ノード210BのN−およびD−モジュールとの間で一対一対応の関係を示さなくともよい。そのような理由で、各ノードが1つのN−モジュールおよび1つのD−モジュールを有するというノードに関する記載は、例示のみを目的としていると解されるべきである。
また、図2A−図2Bに関する記載は、上述した本発明にかかる方法を実施するのに適したコンピュータ・ハードウェアおよび他の動作コンポーネントを概観するためのものであって、適用可能な環境を限定することを目的としたものではない。当業者であれば、別のコンピュータ・システムの構成でも本発明を実施可能であることを直ちに理解するであろう。本発明は、通信ネットワークでリンクした遠隔の(リモートの)処理装置によってタスクが処理されるような、分散型コンピュータ環境(distributed computing environments)においても実施可能である。
当業者には明らかなことだが、キーボード、ポインティング・デバイス、ディスプレイといった入/出力デバイスをストレージ・サーバに接続してもよい。これらの従来型の特徴については、明瞭さを目的として示されていない。
図3は、図2Aのストレージ・サーバ210A,210Bのようなストレージ・サーバの実施形態のブロック図である。ここでは、該サーバは、プロセッサ302、メモリ310、ネットワーク・アダプタ320、ユーザ・コンソール312、および、ストレージ・アダプタ340を備え、それらが、従来型ペリフェラル・コンポーネント・インターコネクト(PCI、Peripheral Component Interconnect)のようなシステム・バス350で相互接続されている、汎用または専用のコンピュータとして実装される。
メモリ310は、プロセッサ302、ネットワーク・アダプタ320、および、ストレージ・アダプタ340によりアドレス指定可能なストレージ・ロケーションを備える。これは、プロセッサが実行可能な命令や高速クローニングに付随するデータ・ストラクチャを格納する。ストレージ・オペレーティング・システム314は、一般に、部分的にメモリ310に常駐されプロセッサ302により実行され、ストレージ・サーバによって提供されるストレージ・サービスを支援する動作を起動することにより、機能面でストレージ・サーバを構成する。当業者にとっては明らかなことだが、別の処理手段を用いて命令を実行してもよいし、様々なコンピュータ読み取り可能な媒体を含むメモリ手段を用いて、本明細書で説明される創意溢れる技術に関係するプログラム命令群を格納してもよい。また、これも明らかなことだが、プロセッサ302および実行可能なソフトウェアの機能のいくつかまたは全ては、プログラマブル・ロジック・アレイやASICに構成された統合型カレント(integrated currents)のようなハードウェアで実装可能である。
ネットワーク・アダプタ320は、1つまたは複数のポートを備え、それによりストレージ・サーバと、1つまたは複数のクライアントとを、2地点間接続(ポイント・ツー・ポイント・リンク、point-to-point link)またはネットワーク経由で接続する。よって、ネットワーク・アダプタ320は、ストレージ・サーバと、1つまたは複数のクライアントとを、ネットワーク経由で接続するために必要な、機械的でかつ、電気的な、信号伝達のための回路である。各クライアントは、TCP/IPのような所定のプロトコルに従って離散的なデータのフレームまたはパケットを交換することにより、ネットワーク経由で、ストレージ・サーバと通信を行うことができる。
ストレージ・アダプタ340は、入出力(I/O)インタフェース回路を備えた複数のポートを有し、もって、ストレージ・デバイス(例えば、ディスク)と、バス321とを、従来型の高性能FCやSASリンク・トポロジのようなI/O相互接続アレンジメントを介して接続する。ストレージ・アダプタ340は通例、デバイス・コントローラ(不図示)を備える。デバイス・コントローラは、プロセッサおよびメモリを備え、ストレージ・オペレーティング・システム314から受け取った読み出し(リード)コマンドおよび書き込み(ライト)コマンドに従ってストレージ・ユニットの動作を包括的に制御する。ある1つの実施形態においては、ストレージ・オペレーティング・システム314は、エクステント・ベース・ストレージ・アーキテクチャ495を実装する。これについては、後で詳細に説明する。本願明細書では、ライト・コマンドに応じてデバイス・コントローラが書き込んだデータを「ライト・データ」("write data")と称し、リード・コマンドに応じてデバイス・コントローラが読み出したデータを「リード・データ」("read data")と称する。
アドミニストレータは、ユーザ・コンソール312によりストレージ・サーバとのインタフェースが可能になり、コマンド・ライン・インタフェース(CLI)またはグラフィカル・ユーザ・インタフェース(GUI)を用いてストレージ・サーバを動作させたり、入力したりする。ある1つの実施形態においては、ユーザ・コンソール312は、モニタおよびキーボードを用いて実装される。
図2Bのクラスタ220のように、クラスタのノードとして実装される場合には、ストレージ・サーバはさらに、クラスタ・アクセス・アダプタ330(細線(phantom)で図示。)を有する。該アダプタは、1つまたは複数のポートを備え、もって、該ノードと、クラスタ内の他のノードとを、接続する。ある1つの実施形態においては、イーサネット(Ethernet)を、クラスタリング・プロトコルおよび相互接続媒体として用いる。当業者には明らかなことだが、当該クラスタ・アーキテクチャ内で別種のプロトコルおよび相互接続体を用いることも可能である。
図4は、図3のストレージ・オペレーティング・システム314のようなストレージ・オペレーティング・システムのブロック図である。該システムは、重複排除の実施形態を実現する。ストレージ・オペレーティング・システムは、図3のプロセッサ302のようなプロセッサが実行する一連のソフトウェアの層(ソフトウェア・レイヤ、software layer)を有し、統合的ネットワーク・プロトコル・スタック(integrated network protocol stack)を構成する。より概括的には、ブロックおよびファイルアクセス・プロトコルを用いてストレージ・サーバに格納されている情報にアクセスするためのデータ・パス(data path)をクライアントに提供する多プロトコル・エンジン(マルチプロトコル・エンジン、multi-protocol engine)425を構成する。
多プロトコル・エンジン425は、ネットワーク・ドライバ(例えば、ギガビット・イーサネット・ドライバ)のメディア・アクセス・レイヤ412を備える。該レイヤは、IPレイヤ414ならびにそれを支援するトランスポート機構すなわちTCPレイヤ416およびユーザ・データグラム・プロトコル(UDP)415のようなネットワーク・プロトコル・レイヤとのインタフェースを構成する。ファイルシステム・プロトコル・レイヤは、マルチプロトコル・ファイルアクセスを提供するが、そのためにダイレクト・アクセス・ファイルシステム(DAFS、Direct Access File System)プロトコル418、NFSプロトコル420、CIFSプロトコル422、および、ハイパーテキスト・トランスファ・プロトコル(HTTP、Hypertext Transfer Protocol)プロトコル424に対するサポートを備えている。VIレイヤ426は、VIアーキテクチャを実装することにより、RDMAのような、DAFSプロトコル418が要請するダイレクト・アクセス・トランスポート(DAT、direct access transport)機能を提供する。iSCSIドライバ・レイヤ428は、TCP/IPネットワーク・プロトコル・レイヤを経由したブロック・プロトコル・アクセスを提供し、FCドライバ・レイヤ430は、ストレージ・サーバへブロック・アクセス・リクエストを送信したりストレージ・サーバから応答を受信したりする。或る例では、ファイバ・チャネル・オーバー・イーサネット(FCoE、Fibre Channel over Ethernet)レイヤ(不図示)を多プロトコル・エンジン425内で動作させてもよく、該レイヤに、ストレージ・サーバに対しリクエストを送信させ応答を受信させてもよい。ストレージ・サーバのブロックにアクセスする際、FCドライバおよびiSCSIドライバは、それぞれ、ブロックに対する、FC固有アクセス・コントロール(FC-specific access control)およびiSCSI固有アクセス・コントロール(iSCSI-specific access control)を提供し、よって、LUN(luns)のiSCSIもしくはFCPへのエキスポート、または、iSCSIおよびFCPの両方へのエキスポートを管理する。
ストレージ・オペレーティング・システムは、ストレージ・サーバ465を構成するために編成された一連のソフトウェアの層も備える。これがストレージ・デバイスに格納された情報にアクセスするためのデータ・パス(data path)を提供する。情報には、ストレージ・サーバの動作をサポートするためにストレージ・オペレーティング・システムがアクセスするプログラム・アプリケーションのデータやその他のシステム・データのようなデータの他、クライアントから受け取ったデータが含まれてもよい。好ましくは、クライアントのデータは、1つまたは複数の論理ストレージ・オブジェクト(ロジカル・ストレージ・オブジェクト)(例えば、ボリューム)として構成されてよい。これには、全体的な論理アレンジメント(overall logical arrangement)を共同して規定するストレージ・デバイスの収集体(コレクション、collection)が含まれている。ある1つの実施形態においては、論理アレンジメントは、論理ボリューム・ブロック数(vbn)空間(ロジカル・ボリューム・ブロック・ナンバー・スペース、logical volume block number spaces)を含んでよい。ここでは、各ボリュームが、ユニークな(固有の、一意的な)vbnと関連づけされている。
ファイルシステム460は、(SCSIターゲット・モジュール435のように図示される)1つまたは複数の仮想化モジュールの相互作用を通じてストレージ・オペレーティング・システムの仮想化システムを実施する。SCSIターゲット・モジュール435は、通例、ドライバ428,430と、ファイルシステム460との間に配置されてブロック(lun)空間(ブロック(lun)スペース、block (lun) space)と、ファイルシステム空間(ファイルシステム・スペース、file system space)との間のトランスレーション層(トランスレーション・レイヤ、translation layer)を提供する。この場合、lunは、ブロックとして表現される。ある1つの実施形態においては、ファイルシステム460は、例えば4キロバイト(KB)のブロックを用いるブロック・ベースのオンディスクフォーマットの表現(レプリゼンテーション、representation)を有しかつファイルおよび(作成時刻(creation time)、アクセス許可(access permissions)、サイズ(size)、ブロック位置(ロケーション)(block location))といったファイル属性(アトリビュート、attributes)を識別するためにインデックス・ノード(「アイ・ノード」("inodes"))のようなデータ構造を用いるWAFL(ライト・エニウェア・ファイル・レイアウト)ファイルシステムを実装する。ファイルシステム460は、ファイルを用いて自身のファイルシステムのレイアウトを記述しているメタデータを格納する。これには、アイ・ノード・ファイルが含まれる。アイ・ノード・ファイルは、ファイルの基礎となるデータ・ブロックを直接的にまたは間接的に参照(リファレンス)する(指し示す(ポイントする))。
ある1つの実施形態に関し、ファイルシステム460は、WAFLの拡張としてのエクステント・ベース・アーキテクチャ495を備える。動作上、クライアントからのリクエストは、ネットワークを経由してパケットとしてストレージ・サーバへ送られる。該サーバにおいては、リクエストは、ネットワーク・アダプタが受け取る。レイヤ412あるいはレイヤ430といったネットワーク・ドライバは、パケットを処理し、適当と判断すれば、該パケットをネットワーク・プロトコルおよびファイル・アクセス・レイヤへ送って、ファイルシステム460へ転送する前に追加的な処理を行う。ここで、ファイルシステム460は、リクエストされたデータが「イン・コア」("in core")に存在しなければ、つまり、メモリ310に存在しなければ、リクエストされたデータをディスクからロード(load)(読み出し、リトリーブ(retrieve))する。もし情報がメモリに存在しなければ、ファイルシステム460は、エクステント・ベース・アーキテクチャ495と協働して間接ボリューム(インダイレクト・ボリューム、indirect volume)にアクセスしてエクステント識別子(エクステント・アイデンティファイア)を読み出し、エクステント対物理ブロック(エクステント−物理ブロック)・データ構造(extent-to-physical block data structure)にアクセスしてPVBNを読み出し、該PVBNをRAIDシステム480へ送る。ある1つの実施形態においては、エクステント対物理ブロック・データ構造は、マップ(map)として実装される。ここで、PVBNは、ディスク識別子(ディスク・アイデンティファイア)およびデバイス・ブロック・ナンバー(ディスク、DBN)へマッピングされ、ディスク・ドライバ・システム490の適切なドライバへ送られる。ディスク・ドライバは、特定のディスクからDBNへアクセスしてリクエストされたデータのブロックをメモリにロードしてストレージ・サーバによる処理に供する。リクエストを完了すると、ノード(およびオペレーティング・システム400)は、ネットワークを介してクライアントへリプライを返す。
当然のことながら、本発明の教示に適合可能なストレージ・サーバが受け取ったクライアントからのリクエストのためにデータ・ストレージへアクセスするのに必要な上述したストレージ・オペレーティング・システムの複数のレイヤを通るソフトウェア的な「経路(パス、path)」は、ハードウェアで実装されてもよい。つまり、本発明の別の実施形態においては、ストレージ・アクセス・リクエストのデータ・パスは、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途集積回路(ASIC)内に実現される論理回路として実装されてもよい。このタイプのハードウェア的な実装は、クライアントが発したリクエストに対する応答においてストレージ・サーバが提供するストレージ・サービスのパフォーマンスを向上させる。さらに、本発明の別の代替的実施形態においては、アダプタ320,340の処理要素は、パケット処理およびストレージ・アクセス・オペレーションそれぞれの一部または全部をプロセッサ302から解放(オフロード、offload)させるように構成されてもよい。そうすることで、ストレージ・サーバが提供するストレージ・サービスのパフォーマンスが向上する。あきらかなことだが、本明細書に記載の様々な処理、アーキテクチャ、プロシージャは、ハードウェアでも、ファームウェアでも、ソフトウェアでも実装可能である。
クラスタに実装される場合、ストレージ・オペレーティング・システムのデータ・アクセス・コンポーネントは、ディスクに格納されたデータにアクセスするためのD−モジュール450として実現されてよい。対照的に、多プロトコル・エンジン425は、ネットワークを介して到来するクライアントが発したアクセスに関するプロトコルの終端化(ターミネーション、termination)したり、クラスタ内の別のN−モジュールに対するアクセス・リクエストをリダイレクトしたりする、N−モジュール410として実現されてよい。クラスタ・サービス・システム436は、さらに、M−ホスト(例えば、M−ホスト401)を実装してもよい。そうすることで、情報共有操作を生成しクラスタの分散型ファイルシステム・イメージを呈示するクラスタ・サービスが提供される。例えば、メディア・アクセス・レイヤ412は、様々なノードのクラスタ・サービス・システム間で情報パケットの送受信を行い、各ノードの複製データベースを同期化してもよい。
加えて、クラスタ・ファブリック(CF)インタフェース・モジュール440(CFインタフェース・モジュール440A,440B)は、CFプロトコル470を用いたN−モジュール410とD−モジュール450との間でのクラスタ内通信(イントラ−クラスタ・コミュニケーション、intra-cluster communication)を促進してもよい。例えば、D−モジュール450は、CFアプリケーション・プログラミング・インタフェース(API)を、コール(calls)を発したN−モジュール410(あるいは、図示しない別のD−モジュール)に曝し(expose)てもよい。そのために、CFインタフェース・モジュール440は、ローカル・プロシージャ・コール(LPCs)およびリモート・プロシージャ・コール(RPCs)を用いたCFエンコーダ/デコーダとして構成されて、同一ノードに存在するD−モジュールや遠隔のノードに存在するD−モジュールとの間でファイルシステム・コマンドを交換することができる。
エクステント・ベース・アーキテクチャでの重複排除は、重複排除のリクエストの受信を必要とする。重複排除では、リクエストと関係する物理ボリュームの重複排除を行い、重複排除された物理ボリュームに関係付けされた1つまたは複数のエクステントの重複排除を行う。重複排除は、ファイルシステム460の重複排除モジュール(デダプリケーション・モジュール)498が実行してよい。
本明細書では、本発明はストレージ・オペレーティング・システム内での重複排除の実装として示されているが、当然のことながら重複排除は、別の実施形態として、ストレージ・サーバの他のモジュールやコンポーネントで実装されてもよい。加えて、重複排除は、ストレージ・サーバにおいて、ソフトウェアを実行するプロセッサ、ハードウェア、ファームウェアの1つまたは組み合わせとして実装されてよい。よって、重複排除(デダプリケーション)は、本発明の教示に従って、ストレージ・オペレーティング・システムのモジュールと直接的または間接的に相互作用してよい(インタフェースしてよい)。
本明細書では、語「ストレージ・オペレーティング・システム」は、通常、コンピュータ上で動作してデータ・アクセスを管理するストレージ機能を実行するコンピュータ実行可能コードを指し、また、汎用オペレーティング・システムのデータ・アクセス動作を実現するものでもよい。ストレージ・オペレーティング・システムは、マイクロカーネルとして、UNIX(登録商標)やWindowsXP(登録商標)といった汎用オペレーティング・システム上で動作するアプリケーション・プログラムとして、または、機能を設定可能な(with configurable functionality)汎用オペレーティング・システムで本明細書に記載のようなストレージ用途を設定したシステムとして、実装可能である。
加えて、当業者にとっては当然のことだが、本明細書に記載の発明は、様々なタイプの専用コンピュータ(ファイル・サーバやストレージ・サービング・アプライアンス)や汎用コンピュータに適用可能であり、該コンピュータには、スタンドアロンのコンピュータや、その部分体も含まれ、ストレージ・システムとして実施されるもの、ストレージ・システムを含むものも含まれる。また、本発明が教示する内容を、様々なストレージ・システム・アーキテクチャに適化することも可能である。該アーキテクチャには、ネットワークアタッチトストレージ環境や、ストレージエリアネットワークや、クライアントもしくはホストのコンピュータと直接的に接続されたディスク・アセンブリなどが含まれ、またこれらに限定されない。故に、語「ストレージ・システム」("storage system")は、ストレージ機能を有するように設計され他の設備もしくはシステムに付随するサブシステムに加え、以上のような構成を含むように、広く解釈されるべきである。注記するが、本記載は、ライト・エニウェア・ファイル・システムに関して記載されているが、本発明の教示は、従来型の所定の場所に書き込むファイルシステム(ライト・イン・プレース・ファイルシステム、write in place file systems)を含む、あらゆる適当なファイルシステムで利用可能である。
図5は、エクステント・ベース・アーキテクチャ495を例示するブロック図である。エクステント・ベース・アーキテクチャ495は、ボリューム層(ボリューム・レイヤ)505ならびに集合体層(アグリゲート・レイヤ)もしくは領域管理層(リージョン・マネージャ・レイヤ)510を備える。ボリューム・レイヤ505は、1つまたは複数の間接ボリューム(インダイレクト・ボリューム)515を備え、クライアント202からのI/Oリクエストをストレージ・ディスク271内の1つまたは複数の物理ブロックに間接的にマッピングする。ある1つの実施形態においては、ストレージ・サーバ210は、各エクステントについて間接ボリューム515内の1つのエントリを用いる。これに対し、先行技術によるブロック・ベースの実装は、各データ・ブロックについて(例えばフレキシブル・ボリューム110内の)1つの間接ボリューム・エントリを用いた。ある1つの実施形態においては、I/Oリクエストは、ファイル・ブロック・ナンバー(FBN)を経由してデータを参照する。FBNは、クライアント202が見るように、間接ボリューム515内のデータ・ブロックを参照する。FBNは、エクステント識別子(extent identifier)にアクセスするためのキーとして用いられる。本明細書では、エクステントは、FBN空間(FBN space)において連続する1つまたは複数のブロックのグループ(contiguous group)を指す。本明細書では、エクステント対物理ブロック(エクステント−物理ブロック)・マップ(extent-to-physical block map)は、ある実施形態でマップとして実施されるデータ構造である。集合体層(アグリゲート・レイヤ)510は、エクステント−物理ブロック・マップ520ならびに1つまたは複数の物理ボリューム525を備える。エクステント−物理ブロック・マップ520は、(例えば、ボリューム・レイヤ505内のFBNを経由してアクセスされる)エクステント識別子を、別のエクステントまたは1つもしくは複数の物理ボリューム525内の物理ボリューム・ブロック・ナンバー(PVBN)を指すポインタにマッピングする。本明細書では、PVBNは、線的な単一のシークエンス(a single linear sequence)に抽象化されているディスク・ブロックを指す。
エクステント−物理ブロック・マップ520のエクステント・ベース・エントリは、アグリゲート単位の間接(エントリ)(パー・アグリゲート・インダイレクション、per-aggregate indirection)を提供する。対照的に、ボリューム・コンテナ120の仮想ボリューム・ブロック番号(ヴァーチャル・ボリューム・ブロック・ナンバー、virtual volume block number)(VVBN)は、ボリューム単位の間接(エントリ)(パー・ボリューム・インダイレクション、per-volume indirection)を提供する。アグリゲート単位(パー・アグリゲート、per-aggregate)エクステント・ベース・エントリは、本明細書では、アグリゲート内でボリューム境界を越えて一意的な(ユニークな)エクステントを指す。ボリューム単位(パー・ボリューム、per-volume)間接エントリは、ボリューム境界内で一意的な(ユニークな)エントリを指す。アグリゲート単位間接(エントリ)については、ストレージ・サーバ210が、物理ブロックに対しコピー、移動、その他の変更を加えたとき、その変更が、エクステント−物理ブロック・マップ520の当該アグリゲート・レイヤ510に反映される。しかしながら、この変更がボリューム・レイヤ505へ伝えられる必要性はない。なぜなら、物理ブロックに関係づけられたエクステント識別子が変更される必要がないからである。これにより、ボリューム・レイヤ505との情報交換(コミュニケーション、communication)なしで、エクステントの圧縮(compression)、伸張(decompression)、共有(sharing)、共有解除(非共有、unsharing)が可能になる。ボリューム境界を越えたブロックの共有が容易くできるので、ボリューム間重複排除(クロス・ボリューム・デダプリケーション、cross-volume deduplication)が可能になる。一回のパス(single pass)でセグメント・クリーニング(segment cleaning)および関連するディスク・ガーデニング技術(disk gardening techniques)をエクステント−物理ブロック・マップ520で実行できるようになり、その際、変更をボリューム・レイヤ505へ伝える必要は全くない。
図6は、エクステント・ベース・アーキテクチャ495のようなエクステント・ベース・アーキテクチャに含まれる、ソートされたエクステント・ベース・データ構造600の例を示す図である。ある1つの実施形態においては、ソートされたエクステント・ベース・データ構造600は、B+ツリーである。あるいは、ソートされたエクステント・ベース・データ構造600は別種のツリーであるか、または、長くともO(logn)の時間で検索(lookup)および修正(modify)の操作を実行することができるソートされたデータ構造である。ここでnは、ファイル中のブロックの数である。アイ・ノード605は、エクステント・ベース・ツリー/ソートされたデータ構造600のルートを指し示し、かつ、ボリューム/ファイルのメタデータならびにデータ・ブロック620もしくは間接ブロック(インダイレクト・ブロック、indirect blocks)610/615に対するポインタを含んでいる。例えば、B+ツリーにおいては、間接ブロックは、内部ノード(インターナル・ノード、internal nodes)610/615と呼ばれ、データ・ブロックは、葉ノード(リーフ・ノード、leaf nodes)620と呼ばれる。ある1つの実施形態においては、アイ・ノード605は、1つまたは複数の内部ノード610/615の分岐(ブランチ、branches)を指し示す。別の実施形態では、アイ・ノード605は、直接的に葉ノード620を指し示す。ある1つの実施形態では、内部ノード610/615は、他のノードに対するポインタを格納し、FBN、エクステント識別子、PVBN等のデータを格納しない。他方、葉ノード620は、そのようなデータを格納する。別の実施形態では、内部ノード610/615がデータを格納してもよい。
ある1つの実施形態では、エクステントの長さ(レングス)は、(例えば、8ブロックに)予め定められていてもよい。別の実施形態では、エクステントの長さは、変化してもよい。ある1つの実施形態では、エクステントの長さは、エクステント内のブロックの数で表される。例えば、1つのブロックのみを含むエクステントは、1の長さを有し、2つのブロックを含むエクステントは、2の長さを有する、等々である。ある1つの実施形態では、ユーザI/Oまたは書き込み割り当て(ライト・アロケーション、write allocation)で決定される最大長さを有する(例えば、エクステントは、最大長さ64ブロックを有する)。
可変長エクステントを備えるエクステント・ベース・ツリーをエクステント・ベース・データ構造600のデータ構造として用いる実施形態では、同一のサイズを有する2ファイル間でもツリーの高さは変化しうる。ある1つの実施形態では、内部ノード610/615の長さ(スパン、span)も可変である。ある1つの実施形態では、内部ノード610/615のスパンは可変である。本明細書では、間接ブロックのスパンは、間接ブロックが参照するブロックの数である。比較として、WAFLでの以前の実装では、間接ブロックのスパンは固定されており、tradvol間接ブロックのスパンは、1024であり、(例えば、フレキシブル・ボリューム11に格納されている)flexvol間接ブロックのスパンは、510であり、(例えば、フレキシブル・ボリューム11に格納されている)32ビットflexvol間接ブロックのスパンは、255である。
加えて、WAFLの以前の実装においては、Nブロックを有する隣接エクステント(コンティギュアス・エクステント、contiguous extent)は、N個のランダムに位置決めされたブロック(N randomly located blocks)のような、同量の間接空間(indirect space)を使用している。なぜなら、エクステント各データ・ブロックは、ボリューム・レイヤにおいて別個の間接エントリとして表されるからである。しかしながら、ソートされたエクステント・ベース・データ構造600では、間接空間の量を大きく低減させている。なぜなら、ボリューム・レイヤ・エントリは、ブロック単位(パー・ブロック、per-block)ではなく、エクステント単位(パー・エクステント、per-extent)だからである。例えば、WAFLの以前の実装で532,685,800バイト(およそ508MB)のデータを有するファイルを格納する64ビットflexvolについて考察してみよう。flexvolは、255エントリを有する(スパンが255である)間接ブロックを含み、各エントリが、4KBのブロックを参照している。flexvolは、130050個の4KBレベル0データ・ブロックを指し示す510個のレベル1関節ブロックを指し示す2つのレベル2間接ブロックを使用して、508MBのファイルを表現する。ソートされたエクステント・ベース・データ構造600においては、4KBのブロックの各々に対し1つのエントリを使用する代わりに、ストレージ・サーバ210は各エクステントに対して1つのエントリを使用する。エクステントは、1個の4KBブロックよりも長くすることができる。例えば、エクステントは、1つまたは複数の4KBブロックの隣接グループ(コンティギュアス・グループ、contiguous group)である。ブロックあたり127エントリで16ブロック長のエクステントを備える、ソートされたエクステント・ベース・データ構造600を用いると、ストレージ・サーバ210は、たった8129個の葉ノード620と65個の内部ノード610/615で、130050個の4KBを表現する。その結果、間接ブロックのメタデータの87%を節約できる。
ある1つの実施形態では、ストレージ・サーバ210は、ソートされたエクステント・ベース・データ構造600を用いて間接ボリューム515を実装する。ある1つの実施形態では、ストレージ・サーバ210は、間接ボリューム515のそれぞれをB+ツリーとして実装する。図7は、間接ボリューム515を実装するために用いられた、ソートされたエクステント・ベース・データ構造600の葉ノード620についてのボリューム・レイヤ間接エントリ700の例図である。ボリューム・レイヤ間接エントリ700は、FBN705と、対応するエクステント識別子710と、エクステント715のレングス(長さ)と、を格納する。ストレージ・サーバ210は、FBN705を主ソート・キー(プライマリ・ソーティング・キー、primary sorting key)として用いてソートされたエクステント・ベース・データ構造600をナビゲート(navigate)し、FBN705と対応するエクステント識別子710を発見する。ある1つの実施形態では、FBN705は48ビット、エクステント識別子710は48ビット、レングス715は8ビットである。あるいは、ストレージ・サーバ210は、FBN705、エクステント識別子710、レングス715のうちの1つまたは複数について、異なるサイズのものを用いてもよい。例えば、エクステント識別子710は別の実施形態では(例えば、ブロックのオフセットにおいて512バイト粒度(granularity)を実現するために)64ビットの長さを有する。ある1つの実施形態では、エクステントのレングス715は変化する。別の実施形態では、エクステントのレングス715は固定である。
エクステント識別子710は、書き込み割り当て(ライト・アロケーション)の間に割り当てられる(アロケートされる)。ある1つの実施形態では、ストレージ・サーバ210は、エクステント識別子の有限プール(finite pool)からエクステント識別子710を割り当てる。あるいは、エクステント識別子710は、決して尽きることのない(never wrap)単調に増大する値である。
WAFLの以前の実装でのボリューム単位コンテナ・ファイル(パー・ボリューム・コンテナ・ファイル、per-volume container files)120は、間接ボリューム515を実装するために、ソートされたエクステント・ベース・データ構造600を使用していない。ストレージ・サーバ210は、ボリューム単位コンテナ・ファイル120の代わりに、エクステント−物理ブロック・マップを使用する。上述のように、エクステント−物理ブロック・マップを使用することで、間接メタデータを低減することができる。しかしながら、間接ボリューム・ブロックは、キャッシュされている、PVBNに対するポインタを含んでいない。エクステントに対するアクセスには、
ストレージ・サーバ210が間接ボリューム515内のエクステント識別子710を検索すること、および、エクステント−物理ブロック・マップ520内のPVBNを(例えば、ポインタを手段として)検索すること、が含まれる。この追加的なI/Oの検索(I/O look-up)にかかるコンピュテーションのオーバーヘッドは、エクステント・ベース・アーキテクチャ495の特徴のいくつかとで相殺される。例えば、I/Oアクセスは、ブロック単位ではなく、エクステント単位である。それ故、単一のI/Oアクセスで複数のブロックにアクセスされる。また、エクステント・ベース・アーキテクチャ495は、圧縮、重複排除、セグメント・クリーニング等において優位性を有する。重複排除のようなアクションは、単に1つのボリュームにとどまらずにアグリゲートにまで容易に拡大可能であり、例えば、圧縮およびセグメント・クリーニングの帰結としての、ブロックに対する多くの変更は、(例えば、キャッシュされた間接ポインタを訂正するために)間接ボリューム515にまで伝播される必要がない。
ストレージ・サーバ210が間接ボリューム515内のエクステント識別子710を検索すること、および、エクステント−物理ブロック・マップ520内のPVBNを(例えば、ポインタを手段として)検索すること、が含まれる。この追加的なI/Oの検索(I/O look-up)にかかるコンピュテーションのオーバーヘッドは、エクステント・ベース・アーキテクチャ495の特徴のいくつかとで相殺される。例えば、I/Oアクセスは、ブロック単位ではなく、エクステント単位である。それ故、単一のI/Oアクセスで複数のブロックにアクセスされる。また、エクステント・ベース・アーキテクチャ495は、圧縮、重複排除、セグメント・クリーニング等において優位性を有する。重複排除のようなアクションは、単に1つのボリュームにとどまらずにアグリゲートにまで容易に拡大可能であり、例えば、圧縮およびセグメント・クリーニングの帰結としての、ブロックに対する多くの変更は、(例えば、キャッシュされた間接ポインタを訂正するために)間接ボリューム515にまで伝播される必要がない。
ある1つの実施形態では、ストレージ・サーバ210は、ソートされたエクステント・ベース・データ構造600としてエクステント・ベース・ツリーを使用して、エクステント−物理ブロック・マップ520を実装する。ある1つの実施形態では、ストレージ・サーバ210は、エクステント−物理ブロック・マップ520をB+ツリーとして実装する。図8は、エクステント−物理ブロック・マップ520を実装するために用いる、ソートされたエクステント・ベース・データ構造600の葉ノード620のためのエクステント・マップ・エントリ800の例を示す図である。エクステント−物理ブロック・マップ520を実装するために用いる、ソートされたエクステント・ベース・データ構造600の葉ノード620は、エクステント識別子805と、1つまたは複数の、PVBNもしくは別のエクステント識別子810に対するポインタと、エクステント815についてのオフセット815と、エクステント820についてのレングスと、を格納する。ある1つの実施形態では、エクステント識別子805は48ビット、ポインタ/エクステント識別子810は48ビット、オフセット815は8ビット、レングス820は8ビットである。
ある1つの実施形態では、各エクステント・マップ・エントリ800は、PVBNに対する直接的なポインタもしくはその他のリファレンス810か、PVBNを直接的に参照する別のエクステント識別子805か、を含んでいる。加えて、各PVBNは、ただ1つのエクステントにより所有される。ある1つの実施形態では、所有者であるエクステントは、該PVBNを直接的に参照するエクステントである。その結果として、PVBNに至るためになされる、所与のエクステントに関する追加的な検索は最大でもわずかに1である。このことが、エクステント・マップ・エントリ800における間接参照のレベルが恣意的に深く(大きく)なること、および、(各エクステント・エントリが異なるディスク・ブロックに格納されやすいと想定した場合にディスクI/Oオペレーションに基づいて計測したときに)自由裁量的に長時間になることを防いでいる。本明細書では、深い(deep)は、間接参照(インダイレクト・リファレンス、indirect reference)のレベル数を指す。
結果として、ストレージ・サーバ210は、タグ(tag)、固有の番号(unique number)、または、欠落した書き込みの検出(lost write detection)のための別のコンテキストとして、所有者のエクステント識別子を使用する。本明細書では、欠落した書き込みの検出(ロスト・ライト・ディテクション)は、ストレージ・サーバ210のレポートは完了しているものの実際にはストレージ・サーバ210がI/Oの(例えば、ストレージ270A、ストレージ270B等のような)永続型ストレージ(persistent storage)にデータを書き込めていない書き込みの検出を指す。
別の実施形態では、1つまたは複数のPVBNに対して直接的にマップされたあらゆるエクステント識別子805は、2以上のエクステントによって所有されることができる。ロスト・ライト・ディテクションを具備する実施形態では、ストレージ・サーバ210は、複数のエクステント識別子が単一のPVBNを参照する可能性を考慮し、例えば別個のテーブルを用いて、エクステント識別子805とは別の/異なるコンテキスト、タグ、固有番号(ユニーク・ナンバー)を作成する。
ある1つの実施形態では、例えば、1つもしくは複数の、メタファイル、エクステントによる各エクステントに対する参照のリファレンス・カウント、および、エクステントによる各PVBNに対する参照のリファレンス・カウントを維持(maintain)する。リファレンス・カウントにより、ストレージ・サーバ210は、あるエクステント/PVBNに対して行う操作(例えば、再割り当て(リアロケーション、reallocation)、セグメント・クリーニング等)が他のエクステントに影響を及ぼすか否かを知ることができるようになる。ある1つの実施形態では、エクステントに対する操作が該エクステントに格納されている1つまたは複数の値を変更する場合に、そのエクステントは、エクステントに対する操作の影響を受ける。ストレージ・サーバ210は、1つまたは複数のログ・データ・コンテナのリファレンス・カウントの増大および減少を追跡(track)する。例えば、新しいエクステント/PVBNが割り当てられた場合、(例えば、クローンの生成や、スナップショットの生成や、重複排除により)エクステント識別子が共有された場合といったときに、ストレージ・サーバ210は、リファレンス・カウントを増大させる(インクリメントする)。ある1つの実施形態では、ストレージ・サーバ210は、ログ・データ・コンテナを用いて累積(アキュムレート、accumulates)し、増大させ(インクリメントし、increments)、減少させ(デクリメントし、decrements)、例えば整合ポイント(consistency point)において、リファレンス・カウントのメタファイルに対するひとまとめアップデート(バッチ・アップデート、batch update)を行う。
外部リファレンス・カウント825は、エクステント−物理ブロック・マップ520の外側から(例えば外部で)生成されるエクステントについてのリファレンス・カウントとして維持(maintain)される。各エクステントについて単一の外部リファレンス・カウント825が用いられる。例えば、(ファイル生成(creation)や修正(modification)の際に)新たなエクステントが割り当てられた場合、エクステントの外部リファレンス・カウントは1に設定される。ある1つの実施形態では、新たなエクステント/PVBNを割り当てる(アロケートする)ときに、ストレージ・サーバ210は、PVBNについて外部リファレンス・カウントをゼロから1に直接的に(ログ・データ・コンテナをバイパスして)増大させる(インクリメントする)。外部エクステント(エクスターナル・エクステント)は、少なくとも1つの外部参照(エクスターナル・リファレンス、external reference)を含んだエクステント−物理ブロック・マップ520内のエクステントである。一例としては、あるエクステントについての外部リファレンス・カウントが非ゼロであれば、当該外部エクステントは、重複排除操作により解放されることはない。
内部リファレンス・カウント(インターナル・リファレンス・カウント、internal reference count)830は、エクステント・マップ・エントリ800のために維持される。内部リファレンス・カウント830は、エクステント・マップ・エントリ800の内部のPVBNそれぞれための内部リファレンス・カウントを含んでいる。各内部リファレンス・カウントは、エクステント−物理ブロック・マップ520に関する内部操作(internal operation)により生成される。内部エクステントは、予め定められた数の外部参照を含む(例えば外部リファレンス・カウントがゼロの)エクステント−物理ブロック・マップ520内のエクステントである。ある1つの実施形態においては、ストレージ・サーバ210が、新たなエクステント/PVBNの割り当ての場合を除く全ての場合(例えば、PVBNの修正、PVBNの上書き等)において、個々のリファレンス・カウントのログ・データ・コンテナを用いて、該リファレンス・カウントに関するあらゆる増大(インクリメント)および減少(デクリメント)を実行する。
図9は、FBNから物理ボリューム525内のPVBNまでのマッピングのためにする、ボリューム・レイヤ505およびアグリゲート・レイヤ510内での検索のシークエンスの例を示す図である。例えば、ストレージ・サーバ210がFBN705を含んだI/Oリクエストを受け取ると、ストレージ・サーバ210は、該FBNを間接ボリューム515内でのキーとして用いてボリューム・レイヤ間接エントリ700内のエクステント識別子710を検索する。ストレージ・サーバ210は、そのエクステント識別子710を、エクステント−物理ブロック・マップ520内のエクステント・マップ・エントリ800の検索のためのキーとして用いる。ストレージ・サーバ210は、ポインタ810を用いて物理ボリューム525内のPVBN905にアクセスする。この例においては、オフセット815はゼロである。オフセットが正の値を有するならば、ストレージ・サーバ210は、PVBN905の後の1つまたは複数のブロック(例えばPVBN915、PVBN925等)にアクセスする。レングスが1よりも大きいならば、ストレージ・サーバ210は、PVBN905ならびに後続の1つもしくは複数のブロック(例えばPVBN915、PVBN925等)にアクセスする。この例においては、外部リファレンス・カウント825は非ゼロ(例えば1)である。なぜなら、ボリューム・レイヤ間接エントリ700においてエクステント・マップ・エントリ800が特定され、そして、それ故に、該エクステントは外部エクステントだからである。本例においては、エクステント・マップ・エントリ800は、内部エクステントではない。なぜなら、該エクステントは、ボリューム・レイヤ間接エントリ700によって参照されているからである。
図10は、FBNから物理ボリューム525内のPVBNまでのマッピングのためにする、ボリューム・レイヤ505およびアグリゲート・レイヤ510内での検索のシークエンスの別例を示す図である。図9を参照して説明した例と同様、ストレージ・サーバ210がFBN705を含んだI/Oリクエストを受け取り、該FBNを間接ボリューム515内でのキーとして用いてボリューム・レイヤ間接エントリ700内のエクステント識別子710を検索する。ストレージ・サーバ210は、そのエクステント識別子710を、エクステント−物理ブロック・マップ520内の第1のエクステント・マップ・エントリ800の検索のためのキーとして用いる。この例においては、第1のエクステント・マップ・エントリ800は、PVBN905に対するポインタ810と、第2のエクステント・マップ・エントリ1000に対するポインタまたはエクステント識別子810と、を含んでいる。第1のエクステント・マップ・エントリ800を外部エクステントと称することが可能である。外部エクステントは、動作中のファイルシステム(active file system)、ボリューム・クローン(volume clone)、あるいは、スナップショット(snapshot)により参照されるエクステントの1つである。ストレージ・サーバ210は、ポインタ810を用いて物理ボリューム525内のPVBN905にアクセスする。ストレージ・サーバ810は、エクステント識別子810を用いてエクステント−物理ブロック・マップ520内の第2のエクステント・マップ・エントリ1000を検索する。ストレージ・サーバ210は、ポインタ1010を用いて物理ボリューム525内のPVBN915にアクセスする。本例においては、外部リファレンス・カウント825は非ゼロ(例えば1)である。なぜなら、ボリューム・レイヤ間接エントリ700においてエクステント・マップ・エントリ800が特定され、そして、それ故に、該エクステントは外部エクステントだからである。本例においては、エクステント・マップ・エントリ800は、内部エクステントではない。なぜなら、該エクステントは、ボリューム・レイヤ間接エントリ700によって参照されているからである。エクステント・マップ・エントリ1000を、内部エクステントを称することが可能である。内部エクステントは、別のエクステントのみによって参照され、第1のエクステント・マップ・エントリ800によって参照されるPVBNのみを保持する。本例では、外部リファレンス・カウント1025は、予め定められた数(例えばゼロ)であり、これは、エクステント・マップ・エントリ1000が外部エクステント・マップ・エントリ800からのみ参照されることを意味している。
図11−図12は、エクステント・ベース・アーキテクチャにおける重複排除の方法を例示するフローチャートである。図11は、ある1つの実施形態によるエクステント・ベース・アーキテクチャでの重複排除の方法1100を例示するフローチャートである。図11を参照すれば、方法1100は、処理ロジック(processing logic)により実行可能である。処理ロジックは、ハードウェア(例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等)、ソフトウェア(ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群)、またはその結合体を備え、これらは図11においては処理指示ブロック1105−1135として表現されている。ある実施形態においては、方法1100は、図2Aに示されるストレージ・サーバ210、図2Bに示されるD−モジュール222、図3に示されるオペレーティング・システム314、および、図4に示される重複排除モジュール498により実行されてよい。
処理指示ブロック1105において、重複排除実行のリクエストが受け取られる。該リクエストは、重複排除を実行せねばならないと判断するユーザまたはアドミニストレータからのものである。ある別の実施形態においては、重複排除実行のリクエストは、定期的に受け取られる。別の実施形態においては、長く保持されるスナップショット(long retained snapshot)またはアーカイブ化されるスナップショットが取得されるよりも予め定められた時間だけ前に、重複排除実行のリクエストが受け取られる。ある1つの実施形態においては、長く保持されるスナップショットとは、長期間(例えば一週、一月、一年等)にわたり永続型ストレージに保管されることになるスナップショットである。例えば、長く保持されるスナップショットが毎日曜深夜に取得され、かつ重複排除処理に2時間を要するなら、重複排除実行のリクエストが日曜の正午に発生するように設定することができ、そうすることで、これから実行される(スナップショットの)重複排除に十分な時間を確保することが可能になる。重複排除実行のリクエストは、重複排除する特定のスナップショットを含んでもよい。別の実施形態においては、最も近い(最近の)スナップショットが重複排除に関するデフォルトのスナップショットである。別の実施形態においては、新たなスナップショットが取得される場合には常に、全てのスナップショットについて重複排除がなされる。さらに別の実施形態においては、スナップショット以外の、エクステント・ベース・アーキテクチャ内のデータについて重複排除が実行される。
処理指示ブロック1110において、ログ・データ・コンテナがアクセスされる。ログ・データ・コンテナは、書き込み割り当てを受け(write allocated)、かつ/または、変更を受けた(modified)物理ボリューム(例えば物理ボリューム525)内の各ブロックに関する識別情報(identifying information)を格納するデータ構造である。ある1つの実施形態においては、ログ・データ・コンテナは、ファイルである。ある1つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ/または、変更を受けたデータ・ブロックのフィンガープリント(fingerprint)およびエクステントIDを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、エクステント・ベース・アーキテクチャ495にアクセス可能なフィンガープリントに対するポインタおよびエクステントIDを含んでいる。フィンガープリントとは、数学的アルゴリズムを用いて生成される、データ・ブロックを一意的に特定する2進数の符号列(coded string of binary digits)である。データ・ブロックのためのフィンガープリントは、本技術分野において周知の方法により生成される。フィンガープリントは、フィンガープリント構造(不図示)に格納される。フィンガープリント構造は、いずれの図面にも示されていないが、当業者であれば、フィンガープリント構造は、オペレーティング・システム、メモリ、オペレーティング・システム/メモリにアクセス可能なフィンガープリント・データベース等に実装可能であることを理解する。
ある1つの実施形態においては、ログ・データ・コンテナは、先のスナップショットが実行されて以来、割り当て(アロケート)を受け、かつ/または、変更(モディファイ)を受けたデータ・ブロックを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、物理ボリュームがシステムに組み入れられて以来、割り当て(アロケート)を受け、かつ/または、変更(モディファイ)を受けた全てのデータ・ブロックを含んでいる。さらに別の実施形態においては、ログ・データ・コンテナは、重複排除コマンドを伴って受け取ったスナップショットのために割り当てられた(アロケートされた)データ・ブロックを含んでいる。ある1つの実施形態においては、ログ・データ・コンテナは、いつデータ・ブロックが書き込み割り当てを受け、かつ/または、変更を受けたかを示すタイムスタンプを含むことができる。ある別の実施形態においては、ログ・データ・コンテナにタイムスタンプは含まれない。最も近くに(最近に)書き込み割り当てを受け、かつ/または、変更を受けたブロックは、ログ・データ・コンテナにおいて最近のエントリである。処理指示ブロック1115において、ログ・データ・コンテナにおけるエントリがアクセスされる。
処理指示ブロック1115において、現行のエントリ(カレント・エントリ、current entry)のエクステントIDが、ログ・データ・コンテナ内の他のエントリのエクステントIDと比較される。エクステントIDは、当該技術分野の周知技術を用いて比較すればよい。現行のエントリのエクステントIDが、ログ・データ・コンテナ内の他のエントリのエクステントIDと一致すれば、方法1100はブロック1120へ進む。現行のエントリのエクステントIDが、ログ・データ・コンテナ内の他のエントリのエクステントIDと一致しなければ、方法1100はブロック1135へ進む。
処理ブロック1120において、一致しているエントリ(マッチング・エントリ、matching entry)についてのリファレンス・カウントおよびポインタIDが更新される。ある1つの実施形態においては、現行のエントリの内部リファレンス・カウントは、一致しているエントリの内部リファレンス・カウントを含むように、更新される。例えば、現行のエントリの内部リファレンス・カウントが4であって、一致しているエントリの内部リファレンス・カウントが8であったならば、現行のエントリの内部リファレンス・カウントは、12、つまり4と8の合計、に更新される。この実施形態においては、一致しているエントリの内部リファレンス・カウントはゼロに更新される。別の実施形態においては、一致しているエントリの内部リファレンス・カウントは、現行のエントリの内部リファレンス・カウントを含むように更新される。この実施形態においては、現行のエントリの内部リファレンス・カウントはゼロに更新される。ある1つの実施形態においては、現行のエントリの内部リファレンス・カウントが、一致しているエントリの内部リファレンス・カウントを含むように更新されれば、一致しているエントリのエクステントIDのポインタが、現行のエントリのエクステントIDを指し示すように更新される。別の実施形態においては、一致しているエントリの内部リファレンス・カウントが、現行のエントリの内部リファレンス・カウントを含むように更新されれば、現行のエントリのエクステントIDのポインタが、一致しているエントリのエクステントIDを指し示すように更新される。
処理ブロック1125において、現行のエントリに関係づけられたエクステントまたは一致しているエントリに関係づけられたエクステントのいずれかのリファレンス・カウントが予め定められた値(例えばゼロ)であるかどうかが判断される。ある1つの実施形態においては、リファレンス・カウントは、エクステントについての外部リファレンス・カウントである。別の実施形態においては、リファレンス・カウントは、エクステントについての内部リファレンス・カウントである。この実施形態においては、エクステントのあらゆる内部リファレンス・カウントが予め定められた値に等しい場合にのみ、一致が見られるとする。いずれかのエクステントのリファレンス・カウントが予め定められた値に等しければ、方法1100は、ブロック1130へ進む。エクステントの両方のリファレンス・カウントが予め定められた値に等しくなければ、方法1100は、ブロック1135へ進む。
ブロック1130において、リファレンス・カウントが予め定められた値に等しいエクステントが解放される。エクステントは、当該エクステントを有するPVBNを解放し、当該PVBNについてのマッピングをエクステント−物理ブロック・マップ520から除去することにより解放される。ある1つの実施形態においては、エクステントを解放する工程に、エクステント識別子710を、自由に使用することができるエクステント識別子のプールに再び加えることが含まれる。別の実施形態においては、エクステント識別子のプールが存在せず、故に、エクステント識別子710は、エクステント識別子のプールへ戻されることがない。
処理ブロック1135においては、ログ・データ・コンテナ内に処理すべきエントリがまだ存在するかどうかが判断される。ログ・データ・コンテナ内にまだエントリが存在すれば、方法1100は、処理ブロック1110に戻り、ログ・データ・コンテナ内の次のエントリにアクセスする。ログ・データ・コンテナ内に処理すべきエントリがなければ、方法1100は終了する。
図12は、別の実施形態による、エクステント・ベース・アーキテクチャにおける重複排除の方法を例示説明するフローチャートである。図12を参照すれば、方法1200は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア(例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等)、ソフトウェア(ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群)、またはその結合体を備え、これらは図12においては処理指示ブロック1205−1245として表現されている。ある実施形態においては、方法1200は、図2Aに示されるストレージ・サーバ210、図2Bに示されるD−モジュール222、図3に示されるオペレーティング・システム314、および、図4に示される重複排除モジュール498により実行されてよい。
処理指示ブロック1205において、重複排除実行のリクエストが受け取られる。該リクエストは、重複排除を実行せねばならないと判断するユーザまたはアドミニストレータからのものである。ある別の実施形態においては、重複排除実行のリクエストは、定期的に受け取られる。別の実施形態においては、長く保持されるスナップショットまたはアーカイブ化されるスナップショットが取得されるよりも予め定められた時間だけ前に、重複排除実行のリクエストが受け取られる。例えば、長く保持されるスナップショットが毎日曜深夜に取得され、かつ重複排除処理に2時間を要するなら、重複排除実行のリクエストが日曜の正午に発生するように設定することができ、そうすることで、これから実行される(スナップショットの)重複排除に十分な時間を確保することが可能になる。重複排除実行のリクエストは、重複排除する特定のスナップショットを含んでもよい。別の実施形態においては、最も近い(最近の)スナップショットが重複排除に関するデフォルトのスナップショットである。別の実施形態においては、新たなスナップショットが取得される場合には常に、全てのスナップショットについて重複排除がなされる。さらに別の実施形態においては、スナップショット以外の、エクステント・ベース・アーキテクチャ内のデータについて重複排除が実行される。
処理指示ブロック1210において、ログ・データ・コンテナがアクセスされる。ある1つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ/または、変更を受けた物理ボリューム(例えば物理ボリューム525)内の各ブロックに関する識別情報を格納するデータ構造である。ある1つの実施形態においては、ログ・データ・コンテナは、ファイルである。ある1つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ/または、変更を受けたデータ・ブロックのフィンガープリントおよびエクステントIDを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、エクステント・ベース・アーキテクチャ495にアクセス可能な、フィンガープリント・データベースに格納されたフィンガープリントに対するポインタおよびエクステントIDを含んでいる。データ・ブロックについてのフィンガープリントは、当技術分野における周知技術を用いて生成される。ログ・データ・コンテナは、先のスナップショットが実行されて以来、割り当てられ(アロケートされ)、かつ/または、変更された(モディファイされた)データ・ブロックを含んでいる。別の実施形態においては、ログ・データ・コンテナは、物理ボリュームがシステムに組み入れられて以来、割り当て(アロケート)を受け、かつ/または、変更(モディファイ)を受けた全てのデータ・ブロックを含んでいる。さらに別の実施形態においては、ログ・データ・コンテナは、重複排除コマンドを伴って受け取ったスナップショットのために割り当てられた(アロケートされた)データ・ブロックを含んでいる。ある1つの実施形態においては、ログ・データ・コンテナは、いつデータ・ブロックが書き込み割り当てを受け、かつ/または、変更を受けたかを示すタイムスタンプを含むことができる。ある別の実施形態においては、ログ・データ・コンテナにタイムスタンプは含まれない。最も近くに(最近に)書き込み割り当てを受け、かつ/または、変更を受けたブロックは、ログ・データ・コンテナにおいて最近のエントリである。処理指示ブロック1215において、ログ・データ・コンテナにおけるエントリがアクセスされる。
処理ブロック1215において、ログ・データ・コンテナ内の現行のエントリが一致を有するがどうかが判断される。ある1つの実施形態においては、当該判断は、現行のエントリに関係づけられたフィンガープリントがログ・データ・コンテナ内の別のエントリと関係づけられたフィンガープリントと一致するか判断することで、なされる。別の実施形態においては、該判断は、現行のエントリと関係づけられたフィンガープリントがフィンガープリント・データベースに格納されたフィンガープリントと一致するか判断することで、なされる。フィンガープリントの比較は、当技術分野における周知技術を用いて行われる。
現行のエントリに関係づけられたフィンガープリントが一致しないと判断されれば、方法1200はブロック1245へ進む。ある1つの実施形態においては、現行のエントリと関係づけられたフィンガープリントが一致を有すると判断されると、バイト比較(byte comparison)が行われる。本実施形態におけるバイト比較では、現行のエントリに関係づけられたデータ・ブロック内の各バイトが、一致するフィンガープリントを有するデータ・ブロック内の各バイトと比較される。例えば、エントリXが値Yなるフィンガープリントを有し、エントリZも値Yなるフィンガープリントを有すると判断されれば、エントリXと関係づけられたデータ・ブロック内の各バイトが、エントリZと関係づけられたデータ・ブロック内の各バイトと比較される。別の実施形態においては、現行のエントリについてのフィンガープリントが一致を有する場合、バイト比較を行わずに、方法1200がブロック1220へ進む。
処理ブロック1220においては、上述の一致に基づいて、ドナー・エクステントとレシピエント・エクステントとが決定される。ある1つの実施形態においては、現行のエクステントと関係づけられたエクステントが、ドナー・エクステントに決定され、一致するエントリと関係づけられたエクステントが、レシピエント・エクステントに決定される。別の実施形態においては、現行のエクステントと関係づけられたエクステントが、レシピエント・エクステントに決定され、一致するエントリと関係づけられたエクステントが、ドナー・エクステントに決定される。別の実施形態においては、現行のエントリおよび一致するエントリのタイムスタンプ同士が比較され、古い方のエントリがドナー・エクステントとして、新しい方のエントリがレシピエント・エクステントとして決定される。別の実施形態においては、現行のエントリおよび一致するエントリのタイムスタンプ同士が比較され、新しい方のエントリがドナー・エクステントとして、古い方のエントリがレシピエント・エクステントとして決定される。
処理ブロック1225において、レシピエント・エクステントについての外部リファレンス・カウントが予め定められた値(例えばゼロ)と等しいかどうか判断される。レシピエント・エクステントについての外部リファレンス・カウントが予め定められた値と等しいならば、方法1200は、ブロック1235へ進む。例えば、レシピエント・エクステントについての外部リファレンス・カウントがゼロであれば、当該レシピエント・エクステントは、内部エクステントにちがいない。レシピエント・エクステントが内部エクステントであるならば、ドナー・エクステントおよびレシピエント・エクステントの間のブロック共有は行われない。レシピエント・エクステントが内部エクステントでないならば(そして、それ故に、外部エクステントであるならば)、ブロック1230においてブロック共有が行われる。ブロック共有については、図13と併せて以下で説明する。
処理ブロック1235において、エクステントのリファレンス・カウントが予め定めた値(例えばゼロ)と等しいかどうか判断される。ある1つの実施形態においては、外部利ファン連巣・カウントが、予め定められた値と比較される。別の実施形態においては、内部リファレンス・カウントも、予め定められた値と比較され、エクステントに関係づけられたPVBNを解放すべきかどうか判断される。ある1つの実施形態においては、当該判断は、エクステント−物理ブロック・マップ(例えばアグリゲート単位エクステント−物理ブロック・マップ520)内の各エクステントについてなされる。別の実施形態においては、判断は、ドナー・エクステントおよびレシピエント・エクステントについてなされる。
エクステントのリファレンス・カウントが予め定められた値(例えばゼロ)と等しくなければ、方法1200は、ブロック1245へ進む。エクステントのリファレンス・カウントが予め定められた値(例えばゼロ)に等しければ、処理ブロック1240においてエクステントは解放される。エクステントの解放は、図14と併せて以下に記載されるようにして実行される。
処理ブロック1245においては、ログ・データ・コンテナ内に処理すべきエントリがまだ存在するかどうかが判断される。ログ・データ・コンテナ内にまだエントリが存在すれば、方法1200は、処理ブロック1210に戻り、ログ・データ・コンテナ内の次のエントリにアクセスする。ログ・データ・コンテナ内に処理すべきエントリがなければ、方法1200は終了する。
図13は、ある実施形態によるブロック共有の方法を例示説明するフローチャートである。図13を参照すれば、方法1300は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア(例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等)、ソフトウェア(ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群)、またはその結合体を備え、これらは図13においては処理指示ブロック1305−1335として表現されている。ある実施形態においては、方法1300は、図2Aに示されるストレージ・サーバ210、図2Bに示されるD−モジュール222、図3に示されるオペレーティング・システム314、および、図4に示される重複排除モジュール498により実行されてよい。
処理ブロック1305においては、レシピエント・エクステント内の共有されるべきデータ・ブロックに関係づけられた内部リファレンス・カウントが、ドナー・エクステント内の一致しているブロックについての内部リファレンス・カウントを含むように、更新される。例えば、レシピエント・エクステント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントが4であって、ドナー・エクステント内の一致しているデータ・ブロックについての内部リファレンス・カウントが8であったならば、レシピエント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントは更新されて12になる。ある1つの実施形態においては、レシピエント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントの更新は、エクステント−物理データ・ブロック・マップ520内のレシピエント・エクステントのエクステントIDについてのエクステント・エントリを更新することによりなされる。
処理ブロック1310において、ドナー・エクステント内の一致しているデータ・ブロックの内部リファレンス・カウントは、更新されてゼロにされる。ある1つの実施形態においては、ドナー・エクステント内の一致しているデータ・ブロックについての内部リファレンス・カウントの更新は、エクステント−物理データ・ブロック・マップ520内のドナー・エクステントのエクステントIDについてのエクステント・エントリを更新することによりなされる。
処理ブロック1315においては、ドナー・エクステントのエクステント識別子に設定されたエクステント識別子805と、レシピエント・エクステントのエクステント識別子に対する参照810と、レシピエント・エクステント内の共有されるべきデータ・ブロックのオフセットに等しいオフセット815と、共有されるべきデータ・ブロックのレングス820と、先の値から1だけ(例えばゼロから1へ)インクリメントされた外部リファレンス・カウント825と、を含むように、新たなエクステント・マップ・エントリ800が生成される。ある1つの実施形態においては、ドナー・エクステントの外部リファレンス・カウントがインクリメントされることにより、エクステント−物理ブロック・マップ・エントリにおける間接参照のレベルが恣意的に深くなること、および、(各エクステント・エントリが異なるディスク・ブロックに格納されやすく別個のI/O操作が必要になる傾向が高いと想定した場合にディスクI/Oオペレーションに基づいて計測したときに)自由裁量的に長時間になることを防いでいる。本明細書では、深いは、間接参照のレベル数を指す。
処理ブロック1320においては、ドナー・エクステントについてのエクステント・エントリが更新される。エクステント識別子805は、ドナー・エクステントのエクステント識別子に設定される。参照810は、共有されるべきデータ・ブロックのPVBNに設定される。オフセット815は、ドナー・エクステント内の第1のデータ・ブロックの位置(ロケーション、location)に設定される(例えば、ドナー・エクステント内の第1のデータ・ブロックが共有され、もはやドナー・エクステントにより参照されないならば、オフセットは1に設定され、これが共有されないドナー・ブロックの第1のブロックである。)。レングス820は、ドナー・エクステント内の共有されていないデータ・ブロックの数に設定される(例えば、1個のブロックが共有され、エクステントの長さが8であれば、レングスは7に更新される。)。レングス820がゼロであれば、外部リファレンス・カウント825はデクリメントされる。今、ドナー・エクステントのレングスがゼロであれば、当該エクステントはもはやPVBNを参照せず、故に、解放されるべきである。ある1つの実施形態においては、ドナー・エクステントについてのエクステント・エントリは、アグリゲート・レイヤのソートされたデータ構造において現存するエクステント・エントリを上書きすることで、更新される。別の実施形態においては、エクステント・エントリの更新は、更新されたエクステントについて新たなエントリを追加することによりなされる。
処理ブロック1325においては、ストレージ・サーバ210は、割り当てられた(アロケートされた)エクステント識別子805をキーとして用いてアグリゲート・レイヤのソートされたエクステント・ベース・データ構造600を横断し(行き来して)、1つまたは複数の新たなエクステント・マップ・エントリ800を追加する。
図14は、ある実施形態によるエクステントの解放の方法を例示説明するフローチャートである。図14を参照すれば、方法1400は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア(例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等)、ソフトウェア(ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群)、またはその結合体を備え、これらは図14においては処理指示ブロック1405−1415として表現されている。ある実施形態においては、方法1400は、図2Aに示されるストレージ・サーバ210、図2Bに示されるD−モジュール222、図3に示されるオペレーティング・システム314、および、図4に示される重複排除モジュール498により実行されてよい。
処理ブロック1405においては、エクステントを含んだPVBNが解放される。PVBNの解放は、当技術分野において周知の方法を用いてなされる。
処理ブロック1410においては、当該エクステント識別子および対応するPVBNについてのエクステント−物理ブロック・マップ520内エントリが除去される。
処理ブロック1415においては、解放されんとするエクステントのエクステント識別子710は、自由に使用することができるエクステント識別子のプールに加えられる。別の実施形態においては、処理ブロック1415は任意(optional)であり、実行されない。ある1つの実施形態においては、エクステント識別子のプールが存在しなければ、処理ブロック1415は任意である。本実施形態においては、エクステント識別子710は、エクステント識別子のプールに再配置されない。ある特定の実施形態においては、処理ブロック1415は省略され、ブロック1410で処理は終了する。
このように、エクステント・ベース・アーキテクチャにおける重複排除の実施形態は、本明細書中で示したようなコンピュータ・システムに実装される。実用上、方法1100および方法1200は、コンピュータが実行可能な命令群で構成される1つまたは複数のプログラムを構成してよい。図11、図12、図13、および、図14のフローチャートを参照して当該方法を説明したので、当業者であれば、そのようなプログラムを開発することは可能である。ここで、プログラムは、(適切に構成されたコンピュータ(コンピュータ読み取り可能な媒体から読み取った命令群を実行する、コンピュータのプロセッサ)上で)論理ブロック1100から1135、1200から1245、1300から1325、1400から1415として表現された操作(オペレーション、operations)(動作(acts))を実行するための命令群を含んでいる。コンピュータが実行可能な命令群は、コンピュータ・プログラミング言語で記述されてよく、あるいは、ファームウェアのロジックもしくはハードウェア回路で実現されてもよい。もし、認知された基準に準拠したプログラミング言語(programming language conforming to a recognized standard)で記述されているならば、その命令群は、様々なハードウェア・プラットフォームで動作可能であって、様々なオペレーティング・システムに対するインタフェースとして動作する。
さらに、本発明は、特定のプログラミング言語を参照して説明していない。当然のことながら、様々なプログラミング言語を用いて本明細書に記された本発明の教示の内容を実装してよい。なおさらには、当業界では共通の認識だが、ソフトウェアとは、(例えば、プログラム(program)、プロシージャ(procedure)、プロセス(process)、アプリケーション(application)、モジュール(module)、ロジック(logic)………)いかなる形態であっても、ある動作を行うもの、あるいは、何らかの結果をもたらすものである。このような表現は、単に、コンピュータがソフトウェアを実行することにより該コンピュータのプロセッサがある動作を行うかまたはある結果をもたらす、ことを簡潔に言い表したものである。当然のことだが、本発明の範囲を逸脱することなく、より多くの処理を図11、図12、図13、および、図14に組み入れてもよいし、該図の処理をもっと少ない処理にしてもよいし、また、本明細書に記載され図示されるブロックの配置は特定の順序を暗示するものではない。
エクステント・ベース・アーキテクチャにおける重複排除について記載した。特定の実施形態について例示的に示し説明したが、当然、当業者にとっては、同様の目的を達成すると考えられる構成で、開示された実施形態を置換できることは明らかである。本願は、本発明のあらゆる適応(アダプテーション、adaptations)あるいは変形(バリエーション、variations)を包含する。
本明細書中の語「メモリ」("memory")は、ダイナミック・ランダム・アクセス・メモリ(DRAM)およびスタティック・RAM(SRAM)といったあらゆる揮発性記憶媒体(volatile storage media)を包含する。コンピュータが実行可能な命令群は、磁気ハード・ディスク(magnetic hard disk)、光学ディスク(an optical disk)といった不揮発性記憶デバイス(non-volatile storage devices)に格納可能であって、通例、プロセッサがソフトウェアを実行中にダイレクト・メモリ・アクセス・プロセスによりメモリに書き込まれる。当業者であれば、語「コンピュータ読み取り可能記憶媒体」("computer-readable storage medium")は、プロセッサがアクセス可能なあらゆる種類の揮発性または不揮発性の記憶装置(ストレージ・デバイス)を含むものであると、直ちに理解する。
それ故、本発明は、クレームおよびその均等物のみにより限定される。
Claims (26)
- コンピュータを用い、ストレージ・サーバを備えるエクステント・ベース・アーキテクチャにおける重複排除を実行する方法であって、
前記ストレージ・サーバが、前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第1の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第2の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を有する方法。 - 前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする、請求項1に記載のコンピュータを用いた方法。 - ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項1に記載のコンピュータを用いた方法。
- 前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項1に記載のコンピュータを用いた方法。 - 前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた1つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの1つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項1に記載のコンピュータを用いた方法。 - 前記ドナー・エクステントは、前記エントリと関係付けられたエクステントであり、前記レシピエント・エクステントは、前記別のエントリと関係付けられたエクステントである、ことを特徴とする、請求項1に記載のコンピュータを用いた方法。
- 前記ドナー・エクステントは、前記別のエントリと関係付けられたエクステントであり、前記レシピエント・エクステントは、前記エントリと関係づけられたエクステントである、ことを特徴とする、請求項1に記載のコンピュータを用いた方法。
- 前記第1の予め定められた値は、ゼロよりも大きい値であり、前記第2の予め定められた値はゼロである、ことを特徴とする、請求項1に記載のコンピュータを用いた方法。
- 持続性のコンピュータ読み取り可能な記憶媒体であって、ストレージ・サーバを備えるエクステント・ベース・アーキテクチャにおける重複排除のための工程をプロセッサに実行させる実行可能な命令群を備えた記憶媒体であって、前記工程は、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第1の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第2の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を含むことを特徴とする、持続性のコンピュータ読み取り可能な記憶媒体。 - 前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする請求項9に記載のコンピュータ読み取り可能な記憶媒体。 - ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。
- 前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。 - 前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた1つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの1つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。 - 前記ドナー・エクステントは、前記エントリと関係づけられたエクステントであり、前記レシピエント・エクステントは、前記別のエントリと関係づけられたエクステントである、ことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。
- 前記ドナー・エクステントは、前記別のエントリと関係づけられたエクステントであり、前記レシピエント・エクステントは、前記エントリと関係づけられたエクステントである、ことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。
- 前記第1の予め定められた値は、ゼロよりも大きい値であり、前記第2の予め定められた値はゼロである、ことを特徴とする、請求項9に記載のコンピュータ読み取り可能な記憶媒体。
- コンピュータ・システムであって、
バスを介してメモリと接続されたプロセッサと、
前記プロセッサによって前記メモリから実行される命令群であって、前記命令群は前記プロセッサに、
前記コンピュータ・システム内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第1の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第2の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を実行させる命令群と、を有するコンピュータ・システム。 - 請求項17に記載のコンピュータ・システムであって、前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする、請求項17に記載のコンピュータ・システム。 - ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項17に記載のコンピュータ・システム。
- 前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項17に記載のコンピュータ・システム。 - 前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた1つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの1つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項17に記載のコンピュータ・システム。 - コンピュータ・システムであって、
ストレージ・デバイスと接続されたストレージ・サーバを有し、前記ストレージ・サーバは、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取り、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられ、複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ログ・データ・コンテナにアクセスし、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第1の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第2の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放する、ことを特徴とする、コンピュータ・システム。 - コンピュータを用いた方法であって、
ストレージ・サーバが、前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を有する方法。 - 持続性のコンピュータ読み取り可能な記憶媒体であって、プロセッサに工程を実行させる実行可能な命令群を備えた記憶媒体であって、前記工程は、
ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を含むことを特徴とする、持続性のコンピュータ読み取り可能な記憶媒体。 - コンピュータ・システムであって、
バスを介してメモリと接続されたプロセッサと、
前記プロセッサによって前記メモリから実行される命令群であって、前記命令群は前記プロセッサに、
ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を実行させる命令群と、を有するコンピュータ・システム。 - コンピュータ・システムであって、
ストレージ・デバイスと接続されたストレージ・サーバを有し、前記ストレージ・サーバは、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取り、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられ、複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ログ・データ・コンテナにアクセスし、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放する、ことを特徴とする、コンピュータ・システム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/165,631 US8600949B2 (en) | 2011-06-21 | 2011-06-21 | Deduplication in an extent-based architecture |
US13/165,631 | 2011-06-21 | ||
PCT/US2012/034788 WO2012177318A1 (en) | 2011-06-21 | 2012-04-24 | Deduplication in an extent-based architecture |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014525073A true JP2014525073A (ja) | 2014-09-25 |
Family
ID=46086048
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014516967A Pending JP2014525073A (ja) | 2011-06-21 | 2012-04-24 | エクステント・ベース・アーキテクチャにおける重複排除 |
Country Status (4)
Country | Link |
---|---|
US (2) | US8600949B2 (ja) |
EP (1) | EP2724225A1 (ja) |
JP (1) | JP2014525073A (ja) |
WO (1) | WO2012177318A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10037161B2 (en) | 2015-10-21 | 2018-07-31 | Kabushiki Kaisha Toshiba | Tiered storage system, storage controller, and method for deduplication and storage tiering |
Families Citing this family (72)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8671265B2 (en) | 2010-03-05 | 2014-03-11 | Solidfire, Inc. | Distributed data storage system providing de-duplication of data using block identifiers |
US8539008B2 (en) | 2011-04-29 | 2013-09-17 | Netapp, Inc. | Extent-based storage architecture |
US8812450B1 (en) | 2011-04-29 | 2014-08-19 | Netapp, Inc. | Systems and methods for instantaneous cloning |
US8745338B1 (en) | 2011-05-02 | 2014-06-03 | Netapp, Inc. | Overwriting part of compressed data without decompressing on-disk compressed data |
US8600949B2 (en) * | 2011-06-21 | 2013-12-03 | Netapp, Inc. | Deduplication in an extent-based architecture |
US8805796B1 (en) * | 2011-06-27 | 2014-08-12 | Emc Corporation | Deduplicating sets of data blocks |
US9838269B2 (en) | 2011-12-27 | 2017-12-05 | Netapp, Inc. | Proportional quality of service based on client usage and system metrics |
US9054992B2 (en) | 2011-12-27 | 2015-06-09 | Solidfire, Inc. | Quality of service policy sets |
US8996467B2 (en) * | 2011-12-29 | 2015-03-31 | Druva Inc. | Distributed scalable deduplicated data backup system |
US8700634B2 (en) * | 2011-12-29 | 2014-04-15 | Druva Inc. | Efficient deduplicated data storage with tiered indexing |
WO2013111187A1 (en) * | 2012-01-25 | 2013-08-01 | Hitachi, Ltd. | Single instantiation method using file clone and file storage system utilizing the same |
US9256609B2 (en) * | 2012-03-08 | 2016-02-09 | Dell Products L.P. | Fixed size extents for variable size deduplication segments |
US10417027B1 (en) * | 2012-03-30 | 2019-09-17 | EMC IP Holding Company LLC | Virtual machine proxy server for hyper-V image backup and recovery |
US8954718B1 (en) * | 2012-08-27 | 2015-02-10 | Netapp, Inc. | Caching system and methods thereof for initializing virtual machines |
US9559862B1 (en) * | 2012-09-07 | 2017-01-31 | Veritas Technologies Llc | Determining connectivity of various elements of distributed storage systems |
US9063967B2 (en) | 2013-01-10 | 2015-06-23 | Pure Storage, Inc. | Performing copies in a storage system |
US11768623B2 (en) | 2013-01-10 | 2023-09-26 | Pure Storage, Inc. | Optimizing generalized transfers between storage systems |
US9846620B2 (en) | 2013-01-11 | 2017-12-19 | Commvault Systems, Inc. | Table level database restore in a data storage system |
US9557937B2 (en) * | 2013-08-21 | 2017-01-31 | Netapp, Inc. | Systems, methods, and computer program products implementing hybrid file structures for data storage |
US9405783B2 (en) | 2013-10-02 | 2016-08-02 | Netapp, Inc. | Extent hashing technique for distributed storage architecture |
US9152684B2 (en) | 2013-11-12 | 2015-10-06 | Netapp, Inc. | Snapshots and clones of volumes in a storage system |
US9448924B2 (en) | 2014-01-08 | 2016-09-20 | Netapp, Inc. | Flash optimized, log-structured layer of a file system |
US9529546B2 (en) | 2014-01-08 | 2016-12-27 | Netapp, Inc. | Global in-line extent-based deduplication |
US9268653B2 (en) | 2014-01-17 | 2016-02-23 | Netapp, Inc. | Extent metadata update logging and checkpointing |
US9256549B2 (en) | 2014-01-17 | 2016-02-09 | Netapp, Inc. | Set-associative hash table organization for efficient storage and retrieval of data in a storage system |
US20150244795A1 (en) | 2014-02-21 | 2015-08-27 | Solidfire, Inc. | Data syncing in a distributed system |
US9600201B2 (en) * | 2014-03-27 | 2017-03-21 | Hitachi, Ltd. | Storage system and method for deduplicating data |
US11055258B2 (en) | 2014-04-02 | 2021-07-06 | International Business Machines Corporation | Directly accessing archived data and executable files |
US9798728B2 (en) | 2014-07-24 | 2017-10-24 | Netapp, Inc. | System performing data deduplication using a dense tree data structure |
US10133511B2 (en) | 2014-09-12 | 2018-11-20 | Netapp, Inc | Optimized segment cleaning technique |
US9671960B2 (en) | 2014-09-12 | 2017-06-06 | Netapp, Inc. | Rate matching technique for balancing segment cleaning and I/O workload |
US9967310B2 (en) * | 2014-10-21 | 2018-05-08 | Dropbox, Inc. | Using an RPC framework to facilitate out-of-band data transfers |
US9836229B2 (en) | 2014-11-18 | 2017-12-05 | Netapp, Inc. | N-way merge technique for updating volume metadata in a storage I/O stack |
US9753936B1 (en) * | 2014-12-01 | 2017-09-05 | Amazon Technologies, Inc. | Metering data in distributed storage environments |
US9659047B2 (en) * | 2014-12-03 | 2017-05-23 | Netapp, Inc. | Data deduplication utilizing extent ID database |
US20160210306A1 (en) * | 2015-01-15 | 2016-07-21 | Commvault Systems, Inc. | Managing structured data in a data storage system |
US10108687B2 (en) | 2015-01-21 | 2018-10-23 | Commvault Systems, Inc. | Database protection using block-level mapping |
US9720601B2 (en) | 2015-02-11 | 2017-08-01 | Netapp, Inc. | Load balancing technique for a storage array |
US9762460B2 (en) | 2015-03-24 | 2017-09-12 | Netapp, Inc. | Providing continuous context for operational information of a storage system |
US10275408B1 (en) * | 2015-03-27 | 2019-04-30 | EMC IP Holding Company LLC | Analysis and visualization tool utilizing mixture of multiple reliability measures for product and part combinations |
US9710317B2 (en) | 2015-03-30 | 2017-07-18 | Netapp, Inc. | Methods to identify, handle and recover from suspect SSDS in a clustered flash array |
US11423004B2 (en) * | 2015-04-17 | 2022-08-23 | Netapp Inc. | Granular replication of volume subsets |
US9904598B2 (en) | 2015-04-21 | 2018-02-27 | Commvault Systems, Inc. | Content-independent and database management system-independent synthetic full backup of a database based on snapshot technology |
US9798497B1 (en) * | 2015-06-08 | 2017-10-24 | Skytap | Storage area network emulation |
US10853323B2 (en) * | 2015-07-23 | 2020-12-01 | Netapp Inc. | Deduplicating extents across systems based upon indications of shared extents provided by clients |
US10257273B2 (en) | 2015-07-31 | 2019-04-09 | Netapp, Inc. | Systems, methods and devices for RDMA read/write operations |
US10565230B2 (en) | 2015-07-31 | 2020-02-18 | Netapp, Inc. | Technique for preserving efficiency for replication between clusters of a network |
US9952797B2 (en) | 2015-07-31 | 2018-04-24 | Netapp, Inc. | Systems, methods and devices for addressing data blocks in mass storage filing systems |
US10394660B2 (en) | 2015-07-31 | 2019-08-27 | Netapp, Inc. | Snapshot restore workflow |
US9740566B2 (en) | 2015-07-31 | 2017-08-22 | Netapp, Inc. | Snapshot creation workflow |
US9715348B2 (en) * | 2015-09-09 | 2017-07-25 | Netapp, Inc. | Systems, methods and devices for block sharing across volumes in data storage systems |
US9753647B2 (en) | 2015-09-09 | 2017-09-05 | International Business Machines Corporation | Deduplicating chunk digests received for chunks in objects provided by clients to store |
US9665287B2 (en) | 2015-09-18 | 2017-05-30 | Alibaba Group Holding Limited | Data deduplication using a solid state drive controller |
US9959056B2 (en) * | 2016-01-13 | 2018-05-01 | Netapp, Inc. | Methods and systems for efficiently storing data at a plurality of storage tiers using a transfer data structure |
US9792043B2 (en) | 2016-01-13 | 2017-10-17 | Netapp, Inc. | Methods and systems for efficiently storing data |
US11182344B2 (en) * | 2016-03-14 | 2021-11-23 | Vmware, Inc. | File granular data de-duplication effectiveness metric for data de-duplication |
US9880743B1 (en) * | 2016-03-31 | 2018-01-30 | EMC IP Holding Company LLC | Tracking compressed fragments for efficient free space management |
US10929022B2 (en) | 2016-04-25 | 2021-02-23 | Netapp. Inc. | Space savings reporting for storage system supporting snapshot and clones |
US11113247B1 (en) * | 2016-05-10 | 2021-09-07 | Veritas Technologies Llc | Routing I/O requests to improve read/write concurrency |
US10642763B2 (en) | 2016-09-20 | 2020-05-05 | Netapp, Inc. | Quality of service policy sets |
US9933945B1 (en) * | 2016-09-30 | 2018-04-03 | EMC IP Holding Company LLC | Efficiently shrinking a dynamically-sized volume |
US10776210B2 (en) * | 2016-09-30 | 2020-09-15 | Hewlett Packard Enterprise Development Lp | Restoration of content of a volume |
US10534755B2 (en) | 2016-10-13 | 2020-01-14 | International Business Machines Corporation | Word, phrase and sentence deduplication for text repositories |
US10521143B2 (en) * | 2017-03-23 | 2019-12-31 | Netapp Inc. | Composite aggregate architecture |
US10684786B2 (en) * | 2017-04-28 | 2020-06-16 | Netapp, Inc. | Methods for performing global deduplication on data blocks and devices thereof |
US10409736B2 (en) * | 2017-05-15 | 2019-09-10 | Seagate Technology Llc | Multi-host Intelligent block level provisioning |
US10789002B1 (en) * | 2017-10-23 | 2020-09-29 | EMC IP Holding Company LLC | Hybrid data deduplication for elastic cloud storage devices |
US11099771B2 (en) * | 2018-09-24 | 2021-08-24 | Salesforce.Com, Inc. | System and method for early removal of tombstone records in database |
US11199990B2 (en) * | 2018-11-02 | 2021-12-14 | EMC IP Holding Company LLC | Data reduction reporting in storage systems |
US11269732B2 (en) | 2019-03-12 | 2022-03-08 | Commvault Systems, Inc. | Managing structured data in a data storage system |
US11288212B2 (en) | 2019-12-18 | 2022-03-29 | Samsung Electronics Co., Ltd. | System, apparatus, and method for secure deduplication |
US20230385240A1 (en) * | 2022-05-31 | 2023-11-30 | Microsoft Technology Licensing, Llc | Optimizations for data deduplication operations |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005135126A (ja) | 2003-10-30 | 2005-05-26 | Hitachi Ltd | フラグメント防止ファイルシステム |
US7730277B1 (en) | 2004-10-25 | 2010-06-01 | Netapp, Inc. | System and method for using pvbn placeholders in a flexible volume of a storage system |
US7664791B1 (en) | 2005-10-26 | 2010-02-16 | Netapp, Inc. | Concurrent creation of persistent point-in-time images of multiple independent file systems |
JP4755487B2 (ja) | 2005-11-24 | 2011-08-24 | 株式会社日立製作所 | データ読出しシステム、データ読出し装置およびデータ読出し方法 |
US8799882B2 (en) * | 2005-12-07 | 2014-08-05 | Microsoft Corporation | Compiler support for optimizing decomposed software transactional memory operations |
US7747565B2 (en) * | 2005-12-07 | 2010-06-29 | Microsoft Corporation | Garbage collector support for transactional memory |
US7870172B1 (en) | 2005-12-22 | 2011-01-11 | Network Appliance, Inc. | File system having a hybrid file system format |
US7702870B2 (en) | 2006-01-19 | 2010-04-20 | Network Appliance Inc. | Method and apparatus for defragmentation and for detection of relocated blocks |
US7562203B2 (en) | 2006-09-27 | 2009-07-14 | Network Appliance, Inc. | Storage defragmentation based on modified physical address and unmodified logical address |
US7321962B1 (en) | 2007-02-07 | 2008-01-22 | Network Appliance, Inc. | Technique for translating a hybrid virtual volume file system into a pure virtual file system data stream |
US7984022B2 (en) | 2008-04-18 | 2011-07-19 | International Business Machines Corporation | Space recovery with storage management coupled with a deduplicating storage system |
US20100088296A1 (en) | 2008-10-03 | 2010-04-08 | Netapp, Inc. | System and method for organizing data to facilitate data deduplication |
WO2010045262A1 (en) | 2008-10-14 | 2010-04-22 | Wanova Technologies, Ltd. | Storage-network de-duplication |
US9542409B2 (en) | 2008-11-26 | 2017-01-10 | Red Hat, Inc. | Deduplicated file system |
US8612702B1 (en) * | 2009-03-31 | 2013-12-17 | Symantec Corporation | Systems and methods for performing optimized backups of multiple volumes |
US20100274772A1 (en) | 2009-04-23 | 2010-10-28 | Allen Samuels | Compressed data objects referenced via address references and compression references |
US9058298B2 (en) * | 2009-07-16 | 2015-06-16 | International Business Machines Corporation | Integrated approach for deduplicating data in a distributed environment that involves a source and a target |
US8037349B2 (en) * | 2009-08-28 | 2011-10-11 | International Business Machines Corporation | Data replication based on capacity optimization |
US8442942B2 (en) * | 2010-03-25 | 2013-05-14 | Andrew C. Leppard | Combining hash-based duplication with sub-block differencing to deduplicate data |
US8793447B2 (en) * | 2010-03-30 | 2014-07-29 | Netapp, Inc. | Restoration of a parent LUN through modification of a read-write clone LUN as the parent LUN |
US8600949B2 (en) * | 2011-06-21 | 2013-12-03 | Netapp, Inc. | Deduplication in an extent-based architecture |
-
2011
- 2011-06-21 US US13/165,631 patent/US8600949B2/en active Active
-
2012
- 2012-04-24 JP JP2014516967A patent/JP2014525073A/ja active Pending
- 2012-04-24 EP EP12721631.5A patent/EP2724225A1/en not_active Withdrawn
- 2012-04-24 WO PCT/US2012/034788 patent/WO2012177318A1/en unknown
-
2013
- 2013-11-22 US US14/087,345 patent/US9043287B2/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10037161B2 (en) | 2015-10-21 | 2018-07-31 | Kabushiki Kaisha Toshiba | Tiered storage system, storage controller, and method for deduplication and storage tiering |
Also Published As
Publication number | Publication date |
---|---|
EP2724225A1 (en) | 2014-04-30 |
WO2012177318A1 (en) | 2012-12-27 |
US8600949B2 (en) | 2013-12-03 |
US20120330903A1 (en) | 2012-12-27 |
US20140201168A1 (en) | 2014-07-17 |
US9043287B2 (en) | 2015-05-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11797510B2 (en) | Key-value store and file system integration | |
US9043287B2 (en) | Deduplication in an extent-based architecture | |
US8924440B2 (en) | Extent-based storage architecture | |
US11010078B2 (en) | Inline deduplication | |
US9477420B2 (en) | Overwriting part of compressed data without decompressing on-disk compressed data | |
US11687265B2 (en) | Transferring snapshot copy to object store with deduplication preservation and additional compression | |
US9208181B2 (en) | Migrating data from legacy storage systems to object storage systems | |
US11063601B1 (en) | File system format for persistent memory | |
US11748208B2 (en) | Persistent memory architecture | |
US20200285613A1 (en) | Object store file system format for representing, storing, and retrieving data in an object store according to a structured format | |
US9256603B1 (en) | File system over fully provisioned volume file in direct mode | |
US8918378B1 (en) | Cloning using an extent-based architecture | |
US9256614B1 (en) | File system snapshots over fully provisioned volume file in direct mode | |
US10936540B2 (en) | Methods for accelerating storage media access and devices thereof | |
US11579910B2 (en) | Policy enforcement and performance monitoring at sub-LUN granularity | |
US11748310B2 (en) | Dependency aware improvements to support parallel replay or parallel replication of operations which are directed to a common node | |
US10394481B2 (en) | Reducing application input/output operations from a server having data stored on de-duped storage |