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

ストレージシステム Download PDF

Info

Publication number
JP6677740B2
JP6677740B2 JP2017546459A JP2017546459A JP6677740B2 JP 6677740 B2 JP6677740 B2 JP 6677740B2 JP 2017546459 A JP2017546459 A JP 2017546459A JP 2017546459 A JP2017546459 A JP 2017546459A JP 6677740 B2 JP6677740 B2 JP 6677740B2
Authority
JP
Japan
Prior art keywords
data
address
flash package
flash
real
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
JP2017546459A
Other languages
English (en)
Other versions
JPWO2017068904A1 (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.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2017068904A1 publication Critical patent/JPWO2017068904A1/ja
Application granted granted Critical
Publication of JP6677740B2 publication Critical patent/JP6677740B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • 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
    • G06F3/0613—Improving I/O performance in relation to throughput
    • 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/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • 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/0683—Plurality of storage devices
    • 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/08—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers from or to individual record carriers, e.g. punched card, memory card, integrated circuit [IC] card or smart card
    • 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/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • 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
    • G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、ストレージシステムにおける重複排除技術に関する。
フラッシュメモリを記憶媒体とする記憶デバイスは、ＨＤＤなどに比べ圧倒的に高速であるため、ビットコストの低下に伴い、近年急速に普及しつつある。また、これまでのストレージシステムは、ＨＤＤなどの記憶デバイスを複数搭載し、高信頼化、高性能化を実現してきた。このため、フラッシュメモリを記憶媒体とする記憶デバイスも、ストレージシステム内に複数搭載され、ストレージコントローラが、フラッシュメモリを記憶媒体とする記憶デバイスを制御するのが一般的である。また、フラッシュメモリを記憶媒体とする記憶デバイスには、ＨＤＤと互換性のあるフォームファクター、インターフェイスを備えるものがある。これはＳＤＤと呼ばれる。一方でＨＤＤとの互換性をもたないものも存在する。本発明は、双方を対象とし、以下、これをフラッシュパッケージと呼ぶ。
フラッシュメモリは、磁気ディスクなどに比べ、ビットコストが高価であるため、格納データ容量を削減して見かけ上の容量を大きくするニーズは高い。ストレージシステムにおいて、データ格納容量を削減する技術の一つに、重複排除技術がある。本技術では、ストレージコントローラが、ストレージシステムに同内容のデータが複数格納されているかチェックする。同内容のデータ（重複データ）が複数ある場合、そのうちの１つだけがストレージシステムに残され、残りのデータは削除される。これにより、記憶装置に格納するデータ量が削減される。
たとえば特許文献１では、複数のフラッシュメモリモジュールを搭載したストレージ装置における重複排除技術が開示されている。特許文献１に開示のストレージ装置は、フラッシュメモリモジュールと呼ばれる記憶デバイスを複数搭載する。また特許文献１に開示のストレージ装置は、データをストライプユニットと呼ばれるデータ単位に分割し、分割されたデータを、複数のフラッシュメモリモジュールに分散格納する。重複排除処理を行う際、ストレージコントローラはストライプユニット以上のサイズのデータに対して、複数のフラッシュメモリモジュールに跨る範囲で重複排除を行う。そしてフラッシュメモリモジュールは、フラッシュメモリモジュール内のデータを対象に、ストライプユニット以下のサイズのデータの重複排除を行う。特許文献１に開示の技術では、複数の記憶デバイスに跨る範囲で重複排除が行われるため、記憶デバイスのデータだけを対象にした重複排除処理を行う場合に比べてデータ量削減の効果が大きくなる。
一方、近年、ストレージシステムでは、容量仮想化機能が普及している。容量仮想化機能とは、ストレージシステムが有する記憶デバイスの物理的な容量より大きな仮想的な容量をホスト側に提供する機能で、一般にストレージシステム内のストレージコントローラがこの機能を有する。これは、ユーザが実際にストレージを使用する場合、ユーザが定義したユーザボリューム（ユーザからみた記憶装置）の容量に対し、実際にユーザボリュームに格納されるデータの量は、ユーザボリュームの容量にはなかなか達しないという特性を利用したものである。
すなわち、容量仮想化機能を用いない場合、ユーザはボリューム定義時に、ボリュームの容量に等しい物理記憶領域を確保する必要がある。容量仮想化機能を用いると、ボリューム定義時点では、ユーザはボリュームの容量に相当する物理記憶領域を必ずしも用意しておく必要ない。実際にボリュームにデータライトが発生したとき、初めてボリュームに記憶領域が割り当てられる。これによって、あらかじめ用意すべき記憶デバイスの容量を削減でき、かつユーザはボリューム容量を厳密に定義する必要なく、単純に大きく余裕をもった値を定義すればよいため、使い勝手も向上できる。
特許文献２では、複数のフラッシュパッケージを有するストレージシステムにおいて、ストレージコントローラだけでなくフラッシュパッケージにも容量仮想化機能を設ける技術が開示されている。さらに特許文献２に開示のストレージシステムでは、フラッシュパッケージがデータを圧縮することも開示されている。一般に、データの圧縮率はデータの内容によって異なるため、圧縮後のデータサイズを予測することは困難である。また、データが更新されれば、当然、圧縮率は変化する。このため、特許文献２では、圧縮率の変化によって、フラッシュパッケージがストレージコントローラに提供するボリュームのサイズ（仮想容量）を変化させる技術が公開されている。
米国特許出願公開第２００９／００８９４８３号明細書 米国特許出願公開第２０１２／０３１７３３３号明細書
ストレージシステムの格納データ量の増大に従って、重複排除処理の負荷は増大する。特許文献１に開示されている技術では、複数の記憶デバイスに跨る範囲のデータを対象にした重複排除処理はストレージコントローラが行う。そのため格納データ量が増加するにつれ、ストレージコントローラが性能上のボトルネックになり得る。一方、記憶デバイスで重複排除処理を行うと、その重複排除処理で対象とされるデータは、記憶デバイス内のデータに限られ、重複排除の効率が上がらない。
本発明において解決しようとする課題は、多数のフラッシュパッケージを含む大規模ストレージシステムにおいて、ストレージシステム全体で、性能に与える影響を少なくしつつ、重複排除技術を利用してフラッシュメモリへの格納データ容量を削減し、見掛け上より多く容量のデータを格納するようにすることである。
本発明の一実施形態に係るストレージシステムは、複数のフラッシュパッケージと、ホストとフラッシュパッケージ間でリード・ライト処理を制御するストレージコントローラを有する。当該ストレージシステムは、複数のフラッシュパッケージのうち第１フラッシュパッケージの第１アドレスに、第２フラッシュパッケージの第２アドレスに書き込まれているデータと同一データが書き込まれると、第１フラッシュパッケージに、第１アドレスに対応付けて第２アドレスを記憶させて重複排除を行う。
第１フラッシュパッケージが、第２アドレスを第１アドレスに対応付けて記憶している状態の時に、ストレージコントローラから第１アドレスに対するリード要求を受領すると、第２アドレスをストレージコントローラに返送する。第２アドレスを受領したストレージコントローラは、第２フラッシュパッケージにリード要求を発行することで、第２フラッシュパッケージからリード対象データを取得する。
本発明によれば、フラッシュパッケージを多数接続した大容量のストレージシステムにおいて、フラッシュパッケージ間のデータの重複排除を実行でき、かつ、ストレージコントローラの性能劣化を抑えつつ、データ格納量を削減し、物理容量よりも大きな量のデータを格納することが可能となる。
実施例１または２におけるストレージシステムを含む情報システムの構成を示す図である。 フラッシュパッケージの構成を示す図である。 論理ボリューム、仮想ページ、実ページ、フラッシュパッケージグループの関係を表した概念図である。 フラッシュボリュームと実ブロックの関係を表した概念図である。 実施例１におけるストレージシステムの共有メモリに格納された情報を示す図である。 論理ボリューム情報の形式を示す図である。 実ページ情報の形式を示す図である。 フラッシュパッケージ情報の形式を示す図である。 フラッシュパッケージグループ情報の形式を示す図である。 空き実ページ管理情報キューの構造を表した図である。 ハッシュ値格納情報の形式を示す図である。 実施例１におけるフラッシュパッケージのパッケージメモリ内に格納された情報を示す図である。 パッケージ情報の形式を示す図である。 チップ情報の形式を示す図である。 実ブロック情報の形式を示す図である。 空き実ブロック情報キューの構造を表す図である。 仮想ブロックグループ情報の形式を示す図である。 重複排除処理が行われた時の、仮想セグメントの状態を表した概念図である。 履歴情報の形式を示す図である。 ハッシュインデックス情報の構造を表す図である。 リーフセグメントの説明図である。 実施例１におけるストレージコントローラのメモリ内に格納されるプログラムを示す図である。 実施例１または２におけるリード処理実行部の処理フローを示す図である。 ライト要求受付部の処理フローを示す図である。 ライトアフタ処理実行部の処理フローを示す図である。 実施例１における重複排除スケジュール部の処理フローを示す図である。 第１のリスト及び第２のリストの内容の説明図である。 消去候補の内容の説明図である。 重複候補の内容の説明図である。 実施例１におけるフラッシュパッケージのパッケージメモリに格納されるプログラムを示す図である。 データリード処理実行部の処理フローを示す図である。 ハッシュ指定型リード実行部の処理フローを示す図である。 データライト処理実行部の処理フロー（１）を示す図である。 データライト処理実行部の処理フロー（２）を示す図である。 履歴情報送信部の処理フローを示す図である。 重複排除実行部の処理フローを示す図である。 重複排除判定部の処理フローを示す図である。 実施例２における重複排除スケジュール部の処理フローを示す図である。 実施例３または４に係る仮想ストレージシステムを含む情報システムの構成を示す図である。 ストレージシステム情報の形式を示す図である。 実施例３または４におけるリード処理実行部の処理フローを示す図である。 実施例３または４における外部パッケージリード実行部の処理フローを示す図である。 実施例３における重複排除スケジュール部の処理フローを示す図である。 実施例４におけるハッシュ値格納情報の形式を示す図である。 実施例４における重複排除スケジュール部の処理フローを示す図である。
以下、幾つかの実施例について、図面を用いて説明する。実施例の説明に入る前に、実施例で用いられる各種用語について説明する。
「ボリューム」とは、ストレージシステムや記憶デバイス等のターゲットデバイスが、ホスト計算機等のイニシエータに提供する記憶空間のことを意味する。イニシエータがボリューム上の領域に対するデータ書き込み要求を発行すると、その領域に割り当てられている物理記憶領域にデータが格納される。
以下で説明する実施例に係るストレージシステムでは、ストレージコントローラと記憶デバイス（フラッシュパッケージ）のそれぞれに、容量仮想化機能が実装されている。本明細書において、ストレージコントローラが容量仮想化機能を用いて定義するボリュームで、ホストに提供されるボリュームのことは「論理ボリューム」と呼ばれる。一方フラッシュパッケージがストレージコントローラに提供するボリュームで、容量仮想化機能を用いて定義されたボリュームを、「フラッシュボリューム」と呼ぶ。ストレージコントローラの持つ容量仮想化機能は、上位レベルの容量仮想化機能と呼ばれ、フラッシュパッケージが持つ容量仮想化機能は、下位レベルの容量仮想化機能と呼ばれる。
論理ボリューム（またはフラッシュボリューム）上の領域には、初期状態（ボリュームが定義された直後）では物理記憶領域が割り当てられていない。ホスト（またはストレージコントローラ）が論理ボリューム（またはフラッシュボリューム）上の領域にデータ書き込み要求を発行した時点で、ストレージコントローラ（またはフラッシュパッケージ）は、その領域に割り当てられるべき物理記憶領域を動的に決定する。
以下で説明する実施例では、論理ボリュームに物理記憶領域を割り当てる時の最小単位は「ページ」と呼ばれる。一般にページとは、フラッシュメモリにおける読み書き処理の最小単位を指すが、以下で説明する実施例では、フラッシュメモリにおけるリード・ライトの単位は、ページではなく「セグメント」と呼ぶ。また論理ボリュームに割り当てられる記憶領域のことは「実ページ」と呼ばれ、実ページが割り当てられる対象となる、論理ボリューム上の領域は「仮想ページ」と呼ばれる。
フラッシュメモリにおける、データの消去単位は「ブロック」と呼ばれる。ブロックには、複数のセグメントが含まれるため、ブロックのサイズはセグメントサイズの整数倍である。一方、以下で説明する実施例におけるページ（実ページ）は、ブロックまたはセグメントとは直接的に関係のない概念で、ページのサイズとブロック（またはセグメント）のサイズとの間には、必ずしも相関がなければならないわけではない。ただし以下の実施例では、説明の簡単化のため、実ページは少なくともセグメントの整数倍という関係にある例が説明される。
フラッシュパッケージは、容量仮想化機能を用いて「フラッシュボリューム」を定義する。フラッシュボリュームに物理記憶領域を割り当てる単位は、以下で説明される実施例ではセグメントである。つまりフラッシュメモリにおける読書き処理の最小単位と等しい。フラッシュボリュームに割り当てられる物理記憶領域は「実セグメント」と呼ばれ、実セグメントが割り当てられるフラッシュボリューム上領域は「仮想セグメント」と呼ばれる。
記憶領域の「更新」とは、記憶領域に格納されているデータの内容を新しい内容に書き換える（上書きする）ことを意味する。ある記憶領域が更新される前に、その記憶領域に格納されていたデータは、「更新前データ」または「旧データ」と呼ばれる。一方その記憶領域に新たに書き込まれるデータのことは、「更新データ」または「更新後データ」と呼ばれる。
本実施例では、「重複排除」とは、ストレージシステム等の記憶装置内に内容が同一のデータが複数存在する場合、１つだけを記憶装置に残し、それ以外のデータを記憶装置から削除する処理である。以下で説明する実施例に係るストレージシステムでは、重複排除の単位はセグメントである。重複排除の単位とは、２つ（以上の）データの異同を比較する時の、各データの最小サイズである。つまり以下で説明する実施例ではセグメントごとにデータの比較が行われる。そして同一データの書き込まれた実セグメントが複数ある場合、１つの実セグメントだけが残される。
以下で説明するいくつかの実施例に係るストレージシステムでは、フラッシュパッケージが重複排除処理を実施することがある。またこのフラッシュパッケージのように容量仮想化機能が用いられる場合、（１または複数の）フラッシュボリューム上の複数の仮想セグメントに対して同内容のデータが書き込まれた場合、同内容のデータが書き込まれた各仮想セグメントには、共通の実セグメントが割り当てられる。
本実施例において、データの「特徴量」とは、データに対して所定の演算を施すことで得られる値を意味する。所定の演算の種類は必ずしも特定の物に限定される必要はない。ただし同内容の複数のデータに所定の演算を施した場合、必ず同じ値が導出されることが保証されている必要がある。この条件に該当する演算の例として、たとえばＳＨＡ−２５６等のハッシュ関数がある。ハッシュ関数を用いて算出される値のことをハッシュ値と呼ぶ。ハッシュ値は特徴量の一例である。ハッシュ値のサイズは、元のデータのサイズに比べて非常に小さい（たとえば数百分の一のサイズ）になるため、例えば複数のデータの異同を判定する場合（たとえば重複排除処理）際に用いられる。
以下で説明する実施例では、特に断りのない限り、特徴量の計算にＳＨＡ−２５６等のハッシュ関数が用いられる。本実施例では、データＡにハッシュ関数を適用することでハッシュ値Ｈが求められる場合、値ＨはデータＡの特徴量、またはデータＡのハッシュ値と呼ばれる。逆にデータＡのことを、「ハッシュ値Ｈを持つデータ」と呼ぶことがある。
本実施例において「衝突」とは、複数の異なるデータそれぞれに対して所定の演算を施して特徴量を生成した時、生成されたそれぞれの特徴量が同一になることを意味する。データ同士の比較に特徴量を用いる場合、衝突が発生することは好ましくない。上で挙げたハッシュ関数ＳＨＡ−２５６により生成されるハッシュ値は、衝突が発生する確率が極めて低いという特徴がある。
図１は、本実施例における情報システムの構成を示す。情報システムは、ストレージシステム１００、ホスト１１０と両者を接続するSAN（Storage Area Network）１２０を有する。ホスト１１０は、ユーザアプリケーションが動作するコンピュータで、ストレージシステム１００との間で、SAN１２０経由で、必要なデータを読み書きする。SAN１２０は例えば、Fibre Channel等の規格に従うネットワークである。また、本発明は、ホスト１１０とストレージシステム１００を直接、接続しても有効である。
ストレージシステム１００は、一つ以上のストレージコントローラ２００、キャッシュメモリ２１０、共有メモリ２２０、フラッシュパッケージ２３０、そしてこれらの構成要素を接続する一つ以上の接続装置２５０、とを有する。また、図１では、ストレージシステム１００内の記憶デバイスは、すべてフラッシュパッケージ２３０であるが、ストレージシステム１００はHDDのような他の種類の記憶デバイスを含んでいてもよい。また、本実施例において、フラッシュパッケージ２３０の容量はすべて等しいものとする。ただし別の実施形態として、ストレージシステム１００に搭載される各フラッシュパッケージ２３０の容量が異なっていてもよい。
ストレージコントローラ２００は、ホスト１１０から発行されたリードライト要求を処理するプロセッサ２６０とメモリ２７０を有する。本実施例に係るストレージシステム１００の特徴の１つは、重複排除処理をフラッシュパッケージ２３０が実行することである。一般に、重複排除処理においては、ストレージシステム１００等の記憶装置に新たにデータ（データＡと呼ぶ）が書き込まれた場合、ハッシュ値のような特徴量を計算する。もしデータＡの特徴量と同じ特徴量を持つデータが存在した場合（仮にそのデータを、データＢと呼ぶ）、データＡとデータＢをビット単位で比較する。比較の結果データＡとＢが同じであれば、データＡは記憶装置に格納しないようにして、格納容量を削減する。特徴量を用いるのは、データの内容を比較する候補を絞り込むためである。本実施例に係るストレージシステム１００では、特徴量の計算はフラッシュパッケージ２３０が行う。ただし別の実施形態として、特徴量の計算がストレージコントローラ２００で行われてもよい。
接続装置２５０は、ストレージシステム１００内の各構成要素を接続する機構である。また、本実施例では、高信頼化のために、各フラッシュパッケージ２３０は、複数の接続装置２５０で複数のストレージコントローラ２００に接続されているものとする。ただし、一つのフラッシュパッケージ２３０が一つの接続装置２５０にしか接続されていない場合も本発明は有効である。
キャッシュメモリ２１０、共有メモリ２２０は、通常DRAMなどの揮発メモリで構成されるが、バッテリーなどにより不揮発化されているものとする。ただ、本発明は、キャッシュメモリ２１０、共有メモリ２２０が不揮発化されていなくても有効である。
キャッシュメモリ２１０には、フラッシュパッケージ２３０に格納されたデータの中で、ストレージコントローラ２００からよくアクセスされるデータが格納される。またストレージコントローラ２００はキャッシュメモリ２１０をいわゆるライトバックキャッシュとして用いる。つまりストレージコントローラ２００は、ホスト１１０からライト要求と共に受け取ったデータを、キャッシュメモリ２１０に書き込み、その時点でホスト１１０にライト要求が完了した旨を応答する。キャッシュメモリ２１０からフラッシュパッケージ２３０へのデータ書き込みは、ホスト１１０からのライト要求とは非同期に実施されてよい。ただし別の実施形態として、いわゆるライトスルー方式（ライトデータがフラッシュパッケージ２３０に格納された時点で、ホスト１１０にライト要求が完了した旨を応答する方式）が用いられてもよい。
共有メモリ２２０は、キャッシュメモリ２１０の制御情報、ストレージシステム１００内の重要な管理情報、ストレージコントローラ２００間の連絡情報、同期情報などが格納される。
なお、本実施例に係る各フラッシュパッケージ２３０はボリューム（記憶空間）を形成し、このボリュームの領域をストレージコントローラ２００に提供する。つまりストレージコントローラ２００はフラッシュパッケージ２３０を、一台の記憶デバイスとして認識する。また本実施例では、フラッシュパッケージ２３０が形成するボリュームを、「フラッシュボリューム」と呼ぶ。
またストレージコントローラ２００は、高信頼化のために、フラッシュパッケージ２３０のデータを回復できるRedundant Arrays of Inexpensive/Independent Disks/Devices (RAID)機能をもっているものとする。ＲＡＩＤ機能では、複数（たとえば４つ）のフラッシュパッケージ２３０から成るグループ（いわゆるＲＡＩＤグループ）が定義され、ＲＡＩＤグループ内の一台のフラッシュパッケージ２３０が故障した場合には、ストレージコントローラ２００はＲＡＩＤグループ内の残りのフラッシュパッケージ２３０に格納されている情報をもとに、故障したフラッシュパッケージ２３０に格納されていたデータ内容を復旧することができる。本実施例では、この複数のフラッシュパッケージ２３０から成るＲＡＩＤグループのことを、フラッシュパッケージグループ２８０と呼ぶ。フラッシュパッケージグループ２８０は複数定義されてよい。なお、RAID機能をストレージコントローラ２００がもっていなくとも本発明は有効である。また、本発明は、ストレージシステム１００内に、フラッシュパッケージ２３０以外の記憶デバイス、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）のような記憶デバイスが含まれていても有効である。
図２は、フラッシュパッケージ２３０の構成を示している。フラッシュパッケージ２３０は、不揮発性半導体メモリを記憶媒体として用いたフラッシュチップ３００を複数有し、またパッケージプロセッサ３１０、パッケージメモリ３２０、バッファ３３０、パッケージバス３４０、パッケージバス転送装置３５０、ハッシュ回路３７０を有する。なお、本実施例では、フラッシュパッケージ２３０は、圧縮・伸張機能を持っていない例を説明する。ただし、フラッシュパッケージ２３０が圧縮・伸張機能を持っていてもよい。
ハッシュ回路３７０は、ストレージコントローラ２００からフラッシュパッケージ２３０に書き込まれたデータのハッシュ値（特徴量）を計算する。本実施例ではハッシュ値の算出の際、衝突確率が極めて小さいＳＨＡ−２５６などのハッシュアルゴリズムが用いられる。そのため、２つのデータから生成されるハッシュ値が等しければ、２つのデータの内容は等しいと判断できる。ただし別の実施形態として、ＳＨＡ−２５６以外のハッシュアルゴリズムが用いられてもよい。
パッケージプロセッサ３１０は、ストレージコントローラ２００からのリード・ライト要求を受け付け、対応する処理を実行する。バッファ３３０は、ストレージコントローラ２００とフラッシュチップ３００との間でリード・ライトされるデータを格納する。本実施例では、バッファ３３０は揮発メモリであるものとする。またパッケージプロセッサ３１０はストレージコントローラ２００からライト要求と書き込みデータを受け取ると、受け取った書き込みデータをフラッシュチップ３００に書き込んだ後、ストレージコントローラ２００にライト処理が完了した旨を通知する。ただし、本発明は、バッファ３３０が不揮発メモリで、ストレージコントローラ２００から受け取ったライト要求を、受け取った書き込みデータをバッファ３３０に書き込んだ段階で、完了させても有効である。
パッケージメモリ３２０には、パッケージプロセッサ３１０が実行するプログラム、フラッシュチップ３００の管理情報などが格納される。フラッシュパッケージ２３０の管理情報は重要な情報であるので、計画停止時には、管理情報を特定のフラッシュチップ３００に退避できることが望ましい。また、突発的な障害に備え、バッテリーをもち、これを利用して、障害などが発生しても、管理情報を特定のフラッシュチップ３００に退避できることが望ましい。
重複排除に関するすべての情報をパッケージメモリ３２０に格納すると、パッケージメモリ３２０の容量が大きくなりコスト高になり得る。そのため、本実施例に係るフラッシュパッケージ２３０では、全情報はフラッシュチップ３００に格納され、一部の情報がパッケージメモリ３２０に格納されるものとする。ただし別の実施形態として、すべての情報がパッケージメモリ３２０に格納されるようにしてもよい。
パッケージバス３４０は、バッファ３３０とフラッシュチップ３００との間でデータ転送を行うバスで、一本以上存在する。性能向上のために、フラッシュパッケージ２３０は複数のパッケージバス３４０を持つのが一般的だが、一本でも本発明は有効である。
パッケージバス転送装置３５０は、パッケージバス３４０ごとに存在し、パッケージプロセッサ３１０の指示にしたがって、バッファ３３０とフラッシュチップ３００との間で、データ転送を実行する。
ハッシュ回路３７０は、バッファ３３０に接続されていて、パッケージプロセッサ３１０の指示に従い、ストレージコントローラ２００から書き込まれたデータのハッシュ値を計算する。
フラッシュチップ３００はたとえば、ＮＡＮＤ型フラッシュメモリ等の不揮発性半導体メモリチップである。フラッシュメモリは周知のとおり、データの読み出し・書き込みの単位はセグメント（一般的にはページと呼ばれるが、本明細書ではセグメントと呼ぶ）である。またデータ消去は、セグメントの集合であるブロック（本実施例では、実ブロックと呼ばれる）ごとに行われる。フラッシュチップ３００内には、実ブロックの集合体であるダイが複数個存在しており、さらに実ブロックには複数のセグメントが存在している。なお本実施例では、実ブロックに存在するセグメントのことを、「実セグメント」と呼ぶ。そしてフラッシュボリューム上の領域で、実セグメントの割り当てられる領域のことを「仮想セグメント」と呼ぶ。
フラッシュパッケージ２３０は、各フラッシュチップ３００に識別番号を付して管理する。フラッシュチップ３００の識別子をチップＩＤと呼ぶ。また、各ダイ、各実ブロックにも識別番号が付される。ダイの識別番号をダイ番号、実ブロックの識別子をブロック番号と呼ぶ。ダイ番号はダイが属するフラッシュチップ３００内で一意な識別番号で、ブロック番号は実ブロックが属するダイの中で一意な識別番号である。また実ブロック内の実セグメントに付される識別番号は、相対セグメント番号と呼ばれる。実ブロック内の先頭実セグメントの相対セグメント番号は０で、後続の実ブロックには順に、１、２、…の番号が付される。
続いて、本実施例におけるストレージシステム１００が管理する情報について説明するが、その前に論理ボリューム、フラッシュボリュームの構成について説明する。本実施例においては、ストレージコントローラ２００は上位レベルの容量仮想化機能をサポートしているものとする。ただし、本発明は、ストレージコントローラ２００が、上位レベルの容量仮想化機能をもっていなくとも有効である。
通常、上位レベルの容量仮想化機能において、記憶領域の割り当て単位は、ページと呼ばれる。なお、本実施例では、論理ボリュームの空間は、仮想ページという単位で分割されているものとし、フラッシュパッケージグループ２８０の記憶領域は、実ページという単位で分割されているものとする。
図３を用いて、論理ボリューム、仮想ページ、実ページ、フラッシュパッケージグループ２８０の関係について説明する。ストレージコントローラ２００は、１以上の論理ボリュームを定義して、ホスト１１０等の上位装置に提供することができる。そして先に述べたとおり、ストレージコントローラ２００は、各論理ボリュームの記憶空間を、複数の仮想ページ（図３：ＶＰ０、ＶＰ１、ＶＰ２）という所定単位の領域に分割して管理している。なお、仮想ページのサイズは、共有メモリ２２０内の仮想ページ容量２６００（後述）に格納されている。また、本実施例に係るストレージシステム１００においては、すべての仮想ページの容量は同じとするが、ストレージシステム１００内に異なるサイズの仮想ページが存在する構成でもよい。
仮想ページは、ストレージコントローラ２００内部で論理ボリュームの記憶空間の管理のためにのみ用いられる概念である。ホスト１１０は論理ボリュームの記憶領域にアクセスする際には、ＬＢＡ（Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ）などのアドレスを用いて、アクセス対象の記憶領域を特定する。ホスト１１０が論理ボリュームへのアクセス要求を発行した時、ストレージコントローラ２００は、ホスト１１０が指定したＬＢＡを仮想ページ番号（各仮想ページに付されている識別番号）及び仮想ページ内の相対アドレス（仮想ページ先頭からのオフセットアドレス）に変換する。この変換は、ＬＢＡを仮想ページサイズで除算することで実現できる。仮に仮想ページのサイズがＰ（ＭＢ）とすると、論理ボリュームの先頭位置からＰ（ＭＢ）分の領域が仮想ページ＃０（＃０は仮想ページ番号を表す）として管理され、その次のＰ（ＭＢ）分の領域が仮想ページ＃１として管理される。そしてそれ以降も同様に、Ｐ（ＭＢ）の領域がそれぞれ、仮想ページ＃２、＃３…として管理される。
ストレージコントローラ２００が論理ボリュームを定義した直後は、各仮想ページに物理記憶領域は割り当てられていない。ストレージコントローラ２００は、ホスト１１０から仮想ページに対するライト要求を受け付けた時点ではじめて、当該仮想ページに対して物理記憶領域を割り当てる。仮想ページに割り当てられる物理記憶領域のことを実ページと呼ぶ。図３では、仮想ページ＃０（ＶＰ０）に実ページＲＰ０が割り当てられている状態を表している。
実ページとは、フラッシュパッケージグループ２８０の複数のフラッシュボリュームの記憶領域を用いて形成される領域である。図３において、２３０−１，２３０−２，２３０−３，２３０−４はそれぞれ、各フラッシュパッケージ２３０のフラッシュボリュームを表している。また、図３で例示しているフラッシュパッケージグループ２８０のＲＡＩＤタイプは、ＲＡＩＤ４の３Ｄ＋１Ｐ構成（データドライブ３台、パリティドライブ１台で構成されるＲＡＩＤグループ）である。
ストレージコントローラ２００は、フラッシュパッケージグループ２８０に属する各フラッシュパッケージ２３０のフラッシュボリューム（２３０−１，２３０−２，２３０−３，２３０−４）を、ストライプブロックと呼ばれる複数の固定サイズの記憶領域に分割して管理する。たとえば図３において、０（Ｄ），１（Ｄ）、２（Ｄ）…、またはＰ０，Ｐ１…と記載されているそれぞれの領域が、ストライプブロックを表している。また本実施例では、ストライプブロックのサイズは、フラッシュボリュームの仮想セグメントのサイズと等しい例を説明するが、別の実施形態として、ストライプブロックと仮想セグメントのサイズは異なっている構成が採用されてもよい。
図３で、ストライプブロックのうち、Ｐ０，Ｐ１…と記載されているストライプブロックは、ＲＡＩＤ機能により生成される冗長データ（パリティ）の格納されるストライプブロックであり、これを「パリティストライプ」と呼ぶ。一方、０（Ｄ），１（Ｄ）、２（Ｄ）…と記載されているストライプブロックは、ホスト１１０から書き込まれるデータ（冗長データではないデータ）が格納されるストライプブロックである。このストライプブロックのことは、「データストライプ」と呼ばれる。パリティストライプには、複数のデータストライプを用いて生成される冗長データが格納される。
以下、パリティストライプと、当該パリティストライプに格納される冗長データを生成するために用いられるデータストライプのセットのことを、「ストライプライン」と呼ぶ。本実施例に係るストレージシステム１００の場合、たとえばパリティストライプＰ０には、データストライプ０（Ｄ），１（Ｄ），２（Ｄ）を用いて生成される冗長データ（パリティ）が格納される関係にあり、データストライプ０（Ｄ），１（Ｄ），２（Ｄ）とパリティストライプＰ０は、同一のストライプラインに属する。
つまり１つのストライプラインに属する各ストライプブロックは、フラッシュボリューム（２３０−１，２３０−２，２３０−３，２３０−４）上の同じ位置（アドレス）に存在する。ただし別の実施形態として、同一ストライプラインに属する各ストライプブロックが、フラッシュボリューム上の異なるアドレスに存在する構成が採用されてもよい。そして本実施例に係るストレージシステム１００では、図３に示されるように、実ページ（たとえばＲＰ０、ＲＰ１）は、１または複数のストライプラインから構成される。
また実ページが仮想ページに割り当てられる場合、データストライプ（０（Ｄ），１（Ｄ）等）のみが割り当てられ、パリティストライプは割り当てられない。そのため、実ページ上のライトデータの格納される領域の合計サイズは、仮想ページのサイズと等しい関係にある。つまり、（実ページのサイズーパリティ格納領域のサイズ）＝仮想ページサイズ、の関係にある。図３ではＲＡＩＤ４の構成例についてのみ示されているが、たとえばフラッシュパッケージグループ２８０のＲＡＩＤタイプがＲＡＩＤ１の場合には、実ページサイズは、仮想ページサイズ（仮想ページ容量２６００）の２倍になる。
仮想ページ内の各領域と、実ページ内の各領域との関係（マッピング）は、図３に示されている通りである。つまり、実ページの先頭ストライプからパリティを除いた領域（０（Ｄ）、１（Ｄ）、２（Ｄ））が、仮想ページの先頭領域に割り当てられている。それ以降も同様に、実ページの２番目以降の各ストライプからパリティを除いた領域（３（Ｄ）、４（Ｄ）、５（Ｄ）…）が、順番に仮想ページの領域に割り当てられる。
このように、仮想ページ内の各領域と実ページ内の各領域とのマッピングは規則的にマッピングされているため、ストレージシステム１００は、ホスト１１０からのアクセス要求で指定されている論理ボリューム上のアクセス位置（ＬＢＡ）から仮想ページ番号及び仮想ページ内の相対アドレス（仮想ページ先頭からのオフセットアドレス）を求めることで、当該アクセス位置に対応付けられているフラッシュパッケージ２３０及びそのフラッシュパッケージ２３０内の領域（データストライプ）を一意に算出できる。さらにアクセス位置に対応付けられているデータストライプに加え、そのデータストライプと同一ストライプラインに属するパリティストライプも一意に定まる。ただし、仮想ページ内の各領域と実ページ内の各領域とのマッピングは、ここで説明したマッピング方法に限定されるものではない。
また容量仮想化技術においては、各論理ボリュームを定義する時、実記憶媒体の容量よりも各論理ボリュームの合計記憶容量が大きくなるように定義することもできる。このため一般的に、仮想ページ数のほうが、実ページ数より多い。本発明の実施例に係るストレージ装置でも、仮想ページ数を実ページ数より多くすることができる。
なお、論理ボリューム中の各仮想ページに割り当てられる実ページは、必ずしも同一フラッシュパッケージグループ２８０内の実ページに限定されない。仮想ページ＃０に割り当てられる実ページと、仮想ページ＃１に割り当てられる実ページが、それぞれ異なるフラッシュパッケージグループ２８０内の実ページであってもよい。ただし本実施例では、１つの論理ボリュームの各仮想ページに割り当てられるべき実ページは全て、ＲＡＩＤタイプが同じフラッシュパッケージグループ２８０から割り当てられる例を説明する。
続いてフラッシュボリュームについて説明する。本実施例においては、それぞれのフラッシュパッケージ２３０は、容量仮想化機能（下位レベルの容量仮想化機能）をもっており、かつ重複排除処理を行う。そのためフラッシュパッケージ２３０はストレージコントローラ２００に、見かけ上、実際の物理容量（フラッシュチップ３００の合計容量）より大きな容量を持つフラッシュボリュームを提供できる。図４は、フラッシュボリュームＶ１と実ブロックの関係を示したものである。
フラッシュパッケージ２３０は、フラッシュボリュームＶ１を、実ブロックｍ個分のサイズに等しい領域に分割して管理している。本実施例では、この領域を「仮想ブロックグループ」と呼ぶ。また便宜上、仮想ブロックグループ内の、実ブロックのサイズと等しいサイズの領域のことを、「仮想ブロック」と呼ぶ。つまり仮想ブロックグループは、ｍ個の仮想ブロックから構成される記憶領域といえる。
各仮想ブロックグループには識別番号が付され、これを仮想ブロックグループ番号と呼ぶ。また、仮想ブロックグループ番号がｎ（ｎは０以上の整数値とする）の仮想ブロックグループのことを「仮想ブロックグループ＃ｎ」と表記する。またこの表記方法は、仮想ブロックグループ以外の物（セグメント、ページ等）にも用いられる。実ブロック（または仮想ブロック）のサイズがＢ（ＫＢ）の時、フラッシュボリュームＶ１の先頭からｍ×Ｂ（ＫＢ）の領域が仮想ブロックグループ＃０として管理され、以下順に、各ｍ×Ｂ（ＫＢ）の領域が、仮想ブロックグループ＃１、＃２…として管理される。
本実施例では、フラッシュパッケージ２３０が、まだ実ブロックを割り当てていない仮想ブロックグループに対する書き込み要求を受け付けたとき、はじめて実ブロックを割り当てる。また本実施例に係るフラッシュパッケージ２３０は、１つの仮想ブロックグループに対して最大で（ｍ＋１）個の実ブロックを割り当てる。以下、本実施例で、実ブロックの最大割り当て数をｍ＋１個にした理由を以下に示す。
仮に、仮想ブロックグループにｍ個の実ブロックを割り当てる方法が用いられるケースを想定する。また仮想ブロックグループの全領域にデータが書き込まれ、その時データがほとんど重複排除できなかった場合を想定する。この場合、仮想ブロックグループに実ブロックがｍ個割り当てられるが、実ブロックに空き容量はほとんどないことになる。
このとき、ブロック内の一部のデータを書き換える要求（普通のライト要求）を、ストレージコントローラ２００からフラッシュパッケージ２３０が受け取った場合を想定する。フラッシュメモリのブロックは書き換えができないので、フラッシュパッケージ２３０は、そのブロックの全データをバッファ３３０に読み出し、バッファ３３０上で書き換え要求の発生した部分だけ更新して、当該ブロックを一度消去した後、ブロック全体にデータを格納しなければならない。フラッシュパッケージ２３０がライト要求を受け取るたびに、以上の動作（ブロックのリード、消去、そしてライト）を実行すると、処理時間が過大になりすぎ、実用的とは言いがたい。
これを解決するため、本実施例に係るフラッシュパッケージ２３０では仮想ブロックグループに実ブロックを１つ余計に割り当てて、空き領域を確保することにより、空き領域に追加書き込みを行うようにする。空き領域が小さくなって、書き換えデータに入らなくなった場合、消去処理を行う。これにより、複数回（たとえばｎ回）のライト要求に対して１回消去処理を実行すればよいので、性能を向上させることができる。また、消去処理の回数の削減は、フラッシュメモリの長寿命化にもつながる。
先にも述べたが、フラッシュメモリのアクセス（読み書き）単位は、「セグメント」である。そのためフラッシュパッケージ２３０はフラッシュボリュームＶ１の空間を、セグメントのサイズと等しい領域ごとに分割して管理する。この領域は「仮想セグメント」と呼ばれる。図４において、仮想セグメント＃０、仮想セグメント＃１、…が仮想セグメントを表す。仮想セグメントは、重複排除処理の単位でもある。
フラッシュパッケージ２３０がストレージコントローラ２００からフラッシュボリュームＶ１に対するアクセス要求を受け付けると、まずアクセス要求で指定されているアドレスを、仮想セグメントを特定するための識別子に変換する。フラッシュパッケージ２３０で用いられる、仮想セグメントを特定するための識別子には、複数の種類（内部仮想セグメント番号、相対仮想セグメント番号、仮想セグメントアドレス）がある。
内部仮想セグメント番号は、フラッシュパッケージ２３０内で仮想セグメントを一意に特定可能な識別子である。フラッシュボリュームＶ１の先頭に位置する仮想セグメントの内部仮想セグメント番号は０と定められている。そして後続の仮想セグメントの内部仮想セグメント番号には順に、１，２，…の連続番号が用いられる。図４において、各仮想セグメントに付されている番号（＃１、＃ｓ等）は、内部仮想セグメント番号を表している。
相対仮想セグメント番号は、仮想ブロックグループ内で仮想セグメントを一意に特定可能な識別子である。各仮想ブロックグループ内の先頭の仮想セグメントの相対仮想セグメント番号は０と定められている。そして後続の各仮想セグメントの相対仮想セグメント番号には順に、１，２，…の連続番号が用いられる。
仮想セグメントアドレスは、内部仮想セグメント番号にフラッシュパッケージの識別子（パッケージＩＤと呼ばれる）を連結して生成されるアドレスである。仮想セグメントアドレスが与えられると、ストレージシステム１００内で１つの仮想セグメントを一意に特定可能である。
続いて、本実施例におけるストレージシステム１００が管理する情報の説明を行う。図５は、ストレージシステム１００の共有メモリ２２０の中に格納される情報のうち、本実施例に関係する情報を示している。共有メモリ２２０には少なくとも、論理ボリューム情報２０００、実ページ情報２１００、空き実ページ管理情報ポインタ２２００、フラッシュパッケージグループ情報２３００、フラッシュパッケージ情報２５００、仮想ページ容量２６００に、ハッシュ値格納情報２４００が格納される。ハッシュ値格納情報２４００以外のこれらの情報は、上位レベルの容量仮想化技術を実現するために必要な情報である。
以下、それぞれの情報について説明する。図６は、論理ボリューム情報２０００の形式を示したものである。論理ボリューム情報２０００は、論理ボリュームごとに存在する情報で、論理ボリュームの属性情報を管理するための情報である。以下、ある論理ボリューム情報２０００によって属性情報が管理される論理ボリュームのことを、「管理対象論理ボリューム」と呼ぶ。論理ボリューム情報２０００は、論理ボリュームID２００１、論理容量２００２、論理ボリュームRAIDタイプ２００３、実ページポインタ２００４を含む。
論理ボリュームID２００１は、管理対象論理ボリュームのIDを示す。一般的に、ホスト１１０は、論理ボリュームの識別子（たとえばＬｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ（ＬＵＮ）等の識別子である）、論理ボリューム内のアドレス（ＬＢＡ）、読み書きしたいデータの長さを指定して、アクセス要求（リード要求やライト要求）を発行する。論理ボリュームＩＤ２００１には、ホスト１１０が論理ボリュームに対してアクセス要求を発行する時に指定する、論理ボリュームの識別子が格納される。
論理容量２００２は、管理対象論理ボリュームの容量である。論理ボリュームRAIDタイプ２００３は、管理対象論理ボリュームのRAIDタイプを表す。論理ボリュームRAIDタイプ２００３に格納される情報には、RAID0、RAID1などのＲＡＩＤタイプの他、RAID5のように、N台の容量に対し、１台の容量の冗長データを格納する場合、Nの具体的数値が含まれる。ただし、任意のRAIDタイプが指定できるわけでなく、少なくとも一つのフラッシュパッケージグループ２８０がもつRAIDタイプである必要がある。管理対象論理ボリュームの仮想ページに実ページを割り当てる際、ストレージコントローラ２００は、フラッシュパッケージグループ２８０のＲＡＩＤタイプが論理ボリュームＲＡＩＤタイプ２００３と同じフラッシュパッケージグループ２８０から実ページを選択する。
実ページポインタ２００４は、管理対象論理ボリュームの仮想ページに割り当てられた実ページのページ管理情報（後述する実ページ情報２１００）へのポインタである。実ページポインタ２００４の数は、管理対象論理ボリュームの仮想ページの数（論理容量２００２を仮想ページ容量２６００で割った数になるが、余りがでれば+１）である。管理対象論理ボリュームの仮想ページ数がｎであれば、実ページポインタ２００４はｎ個存在する（２００４−０〜２００４−（ｎ−１）の実ページポインタが存在する）。
論理ボリューム情報２０００内の複数の実ページポインタ２００４（２００４−０〜２００４−（ｎ−１））のうち、先頭からｋ番目の実ページポインタ２００４−（ｋ−１）には、仮想ページ＃（ｋ−１）に割り当てられた実ページのページ管理情報（後述する実ページ情報２１００）へのポインタが格納される。また、実ページが割り当てられる契機は、論理ボリュームが定義された時ではなく、仮想ページに対して実際にデータ書き込みの要求を受信した契機である。したがって、まだ書き込みが行われていない仮想ページに対応する実ページポインタ２００４は無効値（ＮＵＬＬ）になっている。
図７は、実ページ情報２１００の形式である。実ページ情報２１００は、実ページについての情報を管理するためのもので、実ページごとに１つの実ページ情報２１００が存在する。実ページ情報２１００は、パッケージグループ２１０１、実ページアドレス２１０２、空きページポインタ２１０３、ページデータ格納量２１０４を含む。なお、以下の実ページ情報２１００の説明の過程で、ある実ページ情報２１００によって管理される実ページのことを、「管理対象実ページ」と呼ぶ。
パッケージグループ２１０１には、管理対象実ページが属するフラッシュパッケージグループ２８０の識別子が格納される。以下、フラッシュパッケージグループ２８０の識別子のことを、「パッケージグループＩＤ」と呼ぶ。
実ページアドレス２１０２には、管理対象実ページが存在する位置（アドレス）の情報が格納される。実ページアドレス２１０２に格納されるアドレスは、管理対象実ページが属するフラッシュパッケージグループ２８０内の相対アドレスである。空きページポインタ２１０３は、管理対象実ページが仮想ページに割り当てられていない場合に用いられる情報である。本実施例において、仮想ページに割り当てられていない実ページのことを、「空き実ページ」または「空きページ」と呼ぶ。管理対象実ページが仮想ページに割り当てられていない場合、その空きページポインタ２１０３には、別の空きページの実ページ情報２１００が格納される。管理対象実ページが仮想ページに割り当てられている場合、空きページポインタ２１０３はヌル（ＮＵＬＬ）値となる。
ページデータ格納量２１０４は、管理対象実ページに格納したデータ量である。ただし、この情報は、管理対象実ページに割り当てられているフラッシュパッケージ２３０（の記憶領域）に関する属性情報ではなく、管理対象実ページが割り当てられている仮想ページのデータに関する属性情報である。したがって、この仮想ページに別の実ページが割り当てられ、現在の実ページのデータが新しい実ページにコピーされた場合、ページデータ格納量２１０４を、新しい実ページの管理情報として引き継ぐ必要がある。
図８は、フラッシュパッケージ情報２５００のフォーマットを表している。フラッシュパッケージ情報２５００はフラッシュパッケージ２３０を管理するための情報で、フラッシュパッケージID２５０１、フラッシュパッケージ仮想容量２５０２、ブロック容量２５０３を含む。フラッシュパッケージ情報２５００は、フラッシュパッケージ２３０毎に存在する。以下、あるフラッシュパッケージ情報２５００で管理されるフラッシュパッケージ２３０を、管理対象フラッシュパッケージと呼ぶ。
フラッシュパッケージID２５０１は管理対象フラッシュパッケージの識別子（パッケージＩＤと呼ぶ）である。フラッシュパッケージ仮想容量２５０２は、管理対象フラッシュパッケージが形成するフラッシュボリュームの記憶領域のうち、ストレージコントローラ２００に提供している領域のサイズであり、本実施例ではこのサイズのことを「仮想容量」と呼ぶ。
本発明では、このフラッシュパッケージ仮想容量２５０２を、フラッシュパッケージ２３０の重複排除率などに応じて調整するのが特長である。本実施例では、フラッシュパッケージ２３０がこの容量を決定するが、ストレージコントローラ２００が決定してもよい。フラッシュパッケージ２３０から、仮想容量が変化した旨の通知を受けると、ストレージコントローラ２００は、この値をフラッシュパッケージ仮想容量２５０２に設定する。
ブロック容量２５０３は、ブロックのサイズである。したがって、フラッシュパッケージ仮想容量２５０２をブロック容量２５０３で割った値が、このフラッシュパッケージ２３０のブロック数となる。
再び図４を用いて、フラッシュボリュームと仮想容量の関係について概説する。本実施例に係るフラッシュパッケージ２３０は、フラッシュボリュームＶ１のうち、仮想容量（フラッシュパッケージ仮想容量２５０２）に等しいサイズの領域を、ストレージコントローラ２００に提供する。原則としてフラッシュボリュームＶ１上の任意の領域をストレージコントローラ２００に提供してもよいが、本実施例では一例として図４に示されるように、フラッシュボリュームＶ１の先頭から始まる連続領域（領域Ａ。この領域のサイズは仮想容量に等しい）を提供する例を説明する。
仮想容量は、フラッシュパッケージ２３０の持つ全フラッシュチップ３００の合計記憶容量より大きくてもよい。図４において、ストレージコントローラ２００はフラッシュボリュームＶ１上の、領域Ａ（仮想容量に等しいサイズの領域）だけアクセスできる。また仮想容量は、先に述べたとおり変動可能である。仮想容量（つまり領域Ａ）のサイズが増加すると、アクセス可能な領域は増加することになる。
フラッシュパッケージ２３０の仮想容量の調整は、たとえば特許文献２に記載のものと同様の考え方で行われるとよい。フラッシュボリュームＶ１上の仮想セグメントのうち、ｎ個の仮想セグメントに対してデータ書き込みが行われたとする。書き込まれたデータはフラッシュチップ３００の実セグメントに格納される（実セグメントが消費されると言い換えてもよい）。
重複排除が殆ど行われない場合、ｎ個に近い数の実セグメントが消費される。この場合には、仮想容量はフラッシュパッケージ２３０内の実セグメントの合計と同程度であることが望まれる。ただし重複排除処理が行われると、データ書き込みが行われた仮想セグメントよりも少ない実セグメントしか消費されない。たとえばｎ／１０個の実セグメントしか消費されないこともあり得る。その場合に、もし仮想容量がフラッシュパッケージ２３０内の実セグメントの合計と等しいと、多くの実セグメントが未使用となり、記憶領域を有効活用できない。この場合には実セグメントの合計よりも多い記憶容量（たとえば実セグメントの総記憶容量の１０倍）を、仮想容量としてストレージコントローラ２００に提供すると、フラッシュパッケージ２３０内の記憶領域（実セグメント）を有効に使用できる。
つまり、データ書き込みが行われた仮想セグメントの量と、消費された実セグメントの量の比（重複排除率という）に応じて、仮想容量を調整（拡張または縮小）すると、フラッシュパッケージ２３０内の記憶領域（実セグメント）を有効に使用できる。ただし、仮想容量の調整の具体的な方法は、本発明と直接関係しないため、詳細な説明は略す。
またフラッシュパッケージ２３０は、フラッシュボリュームＶ１の終端に「隠し領域」と呼ばれる領域を確保している。隠し領域は、後述するハッシュインデックス情報３５００を格納するために設けられている。隠し領域にはストレージコントローラ２００はアクセスできない。ただしフラッシュパッケージ２３０で実行されるプログラム（少なくともハッシュインデックス情報３５００の参照更新を行うプログラム）は、隠し領域にアクセスできる。
図９は、フラッシュパッケージグループ情報２３００の形式を示す。フラッシュパッケージグループ情報２３００は、フラッシュパッケージグループ２８０についての情報を管理するために用いられる。１つのフラッシュパッケージグループ２８０に対して、１つのフラッシュパッケージグループ情報２３００が存在する。
フラッシュパッケージグループ情報２３００は、フラッシュパッケージグループID２３０１、パッケージグループRAIDタイプ２３０２、実ページ数２３０３、空き実ページ数２３０４、フラッシュパッケージポインタ２３０５を有する。以下、あるフラッシュパッケージグループ情報２３００で管理されるフラッシュパッケージグループ２８０のことを、「管理対象パッケージグループ」と呼ぶ。
フラッシュパッケージグループID２３０１は、管理対象パッケージグループの識別子である。パッケージグループRAIDタイプ２３０２は、管理対象パッケージグループのRAIDタイプである。このRAIDタイプは、論理ボリュームRAIDタイプ２００３を説明したときに述べたとおりである。
実ページ数２３０３は、空き実ページ数２３０４はそれぞれ、管理対象パッケージグループの全実ページ数、空き実ページ数を示す。
フラッシュパッケージポインタ２３０５は、管理対象パッケージグループに属するフラッシュパッケージ２３０のパッケージＩＤである。フラッシュパッケージグループ情報２３００に含まれるフラッシュパッケージポインタ２３０５の数は、管理対象パッケージグループに属するフラッシュパッケージ２３０の数と等しい。またこの数は、パッケージグループＲＡＩＤタイプ２３０２によって決まる値である。
続いて空き実ページ管理情報ポインタ２２００について説明する。空き実ページ管理情報ポインタ２２００は、フラッシュパッケージグループ２８０ごとに設けられる情報である。図１０は、空き実ページ管理情報ポインタ２２００によって管理される空き実ページの集合を表している。この構造を、空き実ページ管理情報キュー２２０１と呼ぶ。また、空き実ページに対応した実ページ情報２１００を空き実ページ情報２１００と呼ぶ。
空き実ページ管理情報ポインタ２２００は、空き実ページ管理情報キュー２２０１の先頭の空き実ページ情報２１００をポイントする（つまり空き実ページ管理情報ポインタ２２００には、先頭の空き実ページ情報２１００のアドレスが格納される）。次に、先頭の実ページ情報２１００の中の空きページポインタ２１０３が次の空き実ページ情報２１００を指す。図１０では、最後の空き実ページ情報２１００の空きページポインタ２１０３は、空き実ページ管理情報ポインタ２２００を指し示しているが、ヌル値が格納されてもよい。
ストレージコントローラ２００は、実ページを割り当てていない仮想ページに対する書き込み要求を受け付けると、その仮想ページの属する論理ボリュームの論理ボリュームRAIDタイプ２００３と同一のＲＡＩＤタイプ（パッケージグループＲＡＩＤタイプ２３０２）を持つフラッシュパッケージグループ２８０のいずれかを選択し、選択されたフラッシュパッケージグループ２８０が持つ空き実ページを選択し、仮想ページに割り当てる。例えば、空き実ページ数の最も多いフラッシュパッケージグループ２８０の空き実ページ管理情報ポインタ２２００から、空き実ページが選択されるとよい。
続いて図１１を用いて、ハッシュ値格納情報２４００のフォーマットを説明する。本実施例に係るストレージシステム１００では、重複排除の判定で用いられるハッシュ値は、フラッシュチップ３００に格納される。本実施例に係るストレージシステム１００の特徴は、ハッシュ値を、複数のフラッシュパッケージ２３０に分散して格納する点である。ハッシュ値は、データが更新される度に内容が変化することがほとんどである。またデータに比べて容量が小さい。そのためハッシュ値を特定の領域に集約して格納すると、その領域のブロック消去回数がデータに比べ大きくなり、フラッシュメモリの消去回数が早期に限界数に到達する可能性が高い。これが、ストレージシステム１００がハッシュ値を複数のフラッシュパッケージ２３０に分散して格納する理由である。
また、本実施例に係るストレージシステム１００のもう一つの特徴は、フラッシュパッケージ２３０にハッシュ値とデータの双方を格納する点である。これにより、データを格納した実セグメントとハッシュ値を格納した実セグメントの双方の消去回数を、フラッシュパッケージ２３０が（ローカルな）ウェアレベリングにより、均衡化する。ハッシュ値の更新回数とデータの更新回数のオーダはだいたい同じなので、フラッシュパッケージ２３０の全体の実セグメントの更新回数は、データの更新回数とほぼ同じオーダにすることができる。
ハッシュ値格納情報２４００は、各ハッシュ値をどのフラッシュパッケージ２３０に格納して管理するかを示した情報である。本実施例に係るストレージシステム１００では、ハッシュ空間（ハッシュ値の取りえる値の範囲。たとえばストレージシステム１００で用いられるハッシュ関数で得られる値が０〜（２ｈ−１）の値をとり得る場合、ハッシュ空間のサイズは２ｈとなる）をフラッシュパッケージ２３０より十分大きな数（仮にｋ個とする）で分割し、それぞれの分割単位に属するハッシュ値に関する情報を、ストレージシステム１００内のいずれかフラッシュパッケージ２３０に格納する（十分大きな数に分割するのは、それぞれの分割単位により、ハッシュ値に関する情報の大きさはバラバラになる可能性があり、かつ、その情報の更新頻度もバラバラになるためである。たとえば、ハッシュ値の空間が、２の３２乗であれば、フラッシュパッケージ２３０の数（フラッシュパッケージ２３０の数は多くとも千程度である）より十分大きな数、例えば、数万個に分割される）。
ハッシュ値格納情報２４００は、ハッシュ範囲２４０１とフラッシュパッケージＩＤ２４０２のセットを複数有する。ここでは、ハッシュ範囲２４０１とフラッシュパッケージＩＤ２４０２のセットを、エクステント２４１０と呼ぶ。図１１ではエクステント２４１０−１，２４１０−２、…、２４１０−ｋが記載されている。エクステント２４１０の個数はｋ個である。ハッシュ空間のサイズが２ｈの場合、最初のハッシュ範囲２４０１は、０から２ｈ÷ｋ−１で、２番目は、２ｈ÷ｋから２×２ｈ÷ｋ−１である。ｉ番目は、（ｉ−１）×２ｈ÷ｋからｉ×２ｈ÷ｋ−１である。
フラッシュパッケージＩＤ２４０２には、フラッシュパッケージ２３０のパッケージＩＤが格納される。たとえばあるエクステント２４１０内のハッシュ範囲２４０１に格納されているハッシュ値範囲がａ〜ｂで、またそのエクステント２４１０内のフラッシュパッケージＩＤ２４０２がｐの場合、フラッシュパッケージ＃ｐに範囲ａ〜ｂのハッシュ値が格納されることを意味する。またこの場合、ａ〜ｂの範囲のハッシュ値のことを、「フラッシュパッケージ＃ｐが担当するハッシュ値」と呼ぶ。
次に、フラッシュパッケージ２３０が有する管理情報について説明する。フラッシュパッケージ２３０は、ほとんどの管理情報をパッケージメモリ３２０内に格納している。図１２は、パッケージメモリ３２０に含まれる情報を示している。パッケージメモリ３２０に含まれる情報には、パッケージ情報３０００、チップ情報３１００、仮想ブロックグループ情報３２００、実ブロック情報３３００、空き実ブロック情報ポインタ３６００、フラッシュパッケージグループ情報２３００、ハッシュ値格納情報２４００、履歴情報３４００、リーフセグメント以外のハッシュインデックス情報３５００がある。
ハッシュ値格納情報２４００、フラッシュパッケージグループ情報２３００は、ストレージコントローラ２００が持つハッシュ値格納情報２４００、フラッシュパッケージグループ情報２３００と殆ど同じであるため、ここでは内容の説明は略す。なお、ストレージシステム１００に含まれるすべてのフラッシュパッケージグループ２８０のフラッシュパッケージグループ情報２３００が、パッケージメモリ３２０内に格納される。
ハッシュ値格納情報２４００、フラッシュパッケージグループ情報２３００は、たとえば初期化時に、ストレージコントローラ２００から各フラッシュパッケージ２３０に提供される。またストレージコントローラ２００がハッシュ値格納情報２４００とフラッシュパッケージグループ情報２３００を更新するたびに、ストレージコントローラ２００は更新した情報を各フラッシュパッケージ２３０に提供する。
本実施例に係るストレージシステム１００で、ストレージコントローラ２００がもつハッシュ値格納情報２４００と同様の情報を各フラッシュパッケージ２３０がもつ理由は、重複排除処理の際、ストレージシステム１００だけでなく各フラッシュパッケージ２３０も、各フラッシュパッケージ２３０が担当しているハッシュ値に関する情報を認識している必要があるためである。
また、フラッシュパッケージ２３０が、ストレージコントローラ２００が管理しているフラッシュパッケージグループ情報２３００と同じ情報をもつ理由は、フラッシュパッケージ２３０が重複排除の判定を行う際に、重複排除されるべきでないデータを識別するためである。たとえば同じストライプラインに属するデータについて重複排除処理が行われると冗長性が失われ、フラッシュパッケージ２３０の障害時にデータの再生成ができないことがある。そのため本実施例に係るフラッシュパッケージ２３０は、同じストライプラインに属するデータについては重複排除処理を行わないようにする。その際にフラッシュパッケージ２３０は、フラッシュパッケージグループ情報２３００を用いて、複数のデータが同一ストライプラインに属するか否か判定を行う。
図１３は、パッケージ情報３０００の形式を示している。パッケージ情報３０００は、パッケージID３００１、仮想パッケージ容量３００２、実パッケージ容量３００３、フラッシュブロック容量３００４、パッケージ空きブロック数３００５、内部情報格納ブロック数３００９、内部情報格納アドレス３０１０を有する。
パッケージID３００１は、当該フラッシュパッケージ２３０の識別子である。仮想パッケージ容量３００２は、当該フラッシュパッケージ２３０の仮想容量である。実パッケージ容量３００３は、当該フラッシュパッケージグループ２８０の物理記憶領域（フラッシュチップ３００の実ブロックまたは実セグメント）の容量である。ただこの容量は、ストレージコントローラ２００からのライトデータを格納するための容量、重複排除に用いる情報を格納するための容量、パッケージメモリ３２０の情報を退避するための容量、リクラメーションを行う等の目的で使用される領域（予備領域）の容量の合計である。
フラッシュブロック容量３００４は、フラッシュメモリの消去単位であるブロックのサイズである。パッケージ空きブロック数３００５は、当該フラッシュパッケージ２３０内の空きブロックの数である。
内部情報格納ブロック数３００９は、パッケージメモリ３２０に格納されたパッケージ情報３０００、チップ情報３１００、仮想ブロックグループ情報３２００、実ブロック情報３３００、履歴情報３４００、リーフセグメント以外のハッシュインデックス情報３５００、空き実プロック情報ポインタ３６００を、電源OFF時または障害発生時に退避させる実ブロック（この実ブロックを「内部情報格納ブロック」と呼ぶ）のブロック数である。内部情報格納アドレス３０１０は、内部情報格納ブロックのアドレスである。パッケージ情報３０００、チップ情報３１００、仮想ブロックグループ情報３２００、実ブロック情報３３００は重要な情報なので、ｎ重に格納してもよい。また、退避される回数はそう多くないので、実ブロックの消去回数なども問題にならないと考えられる。
図１４は、チップ情報３１００の形式である。チップ情報３１００は、フラッシュチップ３００の属性情報を管理するための情報である。チップ情報３１００は、フラッシュチップ３００ごとに存在する情報である。チップ情報３１００は、チップID３１０１、チップ実ブロック数３１０２、チップ内空き実ブロック数３１０３、接続バスID３１０４を有する。以下、あるチップ情報３１００が管理対象とするフラッシュチップ３００のことを、「管理対象チップ」と呼ぶ。
チップID３１０１は、管理対象チップのチップＩＤである。チップ実ブロック数３１０２は、管理対象チップがもつ実ブロックの数である。チップ内空き実ブロック数３１０３は、管理対象チップ内の空き実ブロックの数を示している。なお空き実ブロックとは、仮想ブロックグループに割り当てられていない実ブロックのことを意味する。接続バスID３１０４は、管理対象チップが接続されているパッケージバス３４０の識別子である。
図１５は、実ブロック情報３３００の形式である。実ブロック情報３３００は、実ブロックごとに存在する情報である。実ブロック情報３３００は、実ブロック識別子３３０１、空き実ブロックポインタ３３０２、実ブロック内空き容量３３０４、実セグメントビットマップ３３０５を含む。以下の説明では、ある実ブロック情報３３００の管理対象となる実ブロックを、「管理対象実ブロック」と呼ぶ。
実ブロック識別子３３０１は、管理対象実ブロックの識別子である。本実施例では実ブロックの識別子は、フラッシュパッケージ２３０内の実ブロックを一意に特定可能にするために、実ブロックが属するフラッシュチップ３００のチップＩＤ、ダイ番号、ブロック番号の組み合わせとして表現される。空き実ブロックポインタ３３０２は、管理対象実ブロックが仮想ブロックグループに割り当てられていない（空き状態にある）時、次の空き状態にある実ブロックの実ブロック情報３３００を指している。
実ブロック内空き容量３３０４は、管理対象実ブロックの現在の空き容量を示している。パッケージプロセッサ３１０は、ストレージコントローラ２００から管理対象実ブロックの実ブロック内空き容量３３０４以下の大きさのライトデータを受領した時、管理対象実ブロックの空き領域にライトデータを格納できる。ライトデータを格納した後、パッケージプロセッサ３１０は実ブロック内空き容量３３０４から格納したデータのサイズを減算する。なお、フラッシュメモリの最小書き込み単位はセグメントなので、格納したデータのサイズは、セグメント（実セグメント）の整数倍である。
実セグメントビットマップ３３０５は、実ブロック内の実セグメント数がＮ個の場合、Ｎビットのサイズの情報である。実セグメントビットマップ３３０５内のｋ番目のビットが１（オン）の場合、管理対象実ブロック内の先頭からｋ番目の実セグメントが使用中（仮想セグメントに割り当てられている）ことを意味し、０（オフ）の場合、管理対象実ブロック内の先頭からｋ番目の実セグメントが未使用（仮想セグメントに割り当てられていない）であることを意味する。
続いて空き実ブロック情報ポインタ３６００について説明する。空き実ブロック情報ポインタ３６００は、フラッシュチップ３００ごとに存在する。図１６は、空き実ブロック情報ポインタ３６００によって管理される空き実ブロックの集合を表している。この構造を、空き実ブロック情報キュー１７００と呼ぶ。空き実ブロック情報ポインタ３６００は、空き実ブロック情報キュー１７００内の先頭の空き実ブロックの実ブロック情報３３００をポイントする（つまり空き実ブロック情報ポインタ３６００には、先頭の空き実ブロックの実ブロック情報３３００が格納されている、パッケージメモリ３２０上アドレスが格納される）。次に、先頭の空き実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２が次の空き実ブロックの実ブロック情報３３００をポイントする。図１６では、空き実ブロック情報キュー１７００の最後尾の空き実ブロックの実ブロック情報３３００の空き実ブロックポインタ３３０２は、空き実ブロック情報ポインタ３６００を示しているが、ヌル値でもよい。
パッケージプロセッサ３１０は、実ブロックが割り当てられていない仮想ブロックグループ内仮想セグメントに対する書き込み要求を受け付けると、フラッシュチップ３００の中のいずれかに対応する空き実ブロック情報ポインタ３６００から、空き実ブロックを探し、仮想ブロックグループに割り当てる。例えば、空き実ブロック数（チップ内空き実ブロック数３１０３）の最も多いフラッシュチップ３００から、空き実ブロックが選択されるとよい。
図１７は、仮想ブロックグループ情報３２００の形式である。仮想ブロックグループ情報３２００は、仮想ブロックグループを管理するための情報で、仮想ブロックグループごとに存在する情報である。仮想ブロックグループ情報３２００はパッケージメモリ３２０内で、仮想ブロックグループのアドレス順に並んでいるものとする。パッケージメモリ３２０内の先頭仮想ブロックグループ情報３２００が、仮想ブロックグループ＃０の管理情報である。またパッケージメモリ３２０内の先頭からｋ番目の仮想ブロックグループ情報３２００は、仮想ブロックグループ＃（ｋ−１）の管理情報である。
仮想ブロックグループ情報３２００は、仮想ブロックグループ識別子３２０１、実ブロック情報ポインタ３２０２、データ格納量３２０３、新仮想セグメントポインタ３２０５、新ハッシュ値３２０６、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１、消去防止仮想セグメント数３２０７、消去防止アドレス３２０８、消去防止ハッシュ値３２０９を含む。以下、仮想ブロックグループ情報３２００で管理される仮想ブロックグループのことを、「管理対象仮想ブロックグループ」と呼ぶ。
本実施例では、重複排除処理の単位がセグメントである場合の例を説明する。ただし本発明は、重複排除の単位がセグメントでない場合も有効である。本実施例に係るストレージシステム１００は、更新データの書き込みが行われた仮想セグメントごとに、当該仮想セグメントに書き込まれた更新データのハッシュ値と同じハッシュ値をもつデータがいずれかのフラッシュパッケージ２３０に既に格納されていないかをチェックする。もしそのようなデータが既に存在する場合、更新データは格納されない（削除される）。これによって、フラッシュパッケージ２３０に格納されるデータ量を削減できる効果がある。
仮想ブロックグループ識別子３２０１は、管理対象仮想ブロックグループの識別子である。実ブロック情報ポインタ３２０２は、管理対象仮想ブロックグループに割り当てられた実ブロックの、実ブロック情報３３００へのポインタ（実ブロック情報３３００が格納されている、パッケージメモリ３２０上アドレス）である。実ブロック情報ポインタ３２０２は、ｍ＋１個存在する。実ブロック情報ポインタ３２０２は、実ブロックを割り当ていないときには、ヌル値となる。当該仮想ブロックグループに割り当てられている実ブロックの数をｐ個（ｍ＋１以下）とすると、先頭からｐ個の実ブロック情報ポインタ３２０２が有効である（ヌル値でない）。
データ格納量３２０３は、管理対象仮想ブロックグループに格納されているデータ量をあらわす。最大容量は、(実ブロックの容量×（m+1）)となる。フラッシュメモリの場合、仮想セグメントの内容が更新されると、それまで仮想セグメントに割り当てられていた実セグメントとは異なる実セグメントに更新データが格納される。そのため、同一の仮想セグメントに対して書き込まれたデータ（最新のデータ及び更新前データ）が複数個所に存在する。そのためデータ格納量３２０３は、仮想ブロックグループ内仮想セグメントの合計サイズよりも大きくなることがある。
続いて説明する新仮想セグメントポインタ３２０５、新ハッシュ値３２０６、消去防止仮想セグメント数３２０７、消去防止アドレス３２０８、消去防止ハッシュ値３２０９、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１は、仮想ブロックグループ内の仮想セグメントごとに設けられる情報である。以下では、これらの情報をまとめて「仮想セグメント管理情報」と呼ぶこともある。
新仮想セグメントポインタ３２０５、新ハッシュ値３２０６、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１はそれぞれ、仮想ブロックグループ情報３２００内に、仮想ブロックグループ内仮想セグメント数と同数存在する情報である。なお、図中で、新仮想セグメントポインタ３２０５の参照番号が「３２０５−ｓ」のように記載されている箇所がある。これは相対仮想セグメント番号が“ｓ”の仮想セグメントの新仮想セグメントポインタであることを表している。またこの参照番号の付与規則は、新ハッシュ値３２０６、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１、消去防止仮想セグメント数３２０７、消去防止アドレス３２０８、消去防止ハッシュ値３２０９についても同様である。
新仮想セグメントポインタ３２０５は、現在仮想セグメントに割り当てられている領域のアドレスを表す。正確には、新仮想セグメントポインタ３２０５には、ストレージコントローラ２００が仮想セグメントに対して書き込みが行われたデータのうち、最新のデータ（更新後データ）が格納された領域（実セグメントまたは仮想セグメント）のアドレス情報が格納される。新ハッシュ値３２０６は、仮想セグメントに書き込まれた最新データのハッシュ値である。具体的には、新仮想セグメントポインタ３２０５で特定される領域に格納されたデータのハッシュ値である。
新仮想セグメントポインタ３２０５、旧仮想セグメントポインタ３２１０、及び消去防止アドレス３２０８には、実セグメントを直接指し示す情報か、仮想セグメントを指し示す情報のいずれかが格納される。実セグメントを直接指し示す情報は、データの格納された実ブロックの識別子（実ブロック識別子３３０１）とその実ブロック内の相対アドレス（相対セグメント番号）の組み合わせで構成される情報で、この情報を実セグメントアドレスと呼ぶ。
たとえば図１８に示す例では、フラッシュパッケージ２３０−Ａの仮想セグメント＃ｘに書き込まれた最新データは、実ブロック＃０の実セグメント＃１（相対セグメント番号が１の実セグメントを表す）に格納されている。その場合仮想セグメント＃ｘの新仮想セグメントポインタ（３２０５）には、実ブロック＃０の実ブロック識別子３３０１と、相対セグメント番号（１）の組が格納される。ストレージコントローラ２００から仮想セグメント＃ｘのリード要求を受領すると、フラッシュパッケージ２３０−Ａは、仮想セグメント＃ｘの新仮想セグメントポインタ（３２０５）を参照することで、リード対象データの格納されている実セグメント（実ブロック＃０内の実セグメント＃１）を特定できる。
一方、仮想セグメントを指し示す情報には、仮想セグメントアドレスが用いられる。仮想セグメントの重複排除処理が行われると、新仮想セグメントポインタ３２０５に仮想セグメントアドレスが格納されることがある。図１８において、たとえば仮想セグメント＃ｙに、仮想セグメント＃ｘに書き込まれたデータと同じデータが書き込まれ、重複排除処理が行われたケースを想定する。その場合、仮想セグメント＃ｙの新仮想セグメントポインタ（３２０５）には、フラッシュパッケージ２３０−Ａの仮想セグメント＃ｘの仮想セグメントアドレスが格納されることになる。
本実施例では、図１８に示された状態のように、（仮想セグメント＃ｙの）新仮想セグメントポインタ３２０５に仮想セグメント＃ｘの仮想セグメントアドレスが格納されている場合、仮想セグメント＃ｙは「仮想セグメント＃ｘを参照している」と表現する。また仮想セグメント＃ｘは、「仮想セグメント＃ｙに参照されている仮想セグメント」と表現される。また（仮想セグメント＃ｙの）旧仮想セグメントポインタ３２１０や消去防止アドレス３２０８に仮想セグメント＃ｘの仮想セグメントアドレスが格納されている場合にも、「仮想セグメント＃ｙは仮想セグメント＃ｘを参照している」と表現される。なお、実セグメントについても同様の表現が用いられる。たとえば図１８において、仮想セグメント＃ｘの新仮想セグメントポインタ３２０５には、実ブロック＃０の実セグメント＃１の実セグメントアドレスが格納されている。この場合、「実セグメント＃１は仮想セグメント＃ｘに参照されている」と表現される。
なお本実施例では、フラッシュパッケージ２３０（パッケージプロセッサ３１０）が、新仮想セグメントポインタ３２０５（または旧仮想セグメントポインタ３２１０、や消去防止アドレス３２０８）に格納されている情報が実セグメントアドレスであるか仮想セグメントアドレスであるか認識できるように、実セグメントアドレスと仮想セグメントアドレスのフォーマットが定められている。たとえば実セグメントアドレスの最上位ビットは常に“１”で、仮想セグメントアドレスの最上位ビットは常に“０”である、と定められているとよい。
図１８の状態にあるフラッシュパッケージ２３０−Ｂに対して、ストレージコントローラ２００が仮想セグメント＃ｙのリード要求を発行すると、フラッシュパッケージ２３０−Ｂは仮想セグメント＃ｙの新仮想セグメントポインタ（３２０５）を参照することで、新仮想セグメントポインタ（３２０５）に仮想セグメント＃ｘの仮想セグメントアドレスが格納されていることを認識する。この場合フラッシュパッケージ２３０−Ｂはストレージコントローラ２００に、読み出された仮想セグメントアドレス等を返送する。この情報を受けたストレージコントローラ２００は、返送された仮想セグメントアドレス（仮想セグメント＃ｘ）をアクセス先とするリード要求を発行することで、リード対象のデータを得る（つまりアクセスのリダイレクションが行われる）。詳細は後述する。
旧仮想セグメントポインタ３２１０は、仮想セグメントに書き込まれたデータのうち、更新前データが格納された領域のアドレス情報が格納される。旧ハッシュ値３２１１は、旧仮想セグメントポインタ３２１０で特定される領域に格納されたデータのハッシュ値である。図１８において、仮想セグメント＃ｘの旧仮想セグメントポインタ（３２１０）は、実ブロック＃ｂの実セグメント＃０をポイントしている。これは仮想セグメント＃ｘの更新前データが、実ブロック＃ｂの実セグメント＃０に格納されていることを意味する。
仮想セグメントに対する更新が発生すると、過去にその仮想セグメントに書き込まれたデータ（更新前データ）は原則として消去してもよいはずである。ただし重複排除処理が行われると、この更新前データを他の仮想セグメントが参照する（他の仮想セグメントの新仮想セグメントポインタ３２０５等によってポイントされる）状態が発生することがある（たとえば図１８では、フラッシュパッケージ２３０−Ａの仮想セグメント＃ｘが、フラッシュパッケージ２３０−Ｂの仮想セグメント＃ｙによって参照されている）。その場合、この更新前のデータを消去できないので、これを記憶（退避）しておくために旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１が用いられる。
そして、仮想セグメントに更なる更新が発生した場合、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１に格納された内容も退避しておく必要が出る。そのために、後述する消去防止アドレス３２０８、消去防止ハッシュ値３２０９が用いられる。
なお、本実施例では、新仮想セグメントポインタ３２０５、新ハッシュ値３２０６、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１が、仮想セグメントごとに存在する例を説明しているが、２つ以上の仮想セグメントごとに同様の情報をもたせるようにしてもよい。
消去防止アドレス３２０８、消去防止ハッシュ値３２０９は、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１の値を退避するために用いられる。退避が必要な旧仮想セグメントポインタ３２１０と旧ハッシュ値３２１１の数は１とは限らない。そのため消去防止アドレス３２０８と消去防止ハッシュ値３２０９は、１つの仮想セグメントに対して１または複数設けられる。
また消去防止仮想セグメント数３２０７は、消去してはいけない仮想セグメントの数（つまり、消去防止アドレス３２０８、消去防止ハッシュ値３２０９のセットの数）を示している。図１７に示されている仮想ブロックグループ情報３２００の例では、仮想ブロックグループ内の（ｓ＋１）番目の仮想セグメント（相対仮想セグメント番号がｓの仮想セグメント）の消去防止アドレス（３２０８−ｓ１，３２０８−ｓ２）、消去防止ハッシュ値（３２０９−ｓ１，３２０９−ｓ２）はそれぞれ２つ存在する。この場合、消去防止仮想セグメント数（３２０７−ｓ）の値は２になる。
以上のように、仮想セグメントごとに、新仮想セグメントポインタ３２０５、旧仮想セグメントポインタ３２１０、消去防止アドレス３２０８という情報が設けられており、結果として１つの仮想セグメントに複数の実セグメント（または仮想セグメント）が割り当てられることがある。上で述べたとおり、仮想セグメントに対してストレージコントローラ２００から書き込まれたデータのうち、最新のデータ（更新後データ）は、新仮想セグメントポインタ３２０５でポイントされる実セグメントに格納されている。そのため、フラッシュパッケージ２３０はストレージコントローラ２００からリード要求を受領した時は、原則として上で述べたように、新仮想セグメントポインタ３２０５でポイントされる実セグメントのデータを読み出して返送する。
ただし、アクセスのリダイレクションが発生した場合には、更新前データ（つまり旧仮想セグメントポインタ３２１０、消去防止アドレス３２０８でポイントされる実セグメントに格納されたデータ）を返送する必要があるかもしれない。この具体的方法は後述する。
なお、以下では、仮想セグメントに書き込まれたデータのうち、仮想セグメントの新仮想セグメントポインタ３２０５でポイントされる実セグメントに格納されたデータの事を、「仮想セグメントの更新後データ」または「仮想セグメントの更新データ」と呼ぶ。一方、仮想セグメントの旧仮想セグメントポインタ３２１０または消去防止アドレス３２０８でポイントされる実セグメントに格納されたデータのことは、「仮想セグメントの更新前データ」または「仮想セグメントの旧データ」と呼ぶ。
なお、本実施例に係るストレージシステム１００は、ハッシュ関数ＳＨＡ−２５６を用いて、仮想セグメントに書き込まれるデータのハッシュ値を計算する。ＳＨＡ−２５６は衝突が発生する確率が極めて小さい。そのため本実施例に係るストレージシステム１００では、ハッシュ値が同一のデータが複数ある場合、それらのデータの内容は同じであるとみなし、重複排除処理を行う。ただし、ハッシュ値の比較に加えて各データの全内容を（ビットまたはバイト単位で）比較することで重複排除の判定が行われる場合にも、本発明は適用可能である。
続いて図１９に示されている履歴情報３４００について説明する。本実施例に係るストレージシステム１００では、重複排除処理はホスト１１０のライト処理とは非同期に実行される。このためフラッシュパッケージ２３０は、ライト処理の履歴を示す履歴情報３４００を維持する。履歴情報３４００は、履歴情報数３４０１、ライトアドレス３４０２、更新前ハッシュ値３４０３、更新後ハッシュ値３４０４をもつ。
ライトアドレス３４０２は、ストレージコントローラ２００からライトデータの書き込みが行われた仮想セグメントの仮想セグメントアドレスである。以下、ライトアドレス３４０２のことを、「仮想セグメントアドレス３４０２」と表記することもある。
更新前ハッシュ値３４０３と更新後ハッシュ値３４０４は、ライトアドレス３４０２で特定される仮想セグメントに書き込まれたデータ（更新後データまたは更新前データ）のハッシュ値を表す。更新後ハッシュ値３４０４は、更新後データのハッシュ値を示す情報である。一方更新前ハッシュ値３４０３は更新前データのハッシュ値を示す情報である。以下では、ライトアドレス３４０２、更新前ハッシュ値３４０３、更新後ハッシュ値３４０４のセットを「ライト履歴」と呼ぶ。
履歴情報数３４０１は、履歴情報３４００に格納されているライト履歴（ライトアドレス３４０２、更新前ハッシュ値３４０３、更新後ハッシュ値３４０４のセット）の数を示す情報で、初期値は０である。フラッシュパッケージ２３０がストレージコントローラ２００からライト要求を受け付け、ライト処理を行うたびに、ライト履歴が履歴情報３４００に追加され、履歴情報数３４０１の値も加算される。ライト履歴は、ライト要求を受け付けた時刻順に履歴情報３４００内に格納される。履歴情報数３４０１の直後に格納されるライト履歴が、最も古いライト履歴となる。ストレージコントローラ２００から履歴情報送信要求を受領すると、フラッシュパッケージ２３０は履歴情報３４００をストレージコントローラ２００に送出し、履歴情報３４００内の情報を全クリアする（履歴情報数３４０１が０にされる。また、各ライト履歴も消去されてもよい）。
続いてハッシュインデックス情報３５００について説明する。先に述べたとおり、本実施例に係るストレージシステム１００では、各フラッシュパッケージ２３０が担当するハッシュ値の範囲はあらかじめ決められている。ハッシュインデックス情報３５００は、ハッシュ値が与えられた時に、そのハッシュ値を持つデータの格納されているフラッシュパッケージ２３０（正確には仮想セグメントアドレス）を特定するための情報である。ハッシュインデックス情報３５００には、フラッシュパッケージ２３０が担当するハッシュ値と、そのハッシュ値をもつデータの格納位置についての情報が格納される。
ハッシュインデックス情報３５００の構造を、図２０に示す。この構造は基本的には、ＤＢＭＳ（データベース管理システム）が管理するインデックスに用いられるＢ＋Ｔｒｅｅ等と同じ構造である。
リーフセグメント３５０１は、Ｂ＋Ｔｒｅｅ等の木構造におけるリーフノードに相当する。そして本実施例では、Ｂ＋Ｔｒｅｅのルートノードからリーフノードに至る経路上に存在する各ノードのことは、階層セグメント３５０９と呼ばれる。リーフセグメント３５０１以外の情報（各階層セグメント３５０９）は、パッケージメモリ３２０（と内部情報格納ブロック）に格納されている。一方、リーフセグメント３５０１はフラッシュチップ３００に格納される。
ただし先に述べたとおり、フラッシュパッケージ２３０はフラッシュボリューム上に、リーフセグメント３５０１の格納される領域（隠し領域）を設けている。リーフセグメント３５０１の参照または更新を行うプログラム（後述する重複排除判定部１２３００等）は、隠し領域上の仮想セグメントに対してリード要求またはライト要求を発行することで、リーフセグメント３５０１の読み書きを行う。その結果リーフセグメント３５０１がフラッシュチップ３００（仮想セグメントに割り当てられる実セグメント）に書き込まれる。
そのため、リーフセグメント３５０１の大きさは、仮想セグメントと同サイズである。リーフセグメント３５０１に、仮想セグメントのサイズに満たない量の情報しか格納されないこともあるが、その場合リーフセグメント３５０１の更新を行うプログラムは、“０”等の無効データをｐａｄｄｉｎｇすることで、リーフセグメント３５０１を仮想セグメントと同サイズの大きさにして、フラッシュチップ３００に格納する。
リーフセグメント３５０１には、ハッシュ値とそのハッシュ値をもつデータの格納位置の集合が格納される。この、データの格納位置を表現するための情報としては、仮想セグメントアドレスが用いられる。そのため、以下では、ハッシュ値Ｈをもつデータの格納位置のことを、「ハッシュ値Ｈを持つ仮想セグメント」と呼ぶ。
リーフセグメント３５０１に格納されるハッシュ値の範囲についての情報は、リーフセグメント３５０１の親ノード（階層セグメント３５０９）に含まれている。図２０を用いてリーフセグメント３５０１に格納されるハッシュ値の範囲について説明する。図２０において、リーフセグメント３５０１−１とリーフセグメント３５０１−２は、共通の親ノードである階層セグメント３５０９−１に接続されている。
階層セグメント３５０９は、リーフアドレス３５０７とハッシュ値の最小値（Ｍｉｎ（ｈａｓｈ））３５０８のセットを１以上（階層セグメント３５０９に接続されるリーフセグメント３５０１の数と同数）含む。リーフアドレス３５０７はリーフセグメント３５０１へのポインタである。リーフセグメント３５０１へのポインタに用いられる値は、仮想セグメントアドレスである（リーフセグメント３５０１が仮想セグメントに書き込まれるからである）。Ｍｉｎ（ｈａｓｈ）３５０８には、リーフアドレス３５０７でポイントされるリーフセグメント３５０１に格納されるべきハッシュ値の最小値が格納される。
図２０の構造例において、たとえばＭｉｎ（ｈａｓｈ）３５０８−１に０、Ｍｉｎ（ｈａｓｈ）３５０８−２にｋ（ｋは０より大きい値）が格納されていた場合、リーフアドレス３５０７−１でポイントされるリーフセグメント３５０１−１には、０から（ｋ−１）の範囲のハッシュ値が格納され、リーフセグメント３５０１−２には、ｋ以上の値のハッシュ値が格納される。そのため、各階層セグメント３５０９の内容（Ｍｉｎ（ｈａｓｈ）３５０８）を参照することで、探索対象のハッシュ値が格納されたリーフセグメント３５０１を特定することができる。ただし初期状態では、リーフセグメント３５０１にハッシュ値は格納されていない。フラッシュパッケージ２３０にライトデータが格納され、ライトデータのハッシュ値が計算された後、リーフセグメント３５０１にハッシュ値は格納されるが、詳細は後述する。
なお、階層セグメント３５０９（たとえば図２０の階層セグメント３５０９−１）の親ノードである階層セグメント３５０９にも、リーフアドレス３５０７とＭｉｎ（ｈａｓｈ）３５０８のセットが１以上含まれる。この場合のリーフアドレス３５０７には、下位の階層セグメント３５０９が置かれているメモリ（パッケージメモリ３２０）上のアドレスが用いられる。そして、このリーフアドレス３５０７に対応するＭｉｎ（ｈａｓｈ）３５０８には、下位の階層セグメント３５０９に格納されている複数のＭｉｎ（ｈａｓｈ）３５０８の中の最小値が格納される。この方法で、さらに、上位の階層セグメント３５０９が形成され、最上位の階層セグメント３５０９つまりルートノードには、ハッシュ値の全空間に関する情報が格納できるような構造となる。
リーフセグメント３５０１に格納される情報の詳細を、図２１を用いて説明する。リーフセグメント３５０１には、登録ハッシュ値３５０２、登録データ数３５０３、セグメント数３５０４、登録アドレス３５０５、無効フラグ３５０６のセットが１以上格納される。以下ではこのセットのことを、エントリ３５１０と呼ぶ。
図２１の例では、エントリ３５１０が３つ格納されている例が示されている。ただしリーフセグメント３５０１内のエントリ３５１０の数は、３未満のこともあれば、４以上になることもある。また、登録アドレス３５０５と無効フラグ３５０６のセットは、エントリ３５１０内に複数個格納されることがある。図２１の例では、エントリ３５１０−１に、登録アドレス３５０５と無効フラグ３５０６のセットが３個格納されている。
以下、エントリ３５１０内に格納される情報について説明する。先に述べたとおり、ハッシュ値はリーフセグメント３５０１に格納される。具体的には、エントリ３５１０内の登録ハッシュ値３５０２にハッシュ値が格納される。１つのエントリ３５１０に格納されるハッシュ値は１つである。たとえば、あるリーフセグメント３５０１にハッシュ値がｎ個格納される場合、そのリーフセグメント３５０１にエントリ３５１０がｎ個設けられ、各エントリ３５１０の登録ハッシュ値３５０２に、ハッシュ値が格納される。
また、登録ハッシュ値３５０２の直後には、登録データ数３５０３が格納される。登録データ数３５０３は、エントリ３５１０内の登録ハッシュ値３５０２に格納されたハッシュ値と同じハッシュ値をもつ仮想セグメント（重複セグメントと呼ぶ）の数を示す。ただし登録データ数３５０３には、重複排除処理対象になっていない仮想セグメントの数は含まれない。
登録データ数３５０３の後に、セグメント数３５０４、登録アドレス３５０５、無効フラグ３５０６が格納される。登録アドレス３５０５は、エントリ３５１０内の登録ハッシュ値３５０２に格納されたハッシュ値をもつ仮想セグメントの仮想セグメントアドレスである。そして無効フラグ３５０６は、この直前の登録アドレス３５０５に有効な値が格納されているか否かを表す情報である。無効フラグ３５０６に“１”（ＯＮ）が格納されている時、この直前の登録アドレス３５０５に有効な値が格納されていないことを表す。
セグメント数３５０４には、エントリ３５１０内に格納されている登録アドレス３５０５と無効フラグ３５０６のセットの数が格納される。原則として、重複排除処理が行われた直後、同一ハッシュ値を持つ仮想セグメントは、ストレージシステム１００内に１つだけ存在すればよい（つまりエントリ３５１０内に登録アドレス３５０５は１つだけあればよい）。ただし本実施例に係るストレージシステム１００は、同一ストライプラインに同じハッシュ値を持つ仮想セグメントが存在する場合、先に述べた理由から、それらの仮想セグメントについて重複排除処理を行わない。そしてフラッシュパッケージ２３０は、１番目の登録アドレス３５０５で特定される仮想セグメントと同じハッシュ値を持つ仮想セグメントが同一ストライプライン上に存在した場合、それらの仮想セグメントの仮想セグメントアドレスを、２番目以降の登録アドレス３５０５に格納する。この処理の詳細は後述する。
先にも述べたが、登録データ数３５０３には、重複排除処理対象になっていない仮想セグメントの数は含まれない。登録データ数３５０３には、１番目の登録アドレス３５０５で特定される仮想セグメント、そしてこの仮想セグメントと異なるストライプライン上に存在し、かつ同じハッシュ値を持つ仮想セグメント（つまり重複排除処理の対象になった仮想セグメント）の合計が格納される。１番目の登録アドレス３５０５で特定される仮想セグメントと同じハッシュ値を持つ仮想セグメントが、すべて同一ストライプライン上に存在した場合には、登録データ数３５０３は１となる。
なお、ストレージコントローラ２００から仮想セグメントに対して新たなデータが書き込まれ、そのデータのハッシュ値がハッシュインデックス情報３５００に存在しない場合、そのハッシュ値を格納するためのエントリ３５１０がリーフセグメント３５０１に追加される。しかしエントリ３５１０が一つのリーフセグメント３５０１に格納しきれなくなると、リーフセグメント３５０１が追加される。そしてこれまでリーフセグメント３５０１（あるいは階層セグメント３５０９）に格納されていた情報は、再配置される。ただし、この操作は、Ｂ＋Ｔｒｅｅ等の木構造へのデータ挿入と同様の公知の操作であるので、ここでは説明を略す。
次に、上記に説明した管理情報を用いて、ストレージコントローラ２００とフラッシュパッケージ２３０が実行する処理の説明を行う。
まず、ストレージコントローラ２００で行われる処理について説明する。なおストレージコントローラ２００で行われる処理は原則として、ストレージコントローラ２００内のプロセッサ２６０がプログラムを実行することで実現される。また、そのプログラムはメモリ２７０内に格納されている。図２２は、メモリ２７０内に、格納された本実施例に関するプログラムが示されている。
本実施例に関するプログラムは、リード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００、重複排除スケジュール部４３００である。これらのプログラムは、上位レベルのウェアレベリング技術、容量仮想化技術を実現するプログラムである。なお以下の各処理の説明においては、プログラム（リード処理実行部４０００等）を主語として、処理の説明を行っている箇所がある。ただしこれは実際には、プログラム（リード処理実行部４０００等）がプロセッサ２６０で実行されることで、処理が行われることを意味する。
なお、すでに述べたが、本実施例に係るストレージシステム１００では、フラッシュパッケージ２３０が、ウェアレベリング機能と下位レベルの容量仮想化機能を実行する。ただし別の実施形態として、ウェアレベリングと下位レベルの容量仮想化機能をストレージコントローラ２００が実行してもよい。その場合、ウェアレベリング機能と下位レベルの容量仮想化機能を実現するプログラムが、ストレージコントローラ２００で実行される。したがって、上位レベルのプログラム（上位レベルの容量仮想化機能を実現するプログラム等）と下位レベルのプログラム双方が、ストレージコントローラ２００で実行されるので、プログラム間のインターフェイスが異なってくるが、上位レベルのプログラムが実行する内容は基本的に大きな相違はない。したがって、本実施例では、下位レベルのウェアレベリング技術、容量仮想化技術を実現するのは、フラッシュパッケージ２３０であることを前提に、リード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００、重複排除スケジュール部４３００の処理フローを詳細に説明する。
また本実施例では、ホスト１１０からのリード要求またはライト要求で指定されるデータアクセス範囲は、フラッシュメモリのリード・ライト単位である仮想セグメント境界に一致している前提で説明する。もちろん、ホスト１１０から指定されるアクセス範囲が、仮想セグメント境界に一致していない場合でも、論理ボリュームはアクセス可能である。たとえば、仮想セグメントの一部の領域がライト範囲に指定された場合、フラッシュパッケージ２３０は仮想セグメント全体を読み出し、指定された部分領域のみ更新し、仮想セグメント全体を書き込む。
図２３は、リード処理実行部４０００の処理フローである。リード処理実行部４０００は、ホスト１１０から、ストレージコントローラ２００が、リード要求を受け付けたときに実行される。
ステップ５０００：リード処理実行部４０００（プロセッサ２６０）は、受け取ったリード要求で指定されたリード対象領域のアドレスから、リード対象領域に対応する仮想ページの仮想ページ＃と仮想ページ内の相対アドレスを計算する。
ステップ５００１：リード処理実行部４０００は、リード対象となったデータが、キャッシュメモリ２１０に格納されているか（ヒットしているか）をチェックする。これは、公知の技術である。ヒットしている場合（ステップ５００１：Ｙｅｓ）、次にステップ５０１１が行われる。ヒットしていない場合（ステップ５００１：Ｎｏ）、次にステップ５００２が行われる。
ステップ５００２：ここでは、リード対象としているデータをキャッシュメモリ２１０にロードする必要がある。ますリード処理実行部４０００は、論理ボリューム情報２０００の実ページポインタ２００４を参照することで、リード対象仮想ページに割り当てられている実ページの実ページ情報２１００を特定する。なお、リード対象仮想ページに割り当てられた実ページを、以下の説明では「リード対象実ページ」と呼ぶ。
ステップ５００３：リード処理実行部４０００は、特定された実ページ情報２１００のパッケージグループ２１０１、実ページアドレス２１０２から、リード対象実ページが属するフラッシュパッケージグループ２８０とリード対象実ページ（の先頭）が位置するフラッシュパッケージグループ２８０内アドレスを算出する。
ステップ５００４：リード処理実行部４０００は、ステップ５００１で得た仮想ページ内の相対アドレスとパッケージグループＲＡＩＤタイプ２３０２から、リード対象データの格納されている実ページ上位置（具体的には実ページ内相対アドレス）を計算する。そしてリード処理実行部４０００は、計算した実ページ内相対アドレス、パッケージグループＲＡＩＤタイプ２３０２とフラッシュパッケージポインタ２３０５とを用いて、リード対象データの格納されているフラッシュパッケージ２３０、及びそのフラッシュパッケージ２３０内のアドレスを特定する。
ステップ５００５： リード処理実行部４０００は、ステップ５００４で特定したフラッシュパッケージ２３０のアドレスに対して、リード要求を発行する。
ステップ５００６：リード処理実行部４０００は、フラッシュパッケージ２３０からデータが送られてくるのを待つ。
ステップ５００７：リード要求を発行した結果、フラッシュパッケージ２３０から、データが重複排除されている旨の応答が返されることがある。この場合、応答には仮想セグメントアドレスとハッシュ値のセットが含まれている。ステップ５００７ではリード処理実行部４０００は、データが重複排除されている旨の応答がフラッシュパッケージ２３０から返却されたか判定する。そうであれば（ステップ５００７：Ｙｅｓ）、リード処理実行部４０００は次にステップ５００９を実行する。そうでない場合（ステップ５００７：Ｎｏ）は、フラッシュパッケージ２３０からはリードデータが返却されてくる。この場合は次にステップ５００８が実行される。
ステップ５００８：リード処理実行部４０００は、キャッシュメモリ２１０に、リード対象データを格納するための領域を確保し、フラッシュパッケージ２３０から送られてきたデータを、確保された領域に格納する。 この後、ステップ５０１１が行われる。
ステップ５００９：このステップが実行されるのは、フラッシュパッケージから、データが重複排除されている旨の応答（仮想セグメントアドレスとハッシュ値のセットを含む応答）が返された時である。応答に含まれる仮想セグメントアドレスは、リード対象データが実際に格納されているフラッシュパッケージ２３０及びその仮想セグメントを示す情報である。この場合、リード処理実行部４０００は応答に含まれている仮想セグメントアドレス及びハッシュ値を指定したリード要求（後述する「ハッシュ指定型リード要求」）を、実際にデータが格納されているフラッシュパッケージ２３０（応答に含まれている仮想セグメントアドレスには、パッケージＩＤが含まれているので、それによりフラッシュパッケージ２３０を特定できる）に発行する。
ステップ５０１０：リード処理実行部４０００は、フラッシュパッケージ２３０からデータが送られてくるのを待つ。フラッシュパッケージ２３０からのデータ転送が開始されると、リード処理実行部４０００はステップ５００８を実行する。
ステップ５０１１：リード処理実行部４０００は、リード対象データをキャッシュメモリ２１０から読み出してホスト１１０へ送り、処理を完了する。
図２４は、ライト要求受付部４１００の処理フローである。ライト要求受付部４１００は、ストレージコントローラ２００が、ホスト１１０からライト要求を受け付けたときに実行される。
ステップ６０００：ライト要求受付部４１００（プロセッサ２６０）は、受け取ったライト要求で指定されたライト対象領域のアドレスから、ライト対象領域に対応する仮想ページの仮想ページ＃と仮想ページ内の相対アドレスを計算する。
ステップ６００１：ライト要求受付部４１００は、ライト要求で指定されている論理ボリュームの論理ボリューム情報２０００を特定する。そしてライト要求受付部４１００は、ステップ６０００で特定された仮想ページに実ページが割り当てられているかを、特定した論理ボリューム情報２０００内の実ページポインタ２００４を参照することでチェックする。実ページが割り当てられている場合、ステップ６００２はスキップされ、次にステップ６００３が実行される。
ステップ６００２：ライト要求受付部４１００は、ライト対象領域に対応する仮想ページに実ページを割り当てる。この時ライト要求受付部４１００は、ステップ６００１で特定された論理ボリューム情報２０００の論理ボリュームＲＡＩＤタイプ２００３と、各フラッシュパッケージグループ情報２３００のパッケージグループＲＡＩＤタイプ２３０３や空き実ページ数２３０４等を参照することで、どのフラッシュパッケージグループ２８０の実ページを割り当てるかを決める。その後ライト要求受付部４１００は、決定されたフラッシュパッケージグループ２８０の空き実ページ管理情報ポインタ２２００を参照して、先頭の空き実ページ情報２１００を、ライト対象領域が属する仮想ページの実ページポインタ２００４が示すようにする。これで、ライト対象領域が属する仮想ページに実ページを割り当てたことになる。
なお、空き実ページ管理情報ポインタ２２００は、次の実ページ情報２１００（仮想ページに割り当てた実ページの実ページ情報２１００の中の空きページポインタ２１０３が示す実ページ情報２１００）を示すように変更され、さらに、仮想ページに割り当てた実ページの実ページ情報２１００の中の空きページポインタ２１０３はヌルにされる。またライト要求受付部４１００は、当該実ページに対応するフラッシュパッケージグループ管理情報の空き実ページ数２３０４の数を減らす。本実施例では、仮想ページを実ページに割り当てる処理がライト要求を受け付けたときに実施される例を説明したが、この割り当て処理は、フラッシュパッケージ２３０へデータを格納するまでに実行されればよい。
ステップ６００３：ライト要求受付部４１００は、ホスト１１０から当該ライト要求で指定されたライトデータを、キャッシュメモリ２１０に格納する。なお、キャッシュメモリ２１０にライトデータを格納する際には、ライト要求受付部４１００はそのライトデータの書き込み位置情報（フラッシュパッケージ２３０のＩＤ及び、フラッシュボリューム上アドレス（ＬＢＡ）等）を付加して格納する。その後、処理を終了する。
フラッシュパッケージグループ２８０は、ＲＡＩＤ構成をとるので、キャッシュメモリ２１０上に格納したライトデータに対応する冗長データ（ライトデータの格納されたデータストライプと同一ストライプラインに属するパリティストライプに格納されるべき冗長データ）を生成する必要がある。ただし、これは、公知の方法であるので、詳細に説明はしない。冗長データの生成は、たとえばステップ６００３の直後に行われると良い。プロセッサ２６０は冗長データを作成すると、一旦キャッシュメモリ２１０に冗長データを格納する。
また、先に述べたとおり、仮想ページ上のアドレスから、データを格納するデータストライプに加えて、そのデータに対応する冗長データを格納すべきパリティストライプも一意に定まる。なお、キャッシュメモリ２１０に冗長データを格納する際、ライトデータと同様に、プロセッサ２６０は書き込み位置情報を冗長データに付加する。
ライトデータ、冗長データは、ライトアフタ処理実行部４２００によって、フラッシュパッケージ２３０に書き込まれるが、フラッシュパッケージ２３０にとって、両者はいずれもフラッシュパッケージ２３０へ書き込むデータなので、両者を区別する必要はない。そのためライトアフタ処理実行部４２００は、ライトデータを書き込む場合と冗長データを書き込む場合とで、異なる処理を行うことはない。
ただし、重複排除処理の観点からは、冗長データは、複数のデータの論理演算（排他的論理和等）の結果生成されるものであるため、通常のデータに比較して、重複排除できる確率（他に同じデータがある確率）は小さい。このため、重複排除のオーバヘッドを削減するため、重複排除の対象にしなくともよい。この場合、ストレージコントローラ２００は、冗長データを書き込む際には、フラッシュパッケージ２３０に、当該データは、重複排除処理の対象にしない旨の情報を付加する。その旨を受領したフラッシュパッケージ２３０は、冗長データを重複排除の対象にしなくともよい。
図２５は、ライトアフタ処理実行部４２００の処理フローである。ライトアフタ処理実行部４２００は、プロセッサ２６０が所定の契機で実行する処理である。たとえば定期的にライトアフタ処理実行部４２００が実行されてもよい。またはキャッシュメモリ２１０上のダーティデータ量が所定量を超過した時点でライトアフタ処理実行部４２００が実行されてもよい。
ライトアフタ処理実行部４２００は、ホスト１１０から受け取ったライトデータまたは冗長データをフラッシュパッケージ２３０に書き込む処理を実行する。ただし、ライトアフタ処理実行部４２００は、ライトデータ、冗長データの両者を、フラッシュパッケージ２３０に書き込むべきデータとして、両者を区別せずに処理する。
ステップ７０００：ライトアフタ処理実行部４２００（プロセッサ２６０）は、キャッシュメモリ２１０をサーチして、フラッシュパッケージ２３０に書き込むべきデータを決める。ライトアフタ処理実行部４２００は、見出したデータに付与されている書き込み位置情報を取り出す。なお、ここではライトアフタ処理実行部４２００によって書き込まれる領域の範囲が、複数のフラッシュパッケージ２３０に跨らない場合の例を説明する。
ステップ７００１：ライトアフタ処理実行部４２００は書き込み位置情報に基づいて、しかるべきフラッシュパッケージ２３０にライト要求を発行する。なお、このときライトアフタ処理実行部４２００は、冗長データを書き込む場合には、このデータ（冗長データ）を重複排除の対象にしない旨の指示を出してもよい。
ステップ７００２：ライトアフタ処理実行部４２００は、ライト要求の完了をまつ。ライトアフタ処理実行部４２００は、フラッシュパッケージ２３０から当該ライト要求に関する終了報告が返却されると、処理を終了する。
図２６は、重複排除スケジュール部４３００の処理フローである。重複排除スケジュール部４３００はストレージシステム１００内の全フラッシュパッケージ２３０に蓄積された履歴情報３４００を取得し、重複排除処理をスケジュールする。本処理は、適当な間隔で実行されるものとする。
ステップ１２０００：重複排除スケジュール部４３００は、ストレージシステム１００内の各フラッシュパッケージ２３０に、履歴情報送信要求を発行し、各フラッシュパッケージ２３０から履歴情報３４００が送られてくるのをまつ。履歴情報送信要求を受領したフラッシュパッケージ２３０は、履歴情報３４００をストレージコントローラ（重複排除スケジュール部４３００）に返送する。フラッシュパッケージ２３０が行う処理は後述する。
ステップ１２００１：重複排除スケジュール部４３００は、それぞれのフラッシュパッケージ２３０から送られてきた履歴情報３４００を参照して、リスト１とリスト２を作成する。リスト１とリスト２については、以下で図２７を参照しながら説明する。
先に述べたとおり、履歴情報３４００には、ライトアドレス３４０２と更新前ハッシュ値３４０３と更新後ハッシュ値３４０４のセット（「ライト履歴」と呼ぶ）が１以上含まれている。図２７に示されているように、リスト１は、各ライト履歴から更新後ハッシュ値３４０４を除去することで生成されたレコードの集合である。そしてリスト２は、各ライト履歴から更新前ハッシュ値３４０３を除去することで生成されたレコードの集合である。
なお、同一の仮想セグメントに対し、複数回の更新が発生していることがある（履歴情報３４００に同一の仮想セグメントに対するライト履歴が複数個含まれていることがある）。重複排除スケジュール部４３００は、同一の仮想セグメントに対し複数回の更新が発生している場合（複数のライト履歴が存在する場合）、ライトアドレス３４０２が等しい複数のライト履歴のうち、最初の（最も古い）ライト履歴と、最後の（最も新しい）ライト履歴を取り出す。そして重複排除スケジュール部４３００は、前者から更新後ハッシュ値３４０４を除去することで生成されたレコードをリスト１に、後者から更新前ハッシュ値３４０３を除去することで生成されたレコードをリスト２に登録する。ただし、旧データのハッシュ値がヌル値である場合には、重複排除スケジュール部４３００はこの旧ハッシュ値と仮想セグメントのアドレスをリスト１に登録しない。
ステップ１２００２：ここでは重複排除スケジュール部４３００は、リスト１とリスト２内の情報を、ハッシュ値（更新前ハッシュ値３４０３または更新後ハッシュ値３４０４）に基づいて、各フラッシュパッケージ２３０に送信すべき情報に分割する。以下、分割されたリスト１内の情報のうち、フラッシュパッケージ＃ｆに送信する情報を「リスト１−ｆ」と呼び、リスト２内の情報のうち、フラッシュパッケージ＃ｆに送信する情報を「リスト２−ｆ」と呼ぶ。
情報の分割の仕方は以下の通りである。たとえばフラッシュパッケージ＃ｆが担当するハッシュ値の範囲がａ〜ｂの場合、リスト１のうち、（更新前）ハッシュ値３４０３がａ〜ｂの範囲に含まれるレコードを抽出したものを、フラッシュパッケージ＃ｆに送信すべき情報とし、リスト１−ｆとする。同様に、リスト２のうち、（更新後）ハッシュ値３４０４がａ〜ｂの範囲に含まれるレコードを抽出したものを、フラッシュパッケージ＃ｆに送信すべき情報とし、リスト２−ｆとする。
ステップ１２００３：重複排除スケジュール部４３００は、各フラッシュパッケージ２３０に重複排除判定要求を発行する。その時重複排除スケジュール部４３００は重複排除判定要求とともに、フラッシュパッケージ２３０ごとに分割したリスト１とのリスト２をフラッシュパッケージ２３０に送る（たとえばフラッシュパッケージ＃ｆにはリスト１−ｆとリスト２−ｆが送られる）。その後時重複排除スケジュール部４３００は、各フラッシュパッケージ２３０からの応答を待つ。
フラッシュパッケージ２３０（たとえばフラッシュパッケージ＃ｆ）は重複排除判定要求と共にリスト１−ｆを受領すると、リスト１−ｆに登録されている仮想セグメントアドレス３４０２ごとに、仮想セグメントアドレス３４０２で特定される仮想セグメントの旧データを消去するか否かを判定し、その結果をストレージコントローラ２００（重複排除スケジュール部４３００）に返送する。返送されてくる結果情報のことを「消去候補」と呼ぶ。
図２８に消去候補の例を示している。消去候補は、フラッシュパッケージ２３０に仮想セグメントの旧データの消去を指示する情報である。本実施例において、仮想セグメントの旧データの消去とは、仮想セグメントの旧仮想セグメントポインタ３２１０（または消去防止アドレス３２０８）の値を無効値（ＮＵＬＬ）にする処理を意味する。この処理により、旧仮想セグメントポインタ３２１０（または消去防止アドレス３２０８）でポイントされるセグメント（たとえば実セグメント）は、仮想セグメントに割り当てられていない状態になるので、実質的にその仮想セグメントの旧データが削除された状態になる。また、これまで仮想セグメントに割り当てられていた実セグメントは、フラッシュパッケージ２３０で実施されるガベージコレクション処理などによって、（その実セグメントを含む）実ブロックの消去が行われた後、別の用途に用いられる。この処理は公知のため、ここでの説明は略す。
消去候補は、仮想セグメントアドレス３６０１、ハッシュ値３６０２、消去Ｆｌａｇ３６０３から構成されるレコードのリストである。レコード内の消去Ｆｌａｇ３６０３が“１”の場合、そのレコードの仮想セグメントアドレス３６０１で特定される仮想セグメントの旧データを消去して良いことを意味する。レコード内の消去Ｆｌａｇ３６０３が“０”の場合、そのレコードの仮想セグメントアドレス３６０１で特定される仮想セグメントの旧データは消去してはいけないことを意味する。またハッシュ値３６０２は仮想セグメントアドレス３６０１で特定される仮想セグメントの旧データのハッシュ値である。
また、フラッシュパッケージ２３０（たとえばフラッシュパッケージ＃ｆ）は（重複排除判定要求と共に）リスト２−ｆを受領すると、リスト２−ｆに登録されている仮想セグメントアドレス３４０２ごとに、仮想セグメントアドレス３４０２で特定される仮想セグメントの更新データは重複排除処理可能か否かを判定し、その結果をストレージコントローラ２００（重複排除スケジュール部４３００）に返送する。返送されてくる結果情報のことを「重複候補」と呼ぶ。
なお本実施例において、「仮想セグメントの重複排除」または「仮想セグメントの更新データの重複排除」とは、ある仮想セグメント（対象セグメントと呼ぶ）の新仮想セグメントポインタ３２０５でポイントされる実セグメントに代えて、その実セグメントと同一のデータを有している仮想セグメントの仮想セグメントアドレスを、対象セグメントの新仮想セグメントポインタ３２０５に格納する処理のことを意味する。これにより、これまで対象セグメントに割り当てられていた（新仮想セグメントポインタ３２０５でポイントされていた）実セグメントは、実質的に削除されたことになる。
図２９に重複候補の例を示している。重複候補は、フラッシュパッケージ２３０に仮想セグメントの重複排除処理を指示する情報である。重複候補は、仮想セグメントアドレス３７０１、重複Ｆｌａｇ３７０２、重複Ａｄｄｒ３７０３から構成されるレコードのリストである。レコード内の重複Ｆｌａｇ３７０２が“１”の場合、そのレコードの仮想セグメントアドレス３７０１で特定される仮想セグメントの更新データは重複排除可能で、仮想セグメントアドレス３７０１で特定される領域のデータを削除してもよいことを意味する。またその場合、重複Ａｄｄｒ３７０３には、仮想セグメントアドレス３７０１で特定される仮想セグメントとハッシュ値が同じである仮想セグメントのアドレス（仮想セグメントアドレス）が格納されている。またレコード内の重複Ｆｌａｇ３７０２が“０”の場合、そのレコードの仮想セグメントアドレス３７０１で特定される仮想セグメントの更新データは重複排除処理可能でないことを意味する。
ステップ１２００４：重複排除スケジュール部４３００は、各フラッシュパッケージ２３０から受領した消去候補内の各レコードを、送信すべきフラッシュパッケージ２３０毎に分類する。この時の分類は、仮想セグメントアドレス３６０１に基づいて行われる。仮想セグメントアドレスにはフラッシュパッケージ２３０の識別子（パッケージＩＤ）が含まれている。仮想セグメントアドレス３６０１に含まれているパッケージＩＤが“ｆ”の場合、そのレコードをフラッシュパッケージ＃ｆに送信すると決定する。またフラッシュパッケージ＃ｆに送信すべきレコードのリストは、「消去候補−ｆ」と呼ぶ。
ステップ１２００５：重複排除スケジュール部４３００は、受領した重複候補内の各レコードを、送信すべきフラッシュパッケージ２３０毎に分類する。この分類はステップ１２００４で行われる分類と同様に、仮想セグメントアドレス３７０１に基づいて行われる。以下では重複候補内のレコードのうち、フラッシュパッケージ＃ｆに送信すべきレコードのリストは、「重複候補−ｆ」と呼ぶ。
ステップ１２００６：重複排除スケジュール部４３００は、各フラッシュパッケージ２３０に重複排除実行要求を発行する。その時重複排除スケジュール部４３００は重複排除実行要求とともに、ステップ１２００４とステップ１２００５で分類（作成）された重複候補と消去候補を、フラッシュパッケージ２３０に送り（たとえばフラッシュパッケージ＃ｆには重複候補−ｆと消去候補−ｆが送られる）、回答がかえってくるのを待つ。
つまりここではストレージコントローラ２００（重複排除スケジュール部４３００）は、各フラッシュパッケージ２３０から受領した重複候補と消去候補を、仮想セグメントアドレス（３６０１，３７０１）に基づいて、送信先のフラッシュパッケージへと転送している。言い換えるとフラッシュパッケージ２３０は、作成した重複候補と消去候補を、ストレージコントローラ２００を介して各フラッシュパッケージ２３０に送信しているものといえる。
フラッシュパッケージ２３０は、重複候補と消去候補が送信されると、消去Ｆｌａｇ３６０３が“１”のレコードに含まれる仮想セグメントアドレス３６０１で特定される仮想セグメントの旧データを消去し、また重複Ｆｌａｇ３７０２が“１”のレコードに含まれる仮想セグメントアドレス３６０１で特定される仮想セグメントについては、重複排除処理を実行する。この処理の詳細は後述する。
ステップ１２００７：重複排除スケジュール部４３００は、各フラッシュパッケージ２３０から回答がかえってくると、処理を完了する。
次に、フラッシュパッケージ２３０が実行する動作の説明を行う。フラッシュパッケージ２３０の動作は、パッケージプロセッサ３１０が実行し、そのプログラムは、パッケージメモリ３２０内に格納されている。
図３０は、パッケージメモリ３２０内に、格納された本実施例に関するプログラムが示されている。本実施例に関するプログラムは、データリード処理実行部１２６００、データライト処理実行部１２１００、履歴情報送信部１２２００、重複排除判定部１２３００、重複排除実行部１２４００、ハッシュ指定型リード実行部１２５００である。以下、それぞれのプログラムの処理フローを説明する。なお以下の各処理の説明においては、プログラム（データリード処理実行部１２６００等）を主語として、処理の説明を行っている箇所がある。ただしこれは実際には、プログラム（データリード処理実行部１２６００等）がパッケージプロセッサ３１０で実行されることで、処理が行われることを意味する。
図３１は、データリード処理実行部１２６００の処理フローである。データリード処理実行部１２６００は、ストレージコントローラ２００から、リード要求を受け取ったときに実行される。また、本処理は、重複排除判定部１２３００がリーフセグメント３５０１を読み出す際にも利用される。なお、本実施例で示す図３１の処理フローでは、一つの仮想ブロックグループに格納されたデータをリードする処理フローを示している。ただし、本発明は、リード要求で、複数の仮想ブロックグループに跨って格納されたデータを読み出すようにした場合も有効である。
また、本実施例に係るストレージコントローラ２００が発行するリード要求は２種類存在する。第１のリード要求では、リード対象領域（アドレスとデータ長とで特定される領域）が指定される。一方第２のリード要求では、リード対象領域に加えてハッシュ値が指定される。以下、第１のリード要求を「通常リード要求」と呼び、第２のリード要求を「ハッシュ指定型リード要求」と呼ぶ。図３１で説明される処理フローは、ストレージコントローラ２００から通常リード要求を受領した時に行われるものである。
ステップ１３０００：データリード処理実行部１２６００（パッケージプロセッサ３１０）は、受け取ったリード要求で指定されているリード対象アドレスから、リード対象領域が属する仮想ブロックグループと、アクセスする仮想ブロックグループ内の相対アドレスを計算する。リード対象アドレスがＬＢＡで表現されている場合、データリード処理実行部１２６００はリード対象アドレス×５１２÷（ｍ×フラッシュブロック容量３００４）を計算する。この計算で算出される商が仮想ブロックグループ番号で、剰余が仮想ブロックグループ内相対アドレスである。これによりデータリード処理実行部１２６００は、リード対象とする仮想ブロックグループ（仮想ブロックグループ情報３２００）を特定できる。
ステップ１３００１：当該ステップでデータリード処理実行部１２６００は、ステップ１３０００で求められた仮想ブロックグループ内の相対アドレスを相対仮想セグメント番号に変換し、さらにそれを用いてアクセス対象の仮想セグメントの新仮想セグメントポインタ３２０５を特定する。
ステップ１３００２：データリード処理実行部１２６００は、新仮想セグメントポインタ３２０５に格納されているアドレスが実セグメントアドレスか識別する。得られたアドレスが実セグメントアドレスである場合には（ステップ１３００２：Ｎｏ）、データリード処理実行部１２６００は次にステップ１３００３を実行する。そうでない場合（ステップ１３００２：Ｙｅｓ）、ステップ１３００８が実行される。
ステップ１３００３：先に述べたとおり、実セグメントアドレスには、データの格納された実ブロックの識別子とその実ブロック内の相対アドレス（相対セグメント番号）のセットが含まれている。データリード処理実行部１２６００は、実セグメントアドレスに含まれている情報により、アクセス対象領域が存在するフラッシュチップ３００と、そのフラッシュチップ３００内の位置（アドレス）を特定する。
ステップ１３００４：データリード処理実行部１２６００は、ステップ１３００３で特定されたフラッシュチップ３００のチップ情報３１００を参照することで、当該フラッシュチップ３００が接続されているパッケージバス３４０を識別し、対応するパッケージバス転送装置３５０を認識する。
ステップ１３００５：データリード処理実行部１２６００は、ステップ１３００４で認識したパッケージバス転送装置３５０に、フラッシュチップ３００からバッファ３３０にデータを転送するよう指示する。
ステップ１３００６：この後、データリード処理実行部１２６００は転送が完了するのを待つ。
ステップ１３００７：データリード処理実行部１２６００は、バッファ３３０に格納された、ストレージコントローラ２００から要求されたリードデータを、ストレージコントローラ２００に送り、処理を終了する。
ステップ１３００８：このステップが実行される場合、ステップ１３００１で特定された新仮想セグメントポインタ３２０５には仮想セグメントアドレスが格納されている。データリード処理実行部１２６００は新仮想セグメントポインタ３２０５の内容と、新ハッシュ値３２０６をストレージコントローラ２００に返送して、処理を完了する。
なお、新仮想セグメントポインタ３２０５に格納されている仮想セグメントアドレスをチェックした結果、その仮想セグメントアドレスが自フラッシュパッケージ（データリード処理実行部１２６００が実行されているフラッシュパッケージ２３０）内の仮想セグメントを指すアドレスであることもあり得る。その場合、リード対象データは自フラッシュパッケージ内にある。そのためこの場合には、データリード処理実行部１２６００は、新仮想セグメントポインタ３２０５の内容と、新ハッシュ値３２０６を返送する代わりに、フラッシュパッケージ２３０内に格納されているデータを探し出して、ストレージコントローラ２００に探し出したデータを返送してもよい。
図３２は、ハッシュ指定型リード実行部１２５００の処理フローである。この処理は、フラッシュパッケージ２３０がストレージコントローラ２００からハッシュ指定型リード要求を受領した時（ステップ５００９が実行された時）に行われる。先に述べたとおり、ハッシュ指定型リード要求には、アクセス対象領域の情報（アドレス）に加え、ハッシュ値が含まれる。なお、以下の説明では、ハッシュ指定型リード要求のことを「リード要求」と略記する。
ステップ１３５００：この処理は、ステップ１３０００と同じである。この処理により、ハッシュ指定型リード実行部１２５００はアクセス対象領域に対応する、仮想ブロックグループ内の相対仮想セグメント番号を特定する。ここでは仮に、特定された相対仮想セグメント番号が“ｓ”であった場合について説明する。また相対仮想セグメント番号が“ｓ”の仮想セグメントは、「仮想セグメント＃ｓ」と表記する。
ステップ１３５０１：ハッシュ指定型リード実行部１２５００は、受け取ったリード要求で指定されているハッシュ値を、仮想セグメント＃ｓの新ハッシュ値３２０６、旧ハッシュ値３２１１、消去防止ハッシュ値３２０９と照合する。リード要求で指定されているハッシュ値が新ハッシュ値３２０６と一致している場合、ハッシュ指定型リード実行部１２５００は仮想セグメント＃ｓの新仮想セグメントポインタ３２０５に格納されている情報（アドレス）を取得する。
もしリード要求で指定されているハッシュ値が旧ハッシュ値３２１１と一致している場合、ハッシュ指定型リード実行部１２５００は仮想セグメント＃ｓの旧仮想セグメントポインタ３２１０に格納されている情報（アドレス）を取得する。一方リード要求で指定されているハッシュ値が消去防止ハッシュ値３２０９と一致している場合、ハッシュ指定型リード実行部１２５００は仮想セグメント＃ｓの消去防止アドレス３２０８に格納されている情報（アドレス）を取得する。なお、仮想セグメント＃ｓに消去防止ハッシュ値３２０９と消去防止アドレス３２０８が複数設けられている場合、ハッシュ指定型リード実行部１２５００は、リード要求で指定されているハッシュ値を、それぞれの消去防止ハッシュ値３２０９と比較照合する。
ステップ１３５０３：ステップ１３５０１で取得されるアドレスは実セグメントアドレスである。データリード処理実行部１２６００は、ステップ１３５０１で得られた実セグメントアドレスから、リード対象データの格納されているフラッシュチップ３００の識別子及びそのフラッシュチップ３００内のアドレスを特定する。これはステップ１３００３と同様の処理である。
ステップ１３５０４：ステップ１３００４と同様の処理が行われる。
ステップ１３５０５：ステップ１３００５と同様の処理が行われる。
ステップ１３５０６：ステップ１３００６と同様の処理が行われる。
ステップ１３５０７：ステップ１３００７と同様の処理が行われる。 これにより、ストレージコントローラ２００にデータが返送される。
続いて図３３と図３４を用いて、データライト処理実行部１２１００の処理フローを説明する。データライト処理実行部１２１００は、ストレージコントローラ２００から、フラッシュパッケージ２３０が、ライト要求を受け付けたときに実行される。また、本処理フローは、重複排除判定部１２３００が、リーフセグメントの書き込みを行う場合にも実行される。
なお、本実施例で示す図３３と図３４の処理フローでは、ライト要求で指定される範囲が一つの仮想ブロックグループ内に含まれ、複数の仮想ブロックグループに跨らない場合の処理を示している。ただし、本発明は、複数の仮想ブロックグループに跨った領域に対するライト要求を受け付けた場合も有効である。
ステップ１４０００：データライト処理実行部１２１００（パッケージプロセッサ３１０）は、受け取ったライト要求がライト対象とするアドレスから、ライト対象領域が属する仮想ブロックグループとアクセスする仮想ブロックグループ内相対アドレスを計算する。これはステップ１３０００で行われる計算と同様である。またデータライト処理実行部１２１００は、ライト対象領域が属する仮想ブロックグループ内の相対アドレスを相対仮想セグメント番号に変換することで、ライト対象領域に対応する仮想セグメントを特定する。以下ではこの仮想セグメントを「ライト対象仮想セグメント」と呼ぶ。またここでは、ライト対象仮想セグメントの新仮想セグメントポインタ３２０５も特定される。
本実施例では、ストレージコントローラ２００からのライト要求で指定されるライト範囲が、仮想セグメント境界に一致している例を説明する。もちろん、本発明は、ストレージコントローラ２００からのライト要求で、仮想セグメントの一部のみを指定された場合にも有効である。なお、フラッシュ仮想セグメントの一部の領域が指定された場合、フラッシュパッケージ２３０は仮想セグメント全体をバッファ３３０等に読み出し、バッファ３３０上で指定された部分領域のみ更新し、更新された１仮想セグメント分のデータを仮想セグメントに対して書き込む。
ステップ１４００１：データライト処理実行部１２１００は、ストレージコントローラ２００から当該ライト要求で指定されたライトデータを受け取り、バッファ３３０に格納する。またデータライト処理実行部１２１００はハッシュ回路３７０を用いて、そのデータのハッシュ値を計算する。
ステップ１４００２：データライト処理実行部１２１００は、ライト対象となった仮想セグメントが属する仮想ブロックグループの仮想ブロックグループ情報３２００（以下、「対象仮想ブロックグループ情報」と呼ぶ）の中から、最初の実ブロック情報ポインタ３２０２を獲得する。そしてデータライト処理実行部１２１００は、この値がヌルかどうか、すなわち、実ブロックが割り当てられているかをチェックする。実ブロックが割り当てられていれば（ステップ１４００２：Ｎｏ）、データライト処理実行部１２１００は次にステップ１４００５を実行する。実ブロックが割り当てられていない場合（ステップ１４００２：Ｙｅｓ）は、次にステップ１４００３が実行される。
ステップ１４００３：データライト処理実行部１２１００は、ライト対象となった仮想セグメントが属する仮想ブロックグループに、空き状態にある実ブロックを割り当てる。なお、ここでは、割り当てる実ブロックは消去されていてデータは格納されていないものとする。
具体的にはデータライト処理実行部１２１００は、各チップ情報３１００のチップ内空き実ブロック数３１０３等を参照して、空き実ブロックを取得する対象のフラッシュチップ３００を決める。その後データライト処理実行部１２１００は、決定したフラッシュチップ３００の空き実ブロック情報ポインタ３６００を参照して、先頭の実ブロック情報３３００へのポインタを得る。そしてデータライト処理実行部１２１００は、得られたポインタを対象仮想ブロックグループ情報の最初の実ブロック情報ポインタ３２０２に格納する。これで、仮想ブロックグループに最初の実ブロックが割り当てられる。
なお、空き実ブロック情報ポインタ３６００は、次の実ブロック情報３３００（仮想ブロックグループに割り当てられた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２が示す実ブロック情報３３００）を示すように変更され、さらに、仮想ブロックに割り当てられた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２はヌルにされる。またデータライト処理実行部１２１００は、当該実ブロックに対応するチップ情報３１００のチップ内空き実ブロック数３１０３の数を減らす。そしてデータライト処理実行部１２１００は、割り当てた実ブロックに対応する実ブロック内空き容量３３０４を、実ブロックの容量にする。ここでは、割り当てた実ブロックの先頭から、データを書き込むことになる。
ステップ１４００４：データライト処理実行部１２１００は、割り当てられた実ブロックの先頭実セグメントの、実セグメントアドレスを生成する。具体的には実ブロックの識別子と実ブロック内の相対アドレス（ここでは相対アドレスは０になる）を組み合わせることで、実セグメントアドレスが生成できる。そしてデータライト処理実行部１２１００は、ライト対象仮想セグメントの新仮想セグメントポインタ３２０５に、生成された実セグメントアドレスをセットする。これによりライト対象仮想セグメントに実セグメントが割り当てられたことになる。またデータライト処理実行部１２１００は、ステップ１４００１で計算したハッシュ値を、ライト対象仮想セグメントの新ハッシュ値３２０６にセットする。さらにデータライト処理実行部１２１００は、ライト対象仮想セグメントの旧仮想セグメントポインタ３２１０と旧ハッシュ値３２１１をヌル値にする。またデータライト処理実行部１２１００は、データ格納量３２０３に０をセットする。この後、データライト処理実行部１２１００はステップ１４０１０を実行する。
ステップ１４００５：データライト処理実行部１２１００は、ライト対象となる実ブロックに対応する実ブロック情報３３００を特定する。これは仮想ブロックグループ情報３２００内の、有効な値（非ＮＵＬＬ値）が格納されている実ブロック情報ポインタ３２０２のうち、最後尾の実ブロック情報ポインタ３２０２でポイントされる実ブロック情報３３００である。データライト処理実行部１２１００は、特定された実ブロック情報３３００の実ブロック内空き容量３３０４とバッファ３３０に格納したライトデータの長さとから、受け取ったデータを、当該実ブロックの空き領域に書き込めるかをチェックする。書き込める場合（ステップ１４００５：Ｎｏ）、次にステップ１４００８が実行される。そうでない場合には、データライト処理実行部１２１００は次にステップ１４００６を実行する。
ステップ１４００６：本ステップは、書き込み対象とした実ブロックの空き領域より、ライトデータの長さが大きい場合に実行されるステップである。本ステップでは、データライト処理実行部１２１００は仮想ブロックグループに、ｍ＋１個の実ブロックが割り当てられているか判定する（仮想ブロックグループ情報３２００内のｍ＋１個の実ブロック情報ポインタ３２０２がすべて非ＮＵＬＬ値か判定する）。ｍ＋１個の実ブロックが割り当てられている場合、データライト処理実行部１２１００はステップ１４０１３を実行する。
ステップ１４００７：このステップは、対応する仮想ブロックグループに空き状態にある実ブロックを割り当てるステップで、ステップ１４００３と同様の処理が行われる。
ステップ１４００８：データライト処理実行部１２１００は、仮想ブロックグループ情報３２００内のライト対象仮想セグメントの旧仮想セグメントポインタ３２１０をチェックして、ヌル値であれば、ライト対象仮想セグメントの新仮想セグメントポインタ３２０５と新ハッシュ値３２０６をそれぞれ、旧仮想セグメントポインタ３２１０と旧ハッシュ値３２１１にコピーする（旧仮想セグメントポインタ３２１０がヌル値でない場合、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１への情報コピーは行われない）。なお、初めて当該仮想セグメントに対するライト要求を受け付けた場合、当該仮想セグメントの旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１はヌル値である。旧ハッシュ値３２１１がヌル値であるということは、そのハッシュ値が無効であることを意味する。
ステップ１４００９：データライト処理実行部１２１００は、:当該仮想ブロックグループに割り当てた実ブロックの中の最終の実ブロック（実ブロック情報ポインタ３２０２がヌル値でない最後の実ブロック情報ポインタ３２０２が示す実ブロック）を書き込み対象と決定する。またデータライト処理実行部１２１００は、ステップ１４００１で計算したハッシュ値を、ライト対象仮想セグメントの新ハッシュ値３２０６に設定する。
ステップ１４０１０：データライト処理実行部１２１００は、ライト対象仮想セグメントの新ハッシュ値３２０６と旧ハッシュ値３２１１と、ライト対象の仮想セグメントアドレスを履歴情報３４００に追加し、履歴情報数３４０１を１つ増やす。またデータライト処理実行部１２１００は、データ書き込み対象実ブロックの実ブロック内空き容量３３０４から、今回書き込みを行うアドレス（実セグメントアドレス。つまりチップＩＤ、ダイ番号、ブロック番号そして実ブロック内相対セグメント番号の組み合わせである）を決定する。データライト処理実行部１２１００は実ブロックの先頭の実セグメントから順にデータを書き込むため、実ブロック内空き容量３３０４と実ブロックのサイズが分かっていれば、今回書き込みを行うべき、実ブロック内相対アドレス（相対セグメント番号）は容易に決定される。データライト処理実行部１２１００はこのアドレスを、ライト対象仮想セグメントの新仮想セグメントポインタ３２０５に設定する。またデータライト処理実行部１２１００は、実セグメントビットマップ３３０５のうち、今回書き込み対象になった実セグメントに対応するビットをオンにする。
ステップ１４０１１：データライト処理実行部１２１００は、バッファ３３０内のライトデータを、ライト対象の実セグメントに書き込む要求を転送装置に設定して、書き込みが完了するのを待つ。
ステップ１４０１２：データライト処理実行部１２１００は、書き込み対象の実ブロックに対応する実ブロック内空き容量３３０４から、今回書き込みを行った実セグメントの合計サイズに相当する値を削減する。さらにデータライト処理実行部１２１００は、ライト対象とした仮想セグメントの容量を、データ格納量３２０３に加える。そしてデータライト処理実行部１２１００は、ストレージコントローラ２００に処理の完了を報告し、処理を完了する。
ステップ１４０１３：ここでは、仮想ブロックグループにこれまで割り当てられていた実ブロック内の有効データを、新たな空き実ブロックに移動する処理（いわゆるガベージコレクション処理）が行われる。具体的にはデータライト処理実行部１２１００は、仮想ブロックグループにこれまで割り当てられていた実ブロックの中で、有効な情報、すなわち、新仮想セグメントポインタ３２０５、旧仮想セグメントポインタ３２１０、消去防止アドレス３２０８でポイントされている実セグメントに格納されているデータだけを読み出し、読み出したデータを新たな空き実ブロックに書き込み、仮想ブロックグループ情報３２００を更新する。具体的にはデータライト処理実行部１２１００は、実ブロック情報ポインタ３２０２に、データが書き込まれた実ブロックの実ブロック情報３３００へのポインタを格納し、新仮想セグメントポインタ３２０５、旧仮想セグメントポインタ３２１０、消去防止アドレス３２０８には、データを書き込んだ実ブロック（の実セグメント）のアドレスを設定する。また、新たにデータが書き込まれた実ブロックの実ブロック情報３３００については、実ブロック内空き容量３３０４と実セグメントビットマップ３３０５の設定も行われる。なお、ここで新たに割り当てられる実ブロックは、ウェアレベリングアルゴリズム（各実ブロックの消去回数を均衡させるアルゴリズム）にしたがって、選択されるものとする。なお、ウェアレベリングは、公知の技術であるため、ここでは詳細に説明しない。また、これまで仮想ブロックグループに割り当てられていた実ブロックは、消去処理が行われ、空き実ブロックとして管理される。この後、ステップ１４００５が実行される。
図３５は、履歴情報送信部１２２００の処理フローである。履歴情報送信部１２２００は、ストレージコントローラ２００から履歴情報送信要求が送られた時（ステップ１２０００）に実行される。
ステップ１５０００：履歴情報送信部１２２００は履歴情報３４００を、ストレージコントローラ２００に送る。
ステップ１５００１：履歴情報送信部１２２００は履歴情報３４００を初期化する。具体的には履歴情報送信部１２２００は、パッケージメモリ３２０内の履歴情報３４００の格納されていた領域を０クリアする。この後、処理を終了する。
図３６は、重複排除実行部１２４００の処理フローである。重複排除実行部１２４００は、ストレージコントローラ２００から重複排除実行要求と、先に説明した消去候補と重複候補が送られてきたとき（ステップ１２００６）に実行される処理フローである（正確にはフラッシュパッケージ２３０には、ステップ１２００４、ステップ１２００５で分類された消去候補と重複候補が送られてくる。たとえばフラッシュパッケージ＃ｘは、消去候補ーｘと重複候補ーｘを受け取る。ただし以下の説明では、消去候補ーｘと重複候補ーｘのことをそれぞれ、「消去候補」、「重複候補」と呼ぶ）。
ステップ１６０００：重複排除実行部１２４００は、ストレージコントローラ２００から送られてきた消去候補のレコードを、消去Ｆｌａｇ３６０３が“１”のレコードと、“０”のレコードに分ける。
ステップ１６００１：本ステップでは、消去Ｆｌａｇ３６０３が“１”のレコードについての処理が行われる。以下、ステップ１６０００を実行した結果、消去Ｆｌａｇ３６０３が“１”のレコードが１つ存在した場合の例を説明する。なお、ステップ１６００１の説明において、このレコードの仮想セグメントアドレス３６０１で特定される仮想セグメントのことを、「対象仮想セグメント」と呼ぶ。
重複排除実行部１２４００はレコードの仮想セグメントアドレス３６０１から、対象仮想セグメントが属する仮想ブロックグループと、対象仮想セグメントの相対仮想セグメント番号を求める。以下では求められた相対仮想セグメント番号が“ｓ”の場合の例を説明する。
そして重複排除実行部１２４００は、特定された仮想ブロックグループの仮想ブロックグループ情報３２００を参照することで、対象仮想セグメントの旧ハッシュ値３２１１（３２１１−ｓ）と消去防止ハッシュ値３２０９（３２０９−ｓ）を読み出し、これらとハッシュ値３６０２を比較する。
ハッシュ値３６０２が旧ハッシュ値３２１１ーｓと一致した場合、重複排除実行部１２４００は旧仮想セグメントポインタ３２１０ーｓに格納されているアドレスが実セグメントアドレスか判定する。実セグメントアドレスである場合、重複排除実行部１２４００はデータ格納量３２０３から仮想セグメントのサイズを減算する。
また重複排除実行部１２４００は、旧仮想セグメントポインタ３２１０ーｓに格納されていたアドレス（具体的には実セグメントアドレスに含まれる実ブロック識別子）と実ブロック情報ポインタ３２０２を参照することで、旧データの格納されていた実セグメントを有する実ブロックの実ブロック情報３３００を特定する。そして重複排除実行部１２４００は、その実ブロック情報３３００の実セグメントビットマップ３３０５のうち、旧データが格納されていた実セグメントに対応するビットをオフする。旧仮想セグメントポインタ３２１０ーｓに格納されているアドレスが実セグメントアドレスでない場合には、これらの処理は行われない。
そして重複排除実行部１２４００は、旧仮想セグメントポインタ３２１０ーｓと旧ハッシュ値３２１１ーｓをヌルにする。これにより、仮想セグメントに割り当てられていた、旧データを格納（退避）していた領域（旧仮想セグメントポインタ３２１０ーｓでポイントされる実セグメント）が、実質的に削除されたことになる。
ハッシュ値３６０２が消去防止ハッシュ値３２０９ーｓと一致した場合、重複排除実行部１２４００は消去防止ハッシュ値３２０９ーｓと消去防止アドレス３２０８ーｓをヌルにし、消去防止仮想セグメント数３２０７ーｓを１減らす。これにより、仮想セグメントに割り当てられていた、旧データを格納（退避）していた領域（消去防止アドレス３２０８ーｓでポイントされる実セグメント）が、実質的に削除されたことになる。
また、重複排除実行部１２４００はデータ格納量３２０３から仮想セグメントのサイズを減算し、これまで消去防止アドレス３２０８ーｓにポイントされていた実セグメントに対応する実セグメントビットマップ３３０５のビットをオフする。これは、上で説明した旧仮想セグメントポインタ３２１０ーｓに対して行われる処理と同じである。
さらに重複排除実行部１２４００は、ヌルにした、消去防止ハッシュ値３２０９ーｓと消去防止アドレス３２０８ーｓより後ろに格納されている、消去防止ハッシュ値３２０９と消去防止アドレス３２０８を、ヌル値にした消去防止ハッシュ値３２０９と消去防止アドレス３２０８まで、前詰めする。
ステップ１６００２：本ステップでは、消去Ｆｌａｇ３６０３が“０”のレコードについての処理が行われる。以下ではステップ１６００１と同様、消去Ｆｌａｇ３６０３が“０”のレコードが１つであった場合の例を説明する。また、このレコードの仮想セグメントアドレス３６０１で特定される仮想セグメントのことを、「対象仮想セグメント」と呼ぶ。
重複排除実行部１２４００はレコードの仮想セグメントアドレス３６０１から、対象仮想セグメントが属する仮想ブロックグループと、対象仮想セグメントの相対仮想セグメント番号を求める。以下では求められた相対仮想セグメント番号が“ｓ”の場合の例を説明する。重複排除実行部１２４００は、特定された仮想ブロックグループの仮想ブロックグループ情報３２００の更新を行う。
具体的には重複排除実行部１２４００は、消去防止仮想セグメント数３２０７−ｓを１増やす。さらに重複排除実行部１２４００は、旧仮想セグメントポインタ３２１０と旧ハッシュ値３２１１を消去防止アドレス３２０８、消去防止ハッシュ値３２０９の領域にコピーする。さらに重複排除実行部１２４００は、旧仮想セグメントポインタ３２１０、旧ハッシュ値３２１１をヌルにする。
ステップ１６００３：ここでは、重複候補に関する処理が実行される。重複候補の中に、重複Ｆｌａｇ３７０２が“０”のレコードが含まれていた場合、そのレコードは無視される。重複Ｆｌａｇ３７０２が“１”のレコードが含まれていた場合、そのレコードの仮想セグメントアドレス３７０１で特定される仮想セグメントについては、重複排除処理が行われるべきである。以下、重複候補内に重複Ｆｌａｇ３７０２が“１”のレコードが１つ含まれていた場合の例を説明する。また、以下の例では、そのレコードの仮想セグメントアドレス３７０１で特定される仮想セグメント（対象仮想セグメントと呼ぶ）の相対仮想セグメント番号が“ｓ”の場合の例を説明する。
重複排除実行部１２４００は対象仮想セグメントが属する仮想ブロックグループの仮想ブロックグループ情報３２００を更新する。具体的には重複排除実行部１２４００は、新仮想セグメントポインタ３２０５ーｓを一度ヌルにし、データ格納量３２０３から仮想セグメントのサイズを削減する。また重複排除実行部１２４００は、ステップ１６００１の処理と同様な方法で、新仮想セグメントポインタ３２０５−ｓが指し示していた実セグメントに対応する実セグメントビットマップ３３０５をオフする。
さらに重複排除実行部１２４００は、新仮想セグメントポインタ３２０５ーｓに、重複Ａｄｄｒ３７０３の値をセットする。これにより新仮想セグメントポインタ３２０５ーｓは、ハッシュ値が同じ仮想セグメントを指すようになり、対象仮想セグメントの重複排除処理が行われた状態になる。なお、ハッシュ値が同じ仮想セグメントは、同一フラッシュパッケージ２３０内に存在することもあれば、別のフラッシュパッケージ２３０内に存在することもある。
ステップ１６００３が完了すると、重複排除実行部１２４００はストレージコントローラ２００に、処理が完了したことを通知して、終了する。なお、上では、各ステップで処理対象となる消去候補のレコード（あるいは重複候補のレコード）が１つの場合の例を説明したが、消去候補のレコード（あるいは重複候補のレコード）が複数ある場合には、各レコードについて上で説明した処理が行われる。
図３７は、重複排除判定部１２３００の処理フローである。重複排除判定部１２３００は、ストレージコントローラ２００から重複排除判定要求と、先に説明したリスト１とリスト２が送られた時（ステップ１２００３）に実行される処理フローである。重複排除判定部１２３００は、当該フラッシュパッケージ２３０が担当するハッシュ値に関するリストを受け取ることになる（たとえばフラッシュパッケージ＃ｘは、リスト１ーｘ、リスト２ーｘを受け取る）。
ステップ１７０００：本ステップでは、リスト１ーｘに関する処理が実行される。重複排除判定部１２３００はリスト１ーｘから、レコードを１つずつ読み出して、各レコードに格納された仮想セグメントアドレス３４０２と（更新前）ハッシュ値３４０３に基づいて、仮想セグメントの旧データの消去可否判定を行い、消去候補のレコードを作成する。
以下、リスト１ーｘ内のある１つのレコードが読み出された時に行われる処理の例を説明する。また以下では、読み出されたレコードの（更新前）ハッシュ値３４０３がＨであった場合の例を説明する。また、読み出されたレコードの仮想セグメントアドレス３４０２で特定される仮想セグメントのことを、「対象セグメント」と呼び、対象セグメントの仮想セグメントアドレス（つまり仮想セグメントアドレス３４０２）を「対象セグメントアドレス」と呼ぶ。
（更新前）ハッシュ値３４０３がＨであった場合、重複排除判定部１２３００は、ハッシュインデックス情報３５００を検索し、ハッシュ値Ｈの情報が格納されているリーフセグメント３５０１を特定し、バッファ３３０へ読みだす。この時重複排除判定部１２３００はデータリード処理実行部１２６００を呼び出すことで、リーフセグメント３５０１の格納されている仮想セグメントの読み出しを行う。
続いて重複排除判定部１２３００は、読み出したリーフセグメント３５０１から、登録ハッシュ値３５０２がＨであるエントリ３５１０を特定する。さらに重複排除判定部１２３００は、そのエントリ３５１０の中に、対象セグメントアドレスと等しい値の登録アドレス３５０５が存在するか判定し、判定結果によって異なる処理を行う。
まず、対象セグメントアドレスの値と等しい登録アドレス３５０５が存在する場合について説明する。この場合、存在した登録アドレス３５０５が、エントリ３５１０内の先頭の登録アドレス３５０５であるケースと、そうでないケースがあり得る。
対象セグメントアドレスの値と等しい登録アドレス３５０５が、エントリ３５１０内の先頭の登録アドレス３５０５でない場合、対象セグメントの旧データは消去してもよい。エントリ３５１０内の２番目以降の登録アドレス３５０５には、重複排除処理が行われていない仮想セグメントのアドレスが格納されているから（１番目の登録アドレス３５０５と同一ストライプラインに属する仮想セグメントの仮想セグメントアドレスが格納されている）、この仮想セグメントの旧データは削除されても問題が発生しない。
そのためこの時には、重複排除判定部１２３００は、消去候補のレコードとして、仮想セグメントアドレス３６０１に対象セグメントアドレスが格納され、ハッシュ値３６０２にＨ、消去Ｆｌａｇ３６０３に１が格納されたレコードを作成する。また重複排除判定部１２３００は、対象セグメントアドレスの値と等しい登録アドレス３５０５に対応する無効フラグ３５０６をオンにする。同時に登録アドレス３５０５にＮＵＬＬが格納されるようにしてもよい。また重複排除判定部１２３００は、セグメント数３５０４を１削減する。
なお、ここで行われるエントリ３５１０の編集（セグメント数３５０４等の更新など）は、バッファ３３０上に読み出されたエントリ３５１０の内容に対して行われるものである。
一方、エントリ３５１０の先頭の登録アドレス３５０５が、対象セグメントアドレスの値と等しかった場合、対象セグメントの旧データは消去して良い場合とそうでない場合があり得る。登録データ数３５０３が１の場合、対象セグメントアドレス（または先頭の登録アドレス３５０５）で特定される仮想セグメント以外に、ハッシュ値Ｈを持つ仮想セグメントは存在しないことを意味する。そのためこの場合、対象セグメントの旧データは消去されて良い。また登録データ数３５０３が１でもセグメント数３５０４が２以上の値である場合、ハッシュ値Ｈを持つ仮想セグメントは複数存在する。ただしこの場合、ハッシュ値Ｈを持つ仮想セグメントはいずれも、あるフラッシュパッケージグループ２８０内の同一ストライプラインに存在する。同一ストライプラインに属する仮想セグメントは重複排除処理が行われていないので消去してもよい。一方、登録データ数３５０３が２以上の場合、対象セグメントを参照している仮想セグメントが存在する（重複排除されている）ことを意味する。その場合、対象セグメントの旧データは消去されるべきでない。
そのため、登録データ数３５０３が１の場合、重複排除判定部１２３００は消去候補のレコードとして、仮想セグメントアドレス３６０１に対象セグメントアドレスが格納され、ハッシュ値３６０２にＨ、消去Ｆｌａｇ３６０３に１が格納されたレコードを作成する。さらに重複排除判定部１２３００は、リーフセグメント３５０１から登録ハッシュ値３５０２がＨであるエントリ３５１０を削除する。これは、ハッシュ値Ｈをもつ仮想セグメントで、かつ重複排除処理対象となる仮想セグメントが無くなったからである。
登録データ数３５０３が２以上の場合には、重複排除判定部１２３００は消去候補のレコードとして、仮想セグメントアドレス３６０１に対象セグメントアドレスが格納され、ハッシュ値３６０２にＨ、消去Ｆｌａｇ３６０３に０が格納されたレコードを作成する（つまり対象セグメントの消去を行わせない）。またこの時、重複排除判定部１２３００はエントリ３５１０の内容変更は行わない。
続いて、エントリ３５１０内に、対象セグメントアドレスの値と等しい登録アドレス３５０５が存在しない場合について説明する。この場合、対象セグメントは、エントリ３５１０の先頭の登録アドレス３５０５で特定される仮想セグメントを参照している仮想セグメントである。逆に対象セグメントは他の仮想セグメントから参照されているわけではないので、対象セグメントの旧データは消去されてよい。そのため、重複排除判定部１２３００は消去候補のレコードとして、仮想セグメントアドレス３６０１に対象セグメントアドレスが格納され、ハッシュ値３６０２にＨ、消去Ｆｌａｇ３６０３に１が格納されたレコードを作成する。さらに重複排除判定部１２３００は、登録データ数３５０３を１削減する。ここで行われる登録データ数３５０３の更新も、バッファ３３０上に読み出されたエントリ３５１０の内容に対して行われるものである。
以上のような処理がリスト１内の全レコードについて行われる。リスト１内の全レコードについて、上で述べた処理が行われた後、重複排除判定部１２３００は、バッファ３３０上で編集（更新）されたリーフセグメント３５０１の書き込みを行う。その際重複排除判定部１２３００は、図３３と図３４に示したデータライト処理実行部１２１００を呼び出すことで書き込みを実行する。データライト処理実行部１２１００の説明から分かる通り、仮想セグメントに対する書き込みを行うと、書き込みデータは、仮想セグメントに割り当てられている実セグメントとは異なる実セグメント（空き実セグメント）に書き込まれることになる。
ステップ１７００１：本ステップでは、リスト２に関する処理が実行される。重複排除判定部１２３００はリスト２ーｘからレコードを１つずつ読み出して、各レコードに格納された仮想セグメントアドレス３４０２と（更新後）ハッシュ値３４０４に基づいて、重複排除の判定を行い、重複候補のレコードを作成する。以下、リスト２ーｘ内のある１つのレコードが読み出された時に行われる処理の例を説明する。ステップ１７０００の説明の場合と同様、以下では読み出されたレコードの（更新後）ハッシュ値３４０４がＨであった場合の例を説明する。また、読み出されたレコードの仮想セグメントアドレス３４０２で特定される仮想セグメントのことを、「対象セグメント」と呼び、対象セグメントの仮想セグメントアドレス（つまり仮想セグメントアドレス３４０２）を「対象セグメントアドレス」と呼ぶ。
（更新後）ハッシュ値３４０４がＨであった場合、重複排除判定部１２３００は、ハッシュインデックス情報３５００を検索し、ハッシュ値Ｈの情報が格納されている可能性があるリーフセグメント３５０１を特定し、バッファ３３０へ読み出す。ステップ１７０００と同様、この時重複排除判定部１２３００はデータリード処理実行部１２６００を呼び出すことで、リーフセグメント３５０１の読み出しを行う。
続いて重複排除判定部１２３００は、読み出したリーフセグメント３５０１内に、登録ハッシュ値３５０２がＨであるエントリ３５１０があるか判定する。該当するエントリ３５１０が見つからない場合、重複排除ができない（重複データが存在しないことを意味する）。この場合には重複排除判定部１２３００は、重複候補のレコードとして、仮想セグメントアドレス３７０１に対象セグメントアドレスが格納され、重複Ｆｌａｇ３７０２に０、重複Ａｄｄｒ３７０３にＮＵＬＬが格納されたレコードを作成する。また重複排除判定部１２３００は、バッファ３３０上に読み出されたリーフセグメント３５０１内に、ハッシュ値Ｈと仮想セグメントアドレスを記録する。具体的には重複排除判定部１２３００は、登録ハッシュ値３５０２にＨが格納されたエントリ３５１０を新たに作成する。また重複排除判定部１２３００は、登録データ数３５０３とセグメント数を１にし、エントリ３５１０内の先頭の登録アドレス３５０５に、対象セグメントアドレスをセットし、無効フラグ３５０６をオフにする。
登録ハッシュ値３５０２がＨであるエントリ３５１０がある場合、重複排除できる可能性がある。この場合重複排除判定部１２３００は、エントリ３５１０内の先頭の登録アドレス３５０５に記録されている仮想セグメントアドレスと対象セグメントアドレスを比較して、両者が同一のストライプラインに属しているか判定する。この判定の際にフラッシュパッケージグループ情報２３００が用いられる。
具体的には、登録アドレス３５０５に記録されている仮想セグメントアドレスと対象セグメントアドレスに含まれているパッケージＩＤが、いずれも同一フラッシュパッケージグループ２８０内のフラッシュパッケージ２３０のもので、かつ登録アドレス３５０５に記録されている仮想セグメントアドレスと対象セグメントアドレスに含まれている内部仮想セグメント番号が等しい場合、両者は同一のストライプラインに属していると判断できる。
両者が同一のストライプラインに属する場合、重複排除判定部１２３００は対象セグメントの重複排除処理は行わないと決定する。そのため重複排除判定部１２３００は重複候補のレコードとして、仮想セグメントアドレス３７０１に対象セグメントアドレスが格納され、重複Ｆｌａｇ３７０２に０、重複Ａｄｄｒ３７０３にＮＵＬＬが格納されたレコードを作成する。さらに重複排除判定部１２３００は、バッファ３３０上に読み出されたリーフセグメント３５０１内のエントリ３５１０の更新を行う。具体的には重複排除判定部１２３００は、セグメント数３５０４の値を１加算し、またエントリ内に登録アドレス３５０５と無効フラグ３５０６のセットを追加し、追加されたセット内の新しい登録アドレス３５０５に対象セグメントアドレスをセットし、無効フラグ３５０６をオフにする。
両者が同一のストライプラインに属さない場合、対象セグメントは重複排除されてよい。重複排除判定部１２３００は、重複候補のレコードとして、仮想セグメントアドレス３７０１に対象セグメントアドレスが格納され、重複Ｆｌａｇ３７０２に１、重複Ａｄｄｒ３７０３にエントリ３５１０内の先頭の登録アドレス３５０５の内容が格納されたレコードを作成する。また重複排除判定部１２３００は、エントリ３５１０内の登録データ数３５０３を一つ増やす。
以上のような処理がリスト２内の全レコードについて行われる。その後重複排除判定部１２３００は、バッファ３３０上で編集（更新）されたリーフセグメント３５０１の書き込みを行う。ステップ１７０００で説明したとおり、重複排除判定部１２３００は、図３３と図３４に示したデータライト処理実行部１２１００を呼び出すことで書き込みを実行する。
ステップ１７００２：重複排除判定部１２３００は、ステップ１７０００、ステップ１７００１で作成された消去候補と重複候補のリストをストレージコントローラ２００に返却し、その後、処理を完了する。
以上が重複排除判定部１２３００の処理である。なお、上では、ステップ１７０００の完了後、バッファ３３０上で編集（更新）されたリーフセグメント３５０１の書き込み（実セグメントへの書き込み）が行われ、さらにステップ１７００１の完了後にバッファ３３０上で編集（更新）されたリーフセグメント３５０１の書き込みが行われる例を説明した。ただしステップ１７０００とステップ１７００１で処理（参照または更新）対象となるリーフセグメント３５０１には同じものが含まれていることもある。そのため重複排除判定部１２３００は、リーフセグメント３５０１の実セグメントへの書き込みを、ステップ１７０００の完了時点では行わず、ステップ１７００１でまとめて行ってもよい。
以上で本実施例に係るストレージシステムの説明を終える。本実施例に係るストレージシステムでは、フラッシュパッケージ間のデータの重複排除を実行できるので、重複排除の効率が良い。また原則として、フラッシュパッケージが重複排除処理を実行するので、ストレージコントローラが性能上のボトルネックになることがないという利点がある。
また本実施例に係るストレージシステムでは、重複排除処理のためにストレージコントローラとフラッシュパッケージとの間でやり取りされる情報は、ハッシュ値と対応するデータアドレスのみである。そして、ストレージコントローラは複数のハッシュ値及びデータアドレスを１回のコマンドで転送することで、ストレージコントローラからのフラッシュパッケージへのアクセス回数を削減する。
また、重複排除処理を行うストレージシステムでは、上で述べた実施例に係るストレージシステムのハッシュインデックスのように、データのハッシュ値と、そのハッシュ値を持つデータが格納された領域の情報（以下、インデックスと呼ぶ）を記憶しておく必要がある。これらの情報は膨大になるため、ＤＲＡＭ等の高価な記憶媒体に格納すると、記憶デバイスのビットコストが高くなる。そのため本実施例に係るストレージシステムでは、これらの情報をフラッシュパッケージのフラッシュメモリに格納している。
インデックスは、ホストからのデータライト（更新）が発生するたびに変更される。そのため、インデックスを特定のフラッシュパッケージに集約して格納すると、そのフラッシュパッケージの更新数が膨大になるため、性能の隘路になり易く、フラッシュメモリの寿命も短くなる。
上で説明した実施例に係るストレージシステムでは、インデックスを複数のフラッシュパッケージに分散して格納し、分散格納されたインデックスはそれぞれのフラッシュパッケージで管理（参照または更新）される。そのためインデックスに係る処理が特定のコントローラ（またはフラッシュパッケージ）に集中することがない。また、インデックスの書き込まれるフラッシュメモリ上の領域（セグメント）も、ウェアレベリング処理の対象として管理されるため、インデックスの書き込まれるセグメントとデータの書き込まれるセグメントとで、消去回数に偏りが出ないように制御される。
また、インデックスの更新処理にかかるオーバヘッドは大きい。データが更新された場合、通常は、ハッシュ値も異なった値（旧ハッシュ値から新ハッシュ値）に変更される。このためデータが１回更新されると、インデックスに対して、１）当該データがもつハッシュ値を新ハッシュ値に更新する、２）新ハッシュ値をもつデータの集合に当該データのアドレスを付加する、３）旧ハッシュ値をもつデータの集合から当該データのアドレスを削除する、という３回の更新が発生する。ストレージコントローラでこの更新を行おうとすると、これらの情報を読み出すためのフラッシュメモリアクセスが３回、書き込むためのフラッシュメモリアクセスが３回発生するので、大きなオーバヘッドになる。
上で説明した実施例に係るストレージシステムでは、ストレージコントローラとフラッシュパッケージ間で、重複排除処理で用いられるライト処理履歴及びライトデータのハッシュ値の転送を行う際、複数回のライト処理履歴及びハッシュ値をまとめて転送する。そのため情報転送のオーバヘッドを小さくすることができる。
続いて実施例２の説明を行う。実施例２における情報システムのハードウェア構成は、実施例１における情報システム（図１）と同様である。また以下の説明では、実施例１に係る情報システムの構成物と同じ物を特定する際、実施例１で用いた参照番号を用いる。
実施例１に係るストレージシステムと実施例２に係るストレージシステムとでは、主に以下の違いがある。実施例１に係るフラッシュパッケージは、重複排除の可否を判定するプログラム（重複排除判定部１２３００）を有し、重複排除判定部１２３００を実行することで、ストレージコントローラ２００から送られてくる情報（リスト１、リスト２）をもとに、重複排除可否の判定等を行っていた。一方、実施例２に係るストレージシステムでは、ストレージコントローラ２００が、実施例１で説明した重複排除判定部１２３００と同様の処理を行うプログラム（実施例２では、これを「重複排除判定部１２３００’」と呼ぶ）を有する。そしてストレージコントローラ２００が重複排除判定部１２３００’を実行することで、重複排除可否の判定等を行う。逆に実施例２に係るフラッシュパッケージは、重複排除判定部１２３００を有さない。
続いて、実施例１に係るストレージシステムの有する管理情報と、実施例２に係るストレージシステムが有する管理情報の違いについて説明する。実施例２に係るフラッシュパッケージ２３０は、実施例１に係るフラッシュパッケージと異なり、ハッシュインデックス情報３５００を持たない。代わりに実施例２に係るストレージシステムでは、ストレージコントローラ２００がハッシュインデックス情報３５００を管理し、ハッシュインデックス情報３５００は共有メモリ２２０上に格納される。そのため、実施例２に係るフラッシュパッケージ２３０は、必ずしもフラッシュボリュームに隠し領域を設ける必要はない。
実施例２において、ストレージコントローラ２００が有するハッシュインデックス情報３５００のフォーマットは、実施例１で説明したものと同じである。ただし、実施例２に係るハッシュインデックス情報３５００では、リーフセグメント３５０１へのポインタであるリーフアドレス３５０７には、リーフセグメント３５０１が格納されている共有メモリ２２０上アドレスが用いられる点が、実施例１におけるハッシュインデックス情報と異なる（実施例１におけるハッシュインデックス情報では、リーフアドレスに仮想セグメントアドレスが用いられた）。
また実施例２に係るフラッシュパッケージ２３０は、フラッシュパッケージグループ情報２３００とハッシュ値格納情報２４００を持っていなくて良い。一方実施例２に係るストレージコントローラ２００は、実施例１と同様にフラッシュパッケージグループ情報２３００を有するが、ハッシュ値格納情報２４００を有する必要はない。
実施例２に係るストレージシステムでは、ストレージコントローラ２００がハッシュインデックス情報３５００の参照・更新を行う。なお、実施例１に係るストレージシステムでは、各フラッシュパッケージ２３０がハッシュインデックス情報３５００を有していたため、ストレージシステム内にはフラッシュパッケージ２３０と同数のハッシュインデックス情報３５００が存在していた。一方実施例２に係るストレージシステムでは、ストレージコントローラ２００が１つのハッシュインデックス情報３５００を有するだけで良い。また、実施例２においては、ハッシュインデックス情報３５００が共有メモリ２２０に格納されている例を説明するが、共有メモリ２２０に代えてキャッシュメモリ２１０にハッシュインデックス情報３５００が格納されていてもよい。あるいは実施例２に係るストレージシステムでは、ハッシュインデックス情報３５００が、フラッシュパッケージ２３０やＨＤＤ等の記憶デバイスが有する記憶領域に格納されるように構成されていてもよい。
次に、実施例２に係るストレージコントローラ２００が実行する処理の説明を行う。なお、先に述べたとおり、実施例２に係るフラッシュパッケージは、重複排除判定部１２３００を有さず、重複排除判定部１２３００を実行しない点だけが、実施例１におけるフラッシュパッケージと異なる。そのため、実施例２に係るフラッシュパッケージが実行する処理の説明は略す。
実施例２に係るストレージコントローラ２００はそのメモリ２７０内に、少なくともリード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００、重複排除スケジュール部４３００’、重複排除判定部１２３００’というプログラムを有する（図示は略す）。リード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００はいずれも、実施例１で説明したものと同じプログラムである。つまり、ホスト１１０からライト要求またはリード要求を受け付けた時に実施例２に係るストレージシステム１００で行われる処理は、実施例１で説明したものと同じである。
重複排除スケジュール部４３００’は、実施例１で説明した重複排除スケジュール部４３００と類似したプログラムだが、若干の相違点がある。以下ではこの相違点を主に説明する。図３８を用いて、重複排除スケジュール部４３００’が行う処理の流れを説明する。
ステップ１２０００とステップ１２００１は、実施例１で説明したもの（図２６のステップ１２０００〜ステップ１２００１）と同じ処理である。そのためここでの説明は略す。ステップ１２００１が完了した後、重複排除スケジュール部４３００’は次にステップ１２００３’を実行する。
ステップ１２００３’：このステップは、実施例１で説明したステップ１２００３に代わる処理である。ステップ１２００３’では重複排除スケジュール部４３００’は、ステップ１２００１で作成されたリスト１、リスト２を用いて、重複排除可否の判定を行う。この時、重複排除スケジュール部４３００’は重複排除判定部１２３００’をコールすることで、重複排除可否の判定を行う。重複排除判定部１２３００’は実施例１で説明した重複排除判定部１２３００と同様の処理を行うことにより、旧データ（更新前データ）の消去可否の判定、更新データの重複排除可否の判定を行い、消去候補と重複候補（実施例１で説明したものと同様のもの）を出力する。
ステップ１２００３’の後、重複排除スケジュール部４３００’はステップ１２００４〜ステップ１２００７を実行する。ステップ１２００４〜ステップ１２００７は、実施例１で説明したステップ１２００４〜ステップ１２００７と同じ処理であるため、ここでの説明は略す。
続いて、重複排除判定部１２３００’の処理の流れの説明を行う。実施例１で説明した重複排除判定部１２３００と、実施例２における重複排除判定部１２３００’との主な違いは、重複排除判定部１２３００’はストレージコントローラ２００のプロセッサ２６０で実行されることである。また重複排除判定部１２３００’の処理の流れは、実施例１で説明した重複排除判定部１２３００の処理の流れと同様のため、ここではフローチャートの図示は略し、実施例１で用いた図３７を参照しながら説明する。また以下の説明では、重複排除判定部１２３００’の処理のうち、実施例１で説明した重複排除判定部１２３００の処理と異なる点を主に説明する。
重複排除判定部１２３００’は、重複排除スケジュール部４３００’から呼び出されたことを契機に、処理を開始する。この時重複排除判定部１２３００’は重複排除スケジュール部４３００’からリスト１とリスト２を受領する。実施例１では重複排除スケジュール部４３００がリスト１とリスト２を（ハッシュ値に基づいて）分割し、分割されたリスト１及びリスト２を、フラッシュパッケージ２３０の重複排除判定部１２３００に送信していた。実施例２に係る重複排除スケジュール部４３００はリスト１とリスト２の分割を行わない。そのため、この時重複排除判定部１２３００’は、重複排除スケジュール部４３００’から分割されてないリスト１とリスト２を受領する。
重複排除判定部１２３００’がリスト１とリスト２を受領した後に行う処理、特に図３７のステップ１７０００及びステップ１７００１は、実施例１で説明したものと殆ど同様である。なおステップ１７０００及びステップ１７００１では、ハッシュインデックス情報３５００の更新が行われることがあるが、実施例２においては、ハッシュインデックス情報３５００が共有メモリ２２０上に格納されているため、実施例１における重複排除判定部１２３００のように、仮想セグメント（に割り当てられた実セグメント）からリーフセグメント３５０１の内容をバッファに読み出して、バッファ上で更新された内容を仮想セグメントに書き出す等の処理が不要である点が、実施例１で説明したものと異なる。
ステップ１７０００及びステップ１７００１が実行された結果、消去候補と重複候補が生成される。実施例１における重複排除判定部１２３００は、ステップ１７００１の終了後、消去候補と重複候補を（フラッシュパッケージ２３０から）ストレージコントローラ２００に返却したが、実施例２における重複排除判定部１２３００’は、生成された消去候補と重複候補を、呼び出し元のプログラム（重複排除スケジュール部４３００’）に送信する。その後重複排除判定部１２３００’は処理を終了する。
実施例２に係るストレージシステムは以上の処理を行うことにより、実施例１に係るストレージシステムと同様に、重複排除処理を行うことができる。
図３９は、実施例３に係る情報システムのハードウェア構成を示している。実施例３に係る情報システムは、複数の実ストレージシステム（１００−１，１００−２，．．．）と、１以上のホスト１１０と、両者を接続するＳＡＮ１２０を有している。それぞれの実ストレージシステム（１００−１，１００−２，．．．）のハードウェア構成は、実施例１または２で説明したストレージシステム１００と同じで、一つ以上のストレージコントローラ２００、キャッシュメモリ２１０、共有メモリ２２０、フラッシュパッケージ２３０、そしてこれらの構成要素を接続する一つ以上の接続装置２５０、とを有する（図３９では、これらの構成要素の図示は略している）。以下では、各実ストレージシステム（１００−１，１００−２，．．．）を総称する場合、「実ストレージシステム１００」と表記する。
また図３９において、実ストレージシステム１００の有する要素１９０は、実ストレージシステム１００をＳＡＮ１２０に接続するための通信インターフェイスである。本実施例ではこれを「ポート」と呼ぶ。各実ストレージシステム１００は、ポート１９０を１以上有する。ポート１９０は、実ストレージシステム１００が、ホスト１１０や他の実ストレージシステム１００との間でデータの送受信を行うために用いられる。
実施例３に係る実ストレージシステム１００は、実ストレージシステム１００同士でデータや要求の送受信を行うことがあり、その時に実ストレージシステム１００はポート１９０を介してデータや要求の送受信を行う。なお、実施例１または実施例２に係るストレージシステムもポートを有するが、実施例１または２ではポートの説明は略している。
また、実施例３に係る情報システムはストレージ管理サーバ１８０を有し、ストレージ管理サーバ１８０はＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）１３０を介して各実ストレージシステム１００に接続されている。
実施例３に係る実ストレージシステム１００は、実施例１に係るストレージシステム１００の有する機能と同じ機能を有する。そのため、実施例１で説明したように、実ストレージシステム１００は１以上の論理ボリュームを定義して、ホスト１１０等に提供する。そして実ストレージシステム１００が各論理ボリュームの記憶空間を複数の仮想ページに分割して管理する点、フラッシュパッケージグループ２８０の領域から実ページが形成され、実ページが仮想ページに割り当てられる点も、実施例１と同じである。
さらに実施例３に係る実ストレージシステム１００は、実施例１に係るストレージシステム１００の有する機能の他、それぞれの実ストレージシステム１００が有する記憶領域を互いに使用する（共有する）機能を有する。そのため実施例３では、互いに記憶領域を使用可能な実ストレージシステム１００の集合を「仮想ストレージシステム１０００」と呼ぶ。
仮想ストレージシステム１０００はたとえば情報システムのユーザ（管理者）によって定義されるとよい。管理者が、１つの仮想ストレージシステム１０００に属する実ストレージシステム１００のセットを決定すると、ストレージ管理サーバ１８０を用いて、各実ストレージシステム１００に対して、１つの仮想ストレージシステム１０００に属するべき実ストレージシステム１００の識別番号（たとえば製造番号等）のセットを通知する、各実ストレージシステム１００はこの情報を受領することで、仮想ストレージシステム１０００に属する各実ストレージシステム１００を認識できる。
各実ストレージシステム１００が互いに記憶領域を共有する構成の一つの例は、複数の実ストレージシステム１００を跨って重複排除が行われる構成である。以下では、複数の実ストレージシステム１００を跨って重複排除が行われる構成の例を、実施例１でも用いられた図１８を参照しながら説明する。なお、図１８に記載のフラッシュパッケージ２３０−Ａが実ストレージシステム１００−１に搭載されているもので、一方実ストレージシステム１００−２はフラッシュパッケージ２３０−Ｂを搭載している前提で説明する。
フラッシュパッケージ２３０−Ｂの仮想セグメント＃ｙに、フラッシュパッケージ２３０−Ａの仮想セグメント＃ｘに書き込まれていたデータと同じデータが書き込まれたケースを想定する。その場合、フラッシュパッケージ２３０−Ｂの仮想セグメント＃ｙには、一旦はフラッシュパッケージ２３０−Ｂ内の実セグメントが割り当てられて、書き込まれたデータは割り当てられた実セグメントに格納される。
その後行われる重複排除処理において、フラッシュパッケージ２３０ーＢは、仮想セグメント＃ｙの新仮想セグメントポインタ（３２０５）に、フラッシュパッケージ２３０−Ａの仮想セグメント＃ｘの仮想セグメントアドレスを格納することで、仮想セグメント＃ｙが仮想セグメント＃ｘを参照するようにする。そして、それまで仮想セグメント＃ｙに割り当てられていた実セグメントは、仮想セグメント＃ｙに割り当てられなくなる（ただし実施例１で説明したように、仮想ストレージシステム１０００内に、仮想セグメント＃ｙを参照する他の仮想セグメントがあった場合には、実セグメントのアドレスは仮想セグメント＃ｙの消去防止アドレス３２０８（または旧仮想セグメントポインタ３２１０）に退避され、実セグメントが仮想セグメント＃ｙに割り当てられた状態が維持される）。
その後、ホスト１１０が仮想セグメント＃ｙをリード対象範囲に含むリード要求を発行すると、仮想セグメント＃ｘを有するフラッシュパッケージ２３０−Ａからデータが読み出されて、ホスト１１０に返送される。この処理は後述する。このように、実施例３に係る仮想ストレージシステム１０００では複数の実ストレージシステム１００に跨った重複排除が行われるため、実施例１または２に係るストレージシステムよりも、データ量削減の効果が大きくなることが期待できる。
また、各実ストレージシステム１００が互いに記憶領域を共有する別の例として、各実ストレージシステム１００が実ページを共有する構成もありえる。たとえば実ストレージシステム１００−１は、実ストレージシステム１００−１が定義した論理ボリュームの仮想ページに、実ストレージシステム１００−２が有する実ページを割り当て、ホスト１１０から、実ストレージシステム１００−１が定義した論理ボリュームの仮想ページに対するライトデータを受領した時、そのライトデータを実ストレージシステム１００−２が有する実ページに格納する機能を有していてもよい。ただしこの機能は、重複排除処理とは直接の関係がないため、本明細書ではこの機能の説明を略す。また以下の説明においても、実ストレージシステム１００はこの機能を有していないことを前提として、説明を行う。
続いて、実施例３に係る実ストレージシステム１００が有する管理情報について説明する。まず実ストレージシステム１００は共有メモリ２２０上に、少なくとも実施例１で説明した管理情報（図５に示された管理情報）を保持する。これに加えて実ストレージシステム１００は、仮想ストレージシステム１０００内の各実ストレージシステム１００についての情報（後述するストレージシステム情報２７００）も、共有メモリ２２０上に保持する。
図４０を用いて、ストレージシステム情報２７００の内容を説明する。ストレージシステム情報２７００は、仮想ストレージシステム１０００内の各実ストレージシステム１００が有するフラッシュパッケージ２３０の情報と、各実ストレージシステム１００の有するポートの情報の集合である。
また、仮想ストレージシステム１０００内の、ある１台の実ストレージシステム１００が有するフラッシュパッケージ２３０の情報とポートの情報のセットを、「実ストレージシステム情報２７１０」と呼ぶ。ストレージシステム情報２７００には、仮想ストレージシステム１０００内のすべての実ストレージシステム１００の実ストレージシステム情報２７１０が含まれる。
実ストレージシステム情報２７１０の内容について、図４０を参照しながら説明する。実ストレージシステム情報２７１０には、実ストレージシステムＩＤ２７１１、ポートアドレス２７１２、フラッシュパッケージＩＤ２７１３が含まれる。
実ストレージシステムＩＤ２７１１は、実ストレージシステム１００の識別番号（たとえば製造番号等である）である。ポートアドレス２７１２は、実ストレージシステム１００が有するポートの識別子で、たとえばＮ＿Ｐｏｒｔ ＩＤあるいはＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）等である。実施例３に係る実ストレージシステム１００は、ＳＡＮ１２０を経由して、他の実ストレージシステム１００に対してデータ送受信要求（後述する外部パッケージリード要求等の要求）を発行することがある。この時、要求送信対象の実ストレージシステム１００の有するポートを指定したアクセス要求を発行する。ポートアドレス２７１２はそのために用いられる。また実ストレージシステム１００がポートを複数有する場合、実ストレージシステム情報２７１０内に複数のポートアドレス２７１２が格納されていてよい。
フラッシュパッケージＩＤ２７１３は、実ストレージシステム１００が有するフラッシュパッケージ２３０のパッケージＩＤである。通常、実ストレージシステム１００には複数のフラッシュパッケージ２３０が搭載されている。実ストレージシステム情報２７１０内には、実ストレージシステム１００が有する全てのフラッシュパッケージ２３０のパッケージＩＤが格納されている。なお、実施例３に係る仮想ストレージシステム１０００では、各フラッシュパッケージ２３０のパッケージＩＤには、仮想ストレージシステム１０００内で一意な識別子が用いられる。
ストレージシステム情報２７００は、仮想ストレージシステム１０００内のすべての実ストレージシステム１００が有する情報である。また仮想ストレージシステム１０００内の各実ストレージシステム１００が有するストレージシステム情報２７００の内容は同じである。
続いて、実施例３に係る実ストレージシステム１００が有するハッシュ値格納情報２４００について説明する。ただしハッシュ値格納情報２４００のフォーマットは、実施例１で説明したものと同じ（図１１）であるので、ここでの図示は略す。
実施例３に係る仮想ストレージシステム１０００では実施例１と同様、各フラッシュパッケージ２３０が重複排除可否の判定を行い、ハッシュ値はフラッシュパッケージ２３０に格納される（実施例１で説明したように、ハッシュ値はハッシュインデックス情報３５００内のリーフセグメント３５０１に格納される）。また実施例１と同じく、各フラッシュパッケージ２３０が担当するハッシュ値の範囲は、フラッシュパッケージ２３０毎に異なっている。実施例３に係る仮想ストレージシステム１０００が有するハッシュ値格納情報２４００には、実施例１で説明したハッシュ値格納情報２４００と同様に、各フラッシュパッケージ２３０が担当するハッシュ値の範囲に関する情報が格納されている。実施例１と同様、実施例３に係る仮想ストレージシステム１０００でも、ハッシュ値格納情報２４００は、各実ストレージシステム１００の共有メモリ２２０と、各フラッシュパッケージ２３０のパッケージメモリ３２０内に格納される。
実施例３に係るハッシュ値格納情報２４００のフォーマットは実施例１で説明したものと同じで、ハッシュ範囲２４０１とフラッシュパッケージＩＤ２４０２のセットが複数含まれる。実施例３に係る実ストレージシステム１００が有するハッシュ値格納情報２４００と、実施例１に係るストレージシステム１００が有するハッシュ値格納情報２４００との違いは、実施例１に係るストレージシステム１００が有するハッシュ値格納情報２４００には、ストレージシステム１００内の各フラッシュパッケージが担当するハッシュ値の情報だけが含まれているが、実施例３に係る実ストレージシステム１００が有するハッシュ値格納情報２４００には、仮想ストレージシステム１０００内の各実ストレージシステム１００が有する全フラッシュパッケージ２３０が担当するハッシュ値の情報が含まれる点である。
次に、フラッシュパッケージ２３０が有する管理情報について説明する。実施例３に係るフラッシュパッケージ２３０が有する管理情報の種類は、実施例１に係るフラッシュパッケージ２３０が有する管理情報（図１２）と同じである。また各管理情報のフォーマットも、実施例１と実施例３とで違いはない。
ただし、実施例１に係るフラッシュパッケージ２３０が有する管理情報と、実施例３に係るフラッシュパッケージ２３０が有する管理情報には、以下の違いがある。実施例１に係るフラッシュパッケージ２３０は、ストレージシステム１００内の全フラッシュパッケージグループ２８０のフラッシュパッケージグループ情報２３００を保持するが、実施例３に係るフラッシュパッケージ２３０は、仮想ストレージシステム１０００内の各実ストレージシステム１００が管理する、全フラッシュパッケージグループ２８０のフラッシュパッケージグループ情報２３００を保持する。
続いて、実施例３に係る仮想ストレージシステム１０００において、ストレージコントローラ２００とフラッシュパッケージ２３０が実行する処理の説明を行う。まず、ストレージコントローラ２００で行われる処理について説明する。
実施例３に係るストレージコントローラ２００が実行する主なプログラムは、リード処理実行部４０００’、ライト要求受付部４１００、ライトアフタ処理実行部４２００、重複排除スケジュール部４３００’’、外部パッケージリード実行部４４００を有する（図示は略す）。ライト要求受付部４１００とライトアフタ処理実行部４２００は、実施例１で説明したものと同じなので、ここでの説明は略す。
リード処理実行部４０００’は実施例１で説明したリード処理実行部４０００と同様、ホスト１１０からリード要求を受領した時に実行されるプログラムである。重複排除スケジュール部４３００’’は実施例１で説明した重複排除スケジュール部４３００と同様の処理を行うプログラムである。
外部パッケージリード実行部４４００は、実ストレージシステム１００が他の実ストレージシステムから要求（外部パッケージリード要求）を受領した時に実行されるプログラムである。以下では、リード処理実行部４０００’と重複排除スケジュール部４３００’’と外部パッケージリード実行部４４００が実行する処理の流れについて説明する。
まず実施例３におけるリード処理実行部４０００’の処理フローについて、図４１を参照しながら説明する。実施例３に係る仮想ストレージシステム１０００では、ホスト１１０からリード要求を受領した実ストレージシステム１００が、仮想ストレージシステム１０００内の他の実ストレージシステム１００に要求（外部パッケージリード要求）を発行することがある。以下の説明では、ホスト１１０からリード要求を受領した実ストレージシステム１００のことを“実ストレージＡ”と呼び、また実ストレージＡが外部パッケージリード要求を発行する先の実ストレージシステム１００のことを“実ストレージＢ”と呼ぶ。
なお、図４１に記載の各ステップは、ホスト１１０からリード要求を受領した実ストレージシステム１００（つまり実ストレージＡ）のリード処理実行部４０００’によって実行される処理である。そのため以下の説明で、リード処理実行部４０００’を主語として説明している箇所は、実ストレージＡが実行する処理であることを意味する。
リード処理実行部４０００’は、実施例１におけるリード処理実行部４０００で行われていたステップ５００９の代わりに、ステップ５００９１〜５００９３を実行する。それ以外の処理（ステップ５０００〜ステップ５００７、ステップ５００８、ステップ５０１０、ステップ５０１１）は、実施例１で説明した処理と同じである。以下、主にステップ５００９１〜５００９３について説明する。
ステップ５００６において、実ストレージＡの有するフラッシュパッケージ２３０から実ストレージＡのストレージコントローラ２００に、データが重複排除されている旨の応答が返された場合（ステップ５００７：Ｙｅｓ）、リード処理実行部４０００’はステップ５００９１を実行する。実施例１で説明したとおり、データが重複排除されている旨の応答には、仮想セグメントアドレスとハッシュ値のセットが含まれている。
ステップ５００９１でリード処理実行部４０００’はストレージシステム情報２７００を参照することにより、データが重複排除されている旨の応答に含まれている仮想セグメントアドレスが、実ストレージＡの有するフラッシュパッケージ２３０の仮想セグメントアドレスか、他の実ストレージシステム１００が有するフラッシュパッケージ２３０の仮想セグメントアドレスか、判定する。仮想セグメントアドレスにはフラッシュパッケージ２３０のパッケージＩＤが含まれているので、リード処理実行部４０００’は応答に含まれている仮想セグメントアドレス内のパッケージＩＤが、ストレージシステム情報２７００のどの実ストレージシステム情報２７１０に含まれているかを判定することにより、どの実ストレージシステム１００が有するフラッシュパッケージ２３０の仮想セグメントアドレスであるかを判定することができる。
応答に含まれている仮想セグメントアドレスが、実ストレージＡの有するフラッシュパッケージ２３０の仮想セグメントアドレスである場合（ステップ５００９１：Ｎｏ）、リード処理実行部４０００’は実ストレージＡの有するフラッシュパッケージ２３０に対してハッシュ指定型リード要求を発行する（ステップ５００９２）。ステップ５００９２は実施例１で説明したステップ５００９と同じ処理である。その後リード処理実行部４０００’は、ステップ５０１０、ステップ５００８、ステップ５０１１を実行し、処理を終了する。
応答に含まれている仮想セグメントアドレスが、実ストレージＡ以外の実ストレージシステム１００（たとえば実ストレージＢ）の有するフラッシュパッケージ２３０の仮想セグメントアドレスである場合（ステップ５００９１：Ｙｅｓ）、リード処理実行部４０００’は実ストレージＢに対して、フラッシュパッケージ２３０内のデータの取得を要求する（ステップ５００９３）。なおここで発行される要求のことを、「外部パッケージリード要求」と呼ぶ。
ステップ５００９３では、リード処理実行部４０００’はＳＡＮ１２０を介して、実ストレージＢに対して外部パッケージリード要求を発行する。外部パッケージリード要求に含まれる情報は、仮想セグメントアドレス、ハッシュ値、そして実ストレージシステム１００（実ストレージＢ）のポートアドレスである。
ステップ５００９３で行われる処理について詳述する。以下の説明では、データが重複排除されている旨の応答に含まれているパッケージＩＤ（仮想セグメントアドレス内に含まれている）が“ｐ”であった場合の例を説明する。リード処理実行部４０００’は、ストレージシステム情報２７００内の実ストレージシステム情報２７１０のうち、フラッシュパッケージＩＤ２７１３が“ｐ”である実ストレージシステム情報２７１０を特定する。
続いてリード処理実行部４０００’は、特定された実ストレージシステム情報２７１０に含まれるポートアドレス２７１２を取得する。さらにリード処理実行部４０００’は、取得したポートアドレス２７１２と、データが重複排除されている旨の応答に含まれている仮想セグメントアドレス及びハッシュ値を用いて、外部パッケージリード要求を作成し、ＳＡＮ１２０経由で実ストレージＢに外部パッケージリード要求を送信する。外部パッケージリード要求を受領した実ストレージシステム１００（実ストレージＢ）で行われる処理の詳細は後述する。
その後リード処理実行部４０００’は、実ストレージＢから応答（リードデータを含む応答）が返却されるまで待機する（ステップ５０１０）。応答が返却されると、リード処理実行部４０００’はステップ５００８とステップ５０１１を実行し、処理を終了する。
続いて、外部パッケージリード要求を受領した実ストレージシステム１００で行われる処理の流れを、図４２を用いて説明する。外部パッケージリード要求を受領した実ストレージシステム１００は、外部パッケージリード実行部４４００の実行を開始する。
ステップ８００１：外部パッケージリード実行部４４００は、外部パッケージリード要求で指定されているリード対象データが、キャッシュメモリ２１０に格納されているか（ヒットしているか）をチェックする。これは、公知の技術である。ヒットしている場合（ステップ８００１：Ｙｅｓ）、外部パッケージリード実行部４４００はキャッシュメモリ２１０に格納されているデータを、要求元の実ストレージシステム１００に返送し（ステップ８００５）、処理を終了する。ヒットしていない場合（ステップ５００１：Ｎｏ）、次にステップ８００２が行われる。
ステップ８００２：この処理は実施例１で説明したステップ５００９と類似した処理である。外部パッケージリード実行部４４００は、外部パッケージリード要求で指定されている仮想セグメントアドレスとハッシュ値を用いて、ハッシュ指定型リード要求を作成し、リード対象データの格納されているフラッシュパッケージ２３０に、作成されたハッシュ指定型リード要求を発行する。外部パッケージリード要求で指定されている仮想セグメントアドレスには、リード対象データの格納されているフラッシュパッケージ２３０のパッケージＩＤが格納されているので、外部パッケージリード実行部４４００はこれにより要求発行先のフラッシュパッケージ２３０を特定できる。
ステップ８００３：外部パッケージリード実行部４４００は、フラッシュパッケージ２３０からデータが送られてくるのを待つ。
ステップ８００４：外部パッケージリード実行部４４００は、キャッシュメモリ２１０に、リード対象データを格納するための領域を確保し、フラッシュパッケージ２３０から送られてきたデータを、確保された領域に格納する。
ステップ８００５：外部パッケージリード実行部４４００はキャッシュメモリ２１０に格納されているデータを、要求元の実ストレージシステム１００に返送し、処理を終了する。
次に、重複排除スケジュール部４３００’’の処理フローを説明する。重複排除スケジュール部４３００’’は、仮想ストレージシステム１０００に含まれる全ての実ストレージシステム１００で実行されるプログラムである。実施例３では、仮想ストレージシステム１０００に含まれる各実ストレージシステム１００において、同時に重複排除スケジュール部４３００’’の実行が開始される。たとえばストレージ管理サーバ１８０が定期的に、仮想ストレージシステム１０００内の全実ストレージシステム１００に対して、重複排除スケジュール部４３００’’の実行開始を指示する命令を送信し、各実ストレージシステム１００は、ストレージ管理サーバ１８０からの指示に応じて、重複排除スケジュール部４３００’’の実行を開始するとよい。あるいは特定の１つの実ストレージシステム１００が定期的に、仮想ストレージシステム１０００内の全実ストレージシステム１００に対して、重複排除スケジュール部４３００’’の実行開始を指示する命令を送信してもよい。
図４３は、仮想ストレージシステム１０００内の特定の１台の実ストレージシステム１００（以下では仮にこれを「実ストレージＡ」と呼ぶ）で実行される、重複排除スケジュール部４３００’’の処理フローを示している。ステップ１２０００〜ステップ１２００２は、実施例１で説明した重複排除スケジュール部４３００の処理（図２６）と同じであるため、説明を略す。
ステップ１２０２１：実ストレージＡの重複排除スケジュール部４３００’’は、ステップ１２００１〜１２００２で作成、分割されたリスト１、リスト２のうち、他の実ストレージシステム１００に送信すべきものを、他の実ストレージシステム１００に送信する。以下の説明では実施例１と同じく、リスト１内のレコードのうちフラッシュパッケージ＃ｆに送信すべきとステップ１２００２で判定されたレコードの集合を「リスト１−ｆ」と表記し、同様に、リスト２内のレコードのうちフラッシュパッケージ＃ｆに送信すべきとステップ１２００２で判定されたレコードの集合を「リスト２−ｆ」と表記する。
また図４３の説明において、ステップ１２０２１で実ストレージＡの重複排除スケジュール部４３００’’が、リスト１−ｆ及びリスト２−ｆをフラッシュパッケージ＃ｆを有する実ストレージシステム１００に送信する場合の例を説明する。実ストレージＡの重複排除スケジュール部４３００’’はストレージシステム情報２７００を参照することで、フラッシュパッケージ＃ｆを有する実ストレージシステム１００のポートアドレス２７１２を特定し、特定された実ストレージシステム１００のポートアドレス２７１２に対し、リスト１−ｆ及びリスト２−ｆの送信を行う。リスト１−ｆ及びリスト２−ｆの送信は、ＳＡＮ１２０経由で行われる。ただし別の実施形態として、ＬＡＮ１３０経由でリスト１−ｆ及びリスト２−ｆが送信されてもよい。
なお、ステップ１２００２において、実ストレージＡの重複排除スケジュール部４３００’’が、分割されたリスト１、リスト２を作成した結果、たとえばある実ストレージシステム１００（以下ではこれを仮に「実ストレージＣ」と呼ぶ）に送信すべきリスト１のレコード（またはリスト２のレコード）がないこともあり得る。このような場合には、実ストレージＡの重複排除スケジュール部４３００’’はステップ１２０２１で、仮想セグメントアドレス３４０２と（更新前）ハッシュ値３４０３に無効値（ＮＵＬＬ）の格納されたレコードを１つ作成し、この作成されたレコードを実ストレージＣに送信する。
実ストレージＣに送信すべきリスト１のレコード（またはリスト２のレコード）がない時に、もし実ストレージＡが実ストレージＣに何も送信しないと、実ストレージＣは、実ストレージＡから実ストレージＣに送信すべきリスト１のレコード（またはリスト２のレコード）がないのか、あるいは障害等が原因で実ストレージＡから送信したレコードが実ストレージＣに届いていないためか、判断できない。そのため実ストレージＡは、実ストレージＣに送信すべきリスト１のレコード（またはリスト２のレコード）がない場合には、無効値（ＮＵＬＬ）の格納されたレコードを作成して実ストレージＣに送信する。
ステップ１２０２２：実ストレージＡの重複排除スケジュール部４３００’’は、仮想ストレージシステム１０００内の全ての実ストレージシステム１００（ただし実ストレージＡを除く）から、分割されたリスト１及びリスト２が送信されてくるまで待機する。そして実ストレージＡの重複排除スケジュール部４３００’’は、仮想ストレージシステム１０００内の全ての実ストレージシステム１００から、分割されたリスト１及びリスト２を受領した後、ステップ１２００３〜１２００５を実行する。ステップ１２００３〜１２００５は、実施例１で説明した処理と同じであるため、ここでの説明は略す。ただし実施例３では、実ストレージＡの重複排除スケジュール部４３００’’はステップ１２００３で分割されたリスト１及びリスト２を各フラッシュパッケージ２３０に送信する時、実ストレージＡで作成されたリスト１及びリスト２（ステップ１２００１，１２００２で作成・分割されたリスト１、リスト２）に加えて、ステップ１２０２２において他の実ストレージシステム１００から受領したリスト１及びリスト２もフラッシュパッケージ２３０に送信する。
また以下の説明では実施例１と同じく、ステップ１２００３で各フラッシュパッケージ２３０から受領した消去候補に含まれるレコードのうち、フラッシュパッケージ＃ｆに送信すべきレコードの集合を「消去候補−ｆ」と呼ぶ。同様に、重複候補内のレコードのうちフラッシュパッケージ＃ｆに送信すべきレコードの集合を「重複候補−ｆ」と呼ぶ。
ステップ１２０５１：実ストレージＡの重複排除スケジュール部４３００’’は、ステップ１２００４〜１２００５で分類された消去候補及び重複候補のうち、他の実ストレージシステム１００に送信すべきものを、他の実ストレージシステム１００に送信する。ステップ１２０２１と同様に、実ストレージＡの重複排除スケジュール部４３００’’はストレージシステム情報２７００を参照することで、フラッシュパッケージ＃ｆを有する実ストレージシステム１００のポートアドレス２７１２を特定し、特定された実ストレージシステム１００に対し、消去候補−ｆ及び重複候補−ｆの送信を行う。
なお、ある実ストレージシステム１００（仮に“実ストレージＣ”と呼ぶ）に送信すべき消去候補のレコード（または重複候補のレコード）が存在しないこともあり得る。その場合重複排除スケジュール部４３００’’は、ステップ１２０２１で説明した方法と同じように、たとえば仮想セグメントアドレス３６０１（または仮想セグメントアドレス３７０１）に無効値（ＮＵＬＬ）の格納されたレコードを１つ作成して、この無効値が格納されたレコードを実ストレージＣに送信する。
ステップ１２０５２：実ストレージＡの重複排除スケジュール部４３００’’は、仮想ストレージシステム１０００内の他の実ストレージシステム１００から、分類された消去候補及び重複候補を受領する。この後実ストレージＡの重複排除スケジュール部４３００’’は、ステップ１２００６〜１２００７を実行する。ステップ１２００６〜１２００７は、実施例１で説明した処理と殆ど同じである。ただし実施例３では、実ストレージＡの重複排除スケジュール部４３００’’はステップ１２００６で、実ストレージＡで作成された消去候補と重複候補をフラッシュパッケージ２３０に送信することに加えて、他の実ストレージシステム１００から受領した消去候補と重複候補もフラッシュパッケージ２３０に送信する。それ以外の点は実施例１で説明した処理と同じである。
なお、実施例３に係るフラッシュパッケージ２３０で実行される処理は実施例１で説明したものと同じであるため、フラッシュパッケージ２３０で実行される処理の説明は省略する。
以上が実施例３における仮想ストレージシステム１０００で実行される処理の説明である。実施例３における仮想ストレージシステム１０００では、上で述べた処理が行われることで、複数の実ストレージシステム１００に跨った重複排除を可能にしている。
続いて実施例４の説明を行う。実施例４における情報システムのハードウェア構成は、実施例３における情報システムと同様であるので、図示は略す。また以下の説明では、実施例３に係る情報システムの構成物と同じ物を特定する際、実施例３で用いた参照番号を用いる。
実施例４に係る仮想ストレージシステムは、実施例３に係る仮想ストレージシステムと同様に、複数の実ストレージシステム１００に跨った重複排除が行われる。ただし実施例４に係る仮想ストレージシステム（または実ストレージシステム）は、実施例３（または実施例１）に係るフラッシュパッケージで行われていた処理の一部を、ストレージコントローラ２００が行う。
実施例１または３に係るフラッシュパッケージは、重複排除処理の可否を判定するプログラム（重複排除判定部１２３００）を有し、ストレージコントローラ２００から送られてくる情報（リスト１、リスト２）をもとに、重複排除処理の可否の判定等を行っていた。一方、実施例４に係る仮想ストレージシステムは実施例２で説明したストレージシステムと同様、ストレージコントローラ２００が重複排除処理の可否の判定を行う。そのため、ストレージコントローラ２００が、実施例２で説明した重複排除判定部１２３００’と類似したプログラム（実施例４では、これを「重複排除判定部１２３００’’」と呼ぶ）を有する。逆に実施例４に係るフラッシュパッケージは、重複排除判定部１２３００を有さない。
実施例４に係るフラッシュパッケージ２３０は実施例２に係るフラッシュパッケージ２３０と同様、ハッシュインデックス情報３５００を持たない。代わりに実施例４に係る仮想ストレージシステムでは、仮想ストレージシステム内の各実ストレージシステム１００が、その共有メモリ２２０内にハッシュインデックス情報３５００を有する。
また実施例４に係るフラッシュパッケージ２３０は、フラッシュパッケージグループ情報２３００とハッシュ値格納情報２４００を持っていなくて良い。一方実施例４に係る実ストレージシステム１００は、共有メモリ２２０内にフラッシュパッケージグループ情報２３００を有する。ただし実ストレージシステム１００は、仮想ストレージシステム１０００内の他の実ストレージシステム１００が有するフラッシュパッケージグループ２８０のフラッシュパッケージグループ情報２３００も保持する。
また実施例４に係る実ストレージシステム１００は、実施例１等で述べたハッシュ値格納情報２４００に代えて、ハッシュ値格納情報２４００’を有する。ハッシュ値格納情報２４００’のフォーマットについて、図４４を用いて説明する。実施例１等で説明したハッシュ値格納情報２４００には、各フラッシュパッケージ２３０が担当するハッシュ値の範囲についての情報が格納されていた。一方ハッシュ値格納情報２４００’には、各実ストレージシステム１００が担当するハッシュ値の範囲についての情報が格納される。
なお、「実ストレージシステム１００が担当するハッシュ値」の意味（定義）は、「フラッシュパッケージが担当するハッシュ値」と同様である。たとえば実ストレージシステム＃ｐ（識別番号がｐの実ストレージシステム１００）が、ハッシュ値の範囲がａ〜ｂの仮想セグメントについて、重複排除可否の判定を行う場合、「実ストレージシステム＃ｐが担当するハッシュ値の範囲はａ〜ｂと表現される。
ハッシュ値格納情報２４００’は、ハッシュ範囲２４０１’と実ストレージシステムＩＤ２４０２’のセットを複数有する。ここでは、ハッシュ範囲２４０１’と実ストレージシステムＩＤ２４０２’のセットを、エクステント２４１０’と呼ぶ。たとえばあるエクステント２４１０’内のハッシュ範囲２４０１’に格納されているハッシュ値範囲がａ〜ｂで、またそのエクステント２４１０’内の実ストレージシステムＩＤ２４０２’がｐの場合、実ストレージシステム＃ｐが担当するハッシュ値の範囲がａ〜ｂであることを意味し、後述する重複排除可否の判定の際、実ストレージシステム＃ｐは、ハッシュ値の範囲がａ〜ｂの仮想セグメントについて重複排除可否の判定を行うことを意味する。またこの場合、実ストレージシステム＃ｐが作成・管理するハッシュインデックス情報３５００に格納されるハッシュ値の範囲は、ａ〜ｂになる。
ハッシュ値格納情報２４００’は、仮想ストレージシステム１０００内の全実ストレージシステム１００の共有メモリ２２０に格納される情報である。また、各実ストレージシステム１００が有するハッシュ値格納情報２４００’の内容は同一である。
次に、実施例４に係るストレージコントローラ２００が実行する処理の説明を行う。なお、実施例４に係るフラッシュパッケージは実施例２に係るフラッシュパッケージと同じものである。つまり実施例４に係るフラッシュパッケージは重複排除判定部１２３００を有さず、重複排除判定部１２３００を実行しない点だけが、実施例１または３におけるフラッシュパッケージと異なる。そのため、実施例４に係るフラッシュパッケージが実行する処理の説明は略す。
実施例４に係るストレージコントローラ２００はそのメモリ２７０内に、少なくともリード処理実行部４０００’、ライト要求受付部４１００、ライトアフタ処理実行部４２００、重複排除スケジュール部４３００’’’、外部パッケージリード実行部４４００、重複排除判定部１２３００’というプログラムを有する（図示は略す）。
リード処理実行部４０００’と外部パッケージリード実行部４４００はいずれも、実施例３で説明したものと同じである。またライト要求受付部４１００、ライトアフタ処理実行部４２００は、実施例１等で説明したものと同じである。重複排除判定部１２３００’は実施例２で説明したものと同じである。そのためここでは、これらについての説明は略す。
重複排除スケジュール部４３００’’’の処理の流れを、図４５を用いて説明する。ステップ１２０００とステップ１２００１は、図２６のステップ１２０００〜ステップ１２００１と同じ処理であるので、ここでの説明は略す。
ステップ１２００２’：重複排除スケジュール部４３００’’’はハッシュ値格納情報２４００’を参照することで、リスト１とリスト２内の情報を、各実ストレージシステム１００に送信すべき情報に分割する。ハッシュ値格納情報２４００’を用いた、情報の分割方法の一例を以下に説明する。たとえばハッシュ値格納情報２４００’の中に、実ストレージシステムＩＤ２４０２’が“ｆ”、ハッシュ範囲２４０１’がａ〜ｂであるエクステント２４１０’があった場合を想定する。この場合、リスト１のレコードの中で、（更新前）ハッシュ値３４０３がａ〜ｂの範囲に含まれるレコードを抽出したものが、実ストレージシステム＃ｆに送信すべき情報と決定される。リスト２内の各レコードについても同様の方法で、分割される。以下の説明では、リスト１内のレコードのうち、ステップ１２００２’において実ストレージシステム＃ｆに送信すべきと判定されたレコードの集合を「リスト１−ｆ」と表記する。同様に、リスト２内のレコードのうち実ストレージシステム＃ｆに送信すべきと判定されたレコードの集合を「リスト２−ｆ」と表記する。
ステップ１２０２１’：重複排除スケジュール部４３００’’’は、ステップ１２００２’で分割されたリスト１、リスト２のうち、他の実ストレージシステム１００に送信すべきものを、他の実ストレージシステム１００に送信する。この処理は、実施例３で説明した処理（ステップ１２０２１）と同様である。なお、実施例３と同様、もしも他の実ストレージシステム１００に送信すべき、分割されたリスト１（またはリスト２）がなかった場合には、重複排除スケジュール部４３００’’’は無効値（ＮＵＬＬ）の格納されたレコードを作成して、他の実ストレージシステム１００に送信する。
ステップ１２０２２’：重複排除スケジュール部４３００’’’は、他の実ストレージシステム１００から、分割されたリスト１及びリスト２を受領する。仮想ストレージシステム内の全実ストレージシステム１００から、分割されたリスト１及びリスト２を受領すると、重複排除スケジュール部４３００’’’は次にステップ１２００３’’を実行する。
ステップ１２００３’’：このステップで行われる処理は、実施例２で説明したステップ１２００３’と同様の処理である。ステップ１２００３’’では重複排除スケジュール部４３００’’’は、自身が作成したリスト１、リスト２、及び他の実ストレージシステム１００から受領したリスト１、リスト２を用いて、重複排除可否の判定を行う。この時、重複排除スケジュール部４３００’’’は重複排除判定部１２３００’をコールすることで、重複排除可否の判定を行う。重複排除判定部１２３００’が行う処理の内容は、実施例２で説明したものと同じであるので、ここでの説明は略す。
ステップ１２００４〜ステップ１２００５は、実施例１で説明した処理（図２６のステップ１２００４〜１２００５）と同じであるため、説明を略す。
ステップ１２０５１，ステップ１２０５２：この処理は、実施例３で説明したステップ１２０５１及びステップ１２０５２と同じであるため、ここでは説明を略す。
ステップ１２０５２の後、重複排除スケジュール部４３００’’’はステップ１２００６、ステップ１２００７を実行し、処理を終了する。ステップ１２００６、ステップ１２００７は、実施例１等で説明したものと同じであるため、説明を略す。以上が、重複排除スケジュール部４３００’’’の処理の流れである。
以上、本発明の実施例を説明したが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。たとえば上で説明したいくつかの実施例では、フラッシュパッケージが重複排除処理などを行う機能を有する例を説明したが、フラッシュパッケージに代えてＨＤＤをストレージシステムに搭載し、上の実施例でフラッシュパッケージが実施していた各処理をＨＤＤが行うようにしてもよい。
また、上で説明したいくつかの実施例では、あるフラッシュパッケージが担当するハッシュ値は、そのフラッシュパッケージ内（ハッシュインデックス情報）にのみ格納される例が説明された。しかし別の実施形態として、可用性を高めるために、あるフラッシュパッケージに作成されたハッシュインデックス情報の複製が、別のフラッシュパッケージにも格納されるようにしてもよい。たとえばフラッシュパッケージＡが、自身の管理するハッシュインデックス情報を更新するたびに、その更新情報をフラッシュパッケージＢに送信し、フラッシュパッケージＢに、フラッシュパッケージＡの管理するハッシュインデックス情報の複製を格納するようにしてもよい。
また、上で説明した実施例では、すべてのデータを重複排除の対象とする前提で説明が行われた。しかしＲＡＩＤの冗長データのように重複排除できる確率が低いデータについては、重複排除の判定を行わない方が望ましいので、上で説明した実施例の処理をそのように変形してもよい。たとえばストレージコントローラ２００が冗長データをフラッシュパッケージ２３０に書き込む際、重複排除の必要がない旨を示す情報（以下これを単に「フラグ」と呼ぶ）をライト要求に付加する。フラッシュパッケージ２３０は仮想ブロックグループ情報３２００に、フラグを受け取った旨を格納する領域を、仮想セグメントごとに用意しておく。フラッシュパッケージ２３０はライト要求受領時にフラグを受領すると、フラグを仮想ブロックグループ情報３２００内の仮想セグメント管理情報に記録し、またステップ１４００１の実行時にデータのハッシュ値の計算を行わなくて良い。そして重複排除判定部１２３００、重複排除実行部１２４００は、フラグが格納された仮想セグメントについては、重複排除の判定等を行わないようにすればよい。
１００：ストレージシステム， １１０：ホスト， １２０：ストレージエリアネットワーク（SAN）， ２００：ストレージコントローラ， ２１０：キャッシュメモリ， ２２０：共有メモリ， ２３０：フラッシュパッケージ， ２５０：接続装置， ２６０：プロセッサ， ２７０：メモリ， ２８０：フラッシュパッケージグループ， ３００：フラッシュチップ， ３１０：パッケージプロセッサ， ３２０：パッケージメモリ， ３３０：バッファ， ３４０：パッケージバス， ３５０：パッケージバス転送装置， ３７０：ハッシュ回路， ２０００：論理ボリューム情報， ２１００：実ページ情報， ２３００：フラッシュパッケージグループ情報， ２４００：ハッシュ値格納情報， ２５００：フラッシュパッケージ情報， ３０００：パッケージ情報， ３１００：チップ情報， ３２００：仮想ブロックグループ情報， ３３００：実ブロック情報， ３４００：履歴情報， ３５００：ハッシュインデックス情報， ３６００：空き実ブロック情報ポインタ， ４０００：リード処理実行部， ４１００：ライト要求受付部， ４２００：ライトアフタ処理実行部， ４３００：重複排除スケジュール部， １２１００：データライト処理実行部， １２２００：履歴情報送信部， １２３００：重複排除判定部， １２４００：重複排除実行部， １２５００：ハッシュ指定型リード実行部， １２６００：データリード処理実行部

Claims (15)

  1. 複数の不揮発性記憶媒体を有する複数のフラッシュパッケージと、
    ホストと前記フラッシュパッケージとの間でリード・ライト処理を実行するストレージコントローラを有するストレージシステムであって、
    前記ストレージシステムは、前記複数のフラッシュパッケージのうち第１フラッシュパッケージの第１アドレスに、前記複数のフラッシュパッケージのうち第２フラッシュパッケージの第２アドレスに書き込まれているデータと同一データが書き込まれている場合に、前記第１フラッシュパッケージに、前記第１アドレスに対応付けて前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを記憶させるよう、構成されており、
    前記フラッシュパッケージは、同じアドレスに、その特徴量が異なる複数のデータを格納可能であり、
    前記第１フラッシュパッケージは、前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを前記第１アドレスに対応付けて記憶している場合、前記ストレージコントローラから前記第１アドレスに対するリード要求を受領したことに応じて、前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを前記ストレージコントローラに返送し、
    前記ストレージコントローラは前記第１フラッシュパッケージから前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを受領すると、前記第２フラッシュパッケージに前記第２アドレスと前記特徴量とを含むリード要求を発行し、前記第２フラッシュパッケージから前記第２アドレスに記憶されその特徴量が前記第１アドレスにかかるデータの特徴量と一致するリード対象データを受領する、
    ことを特徴とするストレージシステム。
  2. 前記フラッシュパッケージは、
    前記ストレージコントローラからライトデータのライト要求を受領すると、
    前記ライトデータの特徴量を算出し、
    前記ライト要求に含まれる前記フラッシュパッケージのアドレスと、前記ライトデータの特徴量と、前記ライトデータの更新前データの特徴量を含む履歴情報を作成し、
    前記ライトデータを前記不揮発性記憶媒体に格納し、
    前記履歴情報を前記ストレージコントローラに送信し、
    前記ストレージコントローラは、
    受領した前記履歴情報に含まれる前記更新前データの特徴量を他のフラッシュパッケージに送信してその返信を受け取り前記ライト要求の対象のフラッシュパッケージに転送することで前記更新前データの特徴量と同一の特徴量を持つデータが他の前記複数のフラッシュパッケージに格納されていない場合には前記ライト要求の対象のフラッシュパッケージが前記更新前データを削除し、格納されている場合には前記ライト要求の対象のフラッシュパッケージが前記更新前データを残すように制御する
    ことを特徴とする、請求項１に記載のストレージシステム。
  3. 前記ストレージコントローラは、
    受領した前記履歴情報に含まれる前記ライトデータの特徴量を他のフラッシュパッケージに送信してその返信を受け取り前記ライト要求の対象のフラッシュパッケージに転送することで前記ライトデータの特徴量と同一の特徴量を持つデータが他の前記複数のフラッシュパッケージに格納されている場合には前記ライト要求の対象のフラッシュパッケージがライト要求の対象である第１アドレスに対応付けて前記ライトデータの特徴量と同一の特徴量を持つデータが格納されている第２アドレスと、前記ライトデータの特徴量とを格納するように制御する
    ことを特徴とする、請求項２に記載のストレージシステム。
  4. 前記ストレージコントローラは、
    前記複数のフラッシュパッケージから、前記フラッシュパッケージが受け付けたライト要求の履歴情報を受領し、
    受領した前記履歴情報に基づいて、前記複数のフラッシュパッケージの複数の領域に同一のデータが書き込まれていることを検出する、
    ことを特徴とする、請求項１に記載のストレージシステム。
  5. 前記履歴情報は、前記ストレージコントローラからライト要求のあった前記フラッシュパッケージのアドレスと、前記ライト要求で指定されたライトデータの特徴量を含み、
    前記ストレージコントローラは、
    前記第１フラッシュパッケージで作成された前記履歴情報に含まれる前記特徴量と、前記第２フラッシュパッケージに格納されているデータの特徴量が同一の場合、前記第２フラッシュパッケージに前記第１フラッシュパッケージと同一データが書き込まれていると判定する、
    ことを特徴とする、請求項４に記載のストレージシステム。
  6. 前記複数のフラッシュパッケージはそれぞれ、あらかじめ定められた範囲の値の前記特徴量及び前記特徴量を持つデータの格納された前記フラッシュパッケージのアドレスの情報を管理するよう構成されており、
    前記履歴情報を受領した前記ストレージコントローラは、前記複数のフラッシュパッケージの中から、前記履歴情報に含まれる特徴量を管理する前記フラッシュパッケージを特定し、前記特定されたフラッシュパッケージに前記履歴情報を送信し、
    前記履歴情報を受領した前記フラッシュパッケージは、
    前記履歴情報に含まれる前記ライトデータの特徴量と同一の特徴量を持つデータが前記複数のフラッシュパッケージのいずれかに格納されているかどうか応答し、
    前記第２フラッシュパッケージが、前記第２アドレスに前記ライトデータの特徴量と同一の特徴量を持つデータを格納していると応答する場合、前記ストレージコントローラを介して前記第１フラッシュパッケージに対し、前記第２アドレスを前記第１アドレスに対応付けて送信する、
    ことを特徴とする、請求項３に記載のストレージシステム。
  7. 前記第１フラッシュパッケージと前記第２フラッシュパッケージは、同一ＲＡＩＤグループに属しており、
    前記履歴情報を受領した前記フラッシュパッケージは、
    前記ライトデータの書き込まれた前記第１フラッシュパッケージのアドレスと、前記ライトデータの特徴量と同一の特徴量を持つデータの格納されている前記第２フラッシュパッケージのアドレスとが同一である時、
    前記第１フラッシュパッケージに、前記同一データの格納されている前記第２フラッシュパッケージ内のアドレスを送信しない、
    ことを特徴とする、請求項６に記載のストレージシステム。
  8. 前記ストレージシステムは、前記ストレージコントローラ及び前記ストレージコントローラに接続された複数の前記フラッシュパッケージを含む実ストレージシステムを複数有し、
    前記第１フラッシュパッケージは、複数の前記実ストレージシステムのうち第１実ストレージシステム内の第１ストレージコントローラに接続され、前記第２フラッシュパッケージは、複数の前記実ストレージシステムのうち第２実ストレージシステム内の第２ストレージコントローラに接続されており、
    前記第１フラッシュパッケージは、前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを前記第１アドレスに対応付けて記憶している場合、前記第１ストレージコントローラから前記第１アドレスに対するリード要求を受領したことに応じて、前記第１ストレージコントローラに前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを返送し、
    前記第１ストレージコントローラは前記第１フラッシュパッケージから前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを受領すると、前記第２ストレージコントローラに対して、前記第２フラッシュパッケージからデータをリードする前記第２アドレスと前記特徴量とを含む要求を発行し、
    前記第２ストレージコントローラは、前記第２フラッシュパッケージから前記第２アドレスに記憶されその特徴量が前記第１アドレスにかかるデータの特徴量と一致するリード対象データを読み出した後、前記第１ストレージコントローラに返送する、
    ことを特徴とする、請求項５に記載のストレージシステム。
  9. 複数の前記ストレージコントローラはそれぞれ、あらかじめ定められた範囲の値の前記特徴量及び前記特徴量を持つデータの格納された前記フラッシュパッケージのアドレスの情報を管理するよう構成されており、
    前記第１フラッシュパッケージは、
    前記ライト要求と前記ライトデータを受領すると、
    受領した前記ライトデータの特徴量を算出し、
    前記ライトデータのライト先アドレスと前記特徴量を含む前記履歴情報を作成して、前記第１ストレージコントローラに送信し、
    前記第１ストレージコントローラは、
    前記履歴情報に含まれる特徴量を管理する前記ストレージコントローラが前記第２ストレージコントローラであった場合、前記第２ストレージコントローラに前記履歴情報を送信し、
    前記履歴情報を受領した前記第２ストレージコントローラは、
    前記履歴情報に含まれる前記ライトデータの特徴量と同一の特徴量を持つデータが前記複数のフラッシュパッケージのいずれかに格納されているかどうか判定する、
    ことを特徴とする、請求項８に記載のストレージシステム。
  10. 前記ストレージシステムは、前記ストレージコントローラ及び前記ストレージコントローラに接続された複数の前記フラッシュパッケージを含む実ストレージシステムを複数有し、
    前記第１フラッシュパッケージは、複数の前記実ストレージシステムのうち第１実ストレージシステム内の第１ストレージコントローラに接続され、前記第２フラッシュパッケージは、複数の前記実ストレージシステムのうち第２実ストレージシステム内の第２ストレージコントローラに接続されており、
    前記第１フラッシュパッケージは、前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを前記第１アドレスに対応付けて記憶している場合、前記第１ストレージコントローラから前記第１アドレスに対するリード要求を受領したことに応じて、前記第１ストレージコントローラに前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを返送し、
    前記第１ストレージコントローラは前記第１フラッシュパッケージから前記第２アドレスと前記第１アドレスにかかるデータの特徴量とを受領すると、前記第２ストレージコントローラに対して、前記第２フラッシュパッケージからデータをリードする前記第２アドレスと前記特徴量とを含む要求を発行し、
    前記第２ストレージコントローラは、前記第２フラッシュパッケージから前記第２アドレスに記憶されその特徴量が前記第１アドレスにかかるデータの特徴量と一致するリード対象データを読み出した後、前記第１ストレージコントローラに返送する、
    ことを特徴とする、請求項３に記載のストレージシステム。
  11. 前記複数のフラッシュパッケージはそれぞれ、あらかじめ定められた範囲の値の前記特徴量及び前記特徴量を持つデータの格納された前記フラッシュパッケージのアドレスの情報を管理するよう構成されており、
    前記第１フラッシュパッケージは、
    前記ライト要求と前記ライトデータを受領すると、
    受領した前記ライトデータの特徴量を算出し、
    前記ライトデータのライト先アドレスと前記特徴量を含む前記履歴情報を作成して、前記第１ストレージコントローラに送信し、
    前記履歴情報を受領した前記第１ストレージコントローラは、
    前記履歴情報に含まれる特徴量を管理する前記フラッシュパッケージが、前記第２ストレージコントローラに接続されている場合、前記第２ストレージコントローラに前記履歴情報を送信し、
    前記履歴情報を受領した前記第２ストレージコントローラが、
    前記履歴情報に含まれる特徴量を管理する前記フラッシュパッケージに前記履歴情報を送信する、
    ことを特徴とする、請求項１０に記載のストレージシステム。
  12. ホストからのデータアクセス要求を処理するストレージコントローラに接続されるフラッシュパッケージであって、
    前記フラッシュパッケージは、あらかじめ定められた範囲の値の特徴量及び前記特徴量を持つデータの格納された前記フラッシュパッケージのアドレスの情報を管理するよう構成されており、
    前記フラッシュパッケージは、前記ストレージコントローラからライト要求とライトデータを受領すると、
    受領した前記ライトデータの特徴量を算出し、
    前記ライトデータのライト先アドレスと前記特徴量を含む履歴情報を作成して前記ストレージコントローラに送信し、
    前記フラッシュパッケージはまた、前記ストレージコントローラから、前記フラッシュパッケージが管理する範囲に含まれる前記特徴量を有する前記履歴情報を受領すると、
    前記履歴情報に基づいて、前記ストレージコントローラに接続される複数の前記フラッシュパッケージのうち、第１フラッシュパッケージに書き込まれたライトデータと同一データを有する前記フラッシュパッケージが存在するか応答し、
    前記複数のフラッシュパッケージのうち第２フラッシュパッケージが、前記ライトデータと同一データを有すると応答する場合、前記ストレージコントローラを介して、前記第１フラッシュパッケージに前記同一データの格納されている前記第２フラッシュパッケージ内のアドレスを前記ライトデータのライト先アドレスに対応付けて送信する、
    ことを特徴とするフラッシュパッケージ。
  13. 前記フラッシュパッケージは、前記ストレージコントローラにボリュームを提供し、
    前記ストレージコントローラから、前記ボリューム上のアドレスに書き込まれたライトデータと同一データを有する、前記複数のフラッシュパッケージのうち第３フラッシュパッケージ内のアドレスを、前記フラッシュパッケージ内の前記ライトデータのライト先アドレスに対応付けて送信された場合に、前記ライト先アドレスに対応付けて、前記第３フラッシュパッケージ内のアドレスと、前記ライト先アドレスにかかるデータの特徴量とを記憶し、
    その後、前記ボリューム上のアドレスに対するリード要求を受領すると、
    前記第３フラッシュパッケージ内のアドレスと前記ライト先アドレスにかかるデータの特徴量を、前記ストレージコントローラに返送する、
    ことを特徴とする、請求項１２に記載のフラッシュパッケージ。
  14. 前記フラッシュパッケージは、前記ストレージコントローラから前記履歴情報を受領すると、
    前記履歴情報に含まれる前記特徴量と、前記あらかじめ定められた範囲の値の特徴量及び前記特徴量を持つデータの格納された前記フラッシュパッケージのアドレスを含む情報に含まれる前記第２フラッシュパッケージに格納されているデータの特徴量が同一の場合、前記第２フラッシュパッケージが前記ライトデータと同一データを有すると応答する、
    ことを特徴とする、請求項１２に記載のフラッシュパッケージ。
  15. 前記フラッシュパッケージは、前記ストレージコントローラから前記ライト要求と前記ライトデータを受領すると、前記ライトデータから前記ライトデータの特徴量を算出し、
    前記ライト要求に含まれる前記フラッシュパッケージのアドレスと、前記ライトデータの特徴量と、前記ライトデータの更新前データの特徴量を含む前記履歴情報を作成する、
    ことを特徴とする、請求項１２に記載のフラッシュパッケージ。
JP2017546459A 2015-10-19 2016-09-21 ストレージシステム Active JP6677740B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/JP2015/079395 WO2017068617A1 (ja) 2015-10-19 2015-10-19 ストレージシステム
JPPCT/JP2015/079395 2015-10-19
PCT/JP2016/077807 WO2017068904A1 (ja) 2015-10-19 2016-09-21 ストレージシステム

Publications (2)

Publication Number Publication Date
JPWO2017068904A1 JPWO2017068904A1 (ja) 2018-07-05
JP6677740B2 true JP6677740B2 (ja) 2020-04-08

Family

ID=58556823

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017546459A Active JP6677740B2 (ja) 2015-10-19 2016-09-21 ストレージシステム

Country Status (4)

Country Link
US (1) US10503424B2 (ja)
JP (1) JP6677740B2 (ja)
CN (1) CN107924291B (ja)
WO (2) WO2017068617A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018181213A (ja) * 2017-04-20 2018-11-15 富士通株式会社 ストレージ制御装置、ストレージ制御方法及びストレージ制御プログラム
CN107357687A (zh) * 2017-07-21 2017-11-17 长沙曙通信息科技有限公司 一种容灾备份新型重复数据删除实现方法
CN109491598A (zh) * 2018-10-19 2019-03-19 浪潮电子信息产业股份有限公司 一种逻辑卷的删除方法和装置
JP2020086477A (ja) * 2018-11-15 2020-06-04 株式会社日立製作所 大規模ストレージシステム及び大規模ストレージシステムにおけるデータ配置方法
CN109739776B (zh) * 2018-12-06 2023-06-30 天津津航计算技术研究所 用于NAND Flash主控芯片的Greedy垃圾回收系统
CN109710541B (zh) * 2018-12-06 2023-06-09 天津津航计算技术研究所 针对NAND Flash主控芯片Greedy垃圾回收的优化方法
KR102231722B1 (ko) * 2019-03-28 2021-03-25 네이버클라우드 주식회사 취약점 중복판단방법 및 이를 이용하는 진단장치
US12014052B2 (en) * 2021-03-22 2024-06-18 Google Llc Cooperative storage architecture
CN114063931B (zh) * 2021-11-26 2023-04-25 重庆科创职业学院 一种基于大数据的数据存储方法
US20230267003A1 (en) * 2022-02-23 2023-08-24 International Business Machines Corporation Padding input data for artificial intelligence accelerators

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5026213B2 (ja) * 2007-09-28 2012-09-12 株式会社日立製作所 ストレージ装置及びデータ重複排除方法
US7992037B2 (en) * 2008-09-11 2011-08-02 Nec Laboratories America, Inc. Scalable secondary storage systems and methods
US9256368B2 (en) * 2010-09-30 2016-02-09 Nec Corporation System and method for deduplication of distributed data
EP2652587B1 (en) 2011-06-07 2017-11-15 Hitachi, Ltd. Storage system comprising flash memory, and storage control method
KR101826047B1 (ko) * 2011-09-28 2018-02-07 삼성전자주식회사 저장 장치 및 그 구동 방법
WO2013095381A1 (en) * 2011-12-20 2013-06-27 Intel Corporation Method and system for data de-duplication
JP6021680B2 (ja) 2013-02-19 2016-11-09 株式会社日立製作所 自律分散重複排除ファイルシステム、記憶装置ユニット及びデータアクセス方法
US20140281155A1 (en) 2013-03-14 2014-09-18 Lsi Corporation Storage device assisted data de-duplication
CN104598161B (zh) * 2013-10-31 2018-10-30 腾讯科技（深圳）有限公司 数据读取、写入方法和装置及数据存储结构
US20150317083A1 (en) * 2014-05-05 2015-11-05 Virtium Technology, Inc. Synergetic deduplication
US10013169B2 (en) * 2014-12-19 2018-07-03 International Business Machines Corporation Cooperative data deduplication in a solid state storage array
US9626121B2 (en) * 2014-12-19 2017-04-18 International Business Machines Corporation De-duplication as part of other routinely performed processes
CN104503705B (zh) * 2014-12-22 2017-08-08 吴剀劼 利用闪存设备构建可信存储系统的方法及构建的可信存储系统

Also Published As

Publication number Publication date
WO2017068617A1 (ja) 2017-04-27
WO2017068904A1 (ja) 2017-04-27
US20180253252A1 (en) 2018-09-06
JPWO2017068904A1 (ja) 2018-07-05
CN107924291A (zh) 2018-04-17
CN107924291B (zh) 2020-10-09
US10503424B2 (en) 2019-12-10

Similar Documents

Publication Publication Date Title
JP6677740B2 (ja) ストレージシステム
US20180173632A1 (en) Storage device and method for controlling storage device
US9606914B2 (en) Apparatus, system, and method for allocating storage
US9442844B2 (en) Apparatus, system, and method for a storage layer
US9323465B2 (en) Systems and methods for persistent atomic storage operations
US9563555B2 (en) Systems and methods for storage allocation
US10089033B2 (en) Storage system
JP6429963B2 (ja) ストレージ装置及びストレージ装置の制御方法
WO2018029820A1 (ja) 計算機システム
WO2016056104A1 (ja) ストレージ装置、及び、記憶制御方法
US11079956B2 (en) Storage system and storage control method
JP6817340B2 (ja) 計算機
WO2018051446A1 (ja) オプショナルなデータ処理機能を有するストレージシステムを含んだ計算機システム、および、記憶制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180314

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190528

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20190723

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190823

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200128

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200217

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: 20200303

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200313

R150 Certificate of patent or registration of utility model

Ref document number: 6677740

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150