JP6304406B2 - ストレージ装置、プログラム、情報処理方法 - Google Patents

ストレージ装置、プログラム、情報処理方法 Download PDF

Info

Publication number
JP6304406B2
JP6304406B2 JP2016571760A JP2016571760A JP6304406B2 JP 6304406 B2 JP6304406 B2 JP 6304406B2 JP 2016571760 A JP2016571760 A JP 2016571760A JP 2016571760 A JP2016571760 A JP 2016571760A JP 6304406 B2 JP6304406 B2 JP 6304406B2
Authority
JP
Japan
Prior art keywords
data
block
block data
read
storage unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016571760A
Other languages
English (en)
Other versions
JP2017521762A (ja
Inventor
ミーハウ カチマルチク
ミーハウ カチマルチク
チェザーリ ドゥブニーツキ
チェザーリ ドゥブニーツキ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2017521762A publication Critical patent/JP2017521762A/ja
Application granted granted Critical
Publication of JP6304406B2 publication Critical patent/JP6304406B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G06F3/0641—De-duplication techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1453—Management of the data involved in backup or backup restore using de-duplication of the data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、ストレージ装置、プログラム、情報処理方法にかかり、特に、同一内容のデータの重複記憶を排除するストレージ装置、プログラム、情報処理方法に関する。
莫大なデータを効率的に取り扱うための技術として、重複記憶を排除する機能を有するストレージ装置が知られている。
上記のような重複排除を行うストレージシステムの場合、新規のデータは、例えば、格納する領域の最後に追加されていくことになる。そのため、後にデータを読み出す際には、記憶装置全体に拡散したブロックデータを読み出すべく、ディスク操作の回数が膨大になる場合があった。
上記問題に対処するための技術としては、例えば、特許文献１がある。特許文献１には、複数の記憶媒体と、キャッシュメモリと、記憶媒体へのデータの入出力を制御する制御部と、を有するストレージ装置が記載されている。特許文献１によると、上記制御部は、複数の記憶媒体の記憶領域から構成され、同一の性能特性を有する第１の記憶領域と第２の記憶領域とを上位装置に提供する。具体的には、上記制御部は、第１の記憶領域に重複排除された第１のデータ列を格納し、第１のデータ列が重複排除される前のデータ列をもとに生成された第２のデータ列を、第２の記憶領域の構成する物理領域の連続した領域に格納する。特許文献１によると、このような構成により、第１の記憶領域に重複排除された第１のデータ列を格納し、第２の記憶領域の構成する物理領域の連続した領域に第２のデータ列を格納することが出来る。その結果、特許文献１によると、重複排除された断片化されたデータではなく連続した領域に格納されたデータをステージングすることが可能となり、アクセス性能を高めることが可能となる。
また、同様に上記問題に対処するための技術として、例えば、特許文献２がある。特許文献２には、データ分割手段と、ブロック検出手段と、データ書き込み手段と、を有するストレージ装置が記載されている。特許文献２によると、上記ブロック検出手段は、分割したブロックデータのうち書き込み対象データ中の所定範囲を構成する連続する複数のブロックデータと、記憶装置に既に連続して記憶されている所定範囲の複数のブロックデータと、の共通部分の割合を表す共通割合を検出する。また、データ書き込み手段は、ブロック検出手段にて検出した共通割合に応じて、分割したブロックデータを、新たに記憶装置に記憶する。特許文献２によると、このような構成により、共通割合が例えば所定の閾値より小さい場合にのみ、記憶装置に新たにブロックデータを書き込むよう制御することが出来る。その結果、特許文献２によると、重複排除を行いつつ、記憶装置内の記憶領域全体に対するブロックデータの拡散を抑制することが出来る。これにより、読出し性能が低下することを抑制することが可能となる。
国際公開第２０１４／１３６１８３号 特表２０１３−５４１０５５号公報
しかしながら、特許文献１の技術の場合、重複排除された第１のデータ列を記憶する第１の記憶領域の他に、第２の記憶領域を確保する必要がある。そのため、記憶装置の容量を消費してしまう、という問題があった。また、上記のような技術の場合、一連の読み出しの最中に２回以上同じブロックが出現することにより生じる読み出し性能の低下に対応することが難しい、という問題があった。つまり、一度キャッシュに読み出したブロックデータを再度必要とする際に、当該データがキャッシュから既に追い出されており、再度ディスクから読み出す必要が生じるおそれある、という問題があった。
このように、重複記憶を排除する機能を有するストレージ装置において、読み出し性能の低下を抑制することは依然として難しかった。
そこで、本発明の目的は、上述した課題である、重複記憶を排除する機能を有するストレージ装置において、読み出し性能の低下を抑制することが難しい、という問題を解決することの出来るストレージ装置を提供することにある。
かかる目的を達成するため本発明の一形態であるストレージ装置は、
重複排除されたブロックデータを記憶するデータ記憶部と、
前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、
前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御部と、
前記一時データ記憶部に記憶されている前記ブロックデータの記憶状態を制御する一時データ制御部と、
を有するとともに、
前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部を有し、
前記データ読出制御部は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部に対する前記ブロックデータの記憶状態を制御する
という構成を採る。
また、本発明の他の形態であるプログラムは、
重複排除されたブロックデータを記憶するデータ記憶部と、前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部と、を有する情報処理装置に、
前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御手段と、
前記一時データ記憶部に記憶されている前記ブロックデータの記憶状態を制御する一時データ制御手段と、
を実現させ、
前記データ読出制御手段は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部に対する前記ブロックデータの記憶状態を制御する
という構成を採る。
また、本発明の他の形態である情報処理方法は、
ブロックデータを読み出す順番についての情報である読出順番情報を取得し、
取得した前記読出順番情報に基づいて記憶装置から取得した前記ブロックデータを一時記憶装置に記憶させ、
前記読出順番情報に基づいて前記一時記憶装置に対する前記ブロックデータの記憶状態を制御する
という構成を採る。
本発明は、以上のように構成されることにより、読み出し性能の低下を抑制することが難しい、という問題を解決することの出来るストレージ装置を実現することが出来る。
本発明の第１の実施形態におけるストレージシステムを含むシステム全体の構成の一例を示すブロック図である。 本発明の第１の実施形態におけるストレージシステムの構成の概略の一例を示すブロック図である。 本発明の第１の実施形態におけるストレージシステムの構成の一例を示す機能ブロック図である。 図３で示すディスク装置が記憶するデータを説明するための図である。 図３で示すキャッシュメモリが記憶するデータを説明するための図である。 図５で示すブロックデータ順番情報の構成例を示す図である。 図５で示すデータ情報の構成例を示す図である。 図３で示すリストア管理部が行うデータの読み出し処理の様子を説明するための図である。 図３で示すリストア管理部が行うデータの読み出し処理の様子を説明するための図である。 図３で示すストレージシステムが行う読み出し処理の動作を示すフローチャートである。 本発明の第２の実施形態におけるストレージシステムの構成の一例を示す機能ブロック図である。 図１１で開示したストレージシステムにおけるデータ書き込み処理の様子の一例を説明するための説明図である。 図１１で開示したストレージシステムにおけるデータ書き込み処理の様子の一例を説明するための説明図である。 図１１で開示したストレージシステムにおけるデータ書き込み処理の様子の一例を説明するための説明図である。 図１１で開示したストレージシステムにおけるデータ書き込み処理の様子の一例を説明するための説明図である。 図１１で開示したストレージシステムにおけるデータ書き込み処理の動作の一例を示すフローチャートである。 書き込み要求にかかる一連のストリームデータ内で同一のブロックデータが複数出現する一例を示す図である。 本発明の第３の実施形態におけるストレージ装置の構成の一例を示すブロック図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。 本発明の第４の実施形態で説明する論文で参照する図である。
＜実施形態１＞
本発明の第１の実施形態を、図１乃至図１０を参照して説明する。図１は、ストレージシステム１を含むシステム全体の構成を示すブロック図である。図２は、ストレージシステム１の概略を示すブロック図である。図３は、ストレージシステム１の構成の一例を示す機能ブロック図である。図４は、図３で示すディスク装置１２が記憶するデータを説明するための図である。図５は、図３で示すキャッシュメモリ１４が記憶するデータを説明するための図である。図６は、図５で示すブロックデータ順番情報１４１の構成例を示す図である。図７は、図５で示すデータ情報１４２の構成例を示す図である。図８、図９は、図３で示すリストア管理部１３が行うデータの読み出し処理の様子を説明するための図である。図１０は、図３で示すストレージシステム１が行う読み出し処理の動作を示すフローチャートである。
本発明の第１の実施形態では、キャッシュメモリ１４を効率的に利用することで読み出し性能が低下することを抑制する、重複排除機能を有するストレージシステム１について説明する。後述するように、本実施形態におけるストレージシステム１は、リストアを行う際に、読み出すブロックデータの順番を示すメタデータを利用して、キャシュメモリ１４に対するブロックデータの記憶状態を制御する。このような制御を行うことで、後述するように、キャッシュメモリ１４が記憶している各ブロックデータがリストアの中で次に読み出される順番に応じて、キャッシュメモリ１４に残す（キャッシュメモリ１４から削除する）ブロックデータを選択することが出来る。その結果、キャッシュメモリ１４が記憶するブロックデータが再利用される前に削除されてしまうおそれや、まったく必要としないブロックデータがキャッシュメモリ１４に記憶されたままになるおそれを低減することが可能となり、読み出し性能が低下することを抑制することが可能となる。
なお、本実施形態では、後述する付記に記載のストレージ装置等の具体的な一例を示すものである。そして、以下では、ストレージシステム１が、複数台のサーバコンピュータが接続されて構成されている場合を説明する。但し、本発明におけるストレージシステム１は、複数台のコンピュータにて構成されることに限定されず、１台のコンピュータで構成されていてもよい。
図１で示すように、本発明におけるストレージシステム１は、ネットワークＮを介してバックアップ処理などを制御するバックアップシステム４に接続している。そして、バックアップシステム４は、ネットワークＮを介して接続されたバックアップ対象装置５に格納されるバックアップ対象データ（書き込み対象となるデータ）を取得し、ストレージシステム１に対して記憶するよう要求する。これにより、ストレージシステム１は、記憶要求されたバックアップ対象データをバックアップ用に記憶する。また、バックアップシステム４は、ストレージシステム１に対してデータの復元を指示するストリーム識別子を送信する。これにより、ストレージシステム１は、リストアを開始してストリーム識別子が示すファイルの復元を行う。
図２で示すように、本実施形態におけるストレージシステム１は、複数のサーバコンピュータが接続された構成を採っている。具体的に、ストレージシステム１は、ストレージシステム１自体における記憶再生動作を制御するサーバコンピュータであるアクセラレータノード２と、データを格納する記憶装置を備えたサーバコンピュータであるストレージノード３と、を備えている。なお、アクセラレータノード２の数とストレージノード３の数は、図２に示したものに限定されず、さらに多くの各ノード２，３が接続されて構成されていてもよい。
さらに、本実施形態におけるストレージシステム１は、データを分割及び冗長化し、分散して複数の記憶装置に記憶すると共に、記憶するデータの内容に応じて設定される固有のコンテンツアドレスによって、当該データを格納した格納位置を特定するコンテンツアドレスストレージシステムである。
従って、ストレージシステム１が記憶する各ブロックデータは、コンテンツアドレスによって識別することが出来る。具体的には、各ブロックデータのコンテンツアドレスは、各ブロックデータの内容に基づいて算出されており、例えば、１６０−ｂｉｔ ＳＨＡ１などのハッシュ関数を用いて算出されている。
なお、以下では、ストレージシステム１が１つのシステムであるとして、当該ストレージシステム１が備えている構成及び機能を説明する。つまり、以下に説明するストレージシステム１が有する構成及び機能は、アクセラレータノード２あるいはストレージノード３のいずれに備えられていてもよい。なお、ストレージシステム１は、図２に示すように、必ずしもアクセラレータノード２とストレージノード３とを備えていることに限定されず、いかなる構成であってもよく、例えば、１台のコンピュータにて構成されていてもよい。さらには、ストレージシステム１は、コンテンツアドレスストレージシステムであることにも限定されず、重複排除機能を有しているストレージシステムであればよい。
図３に、本実施形態におけるストレージシステム１の構成を示す。ストレージシステム１は、サーバコンピュータにて構成され、所定の演算処理を行う演算装置（図示せず）と、プログラムを記憶する記憶装置（図示せず）と、メタデータ記憶部１１（読出順番情報記憶部、Metadata Storage）と、ディスク装置１２（データ記憶部、Physical disk drive）と、キャッシュメモリ１４（一時データ記憶部、Forward Knowledge Cache）と、を備える。そして、ストレージシステム１は、上記演算装置にプログラムが組み込まれることで構築された、リストア管理部１３（データ読出制御部、Restore Manager）とキャッシュメモリ制御部１５（一時データ制御部）とを備えている。
なお、実際には、上述したストレージシステム１が備える構成は、図２に示したアクセラレータノード２及びストレージノード３がそれぞれ備えているＣＰＵ（Central Processing Unit）などの演算装置やハードディスクドライブなどの記憶装置にて構成されている。
メタデータ記憶部１１は、ハードディスクドライブなどの記憶装置である。メタデータ記憶部１１は、データをリストアする際に読み出すブロックデータの順番や実データのブロックのアドレスなどの情報を含むメタデータとストリーム識別子とを対応付けて記憶している。
上記メタデータは、例えば、バックアップ処理によりディスク装置１２にブロックデータを記憶させる際にメタデータ記憶部１１に記憶される。一般に、リストアを行う際には、書き込みが行われた際と同じ順番でブロックデータの読み出しが行われることになる。そのため、上記のようなメタデータをストリーム識別子と対応付けて記憶しておくことで、リストアを行う際に、書き込みが行われた際と同じ順番でブロックデータの読み出しを行うことが可能となる。
また、後述するように、本実施形態におけるストレージシステム１は、キャッシュメモリ１４に対するブロックデータの記憶状態の制御（例えば、キャッシュメモリ１４が記憶するブロックデータの削除など）を行う際に、上記メタデータを利用する。つまり、本実施形態におけるストレージシステム１は、上記メタデータに基づいたキャッシュエビクションポリシー（キャッシュからデータを削除する際の方針）を有していることになる。
ディスク装置１２は、ハードディスクドライブなどの記憶装置である。本実施形態におけるディスク装置１２は、重複排除された状態のブロックデータを記憶している。
また、上述したように、本実施形態におけるストレージシステム１は、コンテンツアドレスストレージシステムである。そのため、ストレージシステム１は、コンテンツアドレスを利用してデータをディスク装置１２に格納している。
ここで、ディスク装置１２がブロックデータを記憶する際の処理の一例について説明する。例えば、ストレージシステム１があるファイルの書き込み要求を受けたとする。すると、ストレージシステム１は、書き込み要求されたファイルを所定容量（例えば、６４ＫＢ）のブロックデータに分割する。そして、分割されたブロックデータのデータ内容に基づいて、当該データ内容を代表する固有のハッシュ値を算出する。その後、ストレージシステム１は、算出されたハッシュ値を用いて、当該ハッシュ値を有するブロックデータがディスク装置１２に既に記憶されているか否かを調べる。そして、ストレージシステム１は、ブロックデータがディスク装置１２に記憶されていないと判断された場合に、ディスク装置１２にブロックデータの書き込みを行う。
本実施形態におけるディスク装置１２は、このようにして書き込まれたブロックデータを記憶している。つまり、ディスク装置１２は、新規なブロックデータがディスクの後方に随時追加されていく形でブロックデータを記憶している。具体的には、例えば図４を参照すると、Ａ１、Ａ２、Ａ３のバックアップデータをとる場合、ディスク装置１２には、Ａ１、Ａ２、Ａ３の順番でブロックデータが書き込まれることになる。そして、上記処理の後にＡ１，Ａ２、Ｂ１、Ａ３のバックアップデータをとる場合、ディスク装置１２には、Ａ１、Ａ２、Ａ３の後方に新たなＢ１が書き込まれることになる。その後、上記処理の後更にＡ１、Ｃ１、Ｂ１、Ａ３、Ｃ２のバックアップデータをとる場合、ディスク装置１２には、Ａ１、Ａ２、Ａ３、Ｂ１の後方に新たなＣ１、Ｃ２が書き込まれることになる。
このように、ディスク装置１２は、重複排除したバックアップを行う際に行われる一般的な方法により書き込まれたブロックデータを記憶している。なお、ディスク装置１２にブロックデータが書き込まれる際の条件や書き込まれるブロックデータの内容などは、必要に応じて変更しても構わない。例えば、ディスク装置１２は、分割したブロックデータのうち書き込み対象データ中の所定範囲を構成する連続する複数のブロックデータと、ディスク装置１２に既に連続して記憶されている所定範囲の複数のブロックデータと、の共通部分の割合を表す共通割合を検出し、検出した共通割合に応じてブロックデータが書き込まれるよう構成されていても構わない。
リストア管理部１３は、バックアップシステム４から受信したストリーム識別子に基づいてデータの復元を行う。つまり、リストア管理部１３は、バックアップシステム４からデータの復元を指示するストリーム識別子を受信することで、当該ストリーム識別子が示すファイルの復元を行うことになる。
具体的には、リストア管理部１３は、バックアップシステム４からストリーム識別子を受信すると、メタデータ記憶部１１から対応するメタデータの一部を取得する。また、リストア管理部１３は、リストアが進むと、メタデータ記憶部１１から追加のメタデータを取得する。このように、リストア管理部１３は、リストアの進み具合に応じて、メタデータ記憶部１１からメタデータを取得する。なお、リストア管理部１３は、一度に全てのメタデータを取得しても構わない。
そして、リストア管理部１３は、取得したメタデータが示す、読み出すブロックデータの順番に基づいて、ストレージシステム１が記憶するブロックデータを取得する。具体的には、リストア管理部１３は、取得する対象のブロックデータをキャッシュメモリ１４が記憶している場合には、当該キャッシュメモリ１４から対象のブロックデータを取得する。一方、取得する対象のブロックデータをキャッシュメモリ１４が記憶していない場合には、リストア管理部１３は、ディスク装置１２からキャッシュメモリ１４に一定又は可変の大きさのチャンクでデータを取得するよう指示する。つまり、取得する対象のブロックデータをキャッシュメモリ１４が記憶していない場合には、ディスク装置１２内の連続する領域に書き込まれた所定の大きさの連続ブロックデータ（例えば、連続する４つのブロックデータ）がキャッシュメモリ１４に読み出されることになる。そして、リストア管理部１３は、キャッシュメモリ１４から対象のブロックデータを取得する。
また、本実施形態におけるリストア管理部１３は、メタデータ記憶部１１から取得したメタデータに基づいて、後述するブロックデータ順番情報１４１をキャッシュメモリ１４に記憶させる。後述するように、キャッシュメモリ制御部１５は、ブロックデータ順番情報１４１を用いて、キャッシュメモリ１４に対するブロックデータの記憶状態の制御を行うことになる。なお、ブロックデータ順番情報１４１とキャッシュメモリ制御部１５の構成の詳細については、後述する。
キャッシュメモリ１４は、半導体メモリなどの記憶装置である。図５を参照すると、キャッシュメモリ１４は、例えば、メタデータに基づいた情報であるブロックデータ順番情報１４１と、ディスク装置１２から取得したブロックデータを示すデータ情報１４２とを記憶している。
ブロックデータ順番情報１４１は、上記のようにメタデータに基づいて生成される情報である。ブロックデータ順番情報１４１は、例えば、リストア管理部１３が読み出したメタデータに含まれる読み出すブロックデータの順番を、ブロックデータごとに示した情報である。図６で示すように、ブロックデータ順番情報１４１は、ブロックデータを識別するためのブロックデータ識別子とブロックデータが読み出される順番を示す順番情報とを対応付けた構造を有している。
ブロックデータ識別子は、ブロックデータを識別するための情報である。ブロックデータ識別子は、例えば、ブロックデータのデータ内容に基づいて算出されるハッシュ値の一部（ショートハッシュ）である。なお、ブロックデータ識別子は、ハッシュ値の全てあっても構わない。
順番情報は、対応付けて記憶されているブロックデータ識別子が示すブロックデータが読み出される順番を示す情報である。具体的には、順番情報は、例えば、リストア管理部１３が現に読み出しているブロックデータの順番以降の、ブロックデータが読み出される順番を示している。例えば、リストア管理部１３が７８番目のブロックデータを読み出しているとすると、順番情報は、対象のブロックデータが読み出される順番のうちの７９番目以降（又は、７８番目以降）の順番を示していることになる。
なお、順番情報は、各ブロックデータが読み出される順番を正確に示している必要は必ずしもない。つまり、順番情報は、ストリーム識別子に基づいて開始される一連の読み出し処理のうちの大まかな順番を示していれば構わない。従って、順番情報は、例えば、一連の読み出し処理を所定の大きさで複数のセクションに分割した際の、当該分割したセクションの順番を示す情報であっても構わない。
データ情報１４２は、ディスク装置１２から取得したブロックデータを示す情報である。例えば、図７で示すように、データ情報１４２は、コンテンツアドレス（例えば、上述したように、ブロックデータのデータ内容に基づいて算出されるハッシュ値）をキーとしデータをバリューとする標準的なマップとして構造化されている。
また、本実施形態におけるデータ情報１４２は、ストリーム識別子に応じて開始されたブロックデータの読み出しにおいて、対象のブロックデータが次回読み出される順番についての情報である次順番情報を含んで構成されている。例えば、図７の１行目は、コンテンツアドレス「d34mf79」のブロックデータが次回読み出される順番は「７９」であることを示している。つまり、図７の１行目によると、コンテンツアドレス「d34mf79」のブロックデータが次回読み出されるのは、ストリーム識別子に応じて開始された一連の読み出し処理のうちの７９番目の順番であることが分かる。なお、データ情報１４２に含まれる次順番情報は、例えば、ブロックデータ順番情報１４１に基づいて求められることになる。
また、本実施形態におけるデータ情報１４２は、例えば、次順番情報に基づいて並べ替えられている（ソートされている）。具体的には、データ情報１４２は、次順番情報に基づいて降順で並べ替えられている。つまり、データ情報１４２は、次回読み出される順番が早い順で並べ替えて記憶されていることになる。
キャッシュメモリ制御部１５は、キャッシュメモリ１４が記憶するブロックデータ順番情報１４１を用いて、キャッシュメモリ１４に対するブロックデータの記憶状態の制御を行う。具体的には、キャッシュメモリ制御部１５は、キャッシュメモリ１４が予め定められた閾値以上の数のブロックデータを記憶している（記憶しようとしている）場合に、リストア管理部１３が読み出す対象としているブロックデータの順番から読み出す順番が離れているブロックデータを削除する。
このように、キャッシュメモリ制御部１５は、リストア管理部１３が読み出す対象としているブロックデータの読み出す順番から離れている度合いに応じて、キャッシュメモリ１４が記憶するブロックデータを削除する。キャッシュメモリ制御部１５は、このような処理を行うことで、キャッシュメモリ１４の容量が一杯になることを防ぐことになる。
ストレージシステム１は、例えば、上記構成のメタデータ記憶部１１と、ディスク記憶部１２と、リストア管理部１３と、キャッシュメモリ１４と、キャッシュメモリ制御部１５と、を有している。
続いて、リストア管理部１３がブロックデータを取得する際の処理の詳細について、図８、図９を参照して説明する。
まず、図８を参照して、取得する対象のブロックデータをキャッシュメモリ１４が記憶している場合について説明する。具体的には、例えば、リストア管理部１３が、７９番目の読み出しとして、コンテンツアドレス「d34mf」のブロックデータを取得しようとしている場合について説明する。
図８の（１）を参照すると、キャッシュメモリ１４がコンテンツアドレス「d34mf」のブロックデータを記憶していることが分かる。そこで、リストア管理部１３は、キャッシュメモリ１４から対象のブロックデータの読み出しを行うことになる。また、上記リストア管理部１３によるブロックデータの読み出しに応じて、キャッシュメモリ制御部１５は、ブロックデータ順番情報１４１とデータ情報１４２との更新を行う（図８の（２）参照）。具体的には、図８を参照すると、コンテンツアドレス「d34mf」のブロックデータは、７９番目の順番の後は、１８１番目の順番に読み出される予定であることが分かる。そのため、キャッシュメモリ制御部１５は、コンテンツアドレス「d34mf」のブロックデータが次回読み出される順番を７９から１８１に更新する処理をブロックデータ順番情報１４１とデータ情報１４２とに対して行う。また、キャッシュメモリ制御部１５は、更新された順番に基づいて、データ情報１４２を降順でソートする。その結果、図８の（３）で示すように、コンテンツアドレス「d34mf」のブロックデータは、コンテンツアドレス「9bgR4」のブロックデータの下の位置に移動することになる。このようにして、リストア管理部１３がキャッシュメモリ１４からブロックデータを読み出すとともに、ブロックデータ順番情報１４１とデータ情報１４２との更新が行われることになる。
なお、例えば、キャッシュメモリ１４からブロックデータを読み出すと、当該ブロックデータの次回読み出される順番がなくなる（次回読み出される予定がない）ことになる場合が想定される。この場合には、キャッシュメモリ制御部１５は、該当するブロックデータをキャッシュメモリ１４から削除するよう構成しても構わない。
続いて、図９を参照して、取得する対象のブロックデータをキャッシュメモリ１４が記憶していない場合について説明する。具体的には、例えば、リストア管理部１３が、７９番目の読み出しとして、コンテンツアドレス「d34mf」のブロックデータを取得しようとしている場合について説明する。
なお、キャッシュメモリ１４がブロックデータを記憶する数の閾値は、例えば、５であるものとする。つまり、キャッシュメモリ制御部１５は、キャッシュメモリ１４が記憶するブロックデータの数が５を超えた場合、キャッシュメモリ１４が記憶するブロックデータの数が５になるように、キャッシュメモリ１４が記憶するブロックデータを削除することになる。
図９の（１）を参照すると、キャッシュメモリ１４は、コンテンツアドレス「d34mf」のブロックデータを記憶していないことが分かる。そこで、リストア管理部１３は、コンテンツアドレス「d34mf」のブロックデータから始まる連続する領域に書き込まれた例えば４つのブロックデータをディスク装置１２からキャッシュメモリ１４に読み出すよう指示する。その結果、図９で示す場合では、コンテンツアドレス「d34mf」のブロックデータとともに、コンテンツアドレス「F5kd9」、「pwQ2e」、「zc5Tf」のブロックデータが読み出されることになる。
上記ディスク装置１２からのブロックデータの読み出しの結果、キャッシュメモリ１４には７つのブロックデータが記憶されることになる（図９の（２））。そこで、キャッシュメモリ制御部１５は、キャッシュメモリ１４が記憶するブロックデータの数が５になるように、ブロックデータを削除する。図９で示す場合では、リストア管理部１３が読み出す対象としているブロックデータの順番（７９番目）から読み出す順番が離れているブロックデータは「pwQ2e」と「zc5Tf」である。そこで、キャッシュメモリ制御部１５は、「pwQ2e」と「zc5Tf」のブロックデータを削除する。これにより、キャッシュメモリ１４には、５つのブロックデータが残ることになる（図９の（３））。
その後、リストア管理部１３とキャッシュメモリ制御部１５とは、図８を参照して説明した処理を行って、キャッシュメモリ１４からブロックデータを取得するとともに、ブロックデータ順番情報１４１とデータ情報１４２との更新を行うことになる。
以上が、リストア管理部１３がブロックデータを取得する際の処理の一例についての説明である。次に、図１０を参照して、ストレージシステム１がデータの復元を行う際の動作について説明する。
図１０を参照すると、ストレージシステム１のリストア管理部１３は、バックアップシステム４からデータの復元を指示するストリーム識別子を受信する（ステップＳ００１）。
すると、リストア管理部１３は、メタデータ記憶部１１から復元するファイルについてのメタデータを取得する（ステップＳ００２）。そして、リストア管理部１３は、取得したメタデータが示す、読み出すブロックデータの順番に基づいて、ストレージシステム１が記憶するブロックデータの取得を開始する。
具体的には、リストア管理部１３は、取得する対象のブロックデータがキャッシュメモリ１４に記憶されている場合には（ステップＳ００３、Ｙｅｓ）、キャッシュメモリ１４から対象のブロックデータを取得する（ステップＳ００７）。また、キャッシュメモリ制御部１５は、キャッシュメモリ１４の更新を行う。つまり、キャッシュメモリ制御部１５は、ブロックデータ順番情報１４１とデータ情報１４２との更新処理を行う。また、キャッシュメモリ制御部１５は、更新された順番に基づいて、データ情報１４２を降順でソートする。
そして、上記ブロックデータの取得によりメタデータが示す全てのブロックデータを取得した場合（ステップＳ００８、Ｙｅｓ）、ストレージシステム１は、データの復元を完了して、その処理を終了する。一方、まだ取得すべきブロックデータが残っている場合（ステップＳ００８、Ｎｏ）には、リストア管理部１３は、ブロックデータの取得を続けることになる。
また、取得する対象のブロックデータがキャッシュメモリ１４に記憶されていない場合（ステップＳ００３、Ｎｏ）には、リストア管理部１３は、ディスク装置１２からキャッシュメモリ１４に例えば４つの連続するブロックデータを読み出すよう指示する（ステップＳ００４）。
そして、上記処理の結果キャッシュメモリ１４が記憶するブロックデータの数が閾値を超えた場合（ステップＳ００５、Ｙｅｓ）には、キャッシュメモリ制御部１５は、キャッシュメモリ１４に対するブロックデータの記憶状態の制御を行う。つまり、キャッシュメモリ制御部１５は、ブロックデータ順番情報１４１に基づいて、リストア管理部１３が読み出す対象としているブロックデータの順番から読み出す順番が離れているブロックデータを削除する（ステップＳ００６）。
その後、上記説明したステップＳ００７の処理が行われることになる。つまり、リストア管理部１３がキャッシュメモリ１４から対象のブロックデータを取得するとともに、キャッシュメモリ制御部１５がキャッシュメモリ１４の更新を行うことになる（ステップＳ００７）。また、キャッシュメモリ１４が記憶するブロックデータの数が閾値を超えていなかった場合（ステップＳ１０５、Ｎｏ）にも、上記と同様に、ステップＳ００７の処理が行われることになる。
そして、上記ブロックデータの取得によりメタデータが示す全てのブロックデータを取得した場合（ステップＳ００８、Ｙｅｓ）、ストレージシステム１は、データの復元を完了して、その処理を終了する。一方、まだ取得すべきブロックデータが残っている場合（ステップＳ００８、Ｎｏ）には、リストア管理部１３は、ブロックデータの取得を続けることになる。
このように、本実施形態におけるストレージシステム１は、メタデータ記憶部１１とキャッシュメモリ制御部１５とを有している。このような構成により、キャッシュメモリ制御部１５は、メタデータ記憶部１１が記憶するメタデータに基づいて生成されるブロックデータ順番情報１４１を用いて、キャッシュメモリ１４に対するブロックデータの記憶状態の制御を行うことが出来るようになる。つまり、キャッシュメモリ制御部１５は、ロックデータ順番情報に基づいて、リストア管理部１３が読み出す対象としているブロックデータの順番から読み出す順番が離れているブロックデータを削除することが出来るようになる。その結果、キャッシュメモリ１４が記憶するブロックデータが再利用される前に削除されてしまうおそれや、まったく必要としないブロックデータがキャッシュメモリ１４に記憶されたままになるおそれを低減することが可能となる。これにより、ディスク装置１２から重複したブロックデータを読み出す回数を減らすことが可能となり、同一のストリームで何度も出現するブロックデータを原因として発生する読み出し性能の低下を抑制することが可能となる。つまり、読み出し性能の低下を抑制することが難しい、という問題を解決することの出来るストレージシステム１を実現することが可能となる。
なお、本実施形態においては、キャッシュメモリ１４がブロックデータ順番情報１４１を記憶しているとした。しかしながら、ブロックデータ順番情報１４１は、例えば、必要に応じてキャッシュメモリ１４が記憶するよう構成されても構わない。
［第２の実施形態］
次に、本発明の第２の実施形態では、書き込み対象データ中の連続する複数のブロックデータと、ディスク装置１２に既に連続して記憶されている複数のブロックデータと、の共通部分の割合に応じて重複するブロックデータの書き直しを行う、ストレージシステム６について説明する。
図１１を参照すると、本実施形態におけるストレージシステム６は、第１の実施形態で説明したストレージシステム１が有する構成と同様の構成を有している。更に、ストレージシステム６は、上記構成に加えて、演算装置にプログラムが組み込まれることで構築された、データ分割部６６と、ブロック検出部６７と、データ書き込み部６８と、を備えている。なお、第１の実施形態で説明した構成については、その説明は省略する。
第１の実施形態と同様に、ストレージシステム６は、コンテンツアドレスを利用してデータをディスク装置１２に格納する機能を有している。具体的には、以下に説明するように、ストレージシステム６は、データを分割及び分散し、かつ、コンテンツアドレスにて格納位置を特定して、データを格納する。以下、ストレージシステム６にてコンテンツアドレスを利用したデータ書き込み処理について、図１２、図１３、図１６を参照して説明する。
まず、図１２及び図１３の矢印Ｙ１に示すように、ストレージシステム６が書き込み要求されたファイルＡの入力を受ける。すると、データ分割部６６が、図１２及び図１３の矢印Ｙ２に示すように、ファイルＡを所定容量（例えば、６４ＫＢ）のブロックデータＤに分割する（図１６のステップＳ１０１）。
続いて、ブロック検出部６７は、分割されたブロックデータＤのデータ内容に基づいて、当該データ内容を代表する固有のハッシュ値Ｈを算出する（図１３の矢印Ｙ３）。例えば、ハッシュ値Ｈは、予め設定されたハッシュ関数を用いて、ブロックデータＤのデータ内容から算出する。
続いて、ブロック検出部６７は、ファイルＡのブロックデータＤのハッシュ値Ｈを用いて、当該ブロックデータＤが既に格納されているか否かを調べる（図１６のステップＳ１０２）。具体的には、まず、既に格納されているブロックデータＤは、そのハッシュ値Ｈと格納位置を表すコンテンツアドレスＣＡとが、関連付けられてＭＦＩ（Ｍａｉｎ Ｆｒａｇｍｅｎｔ Ｉｎｄｅｘ）ファイルに登録されている。従って、格納前に算出したブロックデータＤのハッシュ値ＨがＭＦＩファイル内に存在している場合には、既に同一内容のブロックデータＤが格納されていると判断できる（図１３の矢印Ｙ４、図１６のステップＳ１０３でＹｅｓ）。この場合には、格納前のブロックデータＤのハッシュ値Ｈと一致したＭＦＩ内のハッシュ値Ｈに関連付けられているコンテンツアドレスＣＡを、当該ＭＦＩファイルから取得する。そして、このコンテンツアドレスＣＡを、書き込み要求されたブロックデータＤのコンテンツアドレスＣＡとして返却する。
そして、データ書き込み部６８は、返却されたコンテンツアドレスＣＡが参照する既に格納されているデータを、書き込み要求されたブロックデータＤとして使用する（図１６のステップＳ１０８）。つまり、書き込み要求されたブロックデータＤの格納先として、返却されたコンテンツアドレスＣＡが参照する領域を指定することで、当該書き込み要求されたブロックデータＤを記憶したこととする。これにより、書き込み要求にかかるブロックデータＤを、実際にディスク装置１２内に記憶する必要がなくなる。
また、上記ブロック検出部６７にて、書き込み要求にかかるブロックデータＤがまだ記憶されていないと判断された場合には（図１６のステップＳ１０３でＮｏ）、以下のようにして、データ書き込み部６８にて書き込み要求にかかるブロックデータＤの書き込みを行う（図１６のステップＳ１０７）。まず、書き込み要求にかかるブロックデータＤを圧縮して、図１３の矢印Ｙ５に示すように、複数の所定の容量のフラグメントデータに分割する。例えば、図１２の符号Ｄ１〜Ｄ９に示すように、９つのフラグメントデータ（分割データ７１）に分割する。そしてさらに、分割したフラグメントデータのうちいくつかが欠けた場合であっても、元となるブロックデータを復元可能なよう冗長データを生成し、上記分割したフラグメントデータ７１に追加する。例えば、図１２の符号Ｄ１０〜Ｄ１２に示すように、３つのフラグメントデータ（冗長データ７２）を追加する。これにより、９つの分割データ７１と、３つの冗長データ７２とにより構成される１２個のフラグメントデータからなるデータセット７０を生成する。
続いて、上述したように生成されたデータセットを構成する各フラグメントデータを、記憶装置（ディスク装置１２）に形成された各記憶領域に、それぞれ分散して格納する。例えば、図１２に示すように、１２個のフラグメントデータＤ１〜Ｄ１２を生成した場合には、複数の記憶装置内にそれぞれ形成したデータ格納ファイルに、各フラグメントデータＤ１〜Ｄ１２を１つずつそれぞれ格納する（図１３の矢印Ｙ６参照）。
続いて、ストレージシステム６は、上述したように格納したフラグメントデータＤ１〜Ｄ１２の格納位置、つまり、当該フラグメントデータＤ１〜Ｄ１２にて復元されるブロックデータＤの格納位置を表すコンテンツアドレスＣＡを生成して管理する。具体的には、格納したブロックデータＤの内容に基づいて算出したハッシュ値Ｈの一部（ショートハッシュ）（例えば、ハッシュ値Ｈの先頭８Ｂ（バイト））と、論理格納位置を表す情報と、を組み合わせて、コンテンツアドレスＣＡを生成する。そして、このコンテンツアドレスＣＡを、ストレージシステム６内のファイルシステムに返却する（図１３の矢印Ｙ７）。すると、ストレージシステム６は、バックアップ対象データのファイル名などの識別情報と、コンテンツアドレスＣＡとを関連付けてファイルシステムで管理する。
また、ブロックデータＤのコンテンツアドレスＣＡと、当該ブロックデータＤのハッシュ値Ｈと、を関連付けて、各ストレージノード３がＭＦＩファイルにて管理する。このように、上記コンテンツアドレスＣＡは、ファイルを特定する情報やハッシュ値Ｈなどと関連付けられて、アクセラレータノード２やストレージノード３の記憶装置に格納される。
ここで、上記のようにストレージシステム６にて書き込み要求にかかるデータを書き込むと、上述したように、当該データを分割した複数のブロックデータがディスク装置１２内に拡散して格納されることがある。すると、読み出し性能が低下するおそれがあるが、かかる問題を解決するために、本実施形態におけるストレージシステム１は、以下の機能も備える。以下、図１４乃至図１６を参照して詳述する。
まず、ブロック検出部６７は、上述したように、書き込み要求にかかるデータＡを分割したブロックデータと同じ内容のブロックデータが、ディスク装置１２に既に格納されているか否かを調べる（図１６のステップＳ１０１，ステップＳ１０２）。例えば、図１４に示す例では、まず、書き込み要求にかかるデータＡを分割したブロックデータ１を、今、記憶処理する対象となる対象ブロックとし、これと同じ内容のブロックデータが、ディスク装置１２内に記憶されたデータＢに存在するか否かを調べる。
そして、図１４の斜線に示すように、ディスク装置１２内にも対象ブロックと同じ内容のブロックデータ１が存在している場合には（図１６のステップＳ１０３でＹｅｓ）、ブロック検出部６７は、書き込み要求にかかるデータＡ内の対象ブロック（ブロックデータ１）から連続する複数のブロックデータも取得する。図１４に示す例では、書き込み要求にかかるデータＡ中の所定範囲を構成するブロックデータ１〜８からなる連続ブロックデータＡ１を取得する。これと共に、ブロック検出部６７は、ディスク装置１２内に記憶されたデータＢのうち、上記対象ブロックと同一内容のブロックデータ１から連続する領域に格納された複数のブロックデータ、つまり、図１４に示す例では、データＢ中の所定範囲を構成するブロック１、Ｃ，Ｂ，７，Ｇからなる連続ブロックデータＢ１を取得する。なお、書き込み要求にかかるデータＡから取得する連続ブロックデータＡ１は、例えば、５ＭＢ容量に相当する数のブロックデータであり、ディスク装置１２内のデータＢから取得する連続ブロックデータＢ１は、例えば、２ＭＢ容量に相当する数のブロックデータである。このように、各連続ブロックデータＡ１，Ｂ１は、相互に容量が異なっていてもよく、あるいは、同一であってもよい。
さらに、ブロック検出部６７は、上述したように書き込み要求にかかるデータＡから取得した連続ブロックデータＡ１に含まれる各ブロックデータと、ディスク装置１２内から取得した連続ブロックデータＢ１に含まれる各ブロックデータと、の共通部分の割合を表す共通割合を検出する（図１６のステップＳ１０４）。例えば、上述したように各ブロックデータのハッシュ値を用いて、一致するブロックデータの数を検出する。図１４の例では、各連続ブロックデータＡ１，Ｂ１において、２つのブロックデータ１，７が共通しており、その割合を共通割合として検出する。
その後、データ書き込み部６８は、上述したようにブロック検出部６７にて検出した共通割合の値に応じて、以下のようにブロックデータの書き込みを行う。まず、共通割合が予め設定された値より大きい場合（例えば、５０％より大きい場合）には（図１６のステップＳ１０５でＮｏ）、書き込み要求にかかるデータＡの対象ブロック（ブロックデータ１）について通常の書き込み処理を行う。つまり、書き込み要求にかかるデータＡの対象ブロックは、同一内容のブロックデータが既にディスク装置１２に格納されているため、このディスク装置１２に既に格納されているブロックデータを参照する処理を行い、重複記憶を行わない（図１６のステップＳ１０５）。
このように、各連続ブロックデータの共通割合が大きい場合には、書き込み要求にかかるデータＡの対象ブロックに続く他のブロックデータも、ディスク装置１２内の対象ブロックと同一内容のブロックデータから後ろの所定範囲の領域に記憶されていると言えるため、上述したように対象ブロックについて通常の格納処理を行う。そして、その後は、書き込み要求にかかるデータＡの次のブロックデータ２を対象ブロックとして、上述同様の処理を行う。これにより、書き込み要求にかかるデータＡを後に読み出す際には、既に記憶されているデータＢの連続するブロックデータを読み出すことで、効率よくデータＡを読み出すことができる。また、ブロックデータの重複記憶排除も行われているため、記憶容量の削減を図ることができる。
一方で、共通割合が予め設定された値以下である場合（例えば、５０％以下の場合。３０％などそれ以外の値でも構わない）には（図１６のステップＳ１０５でＹｅｓ）、書き込み要求にかかるデータＡの対象ブロック（ブロックデータ１）を、新たにディスク装置１２に書き込む（図８のステップＳ１０６）。つまり、図１４の例の場合には、一致する共通ブロックが２つのみであり、共通割合が予め設定された値以下となるため、ブロックデータ１がディスク装置１２に既に記憶されているものの、当該ブロックデータ１を再書き込みブロックデータとして、ディスク装置１２に書き込む（図１５参照）。このとき、再書き込みされるブロックデータ１は、ディスク装置１２内においてデータが既に書き込まれている領域の最後に書き込まれる。その後は、書き込み要求にかかるデータＡの次のブロックデータ２に対して、上述同様に、図１６のステップＳ１０１からＳ１０８までの処理が行われる。例えば、ブロックデータ２がディスク装置１２内にまだ記憶されていない場合には、当該ディスク装置１２内において、上述したように再書き込みされたブロックデータ１の次の領域に書き込まれることとなる。
このように、各連続ブロックデータの共通割合が小さい場合には、書き込み要求にかかるデータＡの対象ブロック及びこれに続く各ブロックデータが、ディスク装置１２内に分散して記憶されていると言えるため、書き込み要求にかかるデータＡの対象ブロックを新たに書き込む。これにより、後にデータＡを後に読み出す際には、ディスク装置１２内の連続する領域に書き込まれたブロックデータを読み出すことで、データＡを構成する複数のブロックデータをまとめて読み出せる可能性が高くなり、読み出し性能の向上を図ることができる。
ここで、上述したブロック検出部６７にて書き込み要求にかかる連続ブロックデータと既に記憶されている連続ブロックデータとの共通割合を検出する際には、各連続ブロックデータ内における各ブロックデータの並び順は関係ない。つまり、両方の連続ブロックデータ内のいずれかの位置に、同一内容のブロックデータが存在していれば、そのブロックデータは共通していると検出される。そして、ブロックデータが共通している数によって、共通割合を検出する。なお、共通割合の値は、ブロックデータが共通している数の値でもよく、連続ブロックデータ内でブロックデータが共通する割合でもよい。このように、各連続ブロックデータ内における各ブロックデータの並び順を考慮せず共通割合を検出する理由は、読み出しの際に、ディスク装置１２内の連続する領域に書き込まれた連続ブロックデータを読み出すことで、近傍にある関連するブロックを一度に読み出しすることができるためである。
また、データ書き込み部６８は、上述したように、いかなる場合も新たにブロックデータを書き込むわけではなく、以下の条件を満たす場合にのみ新たにブロックデータを書き込む。例えば、データ書き込み部６８は、書き込み要求にかかるデータＡ（一例として、現在の書き込み要求にかかる一連のストリームデータ）のうち既にディスク装置１２に書き込んだデータの容量に対する、重複して新たにディスク装置１２に書き込んだブロックデータの容量の割合を算出し、その割合が所定の割合（例えば、５％）以下である場合に、ブロックデータの書き込みを行う。これにより、ディスク装置１２に対して重複記憶されるブロックデータの容量を抑制することができる。また、ディスク装置１２への再書き込みの容量を抑制することで、再書き込みによる書き込み速度の低下を抑制することができる。なお、ブロックデータを再度書き込む条件は任意であり、例えば、書き込んだブロックデータの容量が、ディスク装置１２の容量に応じて予め設定された容量以下である、ことを条件としてもよい。
また、データ書き込み部６８は、書き込み要求にかかる一連のストリームデータ内で同一のブロックデータが出現する場合、当該一連のストリームデータ内で最初に出現するブロックデータのみをディスク装置１２への書き込みの対象とするよう構成することが出来る。
例えば、図１７で示す例では、書き込み要求にかかる一連のストリームデータ内で、同じブロックデータ「１」が２回出現していることが分かる。このような場合、データ書き込み部６８は、最初のブロックデータ「１」については書き込みの対象とする（図１６のステップＳ１０１からＳ１０８までの処理を行う）。一方で、データ書き込み部６８は、再度出現したブロックデータ「１」（斜線のブロックデータ「１」）に対しては、再度書き込みを行うか否かの判定を行わずに参照処理を行うよう構成することが出来る。
第１の実施形態で説明したように、本実施形態におけるストレージシステム６は、キャッシュメモリ１４を効率的に利用することで読み出し性能が低下することを抑制することが出来る。そのため、上記のような場合には、再度の書き込み処理を行わずともキャッシュメモリ１４を効率的に利用して読み出し性能が低下することを抑制することが出来るものと考えられる。従って、一連のストリームデータ内で同一のブロックデータが出現する場合、当該一連のストリームデータ内で最初に出現するブロックデータのみをディスク装置１２への書き込みの対象とすることで、読み出し性能の低下を抑制する効率的な再書き込みの判定を実現することが出来るものと考えられる。
また、一連のストリームデータ内で同じブロックデータが既に出現しているか否か判定する際には、ブルームフィルタを用いることが望ましい。ブルームフィルタを用いることで、比較的少ないメモリの使用で上記判定を行うことが出来るものと考えられる。なお、仮にブルームフィルタを用いた際に偽陽性が判定されたとしても、上記のように再書き込みを行うか否かの判定が行われることになるだけであるため、特に問題はないものと考えられる。
以上のように、本実施形態におけるストレージシステム６によると、重複記憶排除を行いつつ、ディスク装置１２内の記憶領域全体に対するブロックデータの拡散を抑制することができる。このため、後にデータを読み出す際には、多くの数のディスクを走査することを抑制することができ、読み出し性能の低下を抑制することができる。一方で、読み出し性能の低下を抑制するために、ブロックデータの重複記憶を許容しているが、その容量を抑制することで、記憶容量の増加も抑制することができる。
本発明の第３の実施形態では、読出順番情報記憶部８４が記憶する読出順番情報に基づいて一時データ記憶部８２に対するブロックデータの記憶状態の制御を行う一時データ制御部を有するストレージ装置８について説明する。なお、本実施形態では、ストレージ装置８の構成の概要について説明する。
図１８を参照すると、ストレージ装置８は、データ記憶部８１と、一時データ記憶部８２と、データ読出制御部８３と、読出順番情報記憶部８４と、一時データ制御部８５と、を有している。
データ記憶部８１は、重複排除されたブロックデータを記憶する。また、一時データ記憶部８２は、データ記憶部８１から取得されたブロックデータを一時的に記憶する。
読出順番情報記憶部８４は、ブロックデータを読み出す順番についての情報である読出順番情報を記憶する。
データ読出制御部８３は、データ記憶部８１が記憶するブロックデータを読み出して一時データ記憶部８２に記憶させ、当該一時データ記憶部８２からブロックデータを読み出す。具体的には、本実施形態におけるデータ読出制御部８３は、読出順番情報記憶部８４から取得した読出順番情報に基づいてデータ記憶部８１から取得したブロックデータを一時データ記憶部８２に記憶させることになる。
一時データ制御部８５は、一時データ記憶部８２に記憶されているブロックデータの記憶状態を制御する。具体的には、本実施形態における一時データ制御部８５は、読出順番情報に基づいて、一時データ記憶部８２に対するブロックデータの記憶状態を制御する。
このように、本実施形態におけるストレージ装置８は、読出順番情報記憶部８４と、一時データ制御部８５と、を有している。このような構成により、一時データ制御部８５は、読出順番情報記憶部８４が記憶する読出順番情報に基づいて、一時データ記憶部８２に対するブロックデータの記憶状態を制御することが出来る。つまり、ブロックデータを読み出す順番に基づいて一時データ記憶部８２に対するブロックデータの記憶状態を制御することが可能となる。その結果、一時データ記憶部８２が記憶するブロックデータが再利用される前に削除されてしまうおそれや、まったく必要としないブロックデータが一時データ記憶部８２に記憶されたままになるおそれを低減することが可能となる。これにより、読み出し性能が低下することを抑制することが出来る。
［第４の実施形態］
本発明の第４の実施形態を、以下の論文形式にて説明する。
<第1章 はじめに>
<１．１ 動機>
デジタルの世界は毎日どんどん大きくなる。２００７年以来、インターナショナルデータコーポレーションは、デジタル宇宙、つまり、１年間で作成され複製されるデジタル情報の量を評価している。直近の研究が示すところによれば、デジタル宇宙は２年ごとにおよそ２倍になり、２０２０年には４０兆ギガバイトという目を引く数字に達するだろう（図１９参照）。
実質的に、作成された新しいデータの全てがデジタル保存されるため、作成データの量の急激な増大は、ストレージに対する需要が同様に増加することに直結する。保存されるトランザクションデータの平均年間増加は、30‐50%に達する。ライトワンス・リードメニー（書き込みは一度だけ、読み出しは何度でも：WORM）データ、たとえば、医療データ（X線など）や、金融、保険、マルチメディアのデータの増大は、年率100%である。また、多くの地域で、長期間のデータの保管が法律で求められ、ストレージのニーズをさらに増大させる。簡単に再作成することができない企業の戦略データや情報を格納する必要性を想像するのは容易だが、現状が示しているのは、一般的には、公共のインターネットコンテンツをアーカイブすることに対する需要である。理由は、「文化的重要性」の空間として、将来の世代のためにウェブを維持するためである。このようなプロジェクトは、大英図書館によってリードされ、時間をかけて彼らの進化とともに英国のインターネット上の数千のウェブサイトをすでに集めている。
最近の報告でも、私たちのデジタル世界のほぼ75%がコピーであることを示しており、これは、作成されたデータの25%だけが固有のものであることを意味する。２次ストレージ市場でこの数字を見ると、格納されている固有データの5%未満であることを示す。この事実は、重複排除機能を有するシステムが、約１０年前に登場して以来、バックアップ市場で非常に人気になった大きな理由の１つである。実際には全てのデータのうち数パーセントだけを保存する必要があるということにより、過去の任意のバックアップへの簡単なアクセスや災害復旧用のネットワークの効率的な複製などの機能を有効にしたディスクベースのバックアップストレージの価格を著しく下落させた。さらに、利用可能なシステムによってもたらされる高い書き込みスループットは、短いバックアップウィンドウを保証し、このことは、わずかなストレージコストとともに、より頻繁なバックアップサービスを可能にする（予定と維持の両方）。
推定では、専用バックアップアプライアンス（PBBA）と呼ばれるこのようなシステムの市場は、２０１１年には２４億ドル（累計４億６５００万ギガバイト送信）であったが、２０１６年には５８億ドル（累計８６億ギガバイト送信）まで成長するだろう（図２０参照）。
重複排除機能を有する２次ストレージシステムの導入は、たとえば、分散ハッシュテーブル、ストリームチャンキング、消失符号化、高速重複排除などの重要技術で可能になった。バックアップを行うために必要な時間とバックアップを保存するために必要なストレージ空間の両方を低減するアプローチの有効性の試験に、多くの労力が供されてきた。その効果は、市場での人気に見られる。今日では、データ重複排除機能を有するストレージシステムは、バックアップ帯域幅の新たな記録を提供し、世界は多くのベンダーによって提案される様々な重複排除のソリューションで溢れている。実際に、重複排除はバックアップシステムの不可欠な特徴の１つとなっている。
<１．２ 問題の提示>
標準的な磁気ハードディスクドライブ（HDD）上のデータの断片化は、一緒に使用される２個以上のデータが互いに離れて保存されている時に生じるので、それらすべてへのアクセスで実現される性能を低下させる。残念ながら、重複排除バックアップシステムにおける断片化の問題は、システムの主な機能である重複排除自体に直結している。最新の重複排除システムにおいて、データは、書き込まれる前に比較的小さなブロック（たとえば8KB）に分割される。ブロックの一意性が確認された後にだけ、ブロックはディスク上に保存される。さもなければ、既存のブロックのアドレスが返される。このようなブロックは、直近に書き込まれたブロックから遠く離れて保存されている可能性があるので、全く同じストリームのデータをリストアすることが非効率的になる。ここから断片化の話が始まる。
<１．２．１ リストア帯域幅に対する断片化の影響>
リストア帯域幅（必要なときにデータを復元するための時間）は、データ重複排除率（確保可能な記憶領域）と最大書き込み性能（バックアップウィンドウの長さ）とともに、重複排除システムの性能を説明する主な要素の１つである。常連の顧客が作業環境において達成する実際のリストア性能は、多くの場合、様々な理由によってシステムのメーカーによって示されたものとは異なる。具体的に、リストア帯域幅は、通常、空のシステムに保存される最初のバックアップにとっては適度に良好であるが、以降のバックアップにとっては劣化する。これは主に、重複排除によるデータの断片化には、以下のように様々な種類があるためである。
・インターバージョン断片化：同じデータの定期的な（毎日、毎週、毎月）バックアップによって引き起こされる。
・インターナルストリーム断片化：１つのバックアップに同じブロックが何度も登場することに起因する。
・グローバル断片化：互いに論理的関係が無いバックアップに同じブロックが現れることに起因する。
上記の要因のそれぞれを持つ場合のおおよそのコストは、リストア帯域幅の減少として現れるものだが、図２１に示す通りである。この論文では、インターバージョン断片化およびインターナルストリーム断片化の２つを（さらなる分析において発見されるので）、より詳しく検証することにする。
<１．２．２ インターバージョン断片化>
インターバージョン断片化は、今日の市場で最も人気がある、インライン重複排除機能を有するシステムにおいてのみ観察することができる。このソリューションにおいて重複ブロックが保存されることはないので、インターバージョン断片化は、古いバックアップの複数の場所に散在する最新のバックアップに論理的に属するデータを生み出す。この影響はバックアップのたびに大きくなる。なぜなら、バックアップのデータの多くは、実際には、増加する過去のバックアップ内にあり、増加する異なるディスクの場所を示唆している。データセットとその特性評価およびバックアップパターンによっては、実験において、数パーセントから最大50%を超える読み出し性能の低下を示す。このデータセットがカバーするのではせいぜい５０の連続したバックアップであるので、より多くのバックアップが行われた場合、この割合はさらに高くなると思われる。
この最も深刻な後続バックアップの断片化は（なぜなら増加するから）、いわゆる、フォワードポインティング（前向きの：forward-pointing）後処理で回避することが可能である（オフラインで）。このアプローチでは、バックアップは、重複排除することなく書き込まれ、後に、ブロックの最新のコピーを保持するためにバックグラウンドで重複排除が実行される。その結果、断片化は増加せず、最新のバックアップは経時的にこれ以上断片化されない。最新のバックアップはリストアされる可能性が最も高いので、このソリューションは有望だと思われる。残念ながら、これには多くの問題がある。第１に、重複排除前にデータ用にスペースが必要なため、ストレージ消費が増大すること、第２に、重複の新しいコピーの書き込みには、通常、そのようなデータをインラインで重複排除するよりもはるかに（数倍）時間がかかるので、非常に重複したデータの書き込み性能は大幅に低減するということである。後者の問題が、新しいデータの書き込みがネットワークを介してそのデータを転送してディスクに保存することを必要とするために発生する一方で、ハッシュベースの重複排除は、はるかに少ないリソース使用量（ネットワーク、プロセッサ、ディスク）を保証するシステムに保存されているブロックのハッシュに対するブロックハッシュの比較のみを必要とする。
インターバージョン断片化の問題を説明するために、たった１つのファイルシステムのフルバックアップが、バックワードポインティング（後向きの：backward-pointing）重複排除機能を有するシステムに毎週保存されると仮定してみよう。インライン重複排除の場合と同様に、新しいコピーがあっても書き込まれないため、このようなシステムでは、ブロックの最も古いコピーが保存されている。
通常、ファイルシステムは、二度のバックアップの間ではあまり変更されず、二度目のバックアップの後で多くの重複が検出され、これらは再び保存されない。最後には、一度目のバックアップは連続的な記憶空間に配置され、二度目のバックアップの全ての新しいブロックが現在占有されている領域の後ろに保存される（図２２参照）。このようなシナリオは、以降のバックアップ中に継続される。何回かのバックアップの後、最新のバックアップからのブロックは、記憶領域中に散在している。このことは、データを読み出すのに必要な非常に多くのディスクシークと、その結果として非常に低い読み出し性能とをもたらす（図２２の最後のバックアップのリストアプロセススキームを参照）。
このようなプロセスは、緊急リストアにとって非常に有害である。なぜなら、上記のシナリオは、インライン重複排除に典型的であり、ユーザーデータが失われた際にリストアが必要とされる可能性が最も高い直近に書き込まれたバックアップが、最もひどく断片化されることになるからである。
<１．２．３ インターナルストリーム断片化>
大きなリストア帯域幅のペナルティを取り入れ得る要因は、インターナルストリーム断片化である。インターナルストリーム断片化は、インターバージョン断片化と同様に重複排除に起因するが、１つのバックアップだけに限られる。これにより、同じデータの全てのバックアップバージョンに対するほぼ一定の影響や、影響を受ける重複排除バックアップシステム（オフラインを含む）の種類といった、異なった特徴がもたらされる。実験によれば、１つのバックアップからのブロックの17‐33%はバックアップ内に１回以上出現するので、インターナルストリーム断片化のまさに原因となっているインターナルストリームの重複の排除は、一般的に非常に重要である。デフォルトでは、それらのブロックは重複排除機構によって除去されるので、ユーザーデータのための貴重なスペースを節約する。残念ながら、そのためには、リストアが必要な際に見られる最大70%の性能低下の犠牲が伴う。さらなる分析によれば、バックアップシステムでのリストアとともに一般的に使用されるLRUキャッシングアルゴリズムは、上記のシナリオではあまり有効ではなく、ほとんどの場合にメモリを無駄なデータで満杯にしてしまう。
インターナルストリーム断片化の問題を説明するためには、重複排除機能を有するシステムに、ある平均的な数の内部の重複ブロックで１つのストリームのデータをバックアップすれば十分である。システムは、各ブロックのコピーを１つだけ保存するので、正常に順次起こるバックアップは、ディスク上にこれ以上は保存されない（図２３参照）。これにより、データを読み出すために必要な多数のディスクシークがもたらされ、結果として、読み出し性能が非常に低くなる（図２３のバックアップのリストアプロセススキームを参照）。
最後に、内部のデータの断片化は、効果のないキャッシュメモリ消費と小さいリストア帯域幅とをもたらす。しかしながら、その問題の特性は、インターナルストリーム断片化によって引き起こされたものと大きく異なる。第１に、性能への影響は、データセットからの全てのバックアップについて最初からほぼ一定である。第２に、この問題は、全ての重複排除システム（オフラインを含む）に対して同等に重大な形で影響を与える。
<１．３ 論文の貢献>
上述のシナリオを考慮すると、この論文の目的は、書き込み性能と重複排除効果の両方に悪影響を与えることなく、リストア性能の低下を回避することである。言い換えれば、理想的な重複排除のソリューションは、インラインアプローチにより現在提供されているような大きい書き込み帯域幅と、高いリストア性能とを、あらゆる種類の断片化に起因する読み出しのペナルティ無しで達成しなければならない。
この論文の主な貢献は以下のとおりである。
・ユーザから収集した実際のトレースに基づいて、重複排除機能を有するストレージシステム（特にインライン）に固有の断片化問題を、詳細に分析して記載した。
・見つけられた問題を解決するアルゴリズムのための要件と考えられる得失評価を同定した。
・リードキャッシュの有効性を大きく改善し、また、バックアップシステムの特性を活用することによりインターナルストリーム断片化に対処するソリューションとしての、フォワードナレッジ（将来の知識）を有するインテリジェントキャッシュを提案した。
・書き込み帯域幅、レイテンシ、リストア性能、追加領域の一時使用といった、重要な得失評価に対処する多くの機能とともに、重複排除ロスがなくバックアップ書き込み性能への影響が最小限である、インターバージョン断片化に対抗するためのコンテキストベースの再書き込みアルゴリズム（CBR）を提案した。
・選択されたソリューションの有効性を証明するための実際のユーザートレースに基づく一連の実験ともに、提案されたアルゴリズムの要件満足度と得失評価を分析した。
・断片化問題と提案されたその問題のソリューションのスケーラビリティを分析した。
<１．４ 論文の概要>
この論文は次のように構成される。次章では、概して重複排除とストレージシステムに関する情報を提供する。この論文の動機づけ、断片化問題の本質の深い考察、その異なる起源、および、いくつかの例を、第３章に示す。第４章と第５章では、重複排除機能を有するストレージシステムにおいて発生する２つの異なる問題について、ソリューションを提示する。フォワードナレッジを有するインテリジェントキャッシュが、インターナルストリーム断片化の存在下でのリードキャッシュの有効利用を提供する一方で、コンテンツベースの再書き込みアルゴリズム（略してCBR）は、最新のバックアップの今後の復元にとって最も効果的なブロック配置を保証するためにインターナルストリーム断片化を扱う。両方のソリューションについて、議論と得失評価を行う。第６章では、実験で使用した仮説と方法論とともに性能の結果についての議論を含め、様々なユーザから収集された実際のトレースに関して両方のアルゴリズムを評価している。第６章にはまた、両ソリューションのスケーラビリティに関するセクションとともに、ソリューション毎の実験と両ソリューションでの実験とが含まれる。第７章では、断片化問題の他のソリューションとともに、関連の研究を説明している。最後に、第８章では、結論と、可能なアルゴリズムの拡張に関する見識と、将来の研究のための他の方向性について述べる。
<第２章 バックアップと重複排除>
<２．１ ２次ストレージシステム>
<２．１．１ 要件>
バックアップとは、オリジナルが紛失または破損した場合に備えて作られるファイルなどのコピーである。このような単純で簡単そうなタスクは、１台のデスクトップのバックアップに関して言えば、それほど困難そうには聞こえない。しかしながら、数百人のユーザを抱える大規模企業となると、数テラバイトのデータが日々生成され、内部安全上の理由から、毎晩あるいは毎週末に（つまりバックアップウィンドウが短い）バックアップを実行する必要があり、状況は劇的に変化する。たった数バイトしか違わない同じデータセットのバックアップを何度も（毎日あるいは週に１回）保存することを要求するバックアップポリシーも、非常に大規模なシステム（ペタバイトレベル）の容易な管理も忘れることはできない。データセットごとに個別の弾力性を設定する可能性を評価する者もいれば、最も重要な機能である容易なシステム拡張とともに、オンデマンドでの削除（分散環境では非常に複雑である）や、無停電更新といった機能に配慮する者もいる。 簡単かつ高速なリモートレプリケーションも、最も安い費用とともに重要な追加と見られている。期待されるように、これらの２つの制約はそれぞれ、一般的に、簡単には対処されない得失評価をもたらす。さらに、バックアップシステムが存在する主な理由について覚えておく必要がある。すなわち、緊急リストアである。費用の高いダウンタイムを最小限に抑えるための高速リカバリがなければ、他の全ての機能はそれほど魅力的には見えない。
以降のセクションを理解するために必要な、２次ストレージ（バックアップ）と１次ストレージとの違いを強調することが重要である（図２４参照）。後者のシステムは、人々が自分のコンピュータ内のハードディスクを使用するのと同様の方法で、日常的なタスクのために使用されるものである。バックアップでは、巨大なストリーミングスループット、データ回復力、および、最大限の容量を期待するだろうが、ここでは、ランダムアクセスを必要とする動作を含めた全ての動作（読み出し/書き込み/削除）にとって、低いレイテンシが非常に重要である。一方、同じ１次システムおいて、帯域幅とデータ回復力は、重要ではあるが、大抵は必要とされない。バックアップ動作毎のクリティカルパス上で行われる、圧縮、暗号化、および、データ重複排除といった機能を考慮すると、このような小さいが微妙な違いが一層大きくなる。
バックアップシステムの要件は以下のとおりである。
・緊急時における高速でのデータ復旧
・大きい（そして拡張可能な）容量
・非常に大きいバックアップ帯域幅（小さいバックアップウィンドウを可能にするため）
・リモートレプリケーションオプション（好ましくは修正されたデータのみ）
・設定可能な、保存データの弾力性
・オンデマンドでの削除
・システムのサイズに関係ない、簡単な管理、アップグレード、および、ストレージの追加
<２．１．２ 歴史>
最初の汎用コンピュータは１９４６年に構築され、バックアップの進化は非常に短期間であるように見えるが、それはまた非常に強烈なものである。最新のデバイスは1TB以上を保存することができるが、最初の利用可能なパンチカードが保存できるデータは、100バイト未満であった。このような短い期間での大きな飛躍は、各ユーザがコンピュータ経験から最大限引き出すための技術を開発することに投入された作業量を表すものだ。
パンチカードはバックアップとして考えることができる最初の媒体であり、１９世紀末から既に使用されていた。コンピュータが出現すると、パンチカードは、企業コンピューティングにおけるデータの保存、入力、および処理に最も広く使用される媒体になるために（１９５０年代）、簡単に取り入れられた。パンチカードは、コンピュータのバイナリ処理命令を格納するために使用されたので、コンピュータプログラマーにとって不可欠だった。実際に、アメリカ航空宇宙局は初めての月への有人宇宙飛行の際に計算を実行するためにパンチカードとそれを読むコンピュータを使用した。幸いなことに、正確なコピーをパンチすることや一度に２枚のカードをパンチすることは、インスタントバックアップを生成するための簡単な方法だった。
パンチカードの使用が急速に増えるにつれて、それらを格納することが大変になった。最終的にはパンチカードのカートンを積み重ねて収容する大きな保管設備を必要とした（図２６参照）。この問題は、当時一般的になりつつあった磁気テープによって解決されることになった。とは言え、１９８０年代半ばまで、パンチカードプログラムは依然として使用されていた。
磁気テープ１巻は、パンチカード数万枚と同程度に記憶可能なので、１９６０年代には、バックアップ用の主要媒体として徐々に普及した。その信頼性、拡張性、および低コストが、１９８０年代に、この技術をバックアップ実行のための最も一般的な方法にした成功の主な理由であった。以来その技術は、より大きな帯域幅とより良いデータ密度を提供するために改良された。２０００年９月に、ヒューレットパッカード、アイビーエム、およびシーゲートによって開始されたコンソーシアム（そのテープ部門はサータンスとして分社化され、現在はクアンタム社の一部）は、これまで開発され使用されていた共通基準を導入したリニアテープオープン(LTO) ウルトゥリウムと呼ばれる技術を発表した。最新世代（LTO-6）は、２０１２年６月に発表され配信された。6.25TBの容量と400MB/sのレベルでのデータ転送速度に、ライトワンス・リードメニー（WORM：書込みは一度だけ、読出しは何度でも）や暗号化、分割などの機能を備える。自動化と、一度に多くのストリームへの/からの転送とを提供するために、多くのテープドライブを備えた専用のロボット/ライブラリが用意されている（図２６参照）。
ハードディスクドライブ（HDD）の導入は、その価格の高さ、サイズの大きさ、および容量の少なさのために、バックアップ市場であまり変化しなかった。データへのランダムアクセスの可能性をもたらした新技術は、デスクトップで初めてその居場所を見つけ、１９８０年代の終わりには、バックアップにも使用された。この方向でのさらなる開発は、極めて小さなデータの世界では依然として一般的な、独立ディスクの冗長アレイ（RAID）の導入のおかげで可能ではあったが、大きさと弾力性の制約は、中規模および大規模企業にとってあまりにも厳しいものであった。２０１３年には、１台の3.5インチハードドライブが、4TBもの容量と200MB/sを超える転送速度とを提供することができた。これらの値は、最新のテープで可能な数値と同等であるにもかかわらず、支払わなければならない価格は数倍高い。
ネットワークアタッチトストレージ(NAS)、および、ストレージエリアネットワーク(SAN)によってサポートされるローカルエリアネットワークが、バックアップ市場における次のビッグプレーヤーとなった。データを遠隔で維持することで、バックアップがより便利になり（添付する追加メディアなし）、より速く簡単に複製することが可能になる。また、ハードドライブの使用は、任意のデータに瞬時にアクセスすることや、重複排除などのアルゴリズムの使用を可能にし、バックアップをより効率的ではるかに安価にすることができる。新世紀以来、バックアップシステムは、ネットワークを介して接続されるだけでなく、以前は不可能だった機能を提供することができるノードの独立したリビングコミュニティになることができる。１つのシステムで多数のサーバを使用するため、マシンやスイッチの故障があっても、どんなディスクでも自動ヒーリングプロセスとともにインテリジェントなデータ回復力を得ることができる。さらに、短いバックアップウィンドウ内に多くの異なるソースからデータを収集することを可能にするために、全てのコンピュータを協働させることで、巨大なレベルのスループット（900TB/hr超）と容量（100PB超）を提供できる。今日利用可能なシステムは、かなりローカル、つまりデータセンターサイズであるにもかかわらず、長い距離を介してデータを複製するために互いに通信し、新規の部分や変更された部分のみを転送することができる。一方、クラスソフトウェアは、重要機能を一式提供し、容易なクラスタ管理を可能にし、NFSやCIFSなどのネットワークインタフェースを介して１つの統合空間としてシステムをエクスポートするインタフェースを提供する。低価格と、潜在的に無限のスケーリング可能性と、より高密度なディスクドライブは、重複排除技術と組み合わされ、また、リモートレプリケーション、負荷分散、耐障害性、高速リカバリにサポートされて、専用バックアップアプライアンス（図２７参照）として知られるシステムを、今日の短期中期のバックアップソリューションとして最初の選択肢にした。
フラッシュストレージは、他の種類の使用において、現在のスピンドルベースのディスクの論理的な後継者であると思われる。フラッシュストレージは、高速で、必要とする電力が少なく、大規模なインデックスへのアクセスやストリームデータの断片化などの問題を防ぐ（ストリームアクセスはもはや必要ない）。残念ながらフラッシュストレージにはいくつかの無視できない欠点があり、そのため、特にストレージスペースを大量に必要とされる場合など、ビジネスソリューションにとって良い選択肢とはならない。1GBあたり1ドルを下回る価格のSSDドライブを見つけることができるが、それでもスピンドルを持つ普通のドライブのために支払われる0.05ドルには程遠い（私の論文：2013年6月）。このような価格と一般的に数倍小さい最大容量のため、近年は価格がかなり下落し続けているという事実を考慮しても、何らかの革命を想定することは難しい。一方、小さな進化はここでも可能であり、ゆっくりと起こる。最近の研究が示すように、SSDドライブは、大規模なインデックスと重複排除スループット改善のために、非常に簡単に採択することができ、今日のバックアップにおいて非常に有用であると思われる。
過去３０年にわたって、バックアップソリューションとして使用可能な他の多くのメディアが登場したが、特に企業環境においては一般的になっていない。最も一般的なデバイスは、フロッピーディスク、コンパクトディスク（CD）、多用途ディスク（DVD）、HD-DVD、ブルーレイなど、様々な種類のディスクであった。それぞれの容量や転送速度、その他の指標は徐々に良くなったが、ハードディスクやテープと競合するにはまだ十分ではなかった。主な問題は、ここでも、価格、アクセス時間、少なすぎる記憶領域、そして複雑な管理である。
バックアップの最新のアイデアは、オンラインバックアップとして知られており、クラウドという概念と関連している。これは、オフサイトのサーバに独自または公共ネットワークを介してデータのコピーを送信することを含む、データをバックアップするための戦略である。通常、サーバは、容量や帯域幅やユーザ数に基づいてバックアップの顧客に料金を請求する第三者のサービスプロバイダによって主催されている。オンラインバックアップシステムは、典型的には、顧客が購入したサービスのレベルによって決まるスケジュール上で動作するクライアントソフトウェアアプリケーションを中心に構築されている。消費される帯域幅の量とファイル転送にかかる時間を短縮するために、サービスプロバイダは、最初のフルバックアップ後は増分バックアップだけを提供してもよい。第三者のクラウドバックアップは、その利便性のため小規模オフィスやホームユーザーの人気を得ている。追加ハードウェアへの多額な支出を必要とせず、また、バックアップはダークに、つまり、手動の介入なしに自動的に実行可能であるからだ。企業においては、クラウドバックアップサービスは、非重要データだけをアーカイブするために主に使用されている。従来のバックアップは、短い目標復旧時間（RTO）を必要とする重要データにとってより良いソリューションである。なぜなら、ネットワークを介して一定時間内に移動可能なデータの量には物理的な限界があるからだ。大量のデータを回復する必要がある場合には、テープその他の携帯型記憶媒体で送る必要があるかもしれない。ここで最も重要な問題は、データセキュリティ、可用性、プライバシー、および、いくつかの未定義の方法でサービスプロバイダがデータを使用することの危険性である。特に大企業は、コントロールを手放すリスクを取ることなく自社のシステム内に機密データを保持することを好むだろう。重要なのは、ここで使用される技術は上述のネットワークバックアップと基本的に同じまたは極めて類似のままであるということだ。異なるのは、両者間で必要な契約、使用されるソフトウェア、顧客とサービスプロバイダ間の相互作用の概念である。
<２．２ 重複排除>
重複排除は、一般的に、冗長データを排除する技術と定義される。データが重複排除された場合、重複した情報の１つのインスタンスが保持され、重複するインスタンスはこの１つのコピーへのポインタに置き換えられる。全体のプロセスはユーザやアプリケーションから完全に隠されており、使いやすく、いかなる専用ソフトウェアの変更も必要としない。
比較と発見を簡単にするために、各データは、データ自体よりもずっと短い固有の識別子を必要とする。２次記憶装置では、そのような識別子は、記憶されるデータの内容に基づいて算出され（通常はハッシュ関数を使用して）、専用のインデックスを使用して、既存の入力データを見つけることを容易する。このような方法で自分のデータを識別するシステムは、コンテンツアドレッサブルストレージ(CAS）と定義され、すでに10年以上の研究分野となっている。
<２．２．１ 特徴>
粒度
データ重複排除は、一般的に、ファイルレベルまたはブロックレベルで動作することができる。前者では、重複ファイルを排除するが、最小限の変更でも全てのファイルを異なるファイルとして再度保存する必要があるので、一般的にはあまり効率的な重複排除方法ではない。ブロックの重複排除では、ファイル内で検索して小さなブロックにチャンクする。各ブロックはその後、記憶されて索引付けされる一意のハッシュ値を生成するために、SHA-1やSHA-256といったハッシュアルゴリズムを使用して処理される。ファイルが更新された場合、変更されたデータのみが保存れる。すなわち、ドキュメントまたはプレゼンテーションの数バイトだけが変更された場合には、変更されたブロックのみが保存される。この動作により、ブロックの重複排除は、はるかに効率的になる。しかし、ブロックの重複排除は、より多くの処理能力を要し、個々のピースを追跡するために、はるかに大きなインデックスを使用する。
アルゴリズム
ブロックレベルでの重複排除アルゴリズムのための２つの主な抽象的概念は、固定サイズおよび可変サイズのチャンキングと呼ばれる。多くのテスト後、固定長のブロックの場合、予定された更新とうまく動作しないことが判明した。ファイルの初めでのまたは途中での数バイトの簡単な修正により、以下の全てのコンテンツは、そのサイズを維持するために、異なるブロック境界を持つ新しいデータとして再書き込みしなければならなかった。一方、可変チャンキング長は、変更が行われた直後にブロック境界の同期を可能にする専用のアルゴリズム（ラビンフィンガープリンティング：Rabin fingerprinting）を使用する。そのおかげで、変更されたファイルの後半は、同一のブロックに分割可能であり、これらのブロックは、変更されていないオリジナルファイルのバックアップ後に既に存在するブロックに重複排除することができる。
一般的に、現代のシステムにおいてこのような方法で作成されるブロックのサイズは、どこか途中に平均値を持つ境界内（たとえば4‐12KB）にある。使用される最も一般的な平均値は、4KBと64KBの間にあり、重複排除の範囲やデータ断片化といった他のシステムの特性とともに、全体の重複排除率に大きな影響を与える。いくつかの専用アルゴリズムは、１回のバックアップ（64KBを8KBで）の間に、多くの異なるブロックサイズの使用を可能にすることによって、この影響を最適化しようとする。研究が示すように、結果は非常に有望である。
適用のポイント
２次ストレージシステムは、バックアップを実行する一群のクライアントによって使用されている。各バックアップストリームはブロックに分けられる必要があり、各ブロックについてハッシュ計算を行い、これによりシステム内でその存在が確認される。これらの動作は、クライアント側またはサーバ側で行うことができる。前者は、ソース重複排除と呼ばれ、クライアントにインストールする専用のソフトウェアが必要になるが、ある処理能力（ハッシュ計算）の費用で、ネットワーク使用をはるかに少なくすることができる。一方、後者は、ターゲット重複排除と呼ばれ、クライアントにとって完全に透明で、単純にネットワークインタフェースを介して記憶領域を提供するので、ハッシングやその他全ての内部で必要な動作の実行を非常に簡単に利用することができる。どちらのオプションも市場で入手可能であり、顧客の要望に基づいて展開される。
適用時間
ターゲット重複排除機能を有するシステムには、プロセスが適用される時間が異なる２つのグループがある。オフライン（後処理）重複排除は、最も簡単な方法であり、第１段階で、現在のバックアップからの全てのデータがシステムに連続的に保存される。動作が終了した後、最新のバックアップからのブロックが古いバックアップから重複を排除するためのベースとなるように、実際の重複排除がバックグラウンドで実行される。このようなアプローチでは、最新のバックアップからの全てのデータが１つの連続した空間に配置されて読みやすい一方で、多くの様々な問題を引き起こす。しかしながら、問題なのは、バックアップ性能が数倍も低いことと、ネットワークやディスク帯域幅を節約する可能性がないこと（すなわち、クライアントまたはバックアップサーバー上での重複排除）と、全バックアップウィンドウに相当する生データを保持するための領域（ランディングゾーン）を保持する必要があることである。ランディングゾーンは、重複排除処理を早く開始してパートごとに行うこと（ステージング）によって最小限に抑えることはできるが、その動作に必要なシステムリソースが現在のバックアップを遅くし、新たな悪影響を加えることになる。さらに、オフラインプロセスでは、各バックアップの後でそのサイズの約95%が（重複排除率が20:1であると仮定して）ストレージスペース全体の中で発見されてバックグラウンドで削除する必要があるので、非常に高価なものとなる。
もう一つは、インライン重複排除と呼ばれ、重複データは書き込み処理中に必ず発見され、システム内に既に存在するブロックを保存することは決してない。その場でブロックの存在を確認し、その結果に応じて重複ポインタか新しいポインタを戻すためには、高速アルゴリズムが必要である。このようなパスは一般的に複雑であるが、重複データがシステムで検出されないことを確認することで、バックアップ後のクリーンアップが不要となる。また、ハッシュの有無をチェックすることは（多くの場合、メモリ内に配置されたインデックス内）、ディスク上に新しいブロックを保存するよりも３倍速いので、はるかに良い帯域幅を提供する。この方法の問題点は断片化が進むことであり、この論文の次章で詳細に説明する。
範囲
重複排除の最後の特性は、その範囲に関する。システム内に存在する各重複ブロックが常に特定される、最も直感的なグローバルバージョンは、出現する実装および技術的な問題のために一般的ではない。主な問題は、巨大なグローバルインデックスであり、常に最新の状態にされて、必要なブロックの高速な識別を可能にしなければならない。ここでの課題の１つは、ブロックが重複しているか否かを識別することだ。これは多くの場合、ブルームフィルタを用いて行われ、グーグルのビッグテーブル（Google’s Big Table）やデータドメイン（DataDomain）のような分散システムで使用される。それは、発見されないブロックのための高額な探索を回避するのに役立つ。一方、インデックスキャッシングやディスク上でのチャンクのレイアウトのために、大きなブロックサイズを使用したりチャンクの局所性を利用したりするといった手法は、RAMに必要なデータの量を減らす。その結果、ディスク上に置かれている完全なインデックスにアクセスする必要がある要求は、ほんのわずかだ。分散環境に入ると問題はさらに複雑で、タスクに対処するために専用の分散ハッシュテーブルを使用する、グローバル重複排除（HYDRAstor：ハイドラストア）を有する市販のシステムしかない。
他の既存のソリューションは、集中型の手法であるか（EMCデータドメインなど）、または、重複排除を犠牲にして必要なメモリを制限する様々な手法の使用である。たとえば、疎索引作成（Sparse Indexing）は、計算されたハッシュに基づいて、最も類似したいくつかのセグメントにだけ重複排除を可能にする技術であり、エクストリームビニング（Extreme Binning）は、低局所性を有する個々のファイルからなるワークロードのためのより良い結果を達成するために、ファイルの類似性を利用する。
<２．２．２ 重複排除率>
重複排除率は、データストリーム特性化、チャンキングアルゴリズム、ブロックサイズ、保存ポリシーに依存して広く変化し得る。研究論文が確認したように、全ての格納データに関連するメタデータサイズも、ハッシュの計算やメタデータの更新を行い、データを保存／検索するために必要な性能とともに考慮されなければならない。最後に、システムのスケーラビリティとデータを再構築するための時間とに関する問題について留意する必要がある。上記の全てが重複排除率に確実に影響を与え、重複排除率は4：1から200：1以上の範囲を取り得る。つまり、10‐20倍以上の圧縮（元の記憶容量の5%未満）が達成可能であり、それは、他のソース、すなわちビジネスと科学の両方で確認されるいくらかの偏差である。
最近のほとんどのバックアップシステムは、セクション２．２．１で説明するその利点から、可変サイズのチャンキングを使用する。多くの論文に示されたように、可変ブロックサイズの平均値目標は、データ重複排除率に顕著な影響を与える。データだけを見ると、スペース節約の面で小さいブロックほど性能が良いと期待するが、起こり得る問題について思い出す必要がある。小さなブロックの使用は、より大きな必要メモリ（より大きなインデックス）、バックアップ性能の劣化（より多くのブロックを検証し送付する）、リストア帯域幅の問題の原因となるデータ断片化（より小さいランダムな読み出しの可能性）を引き起こす。さらに、データの各ブロックは、小さいが目立つ、データサイズに依存しない、格納されたメタデータを必要とする。残念ながら、これを考慮すると、より小さなブロックサイズを適用することによって提供される全ての節約を無駄にする可能性がある。市場を見ると、使用される最も一般的なブロックサイズは8KB（EMCデータドメイン −グローバルリーダー）だが、その一方で、64KB（NECハイドラストア）や4KB（HPストアワンス）というブロックサイズとも競合が存在する。
結局のところ、バックアップのたびに、ある個別に定義されたブロックサイズで最良の重複排除が行われる。また、最良の結果を達成するために、ストリームの各部分は、その修正スキームに関して異なるサイズのセグメントに分割することができる。概して問題は非常に複雑に見えるが、いくつかの単純化されたソリューションは、１回のバックアップ中に２つのサイズのブロックを使用するようだ。ブロックを小さくすべきか大きくすべきかの決定は、以前に格納された情報に基づく。ロマンスキーらによると、このようなアプローチは、ほぼ３倍の平均ブロックサイズで達成される、15%‐25%の重複排除率の改善をもたらすことができる。
重複排除率を計算する時にしばしば過小評価される要因が保存ポリシーである。重複排除の最大の力は、同じデータの過去のバックアップからの重複の排除に由来するので、このようなバックアップの数に関する情報は、計算のために重要である。１例としてファイルシステムのサイズを1 TBとし、変更率を１日あたりブロックの1%のレベルと仮定しよう（計算を簡略化するために、バックアップではサイズは増大せず、ランダムなブロックが毎日変更されると仮定する）。このようなシステムでは、ユーザは３つの単純なバックアップポリシー、すなわち、毎日、毎週、毎月のいずれかを選択することができる。各バックアップポリシーは、フルバックアップが実行される頻度を定義する。各ポリシーにおいて１年後には、システムに占めるデータの量は同様だが（4.1TB‐4.6TB）、書き込まれたデータの量は有意に異なる（12TB‐365TB）という結果になるだろう。したがって、各ポリシーで計算すると、全く対照的な重複排除率、すなわち、78.49、11.48、2.91となる（図２８を参照）。各ポリシーは、単純に固有であり、異なるコストで（すなわち、月内にバックアップに費やす時間）異なる方法でデータを保護する。この計算が示すことは、それぞれの具体的なケースは固有のものであり、重複排除率だけを考慮するとそのケースの欠点が生じる、という事実だけである。一般的に、バックアップにおける重複の平均数は（最初のものを除く）、重複排除パワーの指標としてより正確であると思われる。
増分バックアップかフルバックアップかの選択をする場合にも、同様の効果を得ることができる。前者は、おそらくより少ない時間で実行されるが、最新のフルバックアップとして最終的にデータをリストアするにはより多くの時間がかかり、所定の時間までの全ての増分が一緒にパッチされる必要がある。後者は、より多くの時間を要するが、重複排除のおかげで、それほど多くのストレージ容量を消費しない。統計的観点から、保存されるデータは同様であっても両者における最終的な重複排除率が非常に異なるようだ。
圧縮は、データがシステムに保存される前に通常適用されるもう一つのタスクである。重要なデータだけを保持するには、圧縮して将来おそらく解凍するために、より多くのプロセッサパワーが必要かもしれないが、多くの場合、全体のデータ削減率（重複排除率とともに圧縮）を２倍以上高めることができる。このような省スペース化は、通常、圧縮がより有効となる大きなブロックサイズで特に努力の価値がある。
最後に、重複排除率に対する基本的な影響は、個々のバックアップストリーム特性を有している。ストリームコンテンツとその内部冗長性が、重要なスタートである。映画データベースの最初のバックアップを行っても節約は全く見られないだろうが、メールボックスを例にとると、最初のバックアップで、システムに保存されている固有データの50%未満になる可能性がある（重複排除率を２倍向上させる）。２回めのバックアップからは、通常、重複の割合は安定するが、データセットごとに異なるレベルである。これは多くの場合、変更率／パターンとバックアップ間の時間による。システムに保持されるフルバックアップの回数と合わせてこれら２つの数字が、達成される最終スコアに大きな影響を持つことになる。
<２．２．３ 利点>
重複排除はあらゆる環境で使用可能であるが、３０乃至９０日間にわたって復旧プロセスのために複数回同じデータセットを繰り返しコピーして保存することが必要な、バックアップのような冗長性の高い動作にとって理想的である。記載の使用パターンによれば、この技術は、特に有用であり、保存されるデータが２０倍以上削減される結果となる（多くの様々な特徴による。詳細はセクション２．２．２を参照）。このような結果は、大きく経費を節約させるか、あるいは、以前は達成できなかった可能性を実現することができる。
おそらく、２次記憶装置へのデータ重複排除の導入による最も重要な成果は、その分野における大きな技術的飛躍である。必要なストレージ容量を制限することにより、以前は高価であったディスクベースシステムがテープと競り合うことを可能にし、以前は利用できなかった２次記憶世界の機能になる。その機能とは、データへの即時かつランダムなアクセス（緊急リストア）、高転送レート、１つの結合された記憶領域、多くのバックアップストリーム、安価で定義可能なデータ回復力クラス、簡単かつ高速のレプリケーション、および、維持されたデータ整合性である。
さらに、データの短いハッシュ（160ビット）に基づいてデータの存在を確認する可能性を有することで、ネットワーク帯域幅を節約する道が開かれる。専用のソフトウェアが、クライアント側でハッシュを生成して（ソース重複排除：セクション２．２．１参照）、システム内に存在しないデータだけを送信するために使用される。ハッシュサイズがデータサイズの0.5%未満であり、重複排除率が20:1であると仮定すると、通常バックアップを実行するために、ネットワークを介して全データの中の5.5%を転送すればよい。このようなアプローチによって、プロセスがはるかに高速になる（バックアップウィンドウが小さくなる）だけではなく、クライアントからのネットワークが高い帯域幅値を許容する必要がなくなる。この機能は、マスターとレプリカとが別々の州または国に置かれている場合のレプリケーションでは、さらに重要である。
一般的に、データ重複排除技術は、既存のソフトウェアに追加される１つの機能であるだけではない。２次記憶装置における全く新しい時代、すなわち、即時のランダムアクセス、超高帯域幅、定期的なデータモニタリングなど、提供する全ての機能を備えたサーバとハードディスクの時代の始まりである。ネットワーク節約的なレプリケーションおよび競争力のある価格に支えられて、この技術は、２次記憶の面で完全かつ十分なソリューションを生みだす。
重複排除システムで利用可能な新機能：
・高い書き込みスループット（既存のブロックを保存する必要はない）
・利用可能な物理容量の増大
・特異データだけの簡単なレプリケーション
・ネットワーク帯域幅の節約（ソース重複排除およびレプリケーション）
・下記と一緒にバックアップ用のディスク技術を可能にする
数秒以内のランダムアクセス
迅速な緊急リストア（一度に多数のディスクから）
複数のストリームアクセス
ファイルシステムのインタフェース
設定可能な回復力クラス
維持されているデータ整合性と自己回復
<２．２．４ 欠点および懸念>
データがどのように変換されたとしても、ユーザはその整合性を心配するだろう。重複排除プロセスは、システムのどこかにあるブロックの同じコピーを探し、結果として、ディスクやサーバ上の様々な場所に散在するあるストリームのデータをもたらすだろう。このような記憶領域を節約する方法によれば、メタデータ内のどこかに保存されている正確なレシピ無しに、書かれているのとは正反対の方法で、必要なデータを読み出すことは、ほとんど不可能になる。こうしたことは、ベンダーからのソフトウェアの品質に対する高い要求を置き、顧客からのプロセスに対するかなりの信頼を示唆する。
各重複排除システムは、ブロックの同一性を検証するためにそれらのブロックを見つけて比較できなければならない。前述したように、ハッシュ関数は検証候補を見つけるための簡単かつ効果的な方法であるが、そのような候補を読み出してその内容を新たに書き込まれたブロックで１バイト毎に検証すると、保存プロセスは非常に時間を消費するであろう、ということがわかる。このオーバーヘッドを除去するため、産業界は、２つのブロックの同一性を判断するためだけに、ハッシュ比較に依存している。当然ながら、確認されたことであるが、理論的には160ビットまたは256ビットの長さを有する１つのハッシュが多くの8KBブロックを識別するために利用可能であり、耐衝突機能（すなわち、SHA-1）とシステムに保存可能なブロック量とを想定すると、このような衝突の可能性は非常に低く、ハードウェアのエラー率よりも小さい。データの破損が生じた場合は、それはおそらくむしろ入出力バス、メモリ、またはその他のハードウェアコンポーネントに問題があるだろう。
もう一つの懸念は、アルゴリズムおよびその他の要求される機能を実行するために必要な計算能力に関する。ソース重複排除の場合のように、計算の少なくとも一部は、クライアント側で、したがってそのパワーを使用して実行されるが、ターゲットソリューションの場合は、専用ハードウェアにおいてベンダーが送るもの以外には追加の計算能力は要求されない。システムに必要なエネルギーのコストは、購入前にソリューションを比較する初期段階で計算する必要がある。
最後に、多くのディスクや何十何百台のサーバを有するシステムについては、アクセス可能な全てのデータを保持して解放しないことは問題であるかもしれない。このようなシステムは、かなり容易な管理を可能にするために、効率的な分散アルゴリズムと、自己修復機能と、組み込みインテリジェンスとを必要する。何千ものディスクで、１つを制動する可能性は極めて高くなるので、全体的な可用性を損なうことなくディスク／ノード交換を簡単に行うことを可能にする機能が重要になる。幸いなことに、7.9PBの物理容量を保証する１００個を超えるノードを持つ構成で動作可能であるという上記の全ての機能を有するシステムが存在する。
<２．３ 今日の市場>
情報記憶産業協会（INSIC）によると、テープ技術の使用は、２次記憶として過去３０年にわたり最も一般的であったが、近年では移行しつつある。このシステムは、バックアップシステム市場から、３次バックアップ（アクセスの少ないまたはアクセスの無い長期保存バックアップ用にごく最近作られたカテゴリ）、アーカイブ（長期保存のために移動されるデータ）、そして、規制順守データ（規則で定義された期間保存される）へと移っている。これら全ての使用ケースには、データの１つのコピーを、大抵は全く読み出さずに長期間保持することが含まれる。これらの目的のために、テープは、価格、優れた持続時間、低いエネルギーコスト、および、重複排除要件が無いことにより、より良い選択肢だろう（図３０参照）。
上記の傾向は、データ重複排除ソリューションの使用について様々な組織に尋ねた場合に見られる。３００人以上の回答者に対してエンタブライズストレタジーグループが２０１２年に行った調査では（図２９参照）、回答者の76%が重複排除ソリューションを使用したことがあるか使用する予定であることが示された（２００８年の43%と比較）。一方、市場自体によって発現された数字がある。２０１１年のテープ市場全体では（アーカイブその他の目的を含め、メディアやロボット工学とともに）、最終的に合計３０億ドルであり（10%下落後）、そのうち、重複排除システムは２４億ドルであった（43%上昇後）。テープ市場は依然として大きかったが、通常の２０倍の重複排除率、高い書き込み帯域幅、拡張性、リモートレプリケーションのし易さ、そして、緊急リストアの速さが、企業で決定がなされる場合に重要だとみなされるようだ。
重複排除システムは、急速に成長しているが、テープの使用を完全に排除するつもりはおそらく無い。企業から収集されたデータが示唆しているように、重複排除システムはむしろ、ディスクベースシステムとテープシステムの両方をバックアップに使用しようとしている（２００８年の53%と比較して、２０１０年には62%）。上記の情報をすべて大局的に見ると、６か月までのバックアップ用の主要な構成要素としてディスクベースシステムを用い、より長い保持期間を要するアーカイブやデータ用にテープを用いたデータ保護の最も成功した方法論としてディスクアンドテープモデルを使用する傾向があるようだ。
重複排除のおかげで、グローバルな２次記憶における二番目の大きな一歩が進行中であることは間違いない（最初の一歩は、１９８０年代のパンチカードからテープへの移行であった）。一方、ここ数年の間に掲載された論文の数は、広範な研究の下にそのトピックを置く。このスケールでは、革新的なアプローチ、アルゴリズムまたは発見の一つ一つが、世界中のベンダーからシステム管理者まであらゆる者に大きな影響力を持つだろう。多くの知識が既に提示されているにもかかわらず、発見されるのを待っている戦略的な領域が残っている。その一つが、重複排除の副作用であるストリーム断片化であり、一般的にはクリティカルリストアである。
<第3章 ストリーム断片化の問題>
<３．１ バックアップシステムにおけるリストアの役割>
リストアは、バックアップほど頻繁には発生しないが、データが失われた場合だけではなく、フルバックアップをストリーミングして、変更されたデータをテープに保存して（３次バックアップ）オフサイトに複製するためにも使用される。その結果、実際には書き込みより読み出しの方が多いシステムが全体の20%である一方、レプリケーション動作を除外したとしても、平均すると、読み出しが平均的なバックアップシステムにおける全ての入出力の約26%（平均；中央値9%）を占めている。
バックアップシステムからデータをリストアする試みは、多くの理由で引き起こされる。全てのデータに容易にランダムアクセスするディスクベースシステムを考えると、ファイルを誤って削除した場合やある文書の古いバージョンにアクセスする場合が、実際に、短時間で処理すべき最も簡単な要求の一つである。一方、何ギガバイトものデータからなるフルバックアップをリストアすることは、最大帯域幅を何時間も提供するという全く異なる問題である。このような状況は、必ずしも会社の機能停止を意味するものではないが（他の場所へデータを転送すればよい）、最初の段階で極めて上手く処理されるべきケースであるにちがいない。目標復旧時間（RTO）は、バックアップシステムの仕様の最も重要な要素の１つであり、実際に大多数の企業に合理的なバックアップシステムへの数千ドルの投資をさせる。この分野でのあらゆる緊急課題は、バックアップシステムに対する主要なテストと企業にとっての投資の最終的な検証であると見ることができる。
通常のリストアプロセスを分析すると、その特徴のいくつかに気づくことができる。非常に重要な特徴は、あらゆるバックアップが同じ重要性を有するわけではなく、これにより、リストアプロセスが様々な評価をされる、という事実である。第１に、会社にとって単純にあまり重要でないデータそのものである。第２に、バックアップが取られた時間と緊急時リストアにとってのその有用性である。図３１は、５１０人の回答者にエンタブライズストレタジーグループが行った調査の結果を示す。予想通り、最も頻繁にリストアされたデータは、直近にバックアップされたものである。この結果によると、２週間以上前にリストアされたものは全体のわずか6%であり、大半（58%）が過去４８時間以内にリカバーされている。
つまり、上記の全体像から、バックアップシステムの真の価値を検証する明確な目標ができる。それは、最新のバックアップのリストア帯域幅である。この意見は、ごく些細なことにも聞こえるが、今日の社会で将来的に最も一般的になるであろう重複排除機能を有するバックアップシステムにとっては大きな重要性がある。
<３．１．１ バックアップの手順>
各企業は独自のバックアップポリシーを持っており、それは、データの安全性と災害復旧要件に対する最良の答えでなければならない。最も一般的な戦略の１つは、会社の全データのバックアップを週末に実行し、より小さな増分バックアップを毎日実行することだ。これは、通常、バックアップウィンドウ（バックアップを終えるために利用できる時間）が毎営業日には非常に制限されているが週末には増大する、ということに起因する。重複排除システムを使用すると、新規データおよび変更データ（その大きさは増分バックアップにほぼ等しい）だけを実際に保存するというソリューションと同様に、毎日でもフルバックアップを行うことができる一方、他の全ての重複データは、プロセスを通常のフルバックアップよりも何倍も短くするバックアップアプリケーションに対して非常に素早く確認される。
バックアップポリシーの次の特徴は保存期間であり、企業によって異なってよい。当初の考えは、緊急リストアの際に役立つ可能性が低いバックアップに使用されるスペースを制限することであった。通常、選択肢は、いくつかの（通常５乃至３０）最新の日毎のバックアップ、およそ４乃至２６の週毎のバックアップ、１２乃至２４ほどの月毎のバックアップ、そして数個の年毎のバックアップを維持することであった。非常に頻繁に、３ないし６ヶ月以上前のバックアップが、いわゆるアーカイブストレージに移動され、これは、有用性が極めて低い可能性を示唆する。重複排除システムを導入した後のシナリオは、緩やかに変化している。新技術のおかげで、各追加のバックアップは、ストレージスペースに新しいデータをほとんど追加せず、そのため、企業は、実際のデータや修正だけを維持するよりもほんの少しだけ多く（メタデータ）を支払って、日毎バックアップを一年間維持することができる。このような技術を持つことは、極めて低価格で高精度のバックアップを可能にすることができ、経過時間に関係なく必要な日付から所定の文書の正確な状態をリカバーするのに最終的に役立つ可能性がある。
１つのバックアップ手順を見ると、もう１つの単純だが非常に重要な事実に気づくことができる。その事実はデータの順序と位置に関する。各ストレージシステムは、通常、いわゆるストリームでデータを受信する。これは、始まりと終わりとを持つ、ある定義された論理的な順序のバイト列である。通常、バックアップアプリケーションは、保存先であるファイルシステムやディレクトリからこのようなストリームを作成する役割を持つ。 NFSまたはCIFSを介して直接搭載されたストレージファイルシステムの場合には、ストリームは、転送された各ファイル（通常はかなり大きいtarアーカイブ）に相当する。論理的な順序を有することで、各ストリームは、そのデータへのあらゆるアクセスが、書き込み時と同じ順序で順次行われることを保証する。この仮定は、全てのバックアップシステムにとって重要であり、これらのシステムが優れた性能を実現することを可能にする。データへの不連続的なアクセスは、市場の観点から、これらのシステムを使用できなくするだろう。
<３．１．２ 検証された組み合わせ：プリフェッチとキャッシュ>
データへの連続的なアクセスは、実際のハードドライブからデータを読み出すというリストア性能における最大のボトルネックの問題を軽減するのに非常に役立つ。データ配置が最適であるという事実により、一般的なHDDに関して言えば、エンジニアは、ランダムまたは未定義のデータアクセスパターンと比較して、簡単だが効果的なリストア性能を何倍も改善する技術を使用することが可能になる。
プリフェッチ
連続データの場合に最も一般的かつ効果的な手法は、システムメモリにハードドライブから一定または可変の大きなチャンクでデータをプリフェッチすることだ。この動作の結果、ユーザが１ブロック（たとえば8KB）だけの読み出し要求をすると、はるかに大きなチャンク（たとえば2MB）を、ディスクから読み出すきっかけとなり、今後の使用のためにシステムメモリ内に全ての読み出しブロック（2MB/ 8KB= 256）を配置する。このようなアプローチのおかげで、連続的なアクセスの場合には、多くの次の読み取り動作が、ディスクアクセスの費用を支払うことなく、メモリからデータを取得することを可能にする。
このアルゴリズムは、実際には、HDD構造の結果であり、小さな部分データの読み出しを非常に非効率的にしている。各ディスクの２つの主な特徴は、データアクセス時間と転送速度である。一番目の特徴がここで最も問題となる。システムメモリへのデータ転送を開始する前に、ディスクは、ヘッドを適切なトラックに移動し（シークタイム）、必要なデータがそのヘッドの下に現れるのを待たなければならない（回転待ち時間）。全体のプロセスは非常に費用が高く、一定の転送レートを想定すると、そのようなデータアクセスの数が総読み出し性能を決定する（図３２参照）。
また、帯域幅と容量の面でディスク技術が開発途上であることに気付くことが重要だ。同時に、残念ではあるが、シークタイムと回転数は、既に何年もの間、基本的には同じレベルにとどまっている。実際、この論文がほぼ完了したとき、シーゲートは29%高い持続データ転送速度（226MB/s）を有する新バージョンのエンタブライズキャパシティ3.5 HDDを発表したが、読み出しアクセス時間の変更はなかった。データだけへのアクセスは、総リストア時間の中でより一層大きな部分を占めつつあるので、このような不均等な発展は、断片化の問題をさらに深刻なものにする。
キャッシュ
データは、ディスクからプリフェッチされた後、実際のプリフェッチと比べて通常はるかに大きいバッファキャッシュ（またはリードキャッシュ）と呼ばれる専用のシステムメモリに保存される。その理由は、現実には理想的な連続負荷はないからである。小さいキャッシュの場合、不連続的な途絶（ディスク上の別の場所からの読み出し）があると、以前読み出された列に戻った後でデータを再ロードする必要があるだろう。大きいサイズのおかげで、キャッシュは、上述の状況においてある程度の回復力を有するだけでなく、正確ではない順序での読み出し（書き込み時のデータ並べ替えの場合）や、多くのストリームへの同時アクセスをサポートする。重複排除バックアップシステムの場合、キャッシュのもう一つの機能は非常に興味深く重要になる。この機能は、比較的短期間に何回も要求されるデータブロックを保持することが可能であり、達成されたリストア帯域幅においてさらなる改善を可能にする。
キャッシュ用のメモリは、常に限定されているので、専用のキャッシュ置換ポリシー（cache eviction/replacement policy）を必要とする。多くの既存のアルゴリズムにはそれぞれ、最適な使用法がある。バックアップシステムについては、最も一般的に使用されるポリシーはリーストリーセントユーズド（最近最も使われなかったもの：Least Recent Used(LRU)）である。この場合の主な目標は、最初に最近最も使われていないブロックを破棄することである。このアルゴリズムは、何が使用されて、正しい項目が削除されていることをいつ確認するかを追跡し続ける必要があるが、それをより安価にするためにいくつかの最適化が存在する。この論文で提示するトレースについて行われた、モーストリーセントリユーズド（最近最も使われたもの：Most Recently Used）やリーストフリクェントリユーズド（最も頻繁に使われなかったもの：Least-Frequently Used）といったいくつかの他の周知のアルゴリズムを用いた実験はまた、LRUと比べてはるかに良い結果を示した。
ページ置換ポリシーのために（やや似ている）、最も効率的なアルゴリズムが実際に存在し、ベラディの最適アルゴリズムと呼ばれているということを述べることが重要だ。最適なキャッシュ使用を実現するため、このアルゴリズムは最初に、将来最も長期にわたって必要とされないであろうページをメモリから破棄する。残念ながら、一般的に、情報が必要になる時期を予測することは不可能であるので、このアルゴリズムは、大半の既知のシナリオにとって実際には実現可能ではない。また、メモリ内のページはブロックとは異なるので、バックアップシステム環境にそれを移動することは、簡単ではないが、興味深い洞察をもたらすことができる。
効率性の問題
プリフェッチ／キャッシュアルゴリズムは、合理的なリストア帯域幅を達成するのに効率的に役立つにもかかわらず、最適に動作しないことが時々ある。その１つは、アクセスパターンが実際には一部のみで連続的であるというケースである。このようなパターンは、決して使われないであろう大量のデータをディスクから読み出すことに起因し、実際の読み出し動作時間とメモリ内のスペースの両方を無駄にし、これにより、キャッシュは効率的に実際の確保メモリよりも数倍も小さくなる。
もう１つの問題は、何回もロードされるブロックに関する。このシナリオは、ブロックが、使用される前に既にキャッシュからクリアされたか（小さすぎるキャッシュまたはランダムすぎるアクセス）、既に使用されていても一回以上要求された（内部ストリーム重複）場合に発生する可能性がある。重複排除機能を有するバックアップシステムに関しては、特に第二のシナリオが、１つの連続ストリームデータ内において私が模索しているトレースに驚くほど集中的であった。
<３．２ 重複排除機能を有するシステムにおける断片化の問題>
断片化は、一般に、断片に分割された状態であると定義される。この論文の目的のために、バックアップされる連続ストリームデータと、そのデータが重複排除機能を有するシステム内のディスクドライブへの保存のされ方に焦点を当てる。通常、理論的な観点より実務のほうが関心を呼ぶ。したがって、完璧な連続データの配置の場合に必要とされる入出力の数と比較して、上記のプリフェッチ／キャッシュアルゴリズムを使用する際に追加の入出力動作（ディスクアクセス）を必要とするブロックの並べ替えだけを、断片化として検討する。
重複排除機能を有するバックアップシステムは、データ用の記憶領域の使用において、このような機能を持たないシステムとは大きく異なる。外部からは、各バックアッププロセスは連続的であると見られるかもしれないが、重複排除されたデータに関しては、最終的にハードドライブに到達するのは一部だけである。残念ながら、このような書き込みパターンは、断片化を引き起こす、セクション３．１．２で説明したプリフェッチ／キャッシュアルゴリズムにおいて、非効率性の問題を非常に増加させる。重複排除の概念は、その設計から、実際の論理的ストリームでは互いに何メガバイトも離れて配置される、ディスク上で隣接する２つのブロックの保存を常に最終的に強制したり、２つの論理的に連続するブロックとは反対のことをしたりするだろう。記憶領域を節約するために必要とされるこのようなデータ配置は、研究者にとって全く新たな分野を開き、出現する新たな問題を特定し解決する。
一般に、３種類の断片化問題が存在し、各問題は、最終的なリストア帯域幅に非常に個別の影響を与えるデータ重複排除の異なる側面に起因する（図３３参照）。各分野の詳細な説明および分析は、以下のセクションに記載する。
<３．２．１ インターナルストリーム断片化>
実験が示すところでは、重複排除機能を持つシステム全体で１つのバックアップしか持たないということが既に、この機能を持たないシステムと比較して、そのリストア性能を低下させる可能性がある。このような現象は、インターナルストリーム断片化と呼ばれ、１つのストリームに何度も登場する同一のブロックによって引き起こされる。
図３４は、最初のバックアップの一部（論理ブロックオフセット402から438まで）を示す。図に示すシーケンスでは、同一ストリームの過去の部分に既に保存されている重複であるためにディスク上の別の場所に保存されているブロック（i'5、i'1、i'76など）があることに気付くだろう。このようなブロックに関する問題は、これらを読み出すために、ディスクドライブは現在の読み出し先頭とは別の場所にヘッドを移動しなければならず（i'279とi'304との間）、これには余分な入出力の費用がかかる、ということである。さらに、このアルゴリズムは通常、データの完全なプリフェッチを読み出してキャッシュに置こうとする。これは割り当てられたメモリを浪費する。なぜなら、多くの場合、使用されるのはそのようなブロックのほんの一部だけだからである。最終的なリストア帯域幅となると、プロセス全体では非常に高価になるだろう。
ブロックi'6とブロックi'129は、主たる列（i'279からi'304まで）にはなくても、追加のディスクアクセスを発生させないことに注意されたい。これは、追加の入出力を必要としないで読み出されたブロックi’5とブロックi’128のおかげで、上述のブロックは読み出し時にキャッシュメモリに存在する、という事実による。さらに、i'5というブロックが２つあり、１つめにはディスクアクセスが生じたとして印が付けられていることがわかる。これは単純に、ブロックi'5は、27ブロック先に読み込まれたばかりなので、第２のコピーのリストア中にはキャッシュにまだ存在するだろうということを前提とする。
図３４を参照し、プリフェッチサイズが４ブロック、キャッシュが１００ブロックである（ここまででストリームの25%になるので非常に大きい）という例を想定すると、我々は２つの興味深いケースにおいて必要とされる入出力の数の違いを視覚化することができる。ストリームの図示する部分を、重複排除機能を持たないシステムに保存する際には、全部を読み出すために１０回の入出力（= サイズ4のプリフェッチ）が必要である。この理由は、このようなシステムにおいて論理アドレスは物理アドレスと同一であるので、３７個のブロック（402から438まで）を連続して読み出すからである。一方で、重複排除機能を使用する際は、i'279から i'304までの連続データ（２６個のブロック）を読み出すための７回の入出力と、重複データを読み出すための８回の追加の入出力が必要となる（図３４参照）。両方の結果を比較すると、上述のシナリオ間における差は50%のレベルであり（入出力 １０回対１５回）、同一のバックアップデータをリストアするために、重複排除機能を備えたシステムでは1.5倍の時間を要するということを意味する。なお、２番目のi'5ブロック（論理オフセット431）はそれまでの間（オフセット404と431との間）にキャッシュから取り除かれた可能性があり、これを読み出すために余分な入出力の追加を再検討する必要がある場合があるので、適度に大きなキャッシュサイズを想定したい。
幸いなことに、ストリームリストアに必要な総時間を減らすのではなく増やすために、インターナル重複ブロックの出現は、巧みに変えられることができる。同じ初期バックアップが１番最初から読み出され（論理オフセット1、2、3…から始まる）、無制限のキャッシュを使用すると仮定しよう。このような場合、ブロック402（ディスク上の位置：i'279）を得た後では、重複としてマークされた全てのブロックがメモリ内に既に存在するであろう。その結果、図３４に示す部分を要求すると、重複排除機能を持たないシステムにおける最初の１０ではなく７つの入出力だけが必要とされ、リストア時間は30%削減される結果になる。
概して、重複は１つのストリーム内にも出現し得ると予測されたが、むしろ驚くべき事実は、実験におけるこのような出現規模と、リストア帯域幅へのその悪影響である。良いニュースは、過去に実行したバックアップの時間や数に関係なく、ほぼ一定数のインターナル重複ブロックと各バックアップへの同様の影響である。一方で、重要な事実は、無制限のキャッシュサイズの影響の観察であり、これは、さらに分析され、限定されたフォワードナレッジによってサポートされる代替のキャッシュ置換ポリシーの提示を鼓舞する（第４章参照）。
<３．２．２. インターバージョン断片化>
バックアップは定期的に実行されるので（毎日/毎週/毎月）、１つの論理ストリームの各部分は、同じデータセットのさまざまなバージョンで見つけられる。全てのそのようなバージョンは、１バックアップサイクル内で変更されるデータの量だけ（通常は非常に小さな割合）過去のものと異なり、これにより、同一データセットの結果として生じるバージョンは非常に似たものになる。
重複排除機能を持つバックアップシステムはそれぞれ、重複ブロックを発見して最終的には変更されたものだけを保存する一方、最も一般的なインラインソリューション（セクション２．２．１のオフラインバージョンとの比較を参照）では常に、全ての変更された／新しいブロックを現在空きのある領域内の連続した記憶領域に一緒に置く。残念ながら、このようなデータ配置では、何十何百のバックアップの後、最新のバックアップのデータが記憶領域中に散在する。
図３５は、インライン重複排除機能を持つシステムに保存されているサンプルバックアップセットの１０個のバージョンを示す。各バージョンはディスク上の１つの連続セグメントに保存されているが、最初のバージョンが全てのデータを保存しているので、バージョン1からバージョン9までは、過去のバックアップには存在しなかったデータだけを追加する（全ての重複ブロックは排除されてディスク上には保存されない）。その結果、論理バックアップ9に属するブロックは、初期のセクションとセクション1から9のそれぞれのディスク上に見つけられる。
バックアップ9の最初の３８個のブロックのリストアプロセスを図３６に示す。プリフェッチサイズが４ブロックでありキャッシュメモリが無制限であると仮定すると、図示の例において全てのブロックを読み出すには２１回の入出力が必要であり（マークされたブロックを参照）、その一方で、全てのブロックが常に連続して配置されているシステムでは、たった１０回の入出力で十分である（38をプリフェッチサイズで割る）。最後に、２倍以上のリストア時間が、上述のシナリオにおける断片化の実際のコストである。
こうして得られる断片化は、インターバージョン断片化と呼ばれる。ここで特徴的な事実は、この種の断片化は、システムの使用開始時には存在せず、各データセットおよび使用パターンごとに固有の割合で後に続くバックアップ中に増加するということである。このプロセスは、一般的なバックアップサイクル中にはむしろ見えないので、通常はリストアが必要な時に出現し、これにより、予想よりも数倍低いリストア帯域幅の問題が明らかになる可能性がある。このような発見は、リストアが喫緊の課題である場合には非常に高価な結果をもたらした。
インターバージョン断片化に関しては、２つの事実が問題の核心を明らかに可視化するようだ。１つめは、ゆっくりとバックアップの数とともに増加する変化という特徴であり、２つめは、セクション３．１で説明した、リカバーされたデータの典型的年齢についての知識である（図３１参照）。最新のバックアップが最もリストアされる可能性が高いとすると、問題は非常に深刻に見えるが、一方で、集められた情報は、問題を解決しようとする際に興味深い洞察を与える。
<3.2.3 グローバル断片化>
実際に、グローバル断片化はインターナル断片化とよく似ている。唯一の重大な違いは、問題のある重複が、同じストリームの過去の部分からではなく、全く無関係なものから来ている、ということである。これは、インターナル断片化では、問題はストリームにおける２回目以降のブロック出現によって引き起こされた、という事実によるものであり、既にリストアされたブロックを、十分に長いキャッシュ内に維持することによる悪影響に立ち向かうことを可能にした。グローバル断片化の場合、問題は既に最初のブロックの出現とともに発生し（それ以降のものはむしろインターナル断片化とみなす必要がある）、そのブロックは、現在のバックアップセットの外に存在するので、システム全体の中でほぼいかなる場所でも見つけることができる。
グローバル重複ブロックの量とリストアパフォーマンスに対するグローバル断片化の影響とを検証するために、５つの独立したデータセットに対して簡単な実験を行った。各データセットについて、最初のバックアップがデータセット代表として選択された。バックアップシステムは、最後の１つとしてロードされたテストされた代表以外の全ての代表を保存することによって準備された。重複ブロックの数と帯域幅とを、このようなバックアップがシステム内で唯一のものとして保存されるシナリオと比較することにより、問題の規模を視覚化することができる。
図３７に示す結果は、実際には、他の独立したデータセット内に存在するグローバル重複ブロックは非常に少ないことを示している（0.01%から1.47%）。この結果はリストア帯域幅への影響は比較的小さいことを示唆しているが（0.06%から8.91%）、実際の数値は異なる可能性があり、独立したデータセットの数とシステムに保存されている固有データの合計サイズとともに、おそらく緩やかに増加するだろう。
グローバル断片化を解消するために確実にできることは、別の従業員のメール／ホームバックアップや仮想マシンシステムのパーティションイメージといった共通のブロックを持っている可能性のある全てのデータを、一緒にバックアップすることだ（１つのストリーム内で）。残念ながら、このようなアプローチは、これらのデータを一緒にリストアする可能性が存在するまでは理にかなっているが、さもなければ役に立たない。上記変更の目的は、グローバル断片化を、はるかに対処しやすいインターナル断片化に変えることである。
一方、テスト結果（図３７）が示唆しているように、独立したデータセットは、時にかなりの量の断片化を引き起こすデータを少ししか共有していない（イシューリポジトリを参照）。このようなシナリオを防ぐために、他のデータセットに対して重複排除を行うのではなく、現在のバージョンの前のバージョンに対してだけ重複排除を行うと決めることができる。このようなアプローチは、保存されている通常少しの追加ブロックを費やして、グローバル断片化を解消するだろう。
重複ブロックを保存できないと仮定すると、グローバル断片化は、分析するにも解決するにも間違いなく最も問題があり複雑なものである。現在のシステムデータのいずれかに重複ブロックを排除することは、我々のバックアップを１つまたはおそらくそれ以上の全く関係のない別のものに何らかの形で依存させる。共通ブロック毎に何らかのグローバルに最適な場所が存在しても、その計算は通常複雑であり、見つかったとしても、関与するバックアップの少なくとも一部は、とにかく断片化に悩まされる。さらに、そのような要因の影響は、実際には検証できない。なぜなら、所定のトレースのそれぞれがシステム内に存在する他のデータに基づいて異なる動作をするからである。
上述した複雑さは、一般的に、バックアップシステム内の少量のグローバル重複ブロックとリストア性能に対するかなり一定の影響（一定数のデータセット）であるが、他の問題、すなわち、インターバージョン断片化とインターナルストリーム断片化のはるかに高い優先順位をもたらす。そのことと、検証することがかなり困難または不可能なグローバル断片化の特徴とを考慮して、この論文ではこの問題をこれ以上分析しないと決定した。
<３．２．４ スケーラビリティの問題>
大きな重複排除バックアップシステムを検討する際には、全く新しい視点を考慮しなければならない。何千ものハードディスクとともに数十数百のサーバを持つと、全ての問題は別のレベルに到達する傾向がある。要求を処理したり潜在的な問題を隠したりするハードウェアは多く存在する一方、スケーラビリティの目的は、システムの機能をそのサイズとともに計ることを必要とする。
通常、大規模なシステムからバックアップストリームをリストアする時には、多数のディスクがプロセスに関与する。常駐する消失訂正符号化やRAIDのため、各ブロックはより小さな断片に切断され、その後、多くのハードドライブ上に配置される。より多くのディスクはより優れた回復力とより高い可能性のある１つのストリームの性能を意味するが、残念ながら、断片化問題の増大と時には１つのブロックへのより高価なアクセスを伴う。１つの連続ストリームが１０枚のディスクに保持されていると仮定すると、それを読み出して最適な帯域幅近く（つまり、１枚のディスクで175MB/sの代わりに、1750MB/s近く）に維持するために、各ディスクから約2MBのデータをプリフェッチし、最終的に合計で20MBのプリフェッチを行う。このような大きなプリフェッチは非効率的である可能性が非常に高いので、実際には、ほとんどのシステムは、次善の選択に一致して最大限可能なパフォーマンスを制限するはるかに小さいバッファを使用する。全体的なプリフェッチが大きいということはまた、不要なデータをプリフェッチすることによりキャッシュメモリを無駄にする可能性が高く、最大限断片化が高い、ということを意味し、結果として、数倍大きなキャッシュが必要となる。ディスクドライブが１つの場合、有用データの最小サイズは2MBのプリフェッチのうち8KB（0.4%）であった一方で、スケーラブルなソリューションでは、時にはそのサイズが20MBのうち8KB（0.04%）であったことにより、１回のランダムな読み出しのコストを大幅に増加させた。なお、重複排除ブロックサイズよりも大きなストライプサイズで構成されたRAIDでは、１つのブロックは、多くの断片に切断されない。4‐128KBという典型的ストライプサイズと、プリフェッチサイズより小さいデータを読み出すことはないという事実とを想定すると、とにかく全ドライブが使用されることになり、消去訂正符号化に類似したシナリオにユーザを置く。
一般的に、より多くのスピンドルを備えて良好な帯域幅を確保する方がはるかに簡単だが、大きなシステムでは、１つのディスクドライブの適切な１ストリームの性能よりもはるかに多くのことを期待するべきだ。緊急の場合、通常は毎日／毎週バックアップされるストリームの数のリストアプロセスを期待するべきであり、これは読み込みのスケーラビリティを書き込みと同レベルに維持することを示唆し、通常１つまたは非常に限られた数のディスク位置で実行される。それとは関係なく、１つのストリームをリストアするという最も単純なシナリオにおいても、最小量の電力およびシステムメモリで最大の性能が望まれる。
<３．３ 問題の大きさ>
断片化問題の本当の規模を視覚化するために、商用システムのハイドラストアの顧客から収集した６つの異なるデータセットについてシミュレーションを行った。全てのデータセットの詳細な内容および実験方法は、セクション６．１に述べる。
<３．３．１ 最新のバックアップにおける様々な種類の断片化の影響>
図３８において、一番上の線は、所定のキャッシュメモリサイズと既成のベラディのキャッシュ置換ポリシー（既成のベラディキャッシュと呼ぶ）とを使って最新のバックアップによって達成されるリストア帯域幅に相当し、ページからブロックに移動する際に最適ではないとしても、達成可能な性能レベルを非常に良く述べている（アルゴリズムの詳細についてはセクション３．１．２を、ブロックをプリフェッチする場合における最適性欠如に関する議論についてはセクション８．２．２を参照）。他の線は、実際のバックアップシステムと最も一般的なLRUキャッシュ置換ポリシーとを使用したシミュレーションの結果である。真ん中の線は、システム全体に存在する最新のバックアップだけでの数字を示し、したがって、インターナルストリーム断片化の影響を示す。一方で、一番下の線は、データセットから全てのバックアップが保存された後の最新のバックアップ帯域幅を表し、但し、インターバージョン断片化も含む。
結果は、様々なキャッシュサイズについて収集され、重複排除機能を持たないシステムについて達成されたリストア帯域幅の割合として可視化された（連続したデータ配置であり、１回のプリフェッチのみに合うキャッシュサイズであると仮定）。なお、任意の重複ブロックに対する読み出し要求の場合、アルゴリズムは常にメモリから直接それを受け取るので、無制限のメモリを使用するとインターナル断片化は存在しない（インターバージョン断片化だけが見られる）。さらに、このような無制限のキャッシュでのリストア帯域幅は、インターバージョン断片化もデータの並べ替えもバックアップストリームに存在しない限り、最大であるとみなされる。
各データセットの100%を超える高い最大帯域幅レベルが、あるメモリレベルから始まることに容易に気付くことができるだろう。実は、この現象は、セクション３．２．１で説明したインターナルストリーム重複ブロックの良い影響である（メモリに既に存在する重複データを読む）。いくつかのデータセットにとっては、これらの値は現実的なキャッシュサイズ（512MB以下）でも可能だが、実際には、結果は最大70%の性能低下を示す（メールおよびイシューリポジトリの図を参照）。さらに、インターバージョン断片化の影響（最大50%の低下）を加えると、最終的な結果は、最適なレベル（イシューリポジトリ）を下回って81%に達し、重複排除機能を持たないシステムのレベルを下回る75%になるだろう。
一般に、インターバージョン断片化またはインターナルストリーム断片化のいずれかの重要性について議論するということは非常に困難だ。それらは共に最新バックアップのリストア性能劣化につながるけれども、その起源と特性は大きく異なる。また、それぞれの断片化の影響は、測定に使用されるデータセットに大きく依存する。さらに重要なことは、インターバージョン断片化は、バックアップ毎に増大し、測定の瞬間が非常に重要になる。
<３．３．２ 時間断片化>
インライン重複排除機能を持つバックアップシステムに関して言えば、時間の観点や実行したバックアップの実際の数が非常に重要である。図３９は、各バックアップの実行後の断片化の問題を示している。１番上の線は、無制限のキャッシュを用いて（インターナルストリーム断片化を除く）インターバージョン断片化無しで達成可能な帯域幅を表し、各データセットにおいてバックアップ毎に達成可能な最大性能レベルを示す。他の全ての線は、両方の種類の断片化を含む。
残念ながら、せいぜい５０個のバックアップしかない一方で、何年もの定期的なバックアップの後で最も良く検証された問題の影響を示すことは困難であった。しかしながら、２年という期間をカバーし、かつ、デフラグメンテーション（以下、デフラグ）を使用しない場合に最大で４４倍の下落を示す４８０個のバックアップの合成データセットを通じて、ある概算がリリブリッジらによって与えられている。この概算は、高断片化を引き起こす顧客に基づいてHP ストレージディヴィジョンによってなされるが、依然として問題をよく可視化している。
我々の実験が示すように（図４０参照）、インターナルストリーム断片化のレベルは、１セット内のほとんどのバックアップについて概ね安定しており、通常は、初期バックアップのレベルにとどまる。したがって、さらねるバックアップ毎の減少は、概して、インターバージョン断片化によって引き起こされる。このような性能低下は、初期バックアップの割合として表されるが、キャッシュサイズに関係なく類似するので、問題の実際の規模は、図３９における上位の２本の線を見ると簡単にわかる。両者とも無制限のメモリを用いているが（これによりインターナルストリーム断片化の影響が無効になる）、２本のうち上の線はインターバージョン断片化を含まない。キャッシュサイズ毎のインターバージョン断片化無しの線は、図表を鮮明にするために省略したが、最新のバックアップに対する各要因の詳細な影響は、図３８に示されている。
<３．３．３ リストア時間へのキャッシュサイズの影響>
図４０及び３．５に示すように、キャッシュは、インターナルストリーム断片化を闘うために使用される武器と考えることができる。キャッシュは役に立つけれども（特に、無制限のメモリが利用可能である時）、価格が非常に高い。たとえば、ディベロプメントプロジェクトで32MBのキャッシュメモリから始めると、リストア帯域幅を倍にするためだけに、１６倍大きいメモリ（512MB）を使用する必要があり、依然として重複の無いシステムについての100%ラインを下回る。同様に、同じ結果を達成するためにイシューリポジトリでは、必要なメモリが６４倍にもなる（2048MB）。また、近代的なバックアップシステムが一度に多くのバックアップストリームを処理することを念頭に置くと、必要なメモリはさらに何倍にも増大し、全体のシステム要件を莫大にするだろう。
さらに、メモリが増加すれば通常のバックアップのパフォーマンスは向上するけれども、受けられる支援はあまり効果がない。既存のベラディのキャッシュを用いたアルゴリズムが示すように（図３８における１番上の線）、ほとんどの場合、128MBまたは256MBしかキャッシュメモリのバックアップを持たなければ、ほぼ最大限可能な帯域幅でのリストアを可能にできるはずであり、従来のキャッシュを使用して（LRU）達成するよりも20%（ゼネラルファイルサーバ256MB）から最大519%（イシューリポジトリ256MB）高く、通常は、非重複システムの帯域幅のレベルを上回る。大きく異なる唯一のデータセットはメールであり、この場合、インターナル重複パターンでは、既成のベラディのキャッシュであっても合理的な量のメモリで非重複帯域幅レベルが達成できない。
一方、インターバージョン断片化については、追加のメモリはあまり役に立たないようだ（図３８）。この断片化によって生じるリストア時間増加への影響は、キャッシュサイズに関係なく類似しており、最も短いセット（ウィキ、ディベプメントプロジェクト、ゼネラルファイルサーバ）については13‐20%、メールおよびユーザディレクトリについては34‐46%、たった７バックアップ後の最も断片化されたイシューリポジトリについては最大で91‐171%に等しい。
１つのデータセットにおいて様々なキャッシュサイズを使用してのシミュレーション結果は、実際に達成された帯域幅に対してメモリサイズが与えるわずかな影響を示すだけでなく、このような考察の理由も示す。インターバージョン断片化の問題は、多かれ少なかれメモリに依存するように見えるが、インターナル断片化に関連する第２の問題は、単に、一般的なLRU（最近最も使われなかったもの）キャッシュ置換ポリシーによって到達される乏しいメモリ効果によって引き起こされる。既成のベラディのキャッシュを用いる実験が示すように（図３８参照）、この問題の可能性のあるソリューションは、８倍少ない量のメモリを用いることで、より高いリストア帯域幅を提供するだろう（全てのデータセットにおいて、既成のベラディのキャッシュで128MBを有するほうが、LRUで1024MBを有するよりも優れている）。
<３．４ リストア中の断片化の悪影響を低減するためのオプション>
断片化は、重複排除の自然な副産物（あるいは、むしろ廃棄物）である。バックアップ間の干渉の無い別々の連続的なディスクスペースに各バックアップを維持することによって、断片化を排除することができるが、このような場合、重複排除は無いであろう。
リストア性能に対する断片化の影響を実質的に排除するための別のアプローチは、重複排除のために大きな予定ブロックサイズを使用することである。この場合、断片化が発生してもリストア速度はあまり低下しない。なぜなら、シーク時間は、ブロックデータを読み出すのに必要な時間によって支配されるからである。たとえば、予定ブロックサイズが16MB、リードディスク帯域幅が175MB/s、リードアクセス時間が12.67msでは、各ブロックリードに関するシークが増加させるリストア時間は、14%未満だろう。しかし、重複排除に最適なブロックサイズは、特定のデータパターンとストレージシステムの特性評価に応じて、4KBから16KBの間で変化する（重複排除の有効性を計算する際に、ブロックメタデータを含める必要がある）。あまりに大きなブロックを用いると、重複排除は全く無効になるので、このような大きなブロックの使用は、実行可能なオプションではない。
興味深いソリューションは、断片化に対処するために縮小された重複排除機能を使用することであろう。このアプローチでは、目下書き込まれている或るブロックがバックアップ中にディスク上で遠く離れている時は、既存のコピーに関係なくそのブロックをディスク上に単純に保存することができる。残念ながら、ソリューションの１つが示すように、このやり方は、合理的なリストアの結果に向かう時には特に、重複率を下げることにつながる。興味深いトレードオフは、こうしてグローバル断片化に対処するが（通常は少ない数の重複によって引き起こされるので）、完全な重複排除を省くような、インターバージョン断片化とインターナルストリーム断片化とを解消するための他の技術を使用することであろう。
バックアップシステムは、一般的に多くのサーバとディスクとから構成されることを考えると、リストアを高速化するために使用することもできる。１つのドライブの性能が、重複排除機能を持たないシステムによって達成される性能の25%という水準であれば、所望の水準に到達するために、４つ（またはそれ以上）のディスクを使用することができる（プリフェッチ、キャッシュ乗算、および全ての結果とともに）。必要とされる唯一の変更点は、選択された数のドライブ間で１つのストリームを分けることであろう。これはとにかく、よくある事だ（例えばRAID）。この提案は、問題を解決するというよりも隠すことを意味するが、十分な数の完全には利用されていないデバイスが利用可能な時にはいつでも役に立つ。
最後に、オフライン重複排除と呼ばれる（詳細はセクション２．２．１を参照）、インターバージョン断片化問題のためのもう１つの可能性のある良いソリューションがある。このアプローチでは、最新のバックアップが常に１つの連続ストリームとして保存されているので、リストア性能は最適である（内部重複が無いと仮定して）。残念ながら、この重複排除という概念に関する問題の数は、市場に存在する非常にわずかな割合のこのようなソリューションをもたらす。
上記のオプションは、可能であり時には導入するのが非常に簡単ではあるが、かなりの量の追加リソースを必要とするか、または、容易に受け入れられないトレードオフを要求する（すなわち、重複排除の有効性を犠牲にしたリストア帯域幅）。一方、バックアップやリストアプロセスの詳細を見るだけで、多くの興味深い特性を見出すことができる。特化した方法でそれらを使用することは、実は、最小限のコストだけで問題を解決し、驚いたことに、以前は達成できなかったリストア帯域幅レベル、時には重複排除機能のないバックアップシステムによって提供されるものよりも高いリストア帯域幅レベルに到達する。
<第４章 インターナル断片化の影響を軽減するために限定されたフォワードナレッジ（将来の知識）を持つキャッシュ>
前のセクションで述べたように、重複排除機能を備えたシステムにおいてリストア帯域幅が一般的に低いことの主な理由の１つは、インターナルストリーム断片化である。キャッシュサイズ毎のテスト結果を分析すると（図３８参照）、バックアップが１つだけバックアップシステム内に存在する時でさえ（インターバージョン断片化なし）、LRUキャッシュを使った一般的なソリューションと比較すると、はるかに高いリストア帯域幅が既成のベラディキャッシュで達成されることに気づくことができる。その結果は、データセットによって大きく異なるけれども、全てのキャッシュサイズにおける平均増加は80%を超え、256MBのキャッシュサイズの例では、その値は、ゼネラルファイルサーバとウィキにおける7‐25%からイシューリポジトリとメールにおける197%まで異なっている。
上記の結果で可視化された実際の問題は、キャッシュメモリの非効率的な使用である。LRUによる予測の質が悪いため、多くの場合、ブロックは実際に使用される（または再使用される）前にキャッシュから取り除かれ、同時に、全く不要な多くのブロックがメモリを占める。このことは、同じブロックの多くのコピーが１つのストリームにかなり頻繁に出現する、重複排除機能をもつバックアップシステムに特に当てはまる（詳細は図５１を参照）。
この章では、近い将来に参照されるブロックのみを保持することによって、インターナルストリーム断片化の影響を軽減することを目的とする、限定されたフォワードナレッジを有するキャッシュ置換ポリシーのアルゴリズムを提示したい。提案されたソリューションの副作用はまた、概して、より効果的なキャッシュの使用であり、インターバージョン断片化のあるストリームに使用する際にもメリットを提供する。
<４．１ 最終的なソリューションの所望の特性>
キャッシュ置換ポリシーとしてのLRUとうまく交換するために、新しいソリューションは、以下のことを求められる。
・既成のベラディキャッシュで達成されるものに近い（そして当然ながらLRUよりもかなり高い）リストア帯域幅を提供する。
・保存すべき追加データを必要としない（最大限の重複排除の効果は維持されるべきである）。
・リストアアルゴリズムに何らかの変更があれば少しだけ実施する。
・リストアアルゴリズム外での変更は必要ない。
・ディスク帯域幅、スピンドル、処理能力などの多くの追加リソースを必要としない。
・必要に応じてトレードオフに対処する上での様々な選択肢を提供する。
<４．２ アイデア>
バックアップシステムに保存される前の各データセットは、通常、バックアップアプリケーションによって１つの大きな（数十または数百ギガバイト）論理ストリームに圧縮されている。多くの読み出しアルゴリズムや重複排除アルゴリズムは、このようなバックアップポリシーに既に依存しており、ストリーミングアクセスの経路を最適化する傾向があるが、これは実はバックアップシステムではごく一般的なことだ。私のアイデアでは、リストアプロセス中にこの既知の特性をさらに最適化したい。
インターナルストリーム断片化の問題はかなり頻繁に出現するようなので、最も近い将来に再び出現することになるブロックのみをメモリに維持するために、任意のフォワードナレッジが非常に役立つ。このアイデア自体はベラディのアルゴリズムに存在しているが、通常そのアイデアを無駄にする大きな問題は、そのような情報は取得するのが困難であるか不可能でさえあることだ。幸いにも、バックアップシステムではこの特性は異なっている。なぜなら、一般的にバックアップは非常に大きく、書き込まれたのと同じ順序でアクセスされるからである。リストアを開始すると、通常、全体的なリストアレシピを発見することができるが、これは、将来的に要求されるブロックに関する実際には無制限の知識へのアクセスを有することを意味する。
全ての転送アドレスを使用するというアイデアは、魅力的ではあるが、現実的には必要ではない。なぜなら、それらのアドレスが、実際のキャッシュのために使用することができる（データを維持するために）、貴重なメモリを占領してしまうからだ。実験では、そのようなフォワードナレッジを限定された量だけ持つことで、多くの場合、既成のベラディのキャッシュの結果に近い（無限のフォワードナレッジを持つ）、良好なリストア性能を提供するために十分であることを示した。
<４．３ システムサポート>
限定されたフォワードナレッジのキャッシュを実装するために、次の能力をサポートするバックアップシステムを想定する。
・同一コンテンツを有する全てのブロックに対して１つのアドレス。同じ内容のブロックは同じアドレスを持たなければならない。バックアップシステムの場合、この特性は、コンテンツのアドレス指定能力で確認される。
・１つのストリーム識別子で全体のバックアップリストア：システムに提供される１つの識別子が、バックアップ全体を読み出すために十分であるはずだ。
・事前にメタデータをプリフェッチする機能。システムは、実データを取り出す前に、定義された量のメタデータを最初に読み出すことができなければならない。このようなメタデータは、より良いメモリ使用量を確保するために、キャッシュ置換ポリシーのために必要とされるであろう。
重複排除機能を持つほとんどのシステムは、コンテンツアドレス指定能力を既にサポートし、識別子として例えばファイルパスを考えると、ストリーム全体を読み出すためのメカニズムを提供する。また、完全なレシピと実際のデータブロックのアドレスを受信するために、システム内の専用の場所から（通常はデータとは別）徐々に読み出されるメタデータが、リストア毎に必要である。ストリームリストアの開始前に、このようなメタデータの続きを読むために、小さな組織再編を容易に導入することができる。その結果、次のセクションで説明したアルゴリズムは、重複排除機能を備えたシステムに広く一般的で採用可能と見なすことができる。
<４．４ アルゴリズムの詳細>
<４．４．１ システムリストアアルゴリズム>
システムレベルから見ると、ストリームリストアは、ストリーム識別子を受信することで始まる（図４１参照）。このような動作は必要とされる全てのメタデータへのアクセスのロックを解除するけれども、あまりにも多くのメモリを占有しないようにするために、通常は、ある少しの量だけが読み出される。これに基づき、専用のアドレスを持つブロックを読み出す要求が送信される。リストアが進むと、追加のメタデータが読み出され、より多くの要求が発行される。システムを十分に利用する一定の負荷とそのリソースを提供するために、全体のプロセスは非常に円滑である。
提案されたソリューションの基本的なアイデアは、システム内に既に存在する情報を使用することである。読み取るべき将来のブロックについての知識を持つことは、キャッシュポリシーにとって非常に有用であるので、このアルゴリズムは、ある合理的な量のフォワードナレッジを読み出すことができるはずだ。
<４．４．２ ディスクリストアプロセス>
ディスクレベルでは、データストレージについては、標準的なプリフェッチおよびキャッシュアルゴリズムが使用されるが、修正されたキャッシュ置換ポリシーを使う（図４２参照）。受信した転送情報のおかげで、限定されたフォワードナレッジを持つ専用のオラクルを作成することができる。次のブロックの出現に関する情報は、キャッシュにおいて最適なメモリアロケーション近くを確保するのに役立つ。
ネームキャッシュは、この論文で使用される時はいつでも、実データが保持されているメモリを常に参照し、全てのキャッシュアルゴリズムに共通である（上記の図のデータキャッシュ領域）。その結果、特定のソリューションで必要とされる追加のメモリをカバーしておらず、LRUキャッシュ、フォワードナレッジキャッシュと、その他の類似した名称は、対応するキャッシュ置換ポリシーを利用するアルゴリズム全体を参照するように使用される。
限定されたフォワードナレッジを有するオラクル
オラクルは、全ての既知の将来の、しかし未読のブロックの識別子を、それらがストリームで出現するブロック位置をソートしたリストとともに保持するマップとして設計されている（図４３参照）。将来の情報を用いたアップデートでは、ブロックの識別子が、存在しなければ追加されて、固有のブロック位置がリストの最後尾に押されていく。必要な場合には、その構造は、所定のブロックについてそれが必要となる最も近い将来の位置を戻すか、あるいは、次のブロックの出現のリストから最も近い（現在の）位置を除去することによって直近に読まれたブロックを更新するだろう。追加データで、限定されたフォワードナレッジを有するオラクルは、キャッシュデータが保持されるメモリとは異なる専用メモリを必要とする。総量のフォワードナレッジからの各ブロックアドレスについて、ブロック識別子とストリーム内におけるその位置との両方が必要とされている。幸いなことに、両者のサイズは、実際のキャッシュに必要なメモリの一部のみを使用するように制限することができる。
システム内の各ブロックは、そのアドレスによって識別することができる。重複排除バックアップシステムにおいて、このアドレスは、通常、ブロックの内容に基づいており、160ビットSHA1などのハッシュ関数を用いて計算される。このような元のアドレス（ハッシュ）のサイズは、２つの異なるブロックを同一のものだとみなすことがないように（詳細はセクション２．２．４を参照）、ハッシュ衝突の可能性が極めて低くなることを保証するよう設計されている。幸いなことに、オラクルの構造の場合には、そのような情報は、正確である必要はない。第１に、あるハッシュ衝突が出現したとしても、唯一発生することは、１つのブロックをメモリ内に保持することであり、これは、実際には将来必要とされることはない（容易に検出され、また、予想される出現が起こらない時には削除される）。第２に、アルゴリズムは、限定されたフォワードナレッジを使って、ハッシュ衝突を発見するためにストレージシステム全体のサブセットをも制限する（すなわち、数ギガバイトまで）。例を設定するために、64ビット（8バイト）のハッシュ関数を有してその均一な分布を仮定すると（以下の数１）、約200万のブロック（16GBのデータ。ブロックサイズが8KBと仮定）の中にハッシュ衝突の機会が100‐1000万回ある。これは、必要な機能を提供する目的のために64ビットの識別子が十分であるという結論に導く。
ストリーム内のブロックの位置に関する正確な情報は、アルゴリズムでは必要とされない。その唯一の目的は、ストリームのかなり大きな部分で（すなわち、数ギガバイト）ブロック位置を大雑把に比較することであるので、メモリを節約するには、ストリームを複数のセクションに分割してこの縮小された情報だけを保持すれば十分である。このようなセクションは、たとえば、8MB（任意の数）をカバーし、ストリームの先頭からその番号で順次識別される。セクション識別子を限定する（すなわち、2バイト）ことが望まれるので、全ての数字が使用される場合、リナンバリング動作は、オラクルに保存されている全ての数から現在のセクションの数を減算するために行うことができる。この例において、その動作は、メモリ内で実行されるので安価ではあるが、１つのストリーム内でリストアされる504GB（8MB・64K(2bytes) − 8GB（のフォワードナレッジ））のデータごとに一度実行されるだろう（ウォレスらによるシステムの10000を超えるバックアップワークロード分析によれば、現実には、ほんの数%のケースでしか起こり得ない）。
キャッシュされたブロックの場所
フォワードナレッジキャッシュは、通常、ブロックアドレスをキーとして、また、データを値として持つ標準マップとして編成される。LRUとの唯一の違いは、保持される情報の種類である（図４４参照）。最も昔に使用されたブロックを保存するリスト（LRUプライオリティキュー）の代わりに、直近に発生したブロックの順序リストが保持される。すなわち、FKキャッシュプライオリティキューである（新しい場所のブロックが追加された場合に二分探索を行う能力を持つ）。ブロックの更新や追加などの全ての操作は、最新の利用の代わりに次ブロックの発生情報が保存されているということ以外、LRU構造上の操作に非常に似ている。
置換ポリシー
図４５と４６は、２つの例におけるブロックリストアおよびキャッシュ置換ポリシーの例を示す。１つめはブロックがキャッシュ内に見つかった時、２つめはブロックがディスクからリストアされなければならなかった時である。前者において、実行された唯一の操作は、キャッシュとオラクル構造との両方でリストアされたブロックの実際の更新である。後者はより複雑であり、キャッシュ置換プロセスも含む。一般的には、以下の手順で構成される。
・ブロックをディスクから読み出してそのプリフェッチとともにキャッシュする（オラクルが提供する次のセクションの出現に関する情報でキャッシュを更新）
・次に出現するセクションによって順序付けられたブロックをリストアされたブロックとともに保持するキャッシュプライオリティキューを更新する
・次の出現まで最も時間のある最大キャッシュサイズを超えるブロックを削除する（セクション番号の値が最も高い）
・リストアがキャッシュから実行されるときに行われるのと同じ方法で構造の更新を継続する。
直近にプリフェッチされたブロックについて、オラクル内に次に出現する既知のセクションがなく、また、キャッシュメモリにいくらかのスペースがまだ残っている場合には、いくつかの選択肢がある。キャッシュ内にそのようなブロックを保持するか（たとえば、人工の大きなセクション番号を割り当て、それらを動かすためにLRUまたは他のアルゴリズムを使用）、異なる構造への動的メモリ割り当てが可能な場合は、メモリを解放して他の目的のために使用することができる。我々の実験では、最初の選択肢は顕著な性能利得を提供しないことを示されたので、より良い選択は、必要に応じて他のシステム動作（リストア、書き込み、バックグラウンド計算など）のための追加メモリを使用するか、オラクルサイズを動的に増加させることである。これは、全ての使用可能なメモリが効率的に使用されるまで、より多くの将来の情報を提供することになる。
上記のアルゴリズムは既成のベラディのキャッシュに非常に類似している。実際に上記アルゴリズムは、キャッシュメモリがフォワードナレッジによって示されるブロックにより100%で利用されるまでは同じように動作する。使用率の低さによって、既成のベラディのキャッシュよりフォワードナレッジのサイズと個々のストリームの特性の限界である（フォワードナレッジ領域外の重複ブロック）。
<４．４．３ メモリ要件>
フォワードナレッジを用いるアルゴリズムにおけるキャッシュ自体は、LRUアルゴリズムを用いるものと非常によく似た方法で構築されるので、そのメモリ要件は変わらない。しかしながら、フォワードナレッジを持つオラクルでは、独立した専用のメモリを必要とするであろう。別の要件は全てのブロックアドレスの追加リストであり、これらのブロックアドレスは、フォワードナレッジとして受け取られた後でデータをリストアするために実際に使用されるまでリストアされるのを待機する。フォワードナレッジのサイズは何ギガバイトにも及ぶので、データをリストアするためにアドレスが使用されるまでには何秒もかかるだろう（フォワードナレッジを満たすためにアドレスが配信される一方で、リストアは可能な限り迅速に行われることを想定）。これは、専用のメモリを必要とすることを意味する。セクション４．４．４で詳細に説明される別のアプローチは、追加メモリを占有することではなくメタデータを２回リストアすることである。１回目はフォワードナレッジのためであり、２回目はリストア自体のためである。どのソリューションが使用されたとしても、適切なメモリサイズは、リストアキャッシュに割り当てられたメモリの合計に含まれるべきである。
必要な追加メモリの詳細な量は以下のように計算することができる。オラクルの各エントリは、最大で１つのショートハッシュ（8バイト）と１つのセクション番号のエントリ（2バイト）に等しい。詳述するために、上の構造を同様に含める必要がある。標準的なマップは高価なポインタを維持することを必要とするので（ポインタ当たり8バイト。エントリごとに10バイトだけを維持）、クローズドハッシュのハッシュテーブルは、おそらくインメモリアクセス時間をで、ここでは非常に良い選択である。この場合に許容可能な結果を得るために、割り当てられたメモリは要求よりも少なくとも30%高い必要があり、エントリごとに約13バイトになる。20バイトサイズ（SHA-1を想定して160ビット）の待機リスト内のフルアドレスとともに、合計33バイトが１ブロック（8KB）の将来の知識を持つことのコストであり、これはさらにデータ1GB毎に4.12MBを意味する。最良の結果を得るために、数ギガバイトのフォワードナレッジが望ましい（詳細には、それぞれの正確なデータセットの特性に依存する）。
<４．４．４ ディスカッション>
ソリューションの代替案
重要な点は、将来読み出されるであろうデータのアドレスのリストを維持するだけで、必要とされる追加メモリの三分の二が既に消費される、ということだ（ブロック毎に保持される33バイトのうち20バイト）。この影響を最小限に抑えるために考慮する価値のあるアイデアは以下の通りである。
追加メモリを割り当てたままにしないための最も簡単な方法は、システムから再びアドレスを読み出すことだ。このような場合には、メタデータに対する２つのストリームアクセスが存在する。１つは、オラクルにとって適切な情報を提供すること、もう１つは、リストアされる具体的なブロックアドレスを求めることである。ブロックアドレスのサイズが 8KBのブロック毎に20バイトであることを考えると、動作全体では、元のソリューションの場合よりも0.256%多いデータを読み出すことが必要となり、フォワードナレッジ1GB毎にメモリ約1.62MB（4.12MBの代わり）という小さな要件で済む。
このソリューションは、特に利用可能なメモリがわずかしかない場合に非常に魅力的に聞こえる。正確に選択するには、所定のシステムおよび両アプローチの他の起こり得る結果を、詳細に分析することが確実に必要となるであろう。
異なるメタデータ読み出し順序の影響
メタデータリストアのパターンは、提案されたアルゴリズムを用いて大幅に修正されるので、リストア性能への影響に関する問題が生じる。このテーマに関する議論は、所定のシステムとそのメタデータリストアプロセスの詳細な知識を必要とするので、一般には困難である。幸いなことに、メタデータは通常、リストアされる全てのデータのうちのほんの小さな部分なので（8KBにつき20バイトで0.256%）、再びそれをすべて読み出してもそれほど多くの追加作業を生むことはない。また、ブロック毎に100バイトを超える高いメタデータオーバーヘッドを持つシステムを考慮すると、同じシナリオにおける総リストア帯域劣化は依然として1.5%未満であろう。これはほとんど目立たない。
<４．５ トレードオフ>
フォワードナレッジを持つインテリジェントキャッシュの領域における主要なトレードオフは、標準的なキャッシュに特化したメモリのサイズとフォワードナレッジに関連する。データセットの特性や利用可能なメモリの総量しだいで、あるケースではごくわずかな量のフォワードナレッジが効果的なキャッシュ使用を既に保証する一方、別のケースでは非常に小さいキャッシュサイズでの非常に多くの将来の情報が、非常に良い選択である。
この問題に対する最善のソリューションは、キャッシュとオラクルとの間の難しい区別を述べないことだろう。このようなアプローチのおかげで、システムは、キャッシュメモリが十分に利用されていない場合に将来の知識を拡張するか、そうでなければそれを減少させることができるであろう。上記のシナリオは魅力的だが、はるかに複雑であり、特に、分散通信が問題である実際のストレージシステムの場合には詳細なテストを必要とする。これらの懸念から、ハード部門でバージョンを提供し、将来の研究のためにこのソリューションの詳細を保持した。
もう一つのトレードオフは、セクションのサイズに関連する。メモリを節約するために次のブロックの出現の正確な位置は保持されていないので、いくつかの置換は、所望ではない順序で行われ得る。このようなシナリオは、たくさんのブロックが１つのセクション内に配置され１つが置き換えられようとしている時に発生し得る。幸いにも、並べ替えは次に出現するまでの時間が最も長いブロック（最も重要でないブロック）内だけで起こり得るので、このようなイベントは性能にあまり影響を与えない。また、達成された性能は、同じシナリオだがキャッシュメモリが１セグメントのサイズだけ小さくした場合の性能より低いことは決してない。256MBのキャッシュと8MBのセクションサイズの典型的なシナリオでは、性能は、248MBのキャッシュと各ブロックの位置に関する正確な知識を持った場合より悪くなることはない。
<第５章 インターバージョン断片化の影響を低減するためのコンテンツベースの再書き込みアルゴリズム>
セクション３．３．２で提示した実験は、インライン重複排除によって引き起こされるインターバージョン断片化の悪影響を示す。いくつかのケースにおける値がそれほど重要だとは思えないが（ゼネラルファイルサーバ、ウィキ、ディベロプメントプロジェクトの場合、7‐14回のバックアップ後に約12%‐17%のリストア帯域幅の減少）、それらのデータセット内における比較的少数のバックアップという事実と、長いデータセットを用いた実験でサポートされている時間に増加する問題の顕著な傾向（メールとユーザディレクトリの場合、22‐50のバックアップ後に約19%‐36%の減少）とは、実生活での使用に潜在的に高い影響を示唆し、１つのデータセットのために作成されるバックアップの数は、毎年50から300以上にまで変化する。また、イシューリポジトリデータセットは、たった7回のバックアップを実行することで既に、可能なリストア帯域幅の50%以上のコストがかかる、ということを表している。この見解は、ナムらによる他の独立データセットとリリブリッジらによる一層長いもの（90回以上のバックアップ）とに関して確認された。
この章では、現在のストリーミングアクセスパターンを反映するようにブロックの位置を変化させることによって、インターバージョン断片化の問題に対処する、コンテキストベースの再書き込みアルゴリズム（CBR）を提案し、その結果として、より効果的なプリフェッチとキャッシュ使用を提供したい。
<５．１ 最終的なソリューションの所望の特性>
上記の問題は、重複排除システムの他の重要な評価指標に対する悪影響のないソリューションを必要とする。このようなソリューションは以下の通りでなければならない。
・最新のバックアップについてインターバージョン断片化によって引き起こされるリストア帯域幅の低下を解消する
・進行中のバックアップについてほんのわずかな（好ましくは5%以下）書き込み性能の低下しか生じない
・重複排除の有効性を低下させない（必要であれば、ほんのわずかの一時的な追加スペースを使用する）
・ディスク帯域幅、スピンドル、処理能力などの追加リソースをあまり必要としない
・トレードオフに対処する上での選択肢の範囲を提供する。
<５．２ アイデア>
ほとんどの場合、最新のバックアップは障害発生後にリストアされる。なぜなら、ユーザは通常、最新の情報がリストアされることに関心を持つからである（図３１参照）。この見解に基づいて、（重複排除率を維持するために）古いバックアップを犠牲にして、最新のバックアップのために断片化を解消したい。このようなアプローチの例を図４７に示す。図４７は、２つのケースにおいてバージョンの番号に応じて、複数のバックアップバージョンにわたる断片化によって引き起こされるリストア性能の低下を示す。２つのケースとは、（１）バックアップ経過時間とともに断片化が減少するインライン重複排除と、（2）最新のバックアップが連続的にディスクに書き込まれ、バックアップ経過時間とともに断片化が増大する、オフライン重複排除である。コンテキストベースの再書き込みアルゴリズムを導入することにより、オフライン重複排除に類似したデフラグ効果を達成するために、関連コストなしで、インライン重複排除機能にデフラグ機能を追加したい。
すでにセクション３．２で提示したように、インライン重複排除機能を備えたシステムでは、既存のブロックは再度書き込まれず、バックアップ処理が非常に速くなる。残念ながら、このようなアプローチでは、ストリーム内の２つの隣接するブロックがシステム内では互いに遠く離れてしまうことがあるので、高断片化につながる可能性がある。このようなシナリオを防止するために、CBRアルゴリズムは、受信されたバックアップストリームからのブロックと、システム内におけるそれらの物理的局在性を分析する。インターバージョン断片化による性能低下を最小限にするために、このアルゴリズムは、重複ブロックの一部を新しい物理的な場所に移動して、良好なストリーミングアクセスを維持し、プリフェッチを有効にする。このアルゴリズムは、ストリームのバックアップ中に実行されるので、移動される実際のブロックが読み出されるのではなく（多くの費用がかかるかもしれない）、ストリーム内で配信されるコピーが書き込まれる。古いコピーは定期的に実行される削除プロセスによって除去される。オフライン重複排除とは反対に、わずかなブロックだけが移動され（再書き込みされ）、それらが最高のリストア帯域幅利得を保証する。
限定された知識とCBRアルゴリズムはどちらも断片化と闘うが、全く異なるアプローチを提示し、異なる種類の問題を狙いとして定める。前者は、システム内のデータを変更せず、利用可能な将来の知識を使用することによってリストア時の効果的なキャッシュメモリ使用を可能にする。このようなアプローチは、ストリームの内部にある重複ブロックのキャッシングを可能にし、インターナルストリーム断片化を引き起こす。この章で説明する後者のアルゴリズムは全く異なり、ストリームに再出現するブロックを処理しない。その主な目的は、バックアップ中に全てのブロックをより連続的に構築することと、いわゆるインターバージョン断片化に対抗することである。しかしながら、興味深い事実は、このようなアプローチが、より正確なデータがキャッシュに読み込まれることにつながるより効果的なプリフェッチをもたらし、これは両ソリューションをリンクさせる、ということだ。両ソリューションを別々にした場合と組み合わせた場合の各ソリューションの実際の影響を、実験でさらに分析する。
<５．３ システムサポート>
次のセクションで説明するデフラグソリューションを実装するには、バックアップストレージが下記の機能をサポートしている必要がある。
・コンテンツアドレス指定能力。以下で説明する後続の特徴にとって有用な基本機能である。
・ブロックハッシュの存在のチェックに基づく重複排除クエリ。このクエリはハッシュベースでありメタデータだけを読み出す必要がある、ということが重要である。提示したデフラグソリューションにとって、重複排除がシステム内の全てのブロックに対して試行されるか、あるいはその一部に対して試行されるか（疎索引作成など）は重要ではない。しかしながら、重複排除を実行するためにブロックデータ全体を読み出すことは避ける必要がある。なぜなら、そのような動作は、断片化されたストリームの読み出しと、非常に低い総書き込み性能とを実際に生じるからだ。また、高断片化のせいで、ブロックメタデータを十分速く読み出すのにさえ十分なスピンドルを持てないかもしれない、ということを認識しなければならない。しかしながら、SSDがバックアップデータ全体を保持するにはあまりにも小さく高価である一方、フラッシュメモリに基づく、この問題に対するソリューションがある。
・ディスクで隣接するブロックの高速判定。２つのブロックがあるとすると、システムは、それらがディスク上で互いに近接しているかどうかを迅速に判定することができるはずである。これは、システム内のブロックの有無を確認する各クエリが、ディスク上のこのブロックの位置を返す場合に達成される。
・システム内に既に存在するブロックを書き込んで、古いものを削除する機能。将来の読み出し性能を高めるためにブロックを再度保存する決定がなされた時に、これが必要とされる。このような再書き込みは、新しいものがリストア時に使用されるように、以前のコピーを効果的に無効化する。
データドメインやハイドラストアといったインライン重複排除機能を持つ多くのシステムは、 上記機能をサポートしている。他のシステムには、このような機能またはその均等物を追加することができる。その結果、次のセクションで説明するアルゴリズムは、インライン重複排除機能を備えたシステムに広く一般的であり採用可能であると見なすことができる。
<５．４ アルゴリズムの詳細>
<５．４．１ ブロックコンテキスト>
このアルゴリズムは、ディスクコンテキストとストリームコンテキストという重複の２つの固定サイズのコンテキストを利用する。ストリーム内のブロックのストリームコンテキストは、このブロックの直後にこのストリームに書き込まれるブロックセットとして定義され、ディスクコンテキストは、ディスク上でこのブロックのすぐ後に続くブロックを含む（図４８参照）。これら２つのコンテキストの共通部分が多いときには、プリフェッチのおかげでこの共通部分におけるブロックの読み出しは非常に高速である。実際、これは、特に初期バックアップについて、かなり頻繁に起こる。
ディスクコンテキストがストリームコンテキストからのデータをほとんど含まない場合に断片化の問題が生じる。これは、同じブロックが、複数のストリーム位置に論理的に存在し、その１つ１つにおいて異なる隣接ブロックを有するとき、重複排除のために起こる。この影響は、インターナル重複ブロック（インターナルストリーム断片化）によってももたらされるが、前章で提案した限定されたフォワードナレッジを有するキャッシュによって実質的に除去される。以下に示すアルゴリズムは、最新のバックアップストリームで初めて出現するブロックを処理することだけを可能にする。
なお、ディスクコンテキストのサイズは、リストアアルゴリズムに厳密に関連し、プリフェッチのサイズに等しい。一方、ストリームコンテキストのサイズは、最大共通部分を制限しないために、この値を下回ることはできない。実験に基づき、ディスクコンテキストおよびストリームコンテキストの通常サイズは、デフォルトではそれぞれ2MBと5MBに設定される。他の値の影響は、セクション５．５で説明する。
<５．４．２ コンテキストを類似させ続けること>
基本的なアイデアは、高断片化された重複、つまり、現在のバックアップにおけるストリームコンテキストがディスクコンテキストとは大きく異なるブロックを再書き込みすることである。そのような再書き込みでの試みは、両コンテキストを類似させることである。再書き込み後、ブロックの新しいコピーは読み出しに用いられ、これは、同じバックアップに保存されている他のブロックをプリフェッチすることを意味し（したがって断片化を減少させる）、また、古いコピーは最終的にバックグラウンドで回収される。
再書き込みのたびに、バックアップ速度が低下し、ブロックの古いコピーが回収されるまで追加領域を消費するため、ほんの一部のブロックだけを再書き込みすることを目標とする。初期設定では、再書き込み限度と呼ばれるこのパラメータが、現在のバックアップにおいてこれまで見られたブロックの５%に設定されている。
アルゴリズムは、再書き込みの必要があれば遭遇した重複ごとに決定する、書き込まれるバックアップストリーム上においてループで繰り返し適用される。アルゴリズムによって処理される最新の重複ブロックを、判定ブロックと呼ぶ。
ストレージシステムは、書き込まれるデータを事前に知らないので、重複を再書き込みするかどうかの決定はオンラインで行われる（将来の知識なし、ストリームコンテキストを除く）。上記を考慮すると、このアルゴリズムは常に、ある重複にとって次善の選択を行うことができる。たとえば、それを再書き込みすることを決定することによって（そのような再書き込み「クレジット」は、ストリーム内で後に別の重複のためにより良く確保されるけれども）、あるいは、より良い候補がストリーム内で後に出現することを期待して、再書き込みしないことを決定することによって、選択を行うことができる。しかしながら、このような候補は、実際に具体化しない可能性がある。そのため、このアルゴリズムにおける課題は、良好な再書き込みの決定を行うことである。
<５．４．３ 再書き込み決定に到達すること>
再書き込みプロセスを案内するために、重複の再書き込み有用性という概念を導入する必要がある。また、２つの閾値が各ループ繰り返し上で維持され調整される。２つの閾値とは、最小限の再書き込み有用性（定数）と、最新の有用性閾値（変数）である。
再書き込み有用性
判定ブロックのディスクコンテキストとストリームコンテキストとの共通部分が小さい場合には、そのようなブロックの再書き込みが望ましい。なぜなら、あまり有用でないデータを読み出すための１回の追加ディスクシークを回避するのに役立つからである。一方で、この共通部分が大きい場合には、そのような再書き込みはあまり得策ではない。なぜなら、追加のシークタイムは多くの有用データを読み出すのに必要な時間によって償却されるからである。
したがって、バックアップシステム内の各重複について、再書き込み有用性は、ディスクコンテキストの全体サイズに対する、ストリームコンテキストに属さないこの重複のディスクコンテキスト内のブロックのサイズとして定義される。たとえば、70%の再書き込み有用性は、ディスクコンテキスト内のブロック内のデータのまさに30%がストリームコンテキスト内の同じブロックとしても出現する。
最小再書き込み有用性
最小有用性は、リストア性能をごくわずかしか改善しない再書き込みを回避するための、CBRアルゴリズムの定数パラメータである。最小再書き込み有用性を70%に設定した。この値は高く見えるかもしれないが、低い有用性は、以下の分析で提示されるように有益ではない。
ブロックの5%が断片化された重複ブロックであり、全てが最小再書き込み有用性に等しい再書き込み有用性を有するバックアップ、という単純なケースを想定してみよう。ブロックの残り95%は断片化されていない（再書き込み有用性0%）。また、各断片化ブロックのプリフェッチでは、この断片化ブロックの再書き込み有用性を満たすために必要なブロックを越えて有用データを取得しないことを前提とする。このようなシナリオは、最大限可能な努力で、最小限可能な利得を保証する。このような場合、断片化された重複の全てを再書き込みることで、リストア性能を約12%改善する可能性があり、私見では、再書き込みを正当化するのに十分である（図４９参照）。最小有用性が５０%に設定されていたら、同様のバックアップにおいて全ての断片化された重複を再書き込みしても５%の改善にしかならず、単純に十分ではないと思われる。
ひどい断片化に見舞われており、しかしながら、全ての重複が最小有用性を少し下回る再書き込み有用性を有するバックアップが存在する可能性があることに注意されたい。しかし、このようなバックアップについて断片化により引き起こされるリストア帯域幅の低下を減らすために、このアルゴリズムは、たった5%よりも多くのブロックを再書き込みる必要があるだろう。たとえば、全てのブロックが再書き込み有用性70%であるとき、ブロックの5%を再書き込みても、せいぜい2.15%優れたパフォーマンスが保証されるだけだ。幸いなことに、実験ではそのようなケースに遭遇していない。
現在の有用性閾値
現在の有用性閾値は、現在の判定ブロックの再書き込み有用性を定義する、CBRアルゴリズムの可変パラメータである。その値を計算するために、最良5%ブロックセットが、最も高いの再書き込み有用性をもつバックアップストリーム内において、これまで見られた全ての重複の5%（デフォルト値）と定義される。再書き込み可能な各ブロックは重複でなければならず、ストリーム内に十分な重複がないかもしれないので全ブロックの5%未満であっても維持する可能性があることに注意されたい。
最良5%を確立するために、これまでに見られた各重複を再書き込みすることの有用性は、このアルゴリズムによってとられる実際の行動を考慮せずに計算される。このアルゴリズムの各ループにおいて、現在の再書き込み有用性閾値は、最良5%のブロックのうちの最悪のブロックを再書き込みすることの有用性に設定されている。このような選択が大まかに意味するところは、この値がバックアップの最初から現時点まで判定ブロックごとに現在の有用性閾値として使用され、再書き込みするブロックの数に制限が無い場合、このアルゴリズムは最良5%のブロック全てを再書き込みするだろう、ということだ。
最初は、現在の再書き込み有用性閾値は最小の有用性に設定され、ストリーム内の最初のブロックのデフラグを可能にするために、５００ブロックについてこのレベルに維持される。この部分はたった4MBのデータで構成されるので（通常は数ギガバイト以上）、５%の再書き込み限界はここでは観察されない。
再書き込み判定
判定ブロックは、その再書き込み有用性が現在の再書き込み有用性閾値の最大値と最小有用性を下回っていないときに再書き込みられる。それ以外の場合は、コンテキスト共通部分内の全てのブロックは再書き込みられない、すなわち、それらのブロックは、現在のストリーム内の重複として扱われてアルゴリズムの将来のループによってスキップされるようにマークされる。各再書き込み判定は常に、これまでに見られたストリーム内の全てのブロックに基づいてオンラインで計算される、5%の再書き込み制限の対象であることに注意されたい。
この決定は非対称であり、判定ブロックだけを再書き込みするか、共通部分内の全てのブロックを重複としてマークするかのいずれかである。すなわち、判定ブロックが再書き込みされるべきであっても、共通部分内の他のブロックを再書き込みする（か否）かの決定はない。なぜなら、それらのブロックは、再書き込みを回避するのに十分大きなコンテキスト共通部分を持っているかもしれないからだ。しかしながら、判定ブロックを重複として維持する判断が一度なされると、共通部分内の残り全てのブロックも重複として維持され、判定ブロックの読み出しがこれらの追加ブロックもフェッチすることを確実にする（すなわち、判定ブロックの再書き込み有用性は低いままである）。
ブロックの再書き込みは、ストリームコンテキストとディスクコンテキストの共通部分が拡大されることを常に保証するものではない。たとえば、ストリームコンテキストは重複だけを含んでいてもよく、アルゴリズムはその重複のうちの１つだけを再書き込みする決定をしてもよい。なぜなら、残りの重複は連続しているからだ。このような場合には、共通部分の大きさは増加しない。しかし、再書き込みさられたブロックは、ディスク上で他の新規ブロックまたは再書き込みブロックの近くに依然として残る。これらのブロックは、プリフェッチされるとリードキャッシュに残る可能性が非常に高く、リストアに必要な入出力数を減らすので、再書き込みは依然として有益である。
<５．４．４ 実装の詳細>
コンテキストの共通部分を計算する
判定ブロックのストリームコンテキストは、十分な書き込み要求がこのストリームに対して提示されるまでこのブロックの書き込みの完了を遅延させることによって満たされる。各要求について、重複状態は、データのセキュアハッシュ（すなわち、SHA-1）に基づいて、（ディスク上のブロック位置という追加の結果とともに）修正された重複排除クエリを発行することによって解決される。アルゴリズムの過去のループの１つによって埋められたクエリ結果が既にあるならば、そのクエリは発行されない。重複が検出された場合、修正されたクエリは、ディスク上のブロックの位置を返し、ブロックアドレス（ハッシュ）がこれ以上遅れることなく返される。ストリームコンテキストを埋める間、各所定ブロックは、判定ブロックまでのディスク上での距離の比較により分析され、コンテキストに既に出現する重複か（否か）を判断される。このようにして、ディスクコンテキストとストリームコンテキストの共通部分が判定される。
再書き込み有用性閾値を調整する
最良5%の有用性を追跡することは非現実的であるので、このアルゴリズムは、一定数の有用性バケット（たとえば１万個）を維持する。各バケットは、互いに素である等しい再書き込み有用性小領域を割り当てられ、全てのバケットは、有用性領域全体をカバーし、各バケットは、これまで見られたブロックの数をその有用性とともにこのバケット領域に保持する。このような構造は、各バケットに割り当てられた有用性領域内で、合理的な精度での最良5%のブロックのうちの最悪のブロックの再書き込み有用性の概算を、最小限のコストで可能にする。実際には、最小の再書き込み有用性を超える値を表すバケットだけが有用であるが、どちらの場合においても、このような構造に必要なメモリはごくわずかである。
インターナルストリーム重複をフィルタリングする
実験によると、実際には、あらゆるバックアップストリームが、そのストリームの他のブロックの重複（インターナルストリーム重複）であるブロックを含む。重複排除率を低下させなければ、そのようなインターナル重複の最適な位置を決定するためのオンラインの方法がないので、ストリームの対応重複ブロックの近傍におけるディスク位置は、潜在的に良いものだとみなすことができる。しかしながら、重要なことは、ストリームの各バージョンのバックアップ中に、再書き込みのためにCBRアルゴリズムが同じ論理位置を選択し、他のいかなる位置もこのような動作を始動させないことである。これは、各バックアップの間に論理ストリーム内の１つの場所から他の場所にインターナル重複ブロックを再書き込みすること（スラッシング）をさせないために必要とされる。一方、前のセクションで説明したフォワードナレッジを有するキャッシュは、論理ストリームの最初の位置が最も高い可能性を有するものと考えるべきであることを示唆している。一旦キャッシュに読み込まれると、長時間そこにとどまる可能性があり、同じデータに対する他の要求にも役立つ。したがって、ブロックは、それが初めてストリーム内に発生した場合にのみ再書き込みすることを考慮されるべきだ。
インターナル重複であることについての知識は正確である必要はなく、各バックアップのサイズはそれが書き込まれる前の概算で知ることができるので、比較的小さいメモリを使用するためにブルームフィルタを使用することができる。ストリームコンテキストに適しているよりも前に、各ブロックは、存在をフィルタで確認されなければならない。見つかった場合、それは標準的な機構によってシステムに書き込まれなければならない（誤判定であり得る）。それ以外の場合は、ブロックの存在を示す、フィルタ内の適切なビットが設定されなければならず、そのブロックは、ストリームコンテキストにもCBRアルゴリズムにも適していなければならない。なお、上記ビットはゼロに設定されることはなく、ブルームフィルタ全体がバックアップ完了時に削除される。
このような場合、予想されるデータ1GB毎に、ストリームの最後のバイトについて0.1%の誤判定率（キーごとに１５ビット、１２８・１０２４個のキー、７つのハッシュ関数）を超えないために、メモリの約240KBを必要とする。このような数字は許容可能である。なぜなら、ブロックの最大5%が再書き込みされると、通常はそのうちの４以下（おおよその推定で）が誤ってインターナル重複とみなされるからだ。1GBのデータは、少なくとも５００の入出力を必要とし、リストア帯域幅に対する悪影響は、通常、１%よりもはるかに小さくなる。
一般的に、ハッシングという処理は追加の処理能力を必要とするが、このケースは異なる。検討されているシステムでは、計算されたブロック全体のハッシュ（160または256ビット）を既に持っているので、ブルームフィルタ用の良好なハッシング機能としてこのハッシュの選択された数ビットを単純に使用することができる。このような最適化は、追加のプロセッサ・サイクルの最終要件を無視できる程度にする。
書き込み時のシミュレーションを読み出す
提示したCBRアルゴリズムは、少数のブロックを再書き込みすることによって、より連続したディスクアクセスを確保する際に、十分な役割を果たす。しかしながら、結局のところ、ストリームを読み出す際に重要なのは達成されるリストア性能である。再書き込みするブロックの数をさらに減少させながらこの結果を同じレベルで維持することは、各バックアップ時に支払われる費用を下げるために役立つだろう。
これを達成するために、バックアップ時のリストアシミュレーションは、標準のLRUキャッシュ置換ポリシーを用いて行われる。ブロックハッシュの代わりに、ブロック位置識別子がメモリに保持される。そのおかげで、まだシステムに格納されていないブロックの読み出しのシミュレーションを行うことができる。その構造は、LRUキューと、受信したブロックの位置がキャッシュ内に既に存在するかを確認するためのマップとを必要とし、そのためには128MBのキャッシュ（3×8バイト × 128MB / 8KB）のシミュレーションと384KBのメモリしか必要なく、ほとんどのデータセットにおいて全てのキャッシュメモリサイズについて非常に類似した結果を配信した。この拡張の導入後、同様のリストアを維持しつつ、再書き込みされたブロックの数は約20‐30%少なくなった。
バックアップ時にLRUの代わりにフォワードナレッジを持つキャッシュのアルゴリズムをシミュレーションすることは、再書き込みブロック数の低減においてより良好な結果をもたらすが、より複雑であり（追加メモリと遅延とを要する）、将来の仕事のために考慮されるだろう。
バックグラウンド動作
CBRアルゴリズムは、再書き込みされたブロックの古いコピーを削除するバックグラウンドプロセスを要する。この処理は、データスクラビングやデータソーティングといった既に随時実行されている他のメンテナンスタスクと一緒に行うことが可能である。この削除プロセスが実行されるまで、再書き込みによって使用される追加スペースは一時的に重複排除率を低減する。このようなデータの割合が制限され、メンテナンス作業が通常は非常に頻繁に行われるので、このソリューションは容易に許容されるべきである。
読み出し動作に対する変更
データブロックがコンテンツアドレッサブルである場合、新旧両方のコピーが同じアドレスを持つので、古いコピーが新しいコピーと交換されるときにデータブロックへのポインタを変更しなくてよい。最新のバックアップリストアの良好なパフォーマンスを確保するために、ブロックの最新コピーにアクセスするための唯一の手順は、システムが過去に同じブロックの多くのコピーを許可しなかった場合は、若干修正する必要があるだろう。これは、ブロックインデックスにおいて最新ブロックへのエントリのみを保持することによって行うことができる。
<５．４．５ 必要メモリ量>
セクション５．４．４に記載したように、多くのメモリを必要とする可能性があるアルゴリズムの一部は、インターナル重複ブロックの除去のために使用されるブルームフィルタである。必要なメモリは、バックアップストリーム1GB毎に約240KBであり、それほど多くは見えないが、ストリームが大きいほど、この要件に対する圧力は大きくなる。
ストリームバックアップ中に使用されるメモリの通常の量は数十ギガバイトのレベルであるため、100MB（24MBのメモリ）、さらには１TB（240MBのメモリ）までのストリームサイズにとって、提案されたソリューションは、システムや利用可能な正確なメモリしだいで許容可能である。Wallaceらにより１万を超えるバックアップシステムから収集されたデータによると、500GBを超えるストリームは、平均で、バックアップシステムの総容量の5%未満を使用するので、通常それらは非常に稀である
必要であれば、１つの大きなストリームをその論理的な内容に基づいて小さく分割することは常に可能であり、より共通したデータを一緒に配置することを保証する（セクション３．２．３を参照）。別のソリューションでは、デフラグされるブロックの数の少なさやそのデータへのアクセスの複雑さと引き換えに、より精度の低い（誤判定の数がより多い）または簡潔なブルームフィルタを使用することもできる。
最後に、上述のブルームフィルタと、デフォルトサイズ5MBのストリームコンテキストとは、システムに保存されるストリームごとに必要とされる構造である。これは、メモリの最終的な量は予想されるストリームの数で乗算されなければならない、ということを意味する。
<５．４．６ ディスカッション>
オンラインアルゴリズムの最適化
CBRアルゴリズムは、これまでに見られたブロックだけを見るので（フォワードナレッジとみなすことができる小さなストリームコンテキストも加えて）、明らかにオンラインである。残念ながら、同じ理由で、現在の有用性がストリーム全体で安定しているときにだけ、そのアルゴリズムは最適である。他のケースでは、5%の再書き込み制限を最大限に利用するとともに、特にストリームの最初のブロックと最後のブロックの再書き込み有用性の間には大きな差があるので、最終的な結果はそれほど良好ではないかもしれない（デフラグ前よりはまだ良いが）。
全ての悪いシナリオには、ストリーム全体について一定の再書き込み有用性を設定することによって、最適に対処することができる。そのような有用性の最良値は、現在の有用性アルゴリズムによって計算されストリームの最後に達成される値であろう。残念ながら、そのような情報は、ストリームを保存する前に将来の分析を必要とするであろう。簡単な概算を行って、同じデータセットの過去のバージョンのバックアップ中に収集された統計データを使用することができる。
幸いなことに、テストされた全てのデータセットにおいて、上記の問題は最小レベルであった。なぜなら、再書き込みされたブロックの数が常に5%レベル以下であったためである。したがって、オンラインアルゴリズムを用いて、最終的な結果は、インターバージョン断片化なしで達成されるものに非常に近いものであった。
オフラインCBR
CBRアルゴリズムの単純な変形を導入することができる。これは、コストを削減し利点を維持すると思われる。最初に、再書き込み対象のブロックを識別し、バックアップ終了後、後にバックグラウンドでそれらのブロックを再書き込みする。しかしながら、これは、あまり役に立たない。なぜなら、再書き込みは断片化されたブロックの読み出しを必要とし、これが極端に遅くなる可能性があるからである（正確には、ブロックが最も断片化されているため）。CBRのインラインバージョンでは、これらのブロックは、実際には、ユーザがデータを書き込むときにほとんど無料で受信される。
<５．５ トレードオフ>
ストリームコンテキストの大きさ
このアルゴリズムは、初期設定では、ストリームコンテキストの大きさとして5MBを使用する。なぜなら、それは、CBRを効果的にすることを可能にするほど十分大きく、書き込みレイテンシの向上をこのコンテキストを満たすことにより好ましいものにするほど十分小さいからだ。バックアップシステムが１ストリーム毎に100MB/sを達成すると仮定すると、コンテキストを一杯にするために50msしか必要ないだろう。2MBから20MBの間の他の値も検証され、これらの値は、最終的な帯域幅の結果がほんの少し異なるものの、所望のレイテンシを減少させたり増加させたりするために許容可能であるが、再書き込みされた重複の数のばらつきは大きくなる（ストリームコンテキストが大きいほど、再書き込みされるブロックは少なくなり、リストア帯域幅は若干悪くなることを意味する）。他方、あるシステムにおいて遅延が重要である場合、書き込み確認を待つことができる最大限許容可能な遅延でストリームコンテキストの大きさを定義することができる。このような場合、各ブロックのストリームコンテキストは異なるだろうが、まだ合理的なデフラグ結果を提供するに違いない。
なお、上記の例での遅延は、既にかなりのレイテンシを有する非重複ブロックのためだけに導入されるだろう。
再書き込み回数
再書き込み回数の初期設定での上限はストリーム内でこれまでに登場した全ブロックの5%に設定されているが、いくつかの個別の要件の場合にはこの値は容易に変更することができる。上限を高くすると、再書き込み有用性が最低限よりも高い全てのブロックが再書き込み対象となり、CBRデフラグをせずに長時間バックアップされたストリームにとって非常に有用であるかもしれない。もちろん、このようなバックアップの時間は比例して増加するだろうが、次からはその制限を５%に戻してもよい。
また、上限を低くすると、最小限の帯域幅の低下だけが許容可能である場合に（たとえば1%未満）有用であるかもしれない。そのような場合、このアルゴリズムは、最も断片化された再書き込み対象ブロックの選択に役立ち、最小限の関連コストで最高の利益を提供するだろう。
<第６章 トレース駆動型シミュレーションでの評価>
<６．１ 実験方法>
実験の目標は、ディスクそのもの以外にはボトルネックのない全ての、または、少なくともほとんどのシステムに共通する環境に関する問題を示すことであり、個々の実装を詳細に調べることではない。このように、通常はある所定の実装の制限でしかない構造上の仮定を用いて、実験を不明瞭にすることなく、実際の断片化問題の深刻度とそのソリューションの効率性とを評価することを優先する。言い換えれば、このセクションに示された結果は、性能の上限とみなされ、インライン重複排除機能を持つ最も一般的なシステムにとって特に重要である。なお、オフライン重複排除機能を備えたシステムは、インターバージョン断片化には悩まされないが、ストリーム中に内在する断片化には対処しなければならない。そのために、第４章で提示されここで評価されるフォワードナレッジを有するキャッシュは、非常に役立つ。
同僚の協力も得て、数千の可能性のある構成で（多くのコアやマシンに対して）並列テストを行うことが可能な、１万２千ラインのＣ＋＋シミュレータを用意した。実在するユーザから収集した実際のトレースで、このシミュレータは、結論と最終的にこの研究で提示される数字とにつながる、結果と統計データをもたらした。これは達成された結果の一部にすぎないが、提示された数字は、重複排除機能を有するバックアップシステムに存在する断片化の問題を分析し克服するうえで、最大の影響力を持つ最も重要なものである。
<６．１．１ バックアップシステムモデル>
インライン重複排除を行う大多数のバックアップシステムの共通部分を説明するのに十分に一般的な、バックアップシステムモデルを提案する。これは、主要な問題の特徴に関して特に実装されるうえで十分に簡潔で、かつ、限られた時間で数多くの実験を実施するために十分に効率的である。
書き込みシミュレーション
このモデルでは、各測定の開始時には空である１つの連続スペース（１つの大きなディスクのようなもの）で構成された、単純なストレージサブシステムを想定した。シミュレータでの書き込み処理は、セクション３．２で説明したインライン重複排除を行うシステムに存在する全ての特徴を維持するよう設計された。主なものは、局在性を維持するブロックの配置や現在占有されている領域の後への新しいブロックの配置などである。このような書き込みアルゴリズムは、最大の書き込み帯域幅と最小のリソース使用率とを保証する。これらは、バックアップ実行中において常に優先事項であった
シミュレーションに用いたデータは、実在するユーザから収集した。処理を最適化するため、ラビンフィンガープリンティング法を用いて、所定のデータセットの各バージョンを平均サイズ8KBのブロックにチャンクした（今日のバックアップシステムにおいて最も一般的である）。このような処理の後、短いハッシュだけ（64ビット）を有し、各ブロックのサイズを持つトレースが、保存されて全てのシミュレーションに使用された。そのおかげで、実験が行われるたびにチャンキングやハッシングを実行する必要がなく、ディスクイメージ全体をシステムメモリに維持することができたので、テスト処理は非常に効率的になった。
リストアシミュレーション
セクション３．１．２で説明したように、プリフェッチングとキャッシングを用いる読み出しは、ストレージ環境内で最も一般的に使用されている。
全ての実験において固定サイズのプリフェッチが使用されるので、読み出し帯域幅は、リストア中のデータ入出力の数に反比例すると思われる。性能が他の要因の影響を受けるシステムは確かにあるが、実現される帯域幅と固定サイズの入出力の数とを関連付けることにより、断片化問題の核心に焦点を当て、ネットワークスピードやＣＰＵスピードなどの２次的要因を無視することが可能になる、と確信する。
高断片化されたデータを有する今日のディスクドライブで最も効率的であるとして、2MBという一定のプリフェッチサイズを想定した（理由は次のセクションを参照）。キャッシュサイズは、問題をより一層可視化するために、リストアされる１つのストリームにつき128MBから1GBの間で変化する一方、サイズが無制限のキャッシュを使用する実験は、最大限の理論的制限に関する重要な情報を提供する。一般的なLRUデータ置換ポリシーは、最も一般的であり、現在の性能レベルを示すために使用される。
なお、フォワードナレッジを用いた実験では、将来出現するとわかっているブロックのみがキャッシュに保持される。フォワードナレッジが短い場合、あるいは、将来使用されるブロックがごく少数である場合、キャッシュメモリは十分に利用されないかもしれない。このようなアプローチは最適ではないが、限界を明確に可視化するために使用することを決定した。また、大きなフォワードナレッジを持つ場合は特に、メモリをLRUと同様の方法で十分に利用し続けても、少ししか役に立たないか、あるいは、まったく役に立たない、ということが実験によって示された。この結果に基づくと、追加メモリがフォワードナレッジを拡張するためにまず使用されなければならない、ということが明らかであり、これは、具体的な実装に関していえば、オラクルとキャッシュとの間における動的なメモリ分割を示唆する。
ディスクコンテキスト／プリフェッチサイズの選択
プリフェッチは、ディスク上に連続して配置されたデータを読み出すために非常に有効である。重複排除を行う環境でこれを示すために、６つのデータセット全てについて512KBから8MBまで変更される固定プリフェッチサイズを使用してシミュレーションを行った（図５０参照）。ここでの比較は様々なプリフェッチサイズを使用して行われるため、入出力の数だけに基づく性能の外挿はもはや行うことができない（このようなケースでの比較結果は、ディスクがどのくらいの量のデータをシーク時間内に読み出すことができるかに因る）。したがって、一般的なエンタープライズデータセンター容量のHDD仕様を使用して、達成される性能について推論できるようにした。
図からわかるように、断片化データおよび非断片化データともに、６ケース中４ケースにおいて、最短リストア時間はプリフェッチサイズ2MBで達成される。例外は、ウィキとゼネラルファイルサーバで、8MBのプリフェッチがわずかに優れている。これらの結果に基づき、一般的なLRUキャッシュで断片化データおよび非断片化データの両方にとって最も代表的なものとして、テストの大半に対して2MBのプリフェッチを使用することにした。これら２つの例外は、別のセクションで明らかにされ、フォワードナレッジキャッシュを使用してより大きいプリフェッチサイズを使用する時や、スケーラビリティの全体像を考慮した後で、将来的にリストア帯域幅が増加する可能性を示す。
可変プリフェッチサイズも選択肢であってよいが、ストリーミングアクセスが関係している場合は特に、ある程度まで断片化を隠すことができるだけである。ランダムリードが検出された時に少量のデータを読み出すことによって、現在の性能は向上するかもしれないが、ストリーミングアクセスが十分早く検出されなかった場合、性能を低下させる可能性がある。プリフェッチが最大値から変更されるたびに、最大限可能なパフォーマンスが被害を受ける。また、このようなソリューションは、システムとその構造に関する多くの仮定を必要とする。したがって、実験においては、テストで実行される入出力の数に基づいて帯域幅を推定するために、固定プリフェッチサイズを使用することに決めた。
この測定は、ファイルシステムの物理的な断片化に起因するスピードのばらつきを無視しており、個々の入出力が互いに近接している場合にシークは早く、支配的なコスト、すなわち、１回の入出力読み出し時間を優先して個々の入出力が離れている場合にシークは遅い。
<６．１．２ 省略される要素>
実験では、一般的に多くのユーザが毎日行う増分バックアップを省略した（重複排除を行うシステムでは、新しいデータのみが保存されるので、実際には増分バックアップはフルバックアップと非常に似ている）。残念ながら、実験でデータを使用することに対して親切にも同意してくれたユーザたちは持っていなかった。そのようなデータを用いた実験は、有益ではあるだろうが、既に実験で提示された考えを述べるだけだろう。確かなことは、このようなバックアップは、断片化の問題を無くすことも弱めることもできない、ということだ。なぜなら、丸１週間後には、似たような新規のデータを同じ記憶領域に書き込むことになるからだ。実際には、日々の修正は、より小さくより頻繁であるので、問題をより深刻にするかもしれない。というのも、１週間分の新規データは、１つの領域ではなく５つから７つの領域に分割されるからだ。
現代のバックアップシステムにおいて、多くのバックアップを同時に処理することができるということは、重要な機能の１つである。実験では１つのストリームの負荷だけが検証されたが、このようなアプローチは、実験を行って、ディスク上の最適なブロック配置での結果を示すための、反復可能な方法を提供することを可能にする（他のセットやコンテナからのデータがプリフェッチ力を制限することはない）。多くのストリームを同時に書き込むことは、実装に関連する多くの課題につながり、各システムの視点とは別に問題を検討することを必要とするだろう。これが目標ではなかったので、最も簡単な実装を提供することに決めたが、これは、書き込み帯域幅とリストア帯域幅の観点から、各システムにとって最適なケースに実際に近くなければならない。同時に書き込まれる各追加ストリームは、少なくとも別々のコンテナ内の全てのストリームを保存するという問題の解決を必要とするが、さらなる断片化がもたらされる可能性がある。
データ保持の特徴、したがって、データ削除は、常にバックアップシステムに存在し、重複排除を考慮すると特に困難である。１つのバックアップシステムは、非常に長い時間保存されるので、どのバックアップを除去するかという決定をある時点でしなければならない。このことは、データ断片化にも影響を与える。実際に、実験が示すところによると、バックアップを削除する正確なスケジュールが、結果に対して、全体的な重複排除率を変えるのとは別の形で影響を及ぼすことは特にない。また、実験では、各データセット内のバックアップの数は比較的少なく、したがって、データ保持ポリシーを適用して断片化の変化を検証しても、十分に一般的な結論を引き出すことはできないだろう。
実験で省略した要素の１つはまた、グローバルな重複排除（システム全体における）であり、これは市販されている一部のシステムで発見することができる。その主な理由は、テストを実行して、限られたインパクトファクターとともに信頼性の高い結果を提供することの難しさである。決定の詳細は、セクション３．２．３で提示した。
<６．１．３ データセットの説明>
断片化の問題を診断して提案したアルゴリズムを検証するために、サイズが5.7TBを超える実際のユーザーデータを表し、かつ、６セットの週毎のフルバックアップから成るトレースを収集した。各セットの特徴を図５１に示す一方、それらのコンテンツの種類を以下に提示する。
・ディベロプメントプロジェクト。大きなＣ＋＋プロジェクトのCVSデータ、LDAPデータ、サーバ設定ファイル
・イシューリポジトリ。イシューリポジトリデータ（XMLとアタッチメントを含む）、サーバ設定ファイル
・ウィキ。ウィキデータ、サーバ設定ファイル
・ゼネラルファイルサーバ。コンピュータサイエンス研究室のホームディレクトリ（NetWare）
・ユーザディレクトリ。ソフトウェア会社内の１８人のユーザのLinuxホームディレクトリ（tar）
・メール。ソフトウェア会社内の３５人のユーザのメールボックス（tar）
<６．１．４ テストシナリオ>
各テストは常に空のシステムで始まり、パラメータ（キャッシュおよびプリフェッチサイズ、キャッシングアルゴリズム、フォワードナレッジサイズなど）のほかに３つの異なるシナリオで実行することができる。
・base：次々にロードされるデータセットからの全てのバックアップ（インターナル断片化およびインターバージョン断片化を含む）
・defrag：CBRデフラグが有効な状態で次々にロードされるデータセットから全てのバックアップ（最後のバックアップがCBRアルゴリズムにより制限される、インターナル断片化およびインターバージョン断片化の両方）。なお、この結果は、実際にCBRアルゴリズムを用いた実験においてのみ示されるだろう。
・max：システム（インターナルストリーム断片化のみ）にロードされるセットからの最後のバックアップのみ。この結果は、ストリームにとって可能な最大帯域幅レベルと言うことができる。実際には、サイズ無制限のキャッシュを使用する場合に最大である。これは現実的にオフライン重複解除で配慮されるが、関連コストとともにである（セクション２．２．１を参照）。
各シナリオの目標は、提示されたアルゴリズムの効果を測定して、様々なオプションを重複排除がないバージョンと比較したり（全ての実験においてx軸）、オプションどうしで互いに比較したりするために、断片化された（base：ベース）状態、デフラグされた（defrag：デフラグ）状態、および、断片化されていない（max：マックス）状態で、システムを視覚化することである。なお、シナリオに関係なく、インターナルストリーム断片化は、重複排除レベルを下げて論理構造を変更することなく取り除くことはできないので、ストリーム内に常に存在する。また、セクション３．２．１で既に述べたように、それは最終的な結果に大きく影響し、全てのシナリオにおける数字が重複排除なしで達成されたレベルとはかけ離れたものになる（ネガティブな形でもポジティブな形でも）。
別の重要な考察は、キャッシュサイズが無制限であるマックスシナリオは、理論的に達成可能な最大帯域幅とみなすことができる（バックアップ全体が、読み出し順に１つの連続領域に配置され、１度読み出された全てのブロックがキャッシュから動かされることはない）。
<６．２ フォワードナレッジキャッシュの評価>
<６．２．１ 要件を満たすこと>
性能の結果
第４章で提示した、限られたフォワードナレッジ持つキャッシュは、断片化されたデータと断片化されていないデータ（オフライン重複排除を含む）の両方にとって、各バックアップ（最新のバックアップを含む）のリストア時のメモリ使用の最適化に非常に役立つ。これは、平均帯域幅の増加を62%から88%までの間で保証する（図５２を参照）。
また、６ケースのうち４ケースについては、8GBのフォワードナレッジを持つキャッシュメモリの256MBしか持たない断片化されていないデータセットは、サイズ無制限のキャッシュで実現したものとほぼ同じ結果を既に提供している。残り２つについては（ユーザディレクトリおよびメール）、可能な選択肢は、1GBキャッシュを使うLRUと比較して、256MBサイズのキャッシュのままで、追加の帯域幅の22%‐73%を得ることか、1GBキャッシュの同じサイズを使って、22%‐253%の帯域幅増大と、より大きなフォワードナレッジで可能な追加の20%と得ることである。正確な結果は図５３および図５４に示され、その詳細な分析は、後続のセクションで見ることができる。
上記の特徴に加えて、フォワードナレッジを持つキャッシュは、利用可能なリソースとリストア帯域幅要件とに基づいて幅広い選択肢を可能にする。メモリ使用量は８倍少ないが性能は若干良好である安価な選択肢（1GBのLRU対フォワードナレッジを有する128MB）と、メモリの量は同じだが性能はより高い選択肢との間で選択することが可能である（図５２参照）。実際のシステム使用パターンに従って、どちらの選択肢も、キャッシュ置換ポリシーとして、現在最も一般的なLRUアルゴリズムから大きく飛躍して、非常に興味深いものに聞こえる。
追加リソースの使用と考えられるトレードオフ
セクション４．４．４で詳細に説明したように、限られたフォワードナレッジの使用は追加リソースを必要とし、それは総費用に含まれなければならない。最も効果的なケースでは、メモリ（8GBのフォワードナレッジに対して13MB程度）と、帯域幅（約0.256%減）である。後者は無視できる程度に小さいが、前者は、キャッシュメモリの合計量が少ない場合は特に、いくらかの差を生む可能性がある。256MBのキャッシュが最も効果的であると一般に考えられるが、8GBのフォワードナレッジを備えてもメモリ使用量は約5%高くなるだけである。帯域幅が増加することと、無限のフォワードナレッジをいかに上手く見積もるかということとを想定すると、このコストは高いとは思えない。
なお、実験では、この追加メモリは、初期設定で合計キャッシュサイズに含まれていない。これにより、まったく同じキャッシュサイズを維持しながら、様々なフォワードナレッジサイズと性能に対するその影響との明確で簡単な比較が可能になる。考えられる実装は、それぞれ、異なる量のメモリを必要とし、それは、可視化するには複雑ではるかに多くのテストを必要とする。
調整可能性
フォワードナレッジを備えるキャッシュもまた、追加メモリを費やして必要なフォワードナレッジのサイズを設定することで調整可能である。一般に、フォワードナレッジが多いほどソリューションはより良好であるが、詳細には、このような性質は限られており、インターナル重複パターンやキャッシュメモリのサイズ、ストリームの状態（断片化されているか否か）に依存する。セクション４．５で既に述べたように、所望のソリューションは、最高の性能の結果を確保するために、利用可能なメモリの総量内で実際のキャッシュとフォワードナレッジとのメモリ分割を自動化することであろう。
コード修正と重複排除
コード修正は、ある所定の実装においてアルゴリズムを使用することために必要であるが、非常に限定的であって重複排除効率に影響を与えない。必要とされる２つの修正は、通常はデータリストアを担うアルゴリズムだけを検討し、既に利用可能なインタフェースを使用してキャッシュメモリを管理する。前者は、オラクルを実際のフォワードナレッジで満杯にするためにだけ要求され、各標準的な読み出し要求に適切な情報を添付することによって簡単に行うことが可能であり、他のシステムコンポーネントの観点からは修正がほとんど見えなくなる。一方で、後者は、リストアアルゴリズムに限定され、実装を単純に交換することを容易にするだけだ。このような限定された修正は、市場に存在するほとんどの（あるいは全てかもしれない）システムのためにアルゴリズムを適切にする。
<６．２．２ フォワードナレッジサイズの設定>
図５３および５４は、フォワードナレッジを持つキャッシュの影響を、制限ありの場合（512MB、2GB、8GBまで）と制限なしの場合（この研究で前に使用したベラディのキャッシュと同じ）とを、標準LRUアルゴリズムとの比較とともに示す。
２つの図において、最高の利得（%にて。LRUと比較した場合）はほぼ常に最小のキャッシュサイズで可能であるが、実際に任意の量のフォワードナレッジを使用した場合に非常に良好な結果になることがわかる。この理由は、ブロックは再度要求される前に既にキャッシュから動かされているので（ディベロプメントプロジェクトおよびゼネラルファイルサーバのデータセットを見ると最もよくわかる）、少量のキャッシュではLRUアルゴリズムの効果が非常に小さくなる、ということである。フォワードナレッジを持つ場合、キャッシュ内の各ブロックは、それぞれの目的を持ち、少なくとも一度使用されるまでは置き換えられない（プリフェッチされたブロックが、キャッシュ内に既に存在する他のブロックよりも早期に読み出される場合にいくつかのまれな例外はある）。また、少量のメモリの場合、キャッシュはほぼ全ての場合に実験全体で１００%利用されるが、高めの値では必ずしも当てはまらない（詳細はセクション６．１．１を参照）。たとえば、断片化のないディベロプメントプロジェクトは、無限のフォワードナレッジを持つ場合でも、たった128MBのキャッシュメモリで既に最大の帯域幅を実現している。
フォワードナレッジを増加させることは、得られる結果を改善するのに常に役立つ。しかしながら、利得は、使用されるキャッシュの量とストリーム中に存在するインターナル重複ブロックのパターンとに非常に相関している。重複の問題は、ディスクからブロックを再読み出ししないために必要なメモリの最小サイズを定義するが、実際にはそれがキャッシュの所望のサイズである。全てのブロックを見つけて限られたフォワードナレッジに保持することが可能であり、かつ、必要なサイズのメモリを持っていれば、プロセスは最も効果的になる。この特徴は、最大量のインターナル重複を含む、メールデータセットの場合に特に目立つ。２つの図において（断片化ありと断片化なし）、1GBのキャッシュと8GBのフォワードナレッジを持つ場合、より小さいメモリとフォワードナレッジサイズを持つ場合よりも有意に良好な結果となる。
一方、限られたフォワードナレッジが実際にキャッシュメモリの使用量を制限する場合が多い。実装において、フォワードナレッジを持つキャッシュは、シミュレーションされるたびに、将来使用される（フォワードナレッジ内に見つけられた）ブロックのみをメモリに保持する。したがって、この場合のキャッシュ量は、使用中のメモリの具体的な量というよりも、最大の制限と見るべきである。実際の値は、シミュレーションを通して変化するが、ある点においてピークに達し、それは、別のメモリを追加しても結果を改善しないことを意味する（より多くのフォワードナレッジが使用されない限り）。このようなシナリオは、512MBに制限されたフォワードナレッジの場合に最もよく見られる。この場合、128MBよりも大きいキャッシュは、提示されるどのデータセットに対しても目に見える利益をもたらさない。なぜなら、128MBしか実際に使用されないからだ。将来の知識に対する他の制限があると、そのような境界は、データセット毎に異なり、図５３および図５４から容易に読み出すことができる。
全体像を把握するために、バックアップ全体のサイズに関連させてフォワードナレッジを見ることは興味深い。図５３と図５４とを比較するとわかるように、包括的に正しい１つの主張は、断片化されたデータは断片化されていないデータよりも必要とするフォワードナレッジが少ない、ということだと思われ（詳細は次のセクションを参照）、これにより、フォワードナレッジ用のメモリはデータセットの寿命とともに変化するべきである、という結論に導かれる。その他の洞察は、ストリームサイズではなく、ストリームの詳細な特徴に依存する。図を見ると、2GBのフォワードナレッジを持つことは、128MBのキャッシュを持つ全てのデータセットにとっては全く十分であるが、256MBの場合には少し足りず、特にイシューリポジトリの場合には実際にかなり小さい。非常に大量のストリームがある場合に変わり得る１つのことは、無制限のメモリを使用する最適なアルゴリズムまでの距離であり、これは理解可能である。これは特にユーザディレクトリの場合である。
<６．２．３ 必要なキャッシュサイズに対する断片化の影響>
様々なフォワードナレッジサイズを持つキャッシュメモリ使用の効率について再び図５３と図５４とを比較すると、興味深い事実を観察することができる。前者（インターバージョン断片化あり）について、8GBのフォワードナレッジは、1GBのキャッシュが、無限のフォワードナレッジでアルゴリズムの最大8%以内にとどまるために十分である（平均2.48%）が、断片化されていないオプションは、保持する価値のあるより多くのデータが入出力のたびにリストアされるので、より高い要件を有する。この場合、8GBのフォワードナレッジは、最高256MB（無制限のオプションからの逸脱は最大2.3%；平均0.83%）までのキャッシュに対しては極めて役に立つが、512MBになると既に不足を示している（最大19.25%、平均5.48%）。このオプションとより大きなキャッシュオプションでは、より長いフォワードナレッジが必要である。なお、実験では、フォワードナレッジ内に見つかったブロックだけがキャッシュに保持可能である（詳細はセクション６．１．１を参照）。フォワードナレッジが短い場合や、将来的に使用されるブロックがごく少数である場合に、キャッシュメモリは十分に活用されないかもしれず、これは、異なるメモリサイズでの２つの結果が同じである時に図面上でしばしば見られる。
データセット毎の最大必要メモリを測定するために、無制限の量のメモリと無限のフォワードナレッジでテストを行った。図５５の結果は、フォワードナレッジを有する場合にも、データ断片化が必要なメモリに重大な影響を与えることを示す。６つのケースのうち３つのケースではインターバージョン断片化が起きた後で必要メモリが２倍になった一方で、イシューリポジトリについては必要メモリが９倍になった。残り２つのデータセットについての必要メモリは同様のレベルにとどまった。
<６．２．４ より大きなプリフェッチでの検証作業>
セクション６．１．１からの観測のために、実験のほとんどは、サイズが2MBの固定デフォルトプリフェッチで行われた。なぜなら、それは、最も一般的なLRUアルゴリズムの観点で効果的であり、様々なアルゴリズム間での比較を容易にしたからである。このようなレベルのプリフェッチサイズ（2‐4MB）は、多くの論文で使用されるサイズとも同様であり、最も一般的なサイズとみなされることを示唆する。それにもかかわらず、フォワードナレッジを有するキャッシュアルゴリズムを持つことは、これらの仮定を大きく改めることが判明した。プリフェッチサイズと関連してリストア帯域幅における差を可視化するために、一般的なエンタープライズディスクの特徴を用いたシミュレーションを行った（持続データ転送速度：175MB/s、リードアクセスタイム：12.67ms）。図５６に示す結果は、各条件（断片化ありと断片化なし）でのそれぞれのバックアップと、異なるリストアアルゴリズムの使用とが、それ自体の最適プリフェッチサイズを有することを示唆し、それは互いに大きく異なり得る。１つの明確な観察結果では、このような最適プリフェッチは、断片化されたデータよりも断片化されていないデータについて常により大きく、LRUよりもフォワードナレッジアルゴリズムについて常により大きい、ということである。その結果、より大きなプリフェッチへと切り替えることは、非生産的なシークを制限する、より少ない数の入出力を通じてリストア帯域幅を向上させる。フォワードナレッジアルゴリズムのおかげで、プリフェッチサイズは、LRUの場合よりも２‐１６倍大きくなり、したがって、断片化されたデータについては11%‐117%（平均68.47%）のレベルで、断片化されていないデータについては27%‐252%（平均120.24%）のレベルで、最大リストア帯域幅を増加させる。フォワードナレッジおよび2MBプリフェッチによる結果と比較すると、プリフェッチサイズの拡大により、断片化されたデータについては0%‐48%（平均23.89%）の追加利得が、断片化されていないデータについては3%‐92%（平均53.90%）の追加利得が与えられる。
<６．３ CBRの有効性の評価>
<６．３．１ 要件に適合すること>
性能の結果
第５章で提示したCBRアルゴリズムは、全てのトレースについてインターバージョン断片化の影響を排除する際に非常に有効である。256MBのLRUキャッシュを用いる一般的なシナリオでは、各データにおける最新バックアップのリストア帯域幅は、結果として平均で最大帯域幅の2.48%以内（21.29%以内から）であり、これは、インターバージョン断片化がない場合に達成される（たとえば、単一のバックアップを保存することによって）。これは平均でたった29.1%（8%‐94%）のリストア帯域幅増を示すが、重要なことは、考慮されるべきさらなる劣化という側面である。残念ながら、アルゴリズムの真の可能性は、長年のバックアップをカバーするトレースがないために、ここでは提示できなかった（詳細はセクション３．３．２を参照）。
図５７に示す結果をより深く検討すると、各データセットに特有の興味深い所見をいくつか述べることができる。たとえば、断片化の最大の増加は、イシューリポジトリのバックアップ２および７で発生する。これはデータ削除によって起こる可能性が最も高い。なぜなら、これらのバックアップだけが、前のバックアップよりも著しく小さいものであるからだ。一方、ユーザディレクトリの図とメールの図で見られるピークは、十分には完了していないバックアップによって引き起こされており、大抵の場合、他のピークはバックアップストリームの特徴（重複の数、固有のブロック、バックアップサイズ）において通常のピークとは大きく異なる。残念ながら、それらの偏差の中核となる理由を確認することはできなかった。
使用される追加のスペースとリソース
このアルゴリズムは、再書き込みされた重複ブロック以外に追加スペースを使用しないので、追加のスペース消費量は、全てのブロックの5%に満たない。実際の数字はずっと低く、0.35%から3.27%（平均1.58%）である。ブロックの古いコピーは、たとえば定期的に行われる削除プロセスの一部としてバックグラウンドで除去されるので、スペースの消費は一時的なものにすぎない。追加のディスク帯域幅の消費も再書き込みされたブロックの書き込みに制限されている。
調整可能性
提示されたアルゴリズムは、再書き込みされるブロックの割合を設定することによって、容易に調整することができる。この割合が高いほど、再書き込み性能がより大きく低下して再書き込みされたブロックの古いコピーを一時的に保存するために必要なディスク容量がより多くなるのと引き換えに、リストア性能がより良好になる。
<６．３．２ 再書き込みのコスト>
提示されたアルゴリズムのコストを評価する際、再書き込みに起因するバックアッププロセスの減速を推定した。CBRは重複を非重複として再書き込みするので、このような運用コストを証明するために、商用バックアップシステムであるハイドラストアの書き込みパスを変更して重複のチェックを回避し、その結果として得られた帯域幅を、重複の100%を書き込む際に変更されていないシステムの帯域幅と比較した。
その結果、重複の帯域幅は、非重複よりも３倍高かった。この数字に基づいて、ブロックを再書き込みするための４つの減少の要因（標準的な重複書き込み／検証のための１＋追加の書き込みのための３）とその重複排除との関係を使用した。たとえば、5%のブロックが再書き込みされると、5.17%から最高で15%の減少が起こる。全ての再書き込みブロックは重複であるので、実際の減少は、元のストリームにおける重複の割合に依存する。より高い割合になるほど、より大きな高い減少になるほど、ストリーム内の全てのブロックが重複であるときに15%の減少が達成される。
最大限の提示された減少が重要なようだが、実験が示すように、アルゴリズムはめったに最大許容再書き込み（図５８を参照）に達しない。これは、最小限の再書き込み有用性が70%と高く設定されているために非常に保守的になり、バックアップストリームを処理する間、5%の制限を常に遵守するからである。その結果、CBRはバックアップ時間を1%〜9%増加させ（平均4.21%；図５８参照）、これは妥当だと思われる。しかしながら、潜在的なコストを低減させて最大限の利得で再書き込みだけを行うために、再書き込みされるブロックのより小さな制限を設定する可能性は、まだ存在する。
再書き込みによって導入される、コスト削減のための代替オプションは、n番目のバックアップ毎にだけアルゴリズムを実行することである。このようなソリューションも、非常に役に立ち、いくらかのリストア帯域幅コストでバックアップ処理のより小さいオーバーヘッドを導入するに違いない。
なお、このトレードオフは、バックグラウンドでのオフライン重複排除を実行するために必要なリソースの量とバックアップ後に必要な１次領域にも対処する。なぜなら、それらは再書き込みされたブロックの数に比例するからだ。
<６．３．３ 再書き込み制限の設定>
再書き込みの制限にとって最良の値を選択するために、最小の再書き込み有用性は変更せずに70%に維持しつつ、再書き込みの制限を0%から8%まで変えながら実験を行った。各バックアップセットにおける最新バックアップの結果を図５９に示す。この制限を2%や1%といった低い値に設定すると、イシューリポジトリ以外の全てのセットに適する。イシューリポジトリにとって、5%の再書き込み制限がリストア帯域幅の減少を最も少なくする。再書き込み制限が5%を超えると、それ以上増加せず、バックアップ時間を大幅に増加させるかもしれないので、全ての実験について、再書き込み制限を5%に設定することを決めた。このように設定しても、最大限の理論上の書き込み帯域幅の低下は、15%のレベルであり、現実には、平均で4%をわずかに超えるだけである。また、最大限の低下は、100%重複ストリームでのみ達成可能であり、帯域幅は既に非常に高い。
なお、ほとんどのデータセットについて、再書き込みされたブロックの数は、得られたリストア帯域幅に比例する。この相関関係は、インターナル断片化が非常に激しいメールの場合にはかなり弱く、また、ウィキデータセットの場合には当てはまらない。後者は、最後のバックアップの前の非常にまれなバックアップによって引き起こされ、このセットの標準的なバックアップよりも、約１５倍多くのブロックが追加され、はるかに多くが削除される。このアルゴリズムが多くの再書き込みをしてバックアップをデフラグしようとする一方、次のもの（このセットにおける最後）は他のものにむしろ類似しており、これにより、このアルゴリズムは過去のバックアップからのほとんどのブロックを基本的に再書き込みする。
興味深い事実はまた、デフラグ後のユーザディレクトリリストア帯域幅が、断片化のないバージョンよりも実は良好であるということだ（システム内に単一かつ唯一のストリームとして保存されている）。これはブロックの並べ替えに因るものであり、これは幸運にもキャッシングをより効果的にした。この観察はまた、ユーザの要求とは少し異なる順序でバックアップを書き込む可能性が存在することを示すが、他のテストのいくつかが示唆するように、このような効果は、LRUアルゴリズムの場合にのみ可能である。なぜなら、一般にあまり有効ではないからである（書き込まれるストリーム全体についてのフォワードナレッジと、臨機応変なブロックの再配置や高価なバックグラウンドオペレーションを必要とするだろう）。キャッシュがフォワードナレッジを備える場合、そのような現象は発生しない。
再書き込みされた再書き込み
実験は、最新のバックアップにおける全ての再書き込みされたブロックの39%から97%が、過去のバックアップの１つにおいて既に再書き込みされたものである、ということを示している。新規ブロック数が非常に少ないバックアップにおいて最も高い数字に到達し、十分なサイズのコンテキストを最終的に実現するためには多くの反復が必要となる。それらのブロックは再び再書き込みされるが、不要であるということではない（実験において、過去のまたは任意のバックアップにおいて既に再書き込みされた再書き込みがある可能性を無くしたところ、最終的なリストア性能は10‐20%低下した）。いくつかのケースにおいて、その再書き込みは、再書き込み有用性を若干減少させるが、必要なレベルを下回るほどではない。あるいは、単純にそれらのブロックを近くに移動させることで、必要とされる前に読み出される可能性を増大させるが、再書き込み有用性の値には目に見える影響はない（リストアキャッシュのため）。両方の側面は、ブロックを再書き込みするためには少なくとも１つの非重複ブロックがストリームコンテキスト内に見出されなければならないというように（次回については再書き込み有用性の低減を保証するために）、修正アルゴリズムの結果によって良好に可視化される。このような実験は、再書き込みされるブロックの数を大幅に（半分にも）減少させたが、同時に、達成されるリストア帯域幅を数パーセント減少させた。同様の結果は、ストリームコンテキストを100MBにまで増加させることで達成可能である。
再書き込みされるブロックの絶対数は依然として非常に少ないので、より良好なリストア帯域幅を保証するアルゴリズムのバージョンを維持することに決定した。
<６．３．４ 圧縮の効果>
これまで、バックアップデータは圧縮できないと仮定していた。プリフェッチサイズを一定かつ2MBに維持すると、圧縮可能なデータは、結果的に、断片化が進み、CBRアルゴリズムによってリストア帯域幅の一層良好な相対的向上が実現される。たとえば、50%圧縮可能なデータでは、リストア性能の低下が、テストされたデータセットにおいて12%‐51%（平均21.27%）から16%‐56%（平均26.12%）に増加するが、CBRデフラグが、最新バックアップのリストアを8%‐95%（平均28.94%）ではなく11‐121%（平均35.79%）向上させ、その結果、トータルでの性能低下の縮小は最大10%になる（圧縮無しの場合は最大7%）。全ての結果は、非常に類似した数の再書き込みブロックで達成された。
たとえばデータの圧縮率に基づいて異なるプリフェッチサイズを選択すれば、上記の結果を変更できることは明らかである。
<６．３．５ 必要なキャッシュサイズに対するCBRデフラグプロセスの影響>
必要とされるキャッシュメモリの観点からCBRデフラグプロセスを検証するために、無限のフォワードナレッジと考えられる無制限のキャッシュサイズでデフラグした後で各データセットの最後のバックアップを読み出す、というテストを行った。各ケースにおける実際のピークメモリ使用量は図６０に示す通りである。ここに集められた数字が示唆することは、CBRデフラグプロセスは、メモリ使用を制限して最新のバックアップをメモリ使用領域内の断片化されていないバックアップに似たものにする、という観点から非常に効果がある、ということだ。
<６．４ 両アルゴリズムの複合的な影響>
図６１は、様々なキャッシュサイズを用いる最新のバックアップについて、CBRデフラグおよび限られたフォワードナレッジキャッシュの両アルゴリズムの、単一オプションおよび複合オプションにおける詳細な結果を示す。断片化の異なる側面に対処するために使用される２つのアルゴリズムは、非常に効果的な共生関係になり、その結果、たとえば256MBを用いる様々なデータセットのケースにおいて16〜388%の帯域幅増となる（平均142.65%：図６２参照）。
さらに、このアルゴリズムは、たった256MBのキャッシュメモリを持つ無制限のキャッシュサイズで達成される最大限可能なリストア帯域幅と比較すると、非常に良好な結果を生じる（図６４参照）。６ケースのうち４ケースにおいて、結果は理論上の最大値からせいぜい13%で、改善の余地はあまり残されていない一方で、残り２つのケースは依然として遅れを取っている。ユーザディレクトリ（−34.15%）は、かなり大きいデータセットであり、より良好な結果を提供するために大きめのキャッシュと高めのフォワードナレッジとを必要とする一方で、メール（−71.15%）は、効率的なキャッシングのためにより多くのメモリを必要とするインターナル重複ブロックの大部分を含む。この場合、より多くのフォワードナレッジが、1GBのキャッシュに達した後で有益であろう。
図６３は、ベース（断片化された）LRUのシナリオおよび無制限のキャッシュサイズを用いるマックス（断片化されていない）シナリオとの比較において、時間の断片化プロセスと、256MBのキャッシュメモリを使用する提案された各アルゴリズムの影響とを示す。図を見ると、CBRアルゴリズムおよび限られたフォワードナレッジアルゴリズムの両方を結合した影響は非常に効果的であり、データが全く断片化されなかった場合のシナリオと比較すると、それらの結果は極めて近いものに維持されている（8GBFK デフラグ 対8GBFK マックス）。全てのバックアップについて、偏差が数パーセントよりも高いケースは１つだけである。
一方、収集することができたトレースに基づくと、上記の偏差が、何百何千の将来のバックアップについて同じ小さなレベルにとどまることができるかを予測することは、非常に困難である。これが可能でないとしても、断片化の影響は、このソリューションなしに示すものの一部に限定され、実際に、潜在的なエンドユーザーには決して気付かれないだろう。
図６１と図６６に収集された同じ結果とを見ると、１つの重要な事実に気付く。両方のアルゴリズムを使用したおかげで、必要メモリを８倍低減することが可能であり（1024MBから128MBへ）、より高い性能になる（11.35%‐249.61%；平均67.74%）。さらに、６つのデータセットのうち４つについて、128MBのキャッシュを用いた場合のリストア帯域幅の結果は、LRUケースにおいて無制限のメモリを使った場合よりも高かったが、５番目のデータセットの結果は非常に近く（ユーザディレクトリで4.52%低い）、最後のデータセットの結果は後退した（メールで65.22%低い）。これは、必要メモリが高く特定パターンのインターナルストリーム重複であったためだ。
この結果が示唆しているのは、多くのデータセットはメモリの一部だけを必要とし、これは今日では一般的に割り当てられるものであり、いくつかのデータセットだけはより大きな量で効果が上がるかもしれないが、これは効率的に使用される場合に限られる、ということだ。一般に、適切な量のメモリは、使用可能なメモリと、ユーザ要件と、各データストリームが求める正確なニーズとに基づいて、リストアプロセス中にかなり動的に割り当てられるべきである。
<６．５ スケーラビリティ>
最後になるが、RAIDやイレイジャーコーディングを使って１つのブロックをリストアするために非常に頻繁に１０以上のディスクを使用し、多くのストリームを同時に提供する現在のシステムで、上記の結果全てを別のレベルに引き上げることができる。実験では、ストリーム全体に対して2MBを想定したが、これは、上記設定ではディスク毎にたった200KBのプリフェッチという意味である。最近のディスクドライブを使用すると、このような小さなプリフェッチは、2MBと比較して１つのディスクからのリストア時間がほぼ６倍高いことを意味する（図３２参照）。
前述の通り、重複排除機能を有するシステムの場合、より高いプリフェッチが、より高い性能を常に意味するとは限らない。一般的なLRUアルゴリズムでの結果を見ると（図６５参照）、１０個のドライブのスピード（10×175MB/s）を有していても、8MB（800KB/drive）を超えるプリフェッチの更なる増加は、１ケースにおいてのみ、断片化されていないデータに対してのみ、わずかにプラスの影響を与える（図６５を参照）。
フォワードナレッジを使うキャッシュアルゴリズムを考慮すると、結果は全く異なるようだ。全てのケースにおいて、32MBのプリフェッチは数倍良い結果を与え、２つのケースでは（ディベロプメントプロジェクトとゼネラルファイルサーバ）、より大きなプリフェッチでさらに高い結果が得られる。１ケースだけ（ユーザディレクトリ）、16MBのプリフェッチが32MBよりもわずかに優れている。詳細には、最良のLRUプリフェッチ（各データセットに対して別個に選択される）からフォワードナレッジを使う最良のプリフェッチへと移動すると、断片化されたデータについてはさらに75%‐390%（平均184.23%）、断片化されていないデータについてはさらに116%〜933%（平均396.77%）を得ることができる。フォワードナレッジアルゴリズムおよび単純に増加する2MBのプリフェッチと比較すると、そのプリフェッチサイズは、それぞれ最大109%‐379%（平均254.72%）および132%‐835%（平均531.25%）結果を増加させることができる。
上記の数字によると、プリフェッチサイズを増大させることは非常に興味深いオプションだと思われる。しかしながら、このようなオペレーションは、使用のタイプによっては重要であるかもしれない高いレイテンシ変動をもたらすということを覚えておく必要がある。幸いにも、２次ストレージシステムでは、それは問題ない。なぜなら、この場合には帯域幅が最も重要であり、長めのレイテンシは容易に受け入れ可能であるからだ。
プリフェッチサイズを調べるともう１つの考察がもたらされる。プリフェッチサイズが大きいほど、断片化されたデータと断片化されていないデータとの違いがより分かりやすくなる。LRU標準アルゴリズムとデータセット毎の最良のプリフェッチサイズとで、デフラグは、帯域幅を約20%‐156%（平均59.72%）増加させることができるので、最良のプリフェッチサイズを使うフォワードナレッジアルゴリズムについての同じ利得は44%‐420%（平均164.18%）を達成することができる。このような結果は、適切なデフラグアルゴリズムの一層高い重要性を示唆している。
提案されたCBRデフラグアルゴリズムを使用してデータをデフラグする能力を検証するために、２つのパラメータだけを修正してシミュレーションを行った。プリフェッチサイズは、１０個のドライブでの最適に近いと思われる、32MB（3.2MB/drive）に設定され、また、ストリームコンテキストは、プリフェッチサイズに対する割合を維持するために、80MBに設定された。フォワードナレッジを8GBに設定して、キャッシュサイズは依然として256MBであった。追加調整なしに達成された結果は、実際にかなり良好であった。このアルゴリズムは、リストア帯域幅を36%‐333%（平均97.66%）増加させることが可能で、全てが断片化されているわけではないストリームよりもわずか4%から19%（平均8.88%）低いという結果に終わった。上記の設定でデフラグすることが困難であった唯一のデータセットはメールであった。このケースにおいて、断片化されたバージョンの依然として有意な36%増加の後で、最終的な結果は断片化されていないストリームから34%低かった。
つまり、私は、多くのリストア用ディスクとこの論文で紹介したアルゴリズムとを使用することの重要性を示すもう１つの実験を行った。１０個のディスクを使用すると仮定して、256MBのキャッシュを用いる２つのアルゴリズム、すなわち、2MBプリフェッチのLRU（今日のシステムにおいてしばしば使用されるレベルを表す）とフォワードナレッジ（8GB）およびCBR最適化を用いる32MBのプリフェッチとを比較した。データセットに依存する最新のバックアップのリストア帯域幅の結果は、３．５倍から最大１６倍高く、平均が８倍を若干上回った。LRUで8MBのプリフェッチまで単純に行くことは、全てのデータセットと１０個のディスクドライブを考慮するとベストであるが、たった60%の増加であった。これは、提示されたアルゴリズムと多くのディスクドライブのおかげで、クリティカルリストアの場合に可能な急激な増加は、非常に重要であることを示している。
<第７章 関連研究>
<７．１ オフライン重複排除との比較>
インターバージョン断片化に対処するための要件のいくつかを満たす１つの簡単なソリューションは、既に市場に存在し、オフライン重複排除と呼ばれ、セクション２．２．１で説明した。その最も単純な形式では、現在のバックアップからの全てのデータは、ディスク上に連続して保存され、重複排除機能は、最新のバックアップからのブロックが、より古いバックアップから重複を排除するための基礎となるようにバックグラウンドで行われる。
その結果、現在書き込まれているストリームには断片化がなく、より古いバックアップは、その経過時間に比例して断片化されている。このアルゴリズムは、おそらく断片化に対処するために設計されたわけではないが、最近のバックアップでは排除するために非常に有効である。しかしながら、ブロックの重複排除は、ブロックを回線上で送信してディスク上に保存するよりもはるかに速いので、オフライン重複排除システムは、通常、インライン重複排除システムよりも遅いだろう（あるいは、そのような問題を回避するために、より多くのスピンドルとネットワーク帯域幅を要するだろう）。
バックアップにおける重複の割合はデータパターンに依存するが、ウォレスらにより収集された１万以上のシステムの特徴に基づいて、１０倍減レベルでの重複排除率の平均値を想定することが可能であり、その結果、平均的なバックアップ内において約90%の重複となる。セクション６．３．２で説明したように、データを書き込むことなく重複排除を行うと、最初にデータを書き込み、その後バックグラウンドでそのデータの重複排除を行うよりも３倍速くなる。したがって、90%の重複を有するバックアップストリームを書き込むには、オフライン重複排除システムでは３００時間単位かかり、一方、インライン重複排除システムでは、ブロック毎に重複排除クエリを実行するにしても、１１０時間単位しかかからない。その結果、オフライン重複排除を使用するとバックアップウィンドウが170%以上増える。通常、バックアップウィンドウは、あまり拡大することはできないので、これは明らかに許容されない。
コンテキスト再書き込みアルゴリズムの目的は、オフライン重複排除ソリューションにより保証されるデフラグのほとんどを維持し、セクション２．２．１で説明したその最大の問題に対抗することができる柔軟性を提供することであった。実際に、アルゴリズムの構成パラメータを変更すると、全てのブロックが再書き込みされ、全ての重複がバックグラウンドで取り除かれて、両ソリューションは非常に似通ったものになるだろう。一方、再書き込みされるブロックの境界を5%に設定してインライン重複排除の性能と他の側面とを保つと、断片化は主要な要因によって改善されるだろう。
オフライン重複排除とインラインCBR以外に、バックグラウンドで、つまりオフラインでコンテキストベースの再書き込みを実行するための、少なくとももう１つの選択肢があり、セクション５．４．６で既に述べた。このソリューションは、バックアップ書き込みには全く影響を与えないが、断片化されたデータを読み出してバックグラウンドでそれらを再書き込みすることを完了するのに長い時間を必要とする。さらに、ブロック再書き込みが完了する前に試みられるリストアは、依然として、小さい帯域幅に悩まされる。
上記の全代替案の比較を図６７に示す。ここで注目したいのは、両オフラインオプションのストレージ消費量は、ステージングによって、つまり重複を取り除く（あるいは重複の一部を再書き込みする）処理を、同時に、しかしバックアップ書き込みの処理に少し遅れて実行することによって改善可能である。しかしながら、ステージングは、CPUや、利用可能なディスク帯域幅およびスピンドルなどのリソースをより多く必要とする。
<７．２ 断片化測定>
チャンク断片化レベル（CFL）は、ストリームの断片化の問題を可視化するためにナムらによって導入された。データが固定サイズのコンテナ（2MBまたは4MB）に保存されたと仮定すると、このアイデアは、最適なチャンク断片化（コンテナサイズで割られるストリームのサイズ）を現在のチャンク断片化（リストア中に読み出されるコンテナの実際の数）で割り、求められた結果の最大値を１に制限することであった。結果として生じる数字は達成される性能に比例することとした。残念ながら、その数字は、リストアパフォーマンスを測定する際に非常に重要であるリードキャッシュの存在を考慮しておらず、実験を非現実的なものにした。
このアルゴリズムの第２のバージョンは、現在のチャンクの断片化の計算にはリードキャッシュの存在を含んでいたが、他のいくつかの欠陥は残っていた。１という最大値は、人工的な制限であるように思われ、実験が示すように頻繁に発生し得る、高度にキャッシュされたインターナルストリームの重複排除がある場合の実際のリストア性能を反映していない。もう１つの欠点は、実は、キャッシュ置換アルゴリズムにおけるその利用に伴う、書き込みアルゴリズム（コンテナサイズ）に対する強い依存である。キャッシュ内のコンテナ全体を維持してもコンテナを維持しなくても、特に通常はコンテナからいくつかのブロックだけが必要になるので、どちらもキャッシュにとって最適な選択肢とは思えない。一方、LRUキャッシュ置換ポリシーは、一般的にはあまり効果的ではないので、このアルゴリズムの影響はかなり小さい。この問題は、フォワードナレッジを有するキャッシュのような、より効果的なキャッシュ置換ポリシーが使用された場合には、ずっと大きいだろう。
リリブリッジらは、「速度係数」と呼ばれる非常に類似した指標を実際に提案している。これもコンテナの数に基づいているが、１を1MB毎に読み出されるコンテナの数で割るというように少し異なる方法で定義されている。コンテナサイズがCFL（4MB）と同じであると仮定すると、「速度係数」１はCFL0.25に等しい。両指標を比較すると、CFLの方が少し良いと思われるが、これは単に、１という値が重複排除も断片化もないシステムの速度を明確に示しているからである。一方、「速度係数」は何ら限定されておらず、インターナルストリームの重複排除の影響が正であっても正確な値を示す。残念ながら、このような機能は理論上の存在に過ぎない。なぜなら、実験で使用されるアルゴリズムは、無制限のキャッシュメモリが使用されても、４以上の「速度係数」（CFL1.0に等しい）を許容しなかったからである。両アルゴリズムにおける欠点は、バックアッププロセス中に作成されるコンテナサイズに強く依存することだ。
ここで提案する指標「重複無しでのリストア帯域幅の割合」は、実は、いくつかの修正で上記の指標と非常に類似する（図６８の比較を参照）。第１に、その名称はその意味を明確に提示しており、そのおかげで、非常に直感的に使用できる、第２に、この指標は、何ら結果を制限するものではなく、重複排除のないシステムよりも良好である場合であっても出力性能を非常に良く予測する。第３に、この指標は書き込みアルゴリズムからの独立性が高く、使用されるコンテナのサイズに依存しないので、広範囲のシステムで使用可能にし、様々なプリフェッチ値で実験するために使用可能にするのに役立つ。もちろん、固定されたコンテナサイズを使用する指標と全く同一の動作を反映することも簡単に制限できる。最後の要因は、シミュレーションで使用するキャッシュ置換ポリシーである。実験は、間違いなく、この要因が断片化を測定する際に非常に重要な要因であり、達成される結果に対して非常に大きな影響を持つ可能性がある、ということを示した。
<７．３ 最適化アルゴリズム>
近年、重複排除機能を有するストレージシステムの読み出し性能を向上させるという話題は、発表される論文においてかなり普及した。リリブリッジらによって提案されたソリューションは、デフラグの一種とみなすことができる「コンテナキャッピング」と呼ばれる技術を含む。このソリューションは、限られた数のコンテナだけからのリストアを保証することにより読み出し帯域幅を改善することに成功しているが、示される結果は、その著者が設計した独自のアルゴリズムとの比較ではかなり悪く、設計によって高い断片化を引き起こす（結果を分析すると、重複排除機能のないシンプルなシステムと比較して、12‐44悪いリストア帯域幅）。残念ながら、インターバージョン断片化なしで達成されるリストア帯域幅や無制限のキャッシュを使用するアルゴリズムとの比較はない。このような比較は、非常に興味深いものであろうし、このソリューションの結果を、私の研究で提示するものと比較可能なものにしただろう。それが無いと、インターナル重複排除のレベルを、最終結果に対するその影響とともに決定することはできない。それは、実験において示したように重要である可能性がある。図から得られる１つの情報は、キャッピングを10に設定すると（この論文で分析する全てのオプションの中で最も高いリストア帯域幅を達成する）、このアルゴリズムは、重複排除機能のないシステムの場合に可能な帯域幅の50‐90%を達成する（速度係数4が100%に等しいと仮定）。この結果は、それなりに良いと思われるが、このような設定で17‐50%の（データセット次第である）累積重複排除率に対する悪影響を考慮しない場合に限られる。このコストは非常に高く、書き込み帯域幅を少なくするが、本文中では言及していない。リリブリッジの調査と比較すると、私の研究で提示するアルゴリズムはいずれも重複排除率を変更せず、１つだけが書き込み帯域幅をわずかに縮小させる。これらのアルゴリズム以外に、この研究はまた、断片化問題が興味深い長期の（２年にも及ぶ）トレースに与える重要性を示したが、これは見つけることが困難なものである。残念ながら、このトレースは、他の調査用には入手可能でないと判明し、結果を直接比較することはできなかった。
要求される読み出し性能を確保するための別の方法が、ナムらによって発表された。ここでの基本的なアイデアは、チャンク断片化レベルを使用して、書き込み中に模擬読み出し性能を監視し、チャンク断片化レベルがある所定の閾値よりも低い場合に選択的な重複排除を可能にすることである。CFLはそのために良い指標であることが示されたので、このアルゴリズムは、ある予め定められた読み出し性能を保証する。実際には、この結果は、それなりに高いコストで達成される。選択的重複排除は一部の時間だけ機能するので、断片化が低コストで著しく改善されるストリーム内のいくつかの場所は省略される一方、ブロックが完璧な順序で保存されることを必要とするので、多くの不要な重複ブロックが再び保存されることになる。上記の考察に基づいて、非常に低いバックアップ帯域幅であるいくつかのケース（リストアについてCFL = 0.6を確保しつつ、70‐90%の低下）では、そのようなブロックのレベルは高いと想定することができる。というのも、重複排除率に対するアルゴリズムの影響は論文において言及されなかったからだ。一方で、この論文で提示するアルゴリズムは、追加のストレージ消費をもたらさず、ユーザによって定義されるよりも高くないコストで断片化の問題を解決しようとする。可能な限り最小のコストで断片化を改善しようとするので、このようなアプローチは、はるかに効率的である。性能が保証されたオプションを持つことも可能である（簡単な方法、たとえば現在の書き込み有用性をある固定値に設定することによって、あるいは、より複雑な方法、たとえば書込み中のリストアパフォーマンスをシミュレーションすることによって、それを設定すること）が、可変書き込み帯域幅のコストでは、許容されないかもしれない。このようなソリューションは、最初に再書き込みされるブロックが最も高度の断片化をもたらすブロックとなるので、この著者によって提案されたソリューションよりはまだ良いだろう。
RevDedupは、オンザフライの逆重複排除を行うことによって断片化に対処するシステムである。そのようなブロックを保存した後で、より古いコピーを直ちに見つけて除去する。興味深いアプローチはまた、ヌル（ゼロで満杯の）ブロックを処理するために使用可能である。このような場合、サーバはディスク書き込みをスキップし、必要があれば、オンザフライでヌルデータを作成することができる。残念ながら、システム全体が、一般的にストレージシステムには適用されない、固定ブロックサイズや大きなセグメント（4MB）といった多くのソリューションで仮想マシンイメージに合わせて調整されている。このソリューションは、リストア帯域幅を大きく改善することに成功しているが、一方では、巧妙なヌルブロックを使っても、そのシステムの扱うと、従来の重複排除と比較してはるかに低い（30‐65%）というバックアップのスループットに苦しみ、低い重複排除率を達成するに留まる。
スリニヴァサンらは、１次ストレージで発見される断片化と非常に類似した問題について説明している。iDedupによって提案されたソリューションは、保存されたブロックによるディスク上で最小の列の長さを維持することによって、シークを徐々に減らすことである。この場合、１次システムにとってレイテンシは最も重要な要素の一つであるため、タスクはより複雑である。種々の結果は、平均要求サイズおよびより良好なクライアント応答時間の増加を示すが、差は有意ではない。また、リストア帯域幅は計測されなかった（おそらくこのシステムの異なる目的による）。一方、30‐50%レベルでの重複排除率の低下は、１次ストレージシステムにとっても重要だと思われる。
<７．４ キャッシング>
フォワードアセンブリエリアは、コンテナキャッピングの他にリリブリッジらによって提案された第２の技術であり、リストア開始時に知られているバックアップレシピ（フォワードナレッジに類似）を用いてより良好なキャッシュメモリ利用を支援することを目的とする。最も単純なケースでは、フォワードアセンブリエリアと呼ばれる、読み出されたものに割り当てられる必要なメモリを使って、フルバックアップをMバイトスライスにしてリストアする。１つのMバイトスライスをリストアするために、まず、レシピの対応する部分をメモリバッファに読み込み、必要なバイト範囲を満たすために必要なチャンクを決定する。アセンブリエリアにおいて最も古い充填されていないチャンク場所を特定するたびに、対応するコンテナがリストアしつつ、そのコンテナからのチャンクを必要とするアセンブリの全ての部分を充填する。その処理が終了した後、そのデータをユーザに返すことができ、次のMバイトスライスを読み出すためにアセンブリエリアをクリアすることができる。
興味深い事実は、このソリューションが、高度に断片化されたデータ（キャッピングなしあるいは高いキャッピングレベル）に対してのみ効果があり、これは、定義されたように、私の実験においても観測可能である。残念ながら、より合理的なキャッピング値では、これにより、上記アルゴリズムが実は有用ではないものになる。ここでの主な問題は、フォワードエリア全体は、ほとんどの時間で使用されないにもかかわらず、メモリの確保を必要とする（1GBのRAMで1GBのフォワードアセンブリエリア）。このアプローチは、フォワードアセンブリエリアの最大可能サイズを著しく制限し、結果として、断片化されていないストリームにとってこのアルゴリズムはあまり効果的ではない。フォワードアセンブリエリアと比較して、この論文で提示したフォワードナレッジを有するキャッシュは、1GBのフォワードナレッジに対して1.62MBという少ないメモリを要し、将来実際に必要とされるブロックの維持のためだけに全てのキャッシュを非常に効果的に使用する。実際の違いは図５４で分かるが、512MBのキャッシュと512MBのフォワードナレッジを有するオプションは、512MBのフォワードアセンブリエリアと非常に似ているようだ（私のアルゴリズムでは、再出現するブロックはストリーム全体を通してメモリに保持可能であるが、フォワードアセンブリエリアでは、再び読み出さないという保証は領域の大きさについてだけである、という事実を除いて）。その結果、ユーザは、フォワードナレッジキャッシュを用いて、数倍少ないメモリコストで、より高いリストア帯域幅を得ることができる。
上記以外のバックアップシステムにおける断片化の全ての研究は、単純にLRUキャッシュを使用して、達成された結果を測定し、提案されたソリューションの有効性を検証する。また、ウォレスらは、生産システムにおけるバックアップワークロードについて幅広い研究を行い、最終的なバックアップをリストアするときのLRUリードキャッシュのヒット率を報告した。示した図で、追加のキャッシュメモリの影響を観察することができる。残念ながら、128MBから最大32TBのメモリという唯一の合理的な選択肢（コンテナレベルキャッシング）を見ると、結果のほとんどは、非常によく似通っていて、所望の精度で読み出すことは不可能であるので、このようなデータの表示の有用性は私たちの目的にとって非常に低いものになる。なお、4MBのコンテナでの重複ストリームアクセス無しの場合、期待されるストリームヒット率は99.8%であるが（8KBサイズのブロック５００個につき読み出し１回）、99.6％が、２倍以上の入出力動作を既に示しているので、リストア帯域幅が半分に減る。また、十分にキャッシュされたインターナルストリーム重複の場合には、キャッシュヒット率は99.8%のレベルを上回ることが可能である。
ベラディは、プログラムのプレランにより供給される、使用するブロックレファレンスの完全な配列を有する場合に最適なキャッシュ置き換えポリシーを示している。もともと、そのアルゴリズムは、ページングのために設計されたが、（ある低速デバイスからの）１つのリードサイズと最小のキャッシュ置き換えサイズとが等しくなるまで、どこでも使用することができる。同様の仮定で、Caoらは、あらゆる最適なソリューションが従うべき４つのルールを与える、統合プリフェッチングおよびキャッシング戦略の研究を行った。残念ながら、それらは、ベラディのアルゴリズムがバックアップシステムにおけるストリーミングアクセスの場合に最適ではないのと同じ理由で、直接適用することはできない。プリフェッチが１度に読み出される多くのブロックを含み、キャッシュ置換ポリシーが一つ一つのブロックに影響し得ると仮定して、除去候補毎に再読み出しの予想コストを計算しなければならない。ブロックはバッチで読み込まれるので、このコストは、常に１バッチで読み出される全てのブロックを考慮して算出されるべきであり、実際に必要なブロック数で割らなければならない。このようなアプローチは、一方では、データ専用のキャッシュの最適利用を可能にするであろうが、他方では、未知の最終結果とともにメタ情報のための追加ストレージが必要な場合がある。私の実験が示すように、簡略化された追加情報を使用する限られたフォワードナレッジを用いるキャッシュは、非常にうまく機能し、多くの場合、実際に（無制限のキャッシュサイズで達成される）最大のパフォーマンスに非常に近いパフォーマンスをもたらす。
<７．５ その他の関連研究>
いくつかの論文は、より高速な重複排除のための読み出されるメタデータの向上を調査した。ヂューらがブルームフィルタとストリーム指向メタデータプリフェッチとを用いるソリューションを説明する一方で、リリブリッジらは、疎索引作成（以前に選択された少数の大きなセグメント内だけの重複を排除する）ではメモリ消費が少ないために優れていると主張している。これらのソリューションがストリーミング書き込みパターンを想定する一方で、SSDは、ランダムな重複を除去するために使用することができる。このようなアプローチでは、より細かい重複が検出されるので、断片化問題がさらに難しくなる。さらに、上記の技術のいずれも、断片化されたデータの読み出しの問題を解決せず、全てのケースにおいて、後のバックアップほど断片化が増大する。興味深い事実は、CBRデフラグアルゴリズムが、デフラグされたストリームのデータおよびメタデータの両方へのアクセスをより連続的にすることによって、副次的影響として、いくつかの前のソリューションの有効性を向上させるということだ。
重複排除の有効性を低下させないというデフラグに関する要件を緩和した場合、データのサブセット内のみ重複排除を試みることができるので、断片化を削減する可能性がある。疎索引作成のほかに、このようなアプローチは、極端なビニングや、ProtectTierやサブチャンクの重複排除におけるような大きなセグメントの類似性や、パスティーシやデータドメイングローバルエクステンションのような重複排除を一またはまたはノードのサブセットに制限することだ。残念ながら、過去のバックアップの非常に少ない（2‐3）セグメントを検討して現在のセグメントを重複排除するとしても、これらのセグメントは既にディスク上において連続してしないかもしれない。なぜなら、それらは他からの、より古いセグメントからの重複も含むかもしれないからである。
EMCなどの一部のベンダーは、時間とリソースを消費するハウスキーピングプロセスで断片化に対処しようとしている。このプロセスの説明は公開されていないが、１つの可能なアプローチは、バックグラウンドで重複のサブセットを選択的に、つまり、CBRアプローチと同様にして、再書き込みすることであるが、オフラインで行うのではない。このようなアルゴリズムの詳細は、セクション7.1に記載されている。ハイドラストアのような他のシステムは、より大きなブロックサイズ（64KB）を使用し、断片化の問題の深刻さを低下させるが、重複排除も低下する可能性がある。しかしながら、大きなブロックサイズはまた、合計で重複排除率を増加させるグローバル重複排除を容易にする。最後に、論理オブジェクトでの重複排除により断片化を解消することができる。EMCセンテラの初期のバージョンでは、重複排除の単位は、ファイ全体であり、センテラのターゲット市場、すなわち、アーカイブのために有効なファイル全体であったが、バックアップにとって適切なソリューションではない。なぜなら、ファイルの変更は、このような重複排除を無効にするからである。
重要なことは、上記ソリューションにおいて１つも、バックアップソリューションとなると、簡単にアクセスしやすいフォワードナレッジの利用に言及しておららず、バックアップソリューションでは簡単にアクセスすることができる。
<第８章 結論>
<８．１ 概要>
本論文では、バックアップシステムにおけるデータ断片化問題を、重複排除と、この問題の２つの異なる側面に対して提案されたソリューションとを用いて説明した。また、紹介されたアルゴリズムが有る場合と無い場合とにおいて、重複排除により発生する様々な種類の断片化がバックアップリストア帯域幅に対して与える影響を定量化した。その結果をサポートするために、我々は、ユーザから収集した実際のバックアップトレースについて数多くの実験を行った。
データ断片化問題は非常に深刻であり、データセットの特徴によっては、結果的にリストア帯域幅が４倍以上減少するが（インターバージョン断片化およびインターナルストリーム断片化を含む）、１つのドライブを使用することを想定して重複排除機能を持たないシステムと比較する。使用されるスピンドルの数が多いほど、より一層大きな減少を予測しなければならない。我々の実験は、６セットの実際のバックアップトレースについて行われたが、バックアップの数は各セットで７乃至５０回だけであったので、バックアップが数ヶ月または数年にわたって行われる場合、この問題がさらに深刻になる可能性が依然として高い。最後に、インライン重複排除機能を持つ最も一般的なシステムにおいて、断片化は、リストアされる可能性が最も高いバックアップである最新のバックアップに影響する。この問題に対処するために、我々は、断片化の２つの異なる側面に対処する２つのアルゴリズムを提案した。
第１のアルゴリズムは、フォワードナレッジを有する専用のキャッシュであり、１つのバックアップに存在する多くの重複によって発生するインターナルストリーム断片化に対処することを目的とする。バックアップシステムに合わせて設計されているおかげで、このソリューションでは、再利用される実データ専用のキャッシュメモリ（つまりキャッシュ）を有効利用するために、各バックアップで既に存在しているフォワードナレッジを使用する。また、メモリ制限およびストリーム特性に応じて、このアルゴリズムは、インターナルストリーム断片化によって発生する悪い影響のほとんどを良い影響に変える。これは、何度も使用されたブロックをメモリに保持することによって可能であり、その結果、重複排除機能を持たないためにデータが順番に配置されるシステムよりも、性能がより一層良好であることが多い。
結果として、フォワードナレッジを使用した場合、平均リストア帯域幅は、標準的なLRUアプローチと比較すると、128MB‐1GBのキャッシュ構成において61%‐87%増大する。使用メモリの有効性も、2GBのフォワードナレッジだけを有する128MBのオプション（使用メモリは全部で131.25MB）を1GBのLRUキャッシュと比較すると非常に良くわかる。この場合、メモリはおよそ８分の１であるが、提案されたアルゴリズムは平均で16%良好なリストア帯域幅を達成する。さらに興味深い事実は、256MBのメモリを使用する際にフォワードナレッジが8GBあれば、多くの場合、無限のフォワードナレッジを有するのとほぼ同程度に高いリストア結果を提供できる、ということだ。また、６ケースのうち４ケースでの結果は、サイズ無制限のキャッシュで達成するものとほぼ同じである。
第２のアルゴリズムは、コンテキストベースの再書き込みと呼ばれる。このアルゴリズムは、時間とともにゆっくりと変化する同じファイルシステムにおける数多くのバックアップによって発生する、インターバージョン断片化問題に直接焦点を当てる。バックアップ中に全ブロックの多くても5%を再書き込みすることによって、このアルゴリズムは、最新のバックアップのリストア帯域幅を向上させるが、結果的に、ほとんど読み出されない古いバックアップについての断片化を増大させる。再書き込みされたブロックの古いコピーは、バックグラウンドで、たとえば、定期的な消去および領域再利用プロセス中に削除される。これは、重複排除機能を持つストレージシステムにおいて既に必要とされている。
我々が行ったトレースドリブンシミュレーションが示すことは、いくつかの選択されたブロックを再書き込みすると（平均1.58%）、最大書き込み性能が若干（1‐9%）低下するが、最新バックアップでのリストア速度低下を、LRUキャッシュでの最大帯域幅の12‐51%から多くとも7%（平均2.6%）まで事実上解消する、ということだ。
提案されたアルゴリズムはともにデータ断片化の異なる側面を扱うので、一層良い結果を達成するために両アルゴリズムを組み合わせた。実際の数字は、140%以上の平均値を有する標準的LRUよりも16%から最大388%高いリストア帯域幅を示す（ともに256MBキャッシュと用いるが、複合バージョンはさらにフォワードナレッジ構造用の13MBを有する）。その結果は、これらのアルゴリズムが互いに相補的であることを示す。なぜなら、その効果は、各アルゴリズムによって達成される利得を単に合計することで期待されるよりもずっと高いからだ（99%レベルでの平均的な改善をもたらすであろう）。また、128MBのキャッシュを用いる複合アルゴリズムは、効果的なブロック再書き込みと効率的なメモリ使用が可能である。そのおかげで、無制限のキャッシュが利用可能な状態で、妥当な性能を維持しつつも使用メモリをさらに制限する余地を残しながら、標準的なLRUよりも良好な結果をもたらす。読み出されるストリーム毎に前述のメモリが必要なので、このことは重要であるが、クリティカルリストアの場合は、一度で多くのストリームをリストアすることができる。
上述のアルゴリズムは、システム内に１つのディスクドライブがあると仮定した場合に非常によく機能するが、さらに興味深いのは、より現実的なシナリオでのアルゴリズムの挙動であり、１ストリームのリストアは多数のディスクドライブから同時に行われる。我々の実験は、このような環境においてデータ断片化問題は別の次元に達し、リストアはより一層効果を失う、ということを示している。幸いなことに、複合アルゴリズムは、設定を効果的に利用して３．５乃至１６倍、平均で８倍高い帯域幅に達することによって、このような状況でその強さを示す。
データ断片化問題は、長年にわたり既に知られていたが、数年間は、このテーマで発表された研究はなかった。このトピックを掘り下げようとする最初の論文は２０１２年に登場し、２０１３年にはさらに数件が発表された。このことが示唆するのは、このテーマが、コミュニティにとってより関心の高いものになり、データ断片化問題を明確に理解して様々なアプローチで有用になるほど十分に柔軟なソリューションを提供するための研究を、潜在的に依然として求めている、ということだ。この論文は、下記の点を通じてこの方向における大きな前進であると信じている。（１）観測された減速の３つの理由を命名して問題を詳細に解析すること。（２）問題の最も深刻な側面を解決するための２つの独立したアルゴリズムを提案すること。（３）様々な実験の結果を提供することで、コミュニティに重複排除機能を有するバックアップシステムにおけるデータ断片化問題をより良く理解させること。
<８．２ 今後の課題>
<８．２．１ リストア中の完璧なメモリ分割>
セクション４．５で既に論じたように、実際のキャッシュとフォワードナレッジとの間での固定メモリの分割は、異なるデータセットに関して、また、１つのストリームのリストアプロセス内でも、最適な選択ではない。この場合のソリューションは、動的メモリ分割であろう。この目的は、メモリの残りがまだ完全には実データによって占有されていない場合にフォワードナレッジを拡張し、将来的に読み出され必要とされるブロックを維持するための十分なスペースがない場合にフォワードナレッジを削減することである。キーとなるのは、読み出された全てのブロック（フォワードナレッジ内に見出されるであろう）が、メモリに保存され、ほぼ100%利用され続ける、という状態を常に維持することだ。
この考えは一般的には非常に簡単だが、難点は、分散システムで常に存在する各動作のレイテンシ（待ち時間）である。これは、分割をさらに円滑にする専用アルゴリズムと、メタデータを提供する層とキャッシュ自体との間の専用通信インタフェースとを必要とするだろう。それにもかかわらず、このアルゴリズムは、本論文で提示する固定メモリの割り当てよりもはるかに効果的なキャッシュ利用を可能にするに違いない。
<８．２．２ 最適なキャッシュメモリの利用>
キャッシュが固定量である場合、将来的に最も長い時間使用されないブロックを動かす上記アルゴリズムは、ページ置換ポリシーに関して言えば、ベラディの最適アルゴリズムほど最適ではない。ベラディの最適アルゴリズムの場合、ページは、ページフォールトの場合に別々に削除されたり読み出されたりすることが可能な独立した単位として実際に扱われ、その場合、バックアップストリーム内のデータブロックが異なる。
バックアップ内において、隣接するブロックは読み出される時間という点で互いに論理的に結び付けられることが非常に多いので、メモリ管理に関してこの結果を利用すると良いであろう。この目的は、置換が必要な時にブロックまでの距離を見るだけではなく、各動作のコストを実際に見ることである。その場合、将来的にNやN+1の位置にリストアされるストリーム内に配置されたブロックを維持する代わりに、N+2やN+3の位置に配置されているブロックを維持する方が実際にはより良い、ということがわかるだろう。このような状況は、最初の２つが１つの入出力でディスクから読み出し可能である一方で、後者については２つの入出力が必要である時に発生し得る。
帯域幅を増加させる際や、少量のメモリを一層効果的に利用する際の、このようなソリューションのポテンシャルを予測することは困難だ。一方で、256MBのメモリで、実験において６つのデータセットのうち４つは、最大限可能な帯域幅を既に達成しているが（無制限のキャッシュサイズで達成するものに類似する）、ユーザディレクトリとメールに関して言えばまだ可能性がる。もちろん、全ての場合において、実に最適な実施のおかげで、さらに少量のメモリによって、メモリ制限が存在しない時に可能な最大限の帯域幅に非常に近い帯域幅をもたらすことが可能である。
<８．２．３ 可変サイズのプリフェッチ>
全体的なリストア性能を向上させるもう１つの一般的な提案は、可変プリフェッチサイズの使用である。事前に知られている、あるいは、ストリームリストア時に収集されたストリームの特徴に基づいて、プリフェッチサイズを変更する、という考えである。そのおかげで、たとえば、データ要求がディスクのあちこちに多かれ少なかれランダムに散在している時に、非常に小さなプリフェッチを使用したり、データ要求が正確に連続した順序でなされた時に、非常に大きなプリフェッチを使用したりすることができる。このアルゴリズムは、要求されたデータの順序が大きく異なってもよい時や、ディスク上の各ブロックの配置に関して事前に知ることができる時には非常に有用であるけれども、バックアップシステムの場合は、その有用性が限定されるようだ。この場合の主な問題は、考えられる断片化問題を実際に解決するのではなくて、より小さなプリフェッチを使用して隠そうとするだけであり、これによりリストアが劣化する。
<８．２．４ 保存ポリシーと欠失実験>
最新バックアップのリストア性能に影響を与える要素という点でまだ調査されるべき興味深い領域は、保存ポリシーである。ここでの第１の目的は、バックアップの頻度（毎日、毎週、毎月）と、断片化レベルに対する影響とを、CBRデフラグで達成される結果とともに検証することである。第２の目的は、システム内に維持されている１つのバックアップセットの過去のバージョンの数の影響を検証することである（１回の実験中においてバックアップ頻度が固定されていると仮定）。データが多くなるほど、実際に必要なブロックを読み出すことがより困難になるが、その一方で、古いバージョンを単に削除するだけでは現在のバックアップのディスク上での位置は変更されない。同じストリームに属するデータ間でインテリジェント連結機構を備えることが、この場合のソリューションとなる。
<８．２．５ CBRアルゴリズムの可能な拡張>
コンテキストベースの再書き込みアルゴリズムに関して言えば、今後の研究は次の問題を探求するだろう。
・断片化がひどい場合に、若干低減された重複排除を可能にする
・書き込み中にフォワードナレッジを持つキャッシュアルゴリズムをシミュレーションする（リストアに使用されるものと全く同じか類似の）
・最適な現在の有用性の閾値を選択しながら、過去のバックアップ中に収集された統計を適用する
・書き込み帯域幅を節約するために、n番目のバックアップごとにCBRデフラグを実行する
・あるブロックを再書き込みとみなす場合、そのブロックを含む他のストリームを考慮する
現在のCBRアルゴリズムは、非常に良好にデフラグを実行し、最適な結果までせいぜい7%を残しているが、上記の拡張機能は、あらゆるバックアップで書き込み帯域幅削減のコストとともに、この差を低減することができる。
<８．２．６ グローバル断片化>
さらなる分析のために残された断片化の最後の側面は、１つのバックアップシステムに配置されている異なるデータセット間に存在するグローバル断片化である。セクション３．２．３において、その問題と、実際の解決への可能ないくつかのアプローチとについて既に説明した。データ重複排除の最大限の効率性にコミットしながらも、断片化のこの側面は、既存のシステムおよび一緒に配置されている異なるデータセットの組み合わせにとってのソリューションを提供するという点において、最も複雑であるようだ。多くの異なる使用パターンを通して、グローバルな重複の数は、重複排除率とさらなる断片化の量とに対するその影響とともに大きく変化し得る。重複排除範囲を同じストリームの過去のバージョンに限定することは、リストア性能の優先順位が極めて高いシステムの場合には、合理的な選択であるかもしれない。前のセクションで提案したCBRアルゴリズムへの拡張機能のいくつかは、グローバル断片化の側面において役に立つだろう。
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージ装置などの概略を説明する。但し、本発明は、以下の構成に限定されない。
（付記１）
重複排除されたブロックデータを記憶するデータ記憶部と、
前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、
前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御部と、
前記一時データ記憶部に記憶されている前記ブロックデータの記憶状態を制御する一時データ制御部と、
を有するとともに、
前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部を有し、
前記データ読出制御部は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部に対する前記ブロックデータの記憶状態を制御する
ストレージ装置。
（付記２）
付記１に記載のストレージ装置であって、
前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
ストレージ装置。
（付記３）
付記１又は２に記載のストレージ装置であって、
前記一時データ制御部は、前記読出順番情報に基づいて、前記データ読出制御部が読み出す対象としているブロックデータの読み出す順番から離れている度合いに応じて前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
ストレージ装置。
（付記４）
付記１乃至３のいずれかに記載のストレージ装置であって、
前記データ読出制御部は、前記読出順番情報に基づいて、前記ブロックデータを識別するためのブロックデータ識別子と当該ブロックデータ識別子が示す前記ブロックデータが読み出される順番を示す順番情報とを対応付けたブロックデータ順番情報を前記一時記憶部に記憶させ、
前記一時データ制御部は、前記ブロックデータ順番情報を用いて、前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
ストレージ装置。
（付記５）
付記４に記載のストレージ装置であって、
前記ブロックデータ順番情報に含まれる前記ブロックデータ識別子は、当該ブロックデータ識別子が示す前記ブロックデータの内容に基づいて算出されるハッシュ値の一部である
ストレージ装置。
（付記６）
付記４又は５に記載のストレージ装置であって、
前記ブロックデータ順番情報に含まれる前記順番情報は、前記読出順番情報に基づいて行われる一連の読み出し処理を所定の大きさで複数のセクションに分割した際の、当該分割したセクションの順番を示す情報である
ストレージ装置。
（付記７）
付記１乃至６のいずれかに記載のストレージ装置であって、
前記データ読出制御部は、読み出す対象の前記ブロックデータを前記一時データ記憶部が記憶していない場合に、前記データ記憶部から前記読み出す対象のブロックデータを含む物理領域で連続する複数の前記ブロックデータを読み出して前記一時データ記憶部に記憶させるよう構成され、
前記一時データ制御部は、前記データ記憶部から取得した複数の前記ブロックデータのうち前記読出順番情報に基づいて読み出される予定がないと判断される前記ブロックデータを削除する
ストレージ装置。
（付記８）
付記１乃至７のいずれかに記載のストレージ装置であって、
書き込み対象データを複数の前記ブロックデータに分割するデータ分割部と、
前記データ分割手段にて分割した前記各ブロックデータが前記データ記憶部に既に記憶されているか否かを調べるブロック検出部と、
前記データ分割手段にて分割した前記各ブロックデータを前記データ記憶部に記憶すると共に、当該データ記憶部に既に記憶されているブロックデータと同一内容の他のブロックデータを前記データ記憶部に記憶する場合には、当該データ記憶部に既に記憶されているブロックデータを前記他のブロックデータとして参照させるデータ書き込み部と、を備え、
前記ブロック検出部は、前記データ分割部にて分割した前記ブロックデータのうち前記書き込み対象データ中の所定範囲を構成する連続する複数のブロックデータと、前記データ記憶部に既に連続して記憶されている所定範囲の複数のブロックデータと、の共通部分の割合を表す共通割合を検出し、
前記データ書き込み部は、前記ブロック検出部にて検出した前記共通割合に応じて、前記データ分割部にて分割した前記ブロックデータを新たに前記データ記憶部に記憶する、
ストレージ装置。
（付記９）
付記８に記載のストレージ装置であって、
前記データ書き込み部は、前記書き込み対象データを分割した際に出現する同一の前記ブロックデータのうちの当該書き込み対象データの中で最初に出現する前記ブロックデータを前記データ記憶部に書き込む対象とする
ストレージ装置。
（付記１０）
請求項９に記載のストレージ装置であって、
前記データ書き込み部は、前記ブロックデータが前記書き込み対象データにおける最初の出現であるか否かを、ブルームフィルタを用いて判断する
ストレージ装置。
（付記１０−１）
付記８乃至１０のいずれかに記載のストレージ装置であって、
前記データ書き込み部は、前記ブロック検出部にて検出した前記共通割合に応じて新たに前記データ記憶部に記憶する前記ブロックデータである再書き込みブロックデータの容量が、前記書き込み対象データのうち既に前記データ記憶部に記憶されているデータの容量に対して、予め設定された割合以下となるよう設定する、
（付記１１）
重複排除されたブロックデータを記憶するデータ記憶部と、前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部と、を有する情報処理装置に、
前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御手段と、
前記一時データ記憶部に記憶されている前記ブロックデータの記憶状態を制御する一時データ制御手段と、
を実現させ、
前記データ読出制御手段は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部に対する前記ブロックデータの記憶状態を制御する
プログラム。
（付記１２）
付記１１に記載のプログラムであって、
前記一時データ制御手段は、前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
プログラム。
（付記１３）
付記１１又は１２に記載のプログラムであって、
前記一時データ制御部は、前記読出順番情報に基づいて、前記データ読出制御部が読み出す対象としているブロックデータの順番から読み出す順番が離れている前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
プログラム。
（付記１４）
ブロックデータを読み出す順番についての情報である読出順番情報を取得し、
取得した前記読出順番情報に基づいて記憶装置から取得した前記ブロックデータを一時記憶装置に記憶させ、
前記読出順番情報に基づいて前記一時記憶装置に対する前記ブロックデータの記憶状態を制御する
情報処理方法。
（付記１５）
付記１４に記載の情報処理方法であって、
前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
情報処理方法。
（付記１６）
付記１４又は１５に記載の情報処理方法であって、
前記読出順番情報に基づいて、読み出す対象としているブロックデータの順番から読み出す順番が離れている前記ブロックデータを削除することで前記一時データ記憶部に対する前記ブロックデータの記憶状態の制御を行う
情報処理方法。
なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。
１、６ ストレージシステム
１１ メタデータ記憶部
１２ ディスク装置
１３ リストア管理部
１４ キャッシュメモリ
１４１ ブロックデータ順番情報
１４２ データ情報
１５ キャッシュメモリ制御部
６６ データ分割部
６７ ブロック検出部
６８ データ書き込み部
２ アクセラレータノード
３ ストレージノード
４ バックアップシステム
５ バックアップ対象装置
７０ データセット
７１ 分割データ
７２ 冗長データ
８ ストレージ装置
８１ データ記憶部
８２ 一時データ記憶部
８３ データ読出制御部
８４ 読出順番情報記憶部
８５ 一時データ制御部

Claims (9)

  1. 重複排除されたブロックデータを記憶するデータ記憶部と、
    前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、
    前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御部と、
    前記一時データ記憶部に記憶されている前記ブロックデータを削除する一時データ制御部と、
    を有するとともに、
    前記データ記憶部にブロックデータを記憶させる際に記憶され、データをリストアする際に前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部を有し、
    前記データ読出制御部は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
    前記一時データ制御部は、前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除する
    ストレージ装置。
  2. 請求項１に記載のストレージ装置であって、
    前記一時データ制御部は、前記読出順番情報に基づいて、前記データ読出制御部が読み出す対象としているブロックデータの読み出す順番から離れている度合いに応じて前記ブロックデータを削除する
    ストレージ装置。
  3. 請求項１又は２に記載のストレージ装置であって、
    前記データ読出制御部は、前記読出順番情報に基づいて、前記ブロックデータを識別するためのブロックデータ識別子と当該ブロックデータ識別子が示す前記ブロックデータが読み出される順番を示す順番情報とを対応付けたブロックデータ順番情報を前記一時データ記憶部に記憶させ、
    前記一時データ制御部は、前記ブロックデータ順番情報を用いて、前記一時データ記憶部が記憶する前記ブロックデータを削除する
    ストレージ装置。
  4. 請求項３に記載のストレージ装置であって、
    前記ブロックデータ順番情報に含まれる前記ブロックデータ識別子は、当該ブロックデータ識別子が示す前記ブロックデータの内容に基づいて算出されるハッシュ値の一部である
    ストレージ装置。
  5. 請求項３又は４に記載のストレージ装置であって、
    前記ブロックデータ順番情報に含まれる前記順番情報は、前記読出順番情報に基づいて行われる一連の読み出し処理を所定の大きさで複数のセクションに分割した際の、当該分割したセクションの順番を示す情報である
    ストレージ装置。
  6. 請求項１乃至５のいずれかに記載のストレージ装置であって、
    前記データ読出制御部は、読み出す対象の前記ブロックデータを前記一時データ記憶部が記憶していない場合に、前記データ記憶部から前記読み出す対象のブロックデータを含む物理領域で連続する複数の前記ブロックデータを読み出して前記一時データ記憶部に記憶させるよう構成され、
    前記一時データ制御部は、前記データ記憶部から取得した複数の前記ブロックデータのうち前記読出順番情報に基づいて読み出される予定がないと判断される前記ブロックデータを削除する
    ストレージ装置。
  7. 請求項１乃至６のいずれかに記載のストレージ装置であって、
    書き込み対象データを複数の前記ブロックデータに分割するデータ分割部と、
    前記データ分割部にて分割した前記各ブロックデータが前記データ記憶部に既に記憶されているか否かを調べるブロック検出部と、
    前記データ分割部にて分割した前記各ブロックデータを前記データ記憶部に記憶すると共に、当該データ記憶部に既に記憶されているブロックデータと同一内容の他のブロックデータを前記データ記憶部に記憶する場合には、当該データ記憶部に既に記憶されているブロックデータを前記他のブロックデータとして参照させるデータ書き込み部と、を備え、
    前記ブロック検出部は、前記データ分割部にて分割した前記ブロックデータのうち前記書き込み対象データ中の所定範囲を構成する連続する複数のブロックデータと、前記データ記憶部に既に連続して記憶されている所定範囲の複数のブロックデータと、の共通部分の割合を表す共通割合を検出し、
    前記データ書き込み部は、前記ブロック検出部にて検出した前記共通割合に応じて、前記データ分割部にて分割した前記ブロックデータを新たに前記データ記憶部に記憶する、
    ストレージ装置。
  8. 重複排除されたブロックデータを記憶するデータ記憶部と、前記データ記憶部から取得されたブロックデータを一時的に記憶する一時データ記憶部と、前記データ記憶部にブロックデータを記憶させる際に記憶され、データをリストアする際に前記ブロックデータを読み出す順番についての情報である読出順番情報を記憶する読出順番情報記憶部と、を有する情報処理装置に、
    前記データ記憶部が記憶する前記ブロックデータを読み出して前記一時データ記憶部に記憶させ、当該一時データ記憶部から前記ブロックデータを読み出すデータ読出制御手段と、
    前記一時データ記憶部に記憶されている前記ブロックデータを削除する一時データ制御手段と、
    を実現させ、
    前記データ読出制御手段は、前記読出順番情報記憶部から取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを前記一時データ記憶部に記憶させ、
    前記一時データ制御手段は、前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除する
    プログラム。
  9. データ記憶部にブロックデータを記憶させる際に記憶され、データをリストアする際にブロックデータを読み出す順番についての情報である読出順番情報を取得し、
    取得した前記読出順番情報に基づいて前記データ記憶部から取得した前記ブロックデータを一時データ記憶部に記憶させ、
    前記読出順番情報に基づいて前記一時データ記憶部が記憶する前記ブロックデータを削除する
    情報処理方法。


JP2016571760A 2014-06-27 2015-06-23 ストレージ装置、プログラム、情報処理方法 Active JP6304406B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462018122P 2014-06-27 2014-06-27
US62/018,122 2014-06-27
PCT/JP2015/003139 WO2015198591A1 (en) 2014-06-27 2015-06-23 Storage device, program, and information processing method

Publications (2)

Publication Number Publication Date
JP2017521762A JP2017521762A (ja) 2017-08-03
JP6304406B2 true JP6304406B2 (ja) 2018-04-04

Family

ID=54937699

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016571760A Active JP6304406B2 (ja) 2014-06-27 2015-06-23 ストレージ装置、プログラム、情報処理方法

Country Status (6)

Country Link
US (1) US10430102B2 (ja)
EP (1) EP3161609B1 (ja)
JP (1) JP6304406B2 (ja)
CN (1) CN106662981B (ja)
CA (1) CA2953657A1 (ja)
WO (1) WO2015198591A1 (ja)

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10222986B2 (en) 2015-05-15 2019-03-05 Cisco Technology, Inc. Tenant-level sharding of disks with tenant-specific storage modules to enable policies per tenant in a distributed storage system
CN106557264B (zh) 2015-09-25 2019-11-08 伊姆西公司 针对固态硬盘的存储方法及设备
JP6733214B2 (ja) * 2016-02-19 2020-07-29 日本電気株式会社 制御装置、ストレージシステム、制御方法及びプログラム
CN108780447A (zh) * 2016-03-02 2018-11-09 华为技术有限公司 差异数据备份的方法和设备
US10747726B2 (en) 2016-03-08 2020-08-18 International Business Machines Corporation Deduplication ratio estimation using an expandable basis set
US10482062B1 (en) * 2016-03-30 2019-11-19 Amazon Technologies, Inc. Independent evictions from datastore accelerator fleet nodes
US10963483B2 (en) * 2017-04-26 2021-03-30 Oracle International Corporation Sequential storage volume replication based on comparison of write session identifiers
CN109213621B (zh) * 2017-07-07 2021-08-31 华为技术有限公司 一种数据处理方法及数据处理设备
US10521400B1 (en) * 2017-07-31 2019-12-31 EMC IP Holding Company LLC Data reduction reporting in storage systems
KR101990329B1 (ko) * 2017-08-10 2019-06-18 주식회사 티맥스데이터 로그 데이터 분석을 이용한 데이터베이스 복구 속도 향상 기법 및 장치
US10678778B1 (en) * 2017-10-19 2020-06-09 EMC IP Holding Company LLC Date deduplication acceleration
US10866963B2 (en) 2017-12-28 2020-12-15 Dropbox, Inc. File system authentication
US10877691B2 (en) * 2017-12-29 2020-12-29 Intel Corporation Stream classification based on logical regions
US11144638B1 (en) * 2018-01-18 2021-10-12 Pure Storage, Inc. Method for storage system detection and alerting on potential malicious action
US11010233B1 (en) 2018-01-18 2021-05-18 Pure Storage, Inc Hardware-based system monitoring
US10970395B1 (en) 2018-01-18 2021-04-06 Pure Storage, Inc Security threat monitoring for a storage system
US10503417B2 (en) 2018-03-25 2019-12-10 International Business Machines Corporation Data element validation in consistency groups
US11405289B2 (en) * 2018-06-06 2022-08-02 Gigamon Inc. Distributed packet deduplication
CN108809996B (zh) * 2018-06-15 2021-02-12 青岛大学 不同流行度的删重存储数据的完整性审计方法
US10860555B2 (en) 2018-08-27 2020-12-08 Dell Products, L.P. Method and apparatus for two tier data deduplication using weighted graphs
CN109298836B (zh) * 2018-09-04 2022-07-08 航天信息股份有限公司 处理数据的方法、装置和存储介质
US10949312B2 (en) 2018-09-21 2021-03-16 Netapp, Inc. Logging and update of metadata in a log-structured file system for storage node recovery and restart
US11461015B2 (en) * 2018-10-15 2022-10-04 Netapp, Inc. Available storage space in a system with varying data redundancy schemes
US11379254B1 (en) * 2018-11-18 2022-07-05 Pure Storage, Inc. Dynamic configuration of a cloud-based storage system
US10776029B2 (en) * 2018-12-21 2020-09-15 Dell Products, L.P. System and method for dynamic optimal block size deduplication
CN110311687B (zh) * 2019-07-09 2022-10-04 上海天数智芯半导体有限公司 一种基于集成算法的时序数据无损压缩方法
US11262927B2 (en) 2019-07-30 2022-03-01 Sony Interactive Entertainment LLC Update optimization using feedback on probability of change for regions of data
US11307841B2 (en) 2019-07-30 2022-04-19 Sony Interactive Entertainment LLC Application patching using variable-sized units
US20210034583A1 (en) * 2019-07-30 2021-02-04 Sony Interactive Entertainment LLC Remote triggering of coalescing of data storage
US11449325B2 (en) 2019-07-30 2022-09-20 Sony Interactive Entertainment LLC Data change detection using variable-sized data chunks
US11775484B2 (en) 2019-08-27 2023-10-03 Vmware, Inc. Fast algorithm to find file system difference for deduplication
US11461229B2 (en) 2019-08-27 2022-10-04 Vmware, Inc. Efficient garbage collection of variable size chunking deduplication
US11372813B2 (en) 2019-08-27 2022-06-28 Vmware, Inc. Organize chunk store to preserve locality of hash values and reference counts for deduplication
US11669495B2 (en) * 2019-08-27 2023-06-06 Vmware, Inc. Probabilistic algorithm to check whether a file is unique for deduplication
US11449465B2 (en) * 2019-09-11 2022-09-20 International Business Machines Corporation Fixed chunk size deduplication with variable-size chunking
US11687418B2 (en) 2019-11-22 2023-06-27 Pure Storage, Inc. Automatic generation of recovery plans specific to individual storage elements
US11651075B2 (en) 2019-11-22 2023-05-16 Pure Storage, Inc. Extensible attack monitoring by a storage system
US11645162B2 (en) 2019-11-22 2023-05-09 Pure Storage, Inc. Recovery point determination for data restoration in a storage system
US11675898B2 (en) 2019-11-22 2023-06-13 Pure Storage, Inc. Recovery dataset management for security threat monitoring
US11520907B1 (en) 2019-11-22 2022-12-06 Pure Storage, Inc. Storage system snapshot retention based on encrypted data
US11657155B2 (en) 2019-11-22 2023-05-23 Pure Storage, Inc Snapshot delta metric based determination of a possible ransomware attack against data maintained by a storage system
US11625481B2 (en) 2019-11-22 2023-04-11 Pure Storage, Inc. Selective throttling of operations potentially related to a security threat to a storage system
US11755751B2 (en) 2019-11-22 2023-09-12 Pure Storage, Inc. Modify access restrictions in response to a possible attack against data stored by a storage system
US11341236B2 (en) 2019-11-22 2022-05-24 Pure Storage, Inc. Traffic-based detection of a security threat to a storage system
US11500788B2 (en) 2019-11-22 2022-11-15 Pure Storage, Inc. Logical address based authorization of operations with respect to a storage system
US11941116B2 (en) 2019-11-22 2024-03-26 Pure Storage, Inc. Ransomware-based data protection parameter modification
US11720714B2 (en) 2019-11-22 2023-08-08 Pure Storage, Inc. Inter-I/O relationship based detection of a security threat to a storage system
US11615185B2 (en) 2019-11-22 2023-03-28 Pure Storage, Inc. Multi-layer security threat detection for a storage system
US11720692B2 (en) 2019-11-22 2023-08-08 Pure Storage, Inc. Hardware token based management of recovery datasets for a storage system
JP7477140B2 (ja) 2020-02-19 2024-05-01 Ｎｅｃソリューションイノベータ株式会社 レプリケーション方法
JP7440167B2 (ja) 2020-02-19 2024-02-28 Ｎｅｃソリューションイノベータ株式会社 情報格納方法
US11429279B2 (en) 2020-09-16 2022-08-30 Samsung Electronics Co., Ltd. Automatic data separation and placement for compressed data in a storage device
CN112540733A (zh) * 2020-12-23 2021-03-23 华录光存储研究院（大连）有限公司 一种数据管理方法、装置、电子设备及存储介质
CN112558885B (zh) * 2020-12-24 2022-11-22 展讯半导体(成都)有限公司 功能手机的存储器使用方法及相关产品
US11899558B2 (en) * 2021-01-15 2024-02-13 Netflix, Inc. Systems and methods for optimizing hard drive throughput
US11809281B2 (en) * 2021-04-20 2023-11-07 EMC IP Holding Company LLC Metadata management for scaled and high density backup environments
US11797220B2 (en) 2021-08-20 2023-10-24 Cohesity, Inc. Reducing memory usage in storing metadata
US11947497B2 (en) * 2021-08-24 2024-04-02 Cohesity, Inc. Partial in-line deduplication and partial post-processing deduplication of data chunks
CN115729444A (zh) * 2021-09-01 2023-03-03 华为技术有限公司 一种数据处理方法及装置
CN113791935B (zh) * 2021-09-06 2023-10-24 广州宝云信息科技有限公司 一种数据备份方法、网络节点及***
US11836053B2 (en) 2021-09-27 2023-12-05 Hewlett Packard Enterprise Development Lp Resource allocation for synthetic backups
US11803515B2 (en) 2021-09-28 2023-10-31 International Business Machines Corporation Defragmentation in deduplication storage systems
US20230259488A1 (en) * 2022-01-25 2023-08-17 Hewlett Packard Enterprise Development Lp Data index for deduplication storage system
CN116126753B (zh) * 2022-12-28 2024-02-02 江苏都万电子科技有限公司 一种防护存储器及存储方法
CN116521969B (zh) * 2023-02-28 2023-12-29 华为云计算技术有限公司 一种数据检索方法、服务端、***及相关设备

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6571531B2 (en) * 2001-04-02 2003-06-03 Illinois Tool Works, Inc. Strap detector assembly
US6820180B2 (en) * 2002-04-04 2004-11-16 International Business Machines Corporation Apparatus and method of cascading backup logical volume mirrors
US6804768B2 (en) * 2002-04-15 2004-10-12 Hewlett-Packard Development Company, L.P. Programmable microprocessor cache index hashing function
US7853750B2 (en) 2007-01-30 2010-12-14 Netapp, Inc. Method and an apparatus to store data patterns
US7962452B2 (en) * 2007-12-28 2011-06-14 International Business Machines Corporation Data deduplication by separating data from meta data
US20090177844A1 (en) * 2008-01-08 2009-07-09 International Business Machines Corporation Method of efficiently choosing a cache entry for castout
US8131924B1 (en) 2008-03-19 2012-03-06 Netapp, Inc. De-duplication of data stored on tape media
WO2010113167A1 (en) * 2009-03-30 2010-10-07 Hewlett-Packard Development Company L.P. Deduplication of data stored in a copy volume
JP5712535B2 (ja) 2010-09-17 2015-05-07 富士通株式会社 ストレージ装置、制御部およびストレージ装置制御方法
US8775774B2 (en) * 2011-08-26 2014-07-08 Vmware, Inc. Management system and methods for object storage system
JP5500309B2 (ja) * 2011-09-07 2014-05-21 日本電気株式会社 ストレージ装置
JP5418719B2 (ja) 2011-09-16 2014-02-19 日本電気株式会社 ストレージ装置
US9208820B2 (en) 2012-06-29 2015-12-08 International Business Machines Corporation Optimized data placement for individual file accesses on deduplication-enabled sequential storage systems
WO2014136183A1 (ja) 2013-03-04 2014-09-12 株式会社日立製作所 ストレージ装置及びデータ管理方法
CN103473150B (zh) * 2013-08-28 2016-08-31 华中科技大学 一种用于数据去重***中的碎片重写方法
CN103559106B (zh) * 2013-10-14 2016-03-02 华为技术有限公司 一种数据的备份方法、装置及***
CN103810297B (zh) * 2014-03-07 2017-02-01 华为技术有限公司 基于重删技术的写方法、读方法、写装置和读装置

Also Published As

Publication number Publication date
CN106662981B (zh) 2021-01-26
JP2017521762A (ja) 2017-08-03
CN106662981A (zh) 2017-05-10
US10430102B2 (en) 2019-10-01
CA2953657A1 (en) 2015-12-30
EP3161609A4 (en) 2018-02-28
EP3161609A1 (en) 2017-05-03
EP3161609B1 (en) 2022-08-03
WO2015198591A1 (en) 2015-12-30
US20170131934A1 (en) 2017-05-11

Similar Documents

Publication Publication Date Title
JP6304406B2 (ja) ストレージ装置、プログラム、情報処理方法
US9671974B2 (en) Storage system and deduplication control method therefor
US8639669B1 (en) Method and apparatus for determining optimal chunk sizes of a deduplicated storage system
CN103635900B (zh) 基于时间的数据分割
US10176190B2 (en) Data integrity and loss resistance in high performance and high capacity storage deduplication
JP6385570B2 (ja) ストレージシステムおよび記憶制御方法
Ng et al. Revdedup: A reverse deduplication storage system optimized for reads to latest backups
US8712963B1 (en) Method and apparatus for content-aware resizing of data chunks for replication
JP6124902B2 (ja) ストレージシステムにおける可変長符号化
US9720921B1 (en) Mapping structure for maintaining metadata for snapshots in a virtualized storage environment
US7792882B2 (en) Method and system for block allocation for hybrid drives
US8135907B2 (en) Method and system for managing wear-level aware file systems
CA2810991C (en) Storage system
US9235535B1 (en) Method and apparatus for reducing overheads of primary storage by transferring modified data in an out-of-order manner
US7584229B2 (en) Method and system for priority-based allocation in a storage pool
CN103562914B (zh) 节约资源型扩展文件***
WO2015015550A1 (ja) 計算機システム及び制御方法
JP2015511037A (ja) ハイブリッドストレージ集合体の複製
US10176183B1 (en) Method and apparatus for reducing overheads of primary storage while transferring modified data
US9189408B1 (en) System and method of offline annotation of future accesses for improving performance of backup storage system
US10733105B1 (en) Method for pipelined read optimization to improve performance of reading data from data cache and storage units
US10908818B1 (en) Accessing deduplicated data from write-evict units in solid-state memory cache
US20220342902A1 (en) Storage of a small object representation in a deduplication system
US20190056878A1 (en) Storage control apparatus and computer-readable recording medium storing program therefor
US10565120B1 (en) Method for efficient write path cache load to improve storage efficiency

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171024

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171204

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171226

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180206

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180219

R150 Certificate of patent or registration of utility model

Ref document number: 6304406

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350