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

ストレージシステム Download PDF

Info

Publication number
JP5792313B2
JP5792313B2 JP2013535987A JP2013535987A JP5792313B2 JP 5792313 B2 JP5792313 B2 JP 5792313B2 JP 2013535987 A JP2013535987 A JP 2013535987A JP 2013535987 A JP2013535987 A JP 2013535987A JP 5792313 B2 JP5792313 B2 JP 5792313B2
Authority
JP
Japan
Prior art keywords
data
virtual
storage
block
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
JP2013535987A
Other languages
English (en)
Other versions
JP2014506688A (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 JP2014506688A publication Critical patent/JP2014506688A/ja
Application granted granted Critical
Publication of JP5792313B2 publication Critical patent/JP5792313B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614Improving the reliability of storage systems
    • G06F3/0619Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608Saving storage space on storage systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638Organizing or formatting or addressing of data
    • G06F3/064Management of blocks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662Virtualisation aspects
    • G06F3/0665Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0683Plurality of storage devices
    • G06F3/0688Non-volatile semiconductor memory arrays
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10Providing a specific technical effect
    • G06F2212/1041Resource optimization
    • G06F2212/1044Space efficiency improvement
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/40Specific encoding of data in memory or cache
    • G06F2212/401Compressed data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72Details relating to flash memory management
    • G06F2212/7208Multiple device management, e.g. distributing data over multiple flash devices

Description

本発明は、フラッシュメモリに格納するデータの容量を削減する技術に関する。
フラッシュメモリは、磁気ディスクなどに比べ、ビットコストが高価であるため、格納データ容量を削減し、見かけ上の容量を大きくするニーズは高い。
また、フラッシュメモリ(例えばNAND型のフラッシュメモリ)は、メモリの特性上、データを書き換えようとした時、そのデータが元々格納されていた物理領域上に、そのデータを、直接上書きすることは不可能である。既にデータが書き込まれている物理領域に新たにデータを書き込むためには、フラッシュメモリの消去単位である「ブロック」と呼ばれる単位で、消去処理を実行し、その後に、データを書き込む必要がある。このため、通常、データを書き換える場合、元々そのデータが格納されていた物理領域に新たにデータを書き込むのではなく、別の物理領域にデータを書き込む。同一の論理アドレスを書込み先としたデータが複数の物理領域に書き込まれ、ブロックが満杯になると、そのブロック内の最新のデータ(有効なデータ)を別のブロックに書き込み、無効なデータで満杯のブロックの消去処理(ブロックに格納されているデータを消去する処理)を行うことで、そのブロックを使用可能にする(そのブロックを空きブロックにする)処理が行われる。以下、この処理を「リクラメーション処理」と呼ぶ。このため、1以上のフラッシュメモリを搭載したパッケージ(以下、フラッシュパッケージ)では、フラッシュパッケージの外側に見せるアドレス層として、物理的なアドレスの層とは別に、論理的なアドレスの層が設けられる。物理的なアドレスに割り当てる論理的なアドレスが適宜変更される。また、物理的なアドレスが変更になっても、論理的なアドレスは変わらない。このため、フラッシュパッケージの外側からは、同一の論理アドレスでデータクセスが可能である。故に、使い勝手の良さを維持することができる。
次に、格納容量削減技術について述べる。一般的に、容量を削減する代表的な技術として、圧縮技術がある。一方、近年、ストレージシステムでは、格納容量を削減する技術として、容量仮想化技術という技術が知られている。容量の仮想化技術とは、ストレージシステムが含む記憶装置の物理的な容量より大きな仮想的な容量を、ストレージシステムの外側(例えばホスト側)に見せる技術で、ストレージシステムのコントローラ(以下、ストレージコントローラ)で実現される。これは、ユーザが実際にストレージシステムを使用する場合、ユーザが定義したユーザボリューム(ユーザからみた論理ボリューム)の容量に対し、実際に格納するデータの量は、このユーザボリュームの記憶容量(ユーザが定義した容量)には、なかなか達しないという特性を利用したものである。すなわち、容量仮想化技術が適用されないストレージシステムでは、ボリューム定義時に、定義された物理的な容量が確保されるのに対し、容量仮想化技術が適用されているストレージシステムでは、実際にストレージシステムにデータが格納された時に初めて物理的な容量が確保される。これにより、ストレージシステムで消費される記憶容量(確保される記憶容量)が削減され、かつ、ユーザはユーザボリュームの容量を厳密に定義する必要がないため(例えば、余裕をもった容量を単純に定義すればよいため)、使い勝手を向上することができる。
特許文献1では、多数のフラッシュパッケージに接続されたストレージコントローラを含むストレージシステムにおいて、ストレージコントローラだけでなく、フラッシュパッケージも、容量仮想化技術をもった方式が公開されている。特許文献1では、それぞれを区別するため、ストレージコントローラが持つ容量仮想化機能を「上位レベルの容量仮想化機能」と呼び、フラッシュパッケージが持つ容量仮想化機能を「下位レベルの容量仮想化機能」と呼んでいる。
このため、フラッシュパッケージは、実際のフラッシュメモリの物理容量より大きな容量をストレージコントローラに見せることができる。容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、ページと呼ばれる。特許文献1では、ストレージコントローラで実現される上位レベルの容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、「ページ」と呼ばれる。一方、フラッシュパッケージで実現される下位レベルの容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、フラッシュメモリの消去単位である「ブロック」と呼ばれる。一般に、ページのサイズは、多様性にとんでいるが、特許文献1では、ページのサイズのほうが、ブロックのサイズより大きい。
ところで、フラッシュメモリに関して、一般的に、消去の単位は、前述したように「ブロック」と呼ばれ、ブロックの中での読み書きの単位は「ページ」と呼ばれる。当然、フラッシュメモリにおいては、ブロックのサイズのほうが、ページのサイズより大きい。しかし、特許文献1では、「ページ」という言葉は、フラッシュメモリの読み書き単位でなく、上位レベルの容量仮想化技術に従い割り当てられる物理的な記憶領域を意味する。なお、本明細書においても、「ページ」という言葉は、フラッシュメモリの読み書き単位でなく、上位レベルの容量仮想化技術に従い割り当てられる物理的な記憶領域を意味する。なお、本明細書では、フラッシュメモリの読み書きの単位を、「セグメント」と呼ぶ。
ただし、本発明に従うストレージシステムは、上位レベルの容量仮想化技術を必ずしももっていなくて良い。一方、通常、記憶装置には、ユーザのデータを格納する前に、特定のパターン(例えば、オール0)でフォーマティングする。特許文献2では、フォーマッティングの際に書き込まれる特定パターンが書き込まれているページが解放される。特許文献1では、ストレージシステムが、オール0の書込み先をフラッシュメモリ記憶装置に通知し、フラッシュメモリ記憶装置は、その書込み先にブロックを割り当てないよう制御する。
国際公開第2011/010344号パンフレット 特開2007−199922号公報
フラッシュメモリを記憶媒体とする大容量ストレージシステムにおいては、フラッシュメモリチップの数は、数万に及ぶ。このため、数百のチップを搭載したフラッシュパッケージを数百枚、ストレージコントローラに接続するのが典型的な構成となり得る。
本発明において解決しようとする課題は、多数のフラッシュパッケージを含む大規模ストレージシステムにおいて、ストレージシステム全体で、性能に与える影響を少なくして、フラッシュメモリに格納するデータの量を削減し、見掛け上、より多くの量のデータを格納するようにすることである。具体的には、例えば、下記第1及び第2の課題がある。
第1の課題は、フラッシュパッケージ内で、性能に与える影響を少なくして、格納するデータの量を削減することである。特許文献1は、(1)容量仮想化技術(下位レベルの容量仮想化技術)と、(2)書込み対象のデータが特定のパターンであれば物理的な領域を割り当てない、ことを開示している。しかし、フラッシュメモリに格納するデータの量を更に削減することが可能である。格納するデータの量を削減する代表的な方法として、圧縮という方法がある。しかし、フラッシュメモリの特性を生かす形で、見掛け上より多くの量のデータを格納するような圧縮技術は知られていない。
第2の課題について説明する。一般に、圧縮率のようなデータの削減率は、データの中身によって異なり、予測は難しい。特許文献1では、フラッシュパッケージが、見かけ上、物理容量より大きな容量(以下、仮想容量と呼ぶ)を、ストレージコントローラに見せる。しかし、実際に格納されたデータにより、圧縮率が変化するという事象に生ずる課題、例えば、圧縮率が予想以上に低かった場合に発生する課題を解決する技術は知られていない。
ストレージシステムは、複数のフラッシュパッケージと、ホストからライト要求を受け、そのライト要求に従うライトデータを、ライト先のフラッシュパッケージに送信するストレージコントローラとを有する。各フラッシュパッケージは、複数のフラッシュチップを有する。各フラッシュチップは、複数のブロックで形成されている。ブロックは、データの消去単位である。
第1の課題を解決するための、本発明の1つの特徴は、以下の通りである。すなわち、フラッシュパッケージは、物理容量よりも大きな容量を格納できるよう、物理容量より大きな仮想容量を、ストレージシステム内のコントローラに見せ、且つ、圧縮技術により、ストレージコントローラから受けたライトデータを圧縮する。フラッシュメモリの特性を生かすことで、性能に与える影響を抑えることができる。
すでに、述べたように、フラッシュメモリでは、データを書きかえる場合、元々そのデータが格納されていた領域(例えばブロック内の領域)に書き込むのではなく、別の領域(例えば同じブロック内の別の領域)にそのデータが書き込まれることが多い。同一のデータが複数の領域に書き込まれ、ブロックが満杯になると、リクラメーション処理が実行される。このため、データを圧縮することでそのデータの格納容量(ブロックにおけるデータの容量)が削減されても、データ更新時には、別領域にデータが書き込まれるので、問題がない。また、更新データ(書き換え後のデータ)を圧縮して書き込むことで、更新データの格納容量も削減することができる。ブロックが満杯になったときには、フラッシュパッケージは、リクラメーション処理を行えばよい。リクラメーション処理では、フラッシュパッケージは、一度データを伸長し、伸長したデータを並び替えた後に、並び替えられたデータを圧縮してもよいし、圧縮されたままデータを移動してもよい。
以上の通り、本発明によれば、フラッシュメモリで一般的に実行される基本動作(例えば、追記ライト処理(ブロック内の或る領域に格納済みのデータの書き換え後のデータを、同一のブロック内の別の空き領域(又は別のブロック内の空き領域)に書く処理)とリクラメーション処理)に、圧縮処理を組み込むことができる。これにより、圧縮処理が原因で性能が低下することを抑えることができる。また、圧縮率が高ければ、リクラメーション処理の実行頻度が低くなるため、場合によっては、圧縮によって性能が向上する可能性もある。
第2の課題、すなわち、実際に格納されたデータにより圧縮率が変化するという事象が発生する具体的な課題、について述べる。例えば、圧縮率が予想以上に低いと、フラッシュパッケージがストレージコントローラに見せている仮想容量よりも少ない容量しかそのフラッシュパッケージにデータが格納されていないのに、フラッシュパッケージにそれ以上データが格納できないという事象が発生する。一方で、圧縮率が予想より高いと、フラッシュパッケージがコントローラに見せている仮想容量と同程度の容量のデータがそのフラッシュパッケージに格納されたのに、まだ多くの空き容量が残っているということになる。本発明の更なる特徴は、フラッシュパッケージが、コントローラに見せる仮想容量を動的に変化させるために、圧縮率を用いる機能をもつ点である。この機能により、より効率的にデータの格納容量の削減が可能になる。
一方で、ストレージコントローラは、フラッシュパッケージが、仮想容量の変化を通知してきた場合、これに対応する機能をもつ必要がある。この機能を実現する際には、ストレージコントローラも容量仮想化機能(上位レベルの容量仮想化機能)をもっていることが望ましい。なぜなら、フラッシュパッケージが仮想容量の変化を通知してきても、ストレージコントローラが、その仮想容量の変化をホストに意識させないようにするためである。容量仮想化機能とは、ストレージシステムがもっている実際の物理的な記憶容量ではなく、仮想的な記憶容量をホストに見せる技術の1つである。このため、フラッシュパッケージが仮想容量の変化をストレージコントローラに通知してきても、ストレージコントローラが、その仮想容量の変化をホストに意識させないようにすることができる。圧縮率の認識、及び、フラッシュパッケージの仮想容量の調整を、フラッシュパッケージではなくストレージコントローラが行ってもよい。
本発明によれば、複数のフラッシュパッケージを有する大容量のストレージシステムにおいて、性能劣化を抑えて、データの格納容量の削減し、物理的な記憶容量よりも大きな容量のデータを格納することができる。
本発明の一実施例における情報システムの構成を示す図である。 本発明の一実施例におけるストレージシステムの構成を示す図である。 本発明の一実施例におけるフラッシュパッケージの構成を示す図である。 本発明の一実施例におけるストレージシステムの共有メモリに格納された上位レベルの制御に関する情報を示す図である。 本発明の一実施例における論理ボリューム情報の形式を示す図である。 本発明の一実施例における実ページ情報の形式を示す図である。 本発明の一実施例における仮想ページ、実ページ、仮想ブロック、実ブロックの関係を表した図である。 本発明の一実施例におけるフラッシュパッケージ情報の形式を示すである。 本発明の一実施例におけるフラッシュパッケージグループ情報の形式を示す図である。 本発明の一実施例における空き実ページ情報ポインタからポイントされた空き状態にある実ページ情報の集合を表した図である。 本発明の一実施例における使用不可実ページ情報ポインタからポイントされた使用不可状態にある実ページ情報の集合を表した図である。 本発明の一実施例におけるフラッシュパッケージのパッケージメモリ内における下位レベルの階層のための情報を示す図である。 下位レベルの階層の制御を行うための情報を、ストレージシステムの共有メモリに設けた構成を示す図である。 本発明の一実施例におけるパッケージ情報の形式を示す図である。 本発明の一実施例におけるチップ情報の形式を示す図である。 本発明の一実施例における仮想ブロック情報の形式を示す図である。 本発明の一実施例における実ブロック情報の形式を示す図である。 本発明の一実施例における空き実ブロック情報ポインタによりポイントされる空き状態にある実ブロックの集合を表す図である。 本発明の一実施例におけるストレージコントローラのメモリ内の上位レベルの制御を行うプログラムを示す図である。 本発明の一実施例におけるリード処理実行部の処理フローを示す図である。 本発明の一実施例におけるライト要求受付部の処理フローを示す図である。 本発明の一実施例におけるライトアフタ処理実行部の処理フローを示す図である。 本発明の一実施例におけるライトセイムコマンド処理実行部の処理フローを示す図である。 本発明の一実施例におけるページ移動処理実行部の処理フローを示す図である。 本発明の一実施例におけるフラッシュパッケージのパッケージメモリに格納されるプログラムを示す図である。 下位レベルの制御を行うプログラムを、ストレージコントローラのメモリに格納した構成を示す図である。 本発明の一実施例におけるデータリード処理実行部の処理フローを示す図である。 本発明の一実施例におけるデータライト処理実行部の一部の処理フローを示す図である。 本発明の一実施例におけるデータライト処理実行部の残りの一部の処理フローを示す図である。 本発明の一実施例における実ブロック解放処理実行部の処理フローを示す図である。 本発明の一実施例における仮想ブロック移動処理実行部の処理フローを示す図である。 本発明の一実施例における仮想ブロック格納処理実行部の処理フローを示す図である。 本発明の一実施例における仮想容量判定処理部の処理フローを示す図である。
以下、図面を参照して、本発明の一実施例を説明する。
図1は、本発明の一実施例における情報システムの構成を示す。
情報システムは、ストレージシステム100、ホスト110と、それらを接続するSAN(Storage Area Network)120とを有する。ホスト110は、アプリケーションプログラム(ユーザアプリケーション)を実行する計算機であり、ストレージステム100との間で、SAN120経由で、必要なデータを読み書きする。SAN120は、SCSIコマンドが転送可能なプロトコルを用いる。そのプロトコルとして、例えば、Fibre Channel等のプロトコルを用いることができる。SCSIコマンド以外に、メインフレームのI/Oプロトコルも用いることもできる。
本実施例は、多数のフラッシュメモリを有するストレージシステム100において、フラッシュメモリへの格納データ容量削減技術(フラッシュメモリに格納するデータの容量を削減する技術)を実現するものである。本実施例においては、ストレージシステム100は、階層型の容量仮想化技術をもつ。上位レベルの容量仮想化技術の制御単位は、ページとよばれる単位である。本実施例におけるページは、ストレージコントローラ200で実現される容量仮想化技術で用いられるページである。なお、本発明は、階層型の容量仮想化技術における上位レベルの制御単位は、ページでなくとも有効である。本実施例では、ページのサイズは、フラッシュメモリにおける消去単位であるブロックよりも大きい。例えば、ページのサイズは、ブロックのサイズのX倍である(Xは2以上の整数)。通常、フラッシュメモリにおいては、リード・ライトの単位をページと呼ぶので、ページはブロックよりも小さい。しかし、すでに述べたように、本実施例では、ページは、上位レベルの容量仮想化技術についての制御単位(シンプロビジョニングに従う仮想的な論理ボリュームに割り当てられる記憶領域)を意味しており、そのサイズは、ブロックよりも大きい。なお、本実施例では、フラッシュメモリにおけるリード・ライトの単位を、上位レベルの容量仮想化の制御単位であるページと区別するため、「セグメント」と呼ぶ。また、下位レベルの容量仮想化技術の制御単位は、本実施例では、フラッシュメモリの消去単位であるブロックのN番目(Nは1以上の整数)の単位として、説明を行う。また、本発明は、記憶媒体をフラッシュメモリとし、実容量より大きい仮想容量を持ち、消去単位であるブロックを割り当て単位とした、容量仮想化機能を、単独に、従来の上位レベルの容量仮想化機能なしに、ホスト110に提供しても有効である。
図2は、ストレージシステム100の構成を示している。
ストレージシステム100は、一つ以上のストレージコントローラ200と、キャッシュメモリ210と、共有メモリ220と、フラッシュパッケージ230と、それらの構成要素を接続する一つ以上の接続装置250とを有する。また、本実施例においては、ストレージシステム100内の複数の記憶媒体は、すべてフラッシュメモリであるが、ストレージシステム100は、フラッシュメモリの他に、HDDのような他種の記憶媒体を含んでいてもよい。また、本実施例において、全てのフラッシュパッケージ230の物理容量(物理的な記憶容量)は等しい。ただし、本発明は、複数のフラッシュパッケージ230のうちの少なくとも2以上のフラッシュパッケージ230の物理容量が異なっていても良い。ストレージコントローラ200は、ホスト110から発行されたリード要求又はライト要求を処理するプロセッサ260と、プログラム及び/又は情報を記憶する記憶資源(例えばメモリ270)とを有する。
接続装置250は、ストレージシステム100内の各構成要素を接続する機構である。また、本実施例では、高信頼化のために、一つのフラッシュパッケージ230は、複数の接続機構250で、複数のストレージコントローラ200に接続されているものとする。ただし、一つのフラッシュパッケージ230が一つの接続装置250にしか接続されていない場合も本発明は有効である。
キャッシュメモリ210及び共有メモリ220の少なくとも一方は、通常、DRAMなどの揮発メモリで構成されるが、バッテリーなどによりメモリは不揮発化されていても良い。ただし、本発明は、キャッシュメモリ210及び共有メモリ220の少なくとも一方が不揮発化されていなくても有効である。
キャッシュメモリ210には、フラッシュパッケージ230に格納されたデータの中で、ストレージコントローラ200からよくアクセスされるデータが格納される。ストレージコントローラ200は、ホスト110からライト要求を受け付け、そのライト要求に従うデータ(フラッシュパッケージ230に書き込むデータ)を、キャッシュメモリ210に書き込んで、そのライト要求を完了させる(例えばライト要求に対する完了報告をホスト110に送る)。ただし、本発明は、書き込むデータをフラッシュパッケージ230に格納した段階でライト要求を完了させる方式でも有効である。
共有メモリ220は、キャッシュメモリ210の制御情報、ストレージシステム100内の重要な管理情報、ストレージコントローラ200間の連絡情報、及び、同期情報のうちの少なくとも1種類の情報を記憶する。
なお、本実施例では、フラッシュパッケージ230は、ストレージコントローラ200からは、一台の記憶装置に見えているものとする。したがって、ストレージコントローラ200が、高信頼化のために、一台のフラッシュパッケージ230が故障しても、そのフラッシュパッケージ230のデータを回復できるRAID(Redundant Array of Independent (or Inexpensive) Disks)機能をもっているものとする。ストレージコントローラ200がRAID機能もつ場合、複数のフラッシュパッケージ230で、一つのRAID構成をとる。これを、フラッシュパッケージグループ280と呼ぶ。ただし、そのようなRAID機能を、ストレージコントローラ200がもっていなくとも、本発明は有効である。
図3は、フラッシュパッケージ230の構成を示している。
フラッシュパッケージ230は、複数のフラッシュチップ300と、パッケージプロセッサ310と、パッケージメモリ320と、バッファ330と、パッケージバス340と、バス転送装置350と、圧縮・伸長回路360とを有する。本実施例では、フラッシュパッケージ230は、ブロック単位の容量仮想化機能をもっている。なお、フラッシュパッケージ230が、ブロック単位以外の容量仮想化機能をもっていても、本発明は有効である。このため、フラッシュパッケージ230の物理容量(フラッシュパッケージ230がもっている全てのフラッシュチップ300の物理容量を合計した値)より大きな容量が、仮想容量として定義される。フラッシュパッケージ230は、ストレージコントローラ200からライト要求を受け付けたとき、そのライト要求に従うライト先のアドレス(そのアドレスが属する仮想的な領域)に、データを書き込むべきブロックが割り当てられているかどうかを判断し、その判断の結果が否定的の場合に、ライト先のアドレスに、ブロックを割り当てる。これによって、実際にブロックを割り当てる時刻を遅らせることができ、容量削減の効果がある。
また、2つの圧縮・伸長回路360A及び360Bが設けられている。第1の圧縮・伸長回路360Aは、ストレージコントローラ200とバッファ330の間で転送されるデータを圧縮又は伸長する。第2の圧縮・伸長回路360Bは、バス転送装置350とバッファ330の間で転送されるデータ、及び、バッファ330の或る領域から読み出されてバッファ330の別の領域に書き込まれるデータを、圧縮又は伸長する。以上により、フラッシュチップ300に格納するデータを圧縮することができるので、さらなる容量削減の効果がある。また、本実施例では、圧縮・伸長回路360A及び360Bは、特に指示がない場合(例えば、パッケージプロセッサ310からの指示がない場合)、圧縮及び伸長のいずれも行わず、入力されたデータをそのまま転送する。
パッケージプロセッサ310は、ストレージコントローラ200からリード要求又はライト要求を受け付け、受けた要求に従う処理を実行する。
バッファ330は、ストレージコントローラ200とフラッシュチップ300との間でリード又はライトされるデータを格納する。本実施例では、バッファ330は、揮発メモリである。パッケージプロセッサ310が、ストレージコントローラ200からライト要求を受け、そのライト要求に従うデータをフラッシュチップ300に書き込んだ段階で、そのライト要求を完了する(ライト要求の完了をストレージコントローラ200に報告する)。ただし、バッファ330が不揮発メモリであっても良く、また、パッケージプロセッサ310は、ストレージコントローラ200からのライト要求に従うデータをバッファ330に書き込んだ段階で、そのライト要求の完了報告をストレージコントローラ200に送信しても良い。
パッケージメモリ320には、パッケージプロセッサ310が実行するプログラム、及び、フラッシュチップ300の管理情報などが格納される。フラッシュパッケージ230の管理情報は重要な情報であるので、計画停止時には、管理情報を特定のフラッシュチップ300に退避できることが望ましい。また、突発的な障害に備え、バッテリーをもち、これを利用して、障害などが発生しても、管理情報を特定のフラッシュチップ300に退避できることが望ましい。
パッケージバス340は、バッファ330とフラッシュチップ300との間で転送されるデータが流れるバスで、一本以上存在する。性能向上のために、複数のパッケージバス340を持つのが一般的だが、パッケージバス340が一本でも本発明は有効である。
バス転送装置350は、パッケージバス340対応に存在し、パッケージプロセッサ310の指示にしたがって、バッファ330とフラッシュチップ300との間で、データ転送を実行する。
圧縮・伸長回路360A及び360Bは、パッケージプロセッサ310からの指示に従い、バッファ330から読み出されるデータ、及び/又は、バッファ330に書き込まれるデータの圧縮又は伸長を行う。もちろん、圧縮・伸長回路360A及び360Bは、データを、圧縮又は伸長なしに転送することも可能である。
図4は、ストレージシステム100の共有メモリ220に格納される情報を示す。
論理ボリューム情報2000、実ページ情報2100、空きページ管理情報ポインタ2200、フラッシュパッケージグループ情報2300、フラッシュパッケージ情報2500、仮想ページ容量2600、及び、使用不可ページ管理情報ポインタ2700が共有メモリ220に格納される。これらの情報のうちの少なくとも1種類が、上位レベルの容量仮想化技術を実現するために利用される。
本実施例においては、ストレージコントローラ200は、上位レベルの容量仮想化機能を有しているものとする。ただし、本発明は、ストレージコントローラ200が、上位レベルの容量仮想化機能をもっていなくとも有効である。通常、上位レベルの容量仮想化機能において、記憶領域の割り当て単位は、ページと呼ばれる。なお、本実施例では、論理ボリューム(例えば、シンプロビジョニングに従う仮想的な論理ボリューム)は、複数の仮想ページ(仮想的な記憶領域)に分割されているものとし、1以上のフラッシュパッケージグループ280に基づく記憶空間(以下、「プール」と言うことがある)は、複数の実ページ(実体的な記憶領域)に分割されているものとする。容量仮想化においては、論理ボリュームの記憶容量を、実際の容量よりも大きく見せることができる。このため、一般に、仮想ページの数は、実ページの数より多い。容量仮想化機能を実現した場合、ストレージコントローラ200が、ホスト110からのライト要求に従うライト先のアドレスに属する仮想ページに、空きの実ページをプールから割り当て、その実ページに、ライト要求に従うデータを書き込む。
仮想ページ容量2600は、仮想ページの容量を表す情報である。しかし、本実施例では、仮想ページの容量と実ページの容量は等しいというわけではない。なぜなら、実ページには、RAIDのタイプにより異なってくる冗長データが格納されることがあるためである。したがって、実ページの容量は、その実ページが割り当てられたフラッシュパッケージグループ280のRAIDタイプにより決まる。たとえば、RAID1のようにデータを2重に書き込む場合、実ページの容量は、仮想ページ容量の2倍になる。RAID5のように、N台の記憶装置の容量に対し、1台分の記憶装置の容量の冗長データを格納する場合、仮想ページ容量の(N+1)/Nの容量が、実ページの容量である。また、1つの冗長データとこれを生成するN個のデータを、「ストライプグループ」と呼ぶ。さらに、ストライプグループを構成する個々のデータの長さを「ストライプサイズ」と呼ぶ。当然、RAID0のように、冗長性がない場合、仮想ページの容量と等しい容量が実ページの容量ということになる。なお、本実施例においては、仮想ページの容量は、ストレージシステム100が提供する1又は複数の論理ボリューム(シンプロビジョニングに従う仮想的な論理ボリューム)について共通であるが、1又は複数の仮想ボリュームにおいて異なる容量の仮想ページが含まれていても、本発明は有効である。
図5は、論理ボリューム情報2000の形式を示したものである。
論理ボリュームは、ホスト110がリード又はライトするデータが格納される論理的な記憶デバイスである。一般的に、ホスト110は、論理ボリュームのID、論理ボリューム内のアドレス、読み書きしたいデータの長さを指定して、リード要求やライト要求を発行する。論理ボリューム情報2000は、論理ボリュームごとに存在する情報である。この情報は、論理ボリュームID2001、論理容量2002、論理ボリュームRAIDタイプ2003、実ページポインタ2004、及び、フォーマット情報2005を含む。
論理ボリュームID2001は、対応する論理ボリュームのIDを示す。
論理容量2002は、ホスト110から見た、対応する論理ボリュームの容量、を表す。
論理ボリュームRAIDタイプ2003は、対応する論理ボリュームのRAIDタイプ(例えば、RAID0、RAID1など)を表す。RAID5のように、N台のフラッシュパッケージ230に対し1台のフラッシュパッケージ230に冗長データを格納する場合、Nの具体的数値を指定するものとする。ただし、任意のRAIDタイプが指定できるわけでなく、少なくとも一つのフラッシュパッケージグループ280がもつRAIDタイプである必要がある。
実ページポインタ2004は、対応する論理ボリュームの仮想ページに割り当てた実ページ情報2100へのポインタである。実ページポインタ2004の数は、論理ボリュームの仮想ページの数(論理容量2002が表す値を仮想ページ容量2600が表す値で割った数になるが、余りがでれば、商に1を足す)である。最初の実ページポインタ2004に対応するページが、論理ボリュームの先頭の仮想ページに割り当てられた実ページで、以降、次の実ページポインタ2004には、次の仮想ページに割り当てる実ページに対応するポインタが格納される。また、仮想容量機能をサポートしているので、実ページが割り当てられるのは、論理ボリュームを定義した契機ではなく、対応する仮想ページに実際にデータ書き込みが行われる契機である。したがって、まだ書き込みが行われていな
い仮想ページの場合、対応する実ページポインタ2004はヌルになっている。
フォーマット情報2005も、対応する論理ボリュームの仮想ページ対応に存在する情報である。ホスト110は、アプリケーションプログラムが使用するデータを格納する前に、特定の情報で記憶媒体を初期化することが多い。ストレージシステム100は、ライト要求に従い仮想ページに繰り返し情報(例えば、短いフォーマットデータの繰り返し)が書き込まれたことを認識した場合、その仮想ページに対応するフォーマット情報2005にフォーマットデータが書き込まれたことを表す情報を記録することで、その仮想ページに割り当てられている実ページを解放しても良い。或いは、ホスト110が、明示的に指定した領域に短い繰り返し情報(繰り返しパターン)を書き込めというライトセイムコマンドを発行し、ストレージシステム100は、ライトセイムコマンドを受けた場合でも、繰り返し情報を、フォーマット情報2005に記憶することで、その仮想ページには、この繰り返し情報が格納されていることが認識できるので、その仮想ページに割り当てられている実ページを解放することができる。ストレージシステム100は、ライトセイムコマンドを受領したとき、下位レベルの容量仮想化機能にも、その要求を伝え、ブロック単位の解放をフラッシュパッケージ230に行なわせて良い。それにより、容量の削減効果が期待できる。あるいは、さらに、明示的に、ホスト110が、この領域を解放せよという要求を発行した場合、同じ処理をストレージシステム100が実行してもよい。同様に、通常のライトコマンドで、オール0などのフォーマットパターンが書き込まれた場合にも、ストレージシステム100は、そのフォーマットパターンを認識して、下位レベルの容量仮想化機能に、対応するブロックを解放させても良い。フォーマット情報2005が設定された場合、その仮想ページに実ページを割り当てる必要はないので、実ページポインタ2004はヌル値になる。フォーマット情報2005に格納された情報以外のデータが、対応する仮想ページに書き込まれると、実ページが割り当てられ、フォーマット情報2004はヌルになる。
図6は、実ページ情報2100の形式である。
実ページ情報2100は、実ページごとに存在する、実ページの管理情報である。実ページ情報2100は、パッケージグループ2101、実ページアドレス2102、空きページポインタ2103、ページデータ格納量2104、ページ圧縮後データ格納量2105、移動中フラグ2109、移動先実ページ情報2110、及び、移動待ちフラグ2111を含む。
パッケージグループ2101は、対応する実ページが、どのフラッシュパッケージグループ280に割り当てられているかを示す。
実ページアドレス2102は、対応する実ページの基になっているフラッシュパッケージグループ280の中で、対応する実ページがどの相対的なアドレスに割り当てられているかを示す情報である。
空きページポインタ2103は、対応する実ページに、仮想ページが割り当てられていない場合、有効な値となる。この場合、その値は、次の仮想ページが割り当てられていない空きの実ページ情報2100をさす。仮想ページが割り当てられている場合、空きページポインタ2103は、ヌル値となる。
本実施例においては、それぞれのフラッシュパッケージ230は、容量仮想化機能をもっており、ストレージコントローラ200には、見かけ上、実際の物理容量より大きな容量を仮想容量として提供している。フラッシュパッケージ230の容量仮想化の単位は、本実施例では、フラッシュメモリの消去単位であるブロックとする。以下、ストレージコントローラ200から見たブロックを「仮想ブロック」と呼び、フラッシュパッケージ230が、実際に割り当てているブロックを「実ブロック」と呼ぶことがある。したがって、本実施例では、実ページは、1又は複数の仮想ブロックにより構成されることになる。また、本実施例では、仮想ブロックにより構成される容量空間のほうが、実ブロックにより構成される容量空間より大きいことになる。
図7は、仮想ページ、実ページ、仮想ブロック、実ブロックの関係を示したものである。
すでに述べたように、実ページには、仮想ページにはない、冗長データが格納されることがある。一方、仮想ブロックに格納されるデータは、圧縮され、圧縮されたデータが実ブロックに格納される。本実施例では、m個(mは1以上の整数)の仮想ブロックのデータが、圧縮率に応じて、1個から(m+1)個までの実ブロックに格納される。ただし、以上の格納方式を採らない場合でも、本発明は有効である。以下、このm個の仮想ブロックを「仮想ブロックグループ」、1つの仮想ブロックグループを割り当てた1つ以上の実ブロックを「実ブロックグループ」と呼ぶことがある。以下、本実施例で、実ブロックの最大割り当て数を(m+1)個にした理由を以下に示す。仮に、仮想ブロックグループに格納されるデータをほとんど圧縮することができなかったとする。この場合、必要な実ブロックの数はm個となるが、実ブロックに空き容量はほとんどないことになる。このとき、ブロック内の一部のデータを書き換える要求(普通のライト要求)を、ストレージコントローラ200からフラッシュパッケージ230が受け取ったとする。フラッシュメモリのブロックは書き換えができないので、フラッシュパッケージ230は、そのブロックの全データをバッファ330に読み出し、書き換え部分だけ更新して、当該ブロックを一度消去した後、ブロック全体にデータを格納しなければならない。フラッシュパッケージ230がライト要求を受け取るたびに、以上の動作が実行されると、処理時間が過大になりすぎ、実用的とは言いがたい。これを解決するため、本実施例では、もう一つ実ブロックを割り当て、空き領域を確保することにより、空き領域に追加書き込みを行うようにする。空き領域が小さくなって、書き換えデータに入らなくなった場合、消去処理(ブロックのデータを消去する処理)が行われる。これにより、消去処理をn回のライト要求につき1回実行すればよいので、性能を向上させることができる。また、消去処理の回数の削減は、フラッシュメモリの長寿命化にもつながる。本実施例では、フラッシュパッケージ230は、実ブロック数より多くの仮想ブロックをもっているように、ストレージコントローラ200に見せていることになる。ただし、本発明では、ストレージコントローラ200は、実際にフラッシュパッケージ230がいくつの空き実ブロックをもっているかを意識して、実ページの再配置を行う。本実施例では、フラッシュパッケージ230が、まだ実ブロックを割り当てていない仮想ブロックに属するアドレスを指定したライト要求をストレージコントローラ200から受け付けた場合、その仮想ブロックに実ブロックを割り当てることができる。
ページデータ格納量2104、及び、ページ圧縮後データ格納量2105は、それぞれ、当該実ページの基になっているフラッシュパッケージグループ280を構成するフラッシュパッケージ230の数だけ存在する(つまり、各実ページは、フラッシュパッケージグループ280を構成する複数のフラッシュパッケージ230に基づく記憶領域で良い)。ただし、これらの情報は、この実ページに含まれる仮想ブロックの属性情報ではなく、この実ページに対応する仮想ページのデータに関する属性情報である。したがって、この仮想ページが別の実ページに割り当てられ、現在の実ページのデータが新しい実ページにコピーされた場合、ページデータ格納量2104及びページ圧縮後データ格納量2105は、新しい実ページの管理情報として引き継がれる。ページデータ格納量2104は、当該実ページに格納したデータ量である。ページ圧縮後データ格納量2105は、当該実ページに格納した圧縮後のデータ量である。以上の二つの値(データ量)は、フラッシュパッケージ230から受け取った情報に基づき、算出される。
移動中フラグ2109、移動先実ページ情報2110、移動待ちフラグ2111は、当該実ページのデータを別の実ページに移動するときに使用される情報である。移動中フラグ2109は、この実ページのデータを別の実ページに移動中のときにONにされるフラグである。移動先実ページ情報2110は、この実ページのデータを移動している移動先の実ページのアドレスを表す情報である。移動待ちフラグ2111は、当該実ページ内のデータを移動すると決定したときにONにされるフラグである。
図8は、フラッシュパッケージ情報2500の形式である。
フラッシュパッケージ情報2500は、フラッシュパッケージ230ごとに存在する。フラッシュパッケージ情報2500は、フラッシュパッケージID2501、フラッシュパッケージ仮想容量2502、及び、仮想ブロック容量2503を含む。
フラッシュパッケージID2501は、当該フラッシュパッケージ230の識別子である。
フラッシュパッケージ仮想容量2502は、当該フラッシュパッケージ230の仮想容量を表す。
仮想ブロック容量2503は、仮想ブロックの容量である。フラッシュパッケージ仮想容量2502が表す値を仮想ブロック容量2503を表す値で割った値が、このフラッシュパッケージ230に基づく仮想ブロックの数となる。本実施例では、このフラッシュパッケージ仮想容量2502を表す値が、フラッシュパッケージ230の圧縮率などにより調整される。すでに述べたが、本実施例では、フラッシュパッケージ230がそのパッケージ230の仮想容量を決定するが、その仮想容量は、ストレージコントローラ200が決定してもよい。フラッシュパッケージ230から、仮想容量が変化した旨の通知を受けると、ストレージコントローラ200は、この値を、フラッシュパッケージ仮想容量2502に設定する。
図9は、フラッシュパッケージグループ情報2300の形式を示す。
フラッシュパッケージグループ情報2300は、フラッシュパッケージグループ280ごとに存在する。フラッシュパッケージグループ情報2300は、フラッシュパッケージグループID2301、パッケージグループRAIDタイプ2302、実ページ数2303、空き実ページ数2304、フラッシュパッケージポインタ2305、及び、使用不可実ページ数2306を含む。
フラッシュパッケージグループID2301は、当該フラッシュパッケージグループ280の識別子である。
パッケージグループRAIDタイプ2302は、当該フラッシュパッケージグループ280のRAIDタイプである。本実施例におけるRAIDタイプは、論理ボリュームRAIDタイプ2003を説明したときに述べたとおりである。
実ページ数2303は、フラッシュパッケージグループ280に基づく実ページの数を表す。空き実ページ数2304は、フラッシュパッケージグループ280に基づく複数の実ページのうちの空きの実ページ(空きの実ページ)の数を表す。使用不可実ページ数2306は、フラッシュパッケージグループ280に基づく複数の実ページのうちの使用不可能な実ページの数を表す。すでに述べたように、本実施例における1つの特徴は、圧縮率によって、フラッシュパッケージ230の仮想容量が変化する点である。フラッシュパッケージ230の仮想容量が変化したとき、実ページ数2303及び空き実ページ数2304も変化する。以下、これを説明する。まず、当該フラッシュパッケージ230の仮想容量が変化すると、当該フラッシュパッケージグループ280の実ページの数も変化することになる。これを、具体的に示す。まず、RAIDの考え方から、同一フラッシュパッケージグループ280内のフラッシュパッケージ230では使用可能な容量は等しいことが前提となる。故に、式は、
実ページ数2303=(フラッシュパッケージグループ280内のフラッシュパッケージ230の最小のフラッシュパッケージ仮想容量2502)*(フラッシュパッケージグループ280内のフラッシュパッケージ230の数)/(実ページサイズ)、
になる。従って、当該フラッシュパッケージグループ280内のフラッシュパッケージ230の最小のフラッシュパッケージ仮想容量2502が変化した場合、実ページ数2303も変化する。同様に、空き実ページ数2304も変化する。逆に、これは、使用不可になった実ページの数も変化したことになるので、使用不可実ページ数2306も変化することになる。例えば、実ページ数2303が、10増加した場合、空き実ページ数2304も10増加し、使用不可実ページ数2305は10減少する。なお、すでに、述べたが、本実施例では、フラッシュパッケージ230がこの容量を決定するが、ストレージコントローラ200が決定してもよい。
フラッシュパッケージポインタ2305は、当該フラッシュパッケージグループ280に属するフラッシュパッケージ230のフラッシュパッケージ情報2500へのポインタである。フラッシュパッケージポインタ2305の数は、当該フラッシュパッケージグループ280に属するフラッシュパッケージ230の数であるが、これは、パッケージグループRAIDタイプ2302によって決まる値である。
図4に示した空きページ管理情報ポインタ2200は、フラッシュパッケージグループ280ごとに設けられる情報である。
図10は、空きページ管理情報ポインタ2200によって管理される空き実ページの集合を表している。
この構造を、空きページ管理情報キュー2201と呼ぶ。空き実ページとは、仮想ページに割り当てられていない実ページ(仮想ページに空きの実ページ)を意味する。また、空き実ページに対応した実ページ情報を空き実ページ情報2100と呼ぶ。空きページ管理情報ポインタ2200は、先頭の空き実ページ情報2100のアドレスをさす。次に、先頭の実ページ情報2100の中の空きページポインタ2103が次の空き実ページ情報2100を指す。図10では、最後の空き実ページ情報2100の空き実ページポインタ2103は、空きページ管理情報ポインタ2200を示しているが、ヌル値でもよい。ストレージコントローラ200は、実ページを割り当てていない仮想ページに書き込み要求を受け付けると、論理ボリュームRAIDタイプ2003と同一のフラッシュパッケージグループ280の中のいずれか、例えば、空き実ページ数の最も多いフラッシュパッケージグループ280空きページ管理情報ポインタ2200から、空き実ページを探し、見つかった空き実ページを仮想ページに割り当てる。
図4に示した使用不可ページ管理情報ポインタ2700は、フラッシュパッケージグループ280ごとに設けられる情報である。
図11は、使用不可ページ管理情報ポインタ2700によって管理される使用不可実ページの集合を表している。
この構造を、使用不可ページ管理情報キュー2701と呼ぶ。その構造は、空きページ管理情報キュー2201と同じである。フラッシュパッケージ230の仮想容量が少なくなり、実ページ数2303の数が少なくなった場合、その数だけ、空きページ管理情報キュー2201で管理されている実ページ情報2100が、使用不可ページ管理情報キュー2701に移される。逆に、フラッシュパッケージ230の仮想容量が多くなり、実ページ数2303の数が多くなった場合、その数だけ、使用不可ページ管理情報キュー2701で管理されている実ページ情報2100が、空きページ管理情報キュー2201に移される。本実施例では、ストレージコントローラ200が、上位レベルの容量仮想化機能、フラッシュパッケージ230が下位レベルの容量仮想化機能をもつ。このため、ストレージコントローラ110は、フラッシュパッケージ230の仮想容量が変化しても、実ページ情報2100をすでに説明したような方法で移動させるだけで良い。実ページ情報2100が使用不可ページ管理情報キュー2701に関連付けられた場合、その実ページ情報2100に対応する実ページは、仮想ページに割り当てられなくなり、その実ページに含まれている仮想ブロックにはアクセスが発生しない。このため、実ブロックを他の仮想ブロックに割り当てることができる。つまり、実ブロックを有効に使用することができる。
次に、フラッシュパッケージ230が有する管理情報について説明する。フラッシュパッケージ230は、パッケージメモリ320内に管理情報をもつ。
図12は、パッケージメモリ320に格納される管理情報を示している。
パッケージメモリ320に、パッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300、及び、空き実ブロック情報ポインタ3400が格納される。これらの情報のうちの少なくとも1種類の情報が、下位レベルの容量仮想化技術及び/又は圧縮技術を実現するために使用される。本実施例では、フラッシュパッケージ230が、下位レベルの容量仮想化技術及び圧縮技術を実現する。ただし、本発明は、下位レベルの容量仮想化技術及び圧縮技術をストレージコントローラ200が実現してもよい。この場合、図13に示すように、図12に示した情報とほぼ同様の情報が、共有メモリ220に格納されることになる。図13に示した構成では、図13に示した情報を、ストレージコントローラ200が参照及び更新するので、図12に示したそれぞれの情報とは、若干相違が生ずる。したがって、本実施例では、フラッシュパッケージ230が、下位レベルの容量仮想化技術、圧縮技術を実現するものとする。
図14は、パッケージ情報3000の形式である。
パッケージ情報3000は、パッケージID3001、仮想パッケージ容量3002、実パッケージ容量3003、フラッシュブロック容量3004、パッケージブロック容量3005、パッケージデータ格納量3006、パッケージ圧縮データ格納量3007、内部情報格納ブロック数3009、及び、内部情報格納ブロックアドレス3010を含む。
パッケージID3001は、当該フラッシュパッケージ230の識別子である。
仮想パッケージ容量3002は、ストレージコントローラ200から見た当該フラッシュパッケージ230の仮想容量を表す。本実施例の1つの特徴は、圧縮率の変化によって、この仮想容量を、フラッシュパッケージ230が調整する点である。すでに述べたように、この調整は、ストレージコントローラ200が実施してもよい。
実パッケージ容量3003は、当該フラッシュパッケージグループ280の物理容量、具体的には、当該フラッシュパッケージグループ280内にストレージコントローラ200が実際にデータを物理的に格納できる容量を表す。
フラッシュブロック容量3004は、フラッシュメモリの消去単位であるブロックの物理的な容量を表す。
パッケージブロック容量3005は、フラッシュパッケージ230における実ブロックの容量を表す。
パッケージデータ格納量3006は、ストレージコントローラ200から受けたライトデータの圧縮前の合計値を表す。
パッケージ圧縮データ格納量3007は、ストレージコントローラ200から受けたライトデータの圧縮後の合計値を表す。
内部情報格納ブロック数3009は、内部情報(パッケージメモリ320に格納されたパッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300及び空き実ブロック情報ポインタ3400を含んだ情報)の退避先のブロックの数である。内部情報は、例えば、電源OFF時又は障害発生時に退避される。
内部情報格納ブロックアドレス3010は、内部情報が格納されている記憶領域のアドレス(パッケージメモリ320における格納領域のアドレス)を表す。重要な情報(例えば、パッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300、空き実ブロック情報ポインタ3400)は、n重に格納されてもよい。また、退避される回数はそう多くないので、ブロックの消去回数なども問題にならないと考えられる。
当該フラッシュパッケージ230がもつ実ブロックの総数を表す情報が、パッケージ情報3000に含まれて良い。例えば、内部情報格納ブロック数3009の他に、フラッシュパッケージ230から割り当て可能なブロックの数、フラッシュパッケージ230に基づく障害ブロックの数等を表す情報が、パッケージ情報3000に含まれていても良い。
図15は、チップ情報3100の形式である。
チップ情報3100は、フラッシュチップ300ごとに存在する情報である。チップ情報3100は、チップID3101、チップ内実ブロック数3102、チップ内空き実ブロック数3103、及び、接続バスID3104を含む。
チップID3101は、当該フラッシュチップ300の識別子である。
チップ内実ブロック数3102は、当該フラッシュチップ300がもつ実ブロックの数を表す。
チップ内空き実ブロック数3103は、当該フラッシュチップ300の中の空き実ブロックの数を示している。空き実ブロックとは、仮想ブロックに割り当てられていない実ブロック(仮想ブロックに割り当て可能な実ブロック)である。
接続バスID3104は、当該フラッシュチップ300が接続されているパッケージバス340の識別子である。
図16は、仮想ブロック情報3200の形式である。
仮想ブロック情報3200は、仮想ブロックグループごとに存在する情報である。仮想ブロック情報3200は、仮想ブロックのアドレス順に並んでいるものとする。最初の仮想ブロック情報3200が、先頭の仮想ブロックからm個の仮想ブロックに対応する。仮想ブロック情報3200は、仮想ブロックグループ識別子3201、実ブロック情報ポインタ3202、データ格納量3203、圧縮データ格納量3204、仮想セグメントアドレスポインタ3205、及び、圧縮仮想セグメントデータ量3206を含む。当該実施例では、フラッシュメモリの読み書き単位は「セグメント」と呼ばれる。フラッシュメモリの読み書き単位は、通常、ページと呼ばれるが、本実施例は、ページは、ストレージコントローラ200が行う容量仮想化の単位であるため、混同を避けるために、フラッシュメモリの読み書き単位は、「セグメント」と呼ぶ。本実施例では、フラッシュメモリに書き込むデータは、圧縮され、圧縮されたデータがフラッシュメモリに格納される。圧縮されたデータを格納する、フラッシュメモリのセグメントを、「実セグメント」と呼ぶことがある。圧縮前の仮想的なセグメントを、「仮想セグメント」と呼ぶことがある。本実施例では、1つ以上の仮想セグメントが、圧縮され実セグメントに格納される。
仮想ブロック識別子3201は、対応する仮想ブロックグループの識別子である。
実ブロック情報ポインタ3202は、対応する仮想ブロックグループにおける仮想ブロックに割り当てられた実ブロックの実ブロック情報3300へのポインタである。実ブロック情報ポインタ3202は、(m+1)個存在する。実ブロック情報ポインタ320は、実ブロックを割り当ていないときには、ヌル値である。当該仮想ブロックグループに割り当てられている実ブロックの数をk個(kは(m+1)以下)とすると、先頭からk個の実ブロック情報ポインタ3202が有効である。
データ格納量3203は、当該仮想ブロックグループに格納されている圧縮前のデータ量をあらわす。最大容量は、仮想ブロックグループの容量となる。圧縮データ格納量3204は、当該仮想ブロックグループに格納されている圧縮後のデータの格納量である。なお、フラッシュメモリの場合、仮想セグメントの内容が書き換えられると、別の実ブロックに格納するため、同一の仮想セグメントのデータが複数個所に存在する。データ格納量3203及び圧縮データ格納量3204は、それぞれ、最新の仮想セグメントの格納量に基づき算出された値である。
仮想セグメントアドレスポインタ3205は、対応する仮想セグメントが、当該仮想ブロックグループに割り当てた実ブロックに対応する実ブロック情報3300のうち何番目の情報かを示す識別子と、その実ブロック内のどのアドレスに格納されているかを示すポインタとを表す。圧縮仮想セグメントデータ量3206は、対応する仮想セグメントの圧縮後のデータ量を表す。なお、本実施例では、仮想セグメントアドレスポインタ3205、及び、圧縮仮想セグメントデータ量3206は、仮想セグメントごとに存在するが、2つ以上の仮想セグメントごとに情報3205及び3206のうちの少なくとも一方が存在しても、本発明は有効である。
図17は、実ブロック情報3300の形式である。
実ブロック情報3300は、実ブロックごとに存在する情報である。実ブロック情報3300は、実ブロックID3301、空き実ブロックポインタ3302、及び、実ブロック内空き容量3304を含む。
実ブロックID3301は、対応する実ブロックの識別子であり、例えば、この実ブロックが、どのフラッシュチップ300のどのアドレスに相当するブロックかを示す。
空き実ブロックポインタ3302は、対応する実ブロックが仮想ブロックに割り当てられていない(空き状態にある)時、次の空き状態にある実ブロックの実ブロック情報3300を指している。
実ブロック内空き容量3304は、対応する実ブロックの現在の空き容量を示す。パッケージプロセッサ310は、対応する実ブロックに対し、空き容量以下のライトデータを格納できる。パッケージプロセッサ310は、ライトデータを格納した後、格納したライトデータの量だけ、実ブロック内空き容量3304を削減する。
空き実ブロック情報ポインタ3400は、フラッシュチップ300対応に存在する。図18は、空き実ブロック情報ポインタ3400によって管理される空き実ブロックの集合を表している。空きブロック情報ポインタ3400は、先頭の空き実ブロックの実ブロック情報3300のアドレスをさす。次に、先頭の空き実ブロックの実ブロック情報3300の中の空き実ブロックポインタ3302が、次の空き実ブロックの実ブロック情報3300を示す。図18では、最後の空き実ブロックの実ブロック情報3300の空き実ブロックポインタ3302は、空きブロック情報ポインタ3400を示しているが、ヌル値でもよい。パッケージプロセッサ310は、実ブロックを割り当てていない仮想ブロックに属するアドレスを指定したライト要求をストレージコントローラ200から受けると、フラッシュチップ300の中のいずれかから(例えば、空き実ブロックの数の最も多いフラッシュチップ300に対応する空きブロック情報ポインタ3400を基に)、空き実ブロックを探し、見つけた空き実ブロックを仮想ブロックに割り当てる。パッケージプロセッサ310は、割り当てた空き実ブロックに、上記受けたライト要求に従うデータを書き込む。
次に、上記に説明した管理情報を用いて、ストレージコントローラ200及びフラッシュパッケージ230が実行する動作の説明を行う。
まず、ストレージコントローラ200の動作を説明する。ストレージコントローラ200の動作は、ストレージコントローラ200内のプロセッサ260が実行し、そのプログラムは、メモリ270内に格納されている。
図19は、メモリ270に格納されているプログラムが示されている。
本実施例に関するプログラムとしては、例えば、リード処理実行部4000、ライト要求受付部4100、ライトアフタ処理実行部4200、ライトセイムコマンド処理実行部4300、及びページ移動処理実行部4500がある。これらのプログラムのうちの少なくとも1つが、上位レベルの容量仮想化技術を実現するプログラムである。なお、すでに述べたが、本実施例は、下位レベルの容量仮想化技術を実現するのは、フラッシュパッケージ230であるが、下位レベルの容量仮想化技術をストレージコントローラ200が実行してもよい。その場合、下位レベルの容量仮想化技術は、ストレージコントローラ200で実行される。したがって、上位レベルのプログラムと下位レベルのプログラムの双方が、ストレージコントローラ200で実行されるので、プログラム間のインターフェイスが異なってくるが、基本的に大きな相違はない。本実施例では、下位レベルの容量仮想化技術を実現するのは、フラッシュパッケージ230であることを前提に、リード処理実行部4000、ライト要求受付部4100、ライトアフタ処理実行部4200、ライトセイムコマンド処理実行部4300、ページ移動処理実行部4500の処理フローを詳細に説明する。なお、本実施例では、ホスト110からのリード要求、ライト要求、ライトセイムコマンドは、フラッシュメモリのリード・ライト単位であるセグメント(一般のフラッシュメモリの用語ではページ)境界で発行されるものとする。もちろん、本発明は、ホスト110からのリード要求、ライト要求、ライトセイムコマンドが、セグメントの一部のみを指定した場合にも有効である。
また、以下の説明では、プログラムを主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit))によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、ストレージコントローラ、フラッシュパッケージ、或いはストレージシステムが行う処理としても良い。
図20は、リード処理実行部4000の処理フローである。リード処理実行部4000は、ストレージコントローラ200が、ホスト110からリード要求を受け付けたときに実行される。
ステップ5000:リード処理実行部4000は、リード元仮想ページ(ホスト110からのリード要求で指定されているリード対象アドレスが属する仮想ページ)に対する、リード元仮想ページ内の相対アドレスを計算する。
ステップ5001:リード処理実行部4000は、リード対象となったデータが、キャッシュメモリ210にヒットしているかをチェックする。これは、公知の技術である。ヒットしている場合、ステップ5010へジャンプする。
ステップ5002:ミスしている場合、まず、リード処理実行部4000は、フォーマット情報2005が有効かをチェックする。有効でなければ、ステップ5004へジャンプする。
ステップ5003:フォーマット情報2005が有効な場合、そのフォーマット情報2005は、リード元領域(特定された相対アドレスに従う記憶領域)に繰り返し情報が格納されていることを意味する。このため、リード処理実行部4000は、キャッシュメモリ210上に、この繰り返し情報を格納して、ステップ5010へジャンプする。
ステップ5004:ここでは、リード対象としているデータをキャッシュメモリ210にロードする必要がある。ます、当該ステップでは、リード処理実行部4000は、リード元仮想ページに割り当てられている実ページに対応する実ページ情報2100を、論理ボリューム情報2000の実ページポインタ2004から獲得する。
ステップ5005:リード処理実行部4000は、獲得した実ページ情報2100のパッケージグループ2101及び実ページアドレス2102を基に、リード元仮想ページに割り当てられている実ページ(図20においてリード元実ページ)の基になっているフラッシュパッケージグループ(図20においてリード元パッケージグループ)280と、リード元パッケージグループ280内の相対アドレスとを特定する。
ステップ5006:リード処理実行部4000は、ステップ5005で得たリード元パッケージグループ280内の相対アドレスと、リード元パッケージグループ280に対応したパッケージグループ内RAIDタイプ2302とを基に、リード元実ページ内の相対アドレスを算出する。リード処理実行部4000は、算出した実ページ内相対アドレスと、リード元パッケージグループに対応するパッケージグループ内RAIDタイプ2302及びフラッシュパッケージポインタ2305とを基に、どのフラッシュパッケージ230のどのアドレスにアクセスするかを特定する。
ステップ5007:リード処理実行部4000は、ステップ5006で特定したフラッシュパッケージ230に対し、ステップ5006で特定したアドレスを指定したリード要求を送信する。
ステップ5008:リード処理実行部4000は、ステップ5007でのリード要求の送信先のフラッシュパッケージ230からデータが送られてくるのを待つ。
ステップ5009:リード処理実行部4000は、ステップ5007でのリード要求に応答してフラッシュパッケージ230から送られてきたデータをキャッシュメモリ210に格納する。
ステップ5010:リード処理実行部4000は、ステップ5009でキャッシュメモリ210に格納したデータ(リードデータ)をホスト110へ送り、処理を完了する。
図21は、ライト要求受付部4100の処理フローである。ライト要求受付部4100は、ストレージコントローラ200がホスト110からライト要求を受け付けたときに実行される。
ステップ6000:ライト要求受付部4100は、ライト先仮想ページ(ホスト110からのライト要求が指定するライト対象アドレスが属する仮想ページ)に対する、ライト先仮想ページ内の相対アドレスを計算する。
ステップ6001:ライト要求受付部4100は、ライト先ボリューム(ライト要求で指定されている論理ボリューム)に対応した論理ボリューム情報2000内の実ページポインタ2004を基に、ライト先仮想ページに実ページが割り当てられているかをチェックする。割り当てられている場合、ステップ6005へジャンプする。
ステップ6002:当該ステップでは、ライト要求受付部4100は、ライト先仮想ページに実ページを割り当てる。ライト先ボリュームに対応する論理ボリューム情報2000内のRAIDタイプ2002と、フラッシュパッケージグループ情報2300内のパッケージグループRAIDタイプ2302及び空き実ページ数2304等を基に、ライト要求受付部4100は、どのフラッシュパッケージグループ280に基づく実ページを割り当てるかを決める。その後、ライト要求受付部4100は、決定したフラッシュパッケージグループ(ライト先パッケージグループ)280に対応する空きページ管理情報ポインタ2200を基に、先頭の空き実ページ情報2100を、当該実ページポインタ2004が示すようにする。これにより、ライト先仮想ページに実ページが割り当てられたことになる。なお、空きページ管理情報ポインタ2200は、次の実ページ情報2100(仮想ページに割り当てた実ページの実ページ情報2100の中の空きページポインタ2103が示す実ページ情報2100)を示すようにし、さらに、仮想ページに割り当てた実ページの実ページ情報2100の中の空きページポインタ2103をヌルにする。また、ライト要求受付部4100は、当該実ページに対応するフラッシュパッケージグループ管理情報の空き実ページ数2304の数を減らす。仮想ページを実ページに割り当てる処理を、本実施例では、ライト要求を受け付けたときに実施されるが、本発明では、この割り当て処理は、フラッシュパッケージ230へデータを格納するまでに実行されればよい。
ステップ6003:ライト要求受付部4100は、フォーマット情報2005が有効であるかをチェックする。有効でなければ、ステップ6005へジャンプする。
ステップ6004:ライト要求受付部4100は、フォーマット情報2005を無効にする。
ステップ6005:ライト要求受付部4100は、ホスト110からのライト要求に従うライトデータを、キャッシュメモリ210に格納する。
フラッシュパッケージグループ280は、RAID構成をとるので、キャッシュメモリ210上に格納したライトデータに対して、冗長データを生成する必要がある。ただし、これは、公知の方法であるので、詳細に説明はしない。また、実ページの中には、冗長データを格納する領域も含まれているので、ライトデータに対応する冗長データの実ページ内の格納アドレスも一意に定まる。冗長データも、一度、キャッシュメモリ210に格納する。なお、キャッシュメモリ210上の冗長データも、ライトデータと同様に、どのフラッシュパッケージ230のどのアドレスに書き込むべきかを示す情報をつけておく。ライトデータ、冗長データは、ライトアフタ処理実行部4200によって、フラッシュパッケージ160に書き込まれるが、ライトアフタ処理実行部4200から見ると、いずれもフラッシュパッケージ230へ書き込むデータなので、両者を区別する必要はない。同様に、フラッシュパッケージ230も、両者を区別する必要はない。
図22は、ライトアフタ処理実行部4200の処理フローである。ライトアフタ処理実行部4200は、プロセッサ260によって適宜に実行される。ライトアフタ処理実行部4200は、ホスト110からのライトデータ(及び冗長データ)をフラッシュパッケージ230に書き込む。ライトアフタ処理実行部4200は、ライトデータ、冗長データの両者を、フラッシュパッケージ230に書き込むべきデータとして、両者を区別せずに処理する。
ステップ7000:ライトアフタ処理実行部4200は、キャッシュメモリ210をサーチして、フラッシュパッケージ230に書き込むべきデータを決める。ライトアフタ処理実行部4200は、見つけたデータに関連付けられている情報(例えば、フラッシュパッケージ230のIDとそのパッケージ230におけるライト先アドレスに関する情報)を特定し、特定されたライト先(例えば、フラッシュパッケージ230のID及びライト先アドレス)を指定したライト要求を、ライト先のフラッシュパッケージ230に発行する。なお、このとき、ライトアフタ処理実行部4200は、ライト先に属する仮想ページに割り当てられている実ページに対応する実ページ情報2100の移動中フラグ2109をチェックして、そのフラグ2109がonの場合、その実ページは移動中であるため、当該ライト先を指定したライト要求の実行を中止し、別のデータをキャッシュメモリ210から探す。
ステップ7001:ライトアフタ処理実行部4200は、ライトデータをフラッシュパッケージ230へ送る。
ステップ7002:ライトアフタ処理実行部4200は、フラッシュパッケージ230からライト要求の完了報告を待つ。
ステップ7003:ライトアフタ処理実行部4200は、フラッシュパッケージ230からの当該ライト要求に関する完了報告をチェックする。完了報告は、例えば、データ格納量(ステップ7001で送ったライトデータの量)及び圧縮後データ量(ステップ7001で送ったライトデータの圧縮後の量)を表す情報を含む。この情報は、完了報告とは別のタイミングで、フラッシュパッケージ230からストレージコントローラ200に送られても良い。ライトアフタ処理実行部4200は、当該ライト要求に対する完了報告が含む情報が表すデータ格納量及び圧縮後データ量を特定し、ライト先の実ページに対応するページデータ格納量2104に、特定したデータ格納量を加算し、且つ、ライト先の実ページに対応するページ圧縮後データ格納量2105に、特定した圧縮後データ格納量を加算する。
ステップ7004:ここでは、ライトアフタ処理実行部4200は、仮想容量に変化があったフラッシュパッケージ230が有るか否かをチェックする。ない場合、処理が終了する。
ステップ7005:仮想容量に変化があったフラッシュパッケージ230がある場合、ライトアフタ処理実行部4200は、変化後の仮想容量を、仮想容量に変化があったフラッシュパッケージ230に対応するフラッシュパッケージ仮想容量2502に設定する。次に、ライトアフタ処理実行部4200は、仮想容量に変化があったフラッシュパッケージ230を含むフラッシュパッケージグループ280を構成する複数のフラッシュパッケージ230に対応した複数のフラッシュパッケージ仮想容量2502のうちの最小値が変化したかをチェックする。変化した場合、この変化値にあわせて、ライトアフタ処理実行部4200は、そのフラッシュパッケージグループ280に対応する実ページ数2303及び空き実ページ数2304を更新する。また、ライトアフタ処理実行部4200は、その数にあわせて、空きページ管理情報キューと使用不可ページ管理情報キューの間で、実ページ情報2100を移動する。その後、ライトアフタ処理実行部4200は、ページ移動処理(ページ移動処理実行部4500)をコールする。その後、ライトアフタ処理実行部4200は、処理を完了する。
図23は、ライトセイムコマンド処理実行部4300の処理フローである。ライトセイムコマンド処理実行部4300は、ライトセイムコマンドを、ストレージコントローラ200がホスト110から受けたときに実行される。ライトセイムコマンドは、ストレージシステム100の容量仮想化機能に対応して設けられた機能である。ライトセイムコマンドは、ある記憶領域に短いデータパターンを繰り返し書き込むよう指示するコマンドである。ストレージシステム100は、このデータパターンをフラッシュメモリに書き込むのではなく、指定された記憶領域を含む仮想ページにそのデータパターンが繰り返し格納されているということを記憶して、その仮想ページに実ページが割り当てられていればその実ページを解放する。これにより、使用される実ページの数を削減することができる。一般的に、HDD(Hard Disk Drive)が記憶媒体として採用されているシステムでの容量仮想化機能においては、実ページの解放の際に、HDDの物理的な処理は発生しない。しかし、フラッシュメモリが記憶媒体として採用される本実施例では、実ブロックを他の仮想ブロックに割り当てるためには、実ブロックの消去処理を実行する必要がある。したがって、実ブロックの解放には、その実ブロックの消去処理を行うことになる。本実施例では、ストレージコントローラ200が、ライトセイムコマンドを受けたとき、フラッシュパッケージ230に、実ブロックの消去処理を要求する。また、ライトセイムコマンドを、フラッシュパッケージ230に送り、以上の処理をフラッシュパッケージ230が実行しても本発明は有効である。あるいは、ホスト110が、ある記憶領域を解放せよという、より直接的なコマンドを発行して、ストレージコントローラ200、あるいは、フラッシュパッケージ230が、ライトセイムコマンドを受け取ったときと同じ処理を実行しても本発明は、有効である。なお、通常のライトコマンドで、オール0などの繰り返し情報を書き込んだ場合にも、ストレージコントローラ200、あるいは、フラッシュパッケージ230が、繰り返し情報を認識して、ライト先の仮想ブロックに割り当てられている実ブロックを解放させても、本発明は有効である。
ステップ8000:ライトセイムコマンド処理実行部4300は、受けたライトセイムコマンドで指定されたライト先情報(例えばアドレス)を基に、当該コマンドの処理対象となる仮想ページの集合を判別する。また、この際、仮想ページ全体が、当該コマンドの処理対象となっているものと、仮想ベージの一部が処理対象となっているものに分類する。仮想ページ全体が指定されている場合、ライトセイムコマンド処理実行部4300は、その仮想ページに対応するフォーマット情報2005に、データパターンを設定する。
ステップ8001:次に、フラッシュパッケージ230に送る情報について述べる。フラッシュパッケージ230のアドレス空間は、仮想セグメントベースの仮想アドレス空間なので、本実施例では、ライトセイムコマンドで指定された領域を、フラッシュパッケージのアドレス空間に変換して、要求をおくる。(この変換は、公知の技術なので、詳細に説明しない。)ただし、RAID5のように、N個のデータから1つの冗長データを生成する場合、当該コマンドで、ストライプグループ全体のN個のデータを格納した領域が指定されたとき、冗長データを格納した領域を解放することができる。一方、N個のうちの一部の領域しか指定されなかった場合、その繰り返し情報を冗長データに反映させる必要があるので、その冗長データを格納した領域は更新される必要がある。当該ステップでは、当該コマンドの指定により、更新が必要な領域と、解放可能な領域とに分類される。
ステップ8002:データの更新が必要な領域がない場合、ステップ8004へジャンプする。
ステップ8003:ライトセイムコマンド処理実行部4300は、フラッシュパッケージ230に書き込む、冗長データを生成し、その冗長データをキャッシュメモリ210に格納する。この際、どのプラッシュパッケージ230のどの領域に書き込むのかという情報が、その冗長データに関連付けられる。この後、指定された繰り返し情報は、図22に示したライトアフタ処理部4200によって、フラッシュパッケージ230へ書き込まれる。この後、解放できる領域がない場合、処理が終了する。
ステップ8004:ライトセイムコマンド処理実行部4300は、ステップ8001で判別したフラッシュパッケージ230とその記憶領域を、そのフラッシュパッケージ230へ伝え、対応する領域の解放を要求する。なお、ここでは、フラッシュパッケージ230に要求する領域は、実ページ単位に分割されて発行されるものとする。当然、実ページに含まれるすべての領域が指定される場合と、一部の仮想領域が指定されるケースがある。この要求は、フラッシュパッケージグループ280を構成する一つ以上の任意の個数のフラッシュパッケージ230に発行される。
ステップ8005:ライトセイムコマンド処理実行部4300は、ステップ8004での要求の発行先のフラッシュパッケージ230から処理報告を待つ。
ステップ8006:ライトセイムコマンド処理実行部4300は、フラッシュパッケージ230から当該要求に関する完了報告をチェックする。まず、ライトセイムコマンド処理実行部4300は、当該要求に対してフラッシュパッケージ230から受けた完了報告が含む情報から、データ格納量及び圧縮後データ量を表す情報の処理を行う。具体的には、ライトセイムコマンド処理実行部4300は、1つの実ページに含まれる仮想ブロックグループに対応したデータ格納量と圧縮データ格納量の変化値を、その実ページに対応するページデータ格納量2104と、ページ圧縮後データ格納量2105に加算する。
ステップ8007:ここでは、ライトセイムコマンド処理実行部4300は、それぞれのプラッシュパッケージ230の仮想容量に変化があったか否かをチェックする。仮想容量に変化があったフラッシュパッケージ230が一つもない場合、ステップ8009へジャンプする。
ステップ8008:ライトセイムコマンド処理実行部4300は、変化後の仮想容量を、仮想容量に変化があったフラッシュパッケージ230に対応するフラッシュパッケージ仮想容量2502に設定する。次に、ライトセイムコマンド処理実行部4300は、仮想容量に変化があったフラッシュパッケージ230を含むフラッシュパッケージグループ280を構成する複数のフラッシュパッケージ230に対応した複数のフラッシュパッケージ仮想容量2502のうちの最小値が変化したかをチェックする。変化した場合、この変化値にあわせて、ライトセイムコマンド処理実行部4300は、そのフラッシュパッケージグループ280に対応する実ページ数2303及び空き実ページ数2304を更新する。また、ライトセイムコマンド処理実行部4300は、その数にあわせて、空きページ管理情報キューと使用不可ページ管理情報キューの間で、実ページ情報2100を移動する。その後、ライトセイムコマンド処理実行部4300は、ページ移動処理(ページ移動処理実行部4500)をコールする。その後、ライトアフタ処理実行部4300は、処理を完了する。
ステップ8009:まだ、解放可能な領域を含む実ページの中で、フラッシュパッケージ230に要求を発行していない実ページがあれば、ステップ8004にジャンプする。なければ、ライトセイムコマンド処理実行部4300は処理を完了する。
図24は、ページ移動処理実行部4500の処理フローである。ページ移動処理実行部4500は、ライトアフタ処理実行部4200、ライトセイムコマンド処理実行部4300からコールされる。その際、仮想容量に変化があったフラッシュパッケージ230を含むフラッシュパッケージグループ280が指定される。
ステップ11000:ページ移動処理実行部4500は、指定されたフラッシュパッケージグループ(図24の説明において「対象グループ」と言う)280に対応する空き実ページ数2304が、所定の閾値以下になっていないか否か(つまり、対象グループ280に基づく空き容量が多いか否か)を判断する。この判断の結果が否定的の場合、処理が終了する。
ステップ11001:ページ移動処理実行部4500は、対象グループを構成する複数のフラッシュパッケージ230に対応した実ページ情報2100をサーチし、ページ圧縮後データ格納量2105が表す値が大きい実ページ情報2100を見つける。ページ圧縮後データ格納量2105が表す値が大きい実ページとは、対象グループに基づく全実ページのうちページ圧縮後データ格納量2105が表す値が上位X%(Xは0より大きい値)である1以上の実ページであっても良いし、ページ圧縮後データ格納量2105が表す値が所定の閾値Z(Zは0より大きい値)以上である実ページでも良い。ページ移動処理実行部4500は、見つけた実ページ情報2100に対応する実ページを、移動の対象候補とし、その実ページに対応する移動待ちフラグ2111をオンにする。
ステップ11002:ここでは、ページ移動処理実行部4500は、移動先となるフラッシュパッケージグループ280を選択する。本実施例では、フラッシュパッケージグループ280は一つ選択されるが、もちろん、移動先として複数のフラッシュパッケージグループ280が選択されても良い。本実施例では、例えば、ページ移動処理実行部4500は、空き実ページ数2104が比較的少ないフラッシュパッケージグループ280(例えば空き実ページ数2104が最も少ない或いは所定の閾値未満であるフラッシュパッケージグループ280)を移動先として選択する。次に、ページ移動処理実行部4500は、選択した移動先のフラッシュパッケージグループ(図24の説明において「移動先グループ)280の中のどの実ページを移動先とするかを決定する。移動先の実ページを決めると、ページ移動処理実行部4500は、移動先グループ280に対応する空きページ管理情報ポインタ2200がさす実ページ情報2100を、移動元の実ページの実ページ情報2100のコピー先実ページ情報ポインタ2110に設定する。ページ移動処理実行部4500は、空きページ管理情報ポインタ2200を、次の空きの実ページに対応するページ管理情報2100に更新する。以上の処理が、ステップ11001で移動を決定したすべての実ページに対して実行される。以上で、各移動元実ページについて移動先ページが決まったことになる。
ステップ11003:ここでは、ページ移動処理実行部4500は、移動元となる実ページの実ページ情報2100を決定する。具体的には、ページ移動処理実行部4500は、移動待ちフラグ2111がオンになっている実ページ情報2100を見つける。ない場合、処理が終了し、呼び出し元に戻る。
ステップ11004:ここでは、ページ移動処理実行部4500は、見つけた実ページ情報2100に対応する実ページがフラッシュパッケージ230のどの領域になるかを算出する。見つかった実ページ情報2100のパッケージグループ2101が示すフラッシュパッケージグループ情報2300が、該当するフラッシュパッケージグループ情報2300である。このフラッシュパッケージグループ情報2300に格納されたフラッシュパッケージポインタ2305が示すフラッシュパッケージ情報2500に対応するフラッシュパッケージ230が、コピー元の実ページの基になっているフラッシュパッケージ230である。次に、実ページ情報2100内の実ページアドレス2102と、フラッシュパッケージ情報2500のブロック容量2503から、ページ移動処理実行部4500は、それぞれのフラッシュパッケージ230の中の移動対象となる領域を、すべてのフラッシュパッケージ230に関して特定する。
ステップ11005:ページ移動処理実行部4500は、移動元となる実ページの基になっているフラッシュパッケージグループ280を構成する各フラッシュパッケージ230に、指定した領域の中で、データを格納した領域のデータを、キャッシュメモリ210に移動するよう要求する。
ステップ11006:ページ移動処理実行部4500は、ステップ11005での要求の発行先のフラッシュパッケージ230からの完了報告をまつ。
ステップ11007:フラッシュパッケージ230からは、各領域(本実施例では、仮想セグメント)ごとに、仮想セグメントにデータが格納されていたか、いないかの情報と、データが格納されていた場合、その圧縮後のデータ量と格納されていたデータが、フラッシュパッケージ230から送られてくる。ページ移動処理実行部4500は、これらの情報を、キャッシュメモリ210に格納する。
ステップ11008:ページ移動処理実行部4500は、ここでは、移動先実ページが、その移動元実ページの基になっているフラッシュパッケージグループ280を構成するフラッシュパッケージ230の集合と、それぞれのフラッシュパッケージ230のどの仮想セグメントの集合とに該当するかを算出する。この場合、移動元の実ページに対応する実ページ情報2100の移動先実ページアドレスが示す実ページ情報2100が、移動先の実ページに対応する実ページ情報2100となる。実ページ情報2100から、フラッシュパッケージグループ280を構成するフラッシュパッケージ230の集合と、それぞれのフラッシュパッケージ230のどの領域になるかを算出する処理は、ステップ11004で説明したので省略する。
ステップ11009:ページ移動処理実行部4500は、移動先となる実ページが割り当てられているフラッシュパッケージグループ280を構成する各フラッシュパッケージ230に、指定した領域にデータを格納するよう要求する。このとき、各フラッシュパッケージ230に送られるのは、ステップ1107でキャッシュメモリ210に格納した情報(移動元のフラッシュパッケージ230から送られてきた情報)と、移動元の実ページの中で、データを格納している領域のデータとである。
ステップ11010:ページ移動処理実行部4500は、ステップ11009での要求の発行先のフラッシュパッケージ230からの完了報告をまつ。
ステップ11011:ページ移動処理実行部4500は、移動元実ページを空き実ページとして管理し、且つ、移動元実ページが割り当てられていた仮想ページにその実ページに代えて移動先実ページを割り当てる。具体的には、例えば、ページ移動処理実行部4500は、移動元の実ページに対応する実ページ情報2100を空きページ管理情報ポインタ2200につなぎ、移動元の実ページに対応する実ページ情報2100を示していた実ページポインタ2004を移動先の実ページ情報を示すようにする。また、ページ移動処理実行部4500は、移動元実ページに対応する実ページ情報2100内のページデータ格納量2104及びページ圧縮後データ格納量2105を、移動先実ページに対応する実ページ情報2100にコピーする。その後、ページ移動処理実行部4500は、移動元実ページ及び移動先実ページの双方に対応する実ページ情報2100における移動中フラグ2109、移動先実ページポインタ2110及び移動待ちフラグ2111を、クリアする。
ステップ11012:ページ移動処理実行部4500は、移動元のフラッシュパッケージグループ280に対応するフラッシュパッケージグループ情報(以下、移動元グループ情報)2300と移動先のフラッシュパッケージグループ280に対応するフラッシュパッケージグループ情報(以下、移動先グループ情報)2300とを更新する。具体的には、移動元グループ情報2300内の空き実ページ数2304が表す値から1が削減され、移動先グループ情報2300内の空き実ページ数2304が表す値に1が加算される。この後、次に移動対象とする実ページを探すために、ステップ11003にジャンプする。
次に、フラッシュパッケージ230が実行する動作の説明を行う。フラッシュパッケージ230の動作の大部分は、パッケージプロセッサ310がコンピュータプログラムを実行することにより行われ、そのプログラムは、パッケージメモリ320に格納されている。
図25は、パッケージメモリ320が記憶するプログラムを示している。
パッケージメモリ320は、データリード処理実行部12000、データライト処理実行部12100、仮想ブロック解放処理実行部12200、仮想ブロック移動処理実行部12300、仮想ブロック格納処理実行部12400、及び仮想容量判定処理部12500を記憶する。これらのプログラムのうちの少なくとも1つは、下位レベルの容量仮想化技術を実現するためのプログラムである。本実施例では、フラッシュパッケージ230が、下位レベルの容量仮想化技術を実現する。ただし、本発明は、下位レベルの容量仮想化技術をストレージコントローラ200で実現してもよい。この場合、図26に示すように、図25に示したプログラムとほぼ同様のプログラムが、メモリ270に格納されることになる。図26に示した構成では、これらのプログラムは、ストレージコントローラ200が実行するので、図25に示したプログラムとは若干相違が生ずるだけである。したがって、本実施例では、フラッシュパッケージ230が、下位レベルの容量仮想化技術を実現するものとし、図25に示したデータリード処理実行部12000、データライト処理実行部12100、仮想ブロック解放処理実行部12200、仮想ブロック移動処理実行部12300、仮想ブロック格納処理実行部12400及び仮想容量判定処理部12500の処理フローを詳細に説明する。
図27は、データリード処理実行部12000の処理フローである。データリード処理実行部12000は、フラッシュパッケージ230がストレージコントローラ200からリード要求を受けたときに実行される。なお、図27の処理フローは、一つの仮想ブロックグループに格納されたデータをリードする処理のフローである。ただし、本発明は、リード要求で、複数の仮想ブロックグループに格納されたデータを読み出すようにした場合も有効である。また、図27の処理フローは、仮想セグメント単位のデータをリードする際の処理フローである。ただし、本発明は、リード要求で、仮想セグメントの一部のデータを読み出すようにした場合も有効である。
ステップ13000:データリード処理実行部12000は、受けたリード要求で指定されているリード対象アドレスと、パッケージブロック容量3005とから、対応する仮想ブロックグループ(リード元の仮想ブロックグループ)と、リード元の仮想ブロックグループ内の相対アドレスとを算出する。これにより、リード元の仮想ブロックグループに対応する仮想ブロック情報3200を特定することが可能となる。また、仮想ブロックグループ内の相対アドレスから、対応する仮想セグメントが特定される。その仮想セグメントに対応する仮想セグメントアドレスポインタ3205から、その仮想セグメントが、実ブロック内のどのアドレスに格納されているか(割り当てられているか)が特定される。
ステップ13001:データリード処理実行部12000は、ステップ13000で特定した情報(実ブロック内のどのアドレスに格納されているかを示す情報)が、繰り返し情報を格納していることを意味する情報でなければ、ステップ13003へジャンプする。
ステップ13002:データリード処理実行部12000は、圧縮仮想セグメントデータ量3206に格納された繰り返し情報を、対応する仮想セグメント分の長さだけバッファ330に格納する。この後、ステップ13008へジャンプする。
ステップ13003:データリード処理実行部12000は、リード元のそれぞれの仮想ブロックに割り当てた実ブロックに対応する実ブロック情報3300を、リード元のそれぞれの仮想ブロックに対応する仮想ブロック情報3200の実ブロック情報ポインタ3202を基に特定する。
ステップ13004:データリード処理実行部12000は、特定したそれぞれの実ブロック情報3300の実ブロック識別子3301から識別される実ブロックが、どのフラッシュチップ300のどの先頭アドレスから格納されているかを特定する。次に、データリード処理実行部12000は、該当する仮想セグメントアドレスポインタ3205から、当該リード要求を基に特定されたそれぞれの仮想セグメントが、当該フラッシュチップ300のどの当該アドレスに格納されているかを算出する。なお、仮想セグメントが、実セグメントの一部に格納されている場合、仮想セグメントを含む実セグメント全体が、読み出し対象となる。
ステップ13005:データリード処理実行部12000は、ステップ13004で特定したフラッシュチップ300に対応したチップ情報3100をアクセスして、当該フラッシュチップ300が接続されているパッケージバス340を識別し、対応するバス転送装置350を特定する。
ステップ13006:データリード処理実行部12000は、ステップ13005で特定したバス転送装置350に、ステップ13004で特定したフラッシュチップ300のステップ13004で特定したアドレスからバッファ330にデータを転送するよう指示する。また、圧縮・伸長回路360Bに、データ転送と同期してデータを伸長するよう指示する。
ステップ13007:この後、転送が完了するのを待つ。
ステップ13008:データリード処理実行部12000は、バッファ330に格納したデータ(ステップ13001で、バッファに格納したデータ、あるいは、ステップ13006の指示によりステップ13007で伸長されたデータ)の中から、要求された仮想セグメントのデータを、ストレージコントローラ200に送る。この後、処理を完了する。
図28と図29は、データライト処理実行部12100の処理フローである。データライト処理実行部12100は、フラッシュパッケージ230がストレージコントローラ200からライト要求を受けたときに実行される。なお、本実施例で示す図28と図29の処理フローは、一つの仮想ブロックグループに格納するデータをライトする処理のフローである。ただし、本発明は、ライト要求で複数の仮想ブロックグループにデータを書き込むようにした場合も有効である。また、図28の処理フローは、仮想セグメント単位のデータをライトする際の処理フローである。ただし、本発明は、ライト要求で、仮想セグメントの一部のデータを書き込むようにした場合も有効である。
ステップ14000:データライト処理実行部12100は、受けたライト要求で指定されているライト対象アドレスと、パッケージブロック容量3005とから、対応する仮想ブロックグループとアクセスする仮想ブロックグループの相対アドレスを計算する。これにより、ライト先の仮想ブロックグループに対応する仮想ブロック情報3200を特定することが可能となる。また、仮想ブロックグループ内の相対アドレスから、対応する仮想セグメントが特定される。その仮想セグメントに対応する仮想セグメントアドレスポインタ3205から、その仮想セグメントが、実ブロック内のどのアドレスに格納されているか(割り当てられているか)が特定される。
ステップ14001:データライト処理実行部12100は、ライト要求に従うライトデータをバッファ330に格納する。なお、この際、データライト処理実行部12100は、圧縮・伸長回路360Aに、圧縮を指示する。バッファ330には、圧縮されたライトデータが格納される。
ステップ14002:データライト処理実行部12100は、ライト先の仮想ブロックグループに対応する仮想ブロック情報3200の最初の実ブロック情報ポインタ3202を特定する。この値がヌルかどうか、すなわち、実ブロックが割り当てられているかが、チェックされる。割り当てていれば、ステップ14006へジャンプする。
ステップ14003:データライト処理実行部12100は、ライト先の仮想ブロックグループに空きの実ブロックを割り当てる。ここで割り当てられる実ブロックは、消去処理が済んでいてデータは格納されていない実ブロックである。データライト処理実行部12100は、各チップ情報3100のチップ内空き実ブロック数3103を参照して、どのフラッシュチップ300の実ブロックを割り当てるかを決める。その後、データライト処理実行部12100は、決定したフラッシュチップ300の空きブロック情報ポインタ3400を参照して、先頭の実ブロック情報3300を、当該仮想ブロックグループに対応する仮想ブロック情報3200の最初の空き実ブロックポインタ3302が示すようにする。これで、仮想ブロックグループに最初の実ブロックを割り当てたことになる。なお、データライト処理実行部12100は、空きブロック情報ポインタ3400を、次の実ブロック情報3300(仮想ブロックに割り当てた実ブロックの実ブロック情報3300の中の空き実ブロックポインタ3302が示す実ブロック情報3300)を示すよう更新する。また、データライト処理実行部12100は、仮想ブロックに割り当てられた実ブロックの実ブロック情報3300の中の空き実ブロックポインタ3302をヌルにする。また、データライト処理実行部12100は、当該実ブロックに対応するチップ情報3100のチップ内空き実ブロック数3103が表す値を減らす。
ステップ14004:さらに、データライト処理実行部12100は、ライト先の仮想セグメントに対応する仮想セグメントポインタに、ライト先仮想ブロックに割り当てられた実ブロックの識別子とその実ブロックの先頭アドレスとをセットする。データライト処理実行部12100は、ライト先仮想ブロックグループに対応する圧縮後仮想セグメントデータ量3206に、圧縮・伸長回路360Aから特定された値(圧縮後のライトデータの量)が示す値をセットする。また、同じ値を、データライト処理実行部12100は、圧縮データ格納量3204にセットする。さらに、同じ値を、データライト処理実行部12100は、パッケージ圧縮後データ格納量3007が表す値に加える。さらに、データライト処理実行部12100は、対象となるライトデータの量である、仮想セグメントの容量を、データ格納量3203にセットする。また、同じ値を、データライト処理実行部12100は、ライト先のフラッシュパッケージに対応するパッケージデータ格納量3006に加える。また、データライト処理実行部12100は、ストレージコントローラ200から受けたライトデータの量とそのライトデータの圧縮後のデータ量とを表す情報を、ストレージコントローラ200に返す値として記憶資源(例えばプロセッサ310内のレジスタ、或いは、メモリ320)に格納する。
ステップ14005:データライト処理実行部12100は、ライト先のフラッシュチップ300のライト先のアドレスへバッファ330からデータを書き込むようバス転送装置350に指示する。この後、ステップ14014にジャンプする。
ステップ14006:データライト処理実行部12100は、ライト先仮想ブロックグループに対応する仮想ブロック情報3200の最後の実ブロック情報ポインタ3202が示す実ブロック情報3300の実ブロック識別子3301を参照して、対応する実ブロックが、どのフラッシュチップ300のどの先頭アドレスから格納されているかを特定する。
ステップ14007:データライト処理実行部12100は、ライト先の実ブロック(ライト先の仮想ブロックに割り当てられた実ブロック)に対応する実ブロック情報3300の実ブロック内空き領域3304とバッファ330に格納したライトデータの量とを基に、受けたデータを、ライト先実ブロックの空き領域に書き込めるかをチェックする。書き込めない場合、ステップ14016へジャンプする。
ステップ14008:データライト処理実行部12100は、ライト先仮想セグメントの仮想セグメントアドレスポインタ3205がヌルか、また、繰り返し情報を格納しているかを判断する。いずれかが成立する場合、ステップ14010へジャンプする。
ステップ14009:ヌルでないか、繰り返し情報が格納されていない場合には、データライト処理実行部12100は、当該圧縮・伸長回路360Aが示す値から圧縮仮想セグメントデータ量3206が表す値を減算した値Kを、圧縮データ格納量3204が表す値に加える。さらに、データライト処理実行部12100は、同じ値Kを、パッケージ圧縮データ格納量3007が表す値に加える。この後、データライト処理実行部12100は、圧縮・伸長回路360Aが示す値を圧縮仮想セグメントデータ量3206が表す値にセットする。また、データライト処理実行部12100は、今回書き込んだライトデータの量としては、0を、圧縮後のデータの量としては、圧縮仮想セグメントデータ量3206が表す値に加えた値を、ストレージコントローラ200に返す値として、記憶資源(例えばプロセッサ310内のレジスタ、或いは、メモリ320)に格納する。この後、ステップ14012へジャンプする。
ステップ14010:ヌルか、繰り返し情報を格納している場合、当該圧縮・伸長回路360が示す値を、圧縮データ格納量3204に加える。さらに、同じ値を、パッケージ圧縮データ格納量3007に加える。この後、圧縮・伸長回路が示す値を圧縮仮想セグメントデータ量3206にセットする。また、今回書き込んだライトデータ量に関しては、ストレージコントローラ200から受け取った圧縮前のデータ量を、圧縮後のデータに関しては、当該圧縮・伸長回路360が示す値を、ストレージコントローラ200に返す値として、記憶資源(例えばプロセッサ310内のレジスタ、或いは、メモリ320)に格納する。
ステップ14011:データライト処理実行部12100は、ライト先の実ブロックに対応する実ブロック内空き容量3304が表す値から、今回受けたライトデータの量(圧縮後の値)を減算する。データライト処理実行部12100は、ライト先仮想セグメントに対応する仮想セグメントアドレスポインタ3205に、ライト先仮想ブロックグループに対応する仮想ブロック情報3200の最後の実ブロックポインタ3202と、特定された相対アドレスとをセットする。
ステップ14012:データライト処理実行部12100は、ライトデータを格納するフラッシュチップ300に対応したチップ情報3100を基に、当該フラッシュチップ300が接続されているパッケージバス340を識別し、そのバス340に接続されているバス転送装置350を特定する。
ステップ14013:データライト処理実行部12100は、ステップ14012で特定したバス転送装置350に、ライト先のフラッシュチップ300のライト先のアドレスにバッファ330からライトデータを書き込むよう指示する。
ステップ14014:この後、書き込みが完了するのを待つ。
ステップ14015:データライト処理実行部12100は、ストレージコントローラ200に、ライト要求が完了したことの完了報告を送信して、処理を完了する。その完了報告は、圧縮前のライトデータの量及び圧縮後のライトデータの量を表す情報を含んで良い。
ステップ14016:当該ステップは、ライト先の実ブロックの空き領域より、ライトデータの量が大きい場合に実行される。本ステップでは、データライト処理実行部12100は、ライト先仮想ブロックグループに、(m+1)個の実ブロックを割り当てている場合は、実ブロックを割り当てない。その場合、図29に示すステップ14019にジャンプする。
ステップ14017:このステップでは、ライト先の仮想ブロックグループに空き実ブロックが割り当てられる。なお、ここでは、割り当てられる実ブロックは、消去処理済みの実ブロック(有効なデータが格納されていない実ブロック)であるとする。データライト処理実行部12100は、各チップ情報3100のチップ内空き実ブロック数3103等を参照して、どのフラッシュチップ300の実ブロックを割り当てるかを決める。その後、データライト処理実行部12100は、対応するフラッシュチップ300の空きブロック情報ポインタ3400を参照して、先頭の実ブロック情報3300を、当該仮想ブロックグループ管理情報の最初にヌルになっている実ブロックポインタ3302が示すようにする。これで、仮想ブロックグループに新たな実ブロックが割り当てられたことになる。なお、データライト処理実行部12100は、空きブロック情報ポインタ3400を、次の実ブロック情報3300(仮想ブロックに割り当てた実ブロックの実ブロック情報3300の中の空き実ブロックポインタ3302が示す実ブロック情報3300)を示すようにし、さらに、仮想ブロックに割り当てた実ブロックの実ブロック情報3300の中の空き実ブロックポインタ3302をヌルにする。また、データライト処理実行部12100は、当該実ブロックに対応するチップ情報3100のチップ内空きブロック数3103の値を減らす。
ステップ14018:データライト処理実行部12100は、当該仮想ブロック情報3200の新たに割り当てた実ブロック情報ポインタ3202が示す実ブロック情報3300と、その一つ前の実ブロック情報ポインタ3202が示す実ブロック情報3300の実ブロック識別子3301とを基に、どのフラッシュチップ300のどのアドレスにデータを格納するかを決定する。この後、ステップ14008へジャンプする。
ステップ14019:本ステップでは、当該仮想ブロックグループに別の実ブロックが割り当てられる。別の実ブロックを割り当てる理由は、実ブロックの消去回数の偏りを少なくするためである。この処理は、ウエアレベリング処理と呼ばれる。この際、割り当てる実ブロックの数は、例えば、ライト先仮想ブロックグループに対応する圧縮後データ格納量3206が表す値に圧縮・伸長回路360Aに示された値を加えた値を基に決定される。当該ステップでは、データライト処理実行部12100は、必要な実ブロックの数を入力値として、ウエアレベリング処理部(例えば、フラッシュパッケージ230内のプロセッサ310で実行される図示しないプログラム)をコールして、実ブロックを決定する。データライト処理実行部12100は、ウエアレベリング処理部から、ライトデータを格納する実ブロックの実ブロック情報3300のアドレスを、入力値に等しい数だけ、受ける。この実ブロックは、消去された状態にあり、直接データを書き込めるような状態であるとする。また、本実施例では、ウエアレベリング処理部は、例えば、特許文献1のような公知の技術を前提とするので、ここでは、特に詳細に説明しない。
ステップ14020:ここでは、当該仮想ブロックグループ内のすべての圧縮後データを一度伸長してバッファ330に読み出す。このため、ヌル値でも、繰り返し情報でもないすべての仮想セグメントアドレス3205と対応する圧縮仮想セグメントデータ量3206を参照する。これらの値と、実ブロック情報3300とを基に、データライト処理実行部12100は、仮想セグメントのアドレス順に、どのフラッシュチップ300のどのアドレスからどの量だけをバッファ330に転送するかを示すアドレスリストを生成する。
ただし、必要となる仮想セグメントの一部を含む実セグメントも読み出し対象となる。
ステップ14021:データライト処理実行部12100は、ステップ14020で認識したフラッシュチップ300に対応したチップ情報3100を基に、当該フラッシュチップ300が接続されているパッケージバス340を特定し、対応するバス転送装置350を特定する。
ステップ14022:データライト処理実行部12100は、ステップ14021で特定したバス転送装置350に、ステップ14020で生成したアドレスリストに従う場所(フラッシュチップ300のアドレス)からバッファ330にデータを読み込むよう指示する。なお、この際、データライト処理実行部12100は、圧縮・伸長回路360Bには、データを伸長するよう指示する。
ステップ14023:この後、バッファ330への読み込みが完了するのを待つ。
ステップ14024:データライト処理実行部12100は、当該仮想ブロック情報3200の中で、ヌル値あるいは繰り返し情報を格納している仮想セグメントアドレスポインタ3205以外のすべての仮想セグメントアドレスポインタ3205(以下、有効な仮想セグメントアドレスポインタ3205と呼ぶ)を更新する。データライト処理実行部12100は、最初の有効な仮想セグメントアドレスポインタ3205に、ブロックアドレスとして、最初に割り当てた実ブロックのアドレスを設定し、相対アドレスとして、その実ブロックの先頭アドレスを設定する。データライト処理実行部12100は、次の有効な仮想セグメントアドレスポインタ3205について、基本的には、ブロックアドレスとして、その前の有効な仮想セグメントアドレスポインタ3205が表すブロックアドレスを設定し、相対アドレスとして、その前の有効な圧縮仮想セグメントアドレスポインタ320が表す値(相対アドレス)を加えた値(累積値)を設定していく。相対アドレスが、実ブロックの範囲をこえた場合、相対アドレスとしては、その値(実ブロックの範囲を超えた値)から、実ブロックの範囲に相当する値を減算した値が設定されブロックアドレスとしては、次に割り当てた実ブロックのアドレスが設定される。最後の有効な仮想セグメントアドレスポインタ3205の値を設定したあと、データライト処理実行部12100は、最後の有効な仮想セグメントアドレスポインタ3205に関する相対アドレスの値に、対応する圧縮仮想セグメントデータ量3206が表す値が加算される。このように算出された値Hが、実ブロック容量をこえていなければ、最後の有効な仮想セグメントアドレスポインタ3205のブロックアドレスに対応する実ブロック情報3300の実ブロック内空き容量3304に、実ブロック容量からこの算出値を減算した値がセットされ、加えて、当該ライト要求に対応した仮想セグメントアドレスポインタ3205には、ブロックアドレスとして、当該実ブロックのアドレスが設定される。さらに、算出値Hが、実ブロック容量をこえていれば、最後の実ブロック情報ポインタ3202が示す実ブロック情報3300の実ブロック内空き領域3304に、実ブロック容量の2倍の値からこの算出値Hを減算した値がセットされる。
ステップ14025:データライト処理実行部12100は、ストレージコントローラ200から受けたライトデータを、ステップ14023で転送したデータの次の領域に、伸長して書き込む。
ステップ14026:データライト処理実行部12100は、当該仮想セグメントの仮想セグメントアドレスポインタ3205がヌルか繰り返し情報を格納しているかを判断する。どちらかが成立なら、ステップ14028へジャンプする。
ステップ14027:どちらも成立しないなら、データライト処理実行部12100は、ストレージコントローラ200からライトデータを転送した際に使用した圧縮・伸長回路360Aが示す値から圧縮仮想セグメントデータ量3206を減算した値Jを、圧縮データ格納量3204に加える。さらに、データライト処理実行部12100は、同じ値Jを、パッケージ圧縮データ格納量3007が表す値に加算する。この後、データライト処理実行部12100は、圧縮・伸長回路360Aが示す値を圧縮仮想セグメントデータ量3206にセットする。また、データライト処理実行部12100は、今回書き込んだライトデータ量としては、0を、圧縮後のデータ量として、圧縮後のデータ量を圧縮仮想セグメントデータ量3206に加えた値を、ストレージコントローラ200に返す値として記憶資源(例えばレジスタ又はメモリ320)に格納する。この後、ステップ14029へジャンプする。
ステップ14028:成立の場合、データライト処理実行部12100は、ストレージコントローラ200から転送した際に使用した圧縮・伸長回路360Aが示す値Lを、ライト先の仮想ブロックグループに対応する圧縮データ格納量3204が表す値に加える。さらに、データライト処理実行部12100は、同じ値Lを、パッケージ圧縮データ格納量3007に加える。この後、データライト処理実行部12100は、同じ値Lを圧縮仮想セグメントデータ量3206にセットする。また、データライト処理実行部12100は、今回書き込んだライトデータ量としては、ストレージコントローラ200から受けた圧縮前のデータ量を表す値を、圧縮後のデータ量としては、当該圧縮・伸長回路360Aが示す値Lを、ストレージコントローラ200に返す値として記憶資源(例えばレジスタ又はメモリ)に記憶する。
ステップ14029:データライト処理実行部12100は、最後の有効な仮想セグメントアドレスポインタ3205の値の中で、この相対アドレスの値に、対応する圧縮仮想セグメントデータ量3206の値を加える。これにより算出された値をMとする。この算出値Mが実ブロック容量をこえていなければ、データライト処理実行部12100は、当該ライト要求に対応した仮想セグメントアドレスポインタ3205には、ブロックアドレスとして、最後の有効な仮想セグメントアドレスポインタ3205が示す実ブロックのアドレスを設定し、相対アドレスとして、この算出値Mを設定する。さらに、この算出値Mが実ブロック容量をこえていれば、データライト処理実行部12100は、最後の実ブロック情報3300の実ブロック内空き容量3304に、実ブロック容量からこの算出値Mを減算した値を設定する。さらに、データライト処理実行部12100は、この算出値Mが実ブロック容量をこえていれば、最後の実ブロック情報3300の実ブロック内空き容量3304に、実ブロック容量の2倍の値から、この算出値Mを減算した値を設定する。
ステップ14030:次に、データライト処理実行部12100は、新たに割り当てた実ブロックに対応する実ブロック情報3300の実ブロック識別子3301を基に、この実ブロックがどのフラッシュチップ300のどのアドレスに該当するかを特定し、転送を指示するアドレスリストを生成する。
ステップ14031:データライト処理実行部12100は、ステップ14030で特定したライトデータを格納するフラッシュチップ300に対応したチップ情報3100を基に、当該フラッシュチップ300が接続されているパッケージバス340を特定し、そのバス340に接続されているバス転送装置350を特定する。
ステップ14032:データライト処理実行部12100は、ステップ14031で特定したバス転送装置350に、ステップ14030で生成されたアドレスリストに従うフラッシュチップ300のアドレスへバッファ330からデータを書き込むよう指示する。この際、データライト処理実行部12100は、圧縮・伸長回路360Bには圧縮を指示する。
ステップ14033:この後、バッファ330からの書き込みが完了するのを待つ。
ステップ14034:この後、データライト処理実行部12100は、ステップ14033でのライト先のパッケージの仮想容量を変化させる必要があるかをチェックするために仮想容量判定処理部12500をコールする。
ステップ14035:このステップでは、割り当てられていた実ブロックが空きの状態にされる。まず、データライト処理実行部12100は、元々割り当てられていた実ブロックに対して消去処理を行う。これが完了すると、次に、データライト処理実行部12100は、元々割り当てられていた実ブロックに対応する実ブロック情報3300の空き実ブロックポインタ3302に、空き実ブロック情報ポインタ3400が示していた実ブロック情報3300のアドレスを設定し、空き実ブロック情報ポインタ3400には、元々割り当てられていた実ブロックに対応する実プロック情報3300のアドレスを設定する。さらに、元々割り当てられていた実ブロックに対応する実ブロック情報3300の空き実ブロックポインタ3302以外の情報を、ヌル値にする。また、データライト処理実行部12100は、対応する仮想ブロック情報3200の実ブロック情報ポインタ3202をヌル状態にする。このステップ14035は、当該仮想ブロックグループに割り当てられていた実ブロックの数だけ繰り替えされる。
ステップ14036:このステップでは、実ブロックが新たに仮想ブロックグループに割り当てられる。具体的には、例えば、データライト処理実行部12100は、ライト先の仮想ブロックグループを構成する仮想ブロックの数だけの仮想ブロック情報3200の実ブロック情報ポインタ3202が、新しく割り当てられる実ブロックの実ブロック情報3300を示すようにする。
ステップ14037:データライト処理実行部12100は、ストレージコントローラ200に対して、ライト要求の終了を報告する。なお、データライト処理実行部12100は、仮想容量判定処理部12500の実行結果から、当該フラッシュパッケージ230の仮想容量を変化させることを検出した場合、新たな仮想容量(変化後の仮想容量、又は、現在の仮想容量との差分)を表す情報を、ストレージコントローラ200に報告する。また、データライト処理実行部12100は、ライトデータの圧縮前の量と圧縮後の量を表す情報も、ストレージコントローラ200に報告する。
図30は、仮想ブロック解放処理実行部12200の処理フローである。仮想ブロック解放処理実行部12200は、ストレージコントローラ200から領域の範囲(仮想セグメントの集合)を指定した解放要求(割り当てられている実ブロックを解放することの要求)をフラッシュパッケージ230が受けた時に実行される。
ステップ15000:仮想ブロック解放処理実行部12200は、受けた解放要求で指定された領域範囲と、パッケージブロック容量3005とを基に、解放を指示された範囲(仮想ブロックグループにおける範囲)を特定する。このとき、特定された範囲は、仮想ブロックグループ全域ということもあれば、仮想ブロックグループにおける一部の仮想セグメントということもあり得る。また、指定された範囲(仮想セグメント)を含む仮想ブロックグループごとに、分類が行われて良い。また、仮想ブロック解放処理実行部12200は、ストレージコントローラ200に返却する、指定された領域範囲に対応して設ける、データ格納量と圧縮データ格納量との差分(変化)を示す値をクリアしておく(0としておく)。
ステップ15001:仮想ブロック解放処理実行部12200は、全域が指定された仮想ブロックグループがなければ、ステップ15005へジャンプする。
ステップ15002:仮想ブロック解放処理実行部12200は、解放要求で指定された全ての仮想ブロックグループのデータ格納量3203を合計し、且つ、解放要求で指定された全ての仮想ブロックグループの圧縮データ格納量3204を合計する。仮想ブロック解放処理実行部12200は、それぞれの合計値を、ストレージコントローラ200に返却するそれぞれ対応する値(データ格納量、圧縮データ格納量)に加算する。さらに、仮想ブロック解放処理実行部12200は、データ格納量3203に関する合計値を、パッケージデータ格納量3006から減算し、且つ、圧縮データ格納量3204に関する合計値を、パッケージ圧縮データ格納量3007から減算する。その後、仮想ブロック解放処理実行部12200は、解放要求で指定された全ての仮想ブロックグループについて、データ格納量3203と圧縮データ格納量3204をクリアし、すべての仮想セグメントアドレスポインタ3205に繰り返し情報が指定されていることを意味する値を設定し、且つ、全ての圧縮仮想セグメントデータ量3206にその繰り返し情報を設定する。
ステップ15003:仮想ブロック解放処理実行部12200は、指定されたすべての仮想ブロックグループに対応する仮想ブロック情報3200の実ブロック情報ポインタ3202が示す実ブロック情報3300に対応する実ブロックの解放処理を行う。このため、仮想ブロック解放処理実行部12200は、該当するすべての実ブロック情報3300の実ブロック識別子3301を解析し、解放する実ブロックが、どのフラッシュチップ300のどのアドレスから格納されているかを特定する。
ステップ15004:本ステップでは、該当するすべての仮想ブロックグループに割り当てられているすべての実ブロックが空いた状態にされる。対象となる実ブロックは、ステップ15003で特定された実ブロックであるが、処理は、図29のステップ14035と同じであるので、ここでは、説明を省略する。ただし、ステップ14035の処理は、一つの仮想ブロックグループに対する処理であるが、ここでは、ステップ14035の処理は、該当する仮想ブロックグループの数だけ、実行される。この後、一部の仮想セグメントの解放が指示された仮想セグメントグループがなければ、ステップ15006へジャンプする。
ステップ15005:本ステップは、仮想ブロックグループの全域ではなく一部が指定されたすべての仮想ブロックグループについての処理である。仮想ブロック解放処理実行部12200は、解放要求で指定された全ての仮想ブロックグループのデータ格納量3203を合計し、且つ、解放要求で指定された全ての仮想ブロックグループの圧縮データ格納量3204を合計する。仮想ブロック解放処理実行部12200は、それぞれの合計値を、ストレージコントローラ200に返却するそれぞれ対応する値(データ格納量、圧縮データ格納量)に加算する。さらに、仮想ブロック解放処理実行部12200は、データ格納量3203に関する合計値を、パッケージデータ格納量3006から減算し、且つ、圧縮データ格納量3204に関する合計値を、パッケージ圧縮データ格納量3007から減算する。仮想ブロック解放処理実行部12200は、全ての仮想ブロックグループについて、各々の対応する実ページ(指定された仮想ブロックグループを含む実ページ)と各々の指定された仮想ブロックグループに対して指定された仮想セグメントアドレスポインタ3205の中から、全ての有効な仮想セグメントアドレスポインタ3205の数の合計と当該有効な仮想セグメントアドレスポインタ3205に対応する圧縮仮想セグメントデータ量3206の合計を算出する。仮想ブロック解放処理実行部12200は算出された値を、ストレージコントローラ200へ返却される、各実ページに対して提供される対応する値に加算する。加えて仮想ブロック解放処理実行部12200は、データ格納量について、計算値(データ格納量3203の合計とストレージコントローラ200に返却される値(データ格納量)との合計値)を、パッケージデータ格納量3006から減算し、また圧縮データ格納量について、計算値(圧縮データ格納量3204の合計とストレージコントローラ200に返却される値(圧縮データ格納量)との合計値)をパッケージ圧縮データ格納量3007から減算する。さらに、仮想ブロック解放処理実行部12200は、仮想ブロックグループごとに、算出されたデータ格納量及び圧縮データ格納量を、該当する仮想セグメントグループのデータ格納量3203と圧縮データ格納量3204から減算する。最後に、仮想ブロック解放処理実行部12200は、指定された仮想セグメントアドレスポインタ3205の中で、すべての有効仮想セグメントアドレスポインタ3205の値を、繰り返し情報が設定されていることを示す値に変更し、且つ、対応する圧縮仮想セグメントデータ量3206に繰り返し情報を設定する。なお、ここでは、解放を指示された仮想セグメントには、繰り返し情報が設定されていることを記憶するだけで、実ブロックの解放を行わない。しかし、当該仮想ブロックグループに、別の実ブロックを割り当て、割り当てた実ブロックに有効なデータを書き込む際には、(データライト処理実行部12100のステップ14019-14033の処理)、繰り返し情報が格納されているという情報から、当該仮想セグメントは、データが書き込まれないので、格納領域を削減できる。また、本実施例では、当該仮想ブロックグループに、別セグメントを割り当てる処理を、この契機で実行はしていないが、この契機で、別セグメントを割り当てる処理(データライト処理実行部12100のステップ14019-14033の処理)を実行して、直ちに、格納容量を削減しても、本発明は有効である。
ステップ15006:仮想ブロック解放処理実行部12200は、ストレージコントローラ200に、ステップ15002とステップ15005で算出されたデータ格納量と圧縮後データ格納量を報告する。ストレージコントローラ200へ解放要求の完了報告を行う。その完了報告が、ステップ15002とステップ15005で算出されたデータ格納量と圧縮後データ格納量を表す情報を含んで良い。
図31は、仮想ブロック移動処理実行部12300の処理フローである。仮想ブロック移動処理実行部12300は、指定された仮想セグメントの集合に格納されているデータを移動することの要求(仮想ブロック移動要求)をフラッシュパッケージ230がストレージコントローラ200から受けたときに実行される。なお、ここでは、実ページ単位の要求なので、仮想ブロックグループの一部のセグメントの転送要求はないものとする。また、送ったデータを格納していた実ブロックは解放するので、図30の仮想ブロック解放処理実行部12200と処理が異なるのは、実ブロックに格納されていたデータをストレージコントローラ200に送る点である。このため、図30の処理フローの各ステップを引用しながら、図31の説明を行う。
ステップ16000:仮想ブロック移動処理実行部12300は、仮想ブロック移動要求で指定された仮想ブロックグループの集合を算出する。
ステップ16001:仮想ブロック移動処理実行部12300は、指定されたすべての仮想ブロックグループについて、それぞれの仮想ブロックグループのすべての仮想セグメントに対し、対応する仮想セグメントアドレスポインタ3205を参照して、ステータス情報(データが格納されていない(ヌル)、繰り返し情報が設定されているか、或いは、データが格納されているかを示す情報)と、圧縮仮想セグメントデータ量3206が表す値とを、ストレージコントローラ200に戻す値として設定する。
ステップ16002:仮想ブロック移動処理実行部12300は、指定されたすべての仮想ブロックグループについて、それぞれの仮想ブロックグループのデータ格納量3203と圧縮データ格納量3204を、ストレージコントローラ200に戻す値として設定する。また、仮想ブロック移動処理実行部12300は、これらの仮想ブロックグループのデータ格納量3203と圧縮データ格納量3204のそれぞれの合計値を求め、それぞれの合計値を、ストレージコントローラ200に返却する値として設定する。さらに、仮想ブロック移動処理実行部12300は、それぞれの合計値を、パッケージデータ格納量3006とパッケージ圧縮データ格納量3007から減算する。その後、仮想ブロック移動処理実行部12300は、データ格納量3203、圧縮データ格納量3204、すべての仮想セグメントアドレスポインタ3205と圧縮仮想セグメントデータ量3206をクリアする。
ステップ16003:仮想ブロック移動処理実行部12300は、指定されたすべての仮想セグメントの仮想セグメントアドレスポインタ3205がデータを格納していることを示す、仮想セグメントアドレスポインタ3205と対応する圧縮仮想セグメントデータ量3206から、ストレージコントローラ200に送るべき当該仮想ブロックグループの中に格納されているデータが格納されているアドレスとその転送長を示す情報リストを生成する。ただし、必要となる仮想セグメントの一部を含む実セグメントも読み出し対象となる。
ステップ16004:仮想ブロック移動処理実行部12300は、指定された仮想セグメントに割り当てられている実ブロックが格納されているフラッシュチップ300に対応したチップ3100情報をアクセスして、当該フラッシュチップ300が接続されているパッケージバス340を特定し、対応するバス転送装置350を特定する。
ステップ16005:仮想ブロック移動処理実行部12300は、ステップ16004で特定したバス転送装置350に、ステップ16004で生成した情報リストに従うアドレスからバッファ330にデータを転送するよう指示する。その際、仮想ブロック移動処理実行部12300は、圧縮・伸長回路360Bには、データを伸長するよう指示する。
ステップ16006:転送が完了するのを待つ。
ステップ16007:ステップ15003と同じ処理であるため、説明を省略する。
ステップ16008:ステップ15004と同じ処理であるため、説明を省略する。
ステップ16009:仮想ブロック移動処理実行部12300は、ストレージコントローラ200へ、バッファ330に格納したデータを送る。まず、仮想ブロック移動処理実行部12300は、仮想セグメントごとに、ステータス情報(データが格納されていたか、繰り返し情報が設定されていたか、データが格納されていないかを示す情報)と、圧縮後のデータ量を表す情報とを送る。次に、仮想ブロック移動処理実行部12300は、仮想ブロックグループに対応した格納データ量と圧縮データ格納量の変化値を、さらに、すべてのデータの格納データ量と圧縮データ格納量の変化値を、最後に、バッファ330に格納したデータの中から、有効な仮想セグメントのデータを選択して、ストレージコントローラ200に送る。以上で処理を終了する。
図32は、仮想ブロック格納処理実行部12400の処理フローである。仮想ブロック格納処理実行部12400は、格納要求(指定された仮想ブロックグループに、実ブロックをそれぞれ割り当てて、ストレージコントローラ200から送られてきたデータを格納せよという要求)を受けたときに、実行される。仮想ブロック移動処理実行部12300とは、データの流れが逆ではあるが、共通点が多いので、図31の処理フローの各ステップを引用しながら説明を行う。
ステップ17000:ステップ16000と同様。仮想ブロック格納処理実行部12400は、格納を指示された仮想セグメントの集合から、対象となる仮想ブロックグループを特定する。
ステップ17001:仮想ブロック格納処理実行部12400は、ストレージコントローラ200から以下の情報:
(*)指定された仮想セグメントの集合の内、仮想セグメントごとにデータが格納されているかいないか、或いは、繰り返し情報が設定されているかを示す値;
(*)圧縮後のデータ量を示す値、
を受け、それらの情報をバッファ330に格納する。次に、仮想ブロック格納処理実行部12400は、仮想ブロックグループごとの格納データ量と圧縮データ格納量の変化値を受ける。さらに、仮想ブロック格納処理実行部12400は、すべてのデータの格納データ量と圧縮データ格納量の変化値を受ける。最後に、仮想ブロック格納処理実行部12400は、仮想セグメントに格納するデータを受けるが、この際には、圧縮・伸長回路360Aに圧縮処理を実行するよう指示して、圧縮後のデータをバッファ300に格納するようにする。また、仮想ブロック格納処理実行部12400は、すべてのデータの格納データ量と圧縮データ格納量の変化値をパッケージデータ格納量3006、パッケージ圧縮データ量3007に加える。次に、仮想ブロック格納処理実行部12400は、指定された仮想セグメントを、仮想ブロックグループごとに分類する。
ステップ17002:ステップ16002と同様。仮想ブロック格納処理実行部12400は、データを格納するよう指示されている仮想ブロックグループを探す。もうなければ、ステップ17010へジャンプする。
ステップ17003:仮想ブロック格納処理実行部12400は、当該仮想ブロックグループについての格納データ量と圧縮データ格納量の変化値を、対応する仮想ブロック情報3200のデータ格納量3203と圧縮データ格納量3204に格納する。また、仮想ブロック格納処理実行部12400は、対応する仮想セグメントに関して受けた、データが格納されている、いない、或いは、繰り返し情報が設定されているかを示す値を、仮想セグメントアドレスポインタ3205に設定する。データが格納されているという値を受けた場合、仮想ブロック格納処理実行部12400は、対応する圧縮後データ格納量を、圧縮仮想セグメントデータ量3206にセットする。
ステップ17004:ここでは、実ブロックが当該仮想ブロックグループに割り当てられる。割り当てられる実ブロックの数は、当該仮想ブロック情報3200の圧縮データ格納量3204を基に決定される。ここでは、必要な数の実ブロックが割り当てられる。これは、図29のステップ14019に示した処理なので、説明を省略する。
ステップ17005:仮想ブロック格納処理実行部12400は、当該仮想ブロック情報3200の中で、データを格納していることを示す仮想セグメントアドレスポインタ3205を更新する。これは、ステップ14024と同じであるため、説明を省略する。
ステップ17006:仮想ブロック格納処理実行部12400は、仮想セグメント内のデータが格納されているフラッシュチップ300に対応したチップ情報3100を基に、当該フラッシュチップ300が接続されているパッケージバス340を特定し、対応するバス転送装置350を特定する。
ステップ17007:仮想ブロック格納処理実行部12400は、ステップ17006で特定したバス転送装置350に、フラッシュチップ300のアドレスからバッファ330に当該仮想ブロックグループ全体のデータを格納するよう指示する。
ステップ17008:転送が完了するのを待つ。
ステップ17009:ステップ17002に戻る。
ステップ17010:ストレージコントローラ200へ、処理要求の完了を報告する。以上で処理を終了する。
図33は、仮想容量判定処理部12500の処理フローである。仮想容量判定処理部12500は、圧縮率を把握し、当該パッケージ230の仮想容量を調整する必要があるかを判断する。調整する必要があると判断した場合、その容量を決定し、仮想容量判定処理部12500は、仮想パッケージ容量3002に設定する。さらに、この容量と容量を変更した旨を、呼び出し元に返却する。
ステップ18000:仮想容量判定処理部12500は、パッケージデータ格納量3006/仮想パッケージ容量3002の比を算出する。算出された比をPとする。比Pが、Q(Qは、例えば、Pよりも十分小さい値)以下の場合、仮想容量の調整を行わず、処理が、呼び出し元に戻る。比Pが、Q以下の場合、まだ、それ程多くのデータが格納されていないからである。
ステップ18001:次に、仮想容量判定処理部12500は、R=(仮想パッケージ容量3002/実パッケージ容量3003)を算出する。また、仮想容量判定処理部12500は、T=(パッケージデータ格納量3006/パッケージ圧縮データ格納量3007)を算出する。値Tは、圧縮率である。
ステップ18002:仮想容量判定処理部12500は、RとTを比較する。これらの値がほぼ等しければ(例えば、RとTの差が所定値未満であれば)、理想的な仮想パッケージ容量3002が設定されているということである。このため、仮想容量判定処理部12500は、調整を行わないことを決定し、呼び出し元に戻る。RのほうがTより大きい場合(仮想容量が大き過ぎる場合)、又は、RのほうがTより小さい場合(仮想容量が小さすぎる場合)、仮想容量判定処理部12500は、仮想パッケージ容量3002の調整を行う。
ステップ18003:仮想容量判定処理部12500は、仮想容量を調整する。調整後の仮想容量の値は、例えば、実パッケージ容量3003*Tである。これは、圧縮率Tが今後も変化しなければ理想値となる。調整後の仮想容量の値は、(実パッケージ容量3003−パッケージ圧縮データ格納量3007)*R+パッケージ圧縮データ格納量3007*Tでも良い。仮想容量判定処理部12500は、決定した値(調整後の仮想容量の値)を、仮想パッケージ容量3002に設定し、さらに、呼び出し元に、仮想容量の調整を行うことと、この決定した値とを通知し、処理を完了させる。
本実施例によれば、それぞれが多数のフラッシュメモリを実装したフラッシュパッケージを多数接続した大容量のストレージシステムにおいて、圧縮機能を適用し、データ格納容量を削減しても、性能劣化を抑えて、物理容量よりも大きな容量を格納できることが可能である。
以上、本発明の一実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
以下、上述した説明を基に、本発明の1以上の観点に従う概要を記載する。
ストレージシステムは、複数のフラッシュパッケージと、ホストからのライト要求(以下、上位のライト要求)に従うデータに基づくライトデータのライト要求(以下、下位のライト要求)をフラッシュパッケージに送信するストレージコントローラとを有する。各フラッシュパッケージは、1以上のフラッシュメモリと、ストレージコントローラ及び1以上のフラッシュメモリに接続されるパッケージコントローラとを有する。各フラッシュメモリは、複数の実ブロックを有する。各実ブロックは、複数の実セグメントで構成されている。そのフラッシュメモリは、ブロック単位でデータが消去され、セグメント単位でデータが読み書きされるタイプのフラッシュメモリ、例えば、NAND型のフラッシュメモリである。パッケージコントローラは、ストレージコントローラからのライト要求に従うライトデータを、実ブロックに書き込む。
ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージが有する複数のフラッシュチップの物理的な容量の合計値よりも大きな仮想的な容量をストレージコントローラに定義する。
ストレージコントローラ又はパッケージコントローラが、下位のライト要求に従うライトデータを圧縮する。下位のライト要求の送信先のフラッシュパッケージのパッケージコントローラが、圧縮されたライトデータである圧縮データを、ライト先の仮想ブロックに割り当てられた実ブロックに書き込む。
ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージのデータ格納状況に応じて、そのフラッシュパッケージの仮想容量を変更する。データ格納状況は、典型的には、前述した圧縮率である。フラッシュパッケージの圧縮率は、そのフラッシュパッケージに格納されている有効な圧縮データの圧縮前のライトデータの総容量と、そのフラッシュパッケージに格納されている有効な圧縮データの総容量とに基づく値である。具体的には、例えば、ストレージコントローラ又はパッケージコントローラが、仮想セグメントに書き込まれた有効な圧縮後のデータの量とその有効なデータの圧縮前のデータの量とを仮想セグメントごとに管理する。フラッシュパッケージに格納されている有効な圧縮データの圧縮前のライトデータの総容量は、そのフラッシュパッケージが提供する各仮想セグメントについての、書き込まれた有効なデータの圧縮前のデータの量を基に算出された値である。フラッシュパッケージに格納されている有効な圧縮データの総容量は、そのフラッシュパッケージが提供する各仮想セグメントについての、そのフラッシュパッケージに格納されている有効な圧縮データの量を基に算出された値である。例えば、仮想ブロック#1に実ブロック#1が割り当てられていて、仮想ブロック#1が仮想セグメント#1及び#2を含んでいるとする。ここでは、仮想セグメント長を8キロバイトとして説明を行う。仮想セグメント#1に、データが格納され、圧縮された結果、1キロバイトの圧縮データが格納され、仮想セグメント#2に、データが格納され、圧縮の結果2キロバイトの圧縮データが格納され、さらに、仮想セグメント#1が、書きかえられ、圧縮の結果、3キロバイトのデータが格納されたとする。この場合、仮想セグメント#1の有効なデータ(最新のデータ)は、3キロバイトの圧縮データであり、仮想セグメント#2の有効なデータ(最新のデータ)は、2キロバイトの圧縮データである。このため、実ブロック#1について、最新の圧縮データの総量は、3キロバイト+2キロバイト=5キロバイトである。また、実ブロック#1について、最新の圧縮前のデータの総量は、8キロバイト+8キロバイト=16キロバイトである。このように、仮想セグメントに圧縮データが格納されれば、その仮想セグメントを提供するフラッシュパッケージについて、パッケージデータ格納量3006及びパッケージ圧縮データ格納量3007が更新される。パッケージコントローラが、ライト先の仮想セグメントを含む仮想ブロックについて、圧縮状況情報(例えば、その仮想セグメントに書き込まれた圧縮データの量とその圧縮データの圧縮前のライトデータの量とを表す情報、及び/又は、それらの量に基づいて算出される、当該ライト時の圧縮率を表す情報)を、ストレージコントローラに送信する。圧縮状況情報は、下位のライト要求に対する完了報告に含められても良い。
ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージの圧縮率が増加した場合、そのフラッシュパッケージの仮想容量を増やす。データ格納量をより削減できるので、より多くのライトデータを格納することが期待されるからである。
ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージの圧縮率が減少した場合、そのフラッシュパッケージの仮想容量を減らす。データ格納量があまり削減されないので、あまり多くのライトデータを格納することができないことが期待されるからである。
各実ページは、複数の仮想ブロックを含んでいる。ストレージコントローラは、フラッシュパッケージの仮想容量を増やす場合、そのフラッシュパッケージに基づく空きの実ページを増やし、そのフラッシュパッケージの仮想容量を減らす場合、そのフラッシュパッケージに基づく空きの実ページを減らす。このように、下位レベルの容量仮想化機能に加えて上位レベルの容量仮想化機能があれば、仮想ブロックと実ブロックの対応関係を変更することなく、仮想容量の増減を行うことができる。
ライトデータの圧縮は、フラッシュチップへのライトのとき、リクラメーション処理のとき、或いは、ページ間のデータ移動のときの少なくとも1つのときに行われる。リクラメーション処理は、フラッシュパッケージにおいて必然的に行われる処理であるから、その処理のときに圧縮が行われるので、性能の低下が生じるのを抑えることが期待できる。
ストレージコントローラが、フラッシュパッケージの圧縮率を基に、フラッシュパッケージ間で、移動元の実ページから移動先の実ページにデータを移動する。ストレージコントローラは、移動元の実ページに関連付けられている管理情報、移動先の実ページに関連付けられている管理情報に適用する。管理情報は、例えば、データが格納されているか、繰り返し情報が格納されているか等を含んで良い。また、フラッシュパッケージ間のデータ移動では、移動元のフラッシュパッケージが、移動元実ページに割り当てられている実ブロック内の有効な圧縮データを伸長して(又は伸長することなく)移動先のフラッシュパッケージに転送し、移動先のフラッシュパッケージが、受信したデータを圧縮して(又は圧縮済みであるため圧縮することなく)、移動先実ページに割り当てられている実ブロックに格納して良い。その際、移動元の実ページに対応する管理情報(例えば、データ格納量及び圧縮データ格納量を表す情報)はリセットされ、移動先の実ページに対応する管理情報(例えば、データ格納量及び圧縮データ格納量を表す情報)は、データ移動に伴い格納された圧縮データの量(及びその圧縮データの圧縮前のデータの量)を基に更新されて良い。
パッケージコントローラは、そのパッケージコントローラにおいてリクラメーション処理を行うことができる。リクラメーション処理では、パッケージコントローラは、満杯になった移動元実ブロック内の有効なデータを移動先実ブロックに移し、移動元実ブロックに対する消去処理(移動元実ブロックに格納されているデータを消去する処理)を行うことで、移動元実ブロックを空きの実ブロックとする。このリクラメーション処理において、データの圧縮及び伸長が行われて良い。
100…ストレージシステム、110…ホスト、120…ストレージエリアネットワーク(SAN)、200…ストレージコントローラ200…キャッシュメモリ、220…共有メモリ、230…フラッシュパッケージ、250…接続装置、260…プロセッサ、270…メモリ、280…フラッシュパッケージグループ、300…フラッシュチップ、310…パッケージプロセッサ、320…パッケージメモリ、330…バッファ、340…パッケージバス、350…パッケージ転送装置、360…圧縮・伸長回路、2000…論理ボリューム情報、2100…実ページ情報、2300…フラッシュパッケージグループ情報、2500…フラッシュパッケージ情報、3000…パッケージ情報、3100…チップ情報、3200…仮想ブロック情報、3300…実ブロック情報、4000…リード処理実行部、4100…ライト処理受付部、4200…ライトアフタ処理実行部、4300…ライトセイムコマンド処理実行部、4400…実ページ移動処理実行部、12000…データリード処理実行部、12100…データライト処理実行部、12200…実ブロック解放処理実行部、12300…仮想ブロック移動処理実行部、12400…仮想ブロック格納処理実行部、12500…仮想容量判定処理部

Claims (10)

  1. 複数の記憶媒体とストレージコントローラとを備えるストレージシステムであって、
    前記ストレージコントローラは、前記複数の記憶媒体によって提供されるプールに含まれる複数のページを管理し、ホストに対して仮想ボリュームを提供し、前記ホストからの書き込み要求に応じて、前記プール内の割当て可能な複数のページのうちのあるページを前記仮想ボリュームの一部に割当て、前記プール内の割当て可能なページ数を管理し、割り当てた前記ページに対応する領域を有する前記複数の記憶媒体に対してライトデータを送信し、
    前記複数の記憶媒体のうちの少なくとも一つの記憶媒体は、前記ストレージコントローラから受信した前記ライトデータを圧縮して、圧縮した前記ライトデータを格納し、
    前記複数の記憶媒体のうちの少なくとも一つの記憶媒体は、当該記憶媒体の圧縮されたデータの格納量に基づいて、圧縮情報を生成し、
    前記複数の記憶媒体のうちの少なくとも一つの記憶媒体は、前記圧縮情報を前記ストレージコントローラに送信し、
    前記ストレージコントローラは、前記複数の記憶媒体のうちの少なくとも一つの記憶媒体から受信した前記圧縮情報に基づいて、前記プール内の割当て可能なページ数を調整することを特徴とする、
    ストレージシステム。
  2. 請求項1記載のストレージシステムであって、
    前記ストレージコントローラは、前記圧縮情報に基づいて前記プール内の割当て可能なページ数を調整する際、前記プール内の使用不可ページ数を調整することを特徴とする、
    ストレージシステム。
  3. 請求項1記載のストレージシステムであって、
    前記複数の記憶媒体のうちの少なくとも一つの記憶媒体は、前記ホストからのI/O要求と独立に、前記圧縮情報を前記ストレージコントローラに送信することを特徴とする、ストレージシステム。
  4. 請求項1記載のストレージシステムであって、
    前記ストレージコントローラは、前記プール内の割当て可能な複数のページのうちのあるページを前記仮想ボリュームの一部に割当てる際、前記プール内の割当て可能なページ数から一のページを減じてページ数を管理することを特徴とする、ストレージシステム。
  5. 請求項1記載のストレージシステムであって、
    前記複数の記憶媒体は、それぞれ、データ記憶領域を有し、
    前記圧縮されたデータは、前記データ記憶領域に格納されることを特徴とする、ストレージシステム。
  6. 請求項5記載のストレージシステムであって、
    前記圧縮情報は、前記データ記憶領域に格納された前記圧縮されたデータの格納量と、前記ストレージコントローラから送信されたライトデータの合計値に基づく、圧縮率であることを特徴とする、ストレージシステム。
  7. 請求項1記載のストレージシステムであって、
    前記ストレージコントローラは、前記仮想ボリュームの、前記ホストからの書き込み要求に対応するライト先のアドレスに当該ページが割り当てられていない場合、前記プール内の割当て可能な複数のページのうちのあるページを前記仮想ボリュームの前記アドレスに割当てることを特徴とする、ストレージシステム。
  8. 請求項1記載のストレージシステムであって、
    前記複数の記憶媒体は、それぞれ、複数のフラッシュチップを有するフラッシュパッケージであることを特徴とする、ストレージシステム。
  9. 請求項1記載のストレージシステムであって、
    前記複数の記憶媒体のうちの少なくとも一つは、HDDであることを特徴とする、ストレージシステム。
  10. 請求項1記載のストレージシステムであって、
    前記複数の記憶媒体は、RAIDグループであることを特徴とする、ストレージシステム。
JP2013535987A 2011-06-07 2011-06-07 ストレージシステム Active JP5792313B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/003204 WO2012168962A1 (en) 2011-06-07 2011-06-07 Storage system comprising flash memory, and storage control method

Publications (2)

Publication Number Publication Date
JP2014506688A JP2014506688A (ja) 2014-03-17
JP5792313B2 true JP5792313B2 (ja) 2015-10-07

Family

ID=47294133

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013535987A Active JP5792313B2 (ja) 2011-06-07 2011-06-07 ストレージシステム

Country Status (5)

Country Link
US (2) US8862805B2 (ja)
EP (1) EP2652587B1 (ja)
JP (1) JP5792313B2 (ja)
CN (1) CN103384877B (ja)
WO (1) WO2012168962A1 (ja)

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9424128B2 (en) 2011-08-12 2016-08-23 Futurewei Technologies, Inc. Method and apparatus for flexible RAID in SSD
US9177177B1 (en) * 2012-10-04 2015-11-03 Symantec Corporation Systems and methods for securing storage space
US11037625B2 (en) * 2012-11-20 2021-06-15 Thstyme Bermuda Limited Solid state drive architectures
WO2014081719A1 (en) * 2012-11-20 2014-05-30 Peddle Charles I Solid state drive architectures
US9652376B2 (en) 2013-01-28 2017-05-16 Radian Memory Systems, Inc. Cooperative flash memory control
US9575982B1 (en) 2013-04-29 2017-02-21 Amazon Technologies, Inc. Size targeted database I/O compression
DE112013006565T5 (de) 2013-05-17 2015-11-05 Hitachi, Ltd. Speichervorrichtung
CN105051724B (zh) 2013-08-19 2018-09-28 华为技术有限公司 一种数据对象处理方法与装置
CN103744612A (zh) * 2013-12-17 2014-04-23 记忆科技(深圳)有限公司 基于闪存转换层的精简配置的方法及其系统
US9501393B2 (en) * 2014-01-27 2016-11-22 Western Digital Technologies, Inc. Data storage system garbage collection based on at least one attribute
US10120601B2 (en) 2014-03-24 2018-11-06 Hitachi, Ltd. Storage system and data processing method
US10222988B2 (en) * 2014-04-22 2019-03-05 Hitachi, Ltd. Efficient management storage system via defining of several size units in advance
WO2015162758A1 (ja) * 2014-04-24 2015-10-29 株式会社日立製作所 ストレージシステム
US10430079B2 (en) * 2014-09-08 2019-10-01 Pure Storage, Inc. Adjusting storage capacity in a computing system
US10552085B1 (en) 2014-09-09 2020-02-04 Radian Memory Systems, Inc. Techniques for directed data migration
US9542118B1 (en) 2014-09-09 2017-01-10 Radian Memory Systems, Inc. Expositive flash memory control
TWI539282B (zh) * 2014-10-13 2016-06-21 慧榮科技股份有限公司 非揮發性儲存裝置與控制器
CN104598163B (zh) * 2014-11-28 2017-10-17 成都龙腾中远信息技术有限公司 一种基于载荷地面测试接口适配器的高速存储模块的存储方法
CN104506381A (zh) * 2014-12-16 2015-04-08 新余兴邦信息产业有限公司 一种通过仪表监控文件上传的方法及装置
WO2016139749A1 (ja) * 2015-03-03 2016-09-09 株式会社日立製作所 計算機システム、及び、記憶制御方法
US10452614B2 (en) 2015-06-12 2019-10-22 International Business Machines Corporation Storage data reduction analysis and forecast
WO2017068617A1 (ja) 2015-10-19 2017-04-27 株式会社日立製作所 ストレージシステム
WO2017109931A1 (ja) 2015-12-25 2017-06-29 株式会社日立製作所 計算機システム
US20180267714A1 (en) * 2016-01-22 2018-09-20 Hewlett Packard Enterprise Development Lp Managing data in a storage array
US10394480B2 (en) 2016-01-22 2019-08-27 Hitachi, Ltd. Storage device and storage device control method
JP6725120B2 (ja) * 2016-06-24 2020-07-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド データ処理方法、記憶装置、ソリッドステートディスク及び記憶システム
CN108388524A (zh) * 2016-12-21 2018-08-10 伊姆西Ip控股有限责任公司 用于缓存数据的方法和设备
JP6798002B2 (ja) 2017-02-23 2020-12-09 株式会社日立製作所 スケールアウト型のストレージシステム
JP6805110B2 (ja) 2017-11-06 2020-12-23 株式会社日立製作所 ストレージシステム及びその制御方法
JP7102166B2 (ja) * 2018-02-23 2022-07-19 キヤノン株式会社 情報処理装置、情報処理装置の制御方法及びプログラム
JP2019153363A (ja) 2018-03-05 2019-09-12 株式会社東芝 磁気ディスク装置及びライト方法
US11586385B1 (en) 2020-05-06 2023-02-21 Radian Memory Systems, Inc. Techniques for managing writes in nonvolatile memory
KR102545465B1 (ko) * 2021-11-17 2023-06-21 삼성전자주식회사 스토리지 컨트롤러 및 이를 포함하는 스토리지 장치

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3507132B2 (ja) * 1994-06-29 2004-03-15 株式会社日立製作所 フラッシュメモリを用いた記憶装置およびその記憶制御方法
JP2831602B2 (ja) 1995-01-13 1998-12-02 富士通株式会社 圧縮データ管理装置及び圧縮データ管理方法
US6343293B1 (en) * 1998-09-24 2002-01-29 International Business Machines Corporation Storing the uncompressed data length in a LOB map to speed substring access within a LOB value
US6523102B1 (en) * 2000-04-14 2003-02-18 Interactive Silicon, Inc. Parallel compression/decompression system and method for implementation of in-memory compressed cache improving storage density and access speed for industry standard memory subsystems and in-line memory modules
US7386046B2 (en) * 2001-02-13 2008-06-10 Realtime Data Llc Bandwidth sensitive data compression and decompression
US6877081B2 (en) * 2001-02-13 2005-04-05 International Business Machines Corporation System and method for managing memory compression transparent to an operating system
JP3100146U (ja) 2003-08-29 2004-04-30 万国電脳股▼ふん▲有限公司 圧縮管理メカニズムを具えたストレージデバイス
US20060190643A1 (en) 2004-04-26 2006-08-24 Storewiz, Inc. Method and system for compression of data for block mode access storage
JP2007164240A (ja) 2005-12-09 2007-06-28 Funai Electric Co Ltd ファイル管理システムおよびストレージの自動管理方法、並びに自動管理プログラム
US7596657B2 (en) * 2006-01-13 2009-09-29 Paul Kaler Increased storage capacity for solid state disks using data compression
JP4927408B2 (ja) 2006-01-25 2012-05-09 株式会社日立製作所 記憶システム及びそのデータ復元方法
JP4897524B2 (ja) * 2007-03-15 2012-03-14 株式会社日立製作所 ストレージシステム及びストレージシステムのライト性能低下防止方法
US20080228998A1 (en) * 2007-03-16 2008-09-18 Spansion Llc Memory storage via an internal compression algorithm
US7975109B2 (en) * 2007-05-30 2011-07-05 Schooner Information Technology, Inc. System including a fine-grained memory and a less-fine-grained memory
US9164941B2 (en) * 2007-10-24 2015-10-20 Hitachi, Ltd. Storage system group
JP2009282678A (ja) * 2008-05-21 2009-12-03 Hitachi Ltd フラッシュメモリモジュール及びストレージシステム
JP5302582B2 (ja) * 2008-07-09 2013-10-02 株式会社日立製作所 上位装置から指定されるデバイスに関する記憶容量を変更するストレージシステム及び方法
JP5214502B2 (ja) * 2009-03-12 2013-06-19 株式会社日立製作所 ストレージ装置を管理する計算機及び方法
JP4874368B2 (ja) * 2009-06-22 2012-02-15 株式会社日立製作所 フラッシュメモリを用いたストレージシステムの管理方法及び計算機
CN102449607B (zh) * 2009-07-22 2015-05-27 株式会社日立制作所 具有多个闪存封装的存储系统
US8745353B2 (en) * 2009-10-23 2014-06-03 Seagate Technology Llc Block boundary resolution for mismatched logical and physical block sizes
WO2011128928A1 (en) * 2010-04-12 2011-10-20 Hitachi, Ltd. Storage device

Also Published As

Publication number Publication date
US9575672B2 (en) 2017-02-21
US20140379974A1 (en) 2014-12-25
WO2012168962A1 (en) 2012-12-13
JP2014506688A (ja) 2014-03-17
US8862805B2 (en) 2014-10-14
CN103384877A (zh) 2013-11-06
EP2652587B1 (en) 2017-11-15
EP2652587A1 (en) 2013-10-23
US20120317333A1 (en) 2012-12-13
CN103384877B (zh) 2016-03-23

Similar Documents

Publication Publication Date Title
JP5792313B2 (ja) ストレージシステム
JP5437373B2 (ja) 複数のフラッシュパッケージを有するストレージシステム
JP5816303B2 (ja) フラッシュメモリを含むストレージシステム、及び記憶制御方法
US8832371B2 (en) Storage system with multiple flash memory packages and data control method therefor
WO2015162758A1 (ja) ストレージシステム
US11321229B2 (en) System controller and system garbage collection method
JPWO2015076354A1 (ja) ストレージ装置と方法並びにプログラム
JP6995728B2 (ja) ストレージ装置、管理方法及びプログラム
EP3798852B1 (en) System controller and system garbage recovery method
JP6817340B2 (ja) 計算機
JP5768118B2 (ja) 複数のフラッシュパッケージを有するストレージシステム
JP6138318B2 (ja) 複数のフラッシュパッケージを有するストレージシステム
JP7140807B2 (ja) 仮想ストレージシステム
JP5945040B2 (ja) 複数のフラッシュパッケージを有するストレージシステム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140623

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140701

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140901

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150105

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150805

R150 Certificate of patent or registration of utility model

Ref document number: 5792313

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150