(57)【要約】重複データを除去するリクエストを受け取る。ストレージ・サーバ内のストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスする。ログ・データ・コンテナは複数のエントリを含んでいる。各エントリはストレージ・サーバと関係づけられたボリュームに格納されたデータ構造内のエクステント識別子により識別される。ログ・データ・コンテナの各エントリについて、エントリがログ・データ・コンテナ内の別のエントリと一致するか判断する。エントリがログ・データ・コンテナ内の別のエントリと一致すれば、ドナー・エクステントとレシピエント・エクステントとを決定する。レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第１所定値と等しければ、ドナー・エクステントおよびレシピエント・エクステントについてブロック共有を行う。ドナー・エクステントのリファレンス・カウントが第２所定値と等しいか判断する。ドナー・エクステントのリファレンス・カウントが第２所定値と等しければ、ドナー・エクステントを解放する。
2014525073.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを用い、ストレージ・サーバを備えるエクステント・ベース・アーキテクチャにおける重複排除を実行する方法であって、
前記ストレージ・サーバが、前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第１の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第２の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を有する方法。
【請求項２】
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項３】
ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項４】
前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項５】
前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた１つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの１つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項６】
前記ドナー・エクステントは、前記エントリと関係付けられたエクステントであり、前記レシピエント・エクステントは、前記別のエントリと関係付けられたエクステントである、ことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項７】
前記ドナー・エクステントは、前記別のエントリと関係付けられたエクステントであり、前記レシピエント・エクステントは、前記エントリと関係づけられたエクステントである、ことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項８】
前記第１の予め定められた値は、ゼロよりも大きい値であり、前記第２の予め定められた値はゼロである、ことを特徴とする、請求項１に記載のコンピュータを用いた方法。
【請求項９】
持続性のコンピュータ読み取り可能な記憶媒体であって、ストレージ・サーバを備えるエクステント・ベース・アーキテクチャにおける重複排除のための工程をプロセッサに実行させる実行可能な命令群を備えた記憶媒体であって、前記工程は、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第１の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第２の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を含むことを特徴とする、持続性のコンピュータ読み取り可能な記憶媒体。
【請求項１０】
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１１】
ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１２】
前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１３】
前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた１つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの１つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１４】
前記ドナー・エクステントは、前記エントリと関係づけられたエクステントであり、前記レシピエント・エクステントは、前記別のエントリと関係づけられたエクステントである、ことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１５】
前記ドナー・エクステントは、前記別のエントリと関係づけられたエクステントであり、前記レシピエント・エクステントは、前記エントリと関係づけられたエクステントである、ことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１６】
前記第１の予め定められた値は、ゼロよりも大きい値であり、前記第２の予め定められた値はゼロである、ことを特徴とする、請求項９に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１７】
コンピュータ・システムであって、
バスを介してメモリと接続されたプロセッサと、
前記プロセッサによって前記メモリから実行される命令群であって、前記命令群は前記プロセッサに、
前記コンピュータ・システム内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第１の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第２の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放するステップと、を実行させる命令群と、を有するコンピュータ・システム。
【請求項１８】
請求項１７に記載のコンピュータ・システムであって、前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうかの前記判断は、
前記エントリに関係づけられた各データ・ブロックについて、
前記データ・ブロックのフィンガープリントを、前記ログ・データ・コンテナ内の前記別のエントリに関係づけられた各データ・ブロックのフィンガープリントと、比較するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等である場合に、前記データ・ブロック内の各バイトを、前記別のデータ・ブロック内の対応する各バイトと比較するステップと、
前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロック内の対応する各バイトと同等である場合に、前記データ・ブロックは前記別のデータ・ブロックと一致する、と判断するステップと、
前記データ・ブロックの前記フィンガープリントが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの前記フィンガープリントと同等でない場合に、または、前記データ・ブロック内の各バイトが、予め定められた意味で、前記ログ・データ・コンテナ内の前記別のデータ・ブロックの対応する各バイトと同等でない場合に、前記データ・ブロックは前記別のデータ・ブロックと一致しない、と判断するステップと、を含むことを特徴とする、請求項１７に記載のコンピュータ・システム。
【請求項１９】
ドナー・エクステントおよびレシピエント・エクステントの前記決定は、前記エントリの世代と前記別のエントリの世代とに基づくことを特徴とする、請求項１７に記載のコンピュータ・システム。
【請求項２０】
前記ブロック共有の前記実行は、
前記レシピエント・エクステントと関係づけられた内部リファレンス・カウントを、前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを含むように、更新するステップと、
前記ドナー・エクステントと関係づけられた内部リファレンス・カウントを更新するステップと、
新たなエクステント・エントリを作成するステップと、
前記ドナー・エクステントを更新するステップと、
前記レシピエント・エクステントを更新するステップと、を含むことを特徴とする、請求項１７に記載のコンピュータ・システム。
【請求項２１】
前記ドナー・エクステントの前記解放は、
前記ドナー・エクステントに関係づけられた１つまたは複数のデータ・ブロックを解放するステップと、
前記ドナー・エクステントと関係づけられた、エクステント−物理マップの１つまたは複数のエントリを除去するステップと、を含むことを特徴とする、請求項１７に記載のコンピュータ・システム。
【請求項２２】
コンピュータ・システムであって、
ストレージ・デバイスと接続されたストレージ・サーバを有し、前記ストレージ・サーバは、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取り、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられ、複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ログ・データ・コンテナにアクセスし、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリが、前記ログ・データ・コンテナ内の別のエントリと一致するかどうか判断し、
前記エントリが前記ログ・データ・コンテナ内の別のエントリと一致すれば、
ドナー・エクステントおよびレシピエント・エクステントを決定し、
前記レシピエント・エクステントと関係づけられた外部リファレンス・カウントが第１の予め定められた値と等しければ、前記ドナー・エクステントおよび前記レシピエント・エクステントについてブロック共有を行い、
前記ドナー・エクステントと関係づけられた前記リファレンス・カウントが第２の予め定められた値と等しいか判断し、前記ドナー・エクステントを解放する、ことを特徴とする、コンピュータ・システム。
【請求項２３】
コンピュータを用いた方法であって、
ストレージ・サーバが、前記ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を有する方法。
【請求項２４】
持続性のコンピュータ読み取り可能な記憶媒体であって、プロセッサに工程を実行させる実行可能な命令群を備えた記憶媒体であって、前記工程は、
ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を含むことを特徴とする、持続性のコンピュータ読み取り可能な記憶媒体。
【請求項２５】
コンピュータ・システムであって、
バスを介してメモリと接続されたプロセッサと、
前記プロセッサによって前記メモリから実行される命令群であって、前記命令群は前記プロセッサに、
ストレージ・サーバ内の重複データを除去するリクエストを受け取るステップと、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられたログ・データ・コンテナにアクセスするステップであって、前記ログ・データ・コンテナが複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ステップと、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放するステップと、を実行させる命令群と、を有するコンピュータ・システム。
【請求項２６】
コンピュータ・システムであって、
ストレージ・デバイスと接続されたストレージ・サーバを有し、前記ストレージ・サーバは、
前記ストレージ・サーバ内の重複データを除去するリクエストを受け取り、
前記ストレージ・サーバのストレージ・ボリュームと関係づけられ、複数のエントリを含み、各エントリが前記ストレージ・サーバと関係づけられたボリューム内のソートされたデータ構造内のエクステント識別子により識別される、ログ・データ・コンテナにアクセスし、
前記ログ・データ・コンテナ内の各エントリについて、
前記エントリと関係づけられたエクステント識別子が、前記ログ・データ・コンテナ内の別のエントリと関係づけられたエクステント識別子と一致するかどうか判断し、
前記エントリと関係づけられた前記エクステント識別子が前記ログ・データ・コンテナ内の別のエントリと関係づけられた前記エクステント識別子と一致すれば、
前記エントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記別のエントリと関係づけられた前記エクステント識別子のポインタ識別子およびリファレンス・カウントを更新し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが予め定められた値と等しいか、または、前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しいか、を判断し、
前記エントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記エントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放し、
前記別のエントリと関係づけられた前記エクステント識別子の前記リファレンス・カウントが前記予め定められた値と等しければ、前記別のエントリと関係づけられた前記エクステント識別子により識別される前記エクステントを解放する、ことを特徴とする、コンピュータ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ・ストレージ・システムに関し、特に、エクステント・ベース・データ・ストレージ・システム（extent-based data storage system）における重複排除（deduplication）に関する。
【背景技術】
【０００２】
著作権表示／許諾
この特許文献の開示は一部、著作権にもとづく保護の対象となる内容を含んでいる。著作権者は、何者かによる、特許商標庁のファイルまたは記録に記されているとおりの本特許ドキュメントおよび特許情報の開示（patent disclosure）の複製（facsimile reproduction）についてこれに異存がない。だが、そのような場合を除き著作権者はいかなる著作権についてもこれを留保する。次の表示 Copyright (C) 2011, NetApp, Inc., All Rights Reserved （著作権（Ｃ）２０１１、ネットアップ・インコーポレーテッド、著作権所有）は、以下に記載・添付の図面に示されるソフトウェアおよびデータに適用される。
【０００３】
背景
今日、ネットワーク・ベースのストレージ・システム（network-based storage systems）には、様々な形態が存在する。これらには、ネットワークアタッチトストレージ（network attached storage）（ＮＡＳ）、ストレージエリアネットワーク（storage area networks）（ＳＡＮ’ｓ）などが含まれる。通例、ネットワーク・ベースのストレージ・システムの利用目的は様々である。例えば、複数のユーザに対し共有データに対するアクセスを与えたり、（データのミラーリングすることにより）大切なデータをバックアップしたり、といった用途に用いられる。
【０００４】
ネットワーク・ベースのストレージ・システムは、通例、少なくとも１つのストレージ・サーバを備え、このサーバが処理システム（processing system）となって、１つまたは複数のクライアント処理システム（client processing system）（クライアント（clients））に代わってデータの格納（store）および読み出し（retrieve）を行う。ＮＡＳに関し、ストレージ・サーバは、ファイル・サーバでよく、このサーバは時折、「ファイラ（filer）」と呼ばれる。ファイラは、１つまたは複数のクライアントの代わりに共有ファイル（shared file）を格納し管理（manage）するための動作を行う。ファイルは、レイド（ＲＡＩＤ）（リダンダント・アレイ・オブ・インエクスペンシブ・ディスクズ（Redundant Array of Inexpensive Disks））といったデータ格納スキームを用いて、１つまたは複数の、磁気もしくは光学ディスクまたはテープといった大容量（マス）ストレージ・デバイス（mass storage devices）のアレイを備えるストレージ・システムに格納されればよい。さらに、各アレイの大容量ストレージ・デバイスは、１つまたは複数の別個のＲＡＩＤグループに組織されてよい。ＳＡＮに関し、ストレージ・サーバは、格納されているデータに対する、ファイル・レベルのアクセスでない、ブロック・レベルでのアクセスをクライアントに提供する。カリフォルニア州サニーヴェイルのネットアップ・インコーポレーテッド（ＮｅｔＡｐｐ（登録商標））が製作している特定のストレージ・サーバのような、ある種のストレージ・サーバであれば、ファイル・レベルのアクセスと、ブロック・レベルのアクセスとの両方を、クライアントに提供することも可能である。
【０００５】
図１は先行技術例としてのライト・エニウェア・ファイル・レイアウト（Write Anywhere File Layout）（ＷＡＦＬ）ファイルシステムの実施例を示す。図１を参照すると、ＷＡＦＬアグリゲート１００は、ＷＡＦＬファイルシステムのインスタンスである。ＷＡＦＬアグリゲート１００は、１つまたは複数のフレキシブル・ボリューム１１０と、１つまたは複数のボリューム・コンテナ１２０と、物理ストレージ１３０と、を備える。
【０００６】
ＷＡＦＬアグリゲート１００は、ＷＡＦＬファイルシステムでデータを格納することができる物理ストレージ・コンテナである。フレキシブル・ボリューム１１０は、物理ストレージ１３０上においてボリュームのアロケーションの仮想化を可能にする論理ボリュームである。これにより、従属的に管理されるフレキシブル・ボリューム１１０は、同一の物理ストレージ（例えば、物理ストレージ１３０）を共有することができる。物理ストレージ１３０に格納されたデータにアクセスするために、この仮想化では、フレキシブル・ボリューム１１０が使用する仮想ボリュームのブロックナンバー（ＶＶＢＮｓ）と、ＷＡＦＬアグリゲート１００が使用する物理ボリュームのブロックナンバー（ＰＶＢＮｓ）とのマッピングが必要である。本明細書では、ＰＶＢＮは、アグリゲート（集合体）内の線的な単一のシークエンス（a single linear sequence）に抽象化されたディスクのブロックを指す。ボリューム・コンテナ１２０は、それぞれ、フレキシブル・ボリューム１１０と対応する。ボリューム・コンテナ１２０は、対応するフレキシブル・ボリューム１１０に関する全てのデータ・ブロックを含んでいる。
【０００７】
本明細書では、ブロック・オフセット、または、オフセットは、ボリューム、ファイル、エクステント等といったストレージのオブジェクトの始まりからの（from beginning）ブロック単位での距離（a distance in blocks）を指す。フレキシブル・ボリューム１１０内で用いられるブロック・アドレスは、ボリューム・コンテナ１２０内でのブロック・オフセットを指す。ボリューム・コンテナ１２０は、フレキシブル・ボリューム１１０内のあらゆるブロックを含むため、特定のブロックのロケーション（位置）の参照には２通りの方法がある。ＰＶＢＮは、ＷＡＦＬアグリゲート１００内でのブロックのロケーションを規定する。ＶＶＢＮは、コンテナ・ファイル内でのブロックのオフセットを規定する。あるファイルの中のあるブロックが要求（リクエスト）されると、フレキシブル・ボリューム１１０は、ファイルのオフセットを、ＶＶＢＮにトランスレート（変換）する。ＶＶＢＮは、フレキシブル・ボリューム１１０からボリューム・コンテナ１２０へ渡される（パスされる）。ボリューム・コンテナ１２０は、ＶＶＢＮを、ＰＶＢＮへトランスレートする。そして、ＰＶＢＮが用いられて物理ストレージ１３０内のリクエストされたブロックにアクセスする。また、ＰＶＢＮが初めて（initially）書き込まれるときは、フレキシブル・ボリューム１１０内のＰＶＢＮに対するブロック・ポインタが、ＶＶＢＮについてのＰＶＢＮを（例えばキャッシュに）収録（include）するようにして、書き込まれる。そうすることで、リクエストされたブロックを必要とするときに、フレキシブル・ボリューム１１０は、格納されたＰＶＢＮを用いて物理ストレージ１３０にアクセスすることが可能になる。
【０００８】
現行のＷＡＦＬの実装では、ファイルは、間接的なブロック（indirect blocks）のツリーとして定義される。ツリーに含まれる間接的なブロックはそれぞれが固定的な長さ（スパン、span）を有し、これは、固定された数のエントリ（entries）であって、それぞれがツリーに含まれる別のブロックをポイントする。その規模（エクステント、extents）は、当該エクステントに含まれるブロックそれぞれのエントリを用いて表現される。本明細書では、エクステント（extent）は、１つまたは複数の隣接するブロックからなるグループ（a contiguous group of one or more blocks）を指す。結果的には、間接的なブロックのメタデータの量（アマウント、amount）がファイルのサイズに比例（linear）する。また、セグメントのクリーニング（segment cleaning）やファイルの再割り当て（ファイル・リアロケーション、file reallocation）といったディスク・ガーデニング（disk gardening）の技術は、ＶＶＢＮブロックにおけるＰＶＢＮポインタをキャッシュするため、複雑である。
【０００９】
ストレージ・システムは、しばしば、全ての内的操作（internal operations）に予め定めたブロックサイズを用いる。ちょうど、クライアント側（client-side）のファイルシステム（file system）が、ファイル・ブロック数（ファイル・ブロック・ナンバー、file block numbers）（ＦＢＮ）についてするように、例えば、ＷＡＦＬは、ＶＶＢＮおよびＰＶＢＮの両方について４ＫＢの（例えば４０９６バイトの）ブロックを用いる。ブロックの境界（ブロック・バウンダリ、block boundaries）は、最初のオフセット（例えば、ＦＢＮ  ０）から、４ＫＢ毎に生じることが予想される。ファイルシステムは通例、個々のファイルのブロック・バウンダリに基づいて個々のファイルのオフセットを設けるため、アプリケーションの書き込み手段（ライタ、writers）は、ファイルシステムのブロックサイズおよび配置（アラインメント）を巧みに利用して入出力（「Ｉ／Ｏ」）のための操作のパフォーマンスを向上させている。例えば、常時、４ＫＢの倍数でＩ／Ｏ操作を行ったり、常時、それらの操作をファイルの開始部（beginning）に合わせたりしている。仮想マシン（ヴァーチャル・マシン、virtual machine）のような他のファイルシステムやアプリケーションでは、異なるサイズのブロック・バウンダリを用いることも可能である。（例えば、仮想マシン環境においては、５１２バイトからなる初期マスター・ブート・レコード・ブロックの後に４ＫＢのブロックが複数続く。）これによってＦＢＮのそれとＰＶＢＮのそれとの間にずれ（ミスアラインメント、misalignment）が発生する。また、複数の仮想マシンが、単一のボリューム・コンテナ１２０を共有することも可能であるから、個々の仮想マシンにおいて異なる大きさのずれが生じる可能性がある。
【００１０】
ストレージ・サーバは、重複排除アルゴリズム（デダプリケーション・アルゴリズム、deduplication algorithm）を実装可能である。デダプリケーションによりデータ・ストレージ内に格納された冗長なデータのコピーが解消される。デダプリケーションは、様々な方法で実行される。その中には、階層的重複排除（hierarchical deduplication）、インライン重複排除（in-line deduplication）、バックグラウンド重複排除（background deduplication）が含まれる。
【００１１】
階層的重複排除には、別のファイルから或るファイルを得る過程を含んでいる。通例、ファイルが他方のコピーとして始まっているファイルを用いるが、ゼロのバイトあるいはほぼゼロのバイト群のデータも実際にコピーされたり移動されたりする。その代わり、２つのファイルが、データ・ストレージ内の同じブロックを共有する。その例としてはスナップショット（snapshot）がある。スナップショットは、ファイルシステムで構成されており、スナップショットが作成された時点においてスナップショットと動作中のファイルシステムとは同じであって同一のデータ・ストレージを共有する。よって、データの移動をゼロまたはほぼゼロのままに抑えつつ効率よくコピーされる。もとの（ソースとなった、source）ファイルシステムが変更されると、データ・ストレージにおいて共有されるブロックの数は減少する。この例は、ファイルシステムを取り込む、書き込み可能スナップショット（writable snapshot）である（クローン（clone）とも称される）。この例では、ソースのファイルシステムおよびクローンのファイルシステムが変更を受けるにつれ、共有されるブロックが減少する。
【００１２】
インライン重複排除は、書き込み操作によりコンテントを作成するストレージ・アクセス・プロトコル・イニシエータ（storage access protocol initiator）（例えば、ＮＦＳクライアント）を備え、ストレージ・アクセス・プロトコルのターゲットは、書き込まれようとしているコンテントが、ターゲットのストレージ上のどこか別の場所と重複しているかどうか、をチェックする。もし重複しているならば、データは書き込まれない。あるいは、（例えば、メタデータ、ポインタ等のような）論理コンテント（logical content）が当該重複に言及する。
【００１３】
バックグラウンド重複排除は、重複ブロックをスキャンし、１つを除く全ての重複を解放し（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）が予め定められた第１の値に等しいならば、当該ドナー・エクステントおよびレシピエント・エクステントの間でブロック共有（ブロック・シェアリング、block sharing）が実行される。ドナー・エクステントにかかる上記のリファレンス・カウントが予め定められた第２の値と等しいかどうか、判断される。もし、ドナー・エクステントのリファレンス・カウントが、当該予め定められた第２の値と等しいならば、当該ドナー・エクステントは解放される。
【００１６】
本発明は、添付図面の図により例示的に説明されるものであって、それらに限定されない。
【図面の簡単な説明】
【００１７】
【図１】従来技術によるライト・エニウェア・ファイル・レイアウト（ＷＡＦＬ）の実装例の形態を説明する図である。
【図２Ａ】重複排除を実装可能なネットワーク・ストレージ・システムを説明する図である。
【図２Ｂ】代替的実施形態において重複排除を実装可能なネットワーク・ストレージ・システムの分散型またはクラスタ型（distributed or clustered）アーキテクチャを説明する図である。
【図３】重複排除を実装可能なストレージ・サーバのハードウェア・アーキテクチャの形態例を示すブロック図である。
【図４】重複排除を実装可能な、図３にかかるストレージ・オペレーティング・システムの実施形態を説明する図である。
【図５】エクステント・ベース・ストレージ・アーキテクチャの例のブロック図である。
【図６】エクステント・ベース・ストレージ・アーキテクチャ内のソートされたエクステント・ベース・データ・ストラクチャ（extent-based sorted data structure）の例を説明する図である。
【図７】間接ボリューム（インダイレクト・ボリューム、indirect volume）を実装する際に用いられる、図６にかかるエクステント・ベース・データ・ストラクチャの葉ノード（リーフ・ノード、leaf node）についてのボリューム層間接エントリ（ボリューム・レイヤ・インダイレクト・エントリ、volume layer indirect entry）の例を示す図である。
【図８】エクステント−物理ブロック・マップを実装する際に用いられる、図６にかかるエクステント・ベース・データ・ストラクチャのリーフ・ノードについてのエクステント・マップ・エントリ（extent map entry）の例を示す図である。
【図９】ＦＢＮよりＰＶＢＮまでのマッピングのためにエクステント・ベース・ストレージ・アーキテクチャのボリューム層（ボリューム・レイヤ、volume layer）およびアグリゲート層（アグリゲート・レイヤ、aggregate layer）で行う探索（ルックアップ、look ups）のシークエンスの例を示す図。
【図１０】ＦＢＮよりＰＶＢＮまでのマッピングのためにエクステント・ベース・ストレージ・アーキテクチャのボリューム・レイヤおよびアグリゲート・レイヤで行うルックアップのシークエンスの別例を示す図。
【図１１】実施形態による、エクステント・ベース・アーキテクチャにおける重複排除の方法のフローを例示する図。
【図１２】別の実施形態による、エクステント・ベース・アーキテクチャにおける重複排除の方法のフローを例示する図。
【図１３】実施形態による、ブロック共有（ブロック・シェアリング、block sharing）方法のフローを例示する図。
【図１４】実施形態による、エクステント法（extent method）での解放過程（freeing）のフローを例示する図。
【発明を実施するための形態】
【００１８】
以下の本発明の実施形態にかかる詳細な説明においては、添付の図面を参照する。該図面においては、類似の要素に同様の参照記号を付す。また、該図面は、本発明を実施することが可能な特定の実施形態を例示するものである。これらの実施形態については、当業者が本発明を実施するのに十分な程度に詳細に説明される。だが、その他の実施形態や、論理的、機械的、電気的、機能的な変更、および、その他の変更も、本発明の範囲を逸脱することなく実施することができる。それゆえ、以下の詳細な説明を限定的な意味に捉えることは適当でなく、本発明の範囲はクレームによってのみ規定される。
【００１９】
実施形態では、エクステント・ベース・アーキテクチャにおける重複排除について記載する。本明細書中の「ある実施形態」、「ある１つの実施形態」等といった言及は、記載された特定の特徴、構造、特性が本発明の少なくとも１つの実施形態に含まれることを意味する。上述の文言は、本明細書においては、必ずしも同一の実施形態を指すものではなく、相互排他的（mutually exclusive）でもない。
【００２０】
エクステント・ベース・アーキテクチャにおける重複排除は、ストレージ・サーバ中の重複データを除去する要求（リクエスト）を受けて実行される。ストレージ・サーバ内のストレージ・ボリュームに関連づけされたログ・データ・コンテナがアクセスされる。ログ・データ・コンテナには、複数のエントリが含まれている。各エントリは、ストレージ・サーバと関連づけされたボリュームに格納されたデータ・ストラクチャ内のエクステント識別子（エクステント・アイデンティファイア、extent identifier）により識別される。ログ・データ・コンテナ内の各エントリに関し、当該ログ・データ・コンテナ内の別のエントリと一致するかどうかが判断される。エントリが、ログ・データ・コンテナ内の別のエントリと一致すれば、提供者エクステント（ドナー・エクステント）および被提供者エクステント（レシピエント・エクステント）が決定される。レシピエント・エクステントと関連づけされた外部参照カウント（エクスターナル・リファレンス・カウント）が、予め定められた第１の値と等しいならば、ドナー・エクステントおよびレシピエント・エクステントについて、ブロック共有（ブロック・シェアリング）が実行される。ドナー・エクステントのリファレンス・カウントが、予め定められた第２の値と等しいかどうかが判断される。ドナー・エクステントのリファレンス・カウントが、予め定められた第２の値と等しければ、当該ドナー・エクステントは解放される（freed）。エクステント・ベース・アーキテクチャにおける重複排除は、データの到来に対しインラインで実行される必要はない。それゆえ、エクステント・ベース・アーキテクチャにおける重複排除は、データが書き込まれた後で実行される。また、エクステントといった、当該データに付随するメタデータについても重複排除可能であり、よって、さらなるスペース効率（space efficiency）の向上が可能である。
【００２１】
図２Ａは、ある１つの実施形態により重複排除が実装されたネットワーク・ストレージ・システムの図である。ストレージ・サーバ２１０（ストレージ・サーバ２１０Ａ，２１０Ｂ）はそれぞれ、複数の、大容量ストレージ・デバイスを擁するストレージ・ユニット（ストレージ２７０Ａ，２７０Ｂ）を管理する。これらストレージ・サーバは、１つまたは複数のクライアント２０２に対し、ネットワーク２３０を介してストレージ・サービスを提供する。ネットワーク２３０は、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、インターネットのようなグローバル・エリア・ネットワーク、ファイバーチャネルのファブリック、あるいは、これらの相互接続からなる結合体、でよい。各クライアント２０２は、例えば、従来型のパーソナル・コンピュータ（ＰＣ）、サーバクラスのコンピュータ、ワークステーション、ハンドヘルド型のコンピューティングもしくは通信のためのデバイス、その他の専用もしくは汎用コンピュータ、でよい。
【００２２】
ストレージ・ユニット２７０におけるデータの格納（ストレージ）は、ストレージ・サーバ２１０によって管理される。ストレージ・サーバ２１０は、ストレージ・ユニット２７０に格納されているデータもしくは格納されるべきデータに対するクライアントからの様々な読み出しおよび書き込み要求（リード・リクエストおよびライト・リクエスト）を受け、これに答える。ストレージ・ユニット２７０は、大容量ストレージ・デバイスを構成する。大容量ストレージ・デバイスは、例えば、フラッシュ・メモリ、磁気もしくは光学ディスク、または、テープ・ドライブ、を含むことができ、ディスク２７１（２７１Ａ，２７１Ｂ）として示される。ストレージ・デバイス２７１は、さらに、（図示しない）アレイ状に組織化されてレイド・スキーム（Redundant Array of Inexpensive Disks/Devices scheme、ＲＡＩＤ scheme）を実装することも可能であり、そうすることにより、ストレージ・サーバ２１０は、当技術分野において周知の１つまたは複数のＲＡＩＤプロトコルを用いてストレージ・ユニット２７０にアクセスする。
【００２３】
ストレージ・サーバ２１０は、ネットワークアタッチトストレージ（ＮＡＳ）環境で用いられるようなファイル・レベルのサービスや、ストレージエリアネットワーク（ＳＡＮ）環境で用いられるようなブロック・レベルのサービスや、ファイル・レベルおよびブロック・レベルのサービスの両方を提供可能なサービスや、別のデータ・アクセス・サービスを提供可能な他のサービスを、提供可能である。図２Ａにおいては、ストレージ・サーバ２１０は、それぞれ単一のユニットのように示されているが、別の実施形態においては、ストレージ・サーバは、別個のネットワーク要素もしくはモジュール（「Ｎ−モジュール」）ならびにディスク要素もしくはモジュール（「Ｄ−モジュール」）を構成することもできる。ある１つの実施形態においては、Ｄ−モジュールは、クライアントのリクエストにサービス（servicing）するストレージ・アクセス・コンポーネント（storage access components）を備える。対照的に、Ｎ−モジュールは、クライアントがストレージ・アクセス・コンポーネント（例えば、Ｄ−モジュール）にアクセスすることを可能にする機能を備え、さらに、コモン・インターネット・ファイルシステム（ＣＩＦＳ、Common Internet File System）、ネットワーク・ファイルシステム（ＮＦＳ、Network File System）、といったプロトコル・コンポーネントや、インターネット・プロトコル（ＩＰ）モジュールを備えて接続性を向上させてもよい。Ｄ−モジュールやＮ−モジュールを含む分散型アーキテクチャ環境の詳細については、以下で図２Ｂに関して説明し、Ｄ−モジュールおよびＮ−モジュールに関する実施形態については、図４に関してさらに詳細に説明する。
【００２４】
さらに別の実施形態においては、ストレージ・サーバ２１０はネットワーク・ストレージ・サブシステム（network storage subsystems）と称される。ネットワーク・ストレージ・サブシステムは、特定のアプリケーションまたは目的について、ネットワーク化されたストレージ・サービスを提供する。ここでのアプリケーションの例としては、データベース・アプリケーション、ウェブ・アプリケーション、企業資源計画（ＥＰＲ、Enterprise Resource Planning）アプリケーション等を含み、これらは例えばクライアント内に実装される。ここでの目的の例としては、ファイルのアーカイビング、バックアップ、ミラーリング等を含み、これらは、例えば、主ストレージ・サーバ（プライマリ・ストレージ・サーバ）に接続されたアーカイブ用、バックアップ用、あるいは、副次的ストレージ・サーバ（セカンダリ・ストレージ・サーバ）上で実現される。ネットワーク・ストレージ・サブシステムは、複数のストレージ・サーバおよび／またはストレージ・ユニットから横断的に集められたネットワーク・リソースの集合体により実装することも可能である。
【００２５】
図２Ａの実施形態においては、ストレージ・サーバの１つ（例えば、ストレージ・サーバ２１０Ａ）が、クライアント２０２に対する、データ・ストレージ・サービスの主たる提供者（primary provider）として機能する。１つもしくは複数のストレージ・オブジェクトとして組織化されたディスク２７１Ａを用いて、クライアント２０２からのデータ格納要求（データ・ストレージ・リクエスト）に対するサービスが行われる。セカンダリ・ストレージ・サーバ（例えば、ストレージ・サーバ２１０Ｂ）は、プライマリ・ストレージ・サーバとのミラー関係における交代要員（standby role）として動作し、プライマリ・ストレージ・サーバからのストレージ・オブジェクトを、セカンダリ・ストレージ・サーバ（例えば、ディスク２７０Ｂ）のディスク上に編成されたストレージ・オブジェクトに複製（レプリケート、replicating）する。動作中、セカンダリ・ストレージ・サーバは、プライマリ・ストレージ・サーバが災害（disaster）見舞われるような、プライマリ・ストレージ・オブジェクトのデータに対するアクセス不能になるまで、クライアント２０２からのリクエストに対しサービスを提供しない。このような事象は、プライマリ・ストレージ・サーバにおける障害（failure）とみなされる。プライマリ・ストレージ・サーバに障害が発生すると、プライマリ・ストレージ・オブジェクトに向けられたクライアント２０２からのリクエストについては、複製データ（レプリケーテッド・データ）（つまり、セカンダリ・ストレージ・オブジェクト）を用いてセカンダリ・ストレージ・サーバがサービスを行う。
【００２６】
明らかなことだが、他の実施形態では、ネットワーク・ストレージ・システム２００は、２よりも多くのストレージ・サーバを備えてよい。その場合、システム２００内の様々なストレージ・サーバ間で、保護関係（プロテクション・リレーションシップ、protection relationships）を稼働させることができ、そうすることで、ストレージ・サーバ２１０Ａの１つまたは複数のプライマリ・ストレージ・オブジェクトが、ストレージ・サーバ２１０Ｂ以外のストレージサーバ（不図示）に複製可能である。さらに、セカンダリ・ストレージ・オブジェクトが他のストレージ・オブジェクトと保護関係を結び、当該セカンダリ・ストレージ・オブジェクトが例えば三次的ストレージ・オブジェクト（ターシャリ・ストレージ・オブジェクト、tertiary storage objects）に複製されるようにして、セカンダリ・ストレージ・オブジェクトにかかる障害からの保護を設けてもよい。よって、ストレージ・サーバ２１０のプライマリおよびセカンダリ・ストレージ・オブジェクトの間の単段的（single-tier）保護関係の説明は、例示のみを目的としていると解すべきである。
【００２７】
図２Ｂは、分散型もしくはクラスタ型のネットワーク・ストレージ・システム２２０のブロック図である。当該システムは、ある１つの実施形態において高速クローニング（ラピッド・クローニング、rapid cloning）を実装することができる。システム２２０は、ノード２１０（ノード２１０Ａ，２１０Ｂ）として実装されるストレージ・サーバを備えることができる。各ノードは、ストレージ・デバイス２７１に対するアクセスを提供する。図２Ｂにおいて、ノード２１０は、クラスタ・スイッチング・ファブリック２２５により相互接続されている。クラスタ・スイッチング・ファブリックは、イーサネット・スイッチ（Ethernet switch）で実現されてよい。
【００２８】
ノード２１０は、多機能コンポーネントとして動作することができ、該コンポーネントによって、システム２２０にかかる分散型アーキテクチャが実現されている。当該目的のため、各ノード２１０は、ネットワークの要素もしくはモジュール（Ｎ−モジュール２２１Ａ，２２１Ｂ）、ディスク要素もしくはモジュール（Ｄ−モジュール２２２Ａ，２２２Ｂ）、ならびに、管理（マネージメント）要素もしくはモジュール（Ｍ−ホスト（host）２２３Ａ，２２３Ｂ）として構造化（オーガナイズ）されてよい。ある１つの実施形態においては、各モジュールは、モジュールそれぞれの作用を実現するために、プロセッサおよびメモリを備えている。例えば、Ｎ−モジュール２２１は、ノード２１０をネットワーク２３０越しにクライアント２０２と接続可能にする機能を有してよく、かつ、メディア・アクセス層（メディア・アクセス・レイヤ、media access layer）、インターネット・プロトコル（ＩＰ）層（インターネット・プロトコル・レイヤ、Internet Protocol layer）、トランスポート・コントロール・プロトコル（ＴＣＰ）層（トランスポート・コントロール・プロトコル・レイヤ、Transport Control Protocol）、ユーザ・データグラム・プロトコル（ＵＤＰ）層（ユーザ・データグラム・プロトコル・レイヤ、User Datagram Protocol layer）、ならびに、当技術分野において周知の他のプロトコルといった、プロトコル・コンポーネントを備えてよい。
【００２９】
対照的に、Ｄ−モジュール２２２は、クラスタ・スイッチング・ファブリック２２５を介して１つまたは複数のストレージ・デバイス２７１と接続することが可能であり、かつ、デバイス２７０に対するアクセス・リクエストに対するサービスを提供するために動作可能である。ある１つの実施形態においては、Ｄ−モジュール２２２は、エクステント・ベース・ストレージ・アーキテクチャ４９５を実装する。これについては、後で詳述する。ある１つの実施形態においては、Ｄ−モジュール２２２は、多プロトコル・データ・アクセス（multi-protocol data access）（例えば、コモン・インターネット・ファイルシステム・プロトコル（Common Internet File System protocol）、ネットワーク・ファイルシステム・プロトコル（Network File System protocol）、ハイパーテキスト・トランスファー・プロトコル（Hypertext Transfer Protocol））をサポートするストレージ抽象化層（ストレージ・アブストラクション・レイヤ、storage abstraction layer）、ストレージ・プロトコル（storage protocol）（例えば、ＲＡＩＤプロトコル）を実装するストレージ層（ストレージ・レイヤ、storage layer）、ストレージ・デバイス・プロトコル（storage device protocol）（例えば、スモール・コンピュータ・システムズ・インタフェース・プロトコル（Small Computer Systems Interface protocol））を実装するドライバ層（ドライバ・レイヤ、driver layer）といった、ストレージ・アクセスのための工程を支援する動作を行うストレージ・アクセス・コンポーネント（storage access components）を備える。図２Ｂに示す実施形態においては、Ｄ−モジュールのストレージ・アブストラクション・レイヤ（例えば、ファイルシステム）は、デバイス２７０の物理ストレージを複数のストレージ・オブジェクトに分割（ディバイド、divides）する。ノード２１０が（例えば、Ｎ−モジュール２２１を介して）受け取ったリクエストには、リクエストが実行されるべきストレージ・オブジェクトを示すストレージ・オブジェクト識別子（アイデンティファイア）が含まれてよい。
【００３０】
他にノード２１０上で動作可能なものにＭ−ホスト２２３がある。これは、例えばシステム２２０全体にわたる、分散化ストレージ・システム・イメージを支援する動作を行うことによりノード２１０に関するクラスタ・サービスを提供する。ＲＤＢ２２４（ＲＤＢ２２４Ａ，２２４Ｂ）といった、どのＤ−モジュール２２２が各ストレージ・オブジェクト「を所有している」（"owns"）（のサービスを提供している）のかを判断するためにＮ−モジュール２２１が使用する情報を含んだデータ構造（データ・ストラクチャ、data structure）をＭ−ホスト２２３が管理することで、Ｍ−ホスト２２３はクラスタ・サービスを提供する。複数のノード２１０それぞれにかかるＲＤＢ２２４の様々なインスタンスは、Ｍ−ホストが（例えば、ネットワーク２３０全体にわたって）Ｍ−ホスト同士の間で動作する従来型のプロトコルを用いて互いを同期化することで定期的に更新されればよい。Ｎ−モジュール２２１が受け取ったクライアントのリクエストは、分散型ストレージ・システム・イメージの提供サービスを行う適当なＤ−モジュール２２２へルーティングされる。
【００３１】
注記するが、図２Ｂには例示のシステム内のノードを構成する同数のＮ−モジュールおよびＤ−モジュールが図示されるが、高速クローニングの様々な実施形態においては、ノードを構成するＮ−モジュールおよびＤ−モジュールの数が異なってもよい。例えば、ノード２１０Ａを構成するＮ−モジュールおよびＤ−モジュールの数が、ノード２１０ＢのＮ−およびＤ−モジュールとの間で一対一対応の関係を示さなくともよい。そのような理由で、各ノードが１つのＮ−モジュールおよび１つのＤ−モジュールを有するというノードに関する記載は、例示のみを目的としていると解されるべきである。
【００３２】
また、図２Ａ−図２Ｂに関する記載は、上述した本発明にかかる方法を実施するのに適したコンピュータ・ハードウェアおよび他の動作コンポーネントを概観するためのものであって、適用可能な環境を限定することを目的としたものではない。当業者であれば、別のコンピュータ・システムの構成でも本発明を実施可能であることを直ちに理解するであろう。本発明は、通信ネットワークでリンクした遠隔の（リモートの）処理装置によってタスクが処理されるような、分散型コンピュータ環境（distributed computing environments）においても実施可能である。
【００３３】
当業者には明らかなことだが、キーボード、ポインティング・デバイス、ディスプレイといった入／出力デバイスをストレージ・サーバに接続してもよい。これらの従来型の特徴については、明瞭さを目的として示されていない。
【００３４】
図３は、図２Ａのストレージ・サーバ２１０Ａ，２１０Ｂのようなストレージ・サーバの実施形態のブロック図である。ここでは、該サーバは、プロセッサ３０２、メモリ３１０、ネットワーク・アダプタ３２０、ユーザ・コンソール３１２、および、ストレージ・アダプタ３４０を備え、それらが、従来型ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ、Peripheral Component Interconnect）のようなシステム・バス３５０で相互接続されている、汎用または専用のコンピュータとして実装される。
【００３５】
メモリ３１０は、プロセッサ３０２、ネットワーク・アダプタ３２０、および、ストレージ・アダプタ３４０によりアドレス指定可能なストレージ・ロケーションを備える。これは、プロセッサが実行可能な命令や高速クローニングに付随するデータ・ストラクチャを格納する。ストレージ・オペレーティング・システム３１４は、一般に、部分的にメモリ３１０に常駐されプロセッサ３０２により実行され、ストレージ・サーバによって提供されるストレージ・サービスを支援する動作を起動することにより、機能面でストレージ・サーバを構成する。当業者にとっては明らかなことだが、別の処理手段を用いて命令を実行してもよいし、様々なコンピュータ読み取り可能な媒体を含むメモリ手段を用いて、本明細書で説明される創意溢れる技術に関係するプログラム命令群を格納してもよい。また、これも明らかなことだが、プロセッサ３０２および実行可能なソフトウェアの機能のいくつかまたは全ては、プログラマブル・ロジック・アレイやＡＳＩＣに構成された統合型カレント（integrated currents）のようなハードウェアで実装可能である。
【００３６】
ネットワーク・アダプタ３２０は、１つまたは複数のポートを備え、それによりストレージ・サーバと、１つまたは複数のクライアントとを、２地点間接続（ポイント・ツー・ポイント・リンク、point-to-point link）またはネットワーク経由で接続する。よって、ネットワーク・アダプタ３２０は、ストレージ・サーバと、１つまたは複数のクライアントとを、ネットワーク経由で接続するために必要な、機械的でかつ、電気的な、信号伝達のための回路である。各クライアントは、ＴＣＰ／ＩＰのような所定のプロトコルに従って離散的なデータのフレームまたはパケットを交換することにより、ネットワーク経由で、ストレージ・サーバと通信を行うことができる。
【００３７】
ストレージ・アダプタ３４０は、入出力（Ｉ／Ｏ）インタフェース回路を備えた複数のポートを有し、もって、ストレージ・デバイス（例えば、ディスク）と、バス３２１とを、従来型の高性能ＦＣやＳＡＳリンク・トポロジのようなＩ／Ｏ相互接続アレンジメントを介して接続する。ストレージ・アダプタ３４０は通例、デバイス・コントローラ（不図示）を備える。デバイス・コントローラは、プロセッサおよびメモリを備え、ストレージ・オペレーティング・システム３１４から受け取った読み出し（リード）コマンドおよび書き込み（ライト）コマンドに従ってストレージ・ユニットの動作を包括的に制御する。ある１つの実施形態においては、ストレージ・オペレーティング・システム３１４は、エクステント・ベース・ストレージ・アーキテクチャ４９５を実装する。これについては、後で詳細に説明する。本願明細書では、ライト・コマンドに応じてデバイス・コントローラが書き込んだデータを「ライト・データ」（"write data"）と称し、リード・コマンドに応じてデバイス・コントローラが読み出したデータを「リード・データ」（"read data"）と称する。
【００３８】
アドミニストレータは、ユーザ・コンソール３１２によりストレージ・サーバとのインタフェースが可能になり、コマンド・ライン・インタフェース（ＣＬＩ）またはグラフィカル・ユーザ・インタフェース（ＧＵＩ）を用いてストレージ・サーバを動作させたり、入力したりする。ある１つの実施形態においては、ユーザ・コンソール３１２は、モニタおよびキーボードを用いて実装される。
【００３９】
図２Ｂのクラスタ２２０のように、クラスタのノードとして実装される場合には、ストレージ・サーバはさらに、クラスタ・アクセス・アダプタ３３０（細線（phantom）で図示。）を有する。該アダプタは、１つまたは複数のポートを備え、もって、該ノードと、クラスタ内の他のノードとを、接続する。ある１つの実施形態においては、イーサネット（Ethernet）を、クラスタリング・プロトコルおよび相互接続媒体として用いる。当業者には明らかなことだが、当該クラスタ・アーキテクチャ内で別種のプロトコルおよび相互接続体を用いることも可能である。
【００４０】
図４は、図３のストレージ・オペレーティング・システム３１４のようなストレージ・オペレーティング・システムのブロック図である。該システムは、重複排除の実施形態を実現する。ストレージ・オペレーティング・システムは、図３のプロセッサ３０２のようなプロセッサが実行する一連のソフトウェアの層（ソフトウェア・レイヤ、software layer）を有し、統合的ネットワーク・プロトコル・スタック（integrated network protocol stack）を構成する。より概括的には、ブロックおよびファイルアクセス・プロトコルを用いてストレージ・サーバに格納されている情報にアクセスするためのデータ・パス（data path）をクライアントに提供する多プロトコル・エンジン（マルチプロトコル・エンジン、multi-protocol engine）４２５を構成する。
【００４１】
多プロトコル・エンジン４２５は、ネットワーク・ドライバ（例えば、ギガビット・イーサネット・ドライバ）のメディア・アクセス・レイヤ４１２を備える。該レイヤは、ＩＰレイヤ４１４ならびにそれを支援するトランスポート機構すなわちＴＣＰレイヤ４１６およびユーザ・データグラム・プロトコル（ＵＤＰ）４１５のようなネットワーク・プロトコル・レイヤとのインタフェースを構成する。ファイルシステム・プロトコル・レイヤは、マルチプロトコル・ファイルアクセスを提供するが、そのためにダイレクト・アクセス・ファイルシステム（ＤＡＦＳ、Direct Access File System）プロトコル４１８、ＮＦＳプロトコル４２０、ＣＩＦＳプロトコル４２２、および、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ、Hypertext Transfer Protocol）プロトコル４２４に対するサポートを備えている。ＶＩレイヤ４２６は、ＶＩアーキテクチャを実装することにより、ＲＤＭＡのような、ＤＡＦＳプロトコル４１８が要請するダイレクト・アクセス・トランスポート（ＤＡＴ、direct access transport）機能を提供する。ｉＳＣＳＩドライバ・レイヤ４２８は、ＴＣＰ／ＩＰネットワーク・プロトコル・レイヤを経由したブロック・プロトコル・アクセスを提供し、ＦＣドライバ・レイヤ４３０は、ストレージ・サーバへブロック・アクセス・リクエストを送信したりストレージ・サーバから応答を受信したりする。或る例では、ファイバ・チャネル・オーバー・イーサネット（ＦＣｏＥ、Fibre Channel over Ethernet）レイヤ（不図示）を多プロトコル・エンジン４２５内で動作させてもよく、該レイヤに、ストレージ・サーバに対しリクエストを送信させ応答を受信させてもよい。ストレージ・サーバのブロックにアクセスする際、ＦＣドライバおよびｉＳＣＳＩドライバは、それぞれ、ブロックに対する、ＦＣ固有アクセス・コントロール（FC-specific access control）およびｉＳＣＳＩ固有アクセス・コントロール（iSCSI-specific access control）を提供し、よって、ＬＵＮ（luns）のｉＳＣＳＩもしくはＦＣＰへのエキスポート、または、ｉＳＣＳＩおよびＦＣＰの両方へのエキスポートを管理する。
【００４２】
ストレージ・オペレーティング・システムは、ストレージ・サーバ４６５を構成するために編成された一連のソフトウェアの層も備える。これがストレージ・デバイスに格納された情報にアクセスするためのデータ・パス（data path）を提供する。情報には、ストレージ・サーバの動作をサポートするためにストレージ・オペレーティング・システムがアクセスするプログラム・アプリケーションのデータやその他のシステム・データのようなデータの他、クライアントから受け取ったデータが含まれてもよい。好ましくは、クライアントのデータは、１つまたは複数の論理ストレージ・オブジェクト（ロジカル・ストレージ・オブジェクト）（例えば、ボリューム）として構成されてよい。これには、全体的な論理アレンジメント（overall logical arrangement）を共同して規定するストレージ・デバイスの収集体（コレクション、collection）が含まれている。ある１つの実施形態においては、論理アレンジメントは、論理ボリューム・ブロック数（ｖｂｎ）空間（ロジカル・ボリューム・ブロック・ナンバー・スペース、logical volume block number spaces）を含んでよい。ここでは、各ボリュームが、ユニークな（固有の、一意的な）ｖｂｎと関連づけされている。
【００４３】
ファイルシステム４６０は、（ＳＣＳＩターゲット・モジュール４３５のように図示される）１つまたは複数の仮想化モジュールの相互作用を通じてストレージ・オペレーティング・システムの仮想化システムを実施する。ＳＣＳＩターゲット・モジュール４３５は、通例、ドライバ４２８，４３０と、ファイルシステム４６０との間に配置されてブロック（ｌｕｎ）空間（ブロック（ｌｕｎ）スペース、block (lun) space）と、ファイルシステム空間（ファイルシステム・スペース、file system space）との間のトランスレーション層（トランスレーション・レイヤ、translation layer）を提供する。この場合、ｌｕｎは、ブロックとして表現される。ある１つの実施形態においては、ファイルシステム４６０は、例えば４キロバイト（ＫＢ）のブロックを用いるブロック・ベースのオンディスクフォーマットの表現（レプリゼンテーション、representation）を有しかつファイルおよび（作成時刻（creation time）、アクセス許可（access permissions）、サイズ（size）、ブロック位置（ロケーション）（block location））といったファイル属性（アトリビュート、attributes）を識別するためにインデックス・ノード（「アイ・ノード」（"inodes"））のようなデータ構造を用いるＷＡＦＬ（ライト・エニウェア・ファイル・レイアウト）ファイルシステムを実装する。ファイルシステム４６０は、ファイルを用いて自身のファイルシステムのレイアウトを記述しているメタデータを格納する。これには、アイ・ノード・ファイルが含まれる。アイ・ノード・ファイルは、ファイルの基礎となるデータ・ブロックを直接的にまたは間接的に参照（リファレンス）する（指し示す（ポイントする））。
【００４４】
ある１つの実施形態に関し、ファイルシステム４６０は、ＷＡＦＬの拡張としてのエクステント・ベース・アーキテクチャ４９５を備える。動作上、クライアントからのリクエストは、ネットワークを経由してパケットとしてストレージ・サーバへ送られる。該サーバにおいては、リクエストは、ネットワーク・アダプタが受け取る。レイヤ４１２あるいはレイヤ４３０といったネットワーク・ドライバは、パケットを処理し、適当と判断すれば、該パケットをネットワーク・プロトコルおよびファイル・アクセス・レイヤへ送って、ファイルシステム４６０へ転送する前に追加的な処理を行う。ここで、ファイルシステム４６０は、リクエストされたデータが「イン・コア」（"in core"）に存在しなければ、つまり、メモリ３１０に存在しなければ、リクエストされたデータをディスクからロード（load）（読み出し、リトリーブ（retrieve））する。もし情報がメモリに存在しなければ、ファイルシステム４６０は、エクステント・ベース・アーキテクチャ４９５と協働して間接ボリューム（インダイレクト・ボリューム、indirect volume）にアクセスしてエクステント識別子（エクステント・アイデンティファイア）を読み出し、エクステント対物理ブロック（エクステント−物理ブロック）・データ構造（extent-to-physical block data structure）にアクセスしてＰＶＢＮを読み出し、該ＰＶＢＮをＲＡＩＤシステム４８０へ送る。ある１つの実施形態においては、エクステント対物理ブロック・データ構造は、マップ（map）として実装される。ここで、ＰＶＢＮは、ディスク識別子（ディスク・アイデンティファイア）およびデバイス・ブロック・ナンバー（ディスク、ＤＢＮ）へマッピングされ、ディスク・ドライバ・システム４９０の適切なドライバへ送られる。ディスク・ドライバは、特定のディスクからＤＢＮへアクセスしてリクエストされたデータのブロックをメモリにロードしてストレージ・サーバによる処理に供する。リクエストを完了すると、ノード（およびオペレーティング・システム４００）は、ネットワークを介してクライアントへリプライを返す。
【００４５】
当然のことながら、本発明の教示に適合可能なストレージ・サーバが受け取ったクライアントからのリクエストのためにデータ・ストレージへアクセスするのに必要な上述したストレージ・オペレーティング・システムの複数のレイヤを通るソフトウェア的な「経路（パス、path）」は、ハードウェアで実装されてもよい。つまり、本発明の別の実施形態においては、ストレージ・アクセス・リクエストのデータ・パスは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途集積回路（ＡＳＩＣ）内に実現される論理回路として実装されてもよい。このタイプのハードウェア的な実装は、クライアントが発したリクエストに対する応答においてストレージ・サーバが提供するストレージ・サービスのパフォーマンスを向上させる。さらに、本発明の別の代替的実施形態においては、アダプタ３２０，３４０の処理要素は、パケット処理およびストレージ・アクセス・オペレーションそれぞれの一部または全部をプロセッサ３０２から解放（オフロード、offload）させるように構成されてもよい。そうすることで、ストレージ・サーバが提供するストレージ・サービスのパフォーマンスが向上する。あきらかなことだが、本明細書に記載の様々な処理、アーキテクチャ、プロシージャは、ハードウェアでも、ファームウェアでも、ソフトウェアでも実装可能である。
【００４６】
クラスタに実装される場合、ストレージ・オペレーティング・システムのデータ・アクセス・コンポーネントは、ディスクに格納されたデータにアクセスするためのＤ−モジュール４５０として実現されてよい。対照的に、多プロトコル・エンジン４２５は、ネットワークを介して到来するクライアントが発したアクセスに関するプロトコルの終端化（ターミネーション、termination）したり、クラスタ内の別のＮ−モジュールに対するアクセス・リクエストをリダイレクトしたりする、Ｎ−モジュール４１０として実現されてよい。クラスタ・サービス・システム４３６は、さらに、Ｍ−ホスト（例えば、Ｍ−ホスト４０１）を実装してもよい。そうすることで、情報共有操作を生成しクラスタの分散型ファイルシステム・イメージを呈示するクラスタ・サービスが提供される。例えば、メディア・アクセス・レイヤ４１２は、様々なノードのクラスタ・サービス・システム間で情報パケットの送受信を行い、各ノードの複製データベースを同期化してもよい。
【００４７】
加えて、クラスタ・ファブリック（ＣＦ）インタフェース・モジュール４４０（ＣＦインタフェース・モジュール４４０Ａ，４４０Ｂ）は、ＣＦプロトコル４７０を用いたＮ−モジュール４１０とＤ−モジュール４５０との間でのクラスタ内通信（イントラ−クラスタ・コミュニケーション、intra-cluster communication）を促進してもよい。例えば、Ｄ−モジュール４５０は、ＣＦアプリケーション・プログラミング・インタフェース（ＡＰＩ）を、コール（calls）を発したＮ−モジュール４１０（あるいは、図示しない別のＤ−モジュール）に曝し（expose）てもよい。そのために、ＣＦインタフェース・モジュール４４０は、ローカル・プロシージャ・コール（ＬＰＣｓ）およびリモート・プロシージャ・コール（ＲＰＣｓ）を用いたＣＦエンコーダ／デコーダとして構成されて、同一ノードに存在するＤ−モジュールや遠隔のノードに存在するＤ−モジュールとの間でファイルシステム・コマンドを交換することができる。
【００４８】
エクステント・ベース・アーキテクチャでの重複排除は、重複排除のリクエストの受信を必要とする。重複排除では、リクエストと関係する物理ボリュームの重複排除を行い、重複排除された物理ボリュームに関係付けされた１つまたは複数のエクステントの重複排除を行う。重複排除は、ファイルシステム４６０の重複排除モジュール（デダプリケーション・モジュール）４９８が実行してよい。
【００４９】
本明細書では、本発明はストレージ・オペレーティング・システム内での重複排除の実装として示されているが、当然のことながら重複排除は、別の実施形態として、ストレージ・サーバの他のモジュールやコンポーネントで実装されてもよい。加えて、重複排除は、ストレージ・サーバにおいて、ソフトウェアを実行するプロセッサ、ハードウェア、ファームウェアの１つまたは組み合わせとして実装されてよい。よって、重複排除（デダプリケーション）は、本発明の教示に従って、ストレージ・オペレーティング・システムのモジュールと直接的または間接的に相互作用してよい（インタフェースしてよい）。
【００５０】
本明細書では、語「ストレージ・オペレーティング・システム」は、通常、コンピュータ上で動作してデータ・アクセスを管理するストレージ機能を実行するコンピュータ実行可能コードを指し、また、汎用オペレーティング・システムのデータ・アクセス動作を実現するものでもよい。ストレージ・オペレーティング・システムは、マイクロカーネルとして、ＵＮＩＸ（登録商標）やＷｉｎｄｏｗｓＸＰ（登録商標）といった汎用オペレーティング・システム上で動作するアプリケーション・プログラムとして、または、機能を設定可能な（with configurable functionality）汎用オペレーティング・システムで本明細書に記載のようなストレージ用途を設定したシステムとして、実装可能である。
【００５１】
加えて、当業者にとっては当然のことだが、本明細書に記載の発明は、様々なタイプの専用コンピュータ（ファイル・サーバやストレージ・サービング・アプライアンス）や汎用コンピュータに適用可能であり、該コンピュータには、スタンドアロンのコンピュータや、その部分体も含まれ、ストレージ・システムとして実施されるもの、ストレージ・システムを含むものも含まれる。また、本発明が教示する内容を、様々なストレージ・システム・アーキテクチャに適化することも可能である。該アーキテクチャには、ネットワークアタッチトストレージ環境や、ストレージエリアネットワークや、クライアントもしくはホストのコンピュータと直接的に接続されたディスク・アセンブリなどが含まれ、またこれらに限定されない。故に、語「ストレージ・システム」（"storage system"）は、ストレージ機能を有するように設計され他の設備もしくはシステムに付随するサブシステムに加え、以上のような構成を含むように、広く解釈されるべきである。注記するが、本記載は、ライト・エニウェア・ファイル・システムに関して記載されているが、本発明の教示は、従来型の所定の場所に書き込むファイルシステム（ライト・イン・プレース・ファイルシステム、write in place file systems）を含む、あらゆる適当なファイルシステムで利用可能である。
【００５２】
図５は、エクステント・ベース・アーキテクチャ４９５を例示するブロック図である。エクステント・ベース・アーキテクチャ４９５は、ボリューム層（ボリューム・レイヤ）５０５ならびに集合体層（アグリゲート・レイヤ）もしくは領域管理層（リージョン・マネージャ・レイヤ）５１０を備える。ボリューム・レイヤ５０５は、１つまたは複数の間接ボリューム（インダイレクト・ボリューム）５１５を備え、クライアント２０２からのＩ／Ｏリクエストをストレージ・ディスク２７１内の１つまたは複数の物理ブロックに間接的にマッピングする。ある１つの実施形態においては、ストレージ・サーバ２１０は、各エクステントについて間接ボリューム５１５内の１つのエントリを用いる。これに対し、先行技術によるブロック・ベースの実装は、各データ・ブロックについて（例えばフレキシブル・ボリューム１１０内の）１つの間接ボリューム・エントリを用いた。ある１つの実施形態においては、Ｉ／Ｏリクエストは、ファイル・ブロック・ナンバー（ＦＢＮ）を経由してデータを参照する。ＦＢＮは、クライアント２０２が見るように、間接ボリューム５１５内のデータ・ブロックを参照する。ＦＢＮは、エクステント識別子（extent identifier）にアクセスするためのキーとして用いられる。本明細書では、エクステントは、ＦＢＮ空間（FBN space）において連続する１つまたは複数のブロックのグループ（contiguous group）を指す。本明細書では、エクステント対物理ブロック（エクステント−物理ブロック）・マップ（extent-to-physical block map）は、ある実施形態でマップとして実施されるデータ構造である。集合体層（アグリゲート・レイヤ）５１０は、エクステント−物理ブロック・マップ５２０ならびに１つまたは複数の物理ボリューム５２５を備える。エクステント−物理ブロック・マップ５２０は、（例えば、ボリューム・レイヤ５０５内のＦＢＮを経由してアクセスされる）エクステント識別子を、別のエクステントまたは１つもしくは複数の物理ボリューム５２５内の物理ボリューム・ブロック・ナンバー（ＰＶＢＮ）を指すポインタにマッピングする。本明細書では、ＰＶＢＮは、線的な単一のシークエンス（a single linear sequence）に抽象化されているディスク・ブロックを指す。
【００５３】
エクステント−物理ブロック・マップ５２０のエクステント・ベース・エントリは、アグリゲート単位の間接（エントリ）（パー・アグリゲート・インダイレクション、per-aggregate indirection）を提供する。対照的に、ボリューム・コンテナ１２０の仮想ボリューム・ブロック番号（ヴァーチャル・ボリューム・ブロック・ナンバー、virtual volume block number）（ＶＶＢＮ）は、ボリューム単位の間接（エントリ）（パー・ボリューム・インダイレクション、per-volume indirection）を提供する。アグリゲート単位（パー・アグリゲート、per-aggregate）エクステント・ベース・エントリは、本明細書では、アグリゲート内でボリューム境界を越えて一意的な（ユニークな）エクステントを指す。ボリューム単位（パー・ボリューム、per-volume）間接エントリは、ボリューム境界内で一意的な（ユニークな）エントリを指す。アグリゲート単位間接（エントリ）については、ストレージ・サーバ２１０が、物理ブロックに対しコピー、移動、その他の変更を加えたとき、その変更が、エクステント−物理ブロック・マップ５２０の当該アグリゲート・レイヤ５１０に反映される。しかしながら、この変更がボリューム・レイヤ５０５へ伝えられる必要性はない。なぜなら、物理ブロックに関係づけられたエクステント識別子が変更される必要がないからである。これにより、ボリューム・レイヤ５０５との情報交換（コミュニケーション、communication）なしで、エクステントの圧縮（compression）、伸張（decompression）、共有（sharing）、共有解除（非共有、unsharing）が可能になる。ボリューム境界を越えたブロックの共有が容易くできるので、ボリューム間重複排除（クロス・ボリューム・デダプリケーション、cross-volume deduplication）が可能になる。一回のパス（single pass）でセグメント・クリーニング（segment cleaning）および関連するディスク・ガーデニング技術（disk gardening techniques）をエクステント−物理ブロック・マップ５２０で実行できるようになり、その際、変更をボリューム・レイヤ５０５へ伝える必要は全くない。
【００５４】
図６は、エクステント・ベース・アーキテクチャ４９５のようなエクステント・ベース・アーキテクチャに含まれる、ソートされたエクステント・ベース・データ構造６００の例を示す図である。ある１つの実施形態においては、ソートされたエクステント・ベース・データ構造６００は、Ｂ＋ツリーである。あるいは、ソートされたエクステント・ベース・データ構造６００は別種のツリーであるか、または、長くともＯ（ｌｏｇｎ）の時間で検索（lookup）および修正（modify）の操作を実行することができるソートされたデータ構造である。ここでｎは、ファイル中のブロックの数である。アイ・ノード６０５は、エクステント・ベース・ツリー／ソートされたデータ構造６００のルートを指し示し、かつ、ボリューム／ファイルのメタデータならびにデータ・ブロック６２０もしくは間接ブロック（インダイレクト・ブロック、indirect blocks）６１０／６１５に対するポインタを含んでいる。例えば、Ｂ＋ツリーにおいては、間接ブロックは、内部ノード（インターナル・ノード、internal nodes）６１０／６１５と呼ばれ、データ・ブロックは、葉ノード（リーフ・ノード、leaf nodes）６２０と呼ばれる。ある１つの実施形態においては、アイ・ノード６０５は、１つまたは複数の内部ノード６１０／６１５の分岐（ブランチ、branches）を指し示す。別の実施形態では、アイ・ノード６０５は、直接的に葉ノード６２０を指し示す。ある１つの実施形態では、内部ノード６１０／６１５は、他のノードに対するポインタを格納し、ＦＢＮ、エクステント識別子、ＰＶＢＮ等のデータを格納しない。他方、葉ノード６２０は、そのようなデータを格納する。別の実施形態では、内部ノード６１０／６１５がデータを格納してもよい。
【００５５】
ある１つの実施形態では、エクステントの長さ（レングス）は、（例えば、８ブロックに）予め定められていてもよい。別の実施形態では、エクステントの長さは、変化してもよい。ある１つの実施形態では、エクステントの長さは、エクステント内のブロックの数で表される。例えば、１つのブロックのみを含むエクステントは、１の長さを有し、２つのブロックを含むエクステントは、２の長さを有する、等々である。ある１つの実施形態では、ユーザＩ／Ｏまたは書き込み割り当て（ライト・アロケーション、write allocation）で決定される最大長さを有する（例えば、エクステントは、最大長さ６４ブロックを有する）。
【００５６】
可変長エクステントを備えるエクステント・ベース・ツリーをエクステント・ベース・データ構造６００のデータ構造として用いる実施形態では、同一のサイズを有する２ファイル間でもツリーの高さは変化しうる。ある１つの実施形態では、内部ノード６１０／６１５の長さ（スパン、span）も可変である。ある１つの実施形態では、内部ノード６１０／６１５のスパンは可変である。本明細書では、間接ブロックのスパンは、間接ブロックが参照するブロックの数である。比較として、ＷＡＦＬでの以前の実装では、間接ブロックのスパンは固定されており、ｔｒａｄｖｏｌ間接ブロックのスパンは、１０２４であり、（例えば、フレキシブル・ボリューム１１に格納されている）ｆｌｅｘｖｏｌ間接ブロックのスパンは、５１０であり、（例えば、フレキシブル・ボリューム１１に格納されている）３２ビットｆｌｅｘｖｏｌ間接ブロックのスパンは、２５５である。
【００５７】
加えて、ＷＡＦＬの以前の実装においては、Ｎブロックを有する隣接エクステント（コンティギュアス・エクステント、contiguous extent）は、Ｎ個のランダムに位置決めされたブロック（N randomly located blocks）のような、同量の間接空間（indirect space）を使用している。なぜなら、エクステント各データ・ブロックは、ボリューム・レイヤにおいて別個の間接エントリとして表されるからである。しかしながら、ソートされたエクステント・ベース・データ構造６００では、間接空間の量を大きく低減させている。なぜなら、ボリューム・レイヤ・エントリは、ブロック単位（パー・ブロック、per-block）ではなく、エクステント単位（パー・エクステント、per-extent）だからである。例えば、ＷＡＦＬの以前の実装で５３２，６８５，８００バイト（およそ５０８ＭＢ）のデータを有するファイルを格納する６４ビットｆｌｅｘｖｏｌについて考察してみよう。ｆｌｅｘｖｏｌは、２５５エントリを有する（スパンが２５５である）間接ブロックを含み、各エントリが、４ＫＢのブロックを参照している。ｆｌｅｘｖｏｌは、１３００５０個の４ＫＢレベル０データ・ブロックを指し示す５１０個のレベル１関節ブロックを指し示す２つのレベル２間接ブロックを使用して、５０８ＭＢのファイルを表現する。ソートされたエクステント・ベース・データ構造６００においては、４ＫＢのブロックの各々に対し１つのエントリを使用する代わりに、ストレージ・サーバ２１０は各エクステントに対して１つのエントリを使用する。エクステントは、１個の４ＫＢブロックよりも長くすることができる。例えば、エクステントは、１つまたは複数の４ＫＢブロックの隣接グループ（コンティギュアス・グループ、contiguous group）である。ブロックあたり１２７エントリで１６ブロック長のエクステントを備える、ソートされたエクステント・ベース・データ構造６００を用いると、ストレージ・サーバ２１０は、たった８１２９個の葉ノード６２０と６５個の内部ノード６１０／６１５で、１３００５０個の４ＫＢを表現する。その結果、間接ブロックのメタデータの８７％を節約できる。
【００５８】
ある１つの実施形態では、ストレージ・サーバ２１０は、ソートされたエクステント・ベース・データ構造６００を用いて間接ボリューム５１５を実装する。ある１つの実施形態では、ストレージ・サーバ２１０は、間接ボリューム５１５のそれぞれをＢ＋ツリーとして実装する。図７は、間接ボリューム５１５を実装するために用いられた、ソートされたエクステント・ベース・データ構造６００の葉ノード６２０についてのボリューム・レイヤ間接エントリ７００の例図である。ボリューム・レイヤ間接エントリ７００は、ＦＢＮ７０５と、対応するエクステント識別子７１０と、エクステント７１５のレングス（長さ）と、を格納する。ストレージ・サーバ２１０は、ＦＢＮ７０５を主ソート・キー（プライマリ・ソーティング・キー、primary sorting key）として用いてソートされたエクステント・ベース・データ構造６００をナビゲート（navigate）し、ＦＢＮ７０５と対応するエクステント識別子７１０を発見する。ある１つの実施形態では、ＦＢＮ７０５は４８ビット、エクステント識別子７１０は４８ビット、レングス７１５は８ビットである。あるいは、ストレージ・サーバ２１０は、ＦＢＮ７０５、エクステント識別子７１０、レングス７１５のうちの１つまたは複数について、異なるサイズのものを用いてもよい。例えば、エクステント識別子７１０は別の実施形態では（例えば、ブロックのオフセットにおいて５１２バイト粒度（granularity）を実現するために）６４ビットの長さを有する。ある１つの実施形態では、エクステントのレングス７１５は変化する。別の実施形態では、エクステントのレングス７１５は固定である。
【００５９】
エクステント識別子７１０は、書き込み割り当て（ライト・アロケーション）の間に割り当てられる（アロケートされる）。ある１つの実施形態では、ストレージ・サーバ２１０は、エクステント識別子の有限プール（finite pool）からエクステント識別子７１０を割り当てる。あるいは、エクステント識別子７１０は、決して尽きることのない（never wrap）単調に増大する値である。
【００６０】
ＷＡＦＬの以前の実装でのボリューム単位コンテナ・ファイル（パー・ボリューム・コンテナ・ファイル、per-volume container files）１２０は、間接ボリューム５１５を実装するために、ソートされたエクステント・ベース・データ構造６００を使用していない。ストレージ・サーバ２１０は、ボリューム単位コンテナ・ファイル１２０の代わりに、エクステント−物理ブロック・マップを使用する。上述のように、エクステント−物理ブロック・マップを使用することで、間接メタデータを低減することができる。しかしながら、間接ボリューム・ブロックは、キャッシュされている、ＰＶＢＮに対するポインタを含んでいない。エクステントに対するアクセスには、
ストレージ・サーバ２１０が間接ボリューム５１５内のエクステント識別子７１０を検索すること、および、エクステント−物理ブロック・マップ５２０内のＰＶＢＮを（例えば、ポインタを手段として）検索すること、が含まれる。この追加的なＩ／Ｏの検索（I/O look-up）にかかるコンピュテーションのオーバーヘッドは、エクステント・ベース・アーキテクチャ４９５の特徴のいくつかとで相殺される。例えば、Ｉ／Ｏアクセスは、ブロック単位ではなく、エクステント単位である。それ故、単一のＩ／Ｏアクセスで複数のブロックにアクセスされる。また、エクステント・ベース・アーキテクチャ４９５は、圧縮、重複排除、セグメント・クリーニング等において優位性を有する。重複排除のようなアクションは、単に１つのボリュームにとどまらずにアグリゲートにまで容易に拡大可能であり、例えば、圧縮およびセグメント・クリーニングの帰結としての、ブロックに対する多くの変更は、（例えば、キャッシュされた間接ポインタを訂正するために）間接ボリューム５１５にまで伝播される必要がない。
【００６１】
ある１つの実施形態では、ストレージ・サーバ２１０は、ソートされたエクステント・ベース・データ構造６００としてエクステント・ベース・ツリーを使用して、エクステント−物理ブロック・マップ５２０を実装する。ある１つの実施形態では、ストレージ・サーバ２１０は、エクステント−物理ブロック・マップ５２０をＢ＋ツリーとして実装する。図８は、エクステント−物理ブロック・マップ５２０を実装するために用いる、ソートされたエクステント・ベース・データ構造６００の葉ノード６２０のためのエクステント・マップ・エントリ８００の例を示す図である。エクステント−物理ブロック・マップ５２０を実装するために用いる、ソートされたエクステント・ベース・データ構造６００の葉ノード６２０は、エクステント識別子８０５と、１つまたは複数の、ＰＶＢＮもしくは別のエクステント識別子８１０に対するポインタと、エクステント８１５についてのオフセット８１５と、エクステント８２０についてのレングスと、を格納する。ある１つの実施形態では、エクステント識別子８０５は４８ビット、ポインタ／エクステント識別子８１０は４８ビット、オフセット８１５は８ビット、レングス８２０は８ビットである。
【００６２】
ある１つの実施形態では、各エクステント・マップ・エントリ８００は、ＰＶＢＮに対する直接的なポインタもしくはその他のリファレンス８１０か、ＰＶＢＮを直接的に参照する別のエクステント識別子８０５か、を含んでいる。加えて、各ＰＶＢＮは、ただ１つのエクステントにより所有される。ある１つの実施形態では、所有者であるエクステントは、該ＰＶＢＮを直接的に参照するエクステントである。その結果として、ＰＶＢＮに至るためになされる、所与のエクステントに関する追加的な検索は最大でもわずかに１である。このことが、エクステント・マップ・エントリ８００における間接参照のレベルが恣意的に深く（大きく）なること、および、（各エクステント・エントリが異なるディスク・ブロックに格納されやすいと想定した場合にディスクＩ／Ｏオペレーションに基づいて計測したときに）自由裁量的に長時間になることを防いでいる。本明細書では、深い（deep）は、間接参照（インダイレクト・リファレンス、indirect reference）のレベル数を指す。
【００６３】
結果として、ストレージ・サーバ２１０は、タグ（tag）、固有の番号（unique number）、または、欠落した書き込みの検出（lost write detection）のための別のコンテキストとして、所有者のエクステント識別子を使用する。本明細書では、欠落した書き込みの検出（ロスト・ライト・ディテクション）は、ストレージ・サーバ２１０のレポートは完了しているものの実際にはストレージ・サーバ２１０がＩ／Ｏの（例えば、ストレージ２７０Ａ、ストレージ２７０Ｂ等のような）永続型ストレージ（persistent storage）にデータを書き込めていない書き込みの検出を指す。
【００６４】
別の実施形態では、１つまたは複数のＰＶＢＮに対して直接的にマップされたあらゆるエクステント識別子８０５は、２以上のエクステントによって所有されることができる。ロスト・ライト・ディテクションを具備する実施形態では、ストレージ・サーバ２１０は、複数のエクステント識別子が単一のＰＶＢＮを参照する可能性を考慮し、例えば別個のテーブルを用いて、エクステント識別子８０５とは別の／異なるコンテキスト、タグ、固有番号（ユニーク・ナンバー）を作成する。
【００６５】
ある１つの実施形態では、例えば、１つもしくは複数の、メタファイル、エクステントによる各エクステントに対する参照のリファレンス・カウント、および、エクステントによる各ＰＶＢＮに対する参照のリファレンス・カウントを維持（maintain）する。リファレンス・カウントにより、ストレージ・サーバ２１０は、あるエクステント／ＰＶＢＮに対して行う操作（例えば、再割り当て（リアロケーション、reallocation）、セグメント・クリーニング等）が他のエクステントに影響を及ぼすか否かを知ることができるようになる。ある１つの実施形態では、エクステントに対する操作が該エクステントに格納されている１つまたは複数の値を変更する場合に、そのエクステントは、エクステントに対する操作の影響を受ける。ストレージ・サーバ２１０は、１つまたは複数のログ・データ・コンテナのリファレンス・カウントの増大および減少を追跡（track）する。例えば、新しいエクステント／ＰＶＢＮが割り当てられた場合、（例えば、クローンの生成や、スナップショットの生成や、重複排除により）エクステント識別子が共有された場合といったときに、ストレージ・サーバ２１０は、リファレンス・カウントを増大させる（インクリメントする）。ある１つの実施形態では、ストレージ・サーバ２１０は、ログ・データ・コンテナを用いて累積（アキュムレート、accumulates）し、増大させ（インクリメントし、increments）、減少させ（デクリメントし、decrements）、例えば整合ポイント（consistency point）において、リファレンス・カウントのメタファイルに対するひとまとめアップデート（バッチ・アップデート、batch update）を行う。
【００６６】
外部リファレンス・カウント８２５は、エクステント−物理ブロック・マップ５２０の外側から（例えば外部で）生成されるエクステントについてのリファレンス・カウントとして維持（maintain）される。各エクステントについて単一の外部リファレンス・カウント８２５が用いられる。例えば、（ファイル生成（creation）や修正（modification）の際に）新たなエクステントが割り当てられた場合、エクステントの外部リファレンス・カウントは１に設定される。ある１つの実施形態では、新たなエクステント／ＰＶＢＮを割り当てる（アロケートする）ときに、ストレージ・サーバ２１０は、ＰＶＢＮについて外部リファレンス・カウントをゼロから１に直接的に（ログ・データ・コンテナをバイパスして）増大させる（インクリメントする）。外部エクステント（エクスターナル・エクステント）は、少なくとも１つの外部参照（エクスターナル・リファレンス、external reference）を含んだエクステント−物理ブロック・マップ５２０内のエクステントである。一例としては、あるエクステントについての外部リファレンス・カウントが非ゼロであれば、当該外部エクステントは、重複排除操作により解放されることはない。
【００６７】
内部リファレンス・カウント（インターナル・リファレンス・カウント、internal reference count）８３０は、エクステント・マップ・エントリ８００のために維持される。内部リファレンス・カウント８３０は、エクステント・マップ・エントリ８００の内部のＰＶＢＮそれぞれための内部リファレンス・カウントを含んでいる。各内部リファレンス・カウントは、エクステント−物理ブロック・マップ５２０に関する内部操作（internal operation）により生成される。内部エクステントは、予め定められた数の外部参照を含む（例えば外部リファレンス・カウントがゼロの）エクステント−物理ブロック・マップ５２０内のエクステントである。ある１つの実施形態においては、ストレージ・サーバ２１０が、新たなエクステント／ＰＶＢＮの割り当ての場合を除く全ての場合（例えば、ＰＶＢＮの修正、ＰＶＢＮの上書き等）において、個々のリファレンス・カウントのログ・データ・コンテナを用いて、該リファレンス・カウントに関するあらゆる増大（インクリメント）および減少（デクリメント）を実行する。
【００６８】
図９は、ＦＢＮから物理ボリューム５２５内のＰＶＢＮまでのマッピングのためにする、ボリューム・レイヤ５０５およびアグリゲート・レイヤ５１０内での検索のシークエンスの例を示す図である。例えば、ストレージ・サーバ２１０がＦＢＮ７０５を含んだＩ／Ｏリクエストを受け取ると、ストレージ・サーバ２１０は、該ＦＢＮを間接ボリューム５１５内でのキーとして用いてボリューム・レイヤ間接エントリ７００内のエクステント識別子７１０を検索する。ストレージ・サーバ２１０は、そのエクステント識別子７１０を、エクステント−物理ブロック・マップ５２０内のエクステント・マップ・エントリ８００の検索のためのキーとして用いる。ストレージ・サーバ２１０は、ポインタ８１０を用いて物理ボリューム５２５内のＰＶＢＮ９０５にアクセスする。この例においては、オフセット８１５はゼロである。オフセットが正の値を有するならば、ストレージ・サーバ２１０は、ＰＶＢＮ９０５の後の１つまたは複数のブロック（例えばＰＶＢＮ９１５、ＰＶＢＮ９２５等）にアクセスする。レングスが１よりも大きいならば、ストレージ・サーバ２１０は、ＰＶＢＮ９０５ならびに後続の１つもしくは複数のブロック（例えばＰＶＢＮ９１５、ＰＶＢＮ９２５等）にアクセスする。この例においては、外部リファレンス・カウント８２５は非ゼロ（例えば１）である。なぜなら、ボリューム・レイヤ間接エントリ７００においてエクステント・マップ・エントリ８００が特定され、そして、それ故に、該エクステントは外部エクステントだからである。本例においては、エクステント・マップ・エントリ８００は、内部エクステントではない。なぜなら、該エクステントは、ボリューム・レイヤ間接エントリ７００によって参照されているからである。
【００６９】
図１０は、ＦＢＮから物理ボリューム５２５内のＰＶＢＮまでのマッピングのためにする、ボリューム・レイヤ５０５およびアグリゲート・レイヤ５１０内での検索のシークエンスの別例を示す図である。図９を参照して説明した例と同様、ストレージ・サーバ２１０がＦＢＮ７０５を含んだＩ／Ｏリクエストを受け取り、該ＦＢＮを間接ボリューム５１５内でのキーとして用いてボリューム・レイヤ間接エントリ７００内のエクステント識別子７１０を検索する。ストレージ・サーバ２１０は、そのエクステント識別子７１０を、エクステント−物理ブロック・マップ５２０内の第１のエクステント・マップ・エントリ８００の検索のためのキーとして用いる。この例においては、第１のエクステント・マップ・エントリ８００は、ＰＶＢＮ９０５に対するポインタ８１０と、第２のエクステント・マップ・エントリ１０００に対するポインタまたはエクステント識別子８１０と、を含んでいる。第１のエクステント・マップ・エントリ８００を外部エクステントと称することが可能である。外部エクステントは、動作中のファイルシステム（active file system）、ボリューム・クローン（volume clone）、あるいは、スナップショット（snapshot）により参照されるエクステントの１つである。ストレージ・サーバ２１０は、ポインタ８１０を用いて物理ボリューム５２５内のＰＶＢＮ９０５にアクセスする。ストレージ・サーバ８１０は、エクステント識別子８１０を用いてエクステント−物理ブロック・マップ５２０内の第２のエクステント・マップ・エントリ１０００を検索する。ストレージ・サーバ２１０は、ポインタ１０１０を用いて物理ボリューム５２５内のＰＶＢＮ９１５にアクセスする。本例においては、外部リファレンス・カウント８２５は非ゼロ（例えば１）である。なぜなら、ボリューム・レイヤ間接エントリ７００においてエクステント・マップ・エントリ８００が特定され、そして、それ故に、該エクステントは外部エクステントだからである。本例においては、エクステント・マップ・エントリ８００は、内部エクステントではない。なぜなら、該エクステントは、ボリューム・レイヤ間接エントリ７００によって参照されているからである。エクステント・マップ・エントリ１０００を、内部エクステントを称することが可能である。内部エクステントは、別のエクステントのみによって参照され、第１のエクステント・マップ・エントリ８００によって参照されるＰＶＢＮのみを保持する。本例では、外部リファレンス・カウント１０２５は、予め定められた数（例えばゼロ）であり、これは、エクステント・マップ・エントリ１０００が外部エクステント・マップ・エントリ８００からのみ参照されることを意味している。
【００７０】
図１１−図１２は、エクステント・ベース・アーキテクチャにおける重複排除の方法を例示するフローチャートである。図１１は、ある１つの実施形態によるエクステント・ベース・アーキテクチャでの重複排除の方法１１００を例示するフローチャートである。図１１を参照すれば、方法１１００は、処理ロジック（processing logic）により実行可能である。処理ロジックは、ハードウェア（例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群）、またはその結合体を備え、これらは図１１においては処理指示ブロック１１０５−１１３５として表現されている。ある実施形態においては、方法１１００は、図２Ａに示されるストレージ・サーバ２１０、図２Ｂに示されるＤ−モジュール２２２、図３に示されるオペレーティング・システム３１４、および、図４に示される重複排除モジュール４９８により実行されてよい。
【００７１】
処理指示ブロック１１０５において、重複排除実行のリクエストが受け取られる。該リクエストは、重複排除を実行せねばならないと判断するユーザまたはアドミニストレータからのものである。ある別の実施形態においては、重複排除実行のリクエストは、定期的に受け取られる。別の実施形態においては、長く保持されるスナップショット（long retained snapshot）またはアーカイブ化されるスナップショットが取得されるよりも予め定められた時間だけ前に、重複排除実行のリクエストが受け取られる。ある１つの実施形態においては、長く保持されるスナップショットとは、長期間（例えば一週、一月、一年等）にわたり永続型ストレージに保管されることになるスナップショットである。例えば、長く保持されるスナップショットが毎日曜深夜に取得され、かつ重複排除処理に２時間を要するなら、重複排除実行のリクエストが日曜の正午に発生するように設定することができ、そうすることで、これから実行される（スナップショットの）重複排除に十分な時間を確保することが可能になる。重複排除実行のリクエストは、重複排除する特定のスナップショットを含んでもよい。別の実施形態においては、最も近い（最近の）スナップショットが重複排除に関するデフォルトのスナップショットである。別の実施形態においては、新たなスナップショットが取得される場合には常に、全てのスナップショットについて重複排除がなされる。さらに別の実施形態においては、スナップショット以外の、エクステント・ベース・アーキテクチャ内のデータについて重複排除が実行される。
【００７２】
処理指示ブロック１１１０において、ログ・データ・コンテナがアクセスされる。ログ・データ・コンテナは、書き込み割り当てを受け（write allocated）、かつ／または、変更を受けた（modified）物理ボリューム（例えば物理ボリューム５２５）内の各ブロックに関する識別情報（identifying information）を格納するデータ構造である。ある１つの実施形態においては、ログ・データ・コンテナは、ファイルである。ある１つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ／または、変更を受けたデータ・ブロックのフィンガープリント（fingerprint）およびエクステントＩＤを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、エクステント・ベース・アーキテクチャ４９５にアクセス可能なフィンガープリントに対するポインタおよびエクステントＩＤを含んでいる。フィンガープリントとは、数学的アルゴリズムを用いて生成される、データ・ブロックを一意的に特定する２進数の符号列（coded string of binary digits）である。データ・ブロックのためのフィンガープリントは、本技術分野において周知の方法により生成される。フィンガープリントは、フィンガープリント構造（不図示）に格納される。フィンガープリント構造は、いずれの図面にも示されていないが、当業者であれば、フィンガープリント構造は、オペレーティング・システム、メモリ、オペレーティング・システム／メモリにアクセス可能なフィンガープリント・データベース等に実装可能であることを理解する。
【００７３】
ある１つの実施形態においては、ログ・データ・コンテナは、先のスナップショットが実行されて以来、割り当て（アロケート）を受け、かつ／または、変更（モディファイ）を受けたデータ・ブロックを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、物理ボリュームがシステムに組み入れられて以来、割り当て（アロケート）を受け、かつ／または、変更（モディファイ）を受けた全てのデータ・ブロックを含んでいる。さらに別の実施形態においては、ログ・データ・コンテナは、重複排除コマンドを伴って受け取ったスナップショットのために割り当てられた（アロケートされた）データ・ブロックを含んでいる。ある１つの実施形態においては、ログ・データ・コンテナは、いつデータ・ブロックが書き込み割り当てを受け、かつ／または、変更を受けたかを示すタイムスタンプを含むことができる。ある別の実施形態においては、ログ・データ・コンテナにタイムスタンプは含まれない。最も近くに（最近に）書き込み割り当てを受け、かつ／または、変更を受けたブロックは、ログ・データ・コンテナにおいて最近のエントリである。処理指示ブロック１１１５において、ログ・データ・コンテナにおけるエントリがアクセスされる。
【００７４】
処理指示ブロック１１１５において、現行のエントリ（カレント・エントリ、current entry）のエクステントＩＤが、ログ・データ・コンテナ内の他のエントリのエクステントＩＤと比較される。エクステントＩＤは、当該技術分野の周知技術を用いて比較すればよい。現行のエントリのエクステントＩＤが、ログ・データ・コンテナ内の他のエントリのエクステントＩＤと一致すれば、方法１１００はブロック１１２０へ進む。現行のエントリのエクステントＩＤが、ログ・データ・コンテナ内の他のエントリのエクステントＩＤと一致しなければ、方法１１００はブロック１１３５へ進む。
【００７５】
処理ブロック１１２０において、一致しているエントリ（マッチング・エントリ、matching entry）についてのリファレンス・カウントおよびポインタＩＤが更新される。ある１つの実施形態においては、現行のエントリの内部リファレンス・カウントは、一致しているエントリの内部リファレンス・カウントを含むように、更新される。例えば、現行のエントリの内部リファレンス・カウントが４であって、一致しているエントリの内部リファレンス・カウントが８であったならば、現行のエントリの内部リファレンス・カウントは、１２、つまり４と８の合計、に更新される。この実施形態においては、一致しているエントリの内部リファレンス・カウントはゼロに更新される。別の実施形態においては、一致しているエントリの内部リファレンス・カウントは、現行のエントリの内部リファレンス・カウントを含むように更新される。この実施形態においては、現行のエントリの内部リファレンス・カウントはゼロに更新される。ある１つの実施形態においては、現行のエントリの内部リファレンス・カウントが、一致しているエントリの内部リファレンス・カウントを含むように更新されれば、一致しているエントリのエクステントＩＤのポインタが、現行のエントリのエクステントＩＤを指し示すように更新される。別の実施形態においては、一致しているエントリの内部リファレンス・カウントが、現行のエントリの内部リファレンス・カウントを含むように更新されれば、現行のエントリのエクステントＩＤのポインタが、一致しているエントリのエクステントＩＤを指し示すように更新される。
【００７６】
処理ブロック１１２５において、現行のエントリに関係づけられたエクステントまたは一致しているエントリに関係づけられたエクステントのいずれかのリファレンス・カウントが予め定められた値（例えばゼロ）であるかどうかが判断される。ある１つの実施形態においては、リファレンス・カウントは、エクステントについての外部リファレンス・カウントである。別の実施形態においては、リファレンス・カウントは、エクステントについての内部リファレンス・カウントである。この実施形態においては、エクステントのあらゆる内部リファレンス・カウントが予め定められた値に等しい場合にのみ、一致が見られるとする。いずれかのエクステントのリファレンス・カウントが予め定められた値に等しければ、方法１１００は、ブロック１１３０へ進む。エクステントの両方のリファレンス・カウントが予め定められた値に等しくなければ、方法１１００は、ブロック１１３５へ進む。
【００７７】
ブロック１１３０において、リファレンス・カウントが予め定められた値に等しいエクステントが解放される。エクステントは、当該エクステントを有するＰＶＢＮを解放し、当該ＰＶＢＮについてのマッピングをエクステント−物理ブロック・マップ５２０から除去することにより解放される。ある１つの実施形態においては、エクステントを解放する工程に、エクステント識別子７１０を、自由に使用することができるエクステント識別子のプールに再び加えることが含まれる。別の実施形態においては、エクステント識別子のプールが存在せず、故に、エクステント識別子７１０は、エクステント識別子のプールへ戻されることがない。
【００７８】
処理ブロック１１３５においては、ログ・データ・コンテナ内に処理すべきエントリがまだ存在するかどうかが判断される。ログ・データ・コンテナ内にまだエントリが存在すれば、方法１１００は、処理ブロック１１１０に戻り、ログ・データ・コンテナ内の次のエントリにアクセスする。ログ・データ・コンテナ内に処理すべきエントリがなければ、方法１１００は終了する。
【００７９】
図１２は、別の実施形態による、エクステント・ベース・アーキテクチャにおける重複排除の方法を例示説明するフローチャートである。図１２を参照すれば、方法１２００は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア（例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群）、またはその結合体を備え、これらは図１２においては処理指示ブロック１２０５−１２４５として表現されている。ある実施形態においては、方法１２００は、図２Ａに示されるストレージ・サーバ２１０、図２Ｂに示されるＤ−モジュール２２２、図３に示されるオペレーティング・システム３１４、および、図４に示される重複排除モジュール４９８により実行されてよい。
【００８０】
処理指示ブロック１２０５において、重複排除実行のリクエストが受け取られる。該リクエストは、重複排除を実行せねばならないと判断するユーザまたはアドミニストレータからのものである。ある別の実施形態においては、重複排除実行のリクエストは、定期的に受け取られる。別の実施形態においては、長く保持されるスナップショットまたはアーカイブ化されるスナップショットが取得されるよりも予め定められた時間だけ前に、重複排除実行のリクエストが受け取られる。例えば、長く保持されるスナップショットが毎日曜深夜に取得され、かつ重複排除処理に２時間を要するなら、重複排除実行のリクエストが日曜の正午に発生するように設定することができ、そうすることで、これから実行される（スナップショットの）重複排除に十分な時間を確保することが可能になる。重複排除実行のリクエストは、重複排除する特定のスナップショットを含んでもよい。別の実施形態においては、最も近い（最近の）スナップショットが重複排除に関するデフォルトのスナップショットである。別の実施形態においては、新たなスナップショットが取得される場合には常に、全てのスナップショットについて重複排除がなされる。さらに別の実施形態においては、スナップショット以外の、エクステント・ベース・アーキテクチャ内のデータについて重複排除が実行される。
【００８１】
処理指示ブロック１２１０において、ログ・データ・コンテナがアクセスされる。ある１つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ／または、変更を受けた物理ボリューム（例えば物理ボリューム５２５）内の各ブロックに関する識別情報を格納するデータ構造である。ある１つの実施形態においては、ログ・データ・コンテナは、ファイルである。ある１つの実施形態においては、ログ・データ・コンテナは、書き込み割り当てを受け、かつ／または、変更を受けたデータ・ブロックのフィンガープリントおよびエクステントＩＤを含んでいる。ある別の実施形態においては、ログ・データ・コンテナは、エクステント・ベース・アーキテクチャ４９５にアクセス可能な、フィンガープリント・データベースに格納されたフィンガープリントに対するポインタおよびエクステントＩＤを含んでいる。データ・ブロックについてのフィンガープリントは、当技術分野における周知技術を用いて生成される。ログ・データ・コンテナは、先のスナップショットが実行されて以来、割り当てられ（アロケートされ）、かつ／または、変更された（モディファイされた）データ・ブロックを含んでいる。別の実施形態においては、ログ・データ・コンテナは、物理ボリュームがシステムに組み入れられて以来、割り当て（アロケート）を受け、かつ／または、変更（モディファイ）を受けた全てのデータ・ブロックを含んでいる。さらに別の実施形態においては、ログ・データ・コンテナは、重複排除コマンドを伴って受け取ったスナップショットのために割り当てられた（アロケートされた）データ・ブロックを含んでいる。ある１つの実施形態においては、ログ・データ・コンテナは、いつデータ・ブロックが書き込み割り当てを受け、かつ／または、変更を受けたかを示すタイムスタンプを含むことができる。ある別の実施形態においては、ログ・データ・コンテナにタイムスタンプは含まれない。最も近くに（最近に）書き込み割り当てを受け、かつ／または、変更を受けたブロックは、ログ・データ・コンテナにおいて最近のエントリである。処理指示ブロック１２１５において、ログ・データ・コンテナにおけるエントリがアクセスされる。
【００８２】
処理ブロック１２１５において、ログ・データ・コンテナ内の現行のエントリが一致を有するがどうかが判断される。ある１つの実施形態においては、当該判断は、現行のエントリに関係づけられたフィンガープリントがログ・データ・コンテナ内の別のエントリと関係づけられたフィンガープリントと一致するか判断することで、なされる。別の実施形態においては、該判断は、現行のエントリと関係づけられたフィンガープリントがフィンガープリント・データベースに格納されたフィンガープリントと一致するか判断することで、なされる。フィンガープリントの比較は、当技術分野における周知技術を用いて行われる。
【００８３】
現行のエントリに関係づけられたフィンガープリントが一致しないと判断されれば、方法１２００はブロック１２４５へ進む。ある１つの実施形態においては、現行のエントリと関係づけられたフィンガープリントが一致を有すると判断されると、バイト比較（byte comparison）が行われる。本実施形態におけるバイト比較では、現行のエントリに関係づけられたデータ・ブロック内の各バイトが、一致するフィンガープリントを有するデータ・ブロック内の各バイトと比較される。例えば、エントリＸが値Ｙなるフィンガープリントを有し、エントリＺも値Ｙなるフィンガープリントを有すると判断されれば、エントリＸと関係づけられたデータ・ブロック内の各バイトが、エントリＺと関係づけられたデータ・ブロック内の各バイトと比較される。別の実施形態においては、現行のエントリについてのフィンガープリントが一致を有する場合、バイト比較を行わずに、方法１２００がブロック１２２０へ進む。
【００８４】
処理ブロック１２２０においては、上述の一致に基づいて、ドナー・エクステントとレシピエント・エクステントとが決定される。ある１つの実施形態においては、現行のエクステントと関係づけられたエクステントが、ドナー・エクステントに決定され、一致するエントリと関係づけられたエクステントが、レシピエント・エクステントに決定される。別の実施形態においては、現行のエクステントと関係づけられたエクステントが、レシピエント・エクステントに決定され、一致するエントリと関係づけられたエクステントが、ドナー・エクステントに決定される。別の実施形態においては、現行のエントリおよび一致するエントリのタイムスタンプ同士が比較され、古い方のエントリがドナー・エクステントとして、新しい方のエントリがレシピエント・エクステントとして決定される。別の実施形態においては、現行のエントリおよび一致するエントリのタイムスタンプ同士が比較され、新しい方のエントリがドナー・エクステントとして、古い方のエントリがレシピエント・エクステントとして決定される。
【００８５】
処理ブロック１２２５において、レシピエント・エクステントについての外部リファレンス・カウントが予め定められた値（例えばゼロ）と等しいかどうか判断される。レシピエント・エクステントについての外部リファレンス・カウントが予め定められた値と等しいならば、方法１２００は、ブロック１２３５へ進む。例えば、レシピエント・エクステントについての外部リファレンス・カウントがゼロであれば、当該レシピエント・エクステントは、内部エクステントにちがいない。レシピエント・エクステントが内部エクステントであるならば、ドナー・エクステントおよびレシピエント・エクステントの間のブロック共有は行われない。レシピエント・エクステントが内部エクステントでないならば（そして、それ故に、外部エクステントであるならば）、ブロック１２３０においてブロック共有が行われる。ブロック共有については、図１３と併せて以下で説明する。
【００８６】
処理ブロック１２３５において、エクステントのリファレンス・カウントが予め定めた値（例えばゼロ）と等しいかどうか判断される。ある１つの実施形態においては、外部利ファン連巣・カウントが、予め定められた値と比較される。別の実施形態においては、内部リファレンス・カウントも、予め定められた値と比較され、エクステントに関係づけられたＰＶＢＮを解放すべきかどうか判断される。ある１つの実施形態においては、当該判断は、エクステント−物理ブロック・マップ（例えばアグリゲート単位エクステント−物理ブロック・マップ５２０）内の各エクステントについてなされる。別の実施形態においては、判断は、ドナー・エクステントおよびレシピエント・エクステントについてなされる。
【００８７】
エクステントのリファレンス・カウントが予め定められた値（例えばゼロ）と等しくなければ、方法１２００は、ブロック１２４５へ進む。エクステントのリファレンス・カウントが予め定められた値（例えばゼロ）に等しければ、処理ブロック１２４０においてエクステントは解放される。エクステントの解放は、図１４と併せて以下に記載されるようにして実行される。
【００８８】
処理ブロック１２４５においては、ログ・データ・コンテナ内に処理すべきエントリがまだ存在するかどうかが判断される。ログ・データ・コンテナ内にまだエントリが存在すれば、方法１２００は、処理ブロック１２１０に戻り、ログ・データ・コンテナ内の次のエントリにアクセスする。ログ・データ・コンテナ内に処理すべきエントリがなければ、方法１２００は終了する。
【００８９】
図１３は、ある実施形態によるブロック共有の方法を例示説明するフローチャートである。図１３を参照すれば、方法１３００は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア（例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群）、またはその結合体を備え、これらは図１３においては処理指示ブロック１３０５−１３３５として表現されている。ある実施形態においては、方法１３００は、図２Ａに示されるストレージ・サーバ２１０、図２Ｂに示されるＤ−モジュール２２２、図３に示されるオペレーティング・システム３１４、および、図４に示される重複排除モジュール４９８により実行されてよい。
【００９０】
処理ブロック１３０５においては、レシピエント・エクステント内の共有されるべきデータ・ブロックに関係づけられた内部リファレンス・カウントが、ドナー・エクステント内の一致しているブロックについての内部リファレンス・カウントを含むように、更新される。例えば、レシピエント・エクステント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントが４であって、ドナー・エクステント内の一致しているデータ・ブロックについての内部リファレンス・カウントが８であったならば、レシピエント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントは更新されて１２になる。ある１つの実施形態においては、レシピエント内の共有されるべきデータ・ブロックについての内部リファレンス・カウントの更新は、エクステント−物理データ・ブロック・マップ５２０内のレシピエント・エクステントのエクステントＩＤについてのエクステント・エントリを更新することによりなされる。
【００９１】
処理ブロック１３１０において、ドナー・エクステント内の一致しているデータ・ブロックの内部リファレンス・カウントは、更新されてゼロにされる。ある１つの実施形態においては、ドナー・エクステント内の一致しているデータ・ブロックについての内部リファレンス・カウントの更新は、エクステント−物理データ・ブロック・マップ５２０内のドナー・エクステントのエクステントＩＤについてのエクステント・エントリを更新することによりなされる。
【００９２】
処理ブロック１３１５においては、ドナー・エクステントのエクステント識別子に設定されたエクステント識別子８０５と、レシピエント・エクステントのエクステント識別子に対する参照８１０と、レシピエント・エクステント内の共有されるべきデータ・ブロックのオフセットに等しいオフセット８１５と、共有されるべきデータ・ブロックのレングス８２０と、先の値から１だけ（例えばゼロから１へ）インクリメントされた外部リファレンス・カウント８２５と、を含むように、新たなエクステント・マップ・エントリ８００が生成される。ある１つの実施形態においては、ドナー・エクステントの外部リファレンス・カウントがインクリメントされることにより、エクステント−物理ブロック・マップ・エントリにおける間接参照のレベルが恣意的に深くなること、および、（各エクステント・エントリが異なるディスク・ブロックに格納されやすく別個のＩ／Ｏ操作が必要になる傾向が高いと想定した場合にディスクＩ／Ｏオペレーションに基づいて計測したときに）自由裁量的に長時間になることを防いでいる。本明細書では、深いは、間接参照のレベル数を指す。
【００９３】
処理ブロック１３２０においては、ドナー・エクステントについてのエクステント・エントリが更新される。エクステント識別子８０５は、ドナー・エクステントのエクステント識別子に設定される。参照８１０は、共有されるべきデータ・ブロックのＰＶＢＮに設定される。オフセット８１５は、ドナー・エクステント内の第１のデータ・ブロックの位置（ロケーション、location）に設定される（例えば、ドナー・エクステント内の第１のデータ・ブロックが共有され、もはやドナー・エクステントにより参照されないならば、オフセットは１に設定され、これが共有されないドナー・ブロックの第１のブロックである。）。レングス８２０は、ドナー・エクステント内の共有されていないデータ・ブロックの数に設定される（例えば、１個のブロックが共有され、エクステントの長さが８であれば、レングスは７に更新される。）。レングス８２０がゼロであれば、外部リファレンス・カウント８２５はデクリメントされる。今、ドナー・エクステントのレングスがゼロであれば、当該エクステントはもはやＰＶＢＮを参照せず、故に、解放されるべきである。ある１つの実施形態においては、ドナー・エクステントについてのエクステント・エントリは、アグリゲート・レイヤのソートされたデータ構造において現存するエクステント・エントリを上書きすることで、更新される。別の実施形態においては、エクステント・エントリの更新は、更新されたエクステントについて新たなエントリを追加することによりなされる。
【００９４】
処理ブロック１３２５においては、ストレージ・サーバ２１０は、割り当てられた（アロケートされた）エクステント識別子８０５をキーとして用いてアグリゲート・レイヤのソートされたエクステント・ベース・データ構造６００を横断し（行き来して）、１つまたは複数の新たなエクステント・マップ・エントリ８００を追加する。
【００９５】
図１４は、ある実施形態によるエクステントの解放の方法を例示説明するフローチャートである。図１４を参照すれば、方法１４００は、処理ロジックにより実行可能である。処理ロジックは、ハードウェア（例えば回路、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（ハードウェアのシミュレーションを実行する処理デバイス上で実行される命令群）、またはその結合体を備え、これらは図１４においては処理指示ブロック１４０５−１４１５として表現されている。ある実施形態においては、方法１４００は、図２Ａに示されるストレージ・サーバ２１０、図２Ｂに示されるＤ−モジュール２２２、図３に示されるオペレーティング・システム３１４、および、図４に示される重複排除モジュール４９８により実行されてよい。
【００９６】
処理ブロック１４０５においては、エクステントを含んだＰＶＢＮが解放される。ＰＶＢＮの解放は、当技術分野において周知の方法を用いてなされる。
【００９７】
処理ブロック１４１０においては、当該エクステント識別子および対応するＰＶＢＮについてのエクステント−物理ブロック・マップ５２０内エントリが除去される。
【００９８】
処理ブロック１４１５においては、解放されんとするエクステントのエクステント識別子７１０は、自由に使用することができるエクステント識別子のプールに加えられる。別の実施形態においては、処理ブロック１４１５は任意（optional）であり、実行されない。ある１つの実施形態においては、エクステント識別子のプールが存在しなければ、処理ブロック１４１５は任意である。本実施形態においては、エクステント識別子７１０は、エクステント識別子のプールに再配置されない。ある特定の実施形態においては、処理ブロック１４１５は省略され、ブロック１４１０で処理は終了する。
【００９９】
このように、エクステント・ベース・アーキテクチャにおける重複排除の実施形態は、本明細書中で示したようなコンピュータ・システムに実装される。実用上、方法１１００および方法１２００は、コンピュータが実行可能な命令群で構成される１つまたは複数のプログラムを構成してよい。図１１、図１２、図１３、および、図１４のフローチャートを参照して当該方法を説明したので、当業者であれば、そのようなプログラムを開発することは可能である。ここで、プログラムは、（適切に構成されたコンピュータ（コンピュータ読み取り可能な媒体から読み取った命令群を実行する、コンピュータのプロセッサ）上で）論理ブロック１１００から１１３５、１２００から１２４５、１３００から１３２５、１４００から１４１５として表現された操作（オペレーション、operations）（動作（acts））を実行するための命令群を含んでいる。コンピュータが実行可能な命令群は、コンピュータ・プログラミング言語で記述されてよく、あるいは、ファームウェアのロジックもしくはハードウェア回路で実現されてもよい。もし、認知された基準に準拠したプログラミング言語（programming language conforming to a recognized standard）で記述されているならば、その命令群は、様々なハードウェア・プラットフォームで動作可能であって、様々なオペレーティング・システムに対するインタフェースとして動作する。
【０１００】
さらに、本発明は、特定のプログラミング言語を参照して説明していない。当然のことながら、様々なプログラミング言語を用いて本明細書に記された本発明の教示の内容を実装してよい。なおさらには、当業界では共通の認識だが、ソフトウェアとは、（例えば、プログラム（program）、プロシージャ（procedure）、プロセス（process）、アプリケーション（application）、モジュール（module）、ロジック（logic）………）いかなる形態であっても、ある動作を行うもの、あるいは、何らかの結果をもたらすものである。このような表現は、単に、コンピュータがソフトウェアを実行することにより該コンピュータのプロセッサがある動作を行うかまたはある結果をもたらす、ことを簡潔に言い表したものである。当然のことだが、本発明の範囲を逸脱することなく、より多くの処理を図１１、図１２、図１３、および、図１４に組み入れてもよいし、該図の処理をもっと少ない処理にしてもよいし、また、本明細書に記載され図示されるブロックの配置は特定の順序を暗示するものではない。
【０１０１】
エクステント・ベース・アーキテクチャにおける重複排除について記載した。特定の実施形態について例示的に示し説明したが、当然、当業者にとっては、同様の目的を達成すると考えられる構成で、開示された実施形態を置換できることは明らかである。本願は、本発明のあらゆる適応（アダプテーション、adaptations）あるいは変形（バリエーション、variations）を包含する。
【０１０２】
本明細書中の語「メモリ」（"memory"）は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）およびスタティック・ＲＡＭ（ＳＲＡＭ）といったあらゆる揮発性記憶媒体（volatile storage media）を包含する。コンピュータが実行可能な命令群は、磁気ハード・ディスク（magnetic hard disk）、光学ディスク（an optical disk）といった不揮発性記憶デバイス（non-volatile storage devices）に格納可能であって、通例、プロセッサがソフトウェアを実行中にダイレクト・メモリ・アクセス・プロセスによりメモリに書き込まれる。当業者であれば、語「コンピュータ読み取り可能記憶媒体」（"computer-readable storage medium"）は、プロセッサがアクセス可能なあらゆる種類の揮発性または不揮発性の記憶装置（ストレージ・デバイス）を含むものであると、直ちに理解する。
【０１０３】
それ故、本発明は、クレームおよびその均等物のみにより限定される。
【図１】
2014525073.tif 000003
【図２Ａ】
2014525073.tif 000004
【図２Ｂ】
2014525073.tif 000005
【図３】
2014525073.tif 000006
【図４】
2014525073.tif 000007
【図５】
2014525073.tif 000008
【図６】
2014525073.tif 000009
【図７】
2014525073.tif 000010
【図８】
2014525073.tif 000011
【図９】
2014525073.tif 000012
【図１０】
2014525073.tif 000013
【図１１】
2014525073.tif 000014
【図１２】
2014525073.tif 000015
【図１３】
2014525073.tif 000016
【図１４】
2014525073.tif 000017
【国際調査報告】
2014525073.tif 000018
2014525073.tif 000019
2014525073.tif 000020