JP6045590B2

JP6045590B2 - 部分的重複排除ファイルの最適化

Info

Publication number: JP6045590B2
Application number: JP2014528459A
Authority: JP
Inventors: カラチ，ラン; ハサン，カシーフ; オルテアン，ポール・エイドリアン; ベントン，ジェームズ・ロバート; チャン，チュン・ホー; グプタ，アビシェーク
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2011-09-01
Filing date: 2012-08-23
Publication date: 2016-12-14
Anticipated expiration: 2032-08-23
Also published as: US8990171B2; EP2751693A4; KR20140068919A; CN102880663A; CN102880663B; KR101988683B1; US20130060739A1; WO2013032825A2; WO2013032825A3; JP2014525631A; EP2751693A2

Description

[0001] データーの重複排除(deduplication)（データー最適化と呼ばれることもある）とは、記憶システムにおいて冗長なデーターを検出し、一意に識別し、排除することによって、元のデーターの忠実度または完全性を阻害することなく、ディスク上に格納するまたはネットワークを通じて送信する必要があるデーターの物理的バイト量を削減することを言う。このように、データーを格納および／または送信するために必要とされるリソースを削減することによって、データー重複排除は、ハードウェアおよび電力コスト（格納のため）ならびにデーター管理コスト（例えば、バックアップ・コストを低減する）の節約に至る。ディジタル的に格納されるデーター量が増大するにしたがって、これらのコスト節約は重要になる。

[0002] データー重複排除は、通例、永続的に格納されるファイル内部およびこれらのファイル間における冗長性を排除する技法の組み合わせを用いる。このような技法の１つは、１つまたは多数のファイルにおいて同じデーター領域を識別し、１つの一意の領域（チャンク）だけを物理的に格納しつつ、このデーターの繰り返し出現全てについてファイルと関連付けてこのチャンクへの参照を維持するように動作する。他の技法では、例えば、圧縮したチャンクを格納することによって、データー重複排除を圧縮と混合する。

[0003] データー重複排除には、多くの困難、妥協(tradeoff)、および選択肢があり、環境によっては、利用可能な時間およびリソースを考えると、１回の動作では重複排除するデーターが多すぎる場合が含まれる。以前に重複排除されたファイルが、新たなデーターまたは既存データーの変更に応答して部分的にディスクにリコールされるというように、部分的に重複排除されたファイルに、特定的な課題がある。部分的に重複排除されたファイルを全体的に重複排除するには、ファイル全体を読み取ってチャンキングし(chunking)、チャンクをチャンク・ストアに書き込むために大量の入力／出力リソースが必要となり、更にはこのチャンキングおよび圧縮を実行するためのＣＰＵリソースも必要となる。

[0004] この摘要は、詳細な説明において以下で更に説明する概念から選択したものを、簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するように使用されることは全く意図していない。

[0005] 端的に言うと、本明細書において記載する主題の種々の態様は、１つ以上の重複排除部分を有するファイルを完全に重複排除したファイルに変換することによって、部分的に重複排除されたファイルを最適化することを目的とする。一態様では、重複排除メカニズムは、重複排除されていない部分に渡る(encompass)１つ以上のチャンクを識別し、これら１つ以上のチャンクに関連付けられたファイル・オフセット間に１つ以上の新たなチャンクを定義することによって、非重複排除部分(undeduplicated portion)に対して重複排除プロセスを実行する。１つ以上の新たなチャンクに関連付けられたチャンク境界は、ファイルのリコールされない重複排除部分のチャンクとは重複しない。リコールされない重複排除部分との整合(alignment)を維持することによって、１つ以上の新たなチャンクは、他のいずれのチャンクも変更することなく、チャンク・ストアにコミットする(commit)ことができる。他の態様では、ファイルに関連付けられた重複排除メタデーターが、チャンク境界および１つ以上の新たなチャンクに関連付けられた他の情報を含むように変更され、１つ以上のチャンクと関連付けられたメタデーターはいずれも置き換えることができる。

[0006] 他の態様では、重複排除プロセスを簡素化するために、ファイルをサブファイル・パーティションに区分することもできる。重複排除メカニズムは、各重複排除プロセスの間に一度に１つのサブファイル・パーティションをチャンクに纏め、コミットする。次いで、重複排除メカニズムは、次のサブファイル・パーティションを重複排除する前に、このサブファイル・パーティションをファイルから切り捨てる(truncate)。サブファイル・パーティションの重複排除を完了する前に重複排除プロセスが中断された場合、重複排除プロセスは、コミットされた最後のチャンクの後の位置で再開することができる。

[0007] 本発明は、添付図面において、一例としてそして限定ではなく、例示される。図面において、同様の参照番号は同様のエレメントを示す。

図１は、一実施態様例にしたがって、部分的に重複排除されたファイルを最適化するシステム例を示すブロック図である。図２は、一実施態様例による重複排除メカニズムのコンポーネント／フェーズ例を表すブロック図である。図３Ａは、一実施態様例にしたがって、完全重複排除ファイルに変換される、部分的リコール・ファイルの種々の例を示す。図３Ｂは、一実施態様例にしたがって、完全重複排除ファイルに変換される、部分的リコール・ファイルの種々の例を示す。図３Ｃは、一実施態様例にしたがって完全重複排除ファイルに変換される、部分的重複排除ファイルの一例を示す。図４Ａは、一実施態様例による重複排除メタデーターを示す。図４Ｂは、一実施態様例による重複排除メタデーターを示す。図５は、一実施態様例にしたがって、少なくとも１つの重複排除されていない部分を有するファイルを完全重複排除ファイルに変換するステップを示す流れ図である。図６は、一実施態様例にしたがって、サブファイル・パーティションに区分されたファイルを重複排除するステップを示す流れ図である。図７は、本明細書において説明する種々の実施形態を実現することができる、非限定的なネットワーク接続環境の一例を表すブロック図である。図８は、本明細書において説明する種々の実施形態の１つ以上の態様を実現することができる、非限定的な計算システムまたは動作環境の一例を表すブロック図である。

[0017] 本明細書において説明する技術の種々の態様は、一般に、１つ以上の重複排除されていない部分を有するファイルを完全重複排除ファイルに変換することによって、部分的に重複排除されたファイルを最適化することを目的とする。一実施態様例では、部分的に重複排除されたファイルは、部分的にリコールされたファイルを含んでもよく、ファイル全体の代わりにリコールされたファイルの範囲を重複排除し、以前に重複排除された部分に関連付けられた重複排除メタデーターを、新たに重複排除されたファイルの範囲と組み合わせることによって、部分的にリコールされたファイルを最適化する。以前に重複排除された部分は再度重複排除されないので、Ｉ／ＯおよびＣＰＵリソースのかなりの容量が節約される。同様に、部分的に重複排除されたファイル内にある一部は、その部分内にある新たなチャンクが、周囲にある以前に重複排除された部分のチャンクと整合するように重複排除することができる。

[0018] 他の実施態様例では、重複排除メカニズムは、大きなファイルを段階的に最適化し、このファイルをサブファイル・パーティションに区分し、各サブファイル・パーティション内にあるチャンクをチャンク・ストアにコミットし、ファイルを構成するファイル・ストリームからこのサブファイル・パーティションを切り捨てる。このような実施態様は、ファイル全体を最適化する前に記憶空間を解放し、ファイルが完全に重複排除される前にクラッシュまたはアボート(abortion)があった場合にメモリー・リークの可能性を低減する。

[0019] 他の実施態様例では、重複排除メカニズムは、中断命令(pause instruction)をサポートする。中断命令は、次の再開命令まで、重複排除プロセスを保留にする。重複排除メカニズムは、第１非重複排除部分において重複排除プロセスを再開する。第１非重複排除部分は、チャンキングされずチャンク・ストアにコミットされなかった最後の部分である。これによって、システム・リソースが他の作業負荷に必要とされる場合に、主システムが重複排除プロセスを中断することが可能になり、既に重複排除したデーターに対して重複排除プロセスを繰り返す必要はない。

[0020] 更に他の実施態様例では、チャンクおよび対応するファイル範囲の多レベル区分によって、大型ファイル上における高速入力／出力を可能にする。ファイル範囲の大きな集合体を含む重複排除メタデーターは検索が難しくなるので、ファイルを、多数の連続する、もっと小さなサブファイル・パーティションに区分し、これらを再度区分することによって、重複排除メカニズムは、これらのサブファイル・パーティション内において、仮想ファイル・オブセット（ファイルの先頭に対する）を特定のチャンク・オフセットに効率的に変換することが可能になる。ファイル・オフセット変換は、ファイルとの入力／出力（Ｉ／Ｏ）動作（即ち、リード／ライト）の間に実行することができる。この変換の適した実行は、Ｉ／Ｏ動作に対する影響を抑えて、行うことができる。

[0021] 図１は、一実施態様例にしたがって、部分的に重複排除されたファイルを最適化するシステム例を示すブロック図である。このシステム例は、ファイル１０２のような、部分的に重複排除されたファイルを完全重複排除ファイルに変換する種々の重複排除または最適化メカニズムをサポートすることができる。一実施態様例では、ファイル１０２は、非重複排除データー１０４および重複排除部分（即ち、チャンク）の組み合わせを含む。非重複排除データー１０４は、部分的にリコールされたデーター、および／または未だ重複排除されていないデーターを含むことがある。例えば、アプリケーション１１４は、部分的にリコールされたデーターを変更すること、および／または新たなデーターをファイル１０２に追加することもできる。

[0022] 一般に、ファイルが完全に重複排除されると、そのファイルにはメタデーター１０６が関連付けられる。このメタデーター１０６は、チャンク・ストア１１０におけるファイルのチャンク（例えば、Ｃ３、Ｃ６、およびＣ７）を、ファイルの論理表現に逆方向にマッピングする重複排除（ディダプ(dedup)）メタデーターを含む。重複排除プロセスの間にファイル１０２がサブファイル・パーティションに区分されると、ファイル１０２はパーティション表１１８も含む。このパーティション表１１８は、サブファイル・パーティション毎にファイル・オフセットを維持し、更にサブファイル・パーティション内のあらゆるパーティションに対するファイル・オフセットを維持する。本明細書において記載する場合、パーティション表１１８は、サブファイル・パーティションと対応するファイル範囲の階層を含むことができる。

[0023] チャンク・ストア・メタデーター１１２は、チャンク・ストア１１０が重複チャンクを格納しないことを保証するためにハッシュ・インデックスを含む。一般に、アプリケーション１１４が既存のデーターを変更するときまたは新たなデーターをファイルに書き込むとき、重複排除メカニズム１１６（例えば、ファイル・システム・フィルタに実装される）は、チャンク・ストア１１０内において１つ以上の被参照チャンクにアクセスし、これら１つ以上の被参照チャンクを、リコールされたファイル・データーとして戻し、必要に応じていずれかの解凍の後、リコールされたファイル・データーを被重複排除データー１０４に格納する。

[0024] ファイル１０２が完全重複排除状態から非重複排除／部分的重複排除状態に変化する原因となる種々の動作がある。これは、ユーザーまたはプロセスがファイルに書き込みを行ったときに、書き込まれたファイルのオフセット位置において変更されたファイル・データーが、もはや、以前にデーターを収容していた１つ以上のチャンクと一致しなくなったという場合を含む。このようなファイル変更をサポートするためにファイル全体を完全にリコールするのは、非効率的であることが多い（例えば、非常に大きなファイルに対する小さな変更の場合）。

[0025] 関連のあるチャンクのみをリコールすると、ファイル１０２が部分的に重複排除された状態になり、ファイル１０２は一部のリコールされたファイルのデーターと、リコールされていないチャンクに対する参照とを含むことになる。例えば、図１において、アプリケーション１１４がチャンクＣ７のみをリコールし、その対応するデーターに書き込んだ場合について検討する。ファイル１０２は、リコールされたチャンク・データーを、ライト動作によって変更されたものとして、非重複配著データー１０４に収容する。ファイル１０２がリコールされたデーターを収容することが分かり、今では古くなったチャンクＣ７にはもはやマッピングしないように、重複排除メタデーター１０８は、この部分的リコール状態を反映するように更新される。

[0026] 一実施態様例では、重複排除メタデーター１０８は、ファイル１０２のどの部分(portion or portions)がリコールされたのか、そしてどの部分が重複排除されたチャンクとしてチャンク・ストア１１０に残っているのか追跡する。このように、ファイル１０２は非重複排除状態、部分的重複排除（部分的リコール）状態、または完全重複排除（即ち、最適化された）状態で存在する可能性がある。ファイルは、種々のシナリオにおいて、部分的重複排除状態になり得る。例えば、ユーザーがあるファイル範囲をインプレースで(in-place)変更したことが考えられる。また、重複排除メカニズム１１６が、ユーザー・ライトをチャンク境界、疎ファイル境界(sparse file boundaries)（一実施態様では、各々６４ＫＢの固定ブロックである）、または他の何らかの境界に整合させるために、もっと多くのデーターをリコールすることも考えられる。他の例として、重複排除メカニズム１１６は、サブファイル・パーティションを最適化し、関連するファイル範囲を切り詰め、中断命令のためまたはシステムがクラッシュしたために、重複排除プロセスの間に停止しなければならなかったという場合もある。更に他の例では、重複排除メカニズム１１６が、ファイルの以前のバージョンを重複排除し、次いでユーザーがこのファイルを新たなデーターで拡張したという場合もある。

[0027] 一実施態様では、重複排除メカニズム１１６は、種々の追跡動作を実行する。この動作には、ファイル１０２のどの部分がリコールされ、どの部分がチャンク・ストア１１０に残っているかについて、重複排除メタデーター１０８においてデーターを追跡し続けることを含む。一実施態様例では、Microsoft（登録商標）NTFS構成に対応して、追跡データーはNTSFリパース・ポイント(reparse point)に維持される。これも、ファイルが部分的に重複排除されていることを重複排除メカニズム１１６に知らせる役割を果たす。リパース・ポイントは、他の使用シナリオでも周知であり、ここでは詳しく説明しない。尚、リパース・ポイントは単に代用品の１つであり、追跡の目的に他のメタデーター／ストリームを代わりに用いてもよいことを注記しておく。

[0028] 一実施態様例では、重複排除メカニズム１１６は、重複排除方針１２０にしたがって重複排除プロセスを実行する。このような方針は、ファイル１０２に対する重複排除プロセスをいつ開始、停止、および／または再開するか判断するために種々の判断基準を含む。例えば、重複排除メカニズム１１６は、ファイル１０２に対する変更後にある時間期間が経過したとき、またはホスト機械がアイドルになったときに、重複排除プロセスを開始するのでもよい。他の例として、重複排除メカニズム１１６は、新しいチャンクがあるサイズを超過したとき、あるいはホスト機械がアイドルでなくなったときまたは遮断する必要があるときに、重複排除プロセスを停止し、新たなチャンクをコミットするのでもよい。更に他の例として、重複排除メカニズム１１６は、非重複排除データー１０４のチャンキングが完了した後、またはサブファイル・パーティションの内１つのチャンキングを完了した後に、新たなチャンクをチャンク・ストア１１２にコミットするのでもよい。

[0029] 図２は、一実施態様例による重複排除メカニズム１１６のコンポーネント例を表すブロック図である。この実施態様例では、コンポーネント例は、ファイル２０２に対する重複排除プロセスの実行中に、順次行われるフェーズとして動作する。

[0030] 重複排除プロセスは、本明細書において説明するように、部分的に重複排除されたファイルまたは重複排除されていないファイルを、完全に重複排除されたファイルに変換する。これは、ファイル２０２をスキャンし、どれが部分的に重複排除されているか判断する識別フェーズ２０４を含む。一実施態様例では、重複排除メカニズム１１６は、種々の重複排除メタデーターを検査し、部分的にリコールされた状態のファイルを検出する。重複排除メタデーターは、１つ以上のストリーム・マップを指し示すリパース・データーを含むことができる。チャンク・ストアにおけるチャンクの総サイズ(combined size)がファイル・サイズ未満である場合、またはファイル範囲ビットマップが１つ以上の重複排除されていない部分を示す場合、このファイルは部分的に重複排除された状態にある。すると、重複排除メカニズム１１６は、重複排除された部分および重複排除されていない部分に対するファイル範囲を定義するストリーム・マップを引き出す。各部分は、開始ファイル・オフセットおよびサイズに対応することができ、重複排除メカニズム１１６はこれらから終了ファイル・オフセット(ending file offset)を計算する。ファイル範囲は、先頭から終端までファイル全体と重複せず、そしてファイル全体を内包しない。

[0031] 一実施態様例では、重複排除メカニズム１１６は、非重複排除部分のファイル範囲に渡るチャンクを識別する。例えば、アプリケーションがこれらのチャンクをリコールし、１つ以上の種々の部分を変更して、部分的にリコールされた状態にファイルを置いたということがあり得る。整合フェーズ２０６は、これらのチャンクに関連付けられたチャンク境界を変更して、これらの新たなチャンクと、重複排除部分に関連付けられたチャンク境界との間における重複を防止する。また、本明細書において説明するように、整合フェーズ２０６は、特定のファイル・オフセットにおいてチャンキング・フェーズ２０８を開始し、他のファイル・オフセットにおいてチャンキング・フェーズ２０８を終了するように、チャンキング・コンポーネントに指示する。

[0032] チャンキング・フェーズ２０８の間、経験則(heuristics)に応じて、ChA1〜ChAmのようなチャンキング・アルゴリズムを選択することができる。経験則は、ファイル拡張子、ヘッダ情報等というような、ファイル属性を伴うことができる。例えば、包括的チャンキング・アルゴリズムを１つのファイルに選択し、一方他のファイルには、そのファイル拡張子（ＺＩＰ部分に対するチャンキング・アルゴリズムのような）に特定的なチャンキング・アルゴリズムを有する場合がある。また、チャンキング・アルゴリズムは、識別フェーズ２０４からのヒントに基づいて、あるいは内部フィードバック２２０または外部フィードバック２２２に基づいて選択されるのでもよい。

[0033] チャンキング・フェーズ２０８（所与の実施態様において必要とされるファイル解凍を含むまたはそれの後に行われることもある）は、選択されたアルゴリズムにしたがって、ファイル・コンテンツをチャンクに解凍する。このアルゴリズムは、各チャンクの内容が他のファイルに重複される確率を高める可能性があり、これらのチャンクは後に圧縮されることもある。チャンキングは、ファイルの構造、コンテンツ・ドリブン・アルゴリズム（例えば、メディア・ファイルをメディア・ヘッダおよびメディア本体に区分し、次いでメディア本体を一連のパートに階層的に分割することができる）にしたがって、あるいは高速ハッシング技法（このような高速ハッシュ関数は、ＣＲＣおよびRabin関数ファミリーを含む）に基づいてファイル内容をチャンクするアルゴリズムを用いることによって実行することができる。これは、スライディング・ウィンドウ上で繰り返し計算され、ハッシュ関数および現在のチャンク・サイズ／内容が一定の判断基準を満たすときに、チャンクが選択される。

[0034] チャンキング・フェーズ２０８の結果は、チャンクのリスト（ファイル毎）を含み、１組の「チャンク・レコード」を用いてチャンクが受け渡される。各チャンク・レコードは、チャンク内にあるデーターのタイプを記述する関連メタデーターを収容する。このようなメタデーターの一例は、チャンク・アルゴリズムの実行の一部として計算される任意の(any)ローリング・ハッシュである。他の例は、チャンク内にある実際のデーターの圧縮レベルのインディケーターである（例えば、ＺＩＰチャンキング・モジュールは、圧縮選択モジュールに、既に圧縮されていそうなチャンクを圧縮しないように命令する）。尚、ホストされたプロセス実行では、チャンクは処理のためにしかるべき「出力キュー」に挿入され、次いで一括して重複排除プロセスに送られることを注記しておく。

[0035] チャンクは、一括して処理することができ、次のフェーズ、即ち、重複排除検出フェーズ２１０によって消費される。重複排除検出フェーズ２１０は、ハッシングによって各チャンクを一意に識別し、重複排除検出のためにハッシュを使用する。チャンキングの後、重複排除検出フェーズ２１０は、チャンク・ストア内に既にそのチャンクが存在するか否か判断する。ハッシュ・インデックス・サービスにおいて参照動作を呼び出すために、チャンクに対して計算される(calculated)強いハッシュが算出される(computed)。ハッシュ・インデックス・サービスは、既に重複排除システムには知られているまたは既にチャンク・ストア２１８に格納されている一意のチャンクの一部または全部のハッシュにインデックスを付ける。

[0036] チャンク・ストア２１８は、実際のチャンクの永続的データーベースを維持する。チャンキング・フェーズ２０８は、新たなチャンクをチャンク・ストア２１８に挿入すること（未だこのようなチャンクがない場合）、チャンク・ストアにおける既存のチャンクに参照データーを追加すること（以前から存続していたチャンクを検出したとき）、ならびに１組のチャンク挿入および／またはチャンク参照追加をコミットすることをサポートする。また、チャンク・ストア２１８は、ガベージ・コレクション、データー／メタデーター・チェック等を含む、種々の背景／保守ジョブも実施することができる。

[0037] メタデーター作成フェーズ２１２は、チャンキング・フェーズ２０８によって定義された新たなチャンクを説明するために、重複排除メタデーターおよびチャンク・ストア・メタデーターを生成する。ファイル毎に、ストリーム・マップのような、チャンク・ストア・メタデーターを維持する実施態様例では、重複排除メカニズム１１６は、元のチャンク・ストア・メタデーターおよび新たなチャンク・メタデーターを組み合わせることによって、このようなメタデーターを構築し直す。加えて、メタデーター作成フェーズ２１２は、新たなチャンクに関連付けられたチャンク・ストア・メタデーターにマッピングするように、重複メタデーターを更新する。

[0038] 一実施態様例では、重複排除メカニズム１１６は、無変化のチャンク定義を古いストリーム・マップから保持し、これらの定義を新たなストリーム・マップに追加する。整合された非重複排除部分に対応する新たなチャンクに対して、重複排除メカニズム１１６は対応する定義を新たなストリーム・マップに追加し、続いて、古いストリーム・マップの古くなった定義をいずれもスキップする。本質的に、新たなストリーム・マップは、古いストリーム・マップおよび新たなチャンク・メタデーターを縫合する(stitching)ことによって作成される。重複排除メカニズム１１６は、新たなストリーム・マップをチャンク・ストア・メタデーターに追加し、古いストリーム・マップを削除する。あるいは、重複排除メカニズム１１６は、新たなストリーム／マップを作成し古いストリーム・マップを削除するのではなく、新たなチャンク・メタデーターで古いストリーム・マップを更新する。

[0039] 他の実施態様例では、重複排除メタデーターがパーティション表を含むこともできる。このパーティション表は、チャンクおよびサブファイル・パーティションに関連付けられたファイル範囲の階層を構成する。この階層は、直接１組のサブファイル・パーティションにマッピングすることができる。一例では、１組の第２レベル・ストリーム・マップを指し示す最上位ストリーム・マップを含む。他の例では、ストリーム・マップの多レベル編成を含む。他の例では、予め定義された、固定サイズのサブファイル・パーティションを使用することを含み、最上位ストリーム・マップを調べることなく、ファイル・オフセットを固定サブファイル・パーティション・サイズで除算することによって、ファイル・オフセットと特定のサブファイル・パーティションとの間の変換を可能にする。

[0040] 他の実施態様例では、重複排除メカニズム１１６は、ストリーム・マップの代わりに参照カウント(reference count)をメタデーターの一部として使用する。重複排除メカニズム１１６は、もはや所与のファイルによって参照されないチャンク毎に参照カウントを減分し、整合された非重複排除部分に対応する、新たに参照されたチャンク毎に参照カウントを増分する。

[0041] 同じ重複排除プロセスにおいて１つの段階から次の段階に移行するとき、重複排除メカニズム１１６は、本明細書において説明するように新たなストリーム・マップを作成する代わりに、新たなチャンク定義を元のストリーム・マップに追加することもできる。一実施態様例では、重複排除メカニズム１１６は新たなチャンク定義をファイルの元のストリーム・マップに添付する。他の実施態様例では、重複排除メカニズム１１６は、元のストリーム・マップを一連の部分的ストリーム・マップに分割する。各部分的ストリーム・マップは、コミット・フェーズ２１６の間に処理されたサブファイル・パーティションに対応する。

[0042] 重複排除プロセスが、サブファイル・パーティションを最適化しつつ中断命令を扱う場合、重複排除メカニズム１１６は、新たなストリーム・マップを作成する。このストリーム・マップは、新たなチャンク・メタデーター、および重複排除部分に関連付けられた定義を含む。チャンキング・フェーズ２０８が非重複排除部分のチャンキングを再開するとき、新たなストリーム・マップは元のストリーム・マップに置き換わる。コミット・フェーズ２１６の間、このときリパース・データーが新たなストリーム・マップを参照して、元のストリーム・マップを取り戻すことができる。

[0043] ファイルが部分的にリコールされた状態にあり、重複排除プロセスが中断された場合、再開命令後に作成された新たなストリーム・マップは、元のストリーム・マップに置き換わらない。一実施態様例では、部分的にリコールされたファイルは、双方のストリーム・マップを参照する。他の実施態様例では、部分的にリコールされたファイルは、古いストリーム・マップのみを参照し続ける。重複排除メカニズム１１６は、コミット・フェーズ２１６の間はファイル切り詰めを回避する。最後のサブファイル・パーティションが重複排除されるときに、新たなストリーム・マップが元のストリーム・マップに置き換わる。

[0044] 新たなチャンクをチャンク・ストア２１８に追加する前に、これら新たなチャンクを、圧縮フェーズ２１４に関して処理することもできる。圧縮アルゴリズム・セレクタが、ファイルおよびチャンク・メタデーターを処理し、圧縮アルゴリズムＣＡ１〜ＣＡｎ（該当する場合）の内どれが、このタイプのデーターに対して最良に作用するか判断しようとすることができる。いずれかの圧縮が実行された後、ランタイム(runtime)は大幅な節約が得られたか否か検証することができる。例えば、圧縮されたチャンクがその未圧縮形態よりも大きい場合、新たなチャンクは圧縮されずに格納される（または、異なるアルゴリズムで圧縮を再度試すこともできる）。圧縮アルゴリズムは、方針、ファイル・タイプ等に基づいて選択することができる。

[0045] コミット・フェーズ２１６は、各ファイルを、チャンク・ストア２１８内にある重複排除データーを指し示す参照と置き換える。このために、重複排除メカニズム１１６は、チャンクが既にチャンク・ストアに挿入されたファイルのリストを受け取る。一実施態様では、各チャンク・リストはチャンクＩＤストリーム（一意のストリームＩＤで識別される）にカプセル化される。このチャンクＩＤストリームは、ファイルに関連付けられたリパース・ポイント内に存続する。コミット・フェーズ２１６の間、重複排除メカニズム１１６は、ファイルを、リパース・ポイントのような追跡データーと置き換える。この追跡データーは、ＩＤおよびチャンク・ストリームＩＤのロケーターを収容する。即ち、ストリーム・マップを収容するチャンクは、現在のファイルを組み立てるために用いられたチャンク、およびその論理オフセットのリストを含む。

[0046] 図３Ａ〜図３Ｃは、実施態様例にしたがって、完全重複排除ファイルに変換される少なくとも１つの非重複排除部分を含む種々のファイル例を示す。
[0047] 図３Ａは、部分的にリコールされたファイルを示す。このファイルは、ファイル・オフセット３０２にて開始しファイル・オフセット３０４にて終了し、ファイル・オフセット３０８にて開始する非重複排除部分３０６を含むチャンクを有する。各チャンクは等しく６４ＫＢの大きさになっているが、他のサイズも本開示の範囲内に該当する。一実施態様例では、重複排除メカニズム１１６は、ファイル・オフセット３０２においてチャンキング・フェーズを開始する。他の実施態様例では、重複排除メカニズム１１６はファイル・オフセット３０８においてチャンキング・フェーズを開始し、この場合、６４ＫＢよりも小さい新たなチャンク３１０を定義する。重複排除メカニズム１１６は、既に重複排除されている部分に関連付けられたチャンク境界と整合するように、新たなチャンクのチャンク境界を変更する。

[0048] 図３Ｂは、部分的にリコールされたファイルを示す。このファイルは、ファイル・オフセット３１２にて開始しファイル・オフセット３１２において終了し、ファイル・オフセット３１８にて終了する非重複排除部分３１６を含むチャンクを有する。一実施態様例では、重複排除メカニズム１１６は、ファイル・オフセット３１８においてチャンキング・フェーズを終了し、この場合、６４ＫＢよりも小さい新たなチャンク３１６を定義する。他の実施態様例では、重複排除メカニズム１１６は、新たなチャンクが、後続の重複排除部分に関連付けられたチャンク境界と整合するように、ファイル・オフセット３１４においてチャンク・フェーズを終了する。重複排除メカニズム１１６は、他の実施態様によれば、後続の重複排除部分を有するチャンクと整合するまで、ファイル・オフセット３１４を超えてチャンキング・フェーズを継続することもできる。

[0049] 更に他の実施態様では、重複排除メカニズム１１６は、ファイル・オフセット３１４を超えてチャンキング・フェーズを継続するが、チャンキング・フェーズをいつ終了するか判断するために閾値を使用する。この閾値以内に、後続の重複排除部分を有するチャンクとの整合ができない場合、重複排除メカニズム１１６は、チャンク３２０と同様の新たなチャンクを定義する。このチャンクは、６４ＫＢよりも小さく、要求される整合が得られる結果となる。一実施態様例では、重複排除メカニズムは、固定チャンク・サイズ（例えば、６４ＫＢから１２８ＫＢ）またはチャンクの総数に基づいて、閾値を計算する。

[0050] 図３Ｃは、部分的に重複排除されたファイルを示す。このファイルは、サブファイル・パーティション３２２、サブファイル・パーティション３２４、およびサブファイル・パーティション３２６に区分されている。重複排除メタデーターは、これらのサブファイル・パーティションに対してファイル・オフセットを維持する。この部分的に重複排除されたファイルの重複排除は、段階的に実行され、各サブファイル・パーティションがチャンキングされ、別の段階においてチャンク・ストアにコミットされる。次いで、重複排除メカニズムは、重複排除メタデーターを更新し、特定のサブファイル・パーティションの２つのコピーを保持することを回避するために、部分的に重複排除されたファイルを切り詰める。各段階の後、非重複排除部分はサイズを縮小する。最後のサブファイル・パーティションがコミットされたときに、部分的に重複排除されたファイルは、完全重複排除ファイルに変換される。

[0051] 一実施態様例では、重複排除メカニズム１１６は、サブファイル・パーティション３２２を重複排除しつつ、中断命令を処理し、ファイル・オフセット３２８において重複排除プロセスを停止する。再開命令を受けたときに、重複排除メカニズム１１６は、ファイル・オフセット３２８において重複排除プロセスを再開する。サブファイル・パーティション３２２を形成するチャンクをチャンク・ストアにコミットし、メタデーターを更新した後、重複排除メカニズム１１６は、サブファイル・パーティション３２２を削除し、サブファイル・パーティション３２４を重複排除する処理に移る。本明細書において説明したように、一旦サブファイル・パーティション３２４が重複排除されたなら、それ以上非重複排除部分は残っていないので、重複排除プロセスは終了する。

[0052] 図４Ａおよび図４Ｂは、一実施態様例による重複排除メタデーターを示す。図４Ａに表される一実施態様例では、重複排除メタデーターは、ファイル４０２およびファイル４０４を含む。ファイル４０２は、ストリーム・マップ４０８を参照する追跡データー４０６を含む。同様に、ファイル４０４は、ストリーム・マップ４１２を参照する追跡データー４１０を含む。これらのストリーム・マップの双方は、チャンク・ストア４１４内にあるチャンクに対応する。図示のように、ストリーム・マップ４０８はチャンクＣ２〜Ｃ４、およびチャンクＣ６を定義する。これらのチャンクは、ファイル４０２を形成する。同様に、ストリーム・マップ４１２は、ファイル４０４を形成するチャンクＣ１〜Ｃ５を定義する。

[0053] チャンクＣ５のような特定のチャンクがリコールされその後アプリケーションによって一部が変更されて（重複排除されない）、ファイル４０４が部分的に重複排除されたファイルになった場合、重複排除メカニズム１１６は、チャンクＣ５を包含する(encompass)１つ以上の新たなチャンクを定義する。次いで、重複排除メカニズム１１６は、ストリーム・マップ４１２を更新するか、またはストリーム・マップ４１２と置き換える新たなストリーム・マップを作成する。いずれの実施態様でも、重複排除メタデーターは、この時点では、チャンクＣ５の代わりに、１つ以上の新たなチャンクにマッピングする。例えば、重複排除メカニズム１１６が、チャンクＣ６と一致する(match)新たなチャンクを作成する場合、更新されたストリーム・マップ即ち新たなストリーム・マップは、チャンク・ストア４１４においてチャンクＣ６にマッピングする新たな定義を含む。

[0054] 図４Ｂに概略的に表される一実施態様では、ＮＴＦＳリパース・ポイント４４０が、ストリーム・マップを参照するためのポインター４４２と、非重複排除部分を有するチャンクを追跡するためのビットマップ構造４４４とを含む。リパース・ポイント４４０は、追跡データー４０６または追跡データー４１０の実施形態であってもよい。更に具体的には、ファイルを部分的にリコールするために、重複排除メカニズム１１６は、このファイルの仮想ビューを作成し、６４ＫＢ境界においてというように、所定の境界においてチャンキング・フェーズを実行する。重複排除メカニズム１１６は、リパース・ポイント４４０においてビットマップ構造４４４にこのビューを維持する。一実施態様では、ビットマップ構造４４４におけるセット・ビットが、チャンクが重複排除ファイルにリコールされたことを示し、ゼロ・ビットが、チャンクがチャンク・ストア内に存在することを示す。リパース・ポイントを設定する間に、チャンクのサイズを追加することができる。

[0055] 尚、あるときにデーターがリコールされ、他のときにビットマップ構造４４４が更新されると、クラッシュに関連する不一致(inconsistency)を生ずる可能性があることを注記しておく。本明細書において説明するように、データーを安定したストレージ（例えば、ディスク等）にコミットする（例えば、フラッシュ(flush)する）とき、動作の順序付けがシステム・クラッシュを矛盾のないもの(consistent)にする。更に具体的には、ビットマップ構造４４４に対する変更は、それが表す対応データーがディスクにフラッシュされた後でないと、ディスクにフラッシュされない。このように、ビットマップ構造４４４は、データーが安全にディスクにフラッシュされたことが分かるまで、データーが部分的にリコールされたことを決して示さない。尚、ディスクおよびファイル・システムがライト・スルー(write-through)をサポートする場合、フラッシュの代わりにライト・スルーを使用してもよいことを注記しておく。尚、ファイル・データー／メタデーターをディスクにフラッシュすることは、通例、本明細書では一例として用いられるが、これは一例に過ぎないことを注記しておく。つまり、「安定したディスクにコミットする」ことは、ファイル・システムおよび記憶媒体のライト・スルーの概念、ならびにファイル・システムおよび記憶媒体のフラッシュまたはデーターが確実に安定したストレージに書き込まれることを保証するための他のあらゆる手段を用いる概念も含む。

[0056] 一実施態様例では、ビットマップ構造４４４は、部分的にリコールされたファイルを逆に完全重複排除ファイルに効率的に変換するために使用することもできる。このために、重複排除のためにファイルをスキャンしているとき、部分的にリコールされたファイルの範囲（即ち、非重複排除部分）だけが重複排除のために重複排除メカニズム１１６に供給されるように、追跡データーを使用することができる。これらの部分的にリコールされたファイルの範囲を含む新たなチャンクがチャンク・ストアに追加されるに連れて、部分的にリコールされたファイルの範囲がここでは最適化されたチャンクとなり、もはや部分的にリコールされた範囲ではないことを反映するために、リパース・ポイント４４０を含む重複排除メタデーターを調節する。

[0057] 図５は、一実施態様例にしたがって少なくとも１つの非重複排除部分を有するファイルを完全重複排除ファイルに変換するステップを示す流れ図である。図５に示すステップは、ステップ５０２において開始し、ステップ５０４に進み、ここで重複排除メカニズム１１６が、部分的にリコールされたファイルを識別する。この部分的にリコールされたファイルは、チャンクに区分される。ステップ５０６は、重複排除メタデーターおよびチャンク・ストア・メタデーターというような、ファイルに関連付けられたメタデーターを用いた、１つ以上の非重複排除部分の識別を示す。本明細書において説明したように、重複排除メカニズム１１６は、一実施態様例にしたがって、リパース・ポイント内にあるリコール・ビットマップを調べて、リコールされたファイルの範囲、およびこれらのファイル範囲に及ぶチャンクの位置を判定する。

[0058] ステップ５０８は、いずれかの重複排除部分に対してチャンク境界を取り去るか否かについての判断を表す。一実施態様例では、非重複排除部分は、重複排除部分を構成するチャンクのチャンク境界と整合される必要があるので、２つの非重複排除部分の間に小さな重複排除部分があると、チャンキング・フェーズの間に小さなチャンクが定義される。部分的にリコールされたファイルが小さな重複排除部分を含む場合、図５に示す方法はステップ５１０に進む。一方、取り去るべき重複排除部分がない場合、図５において説明する方法はステップ５１２に進む。

[0059] ステップ５１０は、２つ以上の非重複排除部分を組み合わせて、１つの非重複排除部分にすることを目的とし、この１つの非重複排除部分は１つのファイル範囲のリコールされたデーターとして重複排除される。これは、チャンク・ストアからチャンクを読み出して、非重複排除部分間のギャップを埋めることが必要になる場合がある。ステップ５１０を実行した後、図５において説明する方法はステップ５１２に進む。

[0060] ステップ５１２は、非重複排除部分を検査することを目的とする。一実施態様例では、重複排除メカニズム１１６は、非重複排除部分を構成するまたは包含するチャンクを識別する。一実施態様例では、重複排除メカニズム１１６はファイル内における第１のまたは最も早い非重複排除部分を識別し、少なくとも１つの重複排除部分内にある周囲のチャンクのチャンク境界と整合する新たなチャンクを定義する。ステップ５１４は、少なくとも１つのチャンクの定義を表す。このチャンクは、非重複部分に関連付けられた開始ファイル・オフセットよりも前またはこれに等しいファイル・オフセットにて開始し、非重複排除部分と関連付けられた終了ファイル・オフセットの後またはこれに等しいファイル・オフセットにおいて終了する。

[0061] ステップ５１６は、部分的にリコールされたファイルの次の非重複排除部分を重複排除するか否かについての判断を目的とする。他に非重複排除部分がない場合、図５において説明する方法はステップ５１８に進む。一方、追加の非重複排除部分がある場合、図５において説明する方法はステップ５１２に戻る。ステップ５１８は、部分的にリコールされたファイルの少なくとも１つの重複排除部分のファイル・オフセットと整合するチャンク境界の判定を示す。一実施態様例では、少なくとも１つのチャンクの最後のチャンクは、少なくとも１つの重複排除部分の後続するチャンクのチャンク境界と重複しないチャンク境界を有する。同様に、少なくとも１つのチャンクの第１チャンクは、この少なくとも１つの重複排除部分の直前にあるチャンクのチャンク境界と重複しないチャンク境界を有する。

[0062] ステップ５２０は、少なくとも１つのチャンクについてのメタデーターを作成し、少なくとも１つのチャンクをチャンク・ストアにコミットすることに言及する。一実施態様例では、重複排除メカニズム１１６は、部分的にリコールされたファイルのファイル・オフセットと少なくとも１つのチャンクのチャンク境界との間におけるマッピングを作成する。次いで、重複排除メカニズム１１６は、これらのマッピングを、少なくとも１つの重複排除部分のチャンク境界と組み合わせ、チャンク・ストア・メタデーターを作成する。このチャンク・ストア・メタデーターは、そのファイルについての以前のチャンク・ストア・メタデーターと置き換わる。代替実施態様では、重複排除メカニズム１１６は重複排除メタデーター（例えば、リパース・ポイント、ストリームｉｄ、ビットマップ等）およびチャンク・ストア・メタデーター（例えば、ストリーム・マップ）を、これらのマッピングを用いて更新する。少なくとも１つのチャンクを格納する前に、重複排除メカニズム１１６はチャンク・ストアに関連付けられたハッシュ・インデックスを調べて、チャンクの中に既にチャンク・ストアに格納されているものがあるか否か判断する。

[0063] 他の代替実施態様では、重複排除メカニズム１１６は、次の重複排除部分をチャンキングする前に、ステップ５１８およびステップ５２０を実行する。例えば、ステップ５１６を実行する前に、重複排除メカニズム１１６は重複排除プロセスを停止させ、チャンク境界でチャンク・ストア・メタデーターを更新し、少なくとも１つのチャンクをチャンク・ストアにコミットし、非重複排除部分を削除することによって、部分的にリコールされたファイルを切り詰める。重複排除メカニズム１１６は、図６に示すような中断命令に応答して、重複排除プロセスを停止させるのでもよい。

[0064] 更に他の代替実施態様では、重複排除メカニズム１１６は、重複排除方針に基づいて重複排除プロセスを停止させるのでもよい。一例として、重複排除メカニズム１１６は、種々の判断基準を用いて、次の非重複排除部分を識別しこのような部分で少なくとも１つのチャンクを定義する前に、非重複排除部分に関連付けられた少なくとも１つのチャンクをコミットする。

[0065] ステップ５２２は、参照されないチャンク(unreferenced chunk)をチャンク・ストアから削除することを目的とする。例えば、これらのチャンクは、部分的にリコールされたファイルを含むいずれのファイルに対しても、ストリーム・マップともはや関連付けられていない。参照カウントを採用する実施態様では、重複排除メカニズムは少なくとも１つのチャンクに対して参照カウントを減数する。結果的に得られた参照カウントがゼロに等しい場合はいずれも、対応する各チャンクを取り戻して削除する。ステップ５２４は、図５によって説明した方法のステップを終了する。

[0066] 図６は、一実施態様例にしたがって、サブファイル・パーティションに区分されたファイルを重複排除するステップを示す流れ図である。図６に示すステップは、ステップ６０２において開始し、重複排除メカニズム１１６がファイルを処理するときに、ステップ６０４に進む。ステップ６０６は、ファイルをサブファイル・パーティションに区分することを目的とする。一実施態様例では、ファイルを全て直ちに重複排除するには、大量の時間を必要とする。したがって、重複排除メカニズム１１６はファイルを等しいサイズのサブファイル・パーティションに分割し、一緒に行う代わりに、１回に１つずつ重複排除する。

[0067] ステップ６０８は、第１重複排除部分を有するサブファイル・パーティションを識別することを目的とする。ファイルが全く重複排除されていない場合、重複排除プロセスは、第１サブファイル・パーティションにおいて開始する。ファイルが部分的に重複排除されている場合、重複排除プロセスは、非重複排除部分を含む第１サブファイル・パーティションに関連付けられた開始オフセットにおいて開始する。本明細書において説明したように、サブファイル・パーティションを完了する前に重複排除プロセスが中断された場合、重複排除プロセスは、第１非重複排除部分に関連付けられた開始オフセットにおいて再開する。何故なら、ここは、重複排除プロセスが停止した場所であるからである。更に、第１非重複排除部分の直前にあるチャンクは、チャンク・ストアにコミットされた最後のチャンクであったことになる。

[0068] ステップ６１０は、サブファイル・パーティションによって少なくとも１つのチャンクを定義することを目的とする。ステップ６１２は、重複排除メカニズム１１６が、第１非重複排除部分のチャンキングを停止させる中断命令を受けたか否かについての判定に言及する。代替実施態様によれば、システム・クラッシュが重複排除プロセスを同様に事実上中断させる。重複排除メカニズム１１６が中断すると、図６において説明する方法はステップ６１４に進む。ステップ６１４は、重複排除プロセスが第１非重複排除部分のチャンキングを再開するまで待つことを目的とする。一実施態様例では、重複排除メカニズム１１６はファイル・システムから命令を受け、第１非重複排除部分の開始オフセットにおいて少なくとも１つの定義を再開する。一方、重複排除メカニズム１１６が重複排除プロセスの間に中断しない場合、図６において説明する方法はステップ６１６に進む。

[0069] ステップ６１６は、重複排除メタデーターおよびチャンク・ストア・メタデーターを更新することを目的とする。一実施態様例では、重複排除メカニズム１１６はストリーム・マップにおけるマッピングを新たなチャンク定義によって更新する。他の実施態様例では、重複排除メカニズム１１６は、既に重複排除されているチャンクに対する元のマッピング、および新たなチャンク定義に関連付けられた新たなマッピングを用いて、新たなストリーム・マップを作成する。

[0070] ステップ６１８は、ファイルを切り詰め、少なくとも１つのチャンクをチャンク・ストアにコミットすることを目的とする。第１非重複排除部分を含むサブファイル・パーティションをファイルから除去する。何故なら、対応するファイル・データーのコピーがチャンク・ストアに格納されるからである。ステップ６２０は、次のサブファイル・パーティションを重複排除するか否かについての決定を目的とする。ファイル内に他のサブファイル・パーティションがない場合、図６において説明する方法はステップ６２２に進む。一方、追加のサブファイル・パーティションがある場合、図６において説明する方法はステップ６０８に戻る。ステップ６２２は、図６によって説明した方法のステップを終了する。
ネットワーク接続および分散型環境の例
[0071] 当業者は、本明細書において説明した種々の実施形態および方法は、あらゆるコンピューターあるいは他のクライアントまたはサーバー・デバイスに関して実現できることを認めることができよう。これらは、コンピューター・ネットワークの一部としてまたは分散型計算環境において展開することができ、あらゆる種類の１つ以上のデーター・ストアに接続することができる。これに関して、本明細書において説明した種々の実施形態は、任意の数のメモリーまたは記憶ユニット、ならびに任意の数の記憶ユニットにまたがって実行する任意の数のアプリケーションおよびプロセスを有する任意のコンピューター・システムまたは環境において実現することができる。これは、リモートおよびローカル・ストレージを有するネットワーク環境または分散型計算環境において展開されるサーバー・コンピューおよびクライアント・コンピューターを含むが、これに限定されるのではない。

[0072] 分散型計算は、計算デバイスおよびシステム間における通信交換によって、コンピューター・リソースおよびサービスの共有を図る。これらのリソースおよびサービスは、情報の交換、キャッシュ・ストレージ、およびファイルのような、オブジェクトのディスク・ストレージを含む。また、これらのリソースおよびサービスは、負荷均衡のための多数の処理ユニットに跨がる処理パワーの共有、リソースの拡大、処理の特殊化等も含む。分散型計算は、ネットワーク接続を利用し、クライアントがそれらの集合的パワーを利用し企業(enterprise)全体が恩恵を得ることを可能にする。これに関して、種々のデバイスがアプリケーション、オブジェクト、またはリソースを有することができ、本開示の種々の実施形態について説明したようなリソース管理メカニズムに関与することができる。

[0073] 図７は、ネットワーク接続または分散型計算環境例の模式図を示す。この分散型計算環境は、計算オブジェクト７１０、７１２等、および計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等を備える。計算オブジェクトまたはデバイスは、アプリケーション例７３０、７３２、７３４、７３６、７３８によって表されるように、プログラム、方法、データー・ストア、プログラマブル・ロジック等を含むことができる。尚、計算オブジェクト７１０，７１２等、および計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等が、パーソナル・ディジタル・アシスタント（ＰＤＡ）、オーディオ／ビデオ・デバイス、移動体電話機、ＭＰ３プレーヤー、パーソナル・コンピューター、ラップトップ等のような、異なるデバイスを備えてもよいことは認めることができよう。

[0074] 各計算オブジェクト７１０、７１２等、および計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等は、１つ以上の他の計算オブジェクト７１０、７１２等および計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等と、通信ネットワーク７４０を通じて直接または間接的に通信することができる。図７では１つのエレメントとして図示されているが、通信ネットワーク７４０は、図７のシステムにサービスを提供する他の計算オブジェクトおよび計算デバイスを備えてもよく、および／または図示されていない多数の相互接続されたネットワークを表すこともできる。各計算オブジェクト７１０、７１２等、あるいは計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等は、アプリケーション７３０、７３２、７３４、７３６、７３８というようなアプリケーションを収容することもできる。このアプリケーションは、本開示の種々の実施形態にしたがって設けられるアプリケーションとの通信、あるいはその実現に適したＡＰＩ、あるいは他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを利用することもできる。

[0075] 分散型計算環境をサポートする種々のシステム、コンポーネント、およびネットワーク構成がある。例えば、有線システムまたはワイヤレス・システムによって、ローカル・ネットワークまたは広く分散されたネットワークによって、計算システムを互いに接続することができる。現在、多くのネットワークがインターネットに接続されており、広域分散型計算のためのインフラストラクチャーを提供し、多くの異なるネットワークを包含するが、種々の実施形態において説明したようなシステムに付随する通信例には、あらゆるネットワーク・インフラストラクチャーを使用することができる。

[0076] つまり、クライアント／サーバー、ピア・ツー・ピア、または混成アーキテクチャーというような、ネットワーク・トポロジーおよびネットワーク・インフラストラクチャーのホストを利用することができる。「クライアント」とは、それが関係しない他のクラスまたはグループのサービスを使用するクラスまたはグループのメンバーのことである。クライアントは、他のプログラムまたはプロセスによって提供されるサービスを要求するプロセス、例えば、大まかに１組の命令またはタスクとすることができる。クライアント・プロセスは、他のプログラムまたはサービス自体についての作業詳細を全く「知る」必要なく、要求したサービスを利用する。

[0077] クライアント／サーバー・アーキテクチャーでは、特にネットワーク接続システムでは、クライアントは、通常、他のコンピューター、例えば、サーバーによって提供される共有ネットワーク・リソースにアクセスするコンピューターである。図７の例示では、非限定的な例として、計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等は、クライアントと考えることができ、計算オブジェクト７１０、７１２等は、サーバーと考えることができる。サーバーとして機能する計算オブジェクト７１０、７１２等は、クライアント計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等からのデーター受信、データーの格納、データーの処理、クライアント計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等へのデーター送信というような、データー・サービスを提供するが、いずれのコンピューターであっても、状況に応じて、クライアント、サーバー、または双方と見なすことができる。

[0078] サーバーは、通例、インターネットまたはワイヤレス・ネットワーク・インフラストラクチャーのような、リモートまたはローカル・ネットワークを通じてアクセス可能なリモート・コンピューター・システムである。クライアント・プロセスは、第１コンピューター・システムにおいてアクティブであることができ、サーバー・プロセスは第２コンピューター・システムにおいてアクティブになることができ、通信媒体を介して互いに通信し、こうして分散型機能を設け、多数のクライアントがサーバーの情報収集能力を利用することを可能にする。

[0079] 通信ネットワーク７４０またはバスがインターネットであるネットワーク環境では、例えば、計算オブジェクト７１０、７１２等はウェブ・サーバーであることができ、このウェブ・サーバーによって、他の計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等は、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）のような、多数の既知のプロトコルの内いずれかにしたがって通信する。サーバーとして機能する計算オブジェクト７１０、７１２等が、クライアントとして、例えば、計算オブジェクトまたはデバイス７２０、７２２、７２４、７２６、７２８等として役割を果たすこともできる。これは分散型計算環境の特徴と言える。
計算デバイス例
[0080] 前述のように、本明細書において説明した技法はいずれのデバイスにも応用できるという利点がある。したがって、全ての種類のハンドヘルド、携帯用、およびその他の計算デバイスならびに計算オブジェクトが、種々の実施形態に関連する使用に想定されることは言うまでもない。このことから、図８において以下に説明する次の汎用リモート・コンピューターは、計算デバイスの一例に過ぎない。

[0081] 実施形態は、デバイスまたはオブジェクトのためのサービスの開発者による使用のために、部分的にオペレーティング・システムを通じて実現することができ、および／または本明細書において説明した種々の実施形態の１つ以上の機能的態様を実行するように動作するアプリケーション・ソフトウェア内に含むことができる。ソフトウェアは、クライアント・ワークステーション、サーバー、または他のデバイスというような、１つ以上のコンピューターによって実行される、プログラム・モジュールのような、コンピューター実行可能命令という一般的なコンテキストで説明することができる。コンピューター・システムがデーターを伝達するために用いることができる種々の構成およびプロトコルを有し、したがって特定の構成もプロトコルも限定とは見なされないことは、当業者には認められよう。

[0082] したがって、図８は、本明細書において説明した実施形態の１つ以上の態様を実現することができる、適した計算システム環境の一例を示す。しかしながら、先に明確にしたように、計算システム環境８００は適した計算環境の一例に過ぎず、使用範囲や機能に関して何ら限定を示唆する意図はない。加えて、計算システム環境８００は、例示の計算システム環境８００に示されるコンポーネントのいずれの１つまたはその組み合わせに関しても、何らかの依存性を有するように解釈されることは意図していない。

[0083] 図８を参照すると、１つ以上の実施形態を実現するリモート・デバイスの一例は、コンピューター８１０の形態とした汎用計算デバイスを含む。コンピューター８１０のコンポーネントは、処理ユニット８２０、システム・メモリー８３０、およびシステム・バス８２２を含むことができるが、これらに限定されるのではない。システム・バス８２２は、システム・メモリーから処理ユニット８２０までを含む種々のシステム・コンポーネントを結合する。

[0084] コンピューター８１０は、通例、種々のコンピューター読み取り可能媒体を含み、コンピューター８１０によってアクセスすることができる入手可能な媒体であればいずれでも可能である。システム・メモリー８３０は、リード・オンリー・メモリー（ＲＯＭ）および／またはランダム・アクセス・メモリー（ＲＡＭ）というような、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含むことができる。一例として、そして限定ではなく、システム・メモリー８３０は、オペレーティング・システム、アプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データーを含むことができる。

[0085] ユーザーは、入力デバイス８４０を通じて、コマンドおよび情報をコンピューター８１０に入力することができる。また、モニターまたは他のタイプのディスプレイ・デバイスも、出力インターフェース８５０のようなインターフェースを通じて、システム・バス８２２に接続される。モニターに加えて、コンピューターは、スピーカーおよびプリンターのような他の周辺出力デバイスも含むことができ、これらは出力インターフェース８５０を通じて接続することができる。

[0086] コンピューター８１０は、リモート・コンピューター８７０のような、１つ以上の他のリモート・コンピューターへの論理接続を用いて、ネットワーク接続または分散型環境において動作することもできる。リモート・コンピューター８７０は、パーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイスまたは他の共通ネットワーク・ノード、あるいは他のいずれのメディア消費または送信デバイスであってもよく、コンピューター８１０に関して以上で説明したエレメントのいずれかまたは全てを含むことができる。図８に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）のようなネットワーク８７２を含むが、他のネットワーク／バスを含んでもよい。このようなネットワーク接続環境は、家庭、事務所、企業規模のコンピューター・ネットワーク、イントラネット、およびインターネットでは極普通である。

[0087] 前述のように、種々の計算デバイスおよびネットワーク・アーキテクチャーに関連付けて実施形態例について説明したが、基礎となる概念は、リソース使用の効率を高めることが望ましいネットワーク・システムおよび計算デバイスまたはシステムであればいずれにでも応用することができる。

[0088] また、アプリケーションおよびサービスが本明細書において提供された技法を利用することを可能にする同じ機能または同様の機能、例えば、しかるべきＡＰＩ、ツール・キット、ドライバー・コード、オペレーティング・システム、制御手段、単独のまたはダウンロード可能なソフトウェア・オブジェクト等を実現するには多数の方法がある。つまり、本明細書における実施形態は、ＡＰＩ（または他のソフトウェア・オブジェクト）の観点から、更には本明細書において説明した１つ以上の実施形態を実現するソフトウェアまたはハードウェア・オブジェクトの観点からも考えられる。このため、本明細書において説明した種々の実施形態は、全体的にハードウェア、部分的にハードウェアであり部分的にソフトウェア、およびソフトウェアである態様を有することができる。

[0089] 「一例」(exemplary)という用語は、本明細書では、例(example)、実例(instance)、または例示(illustration)としての役割を果たすとことを意味するために用いられる。疑惑回避のために、本明細書において開示する主題は、このような例によって限定されることはない。加えて、本明細書において「一例」として説明されたいずれの態様または設計も、必ずしも、他の態様または設計に対して優先されるまたは有利であると解釈されるとは限らず、当業者には知られている同等の構造および技法例を除外することを意味するのではない。更に、「含む」(includes)、「有する」(has)、「収容する」(contains)という用語、およびその他の同様の単語が使用される限りにおいて、疑惑回避のために、このような用語は、「含む」(comprising)が請求項において使用されるときに、いずれの追加のエレメントまたは他のエレメントも排除しない、開いた移行単語(transition word)として解釈するのと同様に、内包的である(inclusive)ことを意図するものとする。

[0090] 前述のように、本明細書において説明した種々の技法は、ハードウェアまたはソフトウェアで実現することができ、あるいはしかるべきときには、双方の組み合わせで実現することもできる。本明細書において用いる場合、「コンポーネント」、「モジュール」、「システム」等の用語は、同様に、コンピューター関係エンティティに言及することを意図しており、ハードウェア、またはハードウェアおよびソフトウェアの組み合わせ、またはソフトウェア、または実行中のソフトウェアのいずれでもよい。例えば、コンポーネントは、プロセッサー上で実行するプロセス、プロセッサー、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピューターであってもよいが、これらに限定されるのではない。一例として、コンピューター上で実行するアプリケーション、およびそのコンピューターの双方がコンポーネントであることができる。１つ以上のコンポーネントがプロセス内に存在することができ、および／または実行のスレッドおよびコンポーネントが１つコンピューター上に局在(localize)してもよく、および／または２つ以上のコンポーネント間で分散されてもよい。

[0091] 前述のシステムは、様々なコンポーネント間における相互作用に関して説明した。尚、このようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントの一部、および／または追加のコンポーネントを、以上のことの種々の置換(permutation)および組み合わせにしたがって、含むことができることを認めることができよう。また、サブコンポーネントは、親コンポーネント内に含まれる代わりに（階層的）、他のコンポーネントに通信可能に結合されるコンポーネントとして実現することもできる。加えて、１つ以上のコンポーネントを組み合わせて１つのコンポーネントにして、総合的な機能を設けること、または数個の別個のサブコンポーネントに分割することもでき、そして統合機能を得るためにこのようなサブコンポーネントに通信可能に結合する、管理レイヤーのようないずれの１つ以上の中間レイヤーも設けられることも特筆することができる。本明細書において説明したいずれのコンポーネントも、本明細書では具体的に説明しなかったが当業者には一般に知られている１つ以上の他のコンポーネントと相互作用することもできる。

[0092] 本明細書において説明したシステム例に関して、説明した主題にしたがって実現することができる方法は、種々の図のフローチャートを参照しても認める(appreciate)こともできる。説明を簡素化するために、これらの方法を一連のブロックで示し説明したが、種々の実施形態はそのブロックの順序には限定されないことは言うまでもないことであり認められてしかるべきである。何故なら、一部のブロックは、本明細書において図示および説明したものとは異なる順序で出て来ても、および／または他のブロックと同時に出てきてもよいからである。連続しない、または分岐するフローがフローチャートによって示される場合、同じまたは同様の結果が得られる種々の他の分岐、フロー・パス、およびブロックの順序も実現できることは、認めることができよう。更に、図示したブロックの一部は、以下で説明する方法を実現するときには任意である。
結論
[0093] 本発明には種々の変更および代替構造が可能であるが、その内ある種の例示実施形態を図面に示し、以上で詳細に説明した。しかしながら、開示した具体的な形態に本発明を限定する意図はなく、逆に、本発明の主旨および範囲に該当する全ての変更、代替構造、および均等物を内包することを意図していることは理解されてしかるべきである。

[0094] 本明細書において説明した種々の実施形態に加えて、本発明から逸脱することなく、他の同様の実施形態も用いることができ、または対応する実施形態（１つまたは複数）の同じ機能または同等の機能を実行するために、説明した実施形態（１つまたは複数）に変更および追加を行うことができることは言うまでもない。その上更に、多数の処理チップまたは多数のデバイスが、本明細書において説明した１つ以上の機能の実行を共有することができ、そして同様に、複数のデバイスに跨がって格納を実行することができる。したがって、本発明はいずれの１つの実施形態にも限定されず、逆に、添付した請求項にしたがう広さ、主旨、および範囲で解釈することとする。

Claims

計算環境において、少なくとも１つのプロセッサー上で少なくとも部分的に実行される方法であって、少なくとも１つの非重複排除部分を有する部分的に重複排除されたファイルを完全重複排除ファイルに最適化し直すステップを含み、前記部分的に重複排除されたファイルは更に、チャンク・ストアに維持され前記部分的に重複排除されたファイルに関連付けられたメタデーターによって参照される少なくとも１つの重複排除部分を有し、前記最適化し直すステップは、前記ファイルの各非重複排除部分を処理して少なくとも１つのチャンクを決定するステップと、前記少なくとも１つのチャンクをチャンク・ストアにコミットするステップと、前記チャンク・ストアにコミットされた各チャンクへの参照を含むように、前記ファイルに関連付けられたメタデーターを変更するステップと、を含む、方法。
前記チャンク・ストアから重複排除部分をリコールするステップと、前記リコールされた重複排除部分によって分離された前記ファイルの２つの非重複排除部分を、各非重複排除部分および前記重複排除部分を含む１つの非重複排除部分に組み合わせ、その後前記１つの非重複排除部分を処理するステップと、を更に含む、請求項１に記載の方法。
少なくとも１つの非重複排除部分を処理するステップは、前記非重複排除部分に関連付けられた開始ファイル・オフセットよりも前またはこれに等しいファイル・オフセットから開始するチャンクを定義するステップを含む、請求項１に記載の方法。
直前の重複排除部分に完全に含まれる最後のチャンクと整合させることによって前記ファイル・オフセットを決定するステップを更に含む、請求項３に記載の方法。
少なくとも１つの非重複排除部分を処理するステップは、前記非重複排除部分に関連付けられた終了ファイル・オフセットよりも後またはこれに等しいファイル・オフセットにおいて前記部分のチャンキングを終了することによってチャンクを定義するステップを含む、請求項１に記載の方法。
前記非重複排除部分の前記チャンキングが直前の重複排除部分に関連付けられた１つまたは複数の既存のチャンクと整合する場所に基づいて前記終了ファイル・オフセットを決定するステップを更に含む、請求項５に記載の方法。
チャンキングは、前記非重複排除部分の終端を超えて継続し、更に、サイズに基づく閾値またはチャンク数に基づく閾値内でチャンク整合が得られるか否か判断するステップと、前記閾値内で整合が得られない場合、チャンキングを停止するステップと、を含む、請求項５に記載の方法。
前記ファイルを複数のサブファイル・パーティションに区分するステップを更に含み、前記ファイルを最適化し直すステップは、各サブファイル・パーティションを別々に処理するステップを含む、請求項１に記載の方法。
前記メタデーターを変更するステップは、少なくとも１つの最適化し直されたチャンクをコミットするステップと一緒に行われ、前記メタデーターを変更するステップは、重複排除部分のチャンク定義を前記少なくとも１つの最適化し直されたチャンクのチャンク定義と組み合わせるステップを含む、請求項１に記載の方法。
前記ファイルの最適化し直しを中断し、その後再開するステップを更に含む、請求項１に記載の方法。
中断する前に少なくとも１つのチャンクを前記チャンク・ストアにコミットするステップを更に含む、請求項１０に記載の方法。
前記少なくとも１つのチャンクを前記チャンク・ストアにコミットして中断するステップは、１つまたは複数の判断基準に基づいて行われ、前記判断基準は、ファイル・サイズ、前記最適化し直しを実行する機械が非アイドルになったとき、または前記機械が停止されようとしているときを含む、請求項１１に記載の方法。
前記ファイルのどの部分が重複排除されたかを追跡するメタデーターを維持するステップと、重複排除された前記ファイルの部分を切り捨てるステップと、を更に含む、請求項１１に記載の方法。
前記チャンクは、チャンク・ストアにコミットされ、更に、前記ファイルを最適化し直した結果としてもはや参照されない少なくとも１つのチャンクを前記チャンク・ストアから解放する（garbage collecting）ステップを含む、請求項１に記載の方法。
少なくとも１つのプロセッサーと、前記少なくとも１つのプロセッサーに通信可能に結合され、少なくとも１つの非重複排除部分を有する部分的に重複排除されたファイルを完全重複排除ファイルに最適化し直すように構成された重複排除メカニズムを含むコンポーネントを含んだメモリーと、を備える、計算環境におけるシステムであって、前記部分的に重複排除されたファイルは更に、チャンク・ストアに維持され前記部分的に重複排除されたファイルに関連付けられたメタデーターによって参照される少なくとも１つの重複排除部分を有し、前記重複排除メカニズムは、各非重複排除部分を少なくとも１つの最適化し直されたチャンクにチャンキングし、少なくとも１つの最適化し直されたチャンクを前記チャンク・ストアにコミットし、前記チャンク・ストアにコミットされた前記ファイルの各チャンクを参照するように前記メタデーターを変更する、ように構成される、システム。
コンピューター実行可能命令を有する１つまたは複数のコンピューター読み取り可能記憶媒体であって、前記コンピューター実行可能命令は、実行されると、
部分的に重複排除されたファイルの非重複排除部分に対してチャンクを定義するステップであって、前記部分的に重複排除されたファイルは更に、チャンク・ストアに維持され前記部分的に重複排除されたファイルに関連付けられたメタデーターによって参照される少なくとも１つの重複排除部分を有する、ステップと、
前記チャンクのチャンク境界を、前記ファイルの少なくとも１つの重複排除部分と関連付けられたファイル・オフセットと整合させるステップと、
前記チャンク境界に基づいて、前記ファイルに関連付けられた前記メタデーターを更新するステップと、
前記チャンクをチャンク・ストアにコミットするステップと、
を含むステップを実施する、１つまたは複数のコンピューター読み取り可能記憶媒体。