JP5423896B2 - ストレージシステム - Google Patents

Description

本発明は、ストレージシステムにかかり、特に、重複排除機能を有するストレージシステムに関する。

重複排除は、必要な格納スペースを削減できるという点に最も価値があることは明らかだが、信頼性が向上し、また消費電力の削減と全体的な設備コストの低下により、運用上著しい節約ができるという効果もある。しかし、これらの節約を具体化するには、バックアップデータだけでなくあらゆるタイプのメタデータ（例えば、バックアップアプリケーションメタデータ、ファイルシステムや検索と重複排除に使用する適切なバックエンドメタデータ等の中間レベルのメタデータ）を保持するために必要な、トータルな格納スペースを検討する必要がある。画像へのメタデータの追加は、重複排除により実現できる節約を予測するために必要なだけではない。画像にメタデータが追加されると、特定のストレージシステムにおいて様々な重複排除の選択肢の相対的効用を変えることがよくある。

現在、重複排除を行うためにバックアップデータをチャンク（chunk）に分割する標準的な技術として、コンテンツ指定チャンク分割（ＣＤＣ：ＣｏｎｔｅｎｔＤｅｆｉｎｅｄＣｈｕｎｋｉｎｇ）（非特許文献１６，２０）がある。この技術は、Ｒａｂｉｎのフィンガープリント（非特許文献２２）を用いて、入力ストリーム内のチャンクの境界を選択し、様々な長さのチャンクを作成する。ＣＤＣには様々な利点がある。ＣＤＣはいかなる状態も維持することなく、またオリジナルのストリームにデータの挿入および削除がある場合に有効である。その理由は、変更されていない分割点を次回のチャンク分割実行時に読み出し、変更されていないチャンクを重複排除するために識別するからである。さらに、ＣＤＣではバックアップストリームの境界とそのシーケンスを知る必要がない。これは実際の商用セットアップに適している。標準的なバックアップアプリケーションは、通常「沈黙の」ストレージバックエンドを前提としており、これにより情報がバックエンドへ伝わらないからである。

EMC Corp. EMC Centera: content addressed storage system, January2008.http://www.emc.com/products/family/emccentera-family.htm?-openfolder=platform. ARONOVICH, L., ASHER, R., BACHMAT, E., BITNER, H., HIRSCH,M., ANDKLEIN, S. T. The design of a similarity based deduplication system. In SYSTOR’09: Proceedings of SYSTOR 2009: The Israeli Experimental Systems Conference(New York, NY, USA, 2009), ACM, pp. 1‐14. BARRETO, JO A., AND FERREIRA, P. Efficient file storage using content-basedindexing. In SOSP ’05: Proceedings of the twentieth ACMsymposium on Operatingsystems principles (New York, NY, USA, 2005), ACM, pp. 1‐9. BARRETO, JO A., AND FERREIRA, P. Efficient locally trackable deduplicationin replicated systems. In Middleware’09: Proceedings of the ACM/IFIP/USENIX10th international conference on Middleware (Berlin, Heidelberg, 2009),Springer-Verlag, pp. 103‐122. BHAGWAT, D., ESHGHI, K., LONG, D. D. E., AND LILLIBRIDGE, M. Extremebinning: Scalable, parallel deduplication for chunk-based file backup. BHAGWAT, D., POLLACK, K., LONG, D. D. E., SCHWARZ, T., MILLER, E.L., AND PARIS, J.-F. Providing high reliability in a minimum redundancyarchival storage system. InMASCOTS ’06: Proceedings of the 14th IEEEInternational Symposium on Modeling, Analysis, and Simulation (Washington, DC,USA, 2006), IEEE Computer Society, pp. 413‐421. BOBBARJUNG, D. R., JAGANNATHAN, S., AND DUBNICKI, C. Improvingduplicate elimination in storage systems. Trans. Storage 2, 4 (2006), 424‐448. COX, L. P., MURRAY, C. D., AND NOBLE, B. D. Pastiche:making backup cheap and easy. In OSDI ’02:Proceedings of the 5th symposium on Operating systems design and implementation(New York, NY, USA, 2002), ACM, pp. 285‐298. DUBNICKI, C., GRYZ, L., HELDT, L., KACZMARCZYK, M.,KILIAN, W., STRZELCZAK, P., SZCZEPKOWSKI,J., UNGUREANU, C., AND WELNICKI, M. Hydrastor: a scalable secondary storage. InFAST ’09: Proccedings of the 7th conference on File and storage technologies(Berkeley, CA, USA, 2009), USENIX Association, pp. 197‐210. KRUUS, E., UNGUREANU, C., AND DUBNICKI, C. Bimodal content definedchunking for backup streams. In FAST (2010), pp. 239‐252. KULKARNI, P., DOUGLIS, F., LAVOIE, J., AND TRACEY, J. M. Redundancyelimination within large collections of files. In ATEC ’04: Proceedings of theannual conference on USENIX Annual Technical Conference (Berkeley, CA, USA,2004), USENIX Association, pp. 5‐5. LEE, W., AND PARK, C. An adaptive chunking method for personal databackup and sharing, February 2010. 8th USENIX Conference on File and StorageTechnologies (FAST 10) poster session. LILLIBRIDGE,M., ESHGHI, K., BHAGWAT, D., DEOLALIKAR, V., TREZIS, G.,AND CAMBLE, P. Sparse indexing: Large scale, inline deduplication usingsampling and locality. In FAST (2009), pp. 111‐123. MANDAGERE, N., ZHOU, P., SMITH, M. A., AND UTTAMCHANDANI, S.Demystifying data deduplication. In Companion ’08: Proceedings of theACM/IFIP/USENIX Middleware ’08 Conference Companion (New York, NY, USA, 2008),ACM, pp. 12‐17. MEISTER, D., AND BRINKMANN, A. Multi-level comparison of datadeduplication in a backup scenario. In SYSTOR ’09: Proceedings of SYSTOR 2009:The Israeli Experimental Systems Conference (New York, NY, USA, 2009), ACM, pp.1‐12. MUTHITACHAROEN, A., CHEN, B., AND MAZIRES, D. A lowbandwidth networkfile system. In In Proceedings of the 18th ACM Symposium on Operating SystemsPrinciples (SOSP ’01 (New York, NY, USA, 2001), ACM, pp. 174‐187. NATH, P., URGAONKAR, B., AND SIVASUBRAMANIAM, A. Evaluating theusefulness of content addressable storage for high-performance data intensiveapplications. In HPDC ’08: Proceedings of the 17th international symposium onHigh performance distributed computing (New York, NY, USA, 2008),ACM, pp. 35‐44. PARK, K., IHM, S., BOWMAN, M., AND PAI, V. S. Supporting practicalcontent-addressable caching with czip compression. In ATC’07: 2007 USENIXAnnual Technical Conference on Proceedings of the USENIX Annual TechnicalConference (Berkeley, CA, USA, 2007), USENIX Association, pp. 1‐14. POLICRONIADES, C., AND PRATT, I. Alternatives for detecting redundancyin storage systems data. In ATEC ’04: Proceedings of the annual conference onUSENIX Annual Technical Conference (Berkeley, CA, USA, 2004), USENIXAssociation, pp. 6‐6. PORTS, D. R. K., CLEMENTS, A. T., AND DEMAINE, E. D. Persifs: aversioned file system with an efficient representation. In SOSP ’05:Proceedings of the twentieth ACM symposium on Operating systems principles (NewYork, NY, USA, 2005), ACM, pp. 1‐2. QUINLAN, S., AND DORWARD, S. Venti: a new approach to archivalstorage. In First USENIX conference on File and Storage Technologies (Monterey,CA, 2002), USENIX Association, pp. 89‐101. RABIN, M. Fingerprinting by random polynomials. Tech. Rep. TR-15-81(1981). RHEA, S., COX, R., AND PESTEREV, A. Fast, inexpensive content-addressedstorage in foundation. In Proceedings of the 2008 USENIX Annual TechnicalConference (Berkeley, CA, USA, 2008), USENIX Association, pp. 143‐156. SPRING, N. T., AND WETHERALL, D. A protocol-independent techniquefor eliminating redundant network traffic. SIGCOMM Comput. Commun. Rev. 30, 4(2000), 87‐95. TOLIA, N., KOZUCH, M., SATYANARAYANAN, M., KARP, B., BRESSOUD, T.,AND PERRIG, A. Opportunistic use of content addressable storage for distributedfile systems. In IN PROCEEDINGS OF THE 2003 USENIX ANNUAL TECHNICAL CONFERENCE (2003),pp. 127‐140. WEI, J., JIANG, H., ZHOU, K., AND FENG, D. Mad2: A scalable high-throughputexact deduplication approach for network backup services. In Proceedings of the26th IEEE Symposium on Massive Storage Systems and Technologies (MSST) (May2010). YOU, L. L., POLLACK, K. T., AND LONG, D. D. E. Deep store: Anarchival storage system architecture. In ICDE ’05: Proceedings of the 21stInternational Conference on Data Engineering (Washington, DC, USA, 2005), IEEEComputer Society, pp. 804‐8015. ZHU, B., LI, K., AND PATTERSON, H. Avoiding the disk bottleneck inthe data domain deduplication file system. In FAST’08: Proceedings of the 6thUSENIX Conference on File and Storage Technologies (Berkeley, CA, USA, 2008),USENIX Association, pp. 1‐14.

上述したＣＤＣで作成されたチャンクは様々な長さのものがあるが、実際のサイズはＣＤＣアルゴリズムのパラメータである想定チャンクサイズ値付近に集約される。ＣＤＣを用いる場合、あるバックアップストリームのシーケンスと特定のバックエンドについて、重複排除が最も機能する最適想定チャンク値がある。この値をどのように選択するかは、後続のストリームにおけるデータ修正のタイプと頻度、およびチャンク表示（representation）にかかるメタデータのオーバーヘッドによって異なる。

メタデータのオーバーヘッドを考えると、小さなチャンクを使用するのは最適ではない。また小さなチャンクはパフォーマンスに悪影響を及ぼす恐れもある。一方、大きなチャンクも、後続のバックアップにおける修正の粒度が細かい場合は最適ではない。妥協点として、所定のストレージシステムでうまく機能する、適度な大きさの想定チャンク値を選択するのが良いと思われる。ただし、（関連のない複数のシリーズのバックアップは言うまでもなく）１つのバックアップシーケンスでも変更の粒度は一定ではない。

このため、本発明の目的は、上述した課題である、データの重複排除のさらなる効率化を図ることができるストレージシステムを提供することにある。

本発明の一形態であるストレージシステムは、
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部と、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部と、を備えた、
という構成をとる。

また、本発明の他の形態であるプログラムを記憶した記憶媒体は、
情報処理装置に、
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部と、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部と、
を実現させるためのプログラムを記憶した記憶媒体である。

また、本発明の他の形態である情報処理方法は、
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行い、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行う、
という構成をとる。

本発明は、以上のように構成されることにより、データの重複排除のさらなる効率化を図ることができるストレージシステムを提供することができる。

実施形態１における新規ブロック出力時の様子を示す図である。 実施形態１におけるデータストリームを格納する時の様子を示す図である。 実施形態１における実験を行う対象となるデータ群を示す図である。 実施形態１における実験にて、平均ブロックサイズに対するデータのみのＤＥＲを示す図である。 実施形態１における実験にて、平均ブロックサイズに対する実ＤＥＲを示す図である。 実施形態１における実験にて、実ＤＥＲと前回のバックアップの読出しに必要なディスク動作数を示す図である。 実施形態１における実験にて、平均ブロックサイズを示す図である。 実施形態１における実験にて、平均チャンクサイズを示す図である。 実施形態１における実験にて、実ＤＥＲと様々なパラメータの関係を示す図である。 実施形態２におけるストレージシステムを含むシステム全体の構成を示すブロック図である。 実施形態２におけるストレージシステムの構成の概略を示すブロック図である。 実施形態２におけるストレージシステムの構成を示す機能ブロック図である。 図１２に開示したストレージシステムにおけるデータ記憶処理の様子を説明するための説明図である。 図１２に開示したストレージシステムにおけるデータ記憶処理の様子を説明するための説明図である。 図１２に開示したストレージシステムにおけるデータ読み出し処理の様子を説明するための説明図である。 図１２に開示したストレージシステムにおけるサブブロックデータの記憶処理の様子を示す図である。 図１２に開示したストレージシステムにおけるサブブロックデータの記憶処理の様子を示す図である。 図１２に開示したストレージシステムにおけるサブブロックデータの記憶処理の様子を示す図である。 本発明の付記１におけるストレージシステムの構成を示すブロック図である。

＜実施形態１＞
本実施形態では、ストレージシステムにおける重複排除の効率化を図るより良い方法を提案する。つまり、複数のバックアップにおいて、長期間に渡って変化しない長い一連のデータがあり、このようなデータには大きなサイズのチャンクの方が良い。その中に、変化のある領域が複数分散されており、これらは小さなサイズのチャンクの方が良い。

従って、本願では、アンカー駆動型サブチャンク重複排除という新たなアルゴリズムについて述べる。この新しいアルゴリズムは、大きいチャンクとそのサブチャンクとの２段階で重複排除を行う。小さなチャンクでの重複排除は、サブチャンクからコンテナチャンクへの変換（subchunk-to-container-chunk translations）における特別な重複排除コンテキスト（情報）を使用して行う。このコンテキストはバックエンドから読み出され、バックアップデータを書き込むプロセスで動的に更新される。このコンテキストは小さく、メインメモリに保存することができる。

この新たなアプローチは、バックアップストリームに関するバックエンドの知識を必要とせず、あらゆるストリームにおいて小さなチャンクを使用する重複排除を可能にする。同時に、このコンテキストは、小さなチャンクを使用する重複排除を効果的に行う上で必要な、ほとんどのサブチャンク変換（translations）を保持している。本願では、一連のバックアップトレースを使用してこの新たなアルゴリズムのシミュレーションを行い、その結果を、他のアルゴリズム、つまり従来のアルゴリズムを使用して得た様々な結果と比較することで、本願における主張を検証した。

以下、本実施形態では、次のことを説明する。まず、この新たな重複排除アルゴリズムについて詳細に説明する。次に、一連の実際のバックアップトレースに基づいて行ったシミュレーションに基づく評価を述べる。次に、関連技術について説明し、最後に、結論と今後の研究について記載する。

［アルゴリズム］
［システムモデル］
本願のストレージシステムは、非特許文献９に挙げたＨＹＤＲＡｓｔｏｒをモデルとして作成されている。ＨＹＤＲＡｓｔｏｒは、ファイルシステム抽象化（abstraction）をエクスポートするアクセスノード（ＡＮｓ）のフロントエンド構造と、多様なサイズのコンテンツアドレスブロックを保持するマルチノードブロックストレージ（store）としてのバックエンド構造と、により構成される。本願では、チャンクとデータのブロックとを区別する。チャンクは通常、連続する１つのユーザデータストリームであり、重複排除を最大限機能させるためにチャンク分割手段（chunker）によって定められる境界線を持つ。ブロックは、バックエンドにより格納される基本ユニットである。ブロックは、このブロックのチャンクである１つのユーザデータと、関連付けられたバックエンドレベルのブロックメタデータを含む。ただし、チャンクも、他のブロックへのポインタを含むことができる。ポインタはハッシュアドレスとして表され、ファイルシステム構成を維持するツリーの構築を促進する。

このシステムは、重複排除といったストレージシステムの特別な能力とは無関係な、標準的なバックアップアプリケーションを用いてバックアップの書込みと復元を行ういくつかのバックアップサーバからアクセスすることができる。このアルゴリズムについて議論する上では、上記のような拡張性を持つ分散型ストレージシステムを前提とする必要はない。ただし、様々な重複排除パターンを維持してバックアップを格納するためには、そのようなシステムの方が集約的なシステムよりも適している。そのため、すべての格納データに対して単一の想定チャンクサイズを使わない方がよい。なお、本発明にてストレージシステムで記憶するデータは、バックアップデータに限定されず、いかなるデータであってもよい。

基本システムでは、バックアップストリームは、ＣＤＣアルゴリズムを使用してアクセスノードでチャンクに分割され、ブロックとしてブロックストレージに書き込まれる。書き込まれたチャンクが重複しないと判断されると、そのチャンクは圧縮され、復元力（resiliency）のために冗長符号化され、得られたブロックフラグメントが別々のブロック格納サーバに格納される。なお、本システムでは、必ずしもデータを、分割、圧縮、冗長化しなくてもよい。

このシステムは、ブロック毎の参照カウントを含み、オンデマンドでのデータ削除機能を持つ。削除は２つのフェーズで行われ、ブロックカウンタを再計算するガーベジ識別のフェーズと、カウンタ値がゼロのブロックをバックグラウンドで除去するスペース再利用のフェーズがある。重複排除アルゴリズムを設計する際は、削除処理との相互作用を考慮する必要がある。

このようなシステムでは、重複排除アルゴリズムの評価に含めるべきメタデータの種類がいくつかある。最下位は、このブロックのコンテンツ由来アドレスを含むブロックメタデータで、次のレベルは、このブロックに属するポインタを含むメタデータである。また、更に高いレベルは、ファイルシステム構成と関連付けられたメタデータで、これには例えばｉｎｏｄｅテーブルなどがある。

ポインタを持つブロックが１つ失われると、複数のファイルまたはファイルシステム自体が不能になる場合がある（非特許文献６）。なぜなら、それらのブロックも重複排除される場合があるからである。したがって、すべてのシステムメタデータおよびポインタを持つブロックは、複数のコピーに保存される。ユーザデータについては、このシステムでは複数の冗長符号化された復元レベルに対応しており、ほとんどは非常に低いオーバーヘッドと復元レベルである。デフォルト値のオーバーヘッドは３３％で、３つのノードおよびディスク障害に耐えられる。

［複数のチャンクサイズを使用する重複排除］
複数のチャンクサイズを使用する重複排除に関する過去の２つの研究が、本願における研究の直接的な動機となった。

バイモーダル（bimodal）アプローチ（非特許文献１０）は、大小の２つのサイズのチャンクを使用する。デフォルトでは、新規のデータは大きいサイズのチャンクに分割される。さらに、重複しているチャンクと重複していないチャンクの間を移行する度に、１つまたは複数の隣接する大きなサイズのチャンクの新規データが小さなチャンクに分割され、これらの小さなチャンクがバックエンドに入力される。このアルゴリズムでは、小さなチャンク用のデータベースは必要ない。その代わりに、実際にどのチャンクを出力するか（emit）を決定する前に、バックエンドに対する既存のクエリーを用いて大きなチャンクの重複ステータスを確認する。

Ｆｉｎｇｅｒｄｉｆｆアルゴリズム（非特許文献７）は、データ群毎に、前回のバックアップで遭遇したが必ずしも出力されなかった、すべての小さなチャンクのデータベースを保持する。このデータベースは、バックエンドによって維持される、出力されたチャンクメタデータとは別に保持される。Ｆｉｎｇｅｒｄｉｆｆは、小さなサイズのチャンクのレベルで重複を検出し、可能な限りこれらを合体する（すべての新規データについて、小さなチャンクの最大可能数が限定されている）。

これらの２つのアプローチは改善の余地がある。バイモーダルアプローチは、重複排除された大きなチャンクに含まれる小さなチャンクの存在を忘れている。これは変化のある領域の境界線では特に重要である。Ｆｉｎｇｅｒｄｉｆｆアルゴリズムは、前回のバックアップで見られたすべての小さなチャンクの実質的なデータベースが必要だが、変化の少ないデータに関しては、これはあまり有益ではない。また、このデータベースはメインメモリに適合しない場合があり、もしそうであればパフォーマンスに深刻な影響を及ぼす。さらに、Ｆｉｎｇｅｒｄｉｆｆは、ストレージシステムがバックアップストリーム間の関係を特定できることを前提としているが、前述のようにそうではないことが多い。またＦｉｎｇｅｒｄｉｆｆは、関連性のないバックアップストリームにおいて、小さなチャンクのレベルでは重複を検出しない。

［サブチャンクを使用する重複排除］
本発明における「アンカー駆動型サブチャンク重複排除」という新たなアルゴリズムは、上記の従来のアプローチの欠点を解決する。

概略を説明すると、サブチャンクを使用する重複排除は次の通りである。基本の重複排除は比較的大きい想定チャンクサイズ（例えば６４ＫＢ）で行う。これは、良好なパフォーマンスを確実に行い、各ＳＮ上のローカルデータベースのサイズを管理可能な大きさに維持するためである。大きなサイズのチャンクが重複しないと判断されたら、そのサブチャンクについて重複排除を試みる。これらのサブチャンクは、より小さな想定ブロックサイズを用いてＣＤＣアルゴリズムを実行することにより、所定のチャンク内に定義される。例えば、想定チャンクサイズが６４ＫＢの場合、想定サブチャンクサイズが８ＫＢだとすると、１つのチャンク内に平均８つのサブチャンクが生成される。サブチャンクはブロックのメタデータをかなり共有しているため、分割されたサブチャンクを有するブロックのメタデータは、各サブチャンクが個別のブロックとして格納される場合よりもはるかに小さい。

また、サブチャンクからコンテナチャンクへの変換を含む新たなメタデータは、ブロックのメタデータほど高い復元力は必要ない。これらの変換は、ユーザデータと等しい復元力を伴って維持されれば十分である。これらの変換が消失した場合、考えられる最悪のケースは重複排除効果の低下であるが、その規模は非常に限定的である。その理由は、ユーザデータの復元力のレベルが大規模な障害が引き起こすことはまずないからである。

バックアップストリームを書き込む際、関連するサブチャンクからコンテナチャンクへの一連の変換のセットをアクセスノードに作成できるものとする。このセットを「サブチャンク重複排除コンテキスト」と言い、その詳細を以下に説明する。新規の重複しないチャンクの各サブチャンクについて、このアクセスノードに対してローカルなサブチャンク重複排除コンテキスト内の関連する変換を検索する。そのような変換があった場合、ブロックストレージに対して１つまたは複数の重複排除クエリーを発行して、そこにコンテナチャンクがまだ存在し要求されたサブチャンクを含むかどうかを確認する。このステップが必要な理由は、変換が陳腐化したものである可能性があり、ガーベジコレクションによって使用しないサブチャンクが削除される可能性があるからである。ブロックストレージの中に重複排除されるデータがある場合に限り、この変換によって生成されたアドレスでサブチャンクが重複排除される。

このプロセスで重複排除されないサブチャンクは、図１に示すように合体されて１つの大きなブロックとして出力される。その場合、個々のサブチャンク変換はコンテキストに追加される。つまり、新規ブロック出力の際には、図１に示すように近接する重複していない新規サブチャンク（ステータス：Ｎ）を合体して、サブチャンクｐ１とｐ２を指す２つのポインタを持つ単一のブロック出力となる。なお、ステータス：Ｎは、重複しているサブチャンクを示している。これについては以下に記載する。

「サブチャンク重複排除コンテキスト」
サブチャンクを含むバックアップストリームの重複排除を行う際、これまでに生成されたすべてのサブチャンクにアクセスする必要はない。その代わりに、このバックアップの以前のバージョンからのサブチャンクであって、バックアップストリーム内で現在の位置に「近接する」サブチャンクにアクセスすればよい。この観測を用いることによって、アクセスノード上に、サブチャンク重複排除コンテキストを、そのサブチャンクからコンテナチャンクへの変換を保持するローカルキャッシュとして構築する。

この重複排除コンテキストは、バックアップストリームを書き込む際に、いわゆるアンカーの助けを借りてオンザフライで構築される。アンカーとは、特別なタイプのブロックであり、図２に示すように、概念的に関連付けられた次の３つのアイテムを含む。すなわち、（１）書き込まれるバックアップストリーム内の隣接する大きなチャンクの短いシーケンス（１〜３）である「アンカーシーケンス」。（２）書き込まれるバックアップストリームの実質的な連続部分をカバーする「アンカーウィンドウ」。これらのウィンドウの大きさは通常数百ＭＢであり、バックアップストリーム全体は非連結アンカーウィンドウでカバーされる。（３）アンカーウィンドウ内の非重複サブチャンクを含む、サブチャンクからコンテナチャンクへの変換を含む「アンカーパック」。これらの変換は、出現するすべてのチャンクおよびサブチャンクのバックアップデータを書き込む際に作成される。

アンカーシーケンスは、バックアップストリーム内の固定数のチャンクで構成され、以下に定義する「特別なハッシュ値」は所定数の０の後続ビットを持つ。この「特別なハッシュ値」は、チャンク１つで構成されるアンカーシーケンスにおける通常のチャンクハッシュ値であり、このハッシュ値は、複数のチャンクで構成されるアンカーの各々のシーケンスチャンクの個々のハッシュ値のハッシュ値として定義される。なお、０である特別なハッシュ値のビット数でアンカーの頻度を制御し、ビットが少なければ少ないほどアンカーの頻度が多くなる。なお、アンカーシーケンスは、上述したようなチャンクで構成されていることに限定されず、他の特徴を有するチャンクにて構成されていてもよい。

アンカーウィンドウは、通常、バックアップストリーム内の、このウィンドウに関連付けられたアンカーシーケンスよりもかなり前方にある。その理由は、データの書込みと分割を行う前に必要な変換をフェッチするための十分な時間を確保するためである。新たなバックアップストリームではアンカーがなくなることがあるため、各アンカーは、図２の実線矢印に示すように、ウィンドウ変換へのポインタだけでなく、図２の点線矢印に示すいくつかの後続のウィンドウ用のアンカーパックへのポインタも含んでいる。

バックアップを書き込む一方、このアルゴリズムでは、現在のバックアップ用にアンカーを生成するのに加えて、以前に作成されたアンカーが検出されるかどうかを確認する。検出された場合、このアンカーからポインタで指されているすべてのパックは、重複排除コンテキストを構築するローカルキャッシュに読み込まれる。同時に、そのアンカーの新たな値を計算して出力し、古い値と交換する。

上述したｆｉｎｇｅｒｄｉｆｆとは異なり、アンカーは、ブロックストレージにグローバルに格納されているため、この重複排除はストリーム毎ではなくグローバルに行われる。したがって、異なるバックアップサーバまたは異なるクライアント（例えば、ワークステーションのバックアップの場合はオペレーティングシステムファイル）からのバックアップストリームの類似部分を特定することができる。

古いバックアップ内にあるアンカーシーケンスおよび関連付けられたアンカーウィンドウが新たなバックアップに変更されていない場合、新規のアンカーは古いものと同一となり、新規のアンカーは重複排除される。アンカーウィンドウ内のデータが変更されているのにアンカーブロックが修正されていない場合は、新規のアンカーが古いアンカーに上書きされて古いアンカーは回収される。また、定期的に（例えば週１回）すべてのアンカーを走査して、前回の走査以来、重複排除に全く利用されなかったアンカーを除去する必要がある。

ストレージのオーバーヘッドに関しては、アンカーパック全体で、ｆｉｎｇｅｒｄｉｆｆのバックアップ毎のデータベースに匹敵するスペースを占有する。大きな相違点は、アンカーパックは小さいため結合してメインメモリに適合する重複排除コンテキストを構築することができる一方、巨大なバックアップ用のｆｉｎｇｅｒｄｉｆｆのデータベースは大きくて、メインメモリには適合しない点である。また、ｆｉｎｇｅｒｄｉｆｆの場合、バックアップストリーム同士の関係やストリームの境界を知る必要があるが、アンカー駆動型のアプローチではこれらの知識は必要ない。

この新たなアプローチは、バイモーダルアプローチよりも広範囲に渡って重複データを検索することができる。バイモーダルアプローチとは異なり、この新たなアルゴリズムでは、非重複チャンクと重複チャンクの両方でこれまでに出現したサブチャンクを用いて重複排除のためのチェックを行う。これは、サブチャンク変換コンテキストにこれらのすべての変換が含まれるからである。バイモーダルアプローチでは、書き込まれるストリームの、少なくとも１つの重複チャンクに隣接する非重複チャンクのサブチャンクしかチェックしない。

［詳細および改良点］
基本システムでは、チャンク全体が圧縮されて冗長符号化される。サブチャンク重複排除では、個々のサブチャンクを読み出すことが可能でなければならない。そのためには、コンテナブロック全体を読み出して所望するサブチャンクを抽出すればよい。しかし、これはあまり効率的ではないため、個々のサブチャンクを圧縮して冗長符号化することを提案する。その結果、新たな「フラグメント」には、あるチャンクのすべてのサブチャンクのフラグメントが含まれる。そしてブロックメタデータを拡張し、チャンクフラグメント内のすべてのサブチャンクのフラグメントのオフセットを記憶する。

バックアップ削除後は、死んで除去が必要となるサブチャンクと、生きていて保存が必要なサブチャンクが発生する。そのため、死んだチャンクを特定してそのスペースを再利用するためにガーベジコレクションのアルゴリズムを変える必要がある。スペース再利用後にチャンク内サブチャンクの位置検索を促進するためには、どのオリジナルチャンクがまだ存在しているのかを示す各ブロックメタデータを有するビットベクトルを維持する必要がある。また、各サブチャンクは、サブチャンクの回収を可能にするために小さな参照カウンタ（数ビット）を取得する必要がある。このカウンタは小さくてよい。なぜなら、オーバーフローするという稀なケースでは、ブロック全体が回収されるまでサブチャンクは回収されないからである。

サブチャンクに基づく重複排除を可能にするために、サブチャンクセレクタでアドレスフォーマットを拡張する。サブチャンクセレクタは、様々な形式のものを使用することができる。一例として、単なるサブチャンクの順番がある。例えば、１つのチャンクに平均８つのサブチャンクがある場合、アドレスを４ビット拡張すれば、チャンク全体と１５個までの個々のサブチャンクに対応することができる。

可能な改良点の一例として、隣接するサブチャンクの合体がある。これは、大きなチャンクでは重複排除ができないが、複数の隣接するサブチャンクでは重複排除ができる場合に行う。これは変換のみに基づいて決定することができ、バックエンドへのクエリーを追加する必要はない。この場合、複数のサブチャンクを含む範囲に対してポインタを１つだけ生成する。これを可能にするためには、サブチャンクセレクタをサブチャンク範囲セレクタに変更する。サブチャンク範囲セレクタは２つのサブチャンクの番号を含み、上記の例ではアドレスを４ビットではなく１バイト拡張する。

［評価］
ここでは、以下に記載する３つのデータ群を用いて、本願で提案するサブチャンクアルゴリズム（以下「サブチャンク」と言う）を、上述したＣＤＣおよびバイモーダル手法と対比させて評価する。

実際のバックアップデータ上で直接動作させると非常に長い時間がかかるため、非特許文献１０に記載されている特別なチャンク分割ツールを用いて、圧縮バックアップトレースを生成した。このツールは潜在的なすべての分割ポイントと、その間のデータチャンクのハッシュ値を排除する。このような前処理によって、テストデータのサイズと評価時間が大幅に削減される。平均すると２０分未満で６０ＧＢのトレースを処理することができる。これは実際のデータでは１ＴＢに相当する。

あるデータ群とあるアルゴリズムについて、システムに格納されている全データのサイズを必要な全ディスクスペースで割った値を重複排除率（ＤＥＲ：ＤｕｐｌｉｃａｔｉｏｎＥｌｉｍｉｎａｔｉｏｎＲａｔｉｏ）と定義する。ＤＥＲはメタデータの有無にかかわらず計算できる。メタデータを含まないものを「データのみのＤＥＲ」と言い、メタデータを含むものを「実ＤＥＲ」という。

データのみのＤＥＲは簡易で十分に定義されている。実ＤＥＲとは異なり、実際のストレージシステムの特徴に依存しない。一方、実ＤＥＲの計算では、実際のシステムで必要なストレージに影響を与える、あらゆる要因が考慮される。これには、データ冗長性レベル、圧縮率、およびあらゆる種類のメタデータに必要なスペース等がある。実ＤＥＲの値は、実際のシステムモデルに大きく依存する。本願におけるモデルのメタデータのオーバーヘッドについては後述する。

［テストデータ］
図３に示す３つのデータ群に基づいて実験を行った。
Ｗｉｋｉデータ群は、英語版ウィキペディアの５つの正式なＸＭＬスナップショットで構成される。ファイルには通常のページの最新バージョンしか含まれず、変更履歴、特別ページ、画像などは含まれない。スナップショットが作成されるのは稀で、平均月１回である。バックアップの間隔が長く、バックアップ数が少ないこと、またｗｉｋｉデータの特徴（細かく頻繁に変更がある）により、このデータ群について測定される重複排除率は非常に低い。実ＤＥＲは、選択するアルゴリズムによって１．０６〜１．５２となる。

２つ目のデータ群であるｎｅｃｌａｂは一般的なバックアップデータを表している。これは、非特許文献１０で使用したものと同じデータ群であり、１４個のユーザディレクトリのウィークリーＮｅｔｗａｒｅバックアップで構成される。このデータ群について実際に測定されたＤＥＲは、３．１６〜３．７６である。

３つ目のデータ群であるｍａｉｌは、９ＬｉｖｅｓＤａｔａでの５２人のコンサルタントのメールボックスの、３２個のデイリースナップショットで構成される。これは非常に限定されたデータ群である。一般的なユーザのメールボックスは日々それほど変化があるわけではないため、このデータ群に関して測定される重複排除は非常に高いと思われる（バックアップ数に近い）。しかし、ユーザのメールボックスの１つのスナップショットは、通常数千もの非常に小さなファイル（１ファイル１メッセージ）を含むｔａｒアーカイブとして保存されている。ｔａｒアーカイブ内でのこれらのファイルの順序はｔａｒおよびファイルシステム内部の状態によって決まり、時々わずかに変化する。想定チャンクサイズが複数のファイルを含む場合は、その順序がわずかに置換しただけでも多くの重複排除アルゴリズムに悪影響を及ぼす可能性がある。さらに、データの順序が変わるとデータのフラグメント化が非常に高くなる可能性がある。このデータ群について実際に測定されたＤＥＲは１３．０８〜１８．３７である。

さらに、この３つのデータ群を連結して、人為的なデータ群である「合計データ」を生成した。このデータ群の実ＤＥＲは４．３５〜５．１９である。

［テストを行ったポリシ］
全てのアルゴリズムについて、考えられる様々な構成でテストを行った。最初のアルゴリズムであるＣＤＣについては、４ＫＢから２５６ＫＢまでのすべての２の乗数に設定された想定チャンクサイズでテストを行った。予想通り、ＣＤＣでは想定チャンクサイズ付近のサイズのチャンクが生成された。

上述したバイモーダルでは、大きなチャンクは想定サイズ８ＫＢから２５６ＫＢのものを、小さなチャンクは常にその８分の１のサイズのものを使用した。

本願で提案するアンカー駆動型の重複排除は、８ＫＢから２５６ＫＢまでのすべての２の乗数に設定された想定チャンクサイズで構成され、小さなチャンクの想定サイズは常に８分の１である。アンカー長は１チャンクに設定され、アンカーレベルは１０に設定された。つまり、アンカー間の平均距離は、２^１０＝１０２４チャンク（または８１９２の小さなチャンク）となる。キャッシュサイズは０．５ｍｌｎエントリ（約６４パックからの変換を格納可能）、プリフェッチは１６パック（実際のデータストリーム１ＧＢに相当）に設定された。このような構成により、このアルゴリズムによって達成されるＤＥＲと実行に必要なリソースとの間で合理的なバランスを取ることができる。

「完全キャッシュ」と言われるアルゴリズムは、「サブチャンク」アルゴリズムと類似しているが、アンカーに基づくメカニズムを使用するのではなく現れるすべての変換を直接キャッシュに入れるものであり、この場合、現れる変換は無限である。このアルゴリズムは現実的ではないが、これによる重複排除はサブチャンクのアプローチにとっては最大限のものである。

［データのみのＤＥＲを用いた比較］
図４は、平均ブロックサイズに対するデータのみのＤＥＲを示す。これは３つのデータ群とすべてのアルゴリズムに関するものである。各グラフは個別のデータ群を表し、各曲線は個別のアルゴリズム、各点は個別の構成（異なる想定チャンクサイズ）を表している。これらの表示は、望ましい重複排除アルゴリズムは高いＤＥＲを達成できるだけでなく大きな平均ブロックサイズが維持できるべきであるとの考えに基づくものである。これは、メタデータのオーバーヘッドとパフォーマンスのオーバーヘッドを許容されるレベルに維持するために必要である。平均ブロックサイズとは、システム内に格納されるすべてのユニークなブロックのサイズの合計を、ブロック数で割った値である（多くのバックアップストリームに単一のブロックがある場合でも１つとかぞえる）。これは後に詳細に説明する平均チャンクサイズとは異なる統計値である。

当然ながら、メタデータが含まれない場合はブロックサイズが小さいほど重複排除がよく機能する。ほとんどの場合、データのみのＤＥＲは平均ブロックサイズに対してほぼ直線となる。

本願で提案するアルゴリズムのパフォーマンスは、いかなるデータ群に関してもＣＤＣやバイモーダルよりも良い。大きな平均ブロックサイズを維持しつつ、（より小さな）サブチャンクレベルで重複排除を行うため、ＤＥＲが高くなる。完全キャッシュアルゴリズムの場合、これははっきりと示される。ＸＫＢのチャンクを用いてＣＤＣで達成される重複排除は、ＸＫＢのサブチャンクを用いて完全キャッシュアルゴリズムで達成される重複排除とほぼ等しい。この関係は、完全キャッシュアルゴリズムで用いる想定チャンクサイズにかかわらず成り立ち、想定サブチャンクのサイズのみの問題である。しかし、完全キャッシュアルゴリズムは、すべてのサブチャンクについての膨大なインデックスを維持する必要がある。それには多くのリソースが必要であるため、簡単には実装できない。

本願で提案するアルゴリズムで達成されるＤＥＲは、プリフェッチ変換に使用するアンカーに基づくメカニズムのパフォーマンスに大きく依存する。アンカーがよく機能すればするほど重複排除も高くなる。以上のように、アンカーに基づくサブチャンク重複排除は完全キャッシュアルゴリズムとかなり類似するが、プリフェッチ変換に関して、アンカーに基づくメカニズムは適切に機能することがわかる。アンカーに基づくメカニズムで発見された重複サブチャンク数を、完全キャッシュアルゴリズムで発見された重複サブチャンク数で割った値を、キャッシュヒット率と定義する。確かに、基本構成（６４ＫＢのチャンクと８ＫＢのサブチャンク）では、キャッシュヒット率は非常に高い（ｗｉｋｉデータ群では８１％、ｎｅｃｌａｂでは８７％、ｍａｉｌでは９９％）。

ｎｅｃｌａｂデータについては、予想通りＣＤＣよりもバイモーダルの方がよく機能する。これは非特許文献１０で使用されたデータ群であり、我々の実験結果はこれと一致する。驚いたことに、他のデータ群に関しては、バイモーダルで達成されたＤＥＲはＣＤＣで達成されたＤＥＲよりもわずかに低い。これは、ランダムな場所で数多くの小さな変化がある場合に見られる。大きなチャンクは、重複チャンクと隣接する場合にのみ小さなチャンクに再分割される。あるブロックが、１つのバックアップ内でチャンクに分割され次のバックアップストリームで変更がない場合、このブロックは、重複排除される機会を失わないように毎回再分割されなければならない。このような状況は、ｎｅｃｌａｂのトレースではあまり発生しないが、ｗｉｋｉとｍａｉｌではよく発生する。そのため、バイモーダルのパフォーマンスは少し低かった。

［実ＤＥＲを用いた比較］
あらゆる種類のメタデータが含まれる場合、状況は著しく異なる。上記で説明したシステムモデルでは、各ブロックは冗長符号化され、１２個のフラグメントとして格納される。ほとんどのデータは、オリジナルのフラグメントが９個で、冗長フラグメントが３個であるが、ポインタ付きのブロックは１２個のコピーに保存される。圧縮レベルはブロックサイズの対数の線形関数としてグローバルに予測される（６４ＫＢのブロックについては約０．７７、８ＫＢのブロックについては約０．８０）。格納される各ブロックは、それに関連付けられる１２４バイトのメタデータを含む。高いパフォーマンスと障害からの復元力を持つために、メタデータはすべて１２個のコピーに格納されるため、メタデータのオーバーヘッドは１ブロック当たり１３４４バイトとなる。実際のシステムでは、ポインタ付きのブロックも重複排除されるため、（特に小さなブロックでは）メタデータのオーバーヘッドは少なくなるが、このモデルでは、ポインタ付きブロックは重複排除されないという最悪のシナリオのみをエミュレートする。そのため、バックアップストリーム内の各チャンクにはポインタがなければならない（このチャンクが重複しているかどうかは関係ない）。また、すべてのポインタも１２個のコピーに格納される。

サブチャンクアルゴリズムでは、変換パックを格納するための追加のスペースが必要である。１つの変換は、サブチャンク（２０バイト長）のＳＨＡ−１、インデックス、およびチャンク全体のＳＨＡ−１を含む。チャンク全体のＳＨＡ−１は通常、いくつかの変換で共有されるため、１つの変換は容易に３２バイトにおさまる。変換パックは低い復元力で格納することができる。データが消失した場合、ＤＥＲはチャンク全体のＣＤＣのレベルまでわずかに低下するが、システムは完全に機能する。したがって、本願における実験では、アンカーパックの復元力はユーザデータの復元力と同じであると仮定した。

図５は、システム内に格納された平均ブロックサイズに対する実ＤＥＲを示す。ＤＥＲの計算にすべての種類のメタデータが含まれる場合、ブロックサイズが小さくなると、ある時点までは重複排除率が高くなるが、その後はメタデータの格納に必要なスペースが、重複排除によって得られるスペースを上回る。

各データ群および各アルゴリズムについて、実ＤＥＲが最も高くなると思われる最適なブロックサイズがある。任意のアルゴリズム（メタデータのオーバーヘッドを低下させていないもの。通常これは簡単な作業ではない）では、より良いＤＥＲを得ることはできない。当然、最適なブロックサイズは選択するデータ群によって大きく異なる。様々なデータ群について異なる想定チャンクサイズを使用するには、追加の手動構成が必要となり、グローバルな重複排除が損なわれる恐れがある。その理由は、異なる分割ポリシでチャンクに分割されている２つのストリーム間では重複を発見できないからである。

ＣＤＣでは、最適な想定チャンクサイズは、ｗｉｋｉについては８ＫＢ（ＤＥＲ＝１．２０）、ｎｅｃｌａｂについては１６ＫＢ（ＤＥＲ＝３．１８）、ｍａｉｌについては３２ＫＢ（ＤＥＲ−１４．８９）である。これらの全データ群における平均チャンクサイズとしては、１６ＫＢが合理的な選択であろう。人為的な合計データ群ではＤＥＲ＝４．３９である。

バイモーダルは、ｎｅｃｌａｂのデータ群に関しては良好なパフォーマンスを見せた。３２ＫＢの大きなチャンクと４ＫＢの小さなチャンクについて、ＤＥＲは３．３８であった（ＣＤＣより６％改善された）。しかし、ｗｉｋｉ（３２ＫＢの大きなチャンクではＤＥＲ＝１．０７）とｍａｉｌ（６４ＫＢの大きなチャンクではＤＥＲ＝１３．１４）では、悪かった。合計データ群では、大きなチャンクの想定サイズを３２ＫＢにするのが最善の選択である。

本願で提案するサブチャンクアルゴリズムでは、著しく高いパフォーマンスが達成された。ｗｉｋｉデータ群の場合、最適な平均ブロックサイズは１６ＫＢで、ＤＥＲ＝１．５０となり、最適なＣＤＣよりも２５％改善した。ｎｅｃｌａｂデータ群については、最適な平均ブロックサイズは３２ＫＢで、ＤＥＲ＝３．６７となり、ＣＤＣよりも１５％改善した。また、ｍａｉｌデータ群についても、最適なサブチャンクアルゴリズムは６４ＫＢのブロックを使用してＤＥＲ＝１８．４５であり、最適なＣＤＣよりも２４％改善した。合計データ群については、想定ブロックサイズが６４ＫＢの場合に最も良いパフォーマンスとなった（ＤＥＲ＝５．０６、ＣＤＣより１５％改善）。チャンクのサイズを非常に小さくすると、サブチャンクアルゴリズムのパフォーマンスは低下してＣＤＣに近くなり、ｍａｉｌのトレースではＣＤＣよりも低くなった。その理由は、小さなチャンク（例えば８ＫＢ）ではサブチャンクが非常に小さくなる（例えば１ＫＢ）ため、平均ブロックサイズが非常に短くなりメタデータが膨大になるからである。

［読出し性能］
バックアップデータの重複排除を行うと、連続するストリームではなく、データが多数の小さなチャンクとしてシステム全体に散らばって格納される場合がある。このようなフラグメント化された状態では、読み出す際のディスク動作（検索）が多くなる。

一般的に、拡張性の高いストレージシステムは多数のリソースを保有しており、ディスクの検索が増えてもパフォーマンスに悪影響を与えることはない。特に、同時に１つまたはわずかなストリームを読み出すのであれば問題ない。しかし、重複アルゴリズムを設計する際には、そのアルゴリズムがデータのフラグメント化に与える影響を評価する必要がある。データのフラグメント化は広範囲に及ぶ主題であり、そのほとんどは本願の対象外であるが、本願が提案するアルゴリズムが他のアルゴリズムよりもフラグメント化に関して悪い結果をもたらすものではないことを示すために、基本的な評価の結果を提供する。

ディスク読出し性能を評価するために、ストレージシステムのモデルを簡略化し、すべてのブロックが単一の物理的ディスクに位置する１つの連続ファイルに格納されていると仮定している。新規の（重複しない）ブロックはすべてファイルの最後に書き込み、重複するブロックは単純にスキップする。このモデルではメタデータを格納することは考えない。本願では読出しを以下のようにシミュレートした。すなわち、ブロックは、バックアップストリームに現れる順序で一つずつ要求される。ブロックがディスクからフェッチされると、読出し動作を拡張して後続する複数のブロックも読み出す。１回の想定読出しサイズは２５６ＫＢである。この制限に適合するブロックはすべて読出しキャッシュにロードされ、次のブロックは、その半分がこの制限に適合する場合に限りロードされる（少し変だが、この条件はプリフェッチされたブロックが「切り捨てられる」問題を防ぐことができる）。キャッシュのサイズは１ＧＢに制限される。ブロックがすでにキャッシュ内にある場合は、追加のＩＯ動作を行う必要はない。前回の（最もフラグメント化された）バックアップの読出しに必要なＩＯ動作の総数を、フラグメント化の一つの指標として使用する。

サブチャンクアルゴリズムの場合、このモデルは多少異なる。同じ戦略に従って行うが、大きなブロックではなくサブチャンクを使用して実行する。その理由は、ブロック表示が変更されているおかげで個々のサブチャンクを読み出すことができるからである。

すべてのアルゴリズムを比較するために、実ＤＥＲに関する最適な設定を選択した（サブチャンクアルゴリズムでは大きなチャンクが６４ＫＢで小さなチャンクが８ＫＢ，バイモーダルでは３２ＫＢと４ＫＢ、ＣＤＣでは１６ＫＢ）。図６は、前回の（最もフラグメント化された）バックアップの読出しに必要なディスク動作数に対する、各アルゴリズムの実ＤＥＲを示す。

結果はデータ群によって大きく異なる。ｎｅｃｌａｂについては、サブチャンクアルゴリズムはフラグメント化が最も低く実ＤＥＲが最も高い、最高の結果が出た。このトレースは一般的なバックアップデータを反映しているため、これは良い結果である。一般的に、重複排除とフラグメント化はトレードオフの関係にある。重複排除率が高ければフラグメントが多くなるのだが、例外があることがわかった。

ｍａｉｌとｗｉｋｉのトレースについては、サブチャンクアルゴリズムでのフラグメント化は常に他の２つのアルゴリズムでのフラグメント化の中間であるが、実ＤＥＲは常に最も高い。これらのトレースについては、フラグメント化を犠牲にして重複排除が改善されている。

読出し性能に影響を与える可能性がある別の要因は、システム内に格納されている全データストリームの合計サイズをポインタの総数で割った、平均チャンクサイズである。平均チャンクサイズの計算では、平均ブロックの計算とは異なり、重複が複数回数えられる。平均チャンクが短いということは、同量のデータに対して、より多くの数のポインタを格納し処理する必要があることを意味する。

図７は、各アルゴリズムにおける最適な例について、およびバイモーダルについてはさらに６４ＫＢの大きなチャンクについての、平均ブロックサイズを表し、図８は、その平均チャンクサイズを表している。この例はバイモーダルが効果的であることを示している。その理由は、６４ＫＢの大きなチャンクでのバイモーダルは、最適なバイモーダルよりもわずかしか重複排除率が下がらないが、平均ブロックサイズと平均チャンクサイズが著しく大きくなるからである。しかし、重複排除率が最も高いサブチャンクの例が、ほとんどのケースで６４ＫＢのチャンクのバイモーダルよりも大きい平均ブロックサイズおよび平均チャンクサイズを示している。

サブチャンクアルゴリズムでは、デフォルトで大きなチャンクを出力するようにし、そのチャンクの残りが重複排除された場合にのみ、大きなチャンクよりも少ないデータ量を含むブロックを生成する。バイモーダルは、最初の効果についてはサブチャンクアルゴリズムと同様だが、バイモーダルは後で重複排除を行う際に使用することを期待して変化の境界線に小さなブロックを出力するため、２つ目の効果は得られない。しかし、このような予想が実現するとは限らない。その結果、サブチャンクアルゴリズムでは、ＣＤＣやバイモーダルで生成されるものよりもはるかに大きな平均サイズのブロックが生成される。また、サブチャンクを指すポインタがあるため、他の２つのアルゴリズムと比べて、サブチャンクアルゴリズムの場合は平均ブロックサイズと平均チャンクサイズと間に大きな差がある。

［構成の調整］
ここでは、サブチャンクアルゴリズムの基本構成（上記で説明した想定チャンクサイズ６４ＫＢ）からパラメータを１つ変更することによって、実ＤＥＲにどのような影響を与えるのかについて説明する。プロットを簡略化するために、合計のデータ群についてのみ述べる。通常、各データ群に関する結果もほぼ同じである。その結果を、図９の実ＤＥＲと様々なパラメータの関係に示す。

最初に調整するパラメータはアンカー長、つまりアンカーを構成する連続するチャンクの数である。驚くことに、単一のチャンクから作成されたアンカーが最も良い結果となった。その理由は、実ＤＥＲは使用するチャンク数の対数に対して線形に低下するためである。アンカーが短いほど、その後のバックアップで変化がないことが多い。これは、適切な変換パックをダウンロードするのに必要である。

次に調整するパラメータはアンカーレベルである。アンカーレベルがｎに等しいとは、アンカー間の想定距離が２^ｎチャンクに等しいことを意味する。アンカーレベルを変更すると、常に実データ１ＧＢに相当する変換をプリフェッチするよう、プリフェッチするパック数も調整される。アンカーを数多く設定すると重複排除の性能も高くなるが、各アンカーが読出しおよび書込み動作を生成するため、アンカーが多すぎると性能が低下する。我々はアンカーレベル１０を使用することに決定した。その結果、アンカー間の想定距離は６４ＫＢのブロックに対して６４ＭＢとなった。

また、プリフェッチするパック数も修正した。一般的に、プリフェッチの長さを長くすると重複排除の性能が高まる。最高値の突然の低下は、変換キャッシュプルーニング（pruning）によってもたらされる。このキャッシュはキューとして機能し、プリフェッチのサイズが大きいと、必要な変換が使用前にキャッシュから除外される。このような場合は、キャッシュサイズを大きくすればよいと思われるため、より大きなキャッシュで実験をしたが、結果はそれほど改善されたわけではなく、妥当なサイズとして１ＧＢのプリフェッチを維持した。

さらに、他の想定サイズのサブチャンクでも実験を行ったが、それほど大きな改善は見られなかった。

構成の調整の他に、このアルゴリズムにいくつか修正を加えてテストを行った。最初のテストは、余剰ブロック（重複しないサブチャンクで構成されるブロック）の合体である。各チャンクごとに１つの余剰ブロックを出力するのではなく、いくつかを合わせて単一のブロックを出力することができる。このような修正はＤＥＲに影響を与えることはほとんどない。その理由は、余剰ブロックは非常に稀で重複することはまずないからである。しかし、大きな平均ブロックサイズを維持することができる。

もう１つのテストは、１つのチャンク内のサブチャンク数を制限することである。デフォルトのチャンク分割構成では最大サブチャンク数は２４だが、想定サブチャンク数は８である。我々のシステムが一定サイズのメタデータ記録を必要とする場合、これはスペースの無駄になる。実際にサブチャンクがあるかどうかにかかわらず、各サブチャンク用に約３Ｂを取っておく必要があるからだ。しかし、ある限度を超えるすべてのサブチャンクを合体させることができる。実験により、サブチャンク数を１２に制限すると重複排除にわずかな影響が出る（合計データ群で、データのみのＤＥＲが６．０１から５．９５に低下）が、１６に制限すると全く影響がない（データのみのＤＥＲの低下は０．０１未満）ことがわかった。

［関連技術］
前述のｆｉｎｇｅｒｄｉｆｆとバイモーダルのチャンク分割に加えて、重複排除全般、特にチャンク分割に関連する様々な論文がある。

Ｅｘｔｒｅｍｅ ｂｉｎｎｉｎｇ（非特許文献５）は、単一サイズのチャンク分割を用いて類似するファイル内の重複を探し出す、効果的で拡張性のある技術である。しかし、この技術は代表チャンクを計算するためにファイルコンテンツ全体の知識を必要とするため、ストリーミングデータに直接適用することはできない。

Ｓｐａｒｓｅ ｉｎｄｅｘ（非特許文献１３）はｅｘｔｒｅｍｅ ｂｉｎｎｉｎｇと類似しており、入力チャンクをセグメントに分割して選択されたセグメントチャンクに対して重複排除を行うことにより、ストリーミングデータに適用される。これは、複数のレベルのチャンク分割を用いてより粒度の細かい重複検出を行う技術は採用していない。

Ａｄａｐｔｉｖｅ ｃｈｕｎｃｋｉｎｇ方式（非特許文献１２）は、可動装置での必要な処理能力を最小限に抑えるためにＣＤＣと固定サイズチャンク分割とを切り替える、興味深いアイデアである。

ＥＭＣ Ｃｅｎｔｅｒａ（非特許文献１）はコンテンツアドレスを重複排除に利用できることを初めて証明した製品の１つである。しかし、すべてのファイルについてコンテンツアドレスを計算するので、サブファイルの重複排除を行うことはできない。

Ｖｅｎｔｉ（非特許文献２１）はアーカイバルファイルシステムにおける重複排除用のＣＡＳを初期に採用したものである。固定サイズのブロックを使用するため、シフトされたコンテンツの重複排除を行うことはできない。

ＭＡＤ２（非特許文献２６）、ＨＹＤＲＡｓｔｏｒ（非特許文献９）、およびＤＤＦＳ（非特許文献２８）は、ＣＤＣチャンク分割とコンテンツアドレスストレージを使用する、実装されているシステムの例である。Ｆｏｕｎｄａｔｉｏｎ（非特許文献２３）は、コンテンツアドレスストレージを用いて、夜間のスナップショットにおけるハードディスク全体のバージョンを効果的に格納し重複排除を行う。

ＲＥＢＬ（非特許文献１１）は、コンテンツ指定チャンク分割を用いる重複排除とデルタ符号化および圧縮を組み合わせて、実現しうる最高の圧縮率を得る。Ｐａｓｔｉｃｈｅ（非特許文献８）は、コンテンツ指定チャンク分割、コンテンツアドレス、およびコンテンツに基づく暗号化を用いて、ピアツーピア（peer-to-peer）ネットワークにおけるクライアントシステムのバックアップの安全性を確保する一方、共有チャンクを検出して各チャンクにつき１つのコピーのみを格納することでストレージのオーバーヘッドを制限する。

ＣＺＩＰ（非特許文献１８）は、チャンク分割と汎用のＣＡＳを用いる一般的な圧縮ファイルフォーマットであり、例えば、コンテンツ分配サーザ、ファイル転送、またはウェブキャッシングに利用される。

非特許文献２４に記載されるネットワークトラフィック冗長性排除スキームは、Ｒａｂｉｎのフィンガープリントの代表的なセットを使用してネットワーク通信における重複の可能性があるコンテンツの領域を検索する。これは、この論文に記載したアンカーと類似するところがある。

ＬＢＦＳ（非特許文献１６）は、ネットワークのリンク上での帯域幅の使用に制限を加えるために、コンテンツ指定チャンク分割とコンテンツ検証をネットワークファイルシステムに適用する例を示している。Ｒａｂｉｎのフィンガープリントを使用してファイルをチャンクに分割し、その結果得られるＲａｂｉｎのハッシュによって重複の可能性があるものを検索する一方、ＳＨＡ−１を用いてチャンクが本当に同じコンテンツかどうか、最終確認を行う。ＣＡＳＰＥＲ（非特許文献２５）は、ＣＡＳデータが入手可能な場合に低速リンクでのファイルシステムアクセスを高速化するためにＣＡＳを便宜的に利用する例を示している。
ＲｅｄＦＳ分散型ファイルシステム（非特許文献４）は、ファイルグループに対する局所的重複排除と、レプリカと言われるグループのベクトルに基づく類似するファイルグループの検索とを組み合わせて、分散されたレプリカ間でのデータ転送を最小限にする。

ＰｒｏｔｅｃＴｉｅｒシステム（非特許文献２）は、代表的なＲａｂｉｎのフィンガープリントを採用し、大きなブロックのデータに対してコンテンツアドレスではなく類似性マッチングを用いて重複排除を行う。これにより、重複排除用の非常に小さなインデックスを格納することができる。

コンテンツポインタを合体させる思想は、部分コンテンツ共有ファイルシステムの実装に関する技術で提案されている（非特許文献３）。この技術では、チャンクのメタデータのオーバーヘッドを最小限にするために、類似性検出に基づくオフライン重複排除を用いて、ファイルの共有部分に対してのみチャンク分割と重複排除を行う。

非特許文献１５と非特許文献１９は、実在のデータに対するＣＤＣおよび他の技術を用いた重複排除での可能なゲインの分析について記載している。文献１４は、様々な重複排除技術に関する賛否を包括的に比較し、重複排除率、メタデータのオーバーヘッド、および再構築時間のトレードオフについて述べている。

ＤｅｅｐＳｔｏｒｅ（非特許文献２７）は、重複排除におけるＣＡＳとデルタ圧縮の効果を比較し、重複排除されたデータの信頼性について述べている。非特許文献６では、重複排除を行った結果として、より少数のデータのチャンクを格納することに対する信頼性についても分析している。非特許文献１７は、複数の種類のデータ間の共通性を探す上でのチャンクサイズの効果、メタデータのオーバーヘッドがスペースの節約に与える影響、およびＣＡＳストレージに１回しかチャンクを格納しないことによる回復力の低下、について述べている。

［結論と今後の研究］
本願では、動的にプリフェッチされる限られたサイズのサブチャンク重複排除コンテキストによって駆動されるサブチャンク重複排除アルゴリズムを提案した。このコンテキストは、サブチャンクレベルでの効果的な重複排除に必要なほとんどの変換を提供する。さらに、コンテキスト入力変換は、あまり重要でないメタデータとして、つまり復元力の低いオーバーヘッドとして、格納することができる。また、この新たなアルゴリズムは、可能な場合はすべてのチャンクを使用することによって有効なメタデータのオーバーヘッドを削減し、同じチャンクに属するサブチャンク間でほとんどのメタデータを共有する。その結果、多量のメタデータのオーバーヘッドを含むシステムでは、サブチャンクアルゴリズムは従来のＣＤＣまたはバイモーダル等の他のアプローチと比べて実ＤＥＲが優れており、また平均ブロックサイズおよびチャンクサイズが非常に大きい。同時に、標準的なバックアップトレースについては、この新たなアルゴリズムはフラグメント化が少ない。それ以外のデータストリームについては、フラグメントが多くなる場合もあるが、これは重複排除率を改善するためのコストである。

今後は、より多くのバックアップトレースを使用してこの新たなアルゴリズムを評価し、また重複排除率を著しく低下させることなくフラグメント化の問題に対処する方法を詳細に研究することを計画している。

＜実施形態２＞
本発明の第２の実施形態を、図１０乃至図１８を参照して説明する。図１０は、システム全体の構成を示すブロック図である。図１１は、ストレージシステムの概略を示すブロック図であり、図１２は、構成を示す機能ブロック図である。図１３乃至図１８は、ストレージシステムの動作を説明するための説明図である。

ここで、本実施形態では、ストレージシステムが、複数台のサーバコンピュータが接続されて構成されている場合を説明する。但し、本発明におけるストレージシステムは、複数台のコンピュータにて構成されることに限定されず、１台のコンピュータで構成されていてもよい。

図１０に示すように、本発明におけるストレージシステム１０は、ネットワークＮを介してバックアップ処理を制御するバックアップシステム１１に接続している。そして、バックアップシステム１１は、ネットワークＮを介して接続されたバックアップ対象装置１２に格納されているバックアップ対象データ（記憶対象データ）を取得し、ストレージシステム１０に対して記憶するよう要求する。これにより、ストレージシステム１０は、記憶要求されたバックアップ対象データをバックアップ用に記憶する。なお、ストレージシステム１０は、必ずしもバックアップ対象データを記憶することに限定されず、いかなるデータを記憶してもよい。

そして、図１１に示すように、本実施形態におけるストレージシステム１０は、複数のサーバコンピュータが接続された構成を採っている。具体的に、ストレージシステム１０は、ストレージシステム１０自体における記憶再生動作を制御するサーバコンピュータであるアクセラレータノード１０Ａと、データを格納する記憶装置を備えたサーバコンピュータであるストレージノード１０Ｂと、を備えている。なお、アクセラレータノード１０Ａの数とストレージノード１０Ｂの数は、図１１に示したものに限定されず、さらに多くの各ノード１０Ａ，１０Ｂが接続されて構成されていてもよい。

さらに、本実施形態におけるストレージシステム１０は、データを分割及び冗長化し、分散して複数の記憶装置に記憶すると共に、記憶するデータの内容に応じて設定される固有のコンテンツアドレスによって、当該データを格納した格納位置を特定するコンテンツアドレスストレージシステムである。このコンテンツアドレスストレージシステムについては、後に詳述する。

なお、以下では、ストレージシステム１０が１つのシステムであるとして、当該ストレージシステム１０が備えている構成及び機能を説明する。つまり、以下に説明するストレージシステム１０が有する構成及び機能は、アクセラレータノード１０Ａあるいはストレージノード１０Ｂのいずれに備えられていてもよい。なお、ストレージシステム１０は、図１１に示すように、必ずしもアクセラレータノード１０Ａとストレージノード１０Ｂとを備えていることに限定されず、いかなる構成であってもよく、例えば、１台のコンピュータにて構成されていてもよい。さらには、ストレージシステム１０は、コンテンツアドレスストレージシステムであることにも限定されない。

図１２に、ストレージシステム１０の構成を示す。この図に示すように、ストレージシステム１０は、データを記憶する記憶装置３１，３２と、当該記憶装置３１，３２に対するデータの記憶及び読み出し動作を制御する制御装置２０と、を備えている。そして、制御装置２０は、記憶対象データとなるストリームデータをブロックデータ単位で記憶再生するブロックデータ処理部２１と、上記ブロックデータをさらに複数に分割したサブブロックデータ単位で記憶再生するサブブロックデータ処理部２２と、を備えている。また、記憶装置３１，３２として、ブロックデータやサブブロックデータを記憶するハードディスクドライブなどの補助記憶装置３１と、後述するサブアドレスデータを記憶する主記憶装置３２と、を備えている。なお、ここでは、記憶するデータに応じて格納先となる記憶装置を分けて記載しているが、いかなる記憶装置であってもよく、同じ記憶装置であってもよい。

なお、実際には、上記ブロックデータ処理部２１とサブブロックデータ処理部２２とは、図１１に示したアクセラレータノード１０Ａ及びストレージノード１０Ｂが備えているＣＰＵ（Central Processing Unit）などの複数の演算装置にプログラムが組み込まれることで構成されている。また、補助記憶装置３１は、主に図１１に示したストレージノード１０Ｂが備えている補助記憶装置にて構成されており、主記憶装置３２は、主に図１１に示したアクセラレータノード１０Ａ及びストレージノード１０Ｂが備えている主記憶装置にて構成されている。

なお、上記プログラムは、例えば、ＣＤ−ＲＯＭなどの記憶媒体に格納された状態でストレージシステム１０に提供される。あるいは、上記プログラムは、ネットワーク上の他のサーバコンピュータの記憶装置に記憶され、当該他のサーバコンピュータからネットワークを介してストレージシステム１０に提供されてもよい。

以下、上記ブロックデータ処理部２１と上記サブブロックデータ処理部２２の構成について詳述する。はじめに、ブロックデータ処理部２１（ブロックデータ重複排除部）によるコンテンツアドレス方式のブロックデータ単位におけるストリームデータの記憶及び読み出し方法を、図１３乃至図１５を参照して説明する。

まず、ブロックデータ処理部２１は、図１４の矢印Ｙ１に示すように、ストリームデータであるバックアップ対象データＡの入力を受けると、図１３及び図１４の矢印Ｙ２に示すように、当該バックアップ対象データＡを、可変容量（例えば、平均６４ＫＢ）あるいは所定容量（例えば、６４ＫＢ）のブロックデータＤに分割する。そして、このブロックデータＤのデータ内容に基づいて、当該データ内容を代表する固有のハッシュ値Ｈ（内容識別情報）を算出する（矢印Ｙ３）。例えば、ハッシュ値Ｈは、予め設定されたハッシュ関数を用いて、ブロックデータＤのデータ内容から算出する。なお、ブロックデータ処理部２１による処理は、アクセラレータノード１０Ａにて実行される。

そして、上記ブロックデータ処理部２１は、バックアップ対象データＡのブロックデータＤのハッシュ値Ｈを用いて、当該ブロックデータＤが既に記憶装置３１に格納されているか否かを調べる。具体的には、まず、既に格納されているブロックデータＤは、そのハッシュ値Ｈと格納位置を表すコンテンツアドレスＣＡが、関連付けてＭＦＩ（Ｍａｉｎ Ｆｒａｇｍｅｎｔ Ｉｎｄｅｘ）ファイルに登録されている。従って、ブロックデータ処理部２１は、格納前に算出したブロックデータＤのハッシュ値ＨがＭＦＩファイル内に存在している場合には、既に同一内容のブロックデータＤが格納されていると判断できる（図１４の矢印Ｙ４）。この場合には、格納前のブロックデータＤのハッシュ値Ｈと一致したＭＦＩ内のハッシュ値Ｈに関連付けられているコンテンツアドレスＣＡを、当該ＭＦＩファイルから取得する。そして、このコンテンツアドレスＣＡ（アドレスデータ）を、記憶要求にかかるブロックデータＤのコンテンツアドレスＣＡとして記憶する。あるいは、既に格納されているブロックデータＤを参照するコンテンツアドレスＣＡをさらに参照する他のアドレスデータをツリー構造にて記憶する。これにより、このコンテンツアドレスＣＡにて参照される既に格納されているデータが、記憶要求されたブロックデータＤとして使用されることとなり、当該記憶要求にかかるブロックデータＤは記憶する必要がなくなる。

また、ブロックデータ処理部２１は、は、上述したように重複チェック部２３にてまだ記憶されていないと判断されたブロックデータＤを圧縮して、図１４の矢印Ｙ５に示すように、複数の所定の容量のフラグメントデータに分割する。例えば、図１３の符号Ｄ１〜Ｄ９に示すように、９つのフラグメントデータ（分割データ４１）に分割する。さらに、ブロックデータ処理部２１は、分割したフラグメントデータのうちいくつかが欠けた場合であっても、元となるブロックデータを復元可能なよう冗長データを生成し、上記分割したフラグメントデータ４１に追加する。例えば、図１３の符号Ｄ１０〜Ｄ１２に示すように、３つのフラグメントデータ（冗長データ４２）を追加する。これにより、９つの分割データ４１と、３つの冗長データとにより構成される１２個のフラグメントデータからなるデータセット４０を生成する。なお、上記ブロックデータ処理部２１による処理は、１つのストレージノード１０Ｂによって実行される。

そして、ブロックデータ処理部２１は、上記フラグメント生成部２４にて生成されたデータセットを構成する各フラグメントデータを、記憶装置３１に形成された各記憶領域に、それぞれ分散して格納する。例えば、図１３に示すように、１２個のフラグメントデータＤ１〜Ｄ１２を生成した場合には、１２個の記憶装置３１内にそれぞれ形成したデータ格納ファイルＦ１〜Ｆ１２（データ格納領域）に、各フラグメントデータＤ１〜Ｄ１２を１つずつそれぞれ格納する（図１４の矢印Ｙ６参照）。

また、ブロックデータ処理部２１は、上述したように記憶装置３１に格納したフラグメントデータＤ１〜Ｄ１２の格納位置、つまり、当該フラグメントデータＤ１〜Ｄ１２にて復元されるブロックデータＤの格納位置を表す、コンテンツアドレスＣＡを生成して管理する。具体的には、格納したブロックデータＤの内容に基づいて算出したハッシュ値Ｈの一部（ショートハッシュ）（例えば、ハッシュ値Ｈの先頭８Ｂ（バイト））と、論理格納位置を表す情報と、を組み合わせて、コンテンツアドレスＣＡを生成する。そして、このコンテンツアドレスＣＡを、ストレージシステム１０内のファイルシステム、つまり、アクセラレータノード１０Ａに返却する（図１４の矢印Ｙ７）。すると、アクセラレータノード１０Ａは、バックアップ対象データのファイル名などの識別情報と、コンテンツアドレスＣＡとを関連付けてファイルシステムで管理する。

また、ブロックデータ処理部２１は、ブロックデータＤのコンテンツアドレスＣＡと、当該ブロックデータＤのハッシュ値Ｈと、を関連付けて、各ストレージノード１０ＢがＭＦＩファイルにて管理する。このように、上記コンテンツアドレスＣＡは、ファイルを特定する情報やハッシュ値Ｈなどと関連付けられて、アクセラレータノード１０Ａやストレージノード１０Ｂの記憶装置３１に格納される。

さらに、ブロックデータ処理部２１は、上述したように格納したバックアップ対象データを読み出す制御を行う。例えば、ストレージシステム１０に対して、特定のファイルを指定して読み出し要求があると（図１５の矢印Ｙ１１参照）、まず、ファイルシステムに基づいて、読み出し要求にかかるファイルに対応するハッシュ値の一部であるショートハッシュと論理位置の情報からなるコンテンツアドレスＣＡを指定する（図１５の矢印Ｙ１２参照）。そして、ブロックデータ処理部２１は、コンテンツアドレスＣＡがＭＦＩファイルに登録されているか否かを調べる（図１５の矢印１３参照）。登録されていなければ、要求されたデータは格納されていないため、エラーを返却する。

一方、読み出し要求にかかるコンテンツアドレスＣＡが登録されている場合には、上記コンテンツアドレスＣＡにて指定される格納位置を特定し、この特定された格納位置に格納されている各フラグメントデータを、読み出し要求されたデータとして読み出す（図１５の矢印Ｙ１４参照）。このとき、各フラグメントが格納されているデータ格納ファイルＦ１〜Ｆ１２と、当該データ格納ファイルのうち１つのフラグメントデータの格納位置が分かれば、同一の格納位置から他のフラグメントデータの格納位置を特定することができる。

そして、ブロックデータ処理部２１は、読み出し要求に応じて読み出した各フラグメントデータからブロックデータＤを復元する（図１５の矢印Ｙ１５参照）。さらに、ブロックデータ処理部２１は、復元したブロックデータＤを複数連結し、ファイルＡなどの一群のデータに復元して、読み出し制御を行っているアクセラレータノード１０Ａに返却する（図１５の矢印Ｙ１６参照）。

次に、上記サブブロックデータ処理部２２（サブブロックデータ重複排除部）について、図１６乃至図１８を参照して説明する。なお、以下では、上述したブロックデータ処理部２１との関わりについても説明する。

まず、図１６に示すように、バックアップ対象データであるバックアップストリームが記憶される場合には、このバックアップストリームに対して、上述したようにブロックデータ処理部２１にてブロックデータＢへの分割が行われ、重複記憶排除を行いながら記憶装置３１への記憶処理が実行される。加えて、サブブロックデータ処理部２２は、以下の処理を行う。

まず、サブブロックデータ処理部２２は、バックアップストリームの一部である予め設定された個数からなる一連のブロックデータＢの特徴値を算出し、この特徴値が予め設定された条件を満たすと、その一連のブロックを「アンカーシーケンス」と設定する。例えば、図１６の斜線に示すように、３つのブロックデータＢのハッシュ値を特徴値として算出し、この特徴値の下３桁のビット「０」となるなど設定条件を満たしたときに、これら３つのブロックデータを「アンカーシーケンス」とする。そして、図１６に示すように、「アンカーシークエンス」が参照する「アンカー」を生成し、当該「アンカー」には「アンカーパック」と呼ばれるデータ格納領域へのポインタを格納する。つまり、設定条件を満たした特徴値となる「アンカーシーケンス」が検出されると、その特徴値と「アンカーパック」とが関連付けられて記憶される。

そして、サブブロックデータ処理部２２は、上述したように「アンカーシーケンス」を検出すると、これに隣接するブロックデータＢ、つまり、検出されたアンカーシーケンスが属するアンカーウインドウ内のブロックデータＢを、さらに複数に分割して各サブブロックデータＳＢを生成する。例えば、ブロックデータＢのデータ容量が６４ｋＢである場合に、当該ブロックデータＢを複数のサブブロックデータＳＢに分割する（例えば、平均して８ｋＢの８つのサブブロックデータＳＢに分割する）。また、サブブロックデータ処理部２２は、各サブブロックデータのデータ内容に基づく値としてハッシュ値をそれぞれ算出して、これらハッシュ値を、各サブブロックデータを参照するポインタに対応付ける。そして、サブブロックデータ処理部２２は、各サブブロックデータを記憶装置３１に格納すると共に、各サブブロックデータを参照する各ポインタと各ハッシュ値との対応付けを、検出した「アンカーシーケンス」に関連付けられた「アンカーパック」内に順次格納する。ここでは、アンカーパックに格納されるサブブロックデータを参照するポインタとハッシュ値との対応付けを、当該サブブロックデータの格納先を表すサブアドレスデータとする。但し、サブブロックデータのハッシュ値自体を、当該サブブロックデータを参照するアドレスデータとしてもよい。なお、「アンカーパック」は、主記憶装置３２に格納される。

また、サブブロックデータ処理部２２は、上述したように「アンカーシーケンス」を検出し、この「アンカーシークエンス」の特徴値が既に主記憶装置３２に存在する場合には、当該特徴値に関連付けられ既に主記憶装置３２に格納されている「アンカーパック」を読み出し、サブブロックデータの重複記憶排除処理を行う。具体的には、バックアップストリームのブロックデータを分割したサブブロックデータのハッシュ値（サブアドレスデータ）と、読み出した「アンカーパック」内のサブアドレスデータと、を比較して、同一の値がある場合には、サブブロックデータは既に記憶装置３１に記憶されており、重複していると判定する。従って、「アンカーパック」内のサブアドレスデータを、バックアップストリームのサブブロックデータとして参照して記憶し、重複記憶を排除する。一方、バックアップストリームのブロックデータを分割したサブブロックデータのハッシュ値（サブアドレスデータ）が、読み出した「アンカーパック」内にない場合には、サブブロックデータを新たに記憶装置３１に記憶し、このサブブロックデータのハッシュ値を当該サブブロックデータを参照するサブアドレスデータとして「アンカーパック」内に記憶する。

なお、上述したブロックデータをサブブロックデータに分割して行う重複記憶排除は、上記ブロックデータ処理部２１にて重複排除されなかったブロックデータに対してのみ行ってもよい。

ここで、上述したサブブロックデータの重複記憶排除処理の具体例を、図１７、図１８を参照して説明する。

まず、何もデータが記憶されていない状態で、「バックアップストリーム１」がストレージシステム１０に記憶されたとする。このとき、各ブロックデータが記憶装置３１に記憶されると共に、各ブロックデータのハッシュ値に基づく当該ブロックデータを参照するアドレスデータが記憶される。これと同時に、所定個数のブロックデータの特徴値が算出され、特徴値が設定条件を満たす「アンカーシーケンス」を検出すると、これに関連付けた「アンカーパック」を主記憶装置３２に生成する。そして、「アンカーシーケンス」に隣接するブロックデータを各サブブロックデータに分割して補助記憶装置３１に格納すると共に、各サブブロックデータのハッシュ値を算出して、これを各サブブロックデータを参照するサブアドレスデータとして、「アンカーパック」に順次格納する。

続いて、上記「バックアップストリーム１」の更新データとして、「バックアップストリーム２」がストレージシステム１０に記憶されたとする。すると、まず、「バックアップストリーム２」を順次ブロックデータに分割し、ブロックデータ単位にて重複記憶排除処理を行う。ここでは、符号Ｂ１’に示すブロックデータのみ、データ内容が更新されたとする。すると、ブロックデータＢ１’は記憶装置３１に記憶されていないため、ブロックデータ単位での重複記憶排除は行われない。但し、本願では、ブロックデータＢ１’に対して、サブブロックデータ単位で重複記憶排除が実行されることとなる。

上述したように「バックアップストリーム２」がブロックデータ単位で処理されると同時に、所定個数のブロックデータの特徴値が算出され、特徴値が設定条件を満たす「アンカーシーケンス」を検出し、かかる特徴値が既出のもの、つまり、主記憶装置３２に既に記憶されているか否かを調べる。検出した「アンカーシーケンス」の特徴値が既に記憶されている場合には、その特徴値に関連付けられた主記憶装置３２内の「アンカーパック」を読み出す。つまり、ここでは、「バックアップストリーム１」の時に格納された「アンカーパック」が読み出され、この中には、ブロックデータＢ１を分割した各サブブロックデータのハッシュ値がサブアドレスデータとして格納されている。

また、上述したように「バックアップストリーム２」の「アンカーシーケンス」を検出すると、この検出した「アンカーシークエンス」に隣接するブロックデータをサブブロックデータに分割して、そのハッシュ値を算出する。特に、この処理は、上述したようにブロックデータ単位で重複記憶排除が行われなかったブロックデータＢ１’について行われる。そして、算出したサブブロックデータＢ１’のハッシュ値と、上記読み出した「アンカーパック」内のサブアドレスデータと、を比較して、同一の値があるか否かを調べる。同一の値がある場合には、対応するサブブロックデータは既に記憶装置に記憶されているため、「アンカーパック」内のサブアドレスデータを、格納するサブブロックデータとして参照する。一方、同一の値がない場合には、対応するサブブロックデータを新たに記憶装置３１に格納し、そのハッシュ値を格納したサブブロックデータを参照するサブアドレスデータとして、「アンカーパック」に含める。

例えば、図１８に示すように、ブロックデータ単位で重複記憶排除が行われなかったブロックデータＢ１’のうち、そのサブブロックデータＳＢのいくつかがサブブロックデータ単位で既に記憶されており（符号Ｄ）、網掛けで示すいくつかのサブブロックデータＳＢ（Ａ，Ｂ，Ｃ，Ｄ）が記憶されていない場合には（符号Ｎ）、これら複数のサブブロックデータ（Ａ，Ｂ，Ｃ，Ｄ）をまとめた状態でサブブロックデータが格納される。これにより、これらサブブロックデータを参照するメタデータを削減することができる。

以上より、ブロックデータ単位のみでなく、サブブロックデータ単位で重複記憶排除を行った場合には、ブロックデータＢ１’の全てが記憶される場合を比較して、重複記憶排除の効率の向上を図ることができる。また、このとき、サブブロックデータが既に記憶されているか否かを調べるために用いる「アンカーパック」内のサブアドレスデータは、補助記憶装置３１よりも記録再生速度が高速な主記憶装置３２内に記憶されているため、サブブロック単位での重複記憶排除処理の高速化を図ることができる。但し、「アンカーパック」は、補助記憶装置３１に記憶してもよく、いかなる記憶装置に記憶してもよい。

また、上記「アンカーパック」は、所定のタイミングで（例えば、定期的に）、一旦、削除してもよい。これにより、使用されなくなったサブブロックデータを参照するサブアドレスデータを削除することができ、主記憶装置３２の記憶容量の肥大化を抑制することができる。

ここで、本実施形態では、「アンカーシーケンス」に対応する「アンカー」が参照する「アンカーパック」は、複数設定される。例えば、図１６に示すように、符号Ａ，Ｂに示す「アンカー」に対応する「アンカーシーケンス」が順に検出された場合には、符号Ａの「アンカー」は、対応する「アンカーパック」を参照して関連付けられることはもちろんのこと（実線矢印参照）、この他にも、次に検出された符号Ｂの「アンカー」に対応する「アンカーパック」をも参照して関連付けられる（点線矢印）。これにより、検出された「アンカーシーケンス」の位置に近接するサブブロックデータの「アンカーパック」に容易にアクセスすることができるため、重複データの発見がより容易となる。

＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム（図１９参照）、プログラムを記憶した記憶媒体、情報処理方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。

（付記１）
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部１０１と、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部１０２と、を備えた、
ストレージシステム１００。

（付記２）
付記１に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記ブロックデータ重複排除部にて重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
ストレージシステム。

（付記３）
付記１に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
ストレージシステム。

（付記４）
付記３に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから検出した前記特徴値が前記所定の記憶装置に既に記憶されている場合に、当該特徴値に関連付けられて既に記憶されている前記サブアドレスデータ群と、前記特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを形成する前記各サブブロックデータを参照する前記サブアドレスデータ群と、を比較して、前記サブブロックデータの重複記憶排除を行う、
ストレージシステム。

（付記５）
付記４に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記サブアドレスデータ群の比較により、記憶装置に記憶されていない前記サブブロックデータが複数存在する場合に、当該複数のサブブロックデータをまとめて記憶装置に記憶する、
ストレージシステム。

（付記６）
付記３に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記設定条件を満たす特徴値に、複数の前記サブアドレスデータ群を関連付けて前記所定の記憶装置に記憶する、
ストレージシステム。

（付記７）
付記２に記載のストレージシステムであって、
前記サブブロックデータ重複排除部は、前記設定条件を満たす特徴値に関連付けた前記サブアドレスデータ群を、前記ブロックデータ及び前記サブブロックデータを記憶する記憶装置よりも読み書き速度が速い前記所定の記憶装置に記憶する、
ストレージシステム。

（付記８）
情報処理装置に、
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを前記記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部と、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部と、
を実現させるためのプログラムを記憶した記憶媒体。

（付記９）
付記８に記載のプログラムを記憶した記憶媒体であって、
前記サブブロックデータ重複排除部は、前記ブロックデータ重複排除部にて重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
ことを実現させるためのプログラムを記憶した記憶媒体。

（付記１０）
付記８に記載のプログラムを記憶した記憶媒体であって、
前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
ことを実現させるためのプログラムを記憶した記憶媒体。

（付記１１）
データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを前記記憶装置に格納して前記ブロックデータの重複記憶排除を行い、
前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行う、
情報処理方法。

（付記１２）
付記１１に記載の情報処理方法であって、
重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
情報処理方法。

（付記１３）
付記１２に記載の情報処理方法であって、
前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
情報処理方法。

Claims (13)

1. データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部と、
   前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部と、を備えた、
   ストレージシステム。
2. 請求項１に記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記ブロックデータ重複排除部にて重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
   ストレージシステム。
3. 請求項１又は２に記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
   ストレージシステム。
4. 請求項３に記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから検出した前記特徴値が前記所定の記憶装置に既に記憶されている場合に、当該特徴値に関連付けられて既に記憶されている前記サブアドレスデータ群と、前記特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを形成する前記各サブブロックデータを参照する前記サブアドレスデータ群と、を比較して、前記サブブロックデータの重複記憶排除を行う、
   ストレージシステム。
5. 請求項４に記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記サブアドレスデータ群の比較により、記憶装置に記憶されていない前記サブブロックデータが複数存在する場合に、当該複数のサブブロックデータをまとめて記憶装置に記憶する、
   ストレージシステム。
6. 請求項３乃至５のいずれかに記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記設定条件を満たす特徴値に、複数の前記サブアドレスデータ群を関連付けて前記所定の記憶装置に記憶する、
   ストレージシステム。
7. 請求項３乃至６のいずれかに記載のストレージシステムであって、
   前記サブブロックデータ重複排除部は、前記設定条件を満たす特徴値に関連付けた前記サブアドレスデータ群を、前記ブロックデータ及び前記サブブロックデータを記憶する記憶装置よりも読み書き速度が速い前記所定の記憶装置に記憶する、
   ストレージシステム。
8. 情報処理装置に、
   データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行うブロックデータ重複排除部と、
   前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行うサブブロックデータ重複排除部と、
   を実現させるためのプログラム。
9. 請求項８に記載のプログラムであって、
   前記サブブロックデータ重複排除部は、前記ブロックデータ重複排除部にて重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
   ことを実現させるためのプログラム。
10. 請求項８に記載のプログラムであって、
    前記サブブロックデータ重複排除部は、前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
    ことを実現させるためのプログラム。
11. データストリームを任意の容量に分割したブロックデータを、当該ブロックデータのデータ内容に基づくアドレスデータにて参照して記憶装置に格納すると共に、記憶装置に既に記憶されている前記ブロックデータと同一のデータ内容の他のブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記ブロックデータを前記他のブロックデータとして参照する前記アドレスデータを記憶装置に格納して前記ブロックデータの重複記憶排除を行い、
    前記ブロックデータをさらに複数に分割した各サブブロックデータを、当該各サブブロックデータの各データ内容に基づく各サブアドレスデータにて参照して記憶装置に記憶すると共に、前記各サブアドレスデータからなるサブアドレスデータ群を所定の記憶装置に記憶し、記憶装置に既に記憶されている前記サブブロックデータと同一のデータ内容の他のサブブロックデータを記憶装置に格納する場合に、当該記憶装置に既に記憶されている前記サブブロックデータを前記他のサブブロックデータとして参照する前記サブアドレスデータを前記所定の記憶装置に格納して前記サブブロックデータの重複記憶排除を行う、
    情報処理方法。
12. 請求項１１に記載の情報処理方法であって、
    重複記憶排除されない前記他のブロックデータを複数に分割した前記各サブブロックデータに対して前記サブブロックデータの重複記憶排除を行う、
    情報処理方法。
13. 請求項１１に記載の情報処理方法であって、
    前記データストリーム内の一部の前記ブロックデータから当該ブロックデータのデータ内容に基づいて検出した特徴値が設定条件を満たす場合に、当該設定条件を満たす特徴値が検出された前記ブロックデータに隣接する別の前記ブロックデータを分割した前記各サブブロックデータを参照する前記サブアドレスデータ群を、前記設定条件を満たす特徴値に関連付けて前記所定の記憶装置に記憶する、
    情報処理方法。
    

Images