(57)【特許請求の範囲】
【請求項１】
データを非キャッシュ記録媒体上に格納するための方法であって、前記方法が、
ｉ．データを非キャッシュ記録媒体に書き込むための命令を受信することであって、前記命令が、ユーザーが認識する論理ブロックアドレスおよびユーザー提供のバッファを含むことと、
ｉｉ．前記ユーザー提供のバッファをユーザー提供のバッファユニットに分割することであって、書き込まれる各ユーザー提供のバッファユニットが、前記非キャッシュ記録媒体上の次の隣接するブロックに書き込まれることと、
ｉｉｉ．暗号化ハッシュ関数を各ユーザー提供のバッファユニットに適用し、それにより、各ユーザー提供のバッファユニットに対して生成されたハッシュ値を生成することと、
ｉｖ．コンピュータプログラムにハッシュ値テーブルをアクセスさせて、各生成されたハッシュ値が、前記ハッシュ値テーブル内のハッシュ値と重複しているかどうかを判断させる、アルゴリズムを含む前記コンピュータプログラムを起動することであって、前記ハッシュ値テーブルが、複数の格納されたハッシュ値の各々を異なる格納されたバッファユニット、および本当の論理ブロックアドレスと関連付け、
Ａ．前記生成されたハッシュ値が前記ハッシュ値テーブル内にない場合は、前記ユーザー提供のバッファユニットを非キャッシュ記録媒体内のブロックに書き込み、前記ハッシュ値テーブルを、前記ユーザー提供のバッファユニット、前記生成されたハッシュ値および前記ユーザー提供のバッファユニットが格納されている本当の論理ブロックアドレスの相関関係を含むように更新して、メディエータ上で、前記ユーザー提供のバッファが書き込まれている位置に対応する本当の論理ブロックアドレスを、前記ユーザー提供のバッファに対する前記ユーザーが認識する論理ブロックアドレスと相互に関連付け、
Ｂ．前記生成されたハッシュ値が前記ハッシュ値テーブル内の格納されたハッシュ値と重複している場合は、矛盾があるかどうかを問い合わせ、矛盾は、重複しているハッシュ値が、格納されたバッファユニットおよび前記ユーザー提供のバッファユニットと関連付けられていて、かつ前記格納されたバッファユニットおよび前記格納されたバッファユニットの使用および前記ユーザー提供のバッファユニットが異なる値を有する状況として定義され、
ａ．矛盾がある場合は、前記ユーザー提供のバッファユニットを前記非キャッシュ記録媒体内のブロックに書き込み、前記格納されたバッファユニットと前記格納されたハッシュ値との間の前記ハッシュ値テーブル内の関連付けを非アクティブにするか、または削除して、前記ハッシュ値テーブルを、前記ユーザー提供のバッファユニット、前記生成されたハッシュ値および前記ユーザー提供のバッファユニットが格納されている本当の論理ブロックアドレスの相関関係を含むように更新して、前記ユーザー提供のバッファユニットが書き込まれている位置に対応する本当の論理ブロックアドレスおよび前記ユーザーが認識する論理ブロックアドレスを前記メディエータ上に書き込み、
ｂ．矛盾がない場合は、前記ユーザー提供のバッファユニットと同じである、前記非キャッシュ記録媒体上に格納されたバッファユニットの本当の論理ブロックアドレスを前記メディエータ上に書き込み、それを、前記ユーザー提供のバッファユニットを前記非キャッシュ記録媒体上に書き込むことなく、前記ユーザー提供のバッファに対する前記ユーザーが認識する論理ブロックアドレスと相互に関連付けることと、
を含む、方法。
【請求項２】
前記方法が、複数のユーザー提供のバッファユニットの各々に対して、（ｉｉｉ）〜（ｉｖ）を繰り返すことをさらに含み、全体として、前記複数のユーザー提供のバッファユニットがファイルに対応する、請求項１に記載の方法。
【請求項３】
前記ユーザー提供のバッファがサイズにおいて５１２Ｂ（バイト）と２ＭＢ（メガバイト）との間にある、請求項１に記載の方法。
【請求項４】
ユーザーが認識する論理ブロックアドレスに対して、前記メディエータが、前記本当の論理ブロックアドレスを複数回、相互に関連付ける、請求項１に記載の方法。
【請求項５】
前記バッファユニットがサイズにおいて５１２Ｂ（バイト）または４ＫＢ（キロバイト）である、請求項１に記載の方法。
【請求項６】
前記ハッシュ値がサイズにおいて８Ｂ（バイト）または１６Ｂ（バイト）である、請求項５に記載の方法。
【請求項７】
前記ユーザー提供のバッファユニットが、前処理によって形成され、前記前処理が：
（ｉ）複数のデジタル２値信号を受信することであって、前記デジタル２値信号が複数のチャンクレットに編成されており、各チャンクレットがＮビット長で、Ｎが１より大きい整数であり、前記チャンクレットが順序を有することと、
（ｉｉ）Ｘ個のマーカーのセットから、１つのマーカーを各チャンクレットに割り当てて、複数のマーカーのセットを形成することであって、Ｘがチャンクレット内のビットの異なる組合せの数以下であり、同一のサブユニットが前記マーカーに割り当てられていることと、
（ｉｉｉ）前記マーカーをバッファユニットとして使用することと、
を含む、請求項１に記載の方法。
【請求項８】
前記ユーザー提供のバッファユニットが、前処理によって形成され、前記前処理が：
（ｉ）複数のデジタル２値信号を受信することであって、前記デジタル２値信号が複数のチャンクレットに編成されており、各チャンクレットがＮビット長で、Ｎが１より大きい整数であり、前記チャンクレットが順序を有することと、
（ｉｉ）各チャンクレットを均一なサイズのサブユニットに分割して、Ｘ個のマーカーのセットから、１つのマーカーを各サブユニットに割り当てて、複数のマーカーのセットを形成することであって、Ｘがサブユニット内のビットの異なる組合せの数以下であり、同一のサブユニットが前記マーカーに割り当てられていることと、
（ｉｉｉ）前記マーカーをバッファユニットとして使用することと、
を含む、請求項１に記載の方法。
【請求項９】
少なくとも１つのマーカーが、サイズにおいてサブユニットより小さい、請求項８に記載の方法。
【請求項１０】
ステップ（ｉｉ）が、ビットマーカーテーブルおよび頻度変換器のうちの１つにアクセスすることを含む、請求項７〜８のいずれか一項に記載の方法。
【請求項１１】
データを格納するためのシステムであって、前記システムが、
（ａ）永続的メモリであって、前記永続的メモリが、格納されたバッファユニットを格納されたハッシュ値および本当の論理ブロックアドレスと関連付けるように構成されているハッシュ値テーブルを格納する、永続的メモリと、
（ｂ）持続性媒体内に格納されているコンピュータプログラムを格納しているか、またはそれに動作可能に結合されている、中央処理装置であって、前記コンピュータプログラムが、実行される際に、自動的に
ｉ．ハッシュ値アルゴリズムを１つ以上のユーザー提供のバッファユニットの各々に適用して、生成されたハッシュ値を作成し、
ｉｉ．前記生成されたハッシュ値が、格納されたバッファユニットと関連付けられている前記ハッシュ値テーブル内の格納されたハッシュ値の重複であるかどうかを判断し、そうである場合は、矛盾が存在するかどうかを判断し、前記矛盾が、２つの異なるバッファユニットと関連付けられているハッシュ値として定義されて、矛盾が存在する場合は、前記ハッシュ値テーブルを更新して、前記ハッシュ値テーブル内のハッシュ値を、前記格納されたバッファユニットではなく、前記ユーザー提供のバッファユニットと関連付けさせる、
実行可能コードを含む、中央処理装置と、
（ｃ）非キャッシュ記録媒体であって、前記非キャッシュ記録媒体がブロックレベル記憶に対して構成されており、書き込まれる各ユーザー提供のバッファユニットが、前記非キャッシュ記録媒体上の次の隣接するブロックに書き込まれる、非キャッシュ記録媒体と、
（ｄ）メディエータであって、前記メディエータが、本当の論理ブロックアドレスとユーザーが認識する論理ブロックアドレスとの相関関係を格納する、メディエータと、
を備える、システム。
【請求項１２】
前記コンピュータプログラムが、
ｉ．前記生成されたハッシュ値が、前記ハッシュ値テーブル内のハッシュ値の重複ではないか、または
ｉｉ．前記生成されたハッシュ値が、格納されたハッシュ値の重複であり、かつ矛盾があるか、のいずれか
の場合に限り、前記ユーザー提供のバッファユニットを前記非キャッシュ記録媒体に書き込む、請求項１１に記載のシステム。
【請求項１３】
複数のユーザーファイルに対して、ユーザーが認識する論理ブロックアドレスと本当の論理ブロックアドレスの相関関係があり、かつ、異なるファイルに対する複数の相関関係内に、前記本当の論理ブロックアドレスであるが、異なるユーザーが認識する論理ブロックアドレスが１つ以上ある、請求項１１に記載のシステム。
【請求項１４】
前記システムが取得モジュールをさらに備え、前記取得モジュールが、前記メディエータにアクセスして、ハッシュ値テーブルにアクセスすることなく、複数のバッファユニットを、前記メディエータによって指示される順序で再結合することにより、データファイルを再構成するように構成され、かつ、前記メディエータによって指示される順序が、前記非キャッシュ記録媒体上での前記バッファユニットの順序とは異なる、請求項１１〜１３のいずれか一項に記載のシステム。
【請求項１５】
コンピュータプログラムを格納しているコンピュータ可読記憶媒体であって、前記コンピュータプログラムが、コンピュータ上で実行される際に、前記コンピュータに、請求項１〜１０のいずれか一項に記載の方法を含む、ファイルシステム内で重複を排除し、データブロックを管理するための方法を実装させる、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの格納に関する。
【背景技術】
【０００２】
２１世紀は、人々および企業が生成および格納するデジタル化された情報の量において急激な増加を示してきた。この情報は、通常、ディスクなどの磁気面上に格納されている電子データから成る。これらのディスクは、サイズがサブマイクロメータで、データの個々のバイナリ断片を格納可能な、小さな領域を含む。
【０００３】
任意の所与の実体が格納する膨大な量のデータ内に、しばしば、情報の著しい重複がある。例えば、同じ会社のレターヘッドが何千もの文書に出現し得、そして、このデータに対応する各ファイルは、そのレターヘッダをコード化するビットを含むであろう。歴史的に、多数の実体は、この種の重複が自身のファイル内に存在すること、および同じ情報を重複して格納する非効率性は事業を行うためのコストであることを容認してきた。
【０００４】
記憶装置に対する費用が増加し、記憶装置の可用性が低下してきているので、実体は、ファイル間で重複した情報の全てよりは少ない情報を格納するための手段を探り始めている。理論上は、重複した情報の格納を回避するか、または重複した情報が格納される回数を最小限にしようと努める実体は、自身のデータセット内で一意のビットまたはバイトパターンを識別し、その一意のビットまたはバイトパターンを最小限の回数だけ、格納しようとし得る。これらの方法を実施するために、新しいファイルが、格納のために準備されているとき、それらのファイル内の情報が、既に格納された情報の参照セットと比較され得、検討されているビットまたはバイトパターンが一意の場合に限り、格納されるであろう。一意でない場合、冗長データは、その重複である格納されたデータを指す、データよりも小さいサイズの参照と置き換えられるであろう。
【０００５】
重複した情報が格納される回数を削減することの目標は：（１）冗長を検査するための十分な速度を維持すること；（２）取得のためのデータの再構成において十分な速度を維持すること；（３）冗長の検査または元のファイルに対応する情報の格納のいずれかのプロセス中に、データが失われないことを確実にすること；（４）格納された情報に対する権限のないアクセスを防ぐこと；および（５）データのスナップショットの取得、データの複製およびデータの復元の、全部ではないにしろ、１つ以上と関連して使用され得る効率的な技術および方法を提供すること、を含むが、それらに限定されない、いくつかの課題を提示する。本発明の様々な実施形態は、これらの課題の１つ以上を克服することに関する。
【発明の概要】
【課題を解決するための手段】
【０００６】
本発明は、冗長データが複数回、不必要に格納される程度を最小限にしながら、データを格納および取得する効率を向上させるための方法、システムおよびコンピュータプログラム製品を提供する。本発明の様々な実施形態を使用することにより、データを効率的に格納してアクセスすることができる。本発明のこれらの様々な実施形態を通して、データを変形し得、かつ／または変形もしくは変換されたデータが格納される物理装置を変更し得る。これは、実行される際に、本発明の方法またはプロセスの１つ以上を実施する、コンピュータプログラム製品を含むか、またはそれに動作可能に結合されているコンピュータを採用する自動化プロセスを通して達成され得る。これらの方法またはプロセスは、例えば、コンピュータアルゴリズムもしくはスクリプトで具現化されるか、またはそれを含み、任意選択で、１つ以上のモジュールを通して、システムによって実施され得る。
【０００７】
第１の実施形態によれば、本発明は、データを非キャッシュ記録媒体上に格納するための方法を対象とし、本方法は：（ｉ）データを非キャッシュ記録媒体に書き込むための命令を受信することであって、その命令が、ユーザーが認識する論理ブロックアドレス（「ＬＢＡ」）およびユーザー提供のバッファを含み、ユーザー提供のバッファが、例えば、５１２バイト〜２メガバイト、または５１２バイト〜６４Ｋから成る、データを非キャッシュ記録媒体に書き込むための命令を受信すること；（ｉｉ）ユーザー提供のバッファをユーザー提供のバッファユニットに分割して、暗号化ハッシュ関数をユーザー提供のバッファユニットの各々に適用し、それにより、生成されたハッシュ値を生成すること；（ｉｉｉ）コンピュータプログラム製品にハッシュ値テーブルをアクセスさせて、生成されたハッシュ値が、ハッシュ値テーブル内の格納されたハッシュ値と重複しているかを判断させるアルゴリズムを含むコンピュータプログラム製品を起動することであって、ハッシュ値テーブルが、複数の格納されたハッシュ値の各々を異なる格納されたバッファユニットおよび本当の論理ブロックアドレスと相互に関連付けて；（Ａ）生成されたハッシュ値がハッシュ値テーブル内にない場合は、ユーザー提供のバッファユニットを非キャッシュ記録媒体内のブロックに書き込み、ユーザー提供のバッファユニット、生成されたハッシュ値およびユーザー提供のバッファユニットが格納されている本当の論理ブロックアドレスの相関関係を含むようにハッシュ値テーブルを更新して、ユーザー提供のバッファユニットが書き込まれている位置に対応する本当の論理ブロックアドレスおよびユーザー提供のバッファに対するユーザーが認識する論理ブロックアドレス（または複数のアドレス）をメディエータ上に書き込み、（Ｂ）生成されたハッシュ値がハッシュ値テーブル内に格納されたハッシュ値と重複している場合は、矛盾があるかどうかを問い合わせ、矛盾は、同じハッシュ値が格納されたバッファユニットおよび現在のユーザー提供のバッファユニットと関連付けられていて、その２つのバッファユニットが異なる内容を有する状況として定義され、（ａ）矛盾がある場合は、ユーザー提供のバッファユニットを非キャッシュ記録媒体内のブロックに書き込み、格納されたバッファユニットと格納されたハッシュ値との間のハッシュ値テーブル内の関連付けを非アクティブにするか、または削除して、ユーザー提供のバッファユニット、生成されたハッシュ値およびユーザー提供のバッファユニットが格納されている本当の論理ブロックアドレスの相関関係を含むようにハッシュ値テーブルを更新して、ユーザー提供のバッファユニットが書き込まれている位置に対応する本当の論理ブロックアドレスおよびユーザーが認識する論理ブロックアドレスをメディエータ上に書き込み、（ｂ）矛盾がない場合は、ユーザー生成のバッファユニットと同じである、非キャッシュ記録媒体上に格納されたバッファユニットの本当の論理ブロックアドレスをメディエータ上に書き込み、それを、ユーザー提供のバッファユニットを非キャッシュ記録媒体上に書き込むことなく、ユーザー提供のバッファに対してユーザーが認識する論理ブロックアドレスと相互に関連付ける、コンピュータプログラム製品を起動すること、を含む。
【０００８】
ステップ（Ａ）において、ユーザー提供のバッファユニットを書き込む際に、当業者は、本方法は、テーブル内のハッシュ値と関連付けられていないと判断されているユーザー提供のバッファユニットを書き込む必要があることを理解するであろう。
【０００９】
しばしば、ユーザーは、ハッシュ値アルゴリズムが入力として受け入れるように構成されているユーザー提供のバッファユニットよりも大きい、ストリーム内またはユニット内のデータ（ユーザー提供のバッファ）を提供するであろう。これらの場合、ユーザー提供のバッファユニットは、ホストによって送信された生データをさらに小さいユニットにフラグメント化すること（ブレーキングとも呼ばれる）により形成され得、それは、ホストがそれらをフラグメント化するか、または本発明のシステムもしくは方法がそれを行うかどうかに関わらず、ユーザー提供のバッファユニットと見なされ得る。従って、これらのフラグメント化されたユーザー提供のバッファユニットは、暗号化ハッシュ関数に対する入力として機能し得る。限定されない例として、ユーザー提供されたデータは、１６Ｋ〜２ＭＢであり得、各フラグメント化されたユーザー提供のバッファユニットは、５１２バイト〜４Ｋまで、例えば、５１２バイトまたは４Ｋである。従って、いくつかの実施形態では、フラグメント化されたユーザー提供のバッファユニットは、フラグメンテーション前のユーザー提供のバッファサイズのわずか１／４またはわずか１／１６またはわずか１／６４である。フラグメンテーションのステップが、ハッシュ値アルゴリズムに入る前に使用される場合、ハッシュ値テーブルは、ユーザー提供のバッファユニットとハッシュ値の相関関係を含み得、記憶装置への書込みは、より大きなデータバッファユニットではなく、ユーザー提供のバッファユニットにフラグメント化され、メディエータが、ユーザー提供のバッファユニットのユーザーが認識するアドレス（または複数のアドレス）を複数のフラグメント化されたユーザー提供のバッファユニットと相互に関連付けるであろう。
【００１０】
本発明の本方法の様々なステップは、１つ以上のモジュール、例えば、バッファおよびユーザーが認識する論理ブロックアドレスの受信モジュール、フラグメンテーションモジュール、ハッシュ値検索モジュール、ハッシュ値の重複分析モジュール、矛盾モジュール、および書込みモジュール内に格納され得る。同様に、ファイルの読取りおよび再構成モジュールがあり得る。これらのモジュールは、持続性媒体内に実行可能コードの形で格納され得る。
【００１１】
第２の実施形態によれば、本発明は、データを格納するためのシステムを提供し、本システムは：（ａ）永続的メモリであって、格納されたバッファユニットを格納されたハッシュ値および本当の論理ブロックアドレスと関連付けるように構成されている、ハッシュ値テーブルを格納する、永続的メモリ；（ｂ）持続性媒体内に格納されているコンピュータプログラム製品を含むか、またはそれに動作可能に結合されている、中央処理装置であって、コンピュータプログラム製品が、実行される際に、自動的に（ｉ）ハッシュ値アルゴリズムを１つ以上のユーザー提供のバッファユニットの各々に適用して、生成されたハッシュ値を生成し、（ｉｉ）その生成されたハッシュ値が、格納されたバッファユニットと関連付けられているハッシュ値テーブル内の格納されたハッシュ値と重複しているかどうかを判断し、そうである場合は、矛盾が存在するかどうかを判断し（矛盾は、２つの異なるバッファユニットと関連付けられているハッシュ値として定義される）、矛盾が存在する場合は、ハッシュ値テーブルを更新して、テーブル内のハッシュ値を、格納されたバッファユニットではなく、ユーザー提供のバッファユニットと関連付けさせる、実行可能コードを含む、中央処理装置；（ｃ）非キャッシュ記録媒体であって、ブロックレベル記憶に対して構成されている、非キャッシュ記録媒体；および（ｄ）メディエータであって、本当の論理ブロックアドレスとユーザーが認識する論理ブロックアドレスとの相関関係を格納する、メディエータ；を含む。
【００１２】
第３の実施形態によれば、本発明は、コンピュータ可読プログラムを含む、持続性コンピュータ利用可能媒体を含むコンピュータプログラム製品を提供し、コンピュータ可読プログラムは、コンピュータ上で実行される際に、コンピュータに、本発明の方法のいずれかを含む、ファイルシステム内での重複排除、およびデータブロックの管理のための方法を実装させる。
【発明の効果】
【００１３】
ほとんどの状況で、以前に書き込まれたデータの重複である大きなバッファユニットは、非キャッシュ記録媒体（ＮＣＭ）に再度書き込む必要がないので、本発明の様々な実施形態を通して、データの格納および取得の効率が向上できる。代わりに、それが指すデータを収容する記憶装置よりもサイズが小さく、物理的に別個の構造中にある、メディエータ上のポインタが、コンピュータに、そのデータの以前に格納されたコピーを指示する。効率の向上は、一般に適用される方法で使用されるよりも少ない記憶空間を使用し、情報を格納および／または取得する活動において、より少ない時間および努力を投資することにより、実現され得る。さらにいくつかの実施形態では、本発明は、文書の格納および取得における速度の向上をもたらす。従って、本発明の技術および方法は、データを格納するために要求される物理的な記憶装置の総量を削減するのに役立つ。これは、重複したデータが書き込まれて格納される回数を最小限にすることにより、また、重複するデータがある状況では、以前に格納されたデータをポイントするメディエータを使用することにより、達成される。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に従ってデータを書き込むための方法の表現である。
【図２】本発明の方法に従って矛盾を解決するためのプロトコルの表現である。
【図３】本発明の一実施形態に従って、情報を読み取るための方法の表現である。
【発明を実施するための形態】
【００１５】
ここで、本発明の様々な実施形態に対する参照を詳細に行うが、その例が付随する図に示されている。以下の詳細な記述では、多数の具体的詳細が、本発明の完全な理解を提供するために記載されている。しかし、別段の指示がないか、またはコンテキストから暗黙的でない限り、詳細は例であることを意図し、本発明の範囲をいかなる方法でも制限すると見なされるべきでない。
【００１６】
定義
【００１７】
別段の指示がないか、またはコンテキストから暗黙的でない限り、次の用語および句は、以下に規定する意味を有する。
【００１８】
用語「ビット」は、二進数字を指す。それは、２つの値のうちの１つを有することができる。各値は、０または１のいずれかによって表され得る。
【００１９】
用語「ブロック」は、所定の長さを有するデータのバイトまたはビットのシーケンスを指す。記録媒体上で、物理媒体は、ブロックサイズによって定義されるユニットに分割され得る。記録媒体上の各ブロックは、論理ブロックアドレスによって識別され得る。業界では、現在のところ、５１２バイトがブロックの標準的なサイズである。しかし、４０９６バイトを標準として使用する動向がある。さらに、当業者であれば理解するように、句「ブロックサイズ」および「セクターサイズ」はしばしば、当業者によって区別しないで使用される。
【００２０】
句「ブート可能性コード」、「ブート可能性情報」および「ブート可能性特徴」は、ブート可能状態に入るための手段を提供する情報を指し、ブートセクター上に格納され得る。ブートセクターは、ファームウェアによってＲＡＭ（ランダムアクセスメモリ）内にロードされるように構成されている機械コードを含み得、それは、その結果として、ブートプロセスがプログラムを記憶装置から、または記憶装置にロードするのを可能にする。例として、マスターブートレコードが、アクティブなパーティションを見つけて、ボリュームブートレコードを呼び出すコードを含み得、ボリュームブートレコードは、オペレーティングシステムまたは他のスタンドアロンプログラムをロードして呼び出すためのコードを含み得る。
【００２１】
句「バッファユニット」は、ハッシュ値アルゴリズムへの入力としての使用に対して互換性があるサイズの、一連のビットを指す。バッファユニットは、チャンクレットと同じサイズであり得る。しかし、いくつかの実施形態では、それは、チャンクレットのサイズの分数であるか、またはチャンクレットのサイズの倍数であり得る。
【００２２】
用語「バイト」は、８ビットのシーケンスを指す。
【００２３】
用語「キャッシュ」は、データに対する将来の要求がより迅速に対応されるため、またはバッファリングを目的として、データが一時的に格納される位置を指す。Ｌ１キャッシュ（レベル１キャッシュ）は、例えば、プロセッサコアと統合されている、スタティックメモリを指す。Ｌ１キャッシュは、ＣＰＵ（汎用処理装置）が同じデータを複数回アセスする場合にデータアクセス速度を向上するために使用され得る。Ｌ２キャッシュ（レベル２キャッシュ）は、通常、Ｌ１キャッシュよりも大きく、データファイルが検索されたが、Ｌ１内で見つからなかった場合に、検索は、外部メモリを目指す前に、Ｌ２キャッシュで行われ得る。いくつかの実施形態では、Ｌ１キャッシュは、中央処理装置内ではない。代わりに、それは、ＤＤＲ、ＤＩＭＭまたはＤＲＡＭ内に置かれ得る。追加または代替として、Ｌ２キャッシュは、ＰＣＩ２．０／３．０の一部であり得、それは、マザーボードに入る。従って、Ｌ１キャッシュおよびＬ２キャッシュの各々は、マザーボードの別々の部分にあり得る。いくつかの実施形態では、本発明の方法が実装される際に、ハッシュ値テーブルは、Ｌ２キャッシュ内に常駐する。
【００２４】
用語「チャンクレット」は、セクタークラスタに対応し得るビットのセットを指す。チャンクレットのサイズは、記憶システムによって決定され得、チャンクレットサイズを有し得る。慣例的に、チャンクレットサイズは、ＣＨＳ方式によって導出されたが、ＣＨＳ方式は、シリンダー、ヘッドおよびセクターを、ハードディスク上にそれらが出現したところで定義したタプルによってブロックをアドレス指定した。ごく最近では、チャンクレットサイズは、論理ブロックアドレス（ＬＢＡ）測定から導出されている。例として、チャンクレットサイズは、５１２Ｂ、１Ｋ、２Ｋ、４Ｋ、８Ｋ、１６Ｋ、３２Ｋ、６４Ｋまたは１ＭＢであり得る。当業者として、１Ｋ＝１０２４Ｂが分かっている。チャンクレットは、生データとしてホストから受信され得る。
【００２５】
用語「矛盾」は、異なる入力（例えば、バッファユニット）に対する、ハッシュ値アルゴリズムなどの、関数による、同じ出力（例えば、ハッシュ値）の生成の出現を指す。
【００２６】
「ファイル」は、ビットまたはバイトで測定され得る長さをもつサイズのファイルを提供するために結合する関連したバイトまたはビットの集合である。ファイルは、チャンクレットよりも小さいか、チャンクレットと同じサイズか、またはチャンクレットよりも大きい可能性がある。
【００２７】
句「ファイル名」は、コンピュータが特定のファイルを識別して、そのファイルを他のファイルから区別できるようにする表記法またはコードを指す。
【００２８】
句「ファイルシステム」は、ファイルのセットを格納、取得、および更新するために使用される抽象化を指す。従って、ファイルシステムは、ファイルのデータおよびメタデータへのアクセス、ならびにデータを含む記憶装置上の利用可能な空間を管理するために使用されるツールである。いくつかのファイルシステムは、例えば、サーバー上に常駐し得る。ファイルシステムの例は、Ｕｎｉｘ（登録商標）ファイルシステムおよびその関連したディレクトリテーブルおよびｉノード、Ｗｉｎｄｏｗｓ（登録商標）  ＦＡＴ１６およびＦＡＴ３２ファイルシステム（ＦＡＴは、ファイルアロケーションテーブルを指す）、マスターファイルテーブルに基づく、Ｗｉｎｄｏｗｓ（登録商標）  ＮＴＦＳ、ならびに、ＨＦＳまたはＨＦＳプラスを使用する、Ａｐｐｌｅ  Ｍａｃ  ＯＳＸを含むが、それらに制限されない。
【００２９】
句「ハッシュ関数」、「暗号化ハッシュ関数」、「暗号化ハッシュ関数値アルゴリズム」、および「ハッシュ関数値アルゴリズム」は、（同じ長さまたは可変長の）大きなデータセットを、特定のハッシュ関数に対して固定長を有する、より小さいデータセットにマッピングする、アルゴリズムまたはサブルーチンを指す。「ハッシュ関数値」は、ハッシュ関数アルゴリズムの適用後に返される出力を指す。アルゴリズムが返す値は、ハッシュ値、ハッシュコード、ハッシュ合計、チェックサムまたはハッシュとも呼ばれ得る。例えば、ＭＤ５を使用する場合、出力は１２８ビットであり、他方、ＳＨＡ−１を使用する場合、出力は１６０ビットである。従って、いくつかの実施形態では、ハッシュ値は３２〜５１２ビットの長さである。
【００３０】
用語「ホスト」、「ユーザー」および「イニシエータ」は、区別しないで使用され得、データを格納のために、本発明のデータ記憶および取得仲介システムに送信するエンティティまたはシステムを指す。ホストは、１つ以上のタイプの文書またはファイルに対応するデータを送信して、データを受信し得る。好ましくは、任意の入力／出力（Ｉ／Ｏ）ストリーム内で、データは、単一の文書タイプのファイルに対応する。
【００３１】
用語「含む（ｉｎｃｌｕｄｉｎｇ）」および「包含する（ｃｏｍｐｒｉｓｉｎｇ）」は、制限のない方式で使用され、従って、「〜を含むが〜に制限されない」ことを意味すると解釈されるべきである。
【００３２】
略語「ＬＢＡ」は、「論理ブロックアドレス指定（ｌｏｇｉｃａｌ  ｂｌｏｃｋ  ａｄｄｒｅｓｓｉｎｇ）」または「論理ブロックアドレス」を指す。ＬＢＡは、リニアアドレス指定方式であり、ある記憶媒体、例えば、ハードディスク、内に格納されるデータブロックの位置を指定するために使用されるシステムである。ＬＢＡ方式では、ブロックは、整数によって見つけられ、１つだけの番号がデータをアドレス指定するために使用される。通常、第１のブロックはブロック０である。ユーザーは、データが特定のＬＢＡ上に格納されていると、信じ得る。データが格納されるとユーザーが認識する位置は「ユーザーが認識する論理ブロックアドレス」である。これは、データが実際に格納されている場所と異なり得る。データがＮＣＭ上に実際に格納される位置は、「本当の論理ブロックアドレス」と呼ばれ得る。
【００３３】
略語「ＬＵＮ」は、論理ユニット番号（ｌｏｇｉｃａｌ  ｕｎｉｔ  ｎｕｍｂｅｒ）を指し、論理ユニットを識別するために使用される。ＬＵＮは、通常、ＳＡＮを介して共有されるブロックストレージアレイを管理するために使用される。
【００３４】
用語「マネージャ」は、コンピュータプログラム製品、例えば、持続性媒体内に格納され得、かつ１つ以上の他の動作（例えば、データの受信、送信、または処理）をとらせるコードを指す。それは、ハードウェア、ソフトウェアまたはそれらの組合せ上に格納され得る。いくつかの実施形態では、マネージャは、マネージャがその意図する機能を実施するのを可能にするように構成されている、コンピュータおよび／またはシステムの一部であり得る。
【００３５】
用語「メディエータ」は、ハードウェア、ソフトウェアまたはそれらの組合せ上に格納され得、かつ少なくとも１つの非キャッシュ媒体内の記憶空間の１つ以上のユニットをファイル名と相互に関連付ける、コンピュータプログラム製品を指す。従って、それは、ユーザーが認識するＬＢＡを本当のＬＢＡと相互に関連付け得る。メディエータは、それがポイントする非キャッシュ媒体よりも数桁小さい可能性がある。例えば、メディエータは、おおよそ、通常のシリンダーのサイズの約０．２％の大きさしかない可能性がある。いくつかの実施形態では、メディエータは、コンピューティングクラウド内に存在し、一方、他の実施形態では、メディエータは、持続性有形的記録媒体内に存在する。メディエータは、データが実際には、記録媒体の異なるトラック内に出現している間に、ホストが、記録媒体のあるトラック内にあると認識する位置内のデータの、編成、翻訳、変換および格納の制御を行うことが可能であり得るか、または、全てではないにしろ、これらの機能の１つ以上に対応するマネージャに動作可能に結合され得る。さらに、メディエータは、セクターマップ、テーブル、または物理装置もしくは構造内に配置され得るデータの他の編成を含み得、従って、メディエータの内容は、物理装置もしくは構造にあるジオメトリを持たせ得る。いくつかの実施形態では、メディエータは、Ｌ２キャッシュ上に常駐する。
【００３６】
用語「メタデータ」は、データのコンテナに関する管理情報を指す。メタデータの例は、読み取られているファイルの長さまたはバイトカウント；ファイルが修正された最後の時間に関する情報；ファイルタイプおよびアクセス許可を記述する情報；ならびにＬＵＮ  ＱｏＳ、ＶＭおよびＷＯＲＭを含むが、それらに制限されない。他のタイプのメタデータは、オペレーティングシステム情報、自動初期化情報、グループ許可、および文書タイプ内のビットの頻度を含む。
【００３７】
略語「ＮＣＭ」は、非キャッシュ記録媒体を指す。ＮＣＭの例は、ハードディスクおよびソリッドステートドライブを含むが、それらに制限されない。ＮＣＭは、例えば、１００テラバイトのデータのバイトを保持するように構成され得る。ＮＣＭは、一意のバッファユニットを格納する。いくつかの実施形態では、ＮＣＭは、バッファユニットと格納されたハッシュ値の関連付けを含む、ダイジェストマップも格納する。これらの格納された関連付けは、サーバーのＲＡＭ内のハッシュ値テーブルにデータを投入するために使用され得る。ＲＡＭに、ＮＣＭの永続記憶装置からこの情報を取り込むことにより、高速ロードが達成され得る。追加または代替として、ＮＣＭは単位ブロック当たり１ビットのブットマップを格納し、それは、本発明の記憶装置節約を追跡するために使用され得る。実用性の問題として、ダイジェストマップのおよびビットマップの格納は、ＮＣＭ上に格納されたデータのブロック当たり、５〜１０バイトの間、例えば、８．１２５バイト、のわずかなオーバーヘッドを必要とする。代替として、ダイジェストマップおよびビットマップは、本発明の方法またはシステム利用の結果として書き込まれるバッファユニットを格納するのとは異なる記憶媒体上に格納され得る。
【００３８】
句「動作可能に結合された」は、用語「結合された」と区別しないで使用されて、システム、装置、および／またはモジュールが、互いにまたは相互に通信するように構成されて、通信時または通信した後に、それらの意図する目的を実施することが可能であることを意味する。この句および用語は、間接的、直接的、光学的、有線または無線接続を含む。従って、第１の装置が第２の装置と動作可能に結合されている場合、その接続は、直接的な電気的接続、他の装置および接続を経由した間接的な電気的接続、光学的接続、もしくは無線接続、またはそれらの組合せを通し得る。
【００３９】
句「オペレーティングシステム」は、コンピュータハードウェア資源を管理するソフトウェアを指す。オペレーティングシステムの例は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、およびＭａｃ  ＯＳ  Ｘを含むが、それらに制限されない。
【００４０】
用語「パーティション」は、記憶媒体、例えば、ディスクドライブをユニットに分割するフォーマットを指す。従って、パーティションは、ディスクパーティションとも呼ばれ得る。パーティションの例は、ＧＵＩＤパーティションテーブルおよびＡｐｐｌｅパーティションマップを含むが、それらに制限されない。
【００４１】
句「記録媒体」は、ビットに対応する磁気信号をその中に格納できる、持続性有形的コンピュータ可読記憶媒体を指す。例として、記録媒体は、ハードドライブ、ハードディスク、フロッピィディスク、コンピュータテープ、ＲＯＭ、ＥＥＰＲＯＭ、不揮発性ＲＡＭ、ＣＤ−ＲＯＭおよびパンチカードなどの、ＮＣＭを含むが、それらに制限されない。
【００４２】
用語「セクター」は、ディスク、例えば、磁気ディスク上のトラックの下位区分を指す。各セクターは、一定量のデータを格納する。ディスクに対する一般的なセクターサイズは、５１２バイト（５１２Ｂ）、２０４８バイト（２０４８Ｂ）、および４０９６バイト（４Ｋ）である。チャンクレットが４Ｋのサイズであり、各セクターが５１２Ｂのサイズである場合、各チャンクレットは８セクターに相当する（４＊１０２４／５１２＝８）。セクターは、トラックを有し、プラッター上に配置される。一般に、２つまたは４つのプラッターが１つのシリンダーを構成し、２５５のシリンダーがハードディスクおよび媒体装置を構成する。
【００４３】
句「セクターマップ」は、ホストから要求を受信して、ファイルが格納されている記憶装置内の位置を相互に関連付けるツールを指す。セクターマップは、例えば、ｉＳＣＳＩ（インターネット小規模コンピュータシステムインタフェース）プロトコルによって定義されるパラメータ下で動作し得る。本発明のいくつかの実施形態では、セクターマップは、メディエータのビットフィールド内に配置され得る。
【００４４】
用語「トラック」は、全てのセクターをトラバースするディスク内の円形の単位を指す。「トラックセクター」は、任意の１つのセクター内のトラックである。「トラッククラスタ」は、２つ以上のセクターに及ぶ。
【００４５】
好ましい実施形態
【００４６】
本発明は、データを非キャッシュ記録媒体上に格納するための方法、これらの方法を実施するためのコンピュータプログラム製品、およびこれらの方法を実施するように構成されているシステムを提供する。本発明の様々な実施形態を通して、重複したデータが格納される回数を減らすことにより、データを効率的に格納および取得することができる。
【００４７】
一実施形態によれば、本発明は、データを非キャッシュ記録媒体上に格納するための方法を提供する。いくつかの実施形態では、受信されるデータは、ユーザー定義の論理ブロックアドレス（ＬＢＡ）およびユーザー提供のバッファを含むか、基本的にそれらから成るか、またはそれらから成る。ユーザー提供のバッファのサイズは、例えば、５１２バイト〜６４Ｋまたはそれ以上、例えば、最大で２メガバイトであり得る。受信されるデータは、（ＬＢＡｘ，バッファｘ）の形であり得、ここでｘ＝１〜ｎおよびｎ＝ユーザーが送信するバッファ数である。バッファは生データであり、従って、それらは、任意の文書タイプ、例えば、ＪＰＥＧ、ＰＤＦ、ＷＯＲＤ文書、ＭＰＥＧおよびＴＸＴ文書、に対応し得る。
【００４８】
ユーザーが送信する総ストリームは、Ｎバイトの形式であり得る。ストリームは、有線または無線のネットワークを経由し、Ｉ／Ｏストリームを伝送するための既知の方法および技術を通して、受信され得る。ユーザーは、データをフォーマット：（ＬＢＡｘ，バッファｘ）にフォーマットし得るか、またはユーザーはデータを、そのデータをこのフォーマットにフォーマットするサーバーに送信し得る。従って、Ｎは、バッファユニットのサイズよりも大きい可能性がある。好ましくは、ユーザーは、データをファイル名および／またはファイル識別子とともに伝送する。
【００４９】
Ｎがバッファユニットのサイズよりも大きい場合、データのストリームの受信後に、サーバーは、Ｎバイトをバッファユニットにフラグメント化し得る。従って、バッファは、任意のサイズであり得るデータのストリームであるが、バッファユニットは、固定サイズであり、ＮＣＭ上の記憶ユニットのサイズに対応する。例えば、ユーザーは、１０２４バイトの単一バッファを、ＬＢＡ１０で始まるためのファイルに対する指定とともに送信し得る。本発明の実施態様のバッファユニットサイズが５１２バイトである場合、データは、ＬＢＡ２０およびＬＢＡ２１に格納され得る。とりわけ、いくつかの実施形態では、ユーザーは、開始ＬＢＡのみを伝送し得、そのシステムは、ファイルが、そのアドレスから開始して、そのファイルに対して十分な空間があるように、連続したブロックまで伸びる、ＮＣＭ上に格納されることを認識するであろう。
【００５０】
このフラグメンテーションは、総ストリームまたはチャンクレットについて実行され得る。例えば、本方法が、４Ｋのサイズのバッファユニットを受信するように構成されているが、ユーザーが１６Ｋのサイズのチャンクレットを伝送する場合、サーバーがそのチャンクレットを受信後または受信時に、それは、各チャンクレットを、各々が４Ｋのサイズの４つのバッファユニットに分割するためのプロトコルを開始するであろう。従って、いくつかの実施形態によれば、データを（ＬＢＡｘ，バッファｘ）の形式で受信するか、または受信するデータを、この形式に変換する。ユーザーがデータを、必要なバッファユニットサイズになるように構成されているか、またはそのサイズに変換されるパケットで提供するかに関わらず、ハッシュ値アルゴリズムに対する入力として機能するバッファユニットの各々は、「ユーザー提供のバッファユニット」と呼ばれる。
【００５１】
データが正しいフォームで受信された（または正しいフォームに変換された）後、暗号化ハッシュ関数値アルゴリズムが、各バッファユニットに適用されて、そのバッファユニットに対する生成されたハッシュ値を形成する。生成されるハッシュ値は、生成されたハッシュ値と呼ばれ得る。暗号化ハッシュ値アルゴリズムは、例えば、持続性記憶媒体内に格納されている、コンピュータプログラム製品またはコンピュータプログラム製品内のプロトコルの形式であり得る。これらのタイプのアルゴリズムの例は、ＭＤ５ハッシュ（メッセージダイジェストアルゴリズムとも呼ばれる）、ＭＤ４ハッシュおよびＳＨＡ−１を含むが、それらに制限されない。ハッシュ関数値アルゴリズムから出力される値は、ハッシュ値、チェックサムまたは和（ｓｕｍ）と呼ばれ得る。いくつかの実施形態では、ハッシュ値は、６４、１２８、もしくは２５６ビットまたは８バイトのサイズ、あるいは中間の任意の値である。Ｉ／Ｏストリーム内のデータの非常に繰り返しが多い特質のために、矛盾するハッシュ値、すなわち、同じであるが、異なるバッファユニットに対応するハッシュ値、を生成する確率は、比較的低い。本方法は、先入れ先出し（「ＦＩＦＯ」）プロトコルに従ってハッシュ値を取得し得、Ｉ／Ｏストリームが受信されている間、ハッシュ値が生成されている間、または全てのＩ／Ｏストリームが受信されて、フラグメント化され、必要ならば、ハッシュ関数値アルゴリズムを適用された後のいずれかに、相関ファイルのアクセスを開始する。
【００５２】
生成されたハッシュ値がユーザー提供のバッファユニットに対して取得された後、その生成されたハッシュ値を生成した、異なるコンピュータプログラム製品または同じコンピュータプログラム製品内の異なるモジュールが、アクセスされる。このコンピュータプログラム製品は、ハッシュ値テーブルをアクセスする。ハッシュ値テーブルは、例えば、永続的メモリ内に格納されて、アクセスおよび使用のためにＬ２キャッシュに置かれ得る。ハッシュ値テーブル内で、複数の格納されたハッシュ値が各々、格納されたバッファユニットのセット内の異なる格納されたバッファユニットおよびＮＣＭ上のバッファユニットの本当のＬＢＡと関連付けられる。句「格納されたハッシュ値」は、ハッシュ値アルゴリズムにより特定のユーザー提供のバッファユニットに対して生成されるハッシュ値と対比するために使用され、それは、生成されたハッシュ値と呼ばれ得る。
【００５３】
ハッシュ値テーブルは、当初、特定のハッシュ値アルゴリズムによって関連付けられたとおりの既知のハッシュ値およびバッファユニットのセットで生成され得る。これらの既知の値は、アルゴリズムの経験的な先使用、例えば、１つのホストのファイルまたは同様の産業におけるホストのファイルに対して以前に生成されたもの、に基づき判断されている可能性がある。代替として、それは、当初は空であり得、最初のユーザー提供のバッファユニットが関連付けの空白（ｎｕｌｌ）のセットと比較される。使用時には、ハッシュ値テーブルは、例えば、サーバー上の、ＲＡＭ内に常駐し得る。従って、ハッシュ値テーブルまたはそれに投入するためのデータは、バッファユニットを格納するＮＣＭ上、またはシステムのブートもしくは再ブート時にＲＡＭを再設定するためにアクセスできるフォーマット内のどこかなど、永続記憶装置内に常駐し得る。更新される場合、更新は、ＲＡＭ内のテーブルに対して、および永続的メモリに対しても、行われる。
【００５４】
いくつかの実施形態では、いかなる時でも、テーブル内で、所与の格納されたハッシュ値が、わずか１つのバッファユニットとアクティブに関連付けられる。バッファユニットがハッシュ値テーブル内にあり、格納されたハッシュ値と関連付けられている場合、そのバッファユニットは「格納されたバッファユニット」である。ハッシュ値テーブル内の特定のハッシュ値と関連付けられているバッファユニットは、時間とともに変わり得、以下で説明するように矛盾が起こった場合、最新のバッファユニット、ハッシュ値アルゴリズムによって判断されたハッシュ値関連付けが、本明細書で説明する方法の適用後に、テーブル内のアクティブな関連付けになるであろう。句「アクティブな関連付け」および「アクティブに関連付けられた」は、テーブルが、生成されたハッシュ値との比較のために抽出されるデータを、提供するか、構成するか、または示す条件を指す。アクティブな関連付けは、ハッシュ値アルゴリズムの適用時に、ハッシュ値の生成をもたらす、バッファユニットを最後に受信したＮＣＭ上の本当の論理ブロックアドレスを含み得る。一旦、ハッシュ値が格納されたハッシュ値になると、それは、テーブル内にとどまるが、時間とともに、それが関連付けられているバッファユニットは変わり得る。従って、格納されたバッファユニットは、格納されたバッファユニットのままでない可能性がある。
【００５５】
当業者は、ある実施形態では、ハッシュ値テーブルを使用するのではなく、マルチマップを使用し得ることを認識するであろう。マルチマップを使用する場合、ハッシュ値は、２つ以上のバッファユニットと関連付けられ得、従って、矛盾がある場合に、以前に格納されたハッシュ値が除去される必要がない。
【００５６】
ハッシュ値アルゴリズムは、複数の異なるバッファユニットに対して同じハッシュ値を生成できるので、手続きは、テーブル内でのこれらの出現を扱う方法を判断する必要がある。格納されたハッシュ値と同じである、ハッシュ値が、ユーザー提供のバッファユニットに対して生成されている場合、次の３つの手続きのうちの１つが使用され得る：（１）既存の関連付けが新しい関連付けで上書きされ得る；（２）既存の関連付けが削除され得、新しいエントリがテーブル内に、例えば、新しい位置で作成され得る；または（３）既存の関連付けが非アクティブなファイルに移動され得るか、または別の方法でそれが非アクティブであることを示すように修正され得るが、情報は、例えば、アクティブなファイル内に保持され、適切に設計されたコンピュータプログラムを通じて、後にアクセスできる。条件（１）または（３）は、関連付けを非アクティブにする例である。当業者であれば認識するように、ＮＣＭからのデータ取得は、ハッシュ値テーブルへのアクセスを必要としないので、任意のアーカイブされた情報は、本発明の様々な実施形態の実装のために必要でない。しかし、この情報は、同じハッシュ値が異なるユーザー提供のバッファユニットまたはフラグメント化されたユーザー提供のバッファユニットに対して生成されている程度を再検討するために使用され得る。
【００５７】
データの非常に繰り返しが多い特質のために、矛盾するハッシュ値が、ハッシュ値アルゴリズムの適用の結果として生成されている確率は低い。例えば、ＳＨＡ−１の１６０ビットのハッシュは、異なるパターンに対して同じハッシュ値をランダムに生成する、１０２４分の１の確率を有する。本発明は、重複したバッファユニットが格納される程度を最小限にするために、ハッシュ値アルゴリズムのこの特徴を利用する。これを達成するために、本方法は：（１）新しく生成されたハッシュ値が、それに対して格納されたバッファユニットがある、格納されたハッシュ値と同じであるか；そうであれば、（２）そのハッシュ値に対して格納されたバッファユニットがユーザー提供のバッファユニットと異なるような矛盾があるか、を問い合わせる、２つのモジュールまたは２つの別個のコンピュータプログラムアルゴリズムの割当てを提供する。
【００５８】
前述の問合わせの結果は、どの新しい情報がＮＣＭ上に格納されるか、およびどのような状況下で、ならびに何がメディエータに書き込まれるか、を判断する。最も簡単な場合には、本発明のプロトコルは、ハッシュ値の重複がないことを判断する。ハッシュ値の重複がないことは、ユーザー提供のバッファユニットがハッシュ値テーブル内にないことを示す。その結果として、バッファユニットが、ＮＣＭの新しいブロック内に書き込まれて、ユーザーが後に同じバッファユニットを、異なるデータストリームもしくはデータパケットの一部として、または後に同じデータストリーム内で、投入する場合に、それがＮＣＭ上に既に格納されているデータと同じであることを方法が検出できるように、更新がハッシュ値テーブルに対して行われる。ハッシュ値テーブルは、バッファユニットが書き込まれる本当のＬＢＡを含むようにも更新される。生成されたハッシュ値およびユーザー提供のバッファユニットをハッシュ値テーブルに書き込むと、それらは、それぞれ、格納されたハッシュ値および格納されたバッファユニットとなる。
【００５９】
方法が、ハッシュ値の重複があると判断する場合、第２の問合わせが行われる。前述のように、この第２の問合わせでは、本方法は、アルゴリズムをユーザー提供のバッファユニットに対して適用すると、たとえ２つのバッファユニットが異なっていても、既に格納されたバッファユニットが関連付けられている同じハッシュ値の生成をもたらすかどうかを検討する。
【００６０】
当業者であれば認識するように、この２段階のアプローチは、重複したデータがＮＣＭ上に格納される回数を減らすための方法に効率をもたらす。第１のステップでは、ハッシュ値が比較される。これらの値は、バッファユニットよりも小さく（例えば、バッファユニットよりも少なくとも２分の１、少なくとも１０分の１、少なくとも１００分の１、または少なくとも１０００分の１小さい）、従って、バッファユニット自体よりも比較しやすい。それらの値がハッシュ値の重複を示す場合に限り、システムは実際のバッファユニットを比較する。従って、バッファユニットを互いに対してチェックする前に、ハッシュ値テーブル内にまだないハッシュ値と関連付けられているバッファユニットを除去することにより、システムは効率的である。
【００６１】
問合わせの第２の段階では、２つのバッファユニットを相互に比較する。矛盾がない、すなわち、（格納されたものおよび現在のユーザー提供の）バッファユニットの本当の識別がある場合；ＮＣＭへの書込みの追加のステップが必要とされない。代わりに、バッファユニットが以前に格納されたブロックのメディエータに付けられた印があることを必要とするだけである。従って、これらのバッファユニットは再度書き込まれる必要がないので、効率が向上する。それが属するファイルを追跡するために、メディエータ内で、ＬＢＡは、ユーザーが認識するＬＢＡ、および任意選択で、ユーザーが生成したファイル名またはファイルシステムと関連付けられる。
【００６２】
問合わせの第２の段階の他の結果は、（格納されたバッファユニットと関連付けられた際の）格納されたハッシュ値が、生成されたハッシュ値と同じであるが、格納されたバッファユニットおよびユーザー提供のバッファユニットが異なるので矛盾がある場合に生じる。これらの場合、本発明の方法は、ユーザー提供のバッファユニットがＮＣＭへの書込みを必要としていると考える。本方法は、ハッシュ値テーブルも変更させて、それが、共通のハッシュ値をユーザー提供のバッファユニットと関連付けるようにする。共通のハッシュ値の以前の関連付けが、非アクティブにされるか、または削除される。その結果として、重複したバッファユニットを検索する後続の問合わせでは、より最近格納されたハッシュ値、バッファユニット関連付けが検討される。これらの方法では、矛盾が生じた場合には、ハッシュ値の拡張は絶対に必要ない。
【００６３】
様々な実施形態では、各ＬＢＡｘに対して、本方法は、メディエータにＬＢＡｙをＬＢＡｘとともに格納させ、ＬＢＡｙは、ユーザー提供のバッファユニットと同一である、バッファユニットの実際の位置を指す。ＬＢＡｘは、バッファユニットが格納されているとユーザーが信じる位置であり、ＬＢＡｙは、バッファユニットが実際に格納されている位置であるので、ＬＢＡｙは、ハッシュ値テーブル内にも格納される。しかし、ＬＢＡｘは、ハッシュ値テーブルから省かれ得、いくつかの実施形態では、メディエータ上にのみ存在する。任意選択で、メディエータは、ユーザー作成のファイル名および／またはファイル識別子も格納して、そのファイル名を１つ以上のユーザーが認識する論理ブロックアドレスと関連付ける。
【００６４】
前述のように、ほとんどのバッファユニットはＮＣＭ上に一度だけ格納される。従って、複数のユーザーファイルに対して、ユーザーが認識する論理ブロックアドレスと本当の論理ブロックアドレスとの相関関係があり、異なるユーザーファイルに対応する複数の（メディエータ上の）相関関係内には、同じ本当の論理ブロックアドレスであるが、異なるユーザーが認識する論理ブロックアドレスが１つ以上ある。実際のユーザーファイル内で最も繰り返しが多いバッファユニットは、最多数の異なる相関関係内に出現するであろう。加えて、ユーザーはバッファを提供し、それがＮＣＭ上の連続したサイトに格納されていると信じ得るので、単一のＬＢＡｘとそのバッファとの関連付けを記録して、データをＬＢＡｘから始まる連続したＬＢＡに格納されていると見なし得る。しかし、格納は実際にはバッファユニットレベル上であり、しばしば、所与のバッファに対して連続した位置に格納されないので、メディエータは、単一のユーザーが認識するＬＢＡ（または、暗黙的もしくは明示的に）複数の連続したＬＢＡを、連続していない複数の本当のＬＢＡとともに格納し得る。例えば、ユーザーは、サイズが４０９６Ｂで、ユーザーが認識するＬＢＡが１０のバッファを供給し得る。バッファユニットが５１２Ｂのサイズである場合、ユーザーは暗黙的に、そのデータはＬＢＡ  １０から始まる８つの連続した記憶サイトにあると信じ得る。しかし、実際には、それらは、ＬＢＡ４、ＬＢＡ３、ＬＢＡ２、ＬＢＡ２、ＬＢＡ３、ＬＢＡ３、ＬＢＡ９、ＬＢＡ４であり得、メディエータは、それらの位置を指すであろう。とりわけ、全部ではないにしろ、ユーザーが送信するバッファ内のデータに対応する、ほとんどの重複したバッファユニットに対して、メディエータはＮＣＭ上の同じＬＢＡを指すであろう。従って、メディエータ上に、いくつかの実施形態では、全てのデータの本当の位置（例えば、全ての本当のＬＢＡ）の、ユーザーから受信した際のユーザーが認識する位置または複数の位置との相関関係があり得る。
【００６５】
従って、これらの方法では、拡張を使用して、ハッシュ値アルゴリズムの同じハッシュ値を生成する可能性を考慮に入れるのではなく、（ｉ）比較可能なハッシュ値が、任意のバッファユニットと関連付けられているとして、まだハッシュ値テーブル内にない；または（ｉｉ）任意の所与のハッシュ値に対して、矛盾がある：場合に限り、前述した関連付けの最新の出現を使用して、特定の提供されたバッファユニットをＮＣＭに書き込む。これらの後者の場合、以前に書き込まれている、同じデータのＮＣＭへの何回かの書込みがあり得る。しかし、実用性の問題として、まれにしか起こらないであろう。
【００６６】
いくつかの実施形態では、バッファユニットのＮＣＭへの書込みは連続的である、すなわち、書き込まれる各ユーザー提供のバッファユニットは、ＮＣＭ上の次の隣接するブロックに書き込まれ得る。従って、ＮＣＭ上でのデータの散在が最小限であるか、または全くなく、それは、読取り／書込み性能を向上して、記憶空間の節約を可能にする。加えて、実際のＮＣＭへの書き込みが少ないので、読取り／書込み性能が向上する。これは、その結果として、オペレーティングシステムのキャッシュがより良く機能するのを可能にする。さらに、ＮＣＭ上のデータは、メディエータおよびハッシュ値テーブルがない限り、ファイルを再構成するために使用できないので、データのセキュリティを向上できる。
【００６７】
本発明のさらなる利点は、データがどのように読み取られるかを考慮すると、理解され得る。ユーザーは、ファイルを読み取る要求を送信し得る。要求は、ファイル識別子および１つ以上のユーザーが認識する論理ブロックアドレスに関する情報を含む。関連するメディエータにアクセスすることにより、実際の論理ブロックアドレス（複数可）を判断して、関連するデータを取得できる。とりわけ、書込みプロトコルとは対照的に、取得および読取りステップ中に、ハッシュ値アルゴリズムまたはテーブルは必要ない。代わりに、読取り装置は、メディエータが指すＮＣＭ上のサイトからデータを取得し、また、メディエータは、１つ以上のファイルに対して、１つ以上のバッファユニットを複数回、指し得る。
【００６８】
本発明は、データを効率的に格納するためのシステムも提供する。これらのシステムは：（ａ）永続的メモリ；（ｂ）中央処理装置（ＣＰＵ）；（ｃ）非キャッシュ記録媒体；および（ｄ）メディエータ；を含み得る。構成要素の各々は、それらの指定された機能を実行するために、１つ以上の他の構成要素と動作可能に結合され得る。
【００６９】
永続的メモリは、ハッシュ値テーブルを含み、以下で説明する非キャッシュ記録媒体の一部であり得るか、またはそれとは異なり得る。ハッシュ値テーブルは、複数の格納されたハッシュ値の各々を異なる格納されたバッファユニットと関連付ける。ハッシュ値は、ハッシュ値アルゴリズムのバッファユニットに対する適用によって判断される。各格納されたバッファユニットは、本当の論理ブロックアドレスとも関連付けられる。当業者は、ハッシュ値テーブルが、３つのタイプのデータ：格納されたハッシュ値、格納されたバッファユニットおよび本当の論理ブロックアドレスの間の関連付けを１つのテーブル内に含み得ることを認識するであろう。あるいは、ハッシュ値テーブルは、１つのテーブル内に、最初の２つのタイプのデータだけの関連付けを含み得、同じか、または異なるメモリ装置（例えば、メディエータ）内の、別のテーブル内に、本当のＬＢＡと格納されたバッファユニットを相互に関連付けるテーブルが格納され得る。永続的メモリは、ＣＰＵ内に格納され得るか、またはＣＰＵに動作可能に結合され得る。
【００７０】
中央処理装置は、ハードウェアまたはハードウェアとソフトウェアの組合せから成る。ＣＰＵは、永続的メモリにアクセスして、ハッシュ値テーブルを検索するように構成される。ＣＰＵは、ＮＣＭおよびメディエータへの書込みを含むがそれらに制限されず、本発明の方法の１つ以上を実行するようにも構成される。さらに、ＣＰＵは、例えば、サーバーを通じて、無線または有線ネットワークを通して１つ以上のリモートユーザーと通信するように構成される。
【００７１】
ＮＣＭは、ブロックレベル記憶に対して構成される。ＮＣＭは、ＣＰＵとは別個であり得るか、またはＣＰＵの一部であり得る。
【００７２】
前述したシステムのいくつかの実施形態では、メディエータ、ハッシュ値テーブル、ＣＰＵおよび非キャッシュ記録媒体の各々は、互いにリモートに格納される。それらは、同じ筐体内の別個の構造内または異なる筐体内にあり得る。
【００７３】
前述のように、（サーバーを通して制御され得る）本発明のシステムは、メディエータを調べた後にハッシュ値テーブルにアクセスすることなく、ファイルを再作成してデータをユーザーに伝送することができる。従って、一実施形態では、本発明のシステムは、取得モジュールを含み、取得モジュールは、メディエータにアクセスして、ハッシュ値テーブルにアクセスすることなく、複数のバッファユニットを、メディエータによって指示される順序で再結合することにより、データファイルを再構成するように構成され、メディエータによって指示される順序は、非キャッシュ記録媒体上でのバッファユニットの順序とは異なる。
【００７４】
本発明の様々な方法は、マネージャによって自動的に制御され得る。マネージャは、１つ以上のモジュールを含み、ローカルコンピュータ上、ネットワーク上、またはクラウド内または例えば、ＣＰＵ内に常駐し得る。マネージャは、情報自体の受信を調整するか、または情報自体を受信して、この情報をメディエータに転送するか、または、情報の受信を直接メディエータによって制御するように構成され得る。従って、本方法は、イニシエータからの情報が、本発明の重複排除方法のため、マネージャを通り、マネージャの指示で、メディエータに、またはシステムの他の構成要素に流れるが、マネージャを通って流れないように、設計できる。
【００７５】
いくつかの実施形態では、マネージャは、１つまたは複数のメディエータを制御し、それと通信し、かつ、その活動を調整し得る。各メディエータに対して、マネージャは、パラメータのセットを受信する（または、その受信を調整する）。これらのパラメータは、ファイルシステム情報、ブート可能性情報、およびパーティション分割情報の１つ、２つ、もしくは３つ全部を含むか、基本的にそれらから成るか、またはそれらから成り得る。
【００７６】
メディエータは、例えば、（ａ）トラックの第１のセット；（ｂ）トラックの第２のセット；（ｃ）トラックの第３のセット；および（ｄ）トラックの第４のセット：を含み得る。マネージャは、ファイルシステム情報、ブート可能性情報、およびパーティション分割情報を、メディエータ上のトラックの第１のセット内に格納させ、それは、予約１またはＲ１と呼ばれ得る。この情報は、ファイルシステム情報の識別を含み得、それは、予約ブロックがどのように使用されるかを指示する。例えば、ＮＴＦＳを使用する場合、セクター１〜２がＭＢＲ（マスターブートレコード）用であり得、セクター３が＄ＭＦＴ用であり得る。任意選択で、これらのトラックが、トラックの第２のセットにコピーされ得、それは、予約２またはＲ２と呼ばれ得る。
【００７７】
これらの実施形態では、マネージャは、前のパラグラフで説明したパラメータに加えて、メタデータも受信し得る。メタデータは、メディエータ上のトラックの第３のセット内に格納され得る。マネージャがパラメータおよびメタデータを受信する時、またはその後に、それは、非キャッシュ媒体上に格納するための１つ以上のファイルも受信し得る。各ファイルは、ファイル名および１つ以上のユーザーが認識するＬＢＡとともに受信される。ファイル名は、ファイルを伝送するホストによって生成され、ホストのファイルシステムによって定義され得る。例えば、ＳＡＮもしくはＮＡＳもしくはそれらの組合せであるか、またはその一部であり得る、マネージャは、ファイルをファイル名とともに受信すると、本当のＬＢＡおよびユーザーが認識するＬＢＡをトラックの第４のセットのビットフィールド内に格納することを含め、格納のための本明細書で説明するステップを自動的に実行できる。
【００７８】
いくつかの実施形態では、生データを受信すると、本発明の方法は、受信の確認を自動的にホストに返させ得る。あるＱｏＳ（サービス品質）プロトコルでは、データファイルがＩ／Ｏを通して受信されて、直ちにＬ１キャッシュに送信される。受信されると、確認がＬ１キャッシュからＩ／Ｏを通して返送される。Ｌ１キャッシュから、データファイルがＬ２キャッシュに送信され得、Ｌ２キャッシュは確認をＬ１キャッシュに返送する。Ｌ２キャッシュは、データファイルを、本発明の実施形態の１つ以上を実行するシステムまたはシステムの一部にも送信し、本発明の重複排除プロトコルを経た後、メディエータに書き込み、いくつかの場合には、長期格納のために、非キャッシュ媒体（ＮＣＭ）に書込み得る。ＮＣＭは、同様に、確認をＬ２キャッシュに返送し得る。
【００７９】
いくつかの実施形態では、メディエータは、Ｌ１キャッシュ内のヒープ（動的に割り当てられるメモリ）内に常駐し得るか、またはそれに動作可能に結合され得る。代替として、メディエータは、カード内に常駐し得るか、またはＬ２キャッシュの一部であり得るか、もしくはＬ２キャッシュに動作可能に結合され得るか、またはソリッドステートドライブもしくは格納用の任意のブロック装置上にあり得る。
【００８０】
当業者であれば分かるように、メディエータを、Ｌ２に対してＬ１内に置くという判断は、格納されたデータの使用の頻度などの要因によって影響を受けるであろう。従って、Ｌ１キャッシュは、システムまたはエンドユーザーによって頻繁に使用されるデータを格納するために使用され、他方、Ｌ２キャッシュは、幾分頻繁にアクセスされるデータに対して使用され得る。
【００８１】
別のＱｏＳプロトコルでは、Ｉ／Ｏを通して、データファイルがＬ１キャッシュによって受信される。データファイルは、Ｌ１キャッシュからＬ２キャッシュおよびＮＣＭの両方に転送される。Ｌ２キャッシュおよびＮＣＭの各々が、確認をＬ１キャッシュに送信する。Ｌ２キャッシュおよびＮＣＭの一方または両方から確認を受信する前、または後のいずれかに、Ｌ１キャッシュはＩ／Ｏを通して確認を送信する。
【００８２】
前述のように、メディエータは、トラックの第１の予備セット（Ｒ１）およびトラックの第２の予備セット（Ｒ２）を含み得る。いくつかの実施形態では、トラックの第２の予備セット（Ｒ２）は、トラックの第１の予備セット（Ｒ１）のコピーである。追加として、いくつかの実施形態では、トラックの第２の予備セット（Ｒ２）を使用して、トラックの第１の予備セット（Ｒ１）内のエラーをチェックし得る。
【００８３】
Ｒ１は、ホストの開始のための中心点として機能するように構成され得る。従って、本発明の重複排除方法のいずれかの前に、ホストは、Ｒ１に送信するパラメータを選択し得る。メディエータは、この情報をホストから直接に、またはマネージャを通して間接的に、受信し得る。好ましくは、Ｒ２は、決してホストに公開されない。従って、メディエータ自身またはマネージャのみが情報をＲ２に格納できる。Ｒ１およびＲ２の各々は、例えば、１６のセクターを含み得、ホスト修飾子などの実際のデータで満たされ得る。慣例により、番号付けは、０から始まり得る。従って、Ｒ１は、例えば、セクター（またはトラック）０〜１５を含み得、Ｒ２は、セクター（またはトラック）１６〜３１を含み得る。しかし、メディエータは、Ｒ１およびＲ２の各々が、１６トラックの初期サイズを超えて拡張するのを可能にするように構成され得る。
【００８４】
いくつかの実施形態では、Ｒ１は、一意の予備セクター情報およびパーティション情報を含む。パーティション情報内には、ファイルシステム情報を格納し得る。
【００８５】
限定されない例として、また、当業者であれば分かるように、ボリュームをＮＦＴＳファイルシステムでフォーマットする際に、＄ＭＦＴ（マスターファイルテーブル）、＄Ｂｉｔｍａｐ、＄Ｌｏｇ  Ｆｉｌｅおよびその他などの、メタデータファイルを作成する。このメタデータは、ＮＦＴＳボリューム上のファイルおよびフォルダの全てに関する情報を含む。ＮＴＦＳボリューム上の第１の情報は、パーティションブートセクター（＄Ｂｏｏｔメタデータファイル）であり得、セクター０に配置され得る。このファイルは、基本ＮＴＦＳボリューム情報およびメインメタデータファイル＄ＭＦＴの位置を記述し得る。
【００８６】
フォーマットプログラムは、＄Ｂｏｏｔメタデータファイルに対して最初の１６セクターを割り当てる。最初のセクターは、ブートストラップコードを有するブートセクターであり、次の１５のセクターは、ブートセクターのＩＰＬ（初期プログラムローダー）である。
【００８７】
Ｒ１およびＲ２のトラックに加えて、メディエータは追加のメタデータを格納し得る。このメタデータは、例えば、シンプロビジョニングストラテジの実行を可能にする情報に対応し、それは、装置が、実際に利用可能であるよりも多くの物理的資源を有しているように見えるのを可能にして、例えば、トラック３２〜３９であり得る、Ｒ２の後の８トラック内に含まれ得る。メタデータは、ＬＵＮ  ＱｏＳ、ＶＭおよびＷＯＲＭなどの特徴も提供し得る。
【００８８】
最後に、メディエータは、ビットフィールドも含み得る。ビットフィールドは、データが記憶媒体内の物理的にどこに格納されているかを示す情報を含み、メタデータがトラック３２〜３９に置かれている場合、ビットフィールドのセクター番号はトラック４０から始まる。ホストのファイル名とデータの位置との間の相関関係が格納されているのはメディエータのビットフィールド内である。従って、それは、セクターマップを含むか、基本的にそれから成るか、またはそれから成り得る。
【００８９】
事実上、好ましくは、メディエータは、バッファユニットデータが格納されているディスクまたは記録媒体上に置かれていない。加えて、好ましくは、メディエータは、対応するディスクまたは記録媒体の総メモリの約０．１〜０．２％のみを必要とする。
【００９０】
さらに詳細な説明のために、図が参照され得る。図１は、本発明の方法の表現であり、そのための命令が、持続性記録媒体内の永続記憶装置内に格納され得る。例示を目的として、図１に示す方法のステップ１３０から終わりまでが、単一のユーザー提供バッファユニットに対して示されているが、本方法は、複数のユーザー提供バッファユニットにフラグメント化されている所与のバッファに対して、複数回、繰り返され得る。ユーザーが認識するＬＢＡと本当のＬＢＡとの関連付けがメディエータに書き込まれるとき、それらの関連付けは、一緒にグループ化されて、特定のファイルに対応するとして示される。当業者であれば認識するように、ユーザー提供のバッファがユーザー提供のバッファユニットと同じサイズである場合、それはフラグメント化する必要がなく、本発明の様々な実施形態は、この条件をチェックするように構成できる。本発明の様々な実施形態は、全てのバッファが等しいサイズのバッファユニットに分割され、そうでない場合は、それら全てを同じサイズにするために、バッファまたは最後のバッファユニットであろうもののビット列の端部に０を追加することが可能であることを確実にするようにも構成され得る。
【００９１】
図に示すように、情報を記憶媒体に書き込むための命令が、受信され得る。これらの命令は、ユーザーが認識する論理ブロックアドレス（ＬＢＡ）または（ＬＢＡｘ）およびユーザー提供のバッファユニットの形であり得る（１１０）。
【００９２】
前述のように、ユーザーが認識するＬＢＡは、ユーザーが、彼または彼女のデータが格納されると信じる位置である。ユーザー提供のバッファユニット内のデータは、通常、それが格納される装置上のブロックのサイズになる。ユーザーが、装置上のブロックサイズよりも大きいデータを投入する場合、ユーザーが投入するデータは、各々がブロックのサイズの、複数のバッファユニットを含むように、前処理され得る。バッファユニットがブロックサイズよりも小さい場合には、ブロックのサイズになるまで、コンピュータプログラム製品が、バッファユニットの一方の端部に全て０を追加し得る。
【００９３】
受信された命令は、従って、（ＬＢＡ，バッファ）によって表され得る形式であるか、またはその形式に変換される。ユーザー提供のバッファユニットに対して、コンピュータプログラム製品は、受信された際にデータをフラグメント化し、必要であれば、ハッシュ値を計算する（１２０）。複数の命令が受信される場合、各バッファユニットに対してハッシュ値が計算される。
【００９４】
アルゴリズムがハッシュ値を生成した後、アルゴリズムは、そのハッシュ値が、ハッシュ値テーブル内に既に存在する格納されたハッシュ値と重複しているかを問い合わせる（１３０）。テーブルがその生成されたハッシュ値を含んでいない場合、アルゴリズムは、バッファユニットがＮＣＭに対して新しいものであると結論付けて、そのバッファユニットを、以前に使用されていないＮＣＭ内のブロックに書き込む（１４０）。アルゴリズムはまた、ＮＣＭに新しく書き込まれた、このユーザー生成のバッファユニットと、その生成されたハッシュ値との関連付けを含むように、メモリ内に格納されているハッシュ値テーブルを更新する（１５０）。この生成されたハッシュ値は格納されたハッシュ値になり、ユーザー提供のバッファユニットは格納されたバッファユニットになる。いくつかの実施形態では、ハッシュ値テーブルは、バッファユニットがＮＣＭ上に格納されている本当の論理ブロックアドレスも識別するが、他方、他の実施形態では、ハッシュ値テーブルはこの情報を除外して、例えば、メディエータ上または別のデータファイル内など、他の場所に格納される。
【００９５】
ハッシュ値テーブルが更新された後、ユーザーが認識するＬＢＡおよびユーザー提供のバッファユニットが格納されている本当のＬＢＡがメディエータ上に格納されて、互いに関連づけられる（１６０）。
【００９６】
図１内のステップ１３０に戻り、問合わせが、新しく計算されたハッシュ値が、ハッシュ値テーブル内の格納されたハッシュ値と重複しているという結論となる場合、方法は、矛盾があるかどうかを尋ねるプロトコルを開始する（１７０）。
【００９７】
矛盾がない場合、プロトコルは、既にＮＣＭ上にあり、ユーザー提供のバッファユニットと同じ、バッファユニットデータの位置と、ユーザーが認識する位置との相関関係を、メディエータに格納させる（１６０）。従って、この重複したデータに対して、新しい情報はＮＣＭに書き込まれない。
【００９８】
矛盾があるかどうかに関する問合わせ（１７０）に戻り、応答が、同じハッシュ値が異なるバッファユニットに割り当てられていることを意味する、ｙｅｓの場合、プロトコルは、ユーザー提供のバッファユニットのＮＣＭへの書込み（１４０）およびメモリ内のハッシュ値テーブルを、新しく書き込まれたバッファユニットとアクティブに関連付けられているハッシュ値に更新することを要求する。加えて、メディエータが、ユーザーが認識する位置（複数可）と本当の位置（複数可）との新しい相関関係を含むように更新される。
【００９９】
図２は、このステップをさらに説明する。図１と同様に、矛盾判断プロトコル（２７０）に入ると、ｙｅｓ出力がある場合、バッファユニットの一意のデータがＮＣＭ上の新しいブロックに書き込まれる（２４０）。新しいブロックの書込みに続いて、アルゴリズムはハッシュ値テーブルを更新する。
【０１００】
ハッシュ値テーブルを更新する場合、本方法は、以前に格納されたハッシュ値のバッファユニットとの関連付けを解除して、その格納されたハッシュ値をより最近受信されたバッファユニットと関連付けて（２５１）、ハッシュ値と以前に格納されたバッファユニットとの関連付けを除去するか、または非アクティブにする（２５６）。ハッシュ値テーブルが更新された後、プロトコルは、最後に受信されたバッファユニットの本当の論理ブロックアドレスをメディエータに書き込んで、それをユーザーが認識する論理ブロックアドレスと関連付ける（２６０）。
【０１０１】
図３は、読取り命令を表す。システムは、ブロックを読み取る、すなわち、（ＬＢＡ，バッファ）の情報を取得するための命令を受信し得る（３１０）。要求は、１つ以上のユーザーが認識するＬＢＡとのユーザーのシステムの関連付けである、ファイル名による、ファイルに対する要求の形で到着し得る。
【０１０２】
プロトコルは、メディエータ内の相関関係テーブルのアクセスおよび、バッファまたはその一部に対応する各ＬＢＡ位置での読取りを引き起こす（３２０）。相関関係テーブルは、ユーザーが認識するＬＢＡを本当のＬＢＡと相互に関連付けるので、ＬＢＡ（または複数のＬＢＡ）に対する情報が取得された後、プロトコルは、指定された実際のＬＢＡまたは複数のＬＢＡでＮＣＭを読み取り、ブロック情報を取得して、バッファパラメータを満たす（３３０）。この情報を用いて、システムは、生データを正しい順序で有し、それを、ホストのオペレーティングシステムを通して要求されたファイルの再構成のために、ホストに送信することが可能である。
【０１０３】
とりわけ、読取りステップ中に、ハッシュ値アルゴリズムまたはテーブルにアクセスする必要がない。代わりに、ＮＣＭ上に格納されたとおりのＬＢＡが、ユーザーが必要とするバッファユニットを取得するために読み取られ得る。いずれか１つ以上のバッファユニットが、読取り時に、Ｌ１またはＬ２キャッシュのいずれか内にまだある場合、それらは、ＮＣＭからではなく、適切なキャッシュから読み取られ得る。
【０１０４】
さらなる例として、以下の表が検討され得る。
【表１】
0006345698.tif 000002
【０１０５】
ユーザーが格納のためにデータを投入すると、ユーザーは、バッファユニットのサイズが各々、例えば、５１２バイトである、１８のブロックに対して、ＬＢＡが１〜１８であると認識する。格納のためにデータを伝送する場合、ユーザーは、各バッファユニットを、異なるブロックに格納されていると仮定して、一意として処理する。
【０１０６】
ハッシュ値アルゴリズムを適用すると、２〜３の重複したハッシュ値が生成される。見て分かるとおり、ハッシュ値ｘがバッファユニットＡ、Ｇ、ＬおよびＲに適用され；ハッシュ値ｙがバッファユニットＢ、Ｊ、およびＱに適用され；ハッシュ値ｚがバッファユニットＣおよびＰに適用され；ハッシュ値ｂがバッファユニットＥおよびＯに適用される。しかし、データの本当の重複は、ＡとＲ、ＧとＬ、ＢとＪ、ＥとＯ、およびＣとＰとの間に見つけられる。それ故、矛盾は、ＡとＧ；ＧとＲ；ＢとＱ；およびＱとＪとの間に生じる。
【０１０７】
４列目に示すように、データを書き込む際に、本当の重複に対して、新しいブロックは書き込まれない。例えば、ユーザーが認識するＬＢＡ  ２および１０が格納されている実際の位置を参照されたい。両方がブロック１１０に格納されている。３列目および４列目を検討すると、最初の７つのユーザー提供のバッファユニットが分析された後に、最初の重複したハッシュ値が生成された（ｘ値）ことが分かる。しかし、Ａ≠Ｇなので、ＧはＮＣＭ上のブロックに書き込まれる必要がある。これが生じた後、さらなる矛盾分析のために、メモリ内に格納されているハッシュ値テーブル内で、ｘが、Ａではなく、Ｇと関連付けられる。
【０１０８】
１０番目のバッファユニットＪが分析された後に、重複したハッシュ値ｙが生成されていることが分かる。しかし、バッファユニットが同じであるので、矛盾はない。従って、ハッシュ値テーブルに対する更新は必要なく、新しいブロックがＮＣＭに書き込まれる必要がない。代わりに、メディエータが、本当のＬＢＡ１１０を指して、それをユーザーが認識するＬＢＡと相互に関連付けるように更新される。１２番目のユーザーが認識するＬＢＡが分析された後、類似した本当の重複が明らかになり、１５番目および１６番目が分析される。
【０１０９】
バッファユニットＱが分析された後、ハッシュ値ｙが生成
される。しかし、Ｑ≠Ｂであるので、矛盾がある。その結果として、新しいブロックがＬＢＡ  １２１に書き込まれ、ハッシュ値テーブルが、ｙをＱと関連付けるように更新されて、もはやｙを（Ｊと同じである）Ｂと関連付けない。
【０１１０】
ユーザー提供のバッファユニットＲが分析された後、ハッシュ値ｘが生成される。Ｒ＝Ａである。しかし、Ａは、ハッシュ値テーブル内でｘとの最新の関連付けではない。その結果として、プロトコルは、Ｒを、それがＲを見たのが初めてであるかのように扱い、（１）新しい相関関係をハッシュ値テーブル内に保存するか、または古いものを上書きすること（しかし、それは、メモリ内に格納された関連付けを回復しない）、および（２）新しいブロックのデータをＮＣＭ内に格納する（ここではブロック１２２）こと：の両方を行う必要がある。このように、本例では、ＮＣＭは、いくつかの重複を含むであろう。
【０１１１】
表１は、例示目的であり、いくつかの実施形態では、第１および第４の列のみがメディエータの一部であり、それらは、ハッシュ値テーブルの一部ではない。メディエータのサイズ要件は小さい。例えば、いくつかの実施形態では、メディエータは、５１２バイトまたは４ＫのサイズのＮＣＭ上に格納されている各バッファユニットに対して、８または１６バイトを必要とする。
【０１１２】
本発明の様々な実施形態を通して、ＮＣＭの物理記憶空間が大いに削減できる。例えば、それらは、少なくとも５０％、少なくとも１００％、少なくとも２００％、少なくとも５００％、または少なくとも１０００％だけ削減できる。従って、いくつかの実施形態では、必要な記憶容量は、標準状態下で必要であるよりも５０〜１５０分の１である。例えば、５１２バイト〜４Ｋのバッファユニットに相当するものの、メディエータ上での記憶のために、５〜１０バイトしか必要ないであろう。このように、同じバッファユニット（またはフラグメント化されたバッファユニット）を複数回、格納する必要を削減することにより、（本発明のＮＣＭの一例である）８ＧＢのＵＳＢスティックが、１．５３ＴＢのデータに相当するものを格納するために使用できる。
【０１１３】
本発明の方法、システムおよびコンピュータプログラム製品は、格納されているバッファユニットが、たとえフラグメント化されていても、ユーザーから受信されたものと同じであると仮定して、説明されてきた。これらの実施形態では、それらは、ユーザーが認識するものとは異なるＬＢＡに、ユーザーが認識できない順序で格納されるので、情報を取得するためにメディエータが必要であり、ユーザーはそれなしでは、データを取得できない。それ故、それは、ある程度のセキュリティを提供する。
【０１１４】
同じハッシュ値アルゴリズムを利用する異なるユーザーが、同じハッシュ値を生成するであろう。従って、それらのハッシュ値テーブルは、ＮＣＭ上のバッファユニットの位置を除いて、同様であろう。加えて、メディエータ内の相関関係情報が異なる。追加レベルのセキュリティとして、本発明の方法に入る前に、ユーザーは、データをコード化または変換することを望み得る。これらの動作は、前処理と呼ばれ得る。
【０１１５】
いくつかの実施形態では、前述のプロトコルまたはシステムに入る前に、ユーザーのデータがまず、ビットマーカーテーブルもしくは頻度変換器またはサイズが小さく、かつ／もしくは符号化されているデータを生成するための他のハッシュ値アルゴリズムの使用を通して、変換される。これらの技術を実施するための方法、システムおよびコンピュータプログラム製品は、２０１３年2月２日に出願された「Ｂｉｔ  Ｍａｒｋｅｒｓ  ａｎｄ  Ｆｒｅｑｕｅｎｃｙ  Ｃｏｎｖｅｒｔｅｒｓ」という名称の米国１３／７５６，９２１号；２０１３年３月１２日に出願された「Ｄａｔａ  Ｓｔｏｒａｇｅ  ａｎｄ  Ｒｅｔｒｉｅｖａｌ  Ｍｅｄｉａｔｉｏｎ  Ｓｙｓｔｅｍｓ  ａｎｄ  Ｍｅｔｈｏｄｓ  ｆｏｒ  Ｕｓｉｎｇ  Ｓａｍｅ」という名称の米国１３／７９７，００３号；および２０１３年６月３日に出願された「Ｍｅｔｈｏｄｓ  ａｎｄ  Ｓｙｓｔｅｍｓ  ｆｏｒ  Ｓｔｏｒｉｎｇ  ａｎｄ  Ｒｅｔｒｉｅｖｉｎｇ  Ｄａｔａ」という名称の米国１３／９０８，２３９号に開示されている。前述した出願の開示全体が、参照により、全体として組み込まれる。これらの方法の出力が、重複削減のためのバッファユニットを生成するために使用され得る。
【０１１６】
これらの出願は、本発明に、前処理ステップとして、すなわち、本実施形態の重複排除方策の前に、組み込まれ得る、方法を記述する。これらの場合、バッファユニットは、データが、ビットマーカーテーブルまたは頻度変換器の使用を通して変換される前処理方法の出力に対応し得る。
【０１１７】
従って、一実施形態では、この前処理ステップは：（ｉ）複数のデジタル２値信号を受信することであって、デジタル２値信号が複数のチャンクレットに編成されており、各チャンクレットがＮビット長で、Ｎが１より大きい整数であり、チャンクレットが順序を有する、複数のデジタル２値信号を受信すること；（ｉｉ）各チャンクレットを均一なサイズのサブユニットに分割して、Ｘ個のマーカーのセットから、１つのマーカーを各サブユニットに割り当てて、複数のマーカーのセットを形成することであって、Ｘがサブユニット内のビットの異なる組合せの数以下であり、同一のサブユニットが同じマーカーに割り当てられて、少なくとも１つのマーカーがサブユニットのサイズよりも小さい、複数のマーカーのセットを形成すること；および（ｉｉｉ）マーカーをバッファユニットとして使用すること；を含む。この前処理ステップは、ハッシュ値テーブルと同じか、または異なる永続的メモリ内に格納され得るビットマーカーテーブルを利用する。データを読み取る際に、これらの前処理ステップが逆の順番で実施され得、データがＮＣＭから取得された後に、ＮＣＭ上のバッファユニットが、メディエータによって指示された方法で再結合される。マーカーをバッファユニットとして使用する場合、必要なサイズのバッファユニットを形成するために、マーカーを結合または分割し得る。
【０１１８】
ビットマーカーテーブルは、全てが同じサイズであるか、または異なるサイズのマーカーを含み得る。異なるサイズの場合、サイズは、以下で説明するように、ビットまたはバイトの列の予測された頻度によって判断され得る。
【０１１９】
さらなる例として、前処理ステップがビットマーカーテーブルを利用する場合、生データが、その生データを表す一連のマーカーに翻訳される。生データは、ホストから受信されたデータに対応し、従って、例えば、ＪＰＥＧ、ＰＤＦ、ＴＩＦＦまたはＷＯＲＤ文書などの、１つ以上のファイルを個々に、または全体として形成する１つ以上のチャンクレットであり得る。
【０１２０】
チャンクレットは順番に受信される。例えば、ファイルが、システムによって連続的に受信される１０のチャンクレットを含み得る。あるいは、所与のファイルに対する複数のチャンクレットが、それらが、ホストのオペレーティングシステムによるファイルの再作成および使用を可能にするような方法で、それらの相互の再関連付けを可能にする情報を含む場合、並行して、または一緒に伝送され得る。従って、いくつかの実施形態では、本発明の方法は、マーカーを、チャンクレットが受信されるのと同じ順序で生成する。それに応じて、ホストがファイルの取得を要求する場合、対応する取得手段が、符号化されたデータを同じ順序で呼び戻して、それを適切な順序でチャンクレットに復号するであろう。
【０１２１】
任意選択で、符号化の前に、システムは、チャンクレットをビットのグループ（サブユニットとも呼ばれる）に分割し得、その各々はＡビット長である。システムがチャンクレットをサブユニットに分割する場合、サブユニットがビットマーカーテーブルと比較され得る。システムがチャンクレットをサブユニットに分割しない場合、各チャンクレットがビットマーカーテーブルと比較され得る。
【０１２２】
ビットマーカーテーブルは、ビットの一意のセットを一意のマーカーと相互に関連付ける。いくつかの実施形態では、ビットマーカーテーブルは、サブユニットが使用される場合にはサイズＡ、またはサブユニットが使用されない場合にはサイズＮの、各一意のビット列に対するマーカーを含む。それ故、この方法では、コンピュータプログラムは、チャンクレットのセットを入力として受信し得る。それは、次いで、各チャンクレットを、同じサイズで、各々Ａビット長のＹ個のサブユニットに分割し得、Ａ／８は整数である。各一意のＡに対して、テーブル内に１つのマーカーがあり得る。
【０１２３】
このように、自動化プロトコルを通して、チャンクレットの受信後、コンピュータプログラム製品は、ビットマーカーテーブルをアクセスさせる。それに応じて、各チャンクレットまたはサブユニットは、入力として機能し得、各ビットマーカーは、出力として機能し得、それによりマーカーの出力セットを形成する。マーカーの出力セットは、翻訳されたか、コード化されたか、または符号化されたデータと呼ばれ得る。各チャンクレットが細分されない実施形態では、各チャンクレットは１つのマーカーを受信するであろう。チャンクレットが２つのサブユニットに分割される場合、それは、２つのマーカーに翻訳されるか、または符号化されるであろう。従って、コンピュータプログラム製品は、各チャンクレットに対応する少なくとも１つのマーカーを割り当てるために、マーカーを入力と相互に関連付けるビットマーカーテーブルを使用する。コンピュータプログラム製品は、各個々のマーカーに対応する異なる出力が生成されるように、各チャンクレットに対応するマーカーのセットを含む異なる出力が生成されるように、または、完全なファイルに対応するマーカーのセットを含む異なる出力が生成されるように、設計され得る。
【０１２４】
前述のように、ビットマーカーテーブルは、Ｘ個のマーカーを含む。いくつかの実施形態では、Ｘは、本方法がチャンクレットをサブユニットに分割しない場合には、長さＮのチャンクレット内のビットの異なる組合せの数、または本方法がチャンクレットを分割する場合には、長さＡのサブユニット内のビットの異なる組合せの数のいずれかに等しい。文書タイプが分かっているか、または所与の長さのサブユニットもしくはチャンクレットに対するビットの全ての組合せよりも少ないと予測される場合、Ｘ（マーカーの数）は、ビットの考えられる組合せの実数よりも小さい可能性がある。例えば、いくつかの実施形態では、全てのビットマーカーが同じサイズであり、ビットマーカーテーブル内のビットマーカーの数が、サイズＮまたはＡのビット列内のビットの組合せの数に等しい。他の実施形態では、全てのビットマーカーが同じサイズであり、ビットマーカーテーブル内のビットマーカーの数が、サイズＮまたはＡのビット列内のビットの組合せの数の、９０％未満、８０％未満、７０％未満、もしくは６０％未満である。
【０１２５】
例として、いくつかの実施形態では、各チャンクレットは、複数の０および／または１から成るコード（すなわち、マーカー）を割り当てられる。他の実施形態では、各チャンクレットは、各々が、複数の０および１から成るコード（すなわち、マーカー）を割り当てられている複数のサブユニットに分割される。サブユニットは、長さＡによって定義され得、Ｎ／Ａ＝Ｙで、Ｙは整数である。サブユニットがその数のビットを有していない場合、例えば、１つ以上のサブユニットが、システムが入力として受信するように構成されているビット数よりも少ないビット数しか持たない場合、システムはビット、例えば、ゼロを、全てのサブユニットが同じサイズになるまで、追加し得る。このステップは、例えば、チャンクレットがサブユニットに分割された後、全てのチャンクレットが同じサイズであるかどうかをまず確かめない場合に、実行され得る。あるいは、前述のように、それは、チャンクレットをサブユニットに分割する前に、チャンクレットレベルで実行され得る。
【０１２６】
上の説明で示唆するように、アルゴリズムは、ビット列をコード化されたデータのセットに翻訳するように構成され得、アルゴリズムは、ビット列が、チャンクレットまたは、チャンクレットのサブユニットのいずれかに対応するように、設計され得る。好ましくは、コード化されたデータのセットは、ホストまたはクライアントから受信される際のファイルよりも小さい。しかし、コード化されたデータのセットが元のデータよりも小さいかどうかに関わらず、それは、変換してファイルのチャンクレットに戻すことが可能である。当業者であれば認識するように、格納のためにホストから受信されるデータは、生データであり、従って、任意の文書タイプに対応できる。マーカーの出力は、前述のようなハッシュ値アルゴリズムへの入力のためのユーザー提供バッファユニットを形成するために、それらが結合されるのを可能にする順序であり得る。
【０１２７】
符号化は、２つの独立した目的に役だち得る。第１に、格納のためにデータを符号化することにより、セキュリティが向上する。コードを知っている（すなわち、ビットマーカーテーブルにアクセスできる）人またはエンティティだけが、それを復号して文書を再構築することができる。第２に、コードが元の文書よりも少ないビットを使用して作成される場合、必要な記憶空間が少なくなって、費用を節約できる。
【０１２８】
テーブル内のビットの少なくとも複数の一意の組合せに対して、好ましくは、システムがチャンクレットをサブユニットに分割しない場合、マーカーは、チャンクレット長Ｎよりも小さいか、またはシステムがチャンクレットをサブユニットに分割する場合には、サブユニット長Ａよりも小さい。好ましくは、システムがチャンクレットをサブユニットに分割しない場合、どのマーカーもチャンクレット長Ｎよりも大きくないか、またはシステムがチャンクレットをサブユニットに分割する場合、どのマーカーもサブユニット長Ａよりも大きくない。いくつかの実施形態では、全てのマーカーは、Ｎよりも小さいか、またはＡよりも小さい。加えて、いくつかの実施形態では、各マーカーは、同じサイズであり得るか、または２つ以上のマーカーが異なるサイズであり得る。
【０１２９】
前述のように、ビットマーカーテーブルは、マーカーをビット列に、生データに対してランダムまたは非ランダムに割り当て得、ビットマーカーは、均一または不均一なサイズであり得る。しかし、前述のようなビットマーカーテーブルの代わりに、頻度変換器を使用し得る。従って、ある文書タイプまたは文書のセット内により頻繁に出現すると見込まれる生データに対して、より小さいマーカーを割り当て得る。この方策は、全ての情報のほぼ８０％が、最も頻出するサブユニットのほぼ上位２０％内に含まれるという事実を利用する。言い換えれば、データに対応するサブユニットは、非常に繰返しが多い。
【０１３０】
いくつかの実施形態では、異なるサイズの複数の変換されたビット列の全てに対して、Ａビット長の第１の変換されたビット列、およびＢビット長の第２の変換されたビット列があり、ここで、Ａ＜Ｂであって、第１の変換されたビット列のＡビットの識別が、第２の変換されたビット列の最初のＡビットの識別と同じでない。ビットマーカーテーブルまたは頻度変換器のいずれかから、マーカーを使用するとき、それらが異なるサイズである場合、それらは、どこで１つのマーカーが終わって、次が始まるかをシステムが知ることができるフォーマットにされる必要がある。これは、例えば、最小限のマーカーサイズを設定し、最小限のサイズの各ビット列がテーブルまたは変換器内で一意であるかどうかを問い合わせ、そうでない場合は、追加のビット（複数可）を読み取って、各追加のビットに対する問合わせを繰り返すことにより、ビット列を拡大し続ける、読取り分析を通して達成され得る。
【０１３１】
情報が変換され得、出力コードは、ビットのグループを表すためにマーカーが使用されるので、入力よりも小さくなるように構成できる。従って、好ましくは、テーブル内で、少なくとも１つの、複数の、少なくとも５０％の、少なくとも６０％の、少なくとも７０％の、少なくとも８０％の、少なくとも９０％の、または少なくとも９５％の、マーカーが、サブユニットよりもサイズが小さい。しかし、変換されたデータを同じサイズにするか、またはホストから受信したか、もしくはハッシュ関数値アルゴリズムから生成したデータよりも長くするのを妨げる技術的障害はない。
【０１３２】
別の実施形態によれば、前処理ステップは、（ｉ）ＮバイトのＩ／Ｏストリームを（例えば、Ｉ／Ｏプロトコルを使用して）受信すること；（ｉｉ）Ｎバイトを、Ｘバイトのフラグメント化ユニットにフラグメント化すること；（ｉｉｉ）暗号化ハッシュ関数（値アルゴリズム）をＸバイトの各フラグメント化ユニットに適用して、Ｘバイトの各フラグメント化ユニットに対して生成されたハッシュ関数値を形成すること；（ｉｖ）相関ファイルにアクセスすることであって、相関ファイルが、Ｙビットの格納されたハッシュ関数値を、複数の格納されたＸバイトのシーケンスの各々と関連付けて、（ａ）Ｘバイトのフラグメント化ユニットに対して生成されたハッシュ関数値が相関ファイル内にある場合は、Ｙビットの格納されたハッシュ関数値をユーザー提供のバッファユニットとして使用し；（ｂ）Ｘバイトのフラグメント化ユニットに対して生成されたハッシュ関数値が相関ファイル内にない場合は、Ｙビットの生成されたハッシュ関数値をＸバイトのフラグメント化ユニットとともに相関ファイル内に格納し、生成されたハッシュ関数値をユーザー提供のバッファユニットとして使用する、相関ファイルにアクセスすること：を含む。
【０１３３】
この前処理ハッシュ値アルゴリズムを使用する場合には、それらが矛盾している可能性に対処する必要がある。最新のハッシュ値関連付けが保持されて格納される、重複排除のための前述した方法に対する代替として、この任意選択の前処理ステップ中に、相関ファイル内の格納されたハッシュ関数値と同じであるが、ユーザー提供のチャンクレットが格納されたチャンクレットと異なる、ハッシュ関数値が生成される場合に、方法が、異なるＺビットを格納されたハッシュ関数値および生成されたハッシュ関数値と関連付けさせる、矛盾解決モジュールを使用し得る。この技術は、２０１３年６月３日に出願された、米国特許出願第１３／９０８，２３９号に記述されており、その開示全体が参照により組み込まれる。
【０１３４】
このように、この前処理ステップは、第１のハッシュ値テーブルを利用し得、矛盾が存在しない全てのハッシュ関数値に対して、Ｚビットが関連付けられ、Ｚビットは、例えば、８〜１６個のゼロの均一の長さである。限定されない例として、本方法は、チェックサムが、以前に格納されたチェックサムと矛盾しない場合、８バイトのチェックサムの端部に８個のゼロを結合させ得る。矛盾を識別した際には（例えば、異なるフラグメント化ユニットが同じチェックサムと関連付けられている）、最新のチェックサムが異なるＺ値を割り当てられ得る。従って、相関ファイル内に格納された際のＺ値が００００００００の場合、第１の矛盾しているチェックサムに対するＺ値は、０００００００１であり得、別の矛盾しているチェックサムがあるとすれば、００００００１０である。さらに矛盾しているチェックサムがある場合、矛盾しているチェックサムが識別されると、各矛盾しているチェックサムは次のＺ値を割り当てられ得る。従って、相関ファイルがアクセスされた後、新しく生成されたハッシュ値が既に相関ファイル内にある場合に限り、矛盾モジュールがチェックとしてアクセスされ得る。矛盾モジュールは次いで、矛盾があるか、またはチェックサムおよび受信したファイルからのフラグメント化ユニットの両方が、既に相関ファイル内で互いに関連付けられているかを判断するであろう。これらの拡張ファイルは、格納されたハッシュ値の格納されたバッファユニットとの関連付けの置換え、または上書きに対する代替手段である。これらの拡張をもつチェックサムは、入力をユーザー提供のバッファユニットとして形成するために必要なサイズに結合され得る。
【０１３５】
前処理ステップがハッシュ値アルゴリズムを使用する任意の場合に、適用される第１のハッシュ値アルゴリズムが、第１のハッシュ値アルゴリズムまたは第１のハッシュ値テーブルを利用する前処理ハッシュ値アルゴリズムと呼ばれ得、第２のハッシュ値アルゴリズムが、重複排除ハッシュ値アルゴリズムまたは第２のハッシュ値テーブルを利用する第２のハッシュ値アルゴリズムと呼ばれ得る。前処理ハッシュ値アルゴリズムおよび第２のハッシュ値アルゴリズムの両方が使用される場合には、前述のように、好ましくは、重複排除ハッシュ値アルゴリズムの使用時に矛盾に対処するために、対応するハッシュ値テーブルが、最新の関連付けを好んで選択することにより、矛盾している関連付けの間で解決し、他方、前処理ハッシュ値アルゴリズムの使用時に矛盾に対処するために、対応するハッシュ値テーブルが、前述のような拡張方法を使用する。
【０１３６】
前処理技術を使用する場合、出力、例えば、ビットマーカーは、バッファユニットと同じサイズであり得る。いくつかの実施形態では、ビットマーカーは、バッファユニットのサイズよりも大きい可能性がある。これらの場合、システムは、それらをフラグメント化して、バッファユニットを形成し得るか、または、コード化するデータよりも大きい、いずれのビットマーカーも拒絶して、代わりに、元の生データを使用してバッファユニットを形成し、それにより、ビットマーカーテーブルへのアクセスを迂回する、デフォルトモジュールを含み得る。他の実施形態では、それらは、小さい可能性があり、結合してバッファユニットを形成するか、またはバッファユニットにフラグメント化されるバッファを形成する必要がある。これらのステップは、コンピュータプログラム製品内のモジュールに従い、サーバー上で、クラウド内で、またはＣＰＵによって実施され得る。
【０１３７】
データの前処理が書込みプロセスの一部である場合、データの後処理が読取りプロセスの一部でなければならない。本発明の重複排除ステップの読取りとは異なり、後処理ステップは、前処理ステップと対称的であるが、逆の順番で実施される。
【０１３８】
さらに、本発明の様々な実施形態が、データの損失を防ぐための他の方法と組み合わせて使用され得る。ある実施形態では、データのバックアップを容易にするために２つのメディエータを使用し得る。例えば、第１のメディエータでは、第１の記録媒体上に格納されるデータファイルをファイル名と相互に関連付け得る。前述のように、第１のメディエータは、ファイル名を識別するユーザーまたはエンティティがデータファイルを記録媒体から取得するのを可能にするように構成される。
【０１３９】
第２のメディエータを生成する、データ保護プロトコルが実行され得る。第２のメディエータは、時間Ｔ１における第１のメディエータの正確なコピーであろう。従って、Ｔ１において、第１のメディエータおよび第２のメディエータの両方は、第１の記録媒体上の同じＬＢＡを指す。
【０１４０】
時間Ｔ１の後、例えばＴ２において、ホストは、例えば、所与のセクターまたはセクタークラスタ上の、所与の位置内に格納されていると信じるファイルを更新しようとし得る。ホストは、第１の記憶アドレス（複数可）に格納されたデータを変更しない。ＮＣＭ上の情報を上書きさせるのではなく、第１のメディエータは、更新されたファイルであるとホストが信じるものに対応する新しい相関関係エントリを生成し得る。ＮＣＭ上に書き込まれるバッファユニットの全部ではないにしろ、ほとんどが一意のエントリであるので、メディエータ上の新しい相関関係は、元の相関関係におけるものとは異なるバッファユニットに対してのみ、元の相関関係と異なるであろう。従って、Ｔ０においてファイル（Ａ）に対し、第１のメディエータは、次の本当のＬＢＡ：２００、２０１、２０２、２０３、２０４、２０５、２０６を相互に関連付け得る。Ｔ１において、メディエータのコピーが作成され得る。Ｔ２において、ユーザーは、ファイル（Ａ）を更新しようとし得る。第１のメディエータ上で、次の本当のＬＢＡ：２００、２０１、３１０、２０３、２０４、２０５、２０６を指す、新しい相関関係が保存され得る。しかし、第２のメディエータは変更されないであろう。従って、それらは、それらがどこを指すかが、異なるであろう。以前に保存された相関関係は、第１のメディエータ上で非アクティブにされるか、または削除されるか、または上書きされ得る。
【０１４１】
２つのメディエータのこの使用は、ファイルが、Ｔ１およびＴ２の両方において存在していたとおりに格納されていることを示すように、ホストに、そのファイルシステムを更新させる必要なく、データがＴ１において存在するとおりにそのデータのスナップショットを提供するのを可能にする。従って、スナップショットは、時間Ｔ１において格納されている全てのデータファイルをロックして、いずれも、それらの物理ファイルを通して削除または書込みが行われるのを防ぐ。しかし、ホストがそれらのファイルを修正したい場合、実際にはファイルの新しい部分のみが格納されて、新しいメディエータエントリが作成されるときに、ホストは、それを行っていると思い込んで動作できる。
【０１４２】
上で示唆するように、この方法は、第１のメディエータ、第２のメディエータおよび非キャッシュ媒体を含むシステムによって実装され得る。第１のメディエータ、第２のメディエータおよび記録媒体の各々は、持続性媒体を含むか、基本的にそれから成るか、またはそれから成り得る、別個の装置上に格納され得るか、または別個の装置から形成され得る。加えて、システム内で、メディエータおよび記録媒体は、互いに、ならびに任意選択で、命令を格納する１つ以上のコンピュータまたはＣＰＵに、動作可能に結合されて、それらに、それらの意図する機能を実行させ、ネットワークを経由して、１つ以上のホストへ１つ以上のポータルを通して通信させる。さらになお、この実施形態は２つのメディエータの使用と関連して説明されているが、２つの別個のメディエータではなく、同じメディエータの２つのセクションを使用するシステムを実装できる。
【０１４３】
データをバックアップするための前述のシステムが、２つのメディエータのコンテキストで説明される。しかし、格納されたファイルの履歴またはファイルのバージョンを捕捉するために３つ以上のメディエータが使用できる。例えば、少なくとも３つ、少なくとも４つ、少なくとも５つ、または少なくとも１０のメディエータなど、が使用され得る。追加として、ホストは、メディエータに、一定の間隔で（例えば、毎週、毎月、３か月ごともしくは毎年）または不規則な間隔で（例えば、要求に応じて）、スナップショットを取らせ得る。
【０１４４】
データをバックアップするための別の方法によれば、非キャッシュ媒体のクローンが作成され得る。この方法では、第１のメディエータ内で、複数のファイル名を、非キャッシュ記憶媒体上に格納されている複数のデータ位置と相互に関連付ける。第１のメディエータは、特定のファイル名を識別するユーザーが、特定のファイル名に対応する第１の非キャッシュ記憶媒体からデータファイルを取得するのを可能にするように構成されている。特定ファイルの一部または全体が、第１のセクターまたはセクタークラスタ内に格納され得る。
【０１４５】
複数のデータファイル（または第１の非キャッシュ記憶媒体の全てのデータファイル）のコピーを第２の非キャッシュ記憶媒体および第２のメディエータに対して作成し得る。第２のメディエータは、時間Ｔ１における第１のメディエータのコピーであり、第２の非キャッシュ記憶媒体に動作可能に結合されている。Ｔ１の後である、時間Ｔ２において、ユーザーは、システムに、第１の非キャッシュ記憶媒体上の前記第１のセクターまたはセクタークラスタ内に格納されているデータファイルに対する修正を保存するように指示し得る。新しいバッファユニット（またはハッシュ値とアクティブに関連付けられていないバッファユニット）のみが第１の非キャッシュ記憶媒体に追加され得、第１の非キャッシュ記憶媒体上のデータの上書きはないであろう。代わりに、新しい相関関係が第１のメディエータ上に書き込まれ得る。第２のメディエータまたは第２の非キャッシュ記憶媒体に対する変更は行われない。ユーザーがＴ２の後にファイルを要求すると、彼または彼女は、第１のメディエータを経由して、直前に格納されたファイルのバージョンを取得するであろう。しかし、システム管理者は、第２の非キャッシュ媒体上に格納されて、第２のメディエータを経由することにより取得し得た、前のバージョンにアクセスしていたであろう。
【０１４６】
この方法は、第１のメディエータ、第２のメディエータ、第１の非キャッシュ記憶媒体および第２の非キャッシュ記憶媒体を含む、システムによって実装され得る。第１のメディエータ、第２のメディエータならびにデータファイルを格納するための第１および第２の記録媒体の各々は、持続性媒体を含むか、基本的にそれから成るか、またはそれから成り得る、別個の装置上に格納され得る。いくつかの実施形態では、第１の非キャッシュ媒体内に格納されている、最新のファイルは、従来のファイルが第２の非キャッシュ媒体内に有するのと同じＬＵＮを有する。
【０１４７】
本明細書で説明する様々な実施形態の特徴のいずれも、特別の定めのない限り、開示する任意の他の実施形態に関連して説明する特徴と併用できる。従って、様々な、または特定の実施形態に関連して説明する特徴は、かかる排他性が明記されていないか、またはコンテキストから暗黙的でない限り、本明細書で説明する他の実施形態に関連して適切でないと解釈されるべきでない。
【図１】
0006345698.tif 000003
【図２】
0006345698.tif 000004
【図３】
0006345698.tif 000005