JP5886447B2 - ロケーション非依存のファイル - Google Patents

Description

下記はファイルシステムに関し、より詳しくは、ロケーション非依存のファイルのシステム及び方法に関する。

電子コンテンツが普及した結果、そのような電子コンテンツを記憶する電子ストレージをユーザが拡張しなければならなくなってきた。しかしながら、概して、ユーザがコンピューティングデバイスの容量を超える量の電子コンテンツを溜め込むことも珍しくない。例えば、パーソナルコンピュータ上の電子ストレージの容量が、ポータブルメディアプレーヤの容量を実質的に超過する可能性もある。それ故、ユーザは、パーソナルコンピュータからポータブルメディアプレーヤに転送される電子コンテンツの量を制限する必要に迫られている。同様な問題は、ストレージ容量が異なる２台の別個のコンピューティングデバイス上で電子コンテンツの同期化を試みたときに起こる可能性がある。

そのような問題に対する解決策の１つは、一般に、不足が生じたデバイスに追加のストレージを増設することであった。しかしながら、デバイスの種類によっては、ストレージの増設が概して実用的でないか又は不可能なことさえある。例えば、ポータブルメディアプレーヤの型式によっては、ストレージ容量を拡張できないものもある。別の例では、ポータブル又はラップトップコンピュータなどの一部のコンピューティングデバイスのストレージ容量は、外部ハードディスクなどの外部記憶装置を装着することによって拡張できる。しかしながら、このソリューションは、ラップトップコンピュータの可搬性が制限される場合があるという点で実用性に欠ける。

そのような問題に対する別のソリューションは通例、ネットワーク接続を介してコンピューティングデバイスから増設ストレージへのアクセスを可能にすること、即ち、リモートコンピューティングデバイスのストレージ容量をローカルコンピューティングデバイスが利用できるようにリモートコンピューティングデバイスを構成することであった。動作中には、リモートコンピューティングデバイス上に電子コンテンツを有するファイルを記憶できる。このファイルは、続いて、リモートコンピューティングデバイスからローカルコンピューティングデバイスに転送するか又はコピーすることによって、ローカルコンピューティングデバイスで利用されるようになる。ローカルコンピューティング上には、永久に又は一時的にファイルを記憶できる。しかしながら、ローカルコンピューティングデバイスのユーザがアクセスに先立ってファイル全体が転送されるのを待たなければならないので、この結果、アクセスの遅延時間が大幅に長引く場合がある。しかも、ローカルコンピューティングデバイス上にファイルを一時的にしか記憶しない場合は、リモートコンピューティングシステムをそのファイルの任意の最新版で更新する必要がある。前にも述べたように、この更新を行うには通常、その後でローカルコンピューティングデバイス上のファイルをローカルコンピューティングデバイスから転送してリモートコンピューティングデバイスに戻す必要があるため、更に遅延時間が長引くことになる。

それ故、本技術は、電子コンテンツを複数のロケーションにて管理し使用するためのシステム及び方法を提供する。本技術の一態様は、電子コンテンツのデータストレージを提供することにある。特に、電子コンテンツの１つ以上のファイルを表すデータユニットは、１つ以上の（ローカル又はリモート）ロケーション及びアクセスファイルに記憶されている一連のデータセグメントに変換される。各データセグメントは、別々のハッシュ値に関連付けられているデータユニットの別個の部分を表し、通信ネットワークを介して高速伝送が可能になるように構成できる。

アクセスファイルは、データユニット及び関連データセグメントに関する情報を含む。特に、アクセスファイルは、データユニットに関連付けられているメタデータ、データセグメントに関するセグメント化スキーム情報、ハッシュ値に関するハッシュスキーム情報、データセグメントのロケーション、及びデータセグメントのハッシュ値を判別するための１つ以上のハッシュＩＤ値を含む。一部の構成では、データセグメントのハッシュ値のハッシュによって１つ以上のＩＤ値が生成される。また、代わりに、ハッシュ値自体を値としてもよい。

その場合、本技術を後述するようなデータの取り出しに使用できる。ローカルシステムには、データユニットを記憶する代わりに電子コンテンツ用のアクセスファイルを記憶しておき、対応するアクセスファイルを使用してデータユニットに対する任意の要求に供するようにローカルシステムを構成する。故に、データユニットに対するアクセスがローカルシステムによって要求されたときに、要求を履行するうえで必要とされるデータユニット部分、及び取り出しの対象となるデータセグメントが、アクセスファイルを利用して判別されるようになる。更には、アクセスファイルのハッシュ情報に基づき、マッチングハッシュ値を提供するデータセグメントを識別することによって、必要とされるデータセグメントが取り出されるようにもなる。

データセグメントで表されるデータユニットの使用量が十分多い場合、本技術によって、少なくとも最も頻繁に使用されるデータセグメントを永続的に記憶できる。あるいは、データセグメント及びアクセスファイルを使用してローカルシステムにおいてデータユニットを再アセンブルすることもできる。

また、本技術により、生成されるデータユニットの各バージョンの別々の個別コピーを必要とすることなしに、データユニットの別々のバージョンを生成することも可能になる。例えば、データセグメントにアクセスした結果、データセグメントの更新処理が為された場合、セグメントが更新された結果として取得されるハッシュ値が、元のデータセグメントのハッシュ値とは異なるものになる。それ故、更新されたデータセグメントに基づいて新しいハッシュＩＤ値を提供して、データユニットの更新済みバージョンを表す更新済みアクセスファイルを生成するだけで、更新済みデータユニットを「作成」できる。

本技術はまた、拡張ファイルシステム及びそれに関する方法を提供することもできる。概して、コンピューティングデバイスのストレージは、使用済み部分と未使用部分とから構成するのが一般的である。使用済み部分は、ローカルデバイス上に記憶されたデータユニット用の論理ストレージを提供するファイルシステムにより論理的に管理される。本技術において、ファイルシステムは、リモートシステムから取り出されたデータセグメント用のストレージとして未使用部分を利用するように更に構成される。つまり、前述したように、アクセスファイルは、論理ストレージに記憶され、関連付けられているデータユニットに対する要求に供するために使用される。その後、データセグメントは未使用スペース内に記憶され、それらのハッシュ値を介してアクセスされる。データセグメントの取り出しに利用可能なスペースが十分にない場合は、他のデータセグメントを優先度に基づいて削除又は上書きすることもできる。加えて、ファイルシステムは、幾つかの基準に基づき、データセグメントからの及びデータセグメントへのデータユニット毎に論理ストレージが管理されるように構成できる。

コンピューティングデバイスの例を示す。 アクセスファイル及び関連付けられているデータセグメントの構成の実施形態の概略図である。 コンピューティングシステムの実施形態の概略図である。 データユニットをアクセスファイル及び関連付けられているセグメントに変換するための方法の実施形態におけるステップのフローチャートである。 データユニットをアクセスファイル及び関連付けられているセグメントに変換するためのシステムの実施形態の概略図である。 アクセスファイル及び関連付けられているセグメントを使用してデータユニットにアクセスするための方法の実施形態におけるステップのフローチャートである。 アクセスファイル及び関連付けられているセグメントをデータユニットに変換するための方法の実施形態におけるステップのフローチャートである。 様々なバージョンのデータユニットを生成するための方法の実施形態におけるステップのフローチャートである。 コンピューティングシステムの代替実施形態の概略図である。

開示されている方法及び装置の様々な実施形態については、後ほど詳述する。特定の実施態様を検討するが、これは説明のためにのみ行われることを理解されたい。他のコンポーネント、構成及びステップが本開示の趣旨及び範囲から逸脱することなく使用できることは、関連技術の当業者によって認識されるであろう。

図１を参照すると、可搬式又は固定式であり得る汎用コンピューティングデバイス１００が図示してある。汎用コンピューティングデバイス１００は、処理ユニット（ＣＰＵ）１２０と、読み出し専用メモリ（ＲＯＭ）１４０及びランダムアクセスメモリ（ＲＡＭ）１５０などのシステムメモリ１３０を含む様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１１０と、を含む。他のシステムメモリ１３０も同様に使用できることがある。本システムが、複数のＣＰＵ１２０を有するコンピューティングデバイス上、又は一緒にネットワーク接続されたグループ又はクラスタのコンピューティングデバイス上で動作して、より高い処理性能を提供し得ることが理解される。システムバス１１０は、メモリバス又はメモリコントローラ、周辺機器バス、及び様々なバスアーキテクチャのいずれかを使用するローカルバスを含む数種のバス構造のいずれであってもよい。ＲＯＭ１４０などに記憶された基本入出力（ＢＩＯＳ）は、起動中などにコンピューティングデバイス１００内の要素間で情報を伝えるのを支援する基本ルーチンを提供することがある。コンピューティングデバイス１００は、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、テープドライブ、ソリッドステートドライブなどの記憶装置１６０を更に含む。記憶装置１６０は、ドライブインターフェースによりシステムバス１１０に接続される。ドライブ及び関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、及び他のデータの不揮発性ストレージをコンピューティングデバイス１００に提供する。一態様では、特定の機能を実行するハードウェアモジュールは、その機能を実行するために、ＣＰＵ、バス、ディスプレイなどの必要なハードウェアコンポーネントに関連した有形のコンピュータ可読媒体に記憶されたソフトウェアコンポーネントを含む。基本コンポーネントは、当業者に知られており、デバイスが小さなハンドヘルドのコンピューティングデバイスか、デスクトップコンピュータか、又は大規模コンピュータサーバーかなどのデバイスのタイプにより、適切な変動が考慮される。

本明細書で述べる例示的な実施形態は、ハードディスクを使用するが、当業者は、磁気カセット、フラッシュメモリカード、ＤＶＤ、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ビットストリームを含むケーブル信号又はワイヤレス信号など、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体が、例示的な動作環境で使用されてもよいことを理解されるだろう。

コンピューティングデバイス１００に対するユーザの対話操作を可能にする任意の数の入力メカニズム、例えば、会話用のマイクロフォン、ジェスチャ又は図形入力用のタッチセンシティブスクリーン、キーボード、マウス、モーション入力、スピーチなどが、入力デバイス１９０で表してある。デバイス出力１７０はまた、当業者に公知の多くの出力メカニズムのうちの１つ以上であり得る。例えば、映像出力デバイス又は音声出力デバイスは、ディスプレイ又はスピーカに接続できるか、又はディスプレイ又はスピーカを含むものが、一般的である。加えて、これらの特化された機能のパフォーマンスを増強する目的に、特化されたプロセッサを映像出力デバイス及び音声出力デバイスに含めさせることもできる。幾つかの例では、マルチモーダルシステムは、ユーザに、コンピューティングデバイス１００との通信の複数の入力のタイプを提供できるようにする。ユーザ入力及びシステム出力は一般に、通信インターフェース１８０によって統制、管理される。任意の特定のハードウェア配列上で動作している、開示されている方法及びデバイスは何らの制約も受けないため、改良されたハードウェア又はファームウェア配列が開発されるにしたがって、基本的な諸機能を容易に改良されたハードウェア又はファームウェア配列に置換できる。説明を分かり易くするために、(「プロセッサ」と表記された機能ブロックを含む)個々の機能ブロックを含めて構成されたものとして、例示的なシステムが示してある。これらのブロックで表されている機能は、ソフトウェアを実行できるハードウェアを含むがこれに限定されない共有ハードウェア又は専用ハードウェアのいずれかを用いることによって提供できる。例えば、図１に示された１つ以上のプロセッサの機能は、単一の共用プロセッサ又は複数のプロセッサによって提供されてもよい。（「プロセッサ」という用語が使用されている場合、ソフトウェアを実行できるハードウェアだけを指すものと解釈すべきではない。）例示的な実施形態は、マイクロプロセッサ及び／又はデジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、後述する動作を実行するソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、及び結果を記憶するランダムアクセスメモリ（ＲＡＭ）を含み得る。超大規模集積化（ＶＬＳＩ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、及び特定用途向け集積回路（ＡＷ）ハードウェアの実施形態も提供され得る。

様々な実施形態の論理演算は、（１）汎用コンピュータ内のプログラマブル回路上で実行される、コンピュータにより実行される一連のステップ、動作又は手順、（２）特定用途プログラマブル回路上で実行される、コンピュータにより実行される一連のステップ、動作又は手順及び／又は（３）プログラマブル回路内の相互接続されたマシンモジュール又はプログラムエンジンとして実行される。

ここで図２を参照すると、本技術によるアクセスファイル及び関連付けられているデータセグメントの概略図が示してある。上に記載したように、本技術の一態様は、電子コンテンツの１つ以上のアイテムを表すデータユニットを記憶するための代替の手段を提供することにある。データユニットをデータセグメント及びアクセスファイルに変換するプロセスについては、後ほど図３及び図４を参照しながら詳述する。再び図２に戻って説明すると、データユニットの変換結果は、クラウド又はアクセスファイル２０２、及び１つ以上のロケーション２０６に記憶されている１つ以上のデータセグメント２０４である。

アクセスファイル２０２は、データセグメント２０４を介したデータユニットへのアクセス方法を指示するデータの集合体から構成されるデータファイルである。例えば、図２に示すように、アクセスファイル２０２は、データユニットに関連付けられているメタデータ２０２Ａが記憶されるように構成できる。図２に示すように、メタデータ２０２Ａに、データユニットの拡張論理サイズを含めてもよい。しかしながら、この点に関して本技術は何らの制約も受けないため、メタデータ２０２Ａにはまた、データユニットに関連付けられている他の如何なる種類のメタデータも含むことができる。このメタデータには、日付情報、ユーザ情報、ファイルの種類の情報及び属性情報が包含され得るが、これらはほんの数例にすぎない。しかしながら、２０２Ａに他の如何なる種類の識別情報を含めてもよいし、又は２０２Ａに含まれる情報は上記情報より少なくしてもよい。更に、データユニットが電子コンテンツの２つ以上のアイテムを表す場合、各アイテムのメタデータはまたアクセスファイルのメタデータ２０２Ａ内に含めてもよい。

また、アクセスファイルには、メタデータ２０２Ａに加えて、セグメント化スキーム情報２０２Ｂ、即ち、データセグメントの構成を記述した任意の情報を含むこともできる。例えば、図２に示すように、セグメント化スキーム情報２０２Ｂは、データセグメント２０４のサイズであり得る。図２のセグメント化スキーム情報２０２Ｂには、全てのデータセグメント２０４のサイズが同じ６４Ｋであることを示してあるが、この点に関して本技術は何らの制約も受けない。幾つかの事例においては、上述したように、データセグメント２０４サイズはそれぞれ異なっていてもよい。更に、セグメント化スキーム情報２０２Ｂは、サイズ情報だけに制限されない。寧ろ、幾つかの事例において、セグメント化スキーム情報２０２Ｂには、データセグメント２０４の構成方法に関して追加の詳細を指定することも可能である。例えば、データセグメント２０４は、データユニット及び他の部分に関連付けられているデータから構成されるペイロード部分を含んだパケット又はファイルとして構成することもできる。それ以外の部分には、エラーチェック用の部分、データセグメント内のデータのデータユニット内部の開始位置及び終了位置、データセグメントと他のセグメントとの関係、並びに任意の他の情報を指示する部分が含まれ得る。それ故、セグメント化スキーム情報２０２Ｂには、データの取り出し時に正しく抽出できるように、データセグメントの構造を指定しておくことも可能である。データセグメント２０４構造及び構成を指定する他の何らかの情報もまた、セグメント化スキーム情報２０２Ｂ内に指定できる。

上述したように、データセグメントのサイジングは多様であり得るが、多くの構成においては、データセグメントへのアクセスが迅速かつ効率的になるように、データセグメントのサイジングを選択できる。つまり、ネットワーク接続されたデバイス間で、遅延又は遅滞をほとんど若しくは一切伴わずにデータセグメントをサイジングできる。例えば、上述されている６４Ｋセグメントの転送に必要とされる帯域幅が比較的少なくて済む場合もある。加えて、また、特定のデータストレージ構成又はデータパケット構成が利用されるようにセグメントのサイジングを選択することもできる。つまり、様々な種類のメモリデバイス及びデータパケットは、データへの個別アクセスが行われるように構成されるのではなく、特定の量のデータを含んだブロックへのアクセスが行われるように構成されるのが一般的である。それ故、本技術ではまた、可能な限り高いスループットを維持するため、そのようなブロックの構成が利用されるようにデータセグメントをサイジングできる。

本技術の一態様は、データセグメント２０６に関連付けられているハッシュ値を利用するデータセグメントを取り出すことにある。それ故、ハッシュ値を正しく判別する方法を特定できるように、アクセスファイル２０２にはまたハッシュスキーム情報２０２Ｃを含めてもよい。図２において、ハッシュスキーム情報２０２Ｃに指定されているハッシュタイプはＳＨＡ２であるが、この点に関して本技術は何らの制約も受けないため、本技術においては他の如何なる種類のハッシュスキームも使用できる。ハッシュスキームの使用法については、後で更に詳述する。

本技術の説明では、用語「ハッシュ」、「ハッシュ値」、「ハッシュ関数」などを引用するが、これらの用語の使用は、如何なる形であれ制限的なものであると見なすべきではない。例えば、本明細書において「ハッシュ関数」は、第１のサイズの第１のデータセットと第１のサイズよりも小さい第２のサイズの第２のデータセットとの間のマッピング又は変換を提供する、任意のサブルーチン、アルゴリズム、プロセス、方法などを指す。

アクセスファイル２０２の付加部分は、ロケーション情報２０２Ｄである。ロケーション情報２０２Ｄには、データセグメント２０４が位置する１つ以上のロケーション２０６を指定できる。図２において、ロケーション情報２０２Ｄは、信頼されたユニフォームリソースロケータ（ＵＲＬ）文字列のリストとして示してある。しかしながら、ロケーション情報２０２Ｄは、如何なる形式であってもよく、データセグメント２０４が位置し得る任意の種類のリソースを指定できる。加えて、一部の構成では、ロケーションにアクセスするための特定の順序を、ロケーション情報２０２Ｄに指示できる。例えば、冗長バージョンのデータセグメントを一次的及び二次的なロケーションに記憶する必要がある場合は、データセグメントを一次的なロケーションに位置付けることができないときに限り、先に一次的なロケーションにアクセスしてから二次的なロケーションにアクセスすべきことを、ロケーション情報２０２Ｄに指定できる。

ロケーション情報２０２Ｄのコンテンツは、アクセスファイルの作成時に固定できるが、一部の構成においてはロケーション情報２０２Ｄを経時的に更新することもできる。つまり、データセグメントのストレージロケーションを変更するか又はさもなければ調整する場合には、そのような更新を受信して自動的にアクセスファイル２０２が調整されるように、アクセスファイル２０２が記憶されているコンピューティングシステムを構成できる。そのような調整は、グローバルに又はファイル毎に為され得る。加えて、更新にはまた、アクセスファイル２０２を利用するコンピューティングデバイスのロケーションも反映され得る。つまり、更新には、コンピューティングデバイスのロケーションに基づいてストレージロケーションが反映され得る。その結果、アクセスファイル２０２に関連付けられているデータセグメントへのアクセス性が向上する。

また、アクセスファイル２０２には、ハッシュ識別（ハッシュＩＤ）情報２０２Ｅ、即ち、データセグメント２０４のハッシュ値が直接又は間接的に指定される情報を含めてもよい。一部の構成では、ハッシュＩＤ情報２０２Ｅに、データセグメントのハッシュ値のリストを指定できる。あるいは、アクセスファイル２０２のファイルサイズを制限するか又はアクセスファイルに実質的に同じサイズ及びコンテンツを提供した方が好ましい場合もある。そのような場合、様々なデータユニットに関連付けられているハッシュ値の数値は、それぞれのデータユニットのサイズに応じて大幅に異なり得る。それ故、ソニック構成では、ハッシュＩＤ情報２０２Ｅに、１つ以上の複合ハッシュ値を指定できる。これにより、データセグメントに関連付けられているハッシュ値からハッシュ値が計算される。例えば、図２に示すように、データセグメント２０４に関連付けられているハッシュ値２０８については、複合ハッシュ値２１０を計算してハッシュＩＤ情報２０２Ｅとして使用できる。故に、データの取り出し中に、複合ハッシュ値２１０を使用してハッシュ値２０８を計算することによって、データセグメント２０４を取り出すことができる。

上述したように、各データセグメント２０４と別のデータセグメントとの関係、又は各データセグメント２０４とデータユニットとの関係を指定した情報をデータセグメント２０４に含んでもよい。しかしながら、この種の情報は同様に又は代わりに本技術における複合ハッシュ値２１０を介して記憶することも可能である。つまり、複合ハッシュ値２１０を使用することにより、データセグメント２０４を識別できるだけでなく、データセグメント２０４同士の間の関係を判別することも可能になる。例えば、データユニットがセグメント化によって様々なデータセグメント２０４が生成される際には、様々なデータセグメントのコンテンツをデータユニットの内部に配置する方法を定義する特定の順序、階層などが存在する。したがって、複合ハッシュ値２１０を生成する際には、まず、データユニット内のデータセグメント２０４同士の間の関係に対応した順序でハッシュ値２０８を配置できる。また、代わりに、関係を表すデータを生成してもよい。その後、ハッシュ値２０８のこの構造のハッシュ値を得るか、又はハッシュ値２０８及び構造データの組み合わせを得ることによって、複合ハッシュ値２１０を生成できる。結果として、複合ハッシュ値２１０には、ハッシュ値２０８が記憶されるだけでなく、様々なデータセグメント２０４の関係情報も記憶される。その結果、データセグメント２０４間の関係に関する別個の情報をアクセスファイル２０２内又はデータセグメント２０４内に記憶することによって、データセグメント２０４及びアクセスファイル２０２のサイズを更に縮小させる必要がある。

一部の構成においてアクセスファイルに複数の複合ハッシュ値２０８を含むことができる点は注目するに値する。複合ハッシュ値２０８の個数は、様々な要因に基づき得る。例えば、データユニットが複数のファイルから構成されるか、又は明確に定義された境界に沿った部分に細分され得る場合、これらのファイル又は部分のそれぞれについて別個の複合ハッシュ値２０８を生成できる。結果として、これらのファイル又は部分のうち１つだけが必要とされる場合、複合ハッシュ値２０８のうちの対応するもの１つだけが、データセグメント２０４の関連付けられているものを判別する処理を必要とする。

上述のストレージ構成では、新しい種類のファイルシステムによるデータユニットの管理を可能にしている。このことは、図３に関して略図的に示してある。図３は、本技術に従って構成されたコンピューティングデバイス３００の概略図である。

図３に示すように、コンピューティングデバイス３００は、ファイルシステム３０２と、コンピューティングシステム３００用データが記憶されており、かつファイルシステム３０２によって管理されているコアストレージ３０４と、を含んで構成される。図３においてファイルシステム３０２は、階層ファイルシステムプラス（ＨＦＳ＋）として示してあるが、この点に関して本技術は何らの制約も受けないため、他の如何なる種類のファイルシステムも制限なしに本技術にて使用できる。

動作中に、ファイルシステム３０２は、コアストレージ３０４を２つ以上のストレージエリアとして管理する。特に、コアストレージ３０４を、１つ以上の論理ボリューム部分３０６（ハッチング無し）及びそれ以外の部分３０８（ハッチング有り）として管理することも可能である。コンピューティングシステム内に記憶されているデータユニットを管理するための論理ボリューム３１０を定義する目的で、論理ボリューム部分３０６がファイルシステム３０２によって管理される。論理ボリューム３１０をファイルシステム３０２により実質的に従来方式にて管理することにより、データ取り出し及びデータ記憶が実行できるようになっている。

それ以外の部分３０８は、コンピューティングデバイス３００におけるデータセグメントの管理及び記憶用のコンテンツアドレス指定可能ストレージ（ＣＡＳ）３１２を定義する目的に、ファイルシステム３０２によって使用される。データの取り出し及びデータの記憶を実行するため、ファイルシステム３０２及びＣＡＳ３１２が以下のような動作をする。

データの取り出しに関しては、上述したように、本技術ではデータユニットをアクセスファイル及び１つ以上のデータセグメントで表すことができる。したがって、そのようなデータユニット又はその一部分を要求に応答してコンピューティングデバイスによりアクセスする必要のある場合は、データユニット用のアクセスファイルが処理され、かつ要求に必要なデータセグメントが判別されるようにファイルシステム３０２を構成する。

本技術においてアクセスファイルのロケーションは可変であり得る。一部の構成においてアクセスファイルは、コンピューティングデバイス３００の内部に記憶してもよく、しかも、コンピューティングデバイス３００内部における１つ以上のロケーションにアクセスファイルを記憶することもできる。例えば、アクセスファイルは、１つ以上の構成内の論理ボリューム３１０内に記憶され得る。ある構成において、アクセスファイルは、論理ボリューム３１０内に記憶されている任意のデータユニットと共に追加のファイルとして記憶される。別の構成では、論理ボリューム３１０又は更に別個の論理ボリューム（図示なし）の一部分をアクセスファイルの記憶用に確保できる。しかしながら、アクセスファイルを論理ボリューム内に記憶する必要はない。寧ろ、コンピューティングデバイス３００内の他のデータストレージロケーションを代わりに使用してもよい。例えば、ファイルシステム３０２は、アクセスファイルを記憶するための専用メモリ又はキャッシュを有していてもよい。

ファイルシステム３０２は、この情報を使用して、その場合、ＣＡＳ３１２に対して分析又はクエリを実行し、データセグメントが利用可能かどうかを判別できる。一部の構成において分析は、アクセスファイルに基づいて取得されたハッシュ値を含むデータセグメントがＣＡＳ３１２に記憶されているかどうかを判別することを目的としたＣＡＳ３１２のスキャンであり得る。他の構成において、ファイルシステム３０２は、コンピューティングデバイス３００においてメンテナンスされているテーブルにアクセスできる。このテーブルは、データセグメントが記憶されているＣＡＳ３１２内のロケーション及びＣＡＳ３１２内の各ロケーションに関連付けられているハッシュ値のリストを含む。その後で、所望されるハッシュ値に関連付けられているデータセグメントが、ＣＡＳ３１２内に存在するかどうかが判別される。

アクセスファイルからのハッシュ値とマッチするデータセグメントがＣＡＳ３１２内で利用できない場合は、代わりにデータセグメントがリモートストレージ３１４から取り出されてＣＡＳ３１２内に配置され得る。リモートストレージ３１４内でのデータセグメントの場所指定は、ＣＡＳ３１２内でのデータセグメントの場所指定と同じ又は異なる様式で実行できる。一旦データセグメントがＣＡＳ３１２内で利用可能になった後は、必要に応じて、データセグメントからデータを抽出できる。一旦ＣＡＳ３１２がデータセグメントで充填されており、追加のデータセグメントを取り出す必要が生じた場合は、より古い又は使用頻度が低いデータセグメントを上書きしてもよい。同様に、データユニットを論理ボリューム３１０に追加する必要があり、ＣＡＳ３１２がデータセグメントで充填されている場合は、より古い又は使用頻度が低いデータセグメントを上書きすることによって論理ボリュームの拡張が可能になる。データセグメントの取り出し及びアクセスのプロセスについては、後ほど図６に言及しながら更に詳しく説明する。

データストレージ（即ち、論理ストレージ３１０内のデータユニットをアクセスファイル及びデータセグメントに変換すること）に関しては、データユニットが処理されてかつアクセスファイル及びデータセグメントが生成されるように、ファイルシステム３０２が構成される。次いで、データセグメントを少なくともＣＡＳ３１２にコピーできる。加えて、そのデータセグメントをリモートストレージ３１４にもコピーできる。続いて、論理ストレージ３１０内のデータユニットが削除され、コンピューティングシステム３００が、データアクセスファイル及びデータセグメントで定義されているデータユニットのバージョンに依存する可能性がある。データの記憶プロセスについては、以下図４及び５に言及しながら詳述する。

ここで図４〜８に戻ると、上述したように、アクセスファイル及びデータセグメントの構造を利用して、コンピューティングデバイス用ファイルシステムの様々な諸機能を実施するための様々な方法が提供されている。

最初に、図４及び５に関して、データユニットを変換するための例示的な方法及びシステムを説明する。図４は、本技術に従ってデータユニットをアクセスファイル及び関連付けられているデータセグメントに変換するための例示的な方法４００におけるステップのフローチャートである。図５は、データユニットをアクセスファイル及び関連付けられているデータセグメント及びそのストレージに変換するための、図３のコンピューティングデバイス３００内などの、コンピューティングデバイス内の例示的なシステム５００の略図である。図５に示すように、コントローラ５０２を設け、このコントローラ５０２に命令又は構成情報５０４を制御させて、それらをシステム５００のコンポーネントに供給させることによって、方法４００を遂行することもできる。上で図２に関して説明したように、構成情報５０４には、セグメント化スキーム情報、ハッシュスキーム情報、及びロケーション情報を含むことができる。

方法４００はブロック４０２において開始され、ブロック４０４に進む。ブロック４０４において、変換対象のデータユニットを選択できる。例えば、図５に示すように、ローカルストレージ５０８内の特定のデータユニット５０６をアクセスファイル及びデータセグメントに変換する必要があることが、コントローラ５０２によって判定され得る。一部の構成において、ブロック４０２での選択は、１つ以上の要因又は基準に基づく自動的な選択であり得る。そのような基準には、使用、年齢及びサイズが包含され得るが、これらはほんの数例にすぎない。しかしながら、この点に関して本技術は何らの制約も受けないため、他の任意の要因又は要因の組み合わせを分析してデータユニット５０６が識別されるようにコントローラ５０２を構成できる。他の構成において、ブロック４０４での選択は手動による選択であり得る。つまり、ローカルストレージ５０８内のデータユニットは、ユーザにより直接的に識別され得る。更に他の構成においては、データユニット５０６の自動的識別及び手動による識別の組み合わせを提供できる。

ブロック４０４において、一旦データユニット５０６が選択された後、方法４００はデータユニットの処理を続行して、ブロック４０６において初めにデータユニット５０６をデータセグメントに細分する。例えば、図５に示すように、データユニット５０６をセグメント化システム５１０のデータユニットプロセッサ５１２に送り込むことによって、構成情報５０４に基づいてデータセグメント５１４を生成することが可能になる。データユニット５０６をデータセグメント５１４にセグメント化することは、様々な基準に従って実行できる。基準は、データユニットプロセッサ５１２に固有のものである場合もあれば、構成情報５０４内に提供される場合もあり、又はその両方の組み合わせである場合もある。例えば、上述したように、基準にはデータセグメント５１４のサイズを指定してもよい。また、基準には、セグメント化が発生するデータユニット５０６内のロケーションを指定することもできる。例えば、基準には、ｎバイト数毎にセグメント化が為されるように指定できる。あるいは、データユニット５０６を分析することによって、機能性、クリティカリティ、又はデータユニット５０６の様々な部分に関連付けられている他の任意の特性に基づいて、データユニット５０４用の論理セグメント又はセグメントの群を判別できる。加えて、基準は、データセグメント５１４を利用し、かつこのデータセグメントと相互作用するシステムに依存し得る。例えば、特定のシステム又は通信ネットワークが特定のサイズの、又は特定の構成を有するデータセグメントより効率的に動作する場合、この構成にデータセグメント５１４が適合するようにデータユニットプロセッサ５１２を構成できる。しかしながら、本技術は如何なる特定のセグメント化スキームにも制限されないため、どのような種類のセグメント化スキームにも使用できる。

ブロック４０６においてデータセグメント５１４がデータユニットプロセッサ５１２を介して生成された後、ブロック４０８においてデータセグメント５１４のハッシュ値を生成できる。例えば、図５に示すように、また、様々なデータセグメント５１４に対するハッシュ値５１８を生成するためのハッシュモジュール５１６をセグメント化システム５１０に含んでもよい。上述したように、本技術においては任意の種類のハッシュスキームを利用できるが、衝突のリスクを回避するため、実質的に一意のハッシュ値が提供されるハッシュスキームを使用できる。ＳＨＡ２は、そのような目的に対応した例示的なハッシュスキームである。

ブロック４０８において、一旦ハッシュ値５１８がハッシュモジュール５１６により計算された後は、ブロック４１０においてアクセスファイルの生成又はアセンブルが可能になる。特に、セグメント化システム５１０に、アクセスファイルを生成するためのアクセスファイルジェネレータ５２０を含んでもよい。アクセスファイルジェネレータ５２０は、データユニット５０６に対するメタデータ５２２及び構成情報５０４とハッシュ値５１８を組み合わせて用いることで、データユニット５０６及びデータセグメント５１４用のアクセスファイル５２４を生成できる。

メタデータ５２２を得るには、幾つかの方法があり得る。例えば、図５に示すように、データユニット５０６からメタデータ５２２を抽出しかつメタデータ５２２をアクセスファイルジェネレータ５２０に転送するように、データユニットプロセッサ５１２を構成してもよい。しかしながら、この点に関して本技術は何らの制約も受けないため、セグメント化システム５１０の内部又は外部にて他の任意の方法を使用してメタデータ５２２を得ることができる。

アクセスファイル５２４内に含まれるハッシュスキーム情報、セグメント化スキーム情報、及びロケーション情報に関して、これらはアクセスファイルジェネレータ５２０により構成情報５０４から得ることができる。あるいは、また、そのような情報を利用するセグメント化システム５１０内のモジュール又はユニットは、この情報をアクセスファイルジェネレータ５２０に転送できる。

ブロック４０８及び４１０の後に又はこれらのブロックと並行して、ブロック４１２においてデータセグメント５１４を記憶できる。データセグメント５１４が記憶されるロケーションには、ローカルストレージ５０８、リモートストレージ５２６、又はその両方の組み合わせが含まれ得る。上で図３に関して説明したように、一部の構成では、データセグメント５１４を常にリモートストレージ５２６内に記憶しておくことによって、アーカイブコピーデータをセグメント５１４の上書きに必要とされた場合に提供できる。

上述したように、ブロック４１０において生成されたアクセスファイル５２４には、ロケーション情報が含まれる。少なくとも幾つかのデータセグメント５１４がローカルストレージ５０８内に記憶されている構成では、ローカルシステムはローカルストレージ５０８内でデータセグメント５１４を探せるようにアクセスファイル５２４にてローカルストレージ５０８を識別できる。一方、一部の構成においては、ローカルストレージ５０８のデータセグメント５１４がチェックされるように、ローカルシステム（即ち、ファイルシステム）を構成することもできる。それ故、アクセスファイル内のロケーションからローカルストレージ５０８を排除してアクセスファイル５２４のサイズが更に縮小されるように、アクセスファイルジェネレータ５２０を構成してもよい。

一旦ブロック４１２においてデータセグメント５１４が記憶され、ブロック４１０においてアクセスファイル５２４がアセンブルされた後、方法４００はブロック４１４に進むことができる。ブロック４１４では、アクセスファイル５２４を使用してデータユニット５０６に対する任意の要求に供するように、ローカルシステムを再構成できる。このプロセスには、アクセスファイル５２４をローカルストレージ５０８内又はローカルシステム内の他のストレージに記憶することと、ローカルシステムがアクセスファイル５２４を介してデータユニット用のデータをアクセスするようにファイルシステムを構成することと、を含めてもよい。任意選択的に、ブロック４１６において、ローカルストレージ５０８からデータユニット５０６を削除又はパージしてもよい。その後、ステップ４１８において方法４００は前の処理を再開する。このステップに、方法４００の繰り返しを含めてもよい。

図６は、本技術に従ってアクセスファイル及び関連付けられているデータセグメントを使用してデータユニットにアクセスするための例示的な方法６００のステップにおけるフローチャートである。ブロック６０２において、方法６００が開始され、引き続きブロック６０４に進む。ブロック６０４において、データユニットの少なくとも選択部分へのアクセスに対する要求が受け取られる。つまり、アプリケーション又は要求に応じて、データユニットの一部のみが必要とされ得る。典型的なコンピューティングデバイスでは、ローカルシステム内でのデータユニットに対する要求は、ローカルシステム用のデータ記憶装置を管理する１つ以上のファイルシステムによって供される。それ故、ブロック６０４には、データユニットの選択部分に対する要求をファイルシステムに転送することを含めてもよい。

ブロック６０４において、一旦要求がファイルシステムにより受け取られた後は、ブロック６０６においてファイルシステムはデータユニットに対する要求にどのようにして供すべきかを決定できる。つまり、ブロック６０６において、ファイルシステムはアクセスファイル及びデータセグメントを使用して、データユニットに関連付けられている要求に供するように構成されているかどうかを判定できる。ファイルシステムがこのように構成されなかった場合は、方法がブロック６０８に進み、従来の方法を使用してデータユニットをローカルストレージから取り出すことができる。その後、方法６００がブロック６１０に進み、前の処理（方法６００の繰り返しを含む）を再開する。

ブロック６０６において、ファイルシステムがアクセスファイルを利用して、データユニットに対する要求に供するように構成されていると判定した場合、方法６００はブロック６１２に進むことができる。ブロック６１２では、要求されたデータユニットに対するアクセスファイルを得ることも又はアクセスすることもできる。本技術において、アクセスユニットのロケーションは可変であり得る。一部の構成では、アクセスファイルは、ローカルシステムのローカルストレージ内部において、ローカルシステム上、又は専用メモリロケーションなどの特化されたロケーション内のいずれかに存在するデータユニットと共に、識別されたセグメントを記憶できる。例えば、ローカルシステムには、キャッシュ又はアクセスファイルを記憶するための他の予約メモリエリアを含めてもよい。あるいは、またアクセスファイルを１つ以上のリモートロケーションに記憶することもできる。そのような構成では、要求に供するため、ブロック６１２において、要求を受けると直ぐリモートロケーションにアクセスしてアクセスファイルの永久的又は一時的なコピーを作成するようにファイルシステムを構成できる。

ブロック６１２において、一旦アクセスファイルが取得された後は、ブロック６１４においてアクセスファイルの処理を開始し、要求に供するうえで必要なデータセグメントを得ることができる。例えば、ブロック６１４では、アクセスファイルを処理することによって、要求に基づいて、要求及びその対応するハッシュ値に対応する特定のデータセグメントを識別できる。例えば、アクセスファイル内のメタデータ情報及びセグメント化スキーム情報を利用して、要求に関連付けられているデータセグメントを判別できる。その場合、後になってから、セグメント化スキーム情報及びハッシュＩＤ情報を使用して、識別されたデータセグメントのハッシュ値を判別することもできる。データユニット全体が必要とされる場合は、全てのデータユニットに対するハッシュ値を得る。一方、データセグメントの一部分のみが必要な場合は、当該セグメントについてのみハッシュ値を取り出せば済むが、この点に関して本技術は何らの制約も受けない。つまり、要求に供するうえで必要なデータセグメントに対応したハッシュ値を含む限り、如何なる数のハッシュ値も得ることができる。

この構成の利点の１つは、多くの時点で、ユーザは通例データユニットの特定の部にアクセスする必要があるが、データユニット全体に直ちにアクセスせずに済むという点である。例えば、データユニットが音声又は映像コンテンツから構成される場合は、現在表示されている音声又は映像コンテンツの部分に対応するデータユニットの部分、更には追加の部分（例えば、コンテンツの何らかのバッファリングを提供するため）へのアクセスを提供するだけで済む場合がある。それ故、本技術によって、データユニット及び関連付けられているデータセグメントのこれらの部分の識別が可能になる。

ブロック６１４においてデータセグメントが識別されハッシュ値が取得された後、ブロック６１６において識別されたデータセグメントへのアクセスが提供されるようにローカルストレージを構成できる。このブロックは、最初に、様々なストレージロケーションで検索を実行して、特に識別されたデータセグメントのロケーションを判別することを含み、これは、識別されたデータセグメントのハッシュ値を、様々なストレージロケーションで利用可能なデータセグメントのハッシュ値と比較することを含む。一部の構成では、様々なロケーションにてデータセグメントのハッシュ値を動的に計算でき、他の構成では、様々なストレージロケーションにてデータセグメントのハッシュ値を予め計算できる。そのような構成では、これらのハッシュ値が、データセグメントとは別個のデータファイル内に記憶される場合もあれば、又はデータセグメントの内部に埋め込まれる場合もある。

検索されたロケーションに関しては、このロケーションに少なくともアクセスファイル内に指定されたロケーションが含まれる場合もあれば、一方、検索されたロケーションに、他のロケーションが含まれる場合もある。例えば、ローカルシステムの内部のストレージロケーションも検索可能である。しかしながら、この点に関して本技術は何らの制約も受けないため、他の任意の既定の検索対象ロケーション（ローカル及びリモートロケーションを含む）が含まれるように方法６００を構成できる。しかも、上述したように、ロケーションは、アクセスファイル内又はローカルシステム内に指定された事前定義済みの順序で検索できる。

ブロック６１６にはまた、上述した検索を実行することに加えて、ローカルシステム内で識別されたセグメントのコピーを一時的に又は永久に作成することによって、識別されたセグメントが取り込まれるようにローカルストレージを構成することを含めてもよい。本技術において、識別されたセグメントをローカルシステム内に記憶するためのロケーションは可変であり得る。一部の構成では、ローカルシステムのローカルストレージ内部において、ローカルシステム上、又は専用メモリロケーションなどの特化されたロケーション内のいずれかに存在するデータユニットと共に、識別されたセグメントを記憶できる。例えば、キャッシュ、又は識別されたセグメントを記憶するための他の予約メモリエリアを、ローカルシステムに含むこともできる。

ブロック６１６において、識別されたデータセグメントを含むようにローカルシステムが構成された後、方法はブロック６１８に進む。ブロック６１８において、続いて、ローカルシステム内のデータセグメントを使用して要求に供し得る。つまり、データユニット全体を利用可能にする必要なしに要求に見合ったデータが提供されるように、データセグメントからデータを抽出できる。その後、方法６００は引き続きブロック６１０に進み、前の処理（方法６００の繰り返しを含む）を再開する。

上で図６に関して説明したように、ローカルストレージ内のデータセグメントを使用して要求に供することが可能になる。しかしながら、データセグメントを介してデータユニットの実質部分が頻繁にアクセスされている場合は、ローカルシステム内でデータユニットを再アセンブルする方が高効率であることもあり得る。このプロセスは図７に示してある。図７は、本技術に従ってアクセスファイル及び関連付けられているデータセグメントをデータユニットに変換するための例示的な方法７００におけるステップのフローチャートである。ブロック７０２において方法７００が開始され、引き続きブロック７０４に進む。

ブロック７０４では、ローカルシステムに記憶されるデータユニットを選択する。上述したように、データユニットは、使用基準、例えば、データユニットに関連付けられているデータセグメントの使用頻度に基づいて選択できる。しかしながら、この点に関して本技術は何らの制約も受けないため、他の如何なる基準もデータユニットの選択に使用できる。例えば、ローカルシステムにおいて追加のスペースが利用可能な場合は、データセグメントを介さずに１つ以上のデータユニットをローカルに記憶できる。別の例において、データユニットをアーカイブするか又はコピーを作成する必要があることから、データユニットをアセンブルする必要が生じ得る。本技術では、データユニットを選択するための他の任意の基準もまた利用できる。

ブロック７０４においてデータユニットが選択された後は、ブロック７０６においてデータユニット用の全てのデータセグメントを取り出すことができる。この取り出しは、上で図６に関して説明したのと実質的に同様に実行できる。その後、全てのデータセグメントがローカルシステムにおいて利用可能になった後は、ブロック７０８においてデータセグメントを使用してデータユニットを再アセンブルできる。特に、セグメント化スキーム情報、メタデータ、及びアクセスファイル内の他の情報をデータセグメント内に存在する任意の情報と組み合わせて使用することで、データユニットが再アセンブルされるよう、適切な配列にてデータセグメントを配置できる。

ブロック７０８において、一旦データユニットがローカルシステムにて再アセンブルされた後は、続いてブロック７１０においてローカルシステムを構成できる。つまり、再アセンブル済みデータユニットをローカルシステムでメンテナンスすべき場合は、ブロック７１０において再アセンブル済みデータユニットを使用してデータユニットを利用するため今後の要求に供するようにローカルシステムを再構成できる。

任意選択的に、ブロック７１０において、再アセンブル済みデータユニットが利用されるようにローカルシステムが再構成された後、ブロック７１２においてアクセスファイル及び関連付けられているデータチャンクを削除してもよい。幾つかの事例では、この削除に、ローカルシステムにおいてはアクセスファイル及び関連付けられているデータチャンクを削除することが含まれる。故に、そのような構成では、リモートシステム内にデータユニットのアーカイブコピーがメンテナンスされる。あるいは、ローカルシステム及び１つ以上のリモートシステムの両方におけるアクセスファイル及び関連付けられているデータチャンクを削除することをブロック７１２に含むことができる。そのようにした結果、リモートシステム内のデータユニットのアーカイブコピーの削除が可能になる。しかしながら、幾つかの事例においては、削除を他での非アーカイブリモートシステムだけに制限することによって、データユニットがローカルシステムから不注意にも削除されるか、又はデータユニットの「クリーン」コピーが後でローカルシステムで必要になった場合に備えてファイルのバックアップコピーを提供できるようにしている。

上述したように、本技術に従って構成されたファイルシステムでは、従来方法と比較してスペース使用量が少ない文書版数管理システムが提供されている。この版数管理システムの動作については、以下に図８に言及しながら説明する。図８は、本技術によるデータユニット様々なバージョンを生成するための例示的な方法８００におけるステップのフローチャートである。

方法８００はブロック８０２にて開始し、ブロック８０４に進む。ブロック８０４では、ローカルシステムにコピーされた少なくとも１つのデータセグメントが更新されたことが、ファイルシステムに検出される。例えば、データセグメント内部のデータを変更するコマンドがユーザによって発行されたことが、ファイルシステムに検出される場合もあれば、あるいは、データセグメントに対するハッシュ値がアクセスファイルに準ずるハッシュ値にマッチしなくなったことが、ファイルシステムに検出される場合もある。データセグメントの変更を検出するための他の如何なる方法も、制限なしに使用できる。

ブロック８０４において、一旦データセグメントの変更が検出されると、方法８００はブロック８０６に進み、新しいバージョンのデータユニットを生成する。特に、ブロック８０６において、ファイルシステムは更新済みデータセグメント（１つ又は複数）を使用して、更新済みアクセスファイルを生成する。更新済みアクセスファイルは、元のデータセグメントに関連付けられているアクセスファイルに似ているが、この更新済みアクセスファイルは、更新済みデータセグメント（１つ又は複数）に対するハッシュ値に関する情報を含むように生成される。しかも、メタデータ又は更新済みアクセスファイルに対する他の情報は、更新済みアクセスファイルが元のアクセスファイル内の別のバージョンのデータユニットが参照されていることが反映されるように調整され得る。例えば、元のアクセスファイルを参照する情報を、更新済みアクセスファイル内に更に含めてもよい。

幾つかの事例においては、更新済みデータセグメントに応答して完全なアクセスファイルを生成するより寧ろ、更新済みデータセグメント（１つ又は複数）に基づいて新しいバージョンのデータユニットを生成する方法を指示する情報と、元のアクセスファイル内の情報と、を含むように更新済みアクセスを構成できる。つまり、元のアクセスファイルを識別する情報と、新しいバージョンのデータユニットにアクセスするためのデータセグメントを得るうえで必要な元のアクセスファイル内の変更内容を識別する情報と、を含むように更新済みアクセスファイルを構成できる。

更新済みアクセスファイルの構成に関係なく、ブロック８０６において更新済みアクセスファイルが一旦生成された後は、方法８００がブロック８０８に進む。ブロック８０８において、更新済みデータセグメントを、今後アクセスできるように、アクセスファイルに関連付けられているストレージロケーションに記憶してもよい。また、ブロック８０８には、更新済みアクセスファイルを共有環境内のリモートロケーションに記憶することを含めてもよい。つまり、アクセスファイルを他のユーザにアクセス可能なストレージロケーションに記憶しておけば、他のユーザが更新済みデータセグメントを介してアクセス更新済みデータユニットにアクセスできるようになる。

方法８００は、ブロック８０８の後に又はブロック８０８と並行して、ブロック８１０を実行できる。ブロック８１０において、ローカルシステムが更新済みアクセスファイルを使用して新しいバージョンのデータユニットに対する要求に供するように、ローカルシステムを再構成できる。ブロック８０８及び８１０の後、方法８００は任意選択的に、ブロック８１２に進み得る。元のデータユニットがもうローカルシステムで使用されなくなった場合、例えば、ユーザがローカルシステムで元のデータユニットを上書きする意思がある場合は、ブロック８１２において、元のアクセスファイルをローカルシステムから削除してもよい。同様に、更新済みデータセグメント（１つ又は複数）しか使用しない場合は、元のデータセグメントをローカルシステムから削除してもよい。最後に、方法８００はブロック８１４に進み、前の処理（方法８００の繰り返しを含む）を再開してもよい。

上述のデータセグメントスキームを用いてローカルストレージの容量拡張方法を提供する様々な実施形態について述べてきたが、この点に関して本技術は何らの制約も受けない。幾つかの実施形態においては、ローカルシステムパフォーマンスの増強を目的にデータセグメントが利用される場合もある。

多くの実例において、コンピューティングデバイスは、メモリデバイスに対するデータの読み取り又は書き込みに関して、データ転送速度、アクセス速度、又は他のデータアクセスメトリックがそれぞれ異なる多様な型式のメモリデバイスから構成できる。例えば、ソリッドステートドライブなどのソリッドステート記憶装置は典型的に、磁気ヘッド付きハードディスクドライブなどの磁気記憶装置よりもアクセス速度が顕著に高速である。しかしながら、ソリッドステートドライブのメガバイト当たりのコストは、磁気ヘッド付きハードディスクドライブのメガバイト当たりのコストよりも顕著に高くつくのが一般的である。それ故、多くの型式のコンピューティングデバイスにおいて、磁気ヘッド付きハードディスクドライブは、依然として一次的なストレージ媒体のまま変わりがない。

一方、多くの事例においては、コンピューティングデバイスによって使用されるデータの量が、磁気ヘッド付きハードディスクドライブのストレージの総容量よりも顕著に少ないことの方が一般的になっており、この点は注目に値する。故に、本技術の一態様は、複合ストレージが提供されるようにデータセグメントを利用することにある。そのような複合記憶装置の動作及び構成については、以下図９に言及しながら説明する。

図９は、本技術の代替実施形態に従って構成されたコンピューティングデバイス９００の概略図である。上述したように、コンピューティングデバイス９００は、第１の物理的デバイス９０４及び第２の物理的デバイス９０６を管理するファイルシステム９０２から構成され得る。説明の便宜上、第１の物理的デバイス９０４をアクセス速度が高速でストレージ容量が少ないストレージボリュームとする一方、第２の物理的デバイス９０６をアクセス速度が低速でストレージ容量が多いストレージボリュームとしている。例えば、第１の物理的デバイス９０４は磁気ディスクドライブであってもよく、第２の物理的デバイス９０６はソリッドステートディスクドライブであってもよい。

図９の例示的な実施形態は、ファイルシステムに関して記述しているが、これは図を分かり易くすることのみを目的としたものである。しかしながら、本明細書に記載の複数のストアデバイスは、制限なしに実質的に同じ様式にて、ファイルシステムレベル、ボリュームマネージャレベル、又は更にはデバイスドライバレベルで制御できる。

動作中に、データはコンピューティングデバイス９００により第２の物理的デバイス９０６内にセグメント化された形態でローカルに記憶される。そのようなデータセグメントの生成及び記憶は、上記の方法のいずれかに従って為され得る。第２の物理的デバイス９０６は上述のリモート記憶装置と実質的に同じ様式で動作する。結果として、第２の物理的デバイス９０６内に記憶されている一連の特定のデータセグメントに対して特定のデータユニットが関連付けられるように、ファイルシステム９０２を構成できる。

従来システムにおいては、コンピューティングデバイス９００が後になってから少なくともデータユニットの一部分を要求した場合、コンピューティングデバイス９００は、第２の物理的デバイス９０６内の適切なデータセグメントにのみアクセスする。しかしながら、様々な実施形態においては、そのようなアクセスを提供する代わりに、第１の物理的デバイス９０４に適切なデータセグメントをコピーする。更に、コピーされたデータセグメントに対する今後の要求が第１の物理的デバイス９０４により供されるように、ファイルシステム９０２を再構成することもできる。結果として、第１及び第２の物理的デバイス９０４並びに９０６は、単一の論理記憶装置９０８として動作し、データセグメントのコピーが第１の物理的デバイス９０４において作成されたかどうかに応じてデバイス９０４及び９０６のうちの一方からデータセグメントが取り出される。例えば、第１の物理的デバイス９０４からのデータユニット９１０に関連付けられているデータセグメントに対してアクセスが行えるように、かつ第２の物理的デバイス９０６からのデータユニット９１２に関連付けられているデータセグメントへのアクセスが行えるように、ファイルシステム９０２を構成することもできる。

更に重要なことには、コンピューティングデバイスは通例、多数のデータユニットに繰り返しアクセスしているため、より高速な第１の物理的デバイス９０４を介して対応するデータセグメントにアクセスすると、結果として、コンピューティングデバイス９００の全体的なパフォーマンスも向上する。

第１の物理的デバイス９０４のストレージ容量が枯渇した場合、記憶されているデータセグメントを上書き又は削除できる。上述したように、上書き又は削除可能なデータセグメントを選択する際には、如何なる種類のスキームも利用できる。そのような事例において、第１の物理的デバイス９０４内でデータセグメントの修正が発生しない場合は、単にデータセグメントを上書き又は削除して、第２の物理的デバイス９０６を介してデータセグメントへのアクセスが提供されるようにファイルシステム９０２を再構成することもできる。第１の物理的デバイス９０４内でデータセグメントに対して修正が発生した場合は、第１の物理的デバイス９０４内のデータセグメントを使用して第２の物理的デバイス９０６内の対応するデータセグメントを上書きできる。データセグメントを第２の物理的デバイス９０６に複製し直すとパフォーマンスに影響が及ぶ可能性があるが、典型的なコンピューティングデバイスにおいてアクセス対象データの実質部分（９０％以上）は変更されないままになるのが一般的である。それ故、ほとんどの場合、追加のコピー動作を必要とすることなしに、通例はデータセグメントの削除／上書きは更新済みファイルシステムに対する動作のみから構成される。

あるいは、第１の物理的デバイス９０４からの修正済みデータセグメント及び第２の物理的デバイス９０６内の対応するデータセグメントの両方を、第２の物理的デバイス９０６内でメンテナンスできる。そのような場合は、前述したように、この配列をファイルシステム９０２により利用することによって、様々なバージョンのデータユニットを記憶できる。本開示はまた、第１の物理的デバイス９０４内のデータセグメントの修正に応答して、修正済みのデータセグメントが自動的に第２の物理的デバイス９０６にコピーされ、第１の物理的デバイス９０４からデータセグメントを削除することなしに、様々なバージョンのデータユニットのストレージが提供され得ることを思量している。

図９の例示的な実施形態は、アクセス速度の違いについて記述してあるが、本技術による複合記憶装置は、データアクセスメトリック（データ転送速度、アクセス速度、又は他の関心対象の任意のメトリックを含む）が異なるデバイスに基づくものであり得る。

本開示は、上に図９に関して記載されている複合ストレージスキームを単独で、又は上で記載されている任意の技術と共に使用できることを思量する。つまり、データセグメントは、ローカル−ローカルベース、リモート−ローカルベース、又はその両方で利用できる。

これらの実施例に準ずる実施態様としては、他にも、コンピュータ実行可能命令を保持若しくは有するコンピュータ可読媒体、又はそのコンピュータ可読媒体に記憶されているデータ構造が挙げられる。そのようなコンピュータ可読媒体は、汎用コンピュータ又は特殊用途向けコンピュータによりアクセスできる利用可能な如何なる媒体であってもよい。一例として、また限定するものではなく、そのような有形のコンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、又は他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気記憶装置、ソリッドステートディスクストレージ、又はデータ構造の形で所望のプログラムコード手段を保持又は記憶するために使用することができる、その他任意の媒体が挙げられる。

コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、又は専用処理装置に特定の機能若しくは機能群を実行させる命令及びデータを含む。コンピュータ実行可能命令は、また、コンピュータによってスタンドアロン又はネットワーク環境で実行されるプログラムモジュールを含む。概して、プログラムモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、及び特定のタスクを実行するか又は特定の抽象データ型を実装するデータ構造を含み得る。コンピュータ実行可能命令、関連データ構造、及びプログラムモジュールは、本明細書に開示された方法のステップを実行するためのプログラムコード手段の例を表す。そのような実行可能命令の特定のシーケンス又は関連したデータ構造は、これらのステップで述べられた機能を実行するための対応する動作の例を表す。

当業者は、本発明のその他の実施形態が、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの又はプログラム可能な民生電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多くのタイプのコンピュータシステム構成を含むネットワークコンピューティング環境で実施されてもよいことを理解するであろう。実施形態は、また、通信ネットワーク経由で（有線接続、無線接続、又はこれらの組み合わせによって）結合されたローカル及びリモート処理装置によってタスクが実行される分散コンピューティング環境で実施されてもよい。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリ記憶装置に配置されてもよい。

記載されているシステムの様々なステージにおける通信は、ローカルエリアネットワーク、トークンリングネットワーク、インターネット、企業イントラネット、８０２．１１シリーズのワイヤレス信号、光ファイバネットワーク、無線伝送又はマイクロ波伝送などを介して実行できる。基盤となる通信技術は変遷していく可能性があるが、本明細書に記載されている基本的な原理は、依然として適用され得る。

以上述べた様々な実施形態は、説明のためにのみ提供されているものであって、限定的なものであると解釈すべきではない。当業者は、本開示の真の趣旨及び範囲から逸脱することなしに、本明細書に図示され説明された例示的な実施形態及び用途に従って為され得る様々な修正及び変更を容易に認識できるであろう。

Claims (20)

1. １つ以上のロケーションに、各々がデータユニットの別個の部分を表すデータセグメントを記憶するステップと、
   前記データセグメントの各々についてハッシュ値を計算するステップと、
   前記データユニットに対するメタデータと、前記データセグメントの構成を特定するセグメント化スキーム情報と、前記データセグメントに関連する前記ハッシュ値に用いられたハッシュスキームの種類を特定するハッシュスキーム情報と、前記データセグメントに関連する前記ハッシュ値を記述したハッシュ識別情報と、前記データセグメントが配置される１つ以上のリソースの前記１つ以上のロケーションを識別するロケーション情報と、を含むアクセスファイルをアセンブルするステップと、
   前記アクセスファイルを処理することにより、前記データセグメントを使用して前記データユニットに対する要求に供するようにファイルシステムを構成するステップと、を含む方法。
2. 前記データユニットを少なくとも１つの基準に基づいて選択するステップを更に含む、請求項１に記載の方法。
3. 前記少なくとも１つの基準が、前記データユニットに対するユーザのアクセス頻度に基づくものである、請求項２に記載の方法。
4. 前記データセグメントの各々が同じサイズに構成される、請求項１に記載の方法。
5. 前記ハッシュ識別情報が、前記データセグメントの前記ハッシュ値を含む、請求項１に記載の方法。
6. 前記ハッシュ識別情報が、前記ハッシュ値に基づく少なくとも１つの複合ハッシュ値を含む、請求項１に記載の方法。
7. ファイルシステムを含むコンピューティングデバイスを備え、前記ファイルシステムが、
   前記コンピューティングデバイス内に記憶されたデータユニットをデータセグメントに変換するステップと、
   前記データセグメントを１つ以上のロケーションに記憶するステップと、
   前記データセグメントの各々についてハッシュ値を計算するステップと、
   前記データユニットに対する要求に供するためのアクセスファイルをアセンブルするステップと、を含む複数ステップを遂行する前記コンピューティングデバイスを制御するように構成され、
   前記アクセスファイルが、前記データユニットに対するメタデータと、前記データセグメントの構成を特定するセグメント化スキーム情報と、前記データセグメントに関連する前記ハッシュ値に用いられたハッシュスキームの種類を特定するハッシュスキーム情報と、前記データセグメントに関連する前記ハッシュ値を記述するハッシュ識別情報と、前記データセグメントが配置される１つ以上のリソースの前記１つ以上のロケーションを識別するロケーション情報と、を含む、システム。
8. 前記ロケーションが、前記コンピューティングデバイスによって通信リンク経由でアクセス可能な１つ以上のリモートストレージロケーションを含む、請求項７に記載のシステム。
9. 前記コンピューティングデバイスが、前記アクセスファイルを記憶するための前記ファイルシステムによって管理される専用ストレージを含む、請求項７に記載のシステム。
10. 前記ファイルシステムは、少なくとも１つの基準に基づいて前記データユニットを選択するために前記コンピューティングデバイスを制御するように更に構成される、請求項７に記載のシステム。
11. 前記少なくとも１つの基準が、前記コンピューティングデバイスにおける前記データユニットのアクセス頻度に基づく、請求項１０に記載のシステム。
12. 前記ファイルシステムが、前記データセグメントを記憶するステップ及び前記アクセスファイルをアセンブルするステップに応答して、前記コンピューティングデバイスから前記データユニットをパージするように前記コンピューティングデバイスを制御するように更に構成される、請求項７に記載のシステム。
13. コンピューティングデバイスのコンピュータに、
    データユニットの少なくとも選択部分にアクセスする要求に応答して、前記データユニットに対応するアクセスファイルを取得し、前記データユニットのデータを含む１つ以上のデータセグメントを識別するステップと、
    少なくとも前記データユニットの前記選択部分に対応する前記データセグメントを識別して、識別されたデータセグメントを得るために前記アクセスファイルを処理するステップと、
    少なくとも前記識別されたデータセグメントを含むように前記コンピューティングデバイスのローカルストレージを構成するステップと、
    前記ローカルストレージ内のデータセグメントから抽出されたデータを使用して前記要求に供するステップと、を実行させるコンピュータプログラムであって、
    前記アクセスファイルが、前記データユニットに対するメタデータと、前記データセグメントの構成を特定するセグメント化スキーム情報と、ハッシュ値に用いられたハッシュスキームの種類を特定するハッシュスキーム情報と、前記データセグメントに関連する前記ハッシュ値を記述したハッシュ識別情報と、前記データセグメントが配置される１つ以上のリソースの１つ以上のロケーションを識別するロケーション情報と、を含む、コンピュータプログラム。
14. 前記取得するステップは、前記コンピューティングデバイスによって通信リンク経由でアクセス可能なリモートシステムから前記アクセスファイルを取り出すことを更に含む、請求項１３に記載のコンピュータプログラム。
15. 前記処理するステップが、前記メタデータ及び前記セグメント化スキーム情報に基づいて前記識別されたデータセグメントを判別することを更に含む、請求項１３に記載のコンピュータプログラム。
16. 前記構成するステップが、
    前記ハッシュスキーム情報及び前記ハッシュ識別情報に基づいて前記識別されたデータセグメントに対するハッシュ値を取得し、取得されたハッシュ値を形成し、
    前記取得されたハッシュ値に基づいて、前記識別されたデータセグメントのいずれかが前記ローカルストレージ内に存在しないかどうかを判別し、
    前記ローカルストレージ内に存在しない前記識別されたデータセグメントの各々について、前記アクセスファイル内に指定された前記ロケーションのいずれかから前記識別されたデータセグメントのうちの１つを取り出すこと、
    を更に含む、請求項１３に記載のコンピュータプログラム。
17. コンピューティングデバイスにおいてデータユニットの少なくとも選択部分に対する要求に応答して、前記データユニットに対するメタデータと、前記データユニットの１つ以上の異なる部分を定義するデータセグメントを記憶する１つ以上のロケーションを識別するロケーション情報と、前記データセグメントの構成を特定するセグメント化スキーム情報と、前記データセグメントに関連するハッシュ値に用いられたハッシュスキームの種類を特定するハッシュスキーム情報と、前記データセグメントに関連する前記ハッシュ値に基づくハッシュ識別情報と、を含むアクセスファイルを取得するステップと、
    少なくとも、前記データユニットの選択部分に対応する前記データセグメントを識別するステップと、
    少なくとも前記識別されたデータセグメントを含むように前記コンピューティングデバイスのローカルストレージを構成するステップと、
    前記ローカルストレージ内のデータセグメントから抽出されたデータを使用して前記要求に供するステップと、を含む方法。
18. 前記構成するステップが、前記ローカルストレージにおいて、前記識別されたデータセグメントのうちの１つ以上についてスペースが不十分であることに応答して、現在使用されていない１つ以上の他のデータセグメントを削除するステップを更に含む、請求項１７に記載の方法。
19. 前記他のデータセグメントは、前記コンピューティングデバイスにおける前記他のデータセグメントの少なくとも使用状況の履歴に基づいて削除対象として選択される、請求項１８に記載の方法。
20. 前記識別されたデータセグメントの使用状況が使用基準を満たす場合、コンピューティングデバイスにて前記データユニットを再アセンブルして再アセンブル済みデータユニットを形成し、前記再アセンブル済みデータユニットを使用して前記要求に供するステップ、を更に含み、前記データユニットは前記アクセスファイルに基づいて再アセンブルされる、請求項１７に記載の方法。

Images