JP5816303B2 - フラッシュメモリを含むストレージシステム、及び記憶制御方法 - Google Patents

Description

本発明は、フラッシュメモリを含むストレージシステムの記憶制御に関する。

近年のストレージシステムは、多種多様なストレージ機能を有している。また、ストレージベンダは、これらのストレージ機能を有償で販売しているので、ストレージ機能の高性能化は、顧客価値が高い。フラッシュメモリは、磁気ディスクなどに比べ、基本性能が優れているだけでなく、動作特性も異なるので、フラッシュメモリを有効活用して、ストレージ機能の高性能化を図ることは有効なアプローチである。

また、フラッシュメモリは、メモリの特性上、データを書き換えようとした時、そのデータが元々格納されていた物理領域上に、そのデータを、直接上書きすることはできない。すでに書き込みを行った領域に、データの書き込みを行う際には、フラッシュメモリの消去単位であるブロックと呼ばれる単位で、消去処理を実行した後、データを書き込む必要がある。このため、データを書きかえる場合、元々そのデータが格納されていた領域に書き込むのではなく、別の領域に書き込むことが多い。同一のデータが複数の領域に書き込まれ、ブロックが満杯になると、ブロックの消去処理を行い、最新のデータだけを書き込み、空いている領域を作成するという処理が行われる。以下、この処理をレクラメーション処理と呼ぶ。このため、フラッシュメモリを搭載したパッケージ（以下、フラシュメモリパッケージ）では、外側に見せるアドレス層として、物理的なアドレスとは別に、論理的なアドレス層を設け、物理的なアドレスに割り当てる論理的なアドレスを適宜変更していく。また、物理的なアドレスが変更になっても、論理的なアドレスは変わらないので、外側からは、同一のアドレスでデータクセスが可能であるため、使い勝手の良さも維持できる。

次に、格納容量削減技術について述べる。一般的に、容量を削減する代表的な技術に圧縮技術がある。一方、近年、ストレージシステムでは、格納容量を削減する技術として、容量仮想化技術という技術が普及している。容量の仮想化技術とは、ストレージシステムが含む記憶装置の物理的な容量より大きな仮想的な容量を、ホスト側に見せる技術で、ストレージシステム内のストレージコントローラで実現されている。これは、ユーザが実際にストレージを使用する場合、ユーザが定義したユーザボリューム（ユーザからみた記憶装置）の容量に対し、実際に格納するデータの量は、この定義容量には、なかなか達しないという特性を利用したものである。すなわち、容量仮想化技術がない場合には、ボリューム定義時に、定義された物理的な容量を確保していたのに対し、容量仮想化技術を適用した場合には、実際にストレージシステムにデータが格納されたとき、初めて容量を確保することになる。これによって、格納容量を削減でき、かつ、ユーザはボリューム容量を厳密に定義する必要なく、単純に大きく余裕をもった値を定義すればよいため、使い勝っても向上できる。特許文献１では、多数のフラッシュパッケージに接続されたストレージコントローラを含むストレージシステムにおいて、ストレージコントローラだけでなく、フラッシュパッケージも、容量仮想化技術をもった方式が公開されている。特許文献１では、それぞれを区別するため、前者を上位レベルの容量仮想化機能、後者を下位レベルの容量仮想化機能と呼んでいる。このため、フラッシュパッケージは、ストレージコントローラには実際のフラッシュメモリの物理容量より大きな容量を、ストレージコントローラに見せていた。容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、ページと呼ばれる。特許文献１では、ストレージコントローラで実現される上位の容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、従来どおりページとした。一方、フラッシュパッケージで実現される下位の容量仮想化技術において、データが書き込まれたときに確保される物理的な記憶領域は、フラッシュメモリの消去単位であるブロックとしている。一般に、ページのサイズは、多様性にとんでいるが、特許文献１では、ページのサイズのほうが、フラッシュメモリの消去単位であるブロックのサイズより大きいものとしている。ところで、フラッシュメモリにおいては、一般的に、消去の単位は、前述したようにブロックと呼ぶのに対し、ブロックの中での読み書きの単位をページとよぶ。当然、フラッシュメモリにおいては、ブロックのサイズのほうが、ページサイズより大きくなる。しかし、特許文献１では、ページという言葉は、フラッシュメモリの読み書き単位でなく、上位レベルの容量仮想化におけるページをさしている。なお、本発明においても、ページという言葉は、フラッシュメモリの読み書き単位でなく、上位レベルの容量仮想化におけるページをさすものとする。ただし、本発明の対象となるストレージシステムは、上記の容量仮想化技術をもっていることが必ずしも必要条件とはならない。一方、通常、記憶装置には、ユーザのデータを格納する前に、特定のパターン、例えば、オール０などでフォーマティングする。特許文献２では、この際、ホストが書き込むこの特定パターンを、ストレージシステムで検出して、すでに割り当てているページを解放する技術も公開されている。特許文献１では、また、同じ公知例で、ストレージシステムで、オール０を検出した場合、フラッシュメモリ記憶装置に通知し、フラッシュメモリ記憶装置側では、その領域には、データを割り当てないよう制御する技術も開示されている。

ストレージシステムが持つ代表的なストレージ機能の１つは、コピー系の機能である。代表的な１つの機能として、メインとなるボリュームをベースに多様のボリュームをストレージシステム内にもつ機能がある。このようなボリュームの特徴は、多くのデータは、メインとなるボリュームと同じで、一部のデータだけが異なるという点である。格納容量の削減のため、ストレージシステムには、メインボリューム内のデータと同じデータ（つまり重複したデータ）は格納されずに、メインボリューム内のデータと異なるデータだけが格納されることが好ましい。最近では、サーバの技術として、仮想サーバが普及している。１つの物理サーバに多数（例えば１０−１００台）の仮想サーバが配置されることがある。このようなケースでは、仮想サーバ毎にボリュームを用意しておき、「ゴールデンイメージ」と呼ばれるデータ（仮想サーバのＯＳなどを含んだモジュール）を、仮想サーバ毎のボリュームにコピーすることが考えられる。ボリュームに格納された、ゴールデンイメージのコピーを、そのボリュームに対応する仮想サーバが使用する。仮想サーバ毎のボリューム内のデータは、ゴールデンイメージのボリュームと同じで、一部のデータだけが異なることがある。格納容量の削減のため、ゴールデンイメージと同じデータ（重複するデータ）はストレージシステムに格納されずに、ゴールデンイメージと異なるデータだけが格納されることが好ましい。

さらに、ストレージシステム内にメインとなるボリュームのバックアップとなるバックアップボリュームを取得するバックアップ技術が知られている。これは、大きくわけて２つの方法がある。

第１の方法は、サーバ（具体的には、サーバ上のアプリケーション）が現時点で使用しているボリュームをベースに、ある時点のイメージ（ビフォアイメージ）をボリュームとして、複数世代（たとえば、１日毎、１ヶ月毎）にわたって形成していく方法である。第２の方法は、過去の或る時点、例えば、１ヶ月前のバックアップボリュームをベースに、日ごとのバックアップイメージ（アフタイメージ）を取得していく方法である。第１の方法によれば、サーバが直接使用しているボリューム内のデータが更新される箇所について、その箇所の更新前のデータが取得され、その更新前のデータが、そのボリュームとは別の記憶領域に格納される。これにより、格納データが削減される。第２の方法によれば、サーバが直接使用しているボリューム内のデータが更新される箇所について、その更新後のデータが取得され、その更新後のデータが、そのボリュームとは別の記憶領域に格納される。これにより、格納データが削減される。

国際公開第２０１１／０１０３４４号パンフレット 特開２００７−１９９９２２号公報

フラッシュメモリを含む大容量ストレージシステムにおいては、フラッシュメモリチップの数は、数万に及ぶ。このため、数百のチップを搭載したフラッシュパッケージを数百枚と、数千台のHDD（Hard Disk Drive）をストレージシステムのコントローラに接続するのが典型的な構成となる。

本発明において解決しようとする課題は、ストレージシステム内に、あるボリューム（プライマリボリューム）をベースに、別のボリュームのコピーを作成する際に、プライマリボリュームとは異なったデータ（差分データ）だけを格納するという方式を、フラッシュパッケージとストレージコントローラを連携させることで、高性能化することである。以下、差分データを格納したボリュームを差分ボリュームと呼ぶ。特許文献１では、下記の技術、
（１）容量仮想化技術（下位レベルの容量仮想化技術）、
（２）データが単純なデータの繰り返しパターンであるか否かを判断して、その判断の結果が肯定的であれば、物理的な領域を割り当てない、という技術、
が開示されている。しかし、フラッシュパッケージとストレージコントローラを連携させることで、差分ボリュームを高性能に生成する技術は開示されていない。

前記の課題を解決するための観点の一例は、以下の通りである。

ストレージコントローラが、フラッシュパッケージの同一のアドレス空間（論理的なアドレス空間）に、複数の論理ボリュームのデータを書き込んだり、読み出したりすることである。

このため、ストレージコントローラは、アクセス要求（典型的にはリード要求／ライト要求）を発行する際、アクセス対象のアドレス（リード元のアドレス又はライト先のアドレス）に加えて、世代番号を指定する。世代番号は、プライマリボリュームや差分ボリュームの識別に使用される。

さらに、フラッシュパッケージは、物理容量よりも大きな容量を格納できるよう、物理容量より大きな仮想空間容量を、ストレージシステム内のコントローラに見せる。また、フラッシュパケージは、仮想空間をいくつかの仮想ブロックグループに分割して、これをいくつかの実ブロックに割り当てる。一つの仮想ブロックグループ、実ブロックに、複数の論理ボリュームのデータが格納される。以上のような特性（フラッシュメモリの特性）を活かすことで、差分ボリュームの生成を高性能化することが期待できる。すでに、述べたように、フラッシュメモリでは、データを書きかえる場合、メモリの特性上、元々そのデータが格納されていた領域に書き込むのではなく、別の領域に書き込むことが多い。同一のデータが複数の領域に書き込まれ、実ブロックが満杯になると、レクラメーション処理が実行される。一般に、レクラメーション処理を実行する際に、同一のアドレス（例えば、同一の仮想的なセグメント）について複数のデータが存在している場合、最新の更新データだけを残して、他のデータは消去される。しかし、本観点によれば、同一のアドレスについて世代が異なる複数のデータがあることがあり、その複数のデータのうちの或るデータは、その同一アドレスについて最新の更新データでなくても、１つの世代について最新の更新データであることがある。つまり、本観点によれば、同一のアドレスについて、世代毎に、最新の更新データが記憶され、世代毎に最新の更新データではないデータが消去される。これにより、差分データ（例えば、プライマリボリューム内のデータとの差分に相当するデータ）を、効率的に記憶することができる。また、世代毎に、すべてのアドレスに更新が発生するとは限らない。その場合、バックアップボリュームの場合、通常、１つ前の世代のデータが有効となる。１つ前の世代に、データがなければ、当該データが更新された最新のデータが有効となる。本観点に従うフラッシュパッケージは、対象の世代が指定されたリード要求をストレージコントローラから受け、パッケージ内に格納された世代を遡って、有効な世代のデータを、そのリード要求に従うデータとしてストレージコントローラに提供する機能をもつ。一方、仮想サーバのゴールデンイメージのベースとなるボリュームと差分ボリューム間の関係は、もっと複雑になる。このため、ベースとなるボリュームと差分ボリューム間の関係を、ストレージコントローラか、フラッシュパッケージのどちらかが保持する。

以上のような方式が採用される、仮想ブロックグループによって、更新頻度が異なるため、仮想ブロックグループによって、フラッシュパッケージに格納されるデータ量が異なることになる。フラッシュパッケージの物理容量には限りがあるので、物理的な空き容量が少なくなってきた場合、以下の方法で、物理的な空き容量を増加させることができる。この際、ストレージコントローラが上位レベルの容量仮想化機能をもつことが前提となる。上位レベルの容量仮想化機能で、領域の割り当て単位は「ページ」と呼ばれる。本観点の１つの特徴は、１つのページに複数の世代のデータを含む点、言い換えれば、複数の世代にそれぞれ対応した複数のボリュームの領域に同一のページが割り当てられる点である。フラッシュパッケージの物理的な空き容量を増やす第１の方法は、複数世代のデータを含んだページを、別のフラッシュパッケージに移動する方法である。第２の方法は、１つのページを複数のページに世代分割する方法である。具体的には、１つのページにＮ世代が対応している場合、Ｎ世代が１つのページではなく複数のページに対応付けられる。より具体的には、例えば、１つのページに第１世代から第１０世代までのデータが格納されている場合、第１世代から第５世代までのデータは当該ページに残しておき（或いは別の第１のページに移され）、第６世代から第１０世代までのデータが第２のページに移される。

それぞれが多数のフラッシュメモリを実装したフラッシュパッケージを多数接続した大容量のストレージシステムにおいて、性能劣化を抑えて、データ格納容量の削減し、物理容量よりも大きな容量のデータを格納することが可能となる。

実施例における情報システムの構成を示す図である。 実施例におけるストレージシステムの構成を示す図である。 実施例におけるフラッシュパッケージの構成を示す図である。 実施例におけるストレージシステムの共有メモリに格納された上位レベルの制御を行う情報を示す図である。 実施例における論理ボリューム情報の形式を示す図である。 実施例における実ページ情報の形式を示す図である。 実施例における仮想ページ、実ページ、仮想ブロック、実ブロックの関係を表した図である。 実施例におけるフラッシュパッケージ情報の形式を示すである。 実施例におけるフラッシュパッケージグループ情報の形式を示す図である。 実施例における空きページ管理情報ポインタからポイントされた空き状態にある空き実ページ情報の集合を表した図である。 実施例における使用不可実ページ情報ポインタからポイントされた使用不可状態にある実ページ情報の集合を表した図である。 実施例におけるフラッシュパッケージのパッケージメモリ内に下位レベルの階層の制御を行うための情報を示す図である。 実施例における下位レベルの階層の制御を行うための情報を、ストレージシステムの共有メモリに設けた構成を示す図である。 実施例におけるパッケージ情報の形式を示す図である。 実施例におけるチップ情報の形式を示す図である。 実施例における仮想ブロック情報の形式を示す図である。 実施例における実ブロック情報の形式を示す図である。 実施例における空き実ブロック情報ポインタによりポイントされる空き状態にある実ブロックの集合を表す図である。 実施例におけるストレージコントローラのメモリ内の上位レベルの制御を行うプログラムを示す図である。 実施例におけるリード処理実行部の処理フローを示す図である。 実施例におけるライト要求受付部の処理フローを示す図である。 実施例におけるライトアフタ処理実行部の処理フローを示す図である。 実施例における実ページ分割処理部の処理フローを示す図である。 実施例における実ページ移動処理実行部の処理フローを示す図である。 実施例におけるフラッシュパッケージのパッケージメモリ内の下位レベルの制御を行うプログラムを示す図である。 実施例における下位レベルの制御を行うプログラムを、ストレージコントローラのメモリに格納した構成を示す図である。 実施例におけるデータリード処理実行部の処理フローを示す図である。 実施例におけるデータライト処理実行部の一部の処理フローを示す図である。 実施例におけるデータライト処理実行部の一部の処理フローを示す図である。 実施例における論理ボリューム生成処理部の処理フローを示す図である。 実施例における仮想ブロック移動処理実行部の処理フローを示す図である。 実施例における仮想ブロック格納処理実行部の処理フローを示す図である。 実施例における仮想容量判定処理部の処理フローを示す図である。 実施例における論理ボリュームグループの構成の第１の例を表した図である。 実施例における論理ボリュームグループの構成の第２の例を表した図である。 実施例における論理ボリュームグループの構成の第３の例を表した図である。 実施例における空き状態にある論理ボリューム情報のキューを表した図である。

以下、図面を参照して、本発明の一実施例を説明する。

図１は、一実施例における情報システムの構成を示す。

情報システムは、ストレージシステム１００、ホスト１１０と、それらを接続するSAN（Storage Area Network）１２０とを有する。ホスト１１０は、アプリケーションプログラム（ユーザアプリケーション）を実行する計算機であり、ストレージステム１００との間で、SAN１２０経由で、必要なデータを読み書きする。SAN１２０は、SCSIコマンドが転送可能なプロトコルを用いる。そのプロトコルとして、例えば、Fibre
Channel等のプロトコルを用いることができる。SCSIコマンド以外に、メインフレームのI/Oプロトコルも用いることもできる。

図２は、ストレージシステム１００の構成を示している。

ストレージシステム１００は、一つ以上のストレージコントローラ２００、キャッシュメモリ２１０、共有メモリ２２０、フラッシュパッケージ２３０、などの構成要素を接続する一つ以上の接続装置２５０、から構成される。また、本実施例においては、ストレージシステム１００内の記憶媒体は、すべてフラッシュパッケージ２３０であるが、ＨＤＤ（Hard Disk Drive）のような他の記憶媒体を含んでいてもよい。また、本実施例におけるフラッシュパッケージ２３０の容量はすべて等しいものとする。ただし、本発明は、フラッシュパッケージ２３０の容量の中に異なっているものがあっても有効である。ストレージコントローラ２００は、ホスト１１０から発行されたアクセス要求（典型的にはリード要求又はライト要求）を処理するプロセッサ２６０、プログラムや情報を保管するメモリ２７０から構成される。

本実施例の１つの特徴は、次の通りである。すなわち、ストレージシステム１００内に、ある論理ボリューム（プライマリボリューム）をベースに、差分ボリューム（プライマリボリュームとの差分に相当する論理ボリューム）を作成する際に、プライマリボリューム内のデータとは異なったデータ（差分データ）を格納しプライマリボリューム内のデータと同じデータ（重複データ）を格納しないという方式が、フラッシュパッケージ２３０とストレージコントローラ２００を連携させることで、高性能に実現される。差分データは、差分ボリュームに格納されても良いし差分ボリュームとは別の記憶領域に格納されても良い。ここで、関連のある論理ボリュームの集合（例えば、プライマリボリュームと、プライマリボリュームをベースに作成された差分ボリュームとの集合）を、「論理ボリュームグループ」と呼ぶ。なお、本実施例では、差分ボリュームを生成する目的は、下記の２つ、
（１）バックアップ、及び、
（２）ゴールデンイメージからの仮想サーバイメージの生成、
のいずれかであるとする。勿論、本発明は、上記２つの目的以外の目的で差分ボリュームが生成されることにも有効である。

本実施例は、多数のフラッシュメモリを有するストレージシステム１００において、フラッシュメモリへの格納データ容量削減技術（フラッシュメモリに格納するデータの容量を削減する技術）を実現するものである。本実施例においては、ストレージシステム１００は、階層型の容量仮想化技術をもつ。上位レベルの容量仮想化技術の制御単位は、ページとよばれる単位である。本実施例におけるページは、ストレージコントローラ２００で実現される容量仮想化技術で用いられるページである。なお、本発明は、階層型の容量仮想化技術における上位レベルの制御単位は、ページでなくとも有効である。本実施例では、ページのサイズは、フラッシュメモリにおける消去単位であるブロックよりも大きい。例えば、ページのサイズは、ブロックのサイズのＸ倍である（Ｘは２以上の整数）。通常、フラッシュメモリにおいては、リード・ライトの単位をページと呼ぶので、ページはブロックよりも小さい。しかし、すでに述べたように、本実施例では、ページは、上位レベルの容量仮想化技術についての制御単位（シンプロビジョニングに従う仮想的な論理ボリュームに割り当てられる記憶領域）を意味しており、そのサイズは、ブロックよりも大きい。なお、本実施例では、フラッシュメモリにおけるリード・ライトの単位を、上位レベルの容量仮想化の制御単位であるページと区別するため、「セグメント」と呼ぶ。また、下位レベルの容量仮想化技術の制御単位は、本実施例では、フラッシュメモリの消去単位であるブロックのＮ倍（Ｎは１以上の整数）の単位として、説明を行う。また、本発明は、記憶媒体をフラッシュメモリとし、実容量より大きい仮想容量を持ち、消去単位であるブロックを割り当て単位とした、容量仮想化機能を、単独に、従来の上位レベルの容量仮想化機能なしに、ホスト１１０に提供しても有効である。

図２は、ストレージシステム１００の構成を示している。

ストレージシステム１００は、一つ以上のストレージコントローラ２００と、キャッシュメモリ２１０と、共有メモリ２２０と、フラッシュパッケージ２３０と、それらの構成要素を接続する一つ以上の接続装置２５０とを有する。また、本実施例においては、ストレージシステム１００内の複数の記憶媒体は、すべてフラッシュメモリであるが、ストレージシステム１００は、フラッシュメモリの他に、HDDのような他種の記憶媒体を含んでいてもよい。また、本実施例において、全てのフラッシュパッケージ２３０の物理容量（物理的な記憶容量）は等しい。ただし、本発明は、複数のフラッシュパッケージ２３０のうちの少なくとも２以上のフラッシュパッケージ２３０の物理容量が異なっていても良い。ストレージコントローラ２００は、ホスト１１０から発行されたリード要求又はライト要求を処理するプロセッサ２６０と、プログラム及び／又は情報を記憶する記憶資源（例えばメモリ２７０）とを有する。

接続装置２５０は、ストレージシステム１００内の各構成要素を接続する機構である。また、本実施例では、高信頼化のために、一つのフラッシュパッケージ２３０は、複数の接続機構２５０で、複数のストレージコントローラ２００に接続されているものとする。ただし、一つのフラッシュパッケージ２３０が一つの接続装置２５０にしか接続されていない場合も本発明は有効である。

キャッシュメモリ２１０及び共有メモリ２２０の少なくとも一方は、通常、DRAMなどの揮発メモリで構成されるが、バッテリーなどによりメモリは不揮発化されていても良い。ただし、本発明は、キャッシュメモリ２１０及び共有メモリ２２０の少なくとも一方が不揮発化されていなくても有効である。

キャッシュメモリ２１０には、フラッシュパッケージ２３０に格納されたデータの中で、ストレージコントローラ２００からよくアクセスされるデータが格納される。ストレージコントローラ２００は、ホスト１１０からライト要求を受け付け、そのライト要求に従うデータ（フラッシュパッケージ２３０に書き込むデータ）を、キャッシュメモリ２１０に書き込んで、そのライト要求を完了させる（例えばライト要求に対する完了報告をホスト１１０に送る）。ただし、本発明は、書き込むデータをフラッシュパッケージ２３０に格納した段階でライト要求を完了させる方式でも有効である。

共有メモリ２２０は、キャッシュメモリ２１０の制御情報、ストレージシステム１００内の重要な管理情報、ストレージコントローラ２００間の連絡情報、及び、同期情報のうちの少なくとも１種類の情報を記憶する。

なお、本実施例では、フラッシュパッケージ２３０は、ストレージコントローラ２００からは、一台の記憶装置に見えているものとする。したがって、ストレージコントローラ２００が、高信頼化のために、一台のフラッシュパッケージ２３０が故障しても、そのフラッシュパッケージ２３０のデータを回復できるＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）機能をもっているものとする。ストレージコントローラ２００がRAID機能もつ場合、複数のフラッシュパッケージ２３０で、一つのRAID構成をとる。これを、フラッシュパッケージグループ２８０と呼ぶ。ただし、そのようなRAID機能を、ストレージコントローラ２００がもっていなくとも、本発明は有効である。

図３は、フラッシュパッケージ２３０の構成を示している。

フラッシュパッケージ２３０は、複数のフラッシュチップ３００と、パッケージプロセッサ３１０と、パッケージメモリ３２０と、バッファ３３０と、パッケージバス３４０と、バス転送装置３５０と、圧縮・伸長回路３６０とを有する。本実施例では、フラッシュパッケージ２３０は、ブロック単位の容量仮想化機能をもっている。なお、フラッシュパッケージ２３０が、ブロック単位以外の容量仮想化機能をもっていても、本発明は有効である。このため、フラッシュパッケージ２３０の物理容量（フラッシュパッケージ２３０がもっている全てのフラッシュチップ３００の物理容量を合計した値）より大きな容量が、仮想容量として定義される。フラッシュパッケージ２３０は、ストレージコントローラ２００からライト要求を受け付けたとき、そのライト要求に従うライト先のアドレス（そのアドレスが属する仮想的な領域）に、データを書き込むべきブロックが割り当てられているかどうかを判断し、その判断の結果が否定的の場合に、ライト先のアドレスに、ブロックを割り当てる。これによって、実際にブロックを割り当てる時刻を遅らせることができ、容量削減の効果がある。

また、２つの圧縮・伸長回路３６０Ａ及び３６０Ｂが設けられている。第１の圧縮・伸長回路３６０Ａは、ストレージコントローラ２００とバッファ３３０の間で転送されるデータを圧縮又は伸長する。第２の圧縮・伸長回路３６０Ｂは、バス転送装置３５０とバッファ３３０の間で転送されるデータ、及び、バッファ３３０の或る領域から読み出されてバッファ３３０の別の領域に書き込まれるデータを、圧縮又は伸長する。以上により、フラッシュチップ３００に格納するデータを圧縮することができるので、さらなる容量削減の効果がある。また、本実施例では、圧縮・伸長回路３６０Ａ及び３６０Ｂは、特に指示がない場合（例えば、パッケージプロセッサ３１０からの指示がない場合）、圧縮及び伸長のいずれも行わず、入力されたデータをそのまま転送する。

パッケージプロセッサ３１０は、ストレージコントローラ２００からリード要求又はライト要求を受け付け、受けた要求に従う処理を実行する。

バッファ３３０は、ストレージコントローラ２００とフラッシュチップ３００との間でリード又はライトされるデータを格納する。本実施例では、バッファ３３０は、揮発メモリである。パッケージプロセッサ３１０が、ストレージコントローラ２００からライト要求を受け、そのライト要求に従うデータをフラッシュチップ３００に書き込んだ段階で、そのライト要求を完了する（ライト要求の完了をストレージコントローラ２００に報告する）。ただし、バッファ３３０が不揮発メモリであっても良く、また、パッケージプロセッサ３１０は、ストレージコントローラ２００からのライト要求に従うデータをバッファ３３０に書き込んだ段階で、そのライト要求の完了報告をストレージコントローラ２００に送信しても良い。

パッケージメモリ３２０には、パッケージプロセッサ３１０が実行するプログラム、及び、フラッシュチップ３００の管理情報などが格納される。フラッシュパッケージ２３０の管理情報は重要な情報であるので、計画停止時には、管理情報を特定のフラッシュチップ３００に退避できることが望ましい。また、突発的な障害に備え、バッテリーをもち、これを利用して、障害などが発生しても、管理情報を特定のフラッシュチップ３００に退避できることが望ましい。

パッケージバス３４０は、バッファ３３０とフラッシュチップ３００との間で転送されるデータが流れるバスで、一本以上存在する。性能向上のために、複数のパッケージバス３４０を持つのが一般的だが、パッケージバス３４０が一本でも本発明は有効である。

バス転送装置３５０は、パッケージバス３４０対応に存在し、パッケージプロセッサ３１０の指示にしたがって、バッファ３３０とフラッシュチップ３００との間で、データ転送を実行する。

圧縮・伸長回路３６０Ａ及び３６０Ｂは、パッケージプロセッサ３１０からの指示に従い、バッファ３３０から読み出されるデータ、及び／又は、バッファ３３０に書き込まれるデータの圧縮又は伸長を行う。もちろん、圧縮・伸長回路３６０Ａ及び３６０Ｂは、データを、圧縮又は伸長なしに転送することも可能である。

図４は、ストレージシステム１００の共有メモリ２２０に格納される情報を示す。

論理ボリューム情報２０００、実ページ情報２１００、空きページ管理情報ポインタ２２００、フラッシュパッケージグループ情報２３００、フラッシュパッケージ情報２５００、仮想ページ容量２６００、使用不可ページ情報管理ポインタ２７００及び空き論理ボリューム情報ポインタ２９００が共有メモリ２２０に格納される。これらの情報のうちの少なくとも１種類が、上位レベルの容量仮想化技術を実現するために利用される。

本実施例においては、ストレージコントローラ２００は、上位レベルの容量仮想化機能を有しているものとする。ただし、本発明は、ストレージコントローラ２００が、上位レベルの容量仮想化機能をもっていなくとも有効である。通常、上位レベルの容量仮想化機能において、記憶領域の割り当て単位は、ページと呼ばれる。なお、本実施例では、論理ボリューム（例えば、シンプロビジョニングに従う仮想的な論理ボリューム）は、複数の仮想ページ（仮想的な記憶領域）に分割されているものとし、１以上のフラッシュパッケージグループ２８０に基づく記憶空間（以下、「プール」と言うことがある）は、複数の実ページ（実体的な記憶領域）に分割されているものとする。容量仮想化においては、論理ボリュームの記憶容量を、実際の容量よりも大きく見せることができる。このため、一般に、仮想ページの数は、実ページの数より多い。容量仮想化機能を実現した場合、ストレージコントローラ２００が、ホスト１１０からのライト要求に従うライト先のアドレスに属する仮想ページに、空きの実ページをプールから割り当て、その実ページに、ライト要求に従うデータを書き込む。

仮想ページ容量２６００は、仮想ページの容量を表す情報である。しかし、本実施例では、仮想ページの容量と実ページの容量は等しいというわけではない。なぜなら、実ページには、RAIDのタイプにより異なってくる冗長データが格納されることがあるためである。したがって、実ページの容量は、その実ページが割り当てられたフラッシュパッケージグループ２８０のRAIDタイプにより決まる。たとえば、RAID１のようにデータを２重に書き込む場合、実ページの容量は、仮想ページ容量の２倍になる。RAID5のように、N台の記憶装置の容量に対し、１台分の記憶装置の容量の冗長データを格納する場合、仮想ページ容量の（N+１）/Nの容量が、実ページの容量である。また、１つの冗長データとこれを生成するN個のデータを、「ストライプグループ」と呼ぶ。さらに、ストライプグループを構成する個々のデータの長さを「ストライプサイズ」と呼ぶ。当然、RAID0のように、冗長性がない場合、仮想ページの容量と等しい容量が実ページの容量ということになる。なお、本実施例においては、仮想ページの容量は、ストレージシステム１００が提供する１又は複数の論理ボリューム（シンプロビジョニングに従う仮想的な論理ボリューム）について共通であるが、１又は複数の仮想ボリュームにおいて異なる容量の仮想ページが含まれていても、本発明は有効である。

図５は、論理ボリューム情報２０００の形式を示したものである。

論理ボリュームは、リード又はライトされるデータを記憶する論理的な記憶装置である。一般的に、ホスト１１０は、論理ボリュームのＩＤ、論理ボリューム内のアドレス、及び読み書きしたいデータの長さを指定したアクセス要求（リード要求、ライト要求）を発行する。論理ボリューム情報２０００は、論理ボリュームごとに存在する情報である。この情報は、論理ボリュームID２００１、論理容量２００２、論理ボリュームRAIDタイプ２００３、空き論理ボリュームグループ情報ポインタ２００４、論理ボリュームグループタイプ２００５、グループ内GＩ（Golden Image）ID２００６、グループ内BK（BacKup）ID２００７、GＩポインタ２００８、ＧＩ順ポインタ２００９、ＧＩ逆ポインタ２０１０、ＢＫ順ポインタ２０１３、ＢＫ逆ポインタ２０１４、及び実ページポインタ２０１１により構成される。

本実施例では、ある論理ボリューム（プライマリボリューム）をベースにした新しい論理リューム（差分ボリューム）の生成を指示されると論理ボリュームグループが形成される。この指示は、ホスト１１０や管理サーバ１２０からストレージシステム１００に送られる。差分ボリューム内のデータは、この指示をうけた時点での、プライマリボリュームのデータとなる。したがって、この時点では、差分ボリュームのデータは、プライマリボリュームのデータと同じなので、そういったことを認識するための仕掛けをもてば、データを重複して格納する必要はない。指示を受けた時点以降にプライマリボリューム又は差分ボリュームにデータが書き込まれると、論理ボリューム間（プライマリボリュームと差分ボリューム間）で差が生じる。このため、指示を受けた時点以降のデータは、フラッシュパッケージ２３０に格納され、管理される必要がある。本実施例は、フラッシュメモリの特性を利用して、以上の管理を効率的に実行することを目的にしている。

論理ボリュームID２００１は、対応する論理ボリュームのIDを示す。

論理容量２００２は、ホスト１１０から見たこの論理ボリュームの容量である。

論理ボリュームRAIDグループタイプ２００３は、該当する論理ボリュームのRAIDタイプ、RAID0、RAID1などを指定する。RAID5のように、N台の容量に対し、１台の容量の冗長データを格納する場合、Nの具体的数値を指定するものとする。ただし、任意のRAIDタイプが指定できるわけでなく、少なくとも一つのフラッシュパッケージグループ２８０がもつRAIDタイプである必要がある。

空き論理ボリュームグループ情報ポインタ２００４は、空き状態にある次の論理ボリューム情報を示すポインタである。本実施例では、論理ボリュームが単独に存在しているのであれば、ある論理ボリュームグループに属する論理ボリュームの数は１つである。このボリュームをベースにした差分ボリューム（新しい論理ボリューム）が生成されると、論理ボリュームグループに属する論理ボリュームの数が複数になる。

論理ボリュームグループタイプ２００５は、論理ボリュームのタイプを示す。ここでは、そのタイプは、ＧＩボリューム、オンラインボリューム、バックアップボリュームのいずれかである。ＧＩボリュームは、仮想サーバのゴールデンイメージを格納したボリュームである。オンラインボリュームは、ホスト１１０のアプリケーションが使用するデータを格納したボリュームである。オンラインボリュームは、独立に生成されるものと、ＧＩボリュームから生成されるものとがある。バックアップボリュームは、オンラインボリュームのある時点のバックアップデータを格納したものである。本実施例では、通常の論理ボリュームは、オンラインボリュームになっているものとする。プライマリボリュームをベースにした差分ボリュームにゴールデンイメージを生成せよというＧＩ生成要求を、ストレージコントローラ２００が受け取ったとき、プライマリボリュームのボリュームタイプを、ＧＩボリュームにして、差分ボリュームのボリュームタイプをオンラインボリュームにする（ＧＩ生成要求は、すでにゴールデンイメージになっているプライマリボリュームをベースに差分ボリュームにゴールデンイメージを生成せよという要求でも良い）。オンラインボリュームになっているプライマリボリュームをベースに差分ボリュームにバックアップをとれというバックアップ要求をストレージコントローラ２００が受け付けると、ストレージコントローラ２００は、ボリュームタイプがバックアップボリュームである差分ボリュームを生成する。

グループ内ＧＩID２００６は、当該論理ボリュームグループ内のＧＩボリューム（ゴールデンイメージ）から生成されたオンラインボリュームの識別子である。

グループ内BKＩＤ２００７は、当該論理ボリュームグループの１つのオンラインボリュームから生成されたバックアップボリュームの識別子である。なお、本実施例では、異なったオンラインボリュームから生成されたバックアップボリュームのグループ内BKＩＤ２００７は、重複するが、重複しないようにしても、本発明は有効である。

ＧＩポインタ２００８は、当該論理ボリュームの生成元となったＧＩボリューム（ゴールデンイメージ）の論理ボリューム情報２０００へのポインタである。

ＧＩ順ポインタ２００９は、１以上のポインタ（論理ボリューム情報２０００のポインタ）で構成されている。それら１以上のポインタは、同じゴールデンイメージから生成された論理ボリューム情報２０００の生成順に並んでいる。

ＧＩ逆ポインタ２０１０は、１以上のポインタ（論理ボリューム情報２０００のポインタ）で構成されている。それら１以上のポインタは、ＧＩ順ポインタ２００９とは逆の順序で並んでいる。

ＢＫ順ポインタ２０１３は、１以上のポインタ（論理ボリューム情報２０００のポインタ）で構成されている。それら１以上のポインタは、バックアップボリュームの古い世代から新しい世代の順に並んでいる。

ＢＫ逆ポインタ２０１４は、１以上のポインタ（論理ボリューム情報２０００のポインタ）で構成されている。それら１以上のポインタは、ＢＫ順ポインタ２０１３とは逆の順序で並んでいる。

本実施例では、単独の論理ボリュームが存在している状態であれば、その論理ボリュームの論理ボリュームグループタイプ２００５は、オンラインになっているものとする。また、論理ボリュームの論理ボリューム情報２０００のＧＩポインタ２００８、ＧＩ順ポインタ２００９、ＧＩ逆ポインタ２０１０、ＢＫ順ポインタ２０１３、ＢＫ逆ポインタ２０１４は、いずれもヌル値で、グループ内ＧＩID２００６、グループ内ＢＫＩＤ２００７は、いずれも０番とする。

図３４〜図３６は、論理ボリュームグループの構成の幾つかの例を示す。

図３４に示す第１の論理ボリュームグループ構成例によれば、１つのＧＩボリューム（ゴールデンイメージ）から複数のオンラインボリューム（差分ボリューム）が生成されている。この場合、それぞれのオンラインボリュームの論理ボリュームグループタイプ２００５をもつ論理ボリューム情報２０００のＧＩポインタ２００８が、ＧＩボリュームの論理ボリュームグループタイプ２００５をもつ論理ボリューム情報２０００をポイントする。また、論理ボリュームグループタイプ２００５が、ゴールデンイメージの論理ボリューム情報２０００を先頭に最後に生成された論理ボリュームの論理ボリューム情報２０００が、ＧＩ順ポインタ２００９とＧＩ逆ポインタ２０１０の双方向のポインタにより連結されている。

図３５に示す第２の論理ボリュームグループ構成例によれば、オンラインボリュームから複数世代のバックアップボリュームが生成されている。この場合、最近生成された論理ボリュームの論理ボリューム情報２０００の論理ボリュームグループタイプ２００５が、オンラインボリュームになり、古い論理ボリューム情報２０００の論理ボリュームグループタイプ２００５が、バックアップボリュームになる。ただし、ホスト１１０から見た論理ボリュームのアドレスは、変化しないので、新しい論理ボリューム情報２０００の論理ボリュームＩＤ２００１と論理ボリュームグループタイプ２００５に、それまでのオンラインボリュームという論理ボリューム情報２０００の論理ボリュームＩＤ２００１と論理ボリュームグループタイプ２００５とがコピーされる。生成された論理ボリュームのベースになる古い論理ボリューム（プライマリボリューム）の論理ボリューム情報２０００の論理ボリュームグループタイプ２００５に、バックアップボリュームを意味する値が設定され、その情報２０００の論理ボリュームＩＤ２００１に、プライマリボリュームの識別子が設定される。各論理ボリュームは、ＢＫ順ポインタ２０１３とＢＫ逆ポインタ２０１４によって接続される。グループ内ＢＫＩＤ２００５は、論理ボリューム情報２０００の生成順に昇順となる。

図３６に示す第３の論理ボリュームグループ構成例によれば、ＧＩボリューム（ゴールデンイメージ）からオンラインボリュームが生成されており、さらに、オンラインボリュームに対し、バックアップボリュームが生成されている。この例では、ＧＩポインタ２００８が、ＧＩボリュームの論理ボリューム情報を示すのは、論理ボリュームグループタイプ２００５がオンラインボリュームの論理ボリューム情報２０００である。また、論理ボリュームグループタイプ２００５がＧＩボリュームの論理ボリューム情報２０００と論理ボリュームグループタイプ２００５がオンラインボリュームの論理ボリューム情報２０００が、ＧＩ順ポインタ２００９とＧＩ逆ポインタ２０１０の双方向のポインタにより連結されている。これ以外は、図３４及び図３５を参照して説明したので、ここでの説明を省略する。つまり、図３６に示す論理ボリュームグループ構成例は、図３４に示した論理ボリュームグループ構成例と図３５に示した論理ボリュームグループ構成例の組み合わせに基づいている。

本実施例の１つの特徴は、ストレージコントローラ２００が、フラッシュパッケージ２３０に送信するアクセス要求（リード要求及びライト要求）に、アクセス対象のアドレス（リード元領域のアドレス、ライト先領域のアドレス）に加えて、グループ内ＧＩＩＤ又はグループ内ＢＫＩＤを付加する（グループ内ＧＩＩＤ又はグループ内ＢＫＩＤは、世代番号の一例に相当する）。これによって、フラッシュパッケージ２３０は、同じアドレスを指定されても、グループ内ＧＩＩＤ又はグループ内ＢＫＩＤが異なった場合、異なったデータが読み書き対象となっていることを認識できる。

再び図５を参照する。実ページポインタ２０１１は、対応する論理ボリュームの仮想ページに割り当てたページ管理情報２１００へのポインタである。実ページポインタ２０１１の数は、論理ボリュームの仮想ページの数（論理容量２００２が表す値を仮想ページ容量２６００が表す値で割った数になるが、余りがでれば、商に１を足す）である。最初の実ページポインタ２０１１に対応するページが、論理ボリュームの先頭の仮想ページに割り当てられた実ページで、以降、次の実ページポインタ２０１１には、次の仮想ページに割り当てる実ページに対応するポインタが格納される。また、仮想容量機能をサポートしているので、実ページが割り当てられるのは、論理ボリュームを定義した契機ではなく、対応する仮想ページに実際にデータ書き込みが行われる契機である。したがって、まだ書き込みが行われていない仮想ページの場合、対応する実ページポインタ２０１１はヌルになっている。

図６は、実ページ情報２１００の形式である。

実ページ情報２１００は、実ページごとに存在する、実ページの管理情報である。実ページ情報２１００は、パッケージグループ２１０１、実ページアドレス２１０２、空きページポインタ２１０３、ページデータ格納量２１０４、ページ圧縮後データ格納量２１０５、移動中フラグ２１０９、移動先実ページ情報２１１０、移動待ちフラグ２１１１、論理ボリューム数２１１２及び論理ボリューム情報ポインタ２１１３を含む。

パッケージグループ２１０１は、対応する実ページが、どのフラッシュパッケージグループ２８０に割り当てられているかを示す。

実ページアドレス２１０２は、対応する実ページの基になっているフラッシュパッケージグループ２８０の中で、対応する実ページがどの相対的なアドレスに割り当てられているかを示す情報である。

空きページポインタ２１０３は、対応する実ページに、仮想ページが割り当てられていない場合、有効な値となる。この場合、その値は、次の仮想ページが割り当てられていない空きページ情報２１００をさす。仮想ページが割り当てられている場合、空きページポインタ２１０３は、ヌル値となる。

本実施例においては、それぞれのフラッシュパッケージ２３０は、容量仮想化機能をもっており、ストレージコントローラ２００には、見かけ上、実際の物理容量より大きな容量を仮想容量として提供している。フラッシュパッケージ２３０の容量仮想化の単位は、本実施例では、フラッシュメモリの消去単位であるブロックとする。以下、ストレージコントローラ２００から見たブロックを「仮想ブロック」と呼び、フラッシュパッケージ２３０が、実際に割り当てているブロックを「実ブロック」と呼ぶことがある。したがって、本実施例では、実ページは、１又は複数の仮想ブロックにより構成されることになる。また、本実施例では、仮想ブロックにより構成される容量空間のほうが、実ブロックにより構成される容量空間より大きいことになる。

図７は、仮想ページ、実ページ、仮想ブロック、実ブロックの関係の一例を示したものである。

すでに述べたように、実ページには、仮想ページにはない、冗長データが含まれることがある。一方、仮想ブロックに格納されるデータは、圧縮されて実ブロックに格納される。本実施例では、ｍ個（ｍは１以上の整数）の仮想ブロックのデータが、圧縮率に応じて、１個からmin（k，L＊（当該仮想ブロックグループに割り当てた論理ブロック数））＊（ｍ＋１）個までの実ブロックに格納される。ｋは、例えば世代数である。Lは、例えば１より小さい値（且つ、例えば０より大きい値）である。ただし、上記の格納方式を採らない場合でも、本発明は有効である。本実施例の説明において、このｍ個の仮想ブロックを「仮想ブロックグループ」と言い、１つの仮想ブロックグループを割り当てた１つ以上の実ブロックを「実ブロックグループ」と言うことがある。以下、本実施例で、実ブロックの最大割り当て数をmin（k，L＊（当該仮想ブロックグループに割り当てた論理ブロック数））＊（ｍ＋１）個にした理由を以下に示す。

仮に、仮想ブロックグループのデータがほとんど圧縮できなかったとする。この場合、必要な実ブロックの数はｍ個となるが、実ブロックに空き容量はほとんどないことになる。このとき、ブロック内の一部のデータを書き換える要求（普通のライト要求）を、ストレージコントローラ２００からフラッシュパッケージ２３０が受け取ったとしよう。フラッシュメモリのブロックは書き換えができないので、フラッシュパッケージ２３０は、そのブロックの全データをバッファ３３０に読み出し、書き換え部分だけ更新して、当該ブロックを一度消去した後、ブロック全体にデータを格納しなければならない。フラッシュパッケージ２３０がライト要求を受け取るたびに、以上の動作を実行すると、処理時間が過大になりすぎ、実用的とは言いがたい。これを解決するため、本実施例では、もう１つ実ブロックが割り当てられ、これにより、空き領域が確保される。このため、空き領域に追加書き込みを行うことができる。空き領域が小さくなって、書き換えデータが入らなくなった場合、消去処理が行われる。これに、当該仮想グループに割り当てた論理ブロック数や世代数（ｋ）などを考慮して、実ブロックの最大割り当て数が、min（k,L（＜１）＊（当該仮想ブロックグループに割り当てた論理ブロック数））＊（ｍ＋１）個とされる。これにより、消去処理（例えば、実ブロック内の全てのデータを消去する処理）が、ｎ回のライト要求について１回実行されればよいので、性能を向上させることができる。また、消去処理の回数の削減は、フラッシュメモリの長寿命化にもつながる。本実施例では、フラッシュパッケージ２３０は、実ブロック数より多くの仮想ブロックをもっているように、ストレージコントローラ２００に見せていることになる。ただし、ストレージコントローラ２００は、実際にフラッシュパッケージ２３０がいくつの空き実ブロックをもっているかを意識して、実ページの再配置を行うことができる。本実施例では、フラッシュパッケージ２３０が、まだ実ブロックを割り当てていない仮想ブロックに、書き込み要求を受け付けたとき、実ブロックを割り当てる。

ページデータ格納量２１０４、ページ圧縮後データ格納量２１０５は、それぞれ、当該ページを割り当てた、フラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０の数だけ存在する。ただし、これらの情報は、この実ページに含まれる仮想ブロックの属性情報ではなく、この実ページに対応する仮想ページのデータに関する属性情報である。したがって、この仮想ページが別の実ページに割り当てられ、現在の実ページのデータが新しい実ページにコピーされた場合、ページデータ格納量２１０４、ページ圧縮後データ格納量２１０５を、新しい実ページの管理情報として引き継ぐ必要がある。ページデータ格納量２１０４は、当該実ページに格納したデータ量である。なお本実施例では、実ページに複数の論理ボリュームのデータを書き込むため、ページデータ格納量２１０４は、最大、実ページ容量＊論理ボリューム数２８０２になる。ページ圧縮後データ格納量２１０５は、当該ページに格納した圧縮後のデータ量である。以上の二つの値は、フラッシュパッケージ２３０から受け取った情報に基づき、計算される。

論理ボリューム数２１１２は、当該実ページに割り当てた論理ボリュームの数が格納される。論理ボリュームを割りあてる数は、実ページ毎に異なっていてもよい。

論理ボリューム情報ポインタ２１１３は、当該実ページに割り当てた論理ボリュームの論理ボリューム情報２０００へのポインタである。当該実施例では、１つの実ページに割り当てる論理ボリュームの数は最大ｋ個なので、論理ボリューム情報ポインタ２１１３の領域の数はｋである。先頭から、論理ボリューム数２１１２に設定されている数の分の論理ボリューム情報ポインタ２１１３が有効な値が設定されていて、残りはヌル値が設定されているものとする。本実施例では、フラッシュパッケージ２３０が認識している仮想ブロックグループは、１つの実ページに含まれているものとする。このため、フラッシュパッケージ２３０は、仮想ブロックグループに割り当てる実ブロックの数が限界をこえると、この旨を、ストレージコントローラ２００に通知する。この通知をうけとると、ストレージコントローラ２００は、これまで１つの実ページに割り当てていた論理ボリュームを、複数（例えば２つ）に分割して、それまで使用していた実ページと新たに確保した実ページに、データを分割して格納する。もちろん、３つ以上の実ページにデータが格納されても、本発明は有効である。

移動中フラグ２１０９、移動先実ページ情報２１１０、移動待ちフラグ２１１１は、当該実ページのデータを別の実ページに移動するときに使用される情報である。移動中フラグ２１０９は、この実ページのデータを別の実ページに移動中のときにONにされるフラグである。移動先実ページ情報２１１０は、この実ページのデータを移動している移動先の実ページのアドレスを表す情報である。移動待ちフラグ２１１１は、当該実ページ内のデータを移動すると決定したときにONにされるフラグである。

図８は、フラッシュパッケージ情報２５００の形式である。

フラッシュパッケージ情報２５００は、フラッシュパッケージ２３０ごとに存在する。フラッシュパッケージ情報２５００は、フラッシュパッケージID２５０１、フラッシュパッケージ仮想容量２５０２、及び、仮想ブロック容量２５０３を含む。

フラッシュパッケージID２５０１は、当該フラッシュパッケージ２３０の識別子である。

フラッシュパッケージ仮想容量２５０２は、当該フラッシュパッケージ２３０の仮想容量を表す。

仮想ブロック容量２５０３は、仮想ブロックの容量である。フラッシュパッケージ仮想容量２５０２が表す値を仮想ブロック容量２５０３を表す値で割った値が、このフラッシュパッケージ２３０に基づく仮想ブロックの数となる。本実施例では、このフラッシュパッケージ仮想容量２５０２を表す値が、フラッシュパッケージ２３０の圧縮率などにより調整される。すでに述べたが、本実施例では、フラッシュパッケージ２３０がそのパッケージ２３０の仮想容量を決定するが、その仮想容量は、ストレージコントローラ２００が決定してもよい。フラッシュパッケージ２３０から、仮想容量が変化した旨の通知を受けると、ストレージコントローラ２００は、この値を、フラッシュパッケージ仮想容量２５０２に設定する。

図９は、フラッシュパッケージグループ情報２３００の形式を示す。

フラッシュパッケージグループ情報２３００は、フラッシュパッケージグループ２８０ごとに存在する。フラッシュパッケージグループ情報２３００は、フラッシュパッケージグループID２３０１、パッケージグループRAIDタイプ２３０２、実ページ数２３０３、空き実ページ数２３０４、フラッシュパッケージポインタ２３０５、及び、使用不可実ページ数２３０６を含む。

フラッシュパッケージグループID２３０１は、当該フラッシュパッケージグループ２８０の識別子である。

パッケージグループRAIDタイプ２３０２は、当該フラッシュパッケージグループ２８０のRAIDタイプである。本実施例におけるRAIDタイプは、論理ボリュームRAIDタイプ２００３を説明したときに述べたとおりである。

実ページ数２３０３は、フラッシュパッケージグループ２８０に基づく実ページの数を表す。空き実ページ数２３０４は、フラッシュパッケージグループ２８０に基づく複数の実ページのうちの空きの実ページ（空きの実ページ）の数を表す。使用不可実ページ数２３０６は、フラッシュパッケージグループ２８０に基づく複数の実ページのうちの使用不可能な実ページの数を表す。すでに述べたように、本実施例における１つの特徴は、圧縮率によって、フラッシュパッケージ２３０の仮想容量が変化する点である。フラッシュパッケージ２３０の仮想容量が変化したとき、実ページ数２３０３及び空き実ページ数２３０４も変化する。以下、これを説明する。まず、当該フラッシュパッケージ２３０の仮想容量が変化すると、当該フラッシュパッケージグループ２８０の実ページの数も変化することになる。これを、具体的に示す。まず、ＲＡＩＤの考え方から、同一フラッシュパッケージグループ２８０内のフラッシュパッケージ２３０では使用可能な容量は等しいことが前提となる。故に、式は、
実ページ数２３０３＝（フラッシュパッケージグループ２８０内のフラッシュパッケージ２３０の最小のフラッシュパッケージ仮想容量２５０２）＊（フラッシュパッケージグループ２８０内のフラッシュパッケージ２３０の数）／（実ページサイズ）、
になる。従って、当該フラッシュパッケージグループ２８０内のフラッシュパッケージ２３０の最小のフラッシュパッケージ仮想容量２５０２が変化した場合、実ページ数２３０３も変化する。同様に、空き実ページ数２３０４も変化する。逆に、これは、使用不可になった実ページの数も変化したことになるので、使用不可実ページ数２３０６も変化することになる。例えば、実ページ数２３０３が、１０増加した場合、空き実ページ数２３０４も１０増加し、使用不可実ページ数２３０５は１０減少する。なお、すでに、述べたが、本実施例では、フラッシュパッケージ２３０がこの容量を決定するが、ストレージコントローラ２００が決定してもよい。

フラッシュパッケージポインタ２３０５は、当該フラッシュパッケージグループ２８０に属するフラッシュパッケージ２３０のフラッシュパッケージ情報２５００へのポインタである。パッケージポインタ２３０５の数は、当該フラッシュパッケージグループ２８０に属するフラッシュパッケージ２３０の数であるが、これは、パッケージグループRAIDタイプ２３０２によって決まる値である。

図４に示した空きページ管理情報ポインタ２２００は、フラッシュパッケージグループ２８０ごとに設けられる情報である。

図１０は、空きページ管理情報ポインタ２２００によって管理される空き実ページの集合を表している。

この構造を、空き実ページ情報２１００キュー２２０１と呼ぶ。空き実ページとは、仮想ページに割り当てられていない実ページ（仮想ページに空きの実ページ）を意味する。また、空き実ページに対応した実ページ情報を空き実ページ情報２１００と呼ぶ。空きページ管理情報ポインタ２２００は、先頭の空き実ページ情報２１００のアドレスをさす。次に、先頭の実ページ情報２１００の中の空きページポインタ２１０３が次の空き実ページ情報２１００を指す。図９では、最後の空き実ページ情報２１００の空き実ページポインタ２１０３は、空きページ管理情報ポインタ２２００を示しているが、ヌル値でもよい。ストレージコントローラ２００は、実ページを割り当てていない仮想ページに書き込み要求を受け付けると、論理ボリュームRAIDタイプ２００３と同一のフラッシュパッケージグループ２８０の中のいずれか、例えば、空き実ページ数の最も多いフラッシュパッケージグループ２８０を空きページ管理情報ポインタ２２００から、空き実ページを探し、見つかった空き実ページを仮想ページに割り当てる。

図４に示した使用不可ページ管理情報ポインタ２７００は、フラッシュパッケージグループ２８０ごとに設けられる情報である。

図１１は、使用不可ページ管理情報ポインタ２７００によって管理される使用不可実ページの集合を表している。

この構造を、使用不可ページ管理情報キュー２７０１と呼ぶ。その構造は、空きページ管理情報キュー２２０１と同じである。フラッシュパッケージ２３０の仮想容量が少なくなり、実ページ数２３０３の数が少なくなった場合、その数だけ、空きページ管理情報キュー２２０１で管理されている実ページ情報２１００が、使用不可ページ管理情報キュー２７０１に移される。逆に、フラッシュパッケージ２３０の仮想容量が多くなり、実ページ数２３０３の数が多くなった場合、その数だけ、使用不可ページ管理情報キュー２７０１で管理されている実ページ情報２１００が、空きページ管理情報キュー２２０１に移される。本実施例では、ストレージコントローラ２００が、上位レベルの容量仮想化機能、フラッシュパッケージ２３０が下位レベルの容量仮想化機能をもつ。このため、ストレージコントローラ１１０は、フラッシュパッケージ２３０の仮想容量が変化しても、実ページ情報２１００をすでに説明したような方法で移動させるだけで良い。実ページ情報２１００が使用不可ページ管理情報キュー２７０１に関連付けられた場合、その情報２１００に対応する実ページは、仮想ページに割り当てられなくなり、その実ページに含まれている仮想ブロックにはアクセスが発生しない。このため、実ブロックを他の仮想ブロックに割り当てることができる。つまり、実ブロックを有効に使用することができる。

空き論理ボリューム情報ポインタ２９００は、ストレージコントローラ２００に設けられる情報で、空き状態にある論理ボリューム情報２０００を管理する。図３７に示すように、空き状態にある論理ボリューム情報２０００は、空き論理ボリューム情報キュー２９０１を構成する。この構成は、図１０及び図１１に示した構成と同様なので、説明を省略する。ストレージコントローラ２００が、論理ボリュームの生成の要求を受けたとき、空き論理ボリューム情報ポインタ２９００が示す論理ボリューム情報２０００を特定し、その情報２０００を使用する。また、ストレージコントローラ２００は、ある論理ボリュームを消去したとき、該当する論理ボリューム情報２０００の必要な情報を消去して、空き論理ボリューム情報キュー２９０１に戻す。

次に、フラッシュパッケージ２３０が有する管理情報について説明する。フラッシュパッケージ２３０は、パッケージメモリ３２０内に管理情報をもつ。

図１２は、パッケージメモリ３２０に格納される管理情報を示している。

パッケージメモリ３２０に、パッケージ情報３０００、チップ情報３１００、仮想ブロック情報３２００、実ブロック情報３３００、及び、空き実ブロック情報ポインタ３４００が格納される。これらの情報のうちの少なくとも１種類の情報が、下位レベルの容量仮想化技術及び／又は圧縮技術を実現するために使用される。本実施例では、フラッシュパッケージ２３０が、下位レベルの容量仮想化技術及び圧縮技術を実現する。ただし、本発明は、下位レベルの容量仮想化技術及び圧縮技術をストレージコントローラ２００が実現してもよい。この場合、図１３に示すように、図１２に示した情報とほぼ同様の情報が、共有メモリ２２０に格納されることになる。図１３に示した構成では、図１３に示した情報が、ストレージコントローラ２００が参照及び更新するので、図１２に示したそれぞれの情報とは、若干相違が生ずる。したがって、本実施例では、フラッシュパッケージ２３０が、下位レベルの容量仮想化技術、圧縮技術を実現するものとする。

図１４は、パッケージ情報３０００の形式である。

パッケージ情報３０００は、パッケージID３００１、仮想パッケージ容量３００２、実パッケージ容量３００３、フラッシュブロック容量３００４、パッケージブロック容量３００５、パッケージデータ格納量３００６、パッケージ圧縮データ格納量３００７、セグメント容量３００８、内部情報格納ブロック数３００９、及び、内部情報格納アドレス３０１０を含む。

パッケージID３００１は、当該フラッシュパッケージ２３０の識別子である。

仮想パッケージ容量３００２は、ストレージコントローラ２００から見た当該フラッシュパッケージ２３０の仮想容量を表す。本実施例の１つの特徴は、圧縮率の変化によって、この仮想容量を、フラッシュパッケージ２３０が調整する点である。すでに述べたように、この調整は、ストレージコントローラ２００が実施してもよい。

実パッケージ容量３００３は、当該フラッシュパッケージグループ２８０の物理容量、具体的には、当該フラッシュパッケージグループ２８０内にストレージコントローラ２００が実際にデータを物理的に格納できる容量を表す。

フラッシュブロック容量３００４は、フラッシュメモリの消去単位であるブロックの物理的な容量を表す。

パッケージブロック容量３００５は、フラッシュパッケージ２３０における実ブロックの容量を表す。

パッケージデータ格納量３００６は、ストレージコントローラ２００から受けたライトデータの圧縮前の合計値を表す。

パッケージ圧縮データ格納量３００７は、ストレージコントローラ２００から受けたライトデータの圧縮後の合計値を表す。当該実施例では、フラッシュメモリの読み書き単位を「セグメント」と呼ぶ。

セグメント容量３００８は、セグメントの容量を表す。

内部情報格納ブロック数３００９は、内部情報（パッケージメモリ３２０に格納されたパッケージ情報３０００、チップ情報３１００、仮想ブロック情報３２００、実ブロック情報３３００及び空き実ブロックポインタ３４００を含んだ情報）の退避先のブロックの数である。内部情報は、例えば、電源OFF時又は障害発生時に退避される。

内部情報格納アドレス３０１０は、内部情報が格納されている記憶領域のアドレス（パッケージメモリ３２０における格納領域のアドレス）を表す。重要な情報（例えば、パッケージ情報３０００、チップ情報３１００、仮想ブロック情報３２００、実ブロック情報３３００、空き実ブロックポインタ３４００）は、ｎ重に格納されてもよい。また、退避される回数はそう多くないので、ブロックの消去回数なども問題にならないと考えられる。

当該フラッシュパッケージ２３０がもつ実ブロックの総数を表す情報が、パッケージ情報３０００に含まれて良い。例えば、内部情報格納ブロック数３００９の他に、フラッシュパッケージ２３０から割り当て可能なブロックの数、フラッシュパッケージ２３０に基づく障害ブロックの数等を表す情報が、パッケージ情報３０００に含まれていても良い。パッケージデータ格納量３００６、障害ブロック数、内部情報格納ブロック数３００９の合計が、このフラッシュパッケージがもつ実ブロックの総数で良い。

図１５は、チップ情報３１００の形式である。

チップ情報３１００は、フラッシュチップ３００ごとに存在する情報である。チップ情報３１００は、チップID３１０１、チップ実ブロック数３１０２、チップ内空き実ブロック数３１０３、及び、接続バスID３１０４を含む。

チップID３１０１は、当該フラッシュチップ３００の識別子である。

実チップブロック数３１０２は、当該フラッシュチップ３００がもつ実ブロックの数を表す。

チップ内空き実ブロック数３１０３は、当該フラッシュチップ３００の中の空き実ブロックの数を示している。空き実ブロックとは、仮想ブロックに割り当てられていない実ブロック（仮想ブロックに割り当て可能な実ブロック）である。

接続バスID３１０４は、当該フラッシュチップ３００が接続されているパッケージバス３４０の識別子である。

図１６は、仮想ブロック情報３２００の形式である。

仮想ブロック情報３２００は、仮想ブロックグループ対応に存在する情報である。仮想ブロック情報３２００は、仮想ブロックのアドレス順に並んでいるものとする。最初の仮想ブロック情報３２００が、先頭の仮想ブロックからｍ個の仮想ブロックに対応する。仮想ブロック情報３２００は、仮想ブロックグループ識別子３２０１、実ブロック情報ポインタ３２０２、データ格納量３２０３、圧縮データ格納量３２０４、世代数３２０９、世代ＩＤ３２０８、世代仮想セグメントアドレスポインタ３２０５、及び世代圧縮仮想セグメントデータ量３２０６を含む。フラッシュメモリの読み書き単位は、通常、「ページ」と呼ばれるが、本実施例は、ストレージコントローラ２００が行う容量仮想化の単位とするため、本実施例では、フラッシュメモリの読み書き単位を「セグメント」と呼ぶ。本実施例では、フラッシュメモリに書き込むデータが圧縮されて格納される。圧縮されたデータが格納されるセグメントを「実セグメント」と呼ぶ。圧縮前の仮想的なセグメントを「仮想セグメント」と呼ぶ。本実施例では、１つ以上の仮想セグメントを圧縮して、実セグメントに格納する。

仮想ブロックグループ識別子３２０１は、対応する仮想ブロックグループの識別子である。

実ブロック情報ポインタ３２０２は、対応する仮想ブロックを割り当てた実ブロックの実ブロック情報３３００へのポインタである。実ブロック情報ポインタ３２０２は、例えば（ｍ＋１）個存在する。実ブロック情報ポインタ３２０２は、実ブロックを割り当ていないときには、ヌル値となる。当該仮想ブロックグループに割り当てている実ブロックの数をｊ個（min（k,L（＜１）＊当該仮想ブロックグループに割り当てた論理ブロック数）＊（ｍ＋１）個以下）とすると、先頭からｊ個の実ブロック情報ポインタ３２０２が有効である。

世代ＩＤ３２０８は、当該仮想ブロックグループに格納されている論理ブロックグループの識別子、すなわち、ストレージコントローラ２００から受け取ったグループ内ＧＩID２００６とグループ内ＢＫＩＤ２００７に相当する情報である。

世代数３２０７は、当該仮想セグメントグループに格納されている論理ボリュームの世代の数である。本実施例では、１つの仮想セグメントグループで対応可能な世代数をｋ個とするので、世代ＩＤ３２０８の領域の数は、ｋ個あり、先頭の世代ＩＤ３２０８から順に有効な値が設定され、後のほうには、ヌル値が設定されていることになる。本実施例では、１つの仮想ページに、１つの論理ボリュームグループを構成する複数の論理ボリュームのデータが書き込まれるので、仮想ブロックグループにも、複数の論理ボリュームのデータが格納される。

仮想ブロックグループデータ格納量３２０３は、当該仮想ブロックグループに格納されている圧縮前のデータ量をあらわす。最大容量は、仮想ブロックグループの容量となる。一方、圧縮データ格納量３２０４は、圧縮後のデータの格納量である。なお、フラッシュメモリの場合、仮想セグメントの内容が書き換えられると、別の実ブロックに格納するため、同一の仮想セグメントのデータが複数個所に存在する。データ格納量３２０３、圧縮データ格納量３２０４は、最新の仮想セグメントの格納量を計算した値である。

世代ＩＤ３２０８は、論理ボリュームを区別するための識別子である。なお、本実施例では、図１６に示すように、世代ＩＤ３２０８は、仮想ブロック情報３２００にｐ個存在するとする（ｐは１以上の整数）。また、本実施例では、ストレージコントローラ２００が、フラッシュパッケージ２３０に、アクセス要求（リード要求、ライト要求）を発行する際には、複数の論理ボリュームを区別するため、識別子をつける。この識別子は、ＧＩＩＤ２００６又はＢＫＩＤ２００７（図５参照）に示される値である。フラッシュパッケージ２３０は、ストレージコントローラ２００から、この識別子を受け取ると、世代ＩＤ３２０８をサーチして、まだ登録していないなら、この値を、まだ値を格納していない世代ＩＤ３２０８に登録する。なお、有効な識別子を格納していない世代ＩＤ３２０８には、ヌル値が入っているものとする。

世代仮想セグメントアドレスポインタ３２０５は、論理ボリューム毎に、対応する仮想セグメントが、当該仮想ブロックグループに割り当てた実ブロックに対応する実ブロック情報３３００の内何番目の情報かを示す識別子と、その実ブロック内のどのアドレスに格納されているかとを示すポインタである。

世代圧縮仮想セグメントデータ量３２０６は、対応する仮想セグメントの圧縮後のデータ量である。したがって、世代仮想セグメントアドレスポインタ３２０５の領域の数、世代圧縮仮想セグメントデータ量３２０６の領域の数は、仮想ブロックグループ内の仮想セグメントの数（フラッシュブロック容量３００３＊ｍ／セグメント容量）に世代ＩＤ３２０８の数（ｋ）をかけた値に等しい。したがって、最初の仮想ブロックグループ内の仮想セグメントの数の世代仮想セグメントアドレスポインタ３２０５が、先頭の世代ＩＤ３２０８に相当する論理ボリュームのデータを示すことになる。以下、次の仮想ブロックグループ内の仮想セグメントの数の世代仮想セグメントアドレスポインタ３２０５が、次の世代ＩＤ３２０８に相当する論理ボリュームのデータを示すことになる。世代圧縮仮想セグメントデータ量３２０６も同様である。なお、本実施例では、世代仮想セグメントアドレスポインタ３２０５、世代圧縮仮想セグメントデータ量３２０６を仮想セグメントごとにもつことにしたが、２つ以上の仮想セグメントごとに同様の情報をもっても、本発明は有効である。

図１７は、実ブロック情報３３００の形式である。

実ブロック情報３３００は、実ブロックごとに存在する情報である。実ブロック情報３３００は、実ブロック識別子３３０１、空き実ブロックポインタ３３０２、及び、実ブロック内空き容量３３０４を含む。

実ブロック識別子３３０１は、対応する実ブロックの識別子であり、例えば、この実ブロックが、どのフラッシュチップ３００のどのアドレスに相当するブロックかを示す。

空き実ブロックポインタ３３０２は、対応する実ブロックが仮想ブロックに割り当てられていない（空き状態にある）時、次の空き状態にある実ブロックの実ブロック情報３３００を指している。

実ブロック内空き容量３３０４は、対応する実ブロックの現在の空き容量を示す。パッケージプロセッサ３１０は、対応する実ブロックに対し、空き容量以下のライトデータを格納できる。パッケージプロセッサ３１０は、ライトデータを格納した後、格納したライトデータの量だけ、実ブロック内空き容量３３０４を削減する。

空き実ブロック情報ポインタ３４００は、フラッシュチップ３００対応に存在する。図１８は、空き実ブロック情報ポインタ３４００によって管理される空き実ブロックの集合を表している。空きブロック情報ポインタ３４００は、先頭の空き実ブロックの実ブロック情報３３００のアドレスをさす。次に、先頭の空き実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２が、次の空き実ブロックの実ブロック情報３３００を示す。図１８では、最後の空き実ブロックの実ブロック情報３３００の空き実ブロックポインタ２１０３は、空きブロック情報ポインタ３４００を示しているが、ヌル値でもよい。パッケージプロセッサ３１０は、実ブロックを割り当てていない仮想ページに属するアドレスを指定したライト要求をストレージコントローラ２００から受けると、フラッシュチップ３００の中のいずれかから（例えば、空き実ブロックの数の最も多いフラッシュチップ３００に対応する空きブロック情報ポインタ３４００を基に）、空き実ブロックを探し、見つけた空き実ブロックを仮想ブロックに割り当てる。パッケージプロセッサ３１０は、割り当てた空き実ブロックに、上記受けたライト要求に従うデータを書き込む。

次に、上記に説明した管理情報を用いて、ストレージコントローラ２００及びフラッシュパッケージ２３０が実行する動作の説明を行う。

まず、ストレージコントローラ２００の動作を説明する。ストレージコントローラ２００の動作は、ストレージコントローラ２００内のプロセッサ２６０が実行し、そのプログラムは、メモリ２７０内に格納されている。

図１９は、メモリ２７０に格納されているプログラムが示している。

本実施例に関するプログラムは、論理ボリューム生成処理部４６００、リード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００、実ページ移動処理実行部４５００、実ページ分割処理部４３００である。これらのプログラムは、プロセッサ２６０で実行されるプログラムである。これらのプログラムのうちの少なくとも１つが、上位レベルのウエアレベリング技術、容量仮想化技術を実現するプログラムである。なお、すでに述べたが、本実施例は、下位レベルのウエアレベリング技術、容量仮想化技術を実現するのは、フラッシュパッケージ２３０であるが、本実施例は、下位レベルのウエアレベリング技術、容量仮想化技術をストレージコントローラ２００が実行してもよい。その場合、下位レベルのウエアレベリング技術、容量仮想化技術は、ストレージコントローラ２００で実行される。したがって、上位レベルのプログラムと下位レベルのプログラムの双方が、ストレージコントローラ２００で実行されるので、プログラム間のインターフェイスが異なってくるが、上位レベルのプログラムが実行する内容は基本的に大きな相違はない。したがって、本実施例では、下位レベルのウエアレベリング技術、容量仮想化技術を実現するのは、フラッシュパッケージ２３０であることを前提に、論理ボリューム生成処理部４６００、リード処理実行部４０００、ライト要求受付部４１００、ライトアフタ処理実行部４２００、実ページ移動処理実行部４５００、実ページ分割処理部４３００の処理フローを詳細に説明する。なお、本実施例では、ホスト１１０からのリード要求及びライト要求は、フラッシュメモリのリード・ライト単位であるセグメント（一般のフラッシュメモリの用語ではページ）境界で発行されるものとする。もちろん、本発明は、ホスト１１０からのリード要求及びライト要求の少なくとも一方が、セグメントの一部のみを指定した場合にも有効である。

図３０は、論理ボリューム生成処理部４６００の処理フローである。

図３０に示す処理の開始の契機は、例えば、論理ボリューム生成処理部４６００が、ホスト１１０又は管理サーバ１３０から、ゴールデンイメージを格納した論理ボリュームをベースに新しい論理ボリュームを生成せよというＧＩ生成要求を受け取ったとき、又は、オンラインボリュームである或る論理ボリュームから新たな論理ボリュームにバックアップを生成せよというバックアップ要求を受け取ったときである。このとき、ストレージコントローラ２００は、ベースとなる論理ボリューム（プライマリボリューム）の識別子と新たな論理ボリューム（差分ボリューム）の識別子もホスト１１０又は管理サーバ１３０から受け取る。それらの識別子は、ＧＩ生成要求及びバックアップ要求に含まれていて良い。

ステップ１９０００：論理ボリューム生成処理部４６００は、空き状態にある論理ボリューム情報２０００を、空き論理ボリューム情報キュー２９０１をサーチして確保する。生成処理部４６００は、差分ボリュームの識別子を、論理ボリュームＩＤ２００１に設定する。

ステップ１９００１：生成処理部４６００は、プライマリボリュームの識別子を用いて、ベースとなる論理ボリュームの論理ボリューム情報２０００を見つける。

ステップ１９００２: 生成処理部４６００は、プライマリボリュームの論理ボリューム情報２０００の論理容量２００２、論理ボリュームRAIDグループタイプ２００３、論理ボリュームグループタイプ２００５、実ページポインタ２０１１、繰り返し情報２０１２を、新たな論理ボリュームの論理ボリューム２０００の対応する情報にコピーする。

ステップ１９００３: 生成処理部４６００は、受け取った要求がＧＩ生成要求か否かを判断する。生成処理部４６００は、受け取った要求が、バックアップ要求であれば、ステップ１９００８へジャンプし、ＧＩ生成要求であれば、ステップ１９００４を行う。

ステップ１９００４：生成処理部４６００は、プライマリボリュームの論理ボリュームグループタイプ２００５が、ＧＩボリュームかどうかをチェックする。ＹＥＳなら、ステップ１９００６へジャンプする。

ステップ１９００５：生成処理部４６００は、プライマリボリュームの論理ボリュームグループタイプ２００５が、オンラインボリューム、かつ、ＧＩポインタ２００８がヌルかどうかをチェックする。条件が成立しないなら、ステップ１９０１１へジャンプする。

ステップ１９００６：生成処理部４６００は、新たに確保した論理ボリューム情報のＧＩポインタ２００８に、プライマリボリュームの論理ボリューム情報２０００のアドレスを設定する。また、生成処理部４６００は、差分ボリュームの論理ボリュームグループタイプ２００５を、オンラインボリュームにする。また、生成処理部４６００は、プライマリボリュームの論理ボリューム情報２０００の論理ボリュームグループタイプ２００５をＧＩボリューム（ゴールデンイメージ）とする。

ステップ１９００７：生成処理部４６００は、プライマリボリュームのＧＩ順ポインタ２００９をたどる。この際、生成処理部４６００は、定義されているグループ内GＩ（Golden Image）ID２００６を記憶する。生成処理部４６００は、最後尾の論理ボリューム情報の２０００に、新たに確保した論理ボリューム情報２０００を追加する。この際、生成処理部４６００は、関連する論理ボリューム情報２０００のＧＩ順ポインタ２００９とＧＩ逆ポインタ２０１０を更新する。生成処理部４６００は、差分ボリュームのグループ内GＩID２００６に、そのＩＤ２００６として設定されている識別子より１大きい値を設定する。この後、生成処理部４６００は、ＧＩ生成要求の送信元（ホスト１１０又は管理サーバ１３０）に正常終了報告をして、処理を終了する。

ステップ１９００８：生成処理部４６００は、プライマリボリュームの論理ボリュームグループタイプ２００５が、オンラインボリュームかをチェックする。Ｎｏであれば、ステップ１９０１１へジャンプする。

ステップ１９００９：生成処理部４６００は、新たに確保した論理ボリューム情報２０００の論理ボリュームグループタイプ２００５を、オンラインボリュームにする。生成処理部４６００は、それまでの論理ボリューム情報２０００の論理ボリュームタイプをバックアップボリュームにする。

ステップ１９０１０：生成処理部４６００は、プライマリボリュームのＢＫ順ポインタ２０１３をたどる。この際、生成処理部４６００は、定義されているグループ内GＩ（Golden Image）ID２００６及びグループ内BK（BacKup）ID２００７を記憶する。生成処理部４６００は、プライマリボリュームの最後尾の論理ボリューム情報の２０００に、新たに確保した論理ボリューム情報２０００を追加する。この際、生成処理部４６００は、関連する論理ボリューム情報２０００のＢＫ順ポインタ２０１３とＢＫ逆ポインタ２０１４を更新する。生成処理部４６００は、プライマリボリュームのグループ内BK（BacKup）ID２００７に、ＩＤ２００７として設定されている識別子より１大きい値を設定する。この後、生成処理部４６００は、バックアップ要求の送信元（ホスト１１０又は管理サーバ１３０）に正常終了報告をして、処理を終了する。

ステップ１９０１１：生成処理部４６００は、無効な要求を受け取ったので、新たに確保した論理ボリューム情報２０００に設定した情報をクリアして、当該論理ボリューム情報２０００を、空き論理ボリューム情報キュー２９０１へ戻す。この後、生成処理部４６００は、ＧＩ生成要求又はバックアップ要求の送信元（ホスト１１０又は管理サーバ１３０）に異常終了報告をして、処理を終了する。

図２０は、リード処理実行部４０００の処理フローである。

リード処理実行部４０００は、ホスト１１０から、ストレージコントローラ２００が、リード要求を受け付けたときに実行される。本実施例では、仮想セグメント１つ相当のデータが読み出されるものとする。なお、本発明は、複数の仮想セグメントを読み出す場合、あるいは、仮想セグメントの一部を読み出す場合も有効である。

ステップ５０００：リード処理実行部４０００は、まず、指定された論理ボリュームから対応する論理ボリューム情報２０００を見つける。

ステップ５００１：リード処理実行部４０００受け取ったリード要求で指定されたリード対象とするアドレスから、対応する仮想ページとアクセスする仮想ページ内の相対アドレスを計算する。次に、リード処理実行部４０００リード対象となったデータが、キャッシュメモリ２１０にヒットしているかをチェックする。これは、公知の技術である。ヒットしている場合、ステップ５００９へジャンプする。

ステップ５００２：ミスしている場合、リード対象としているデータをキャッシュメモリ２１０にロードする必要がある。ます、当該ステップでは、リード処理実行部４０００は、リード対象となった仮想ページに割り当てた実ページに対応する実ページ情報２１００を、論理ブロック管理情報２０００の実ページポインタ２０１１から特定する。

ステップ５００３:リード処理実行部４０００は、特定した実ページ情報２１００のパッケージグループ２１０１、実ページアドレス２１０２から、当該実ページが属するフラッシュパッケージグループ２８０と当該実ページのフラッシュパッケージグループ２８０内の先頭アドレスを得る。

ステップ５００４:リード処理実行部４０００は、ステップ５００１で得た仮想ページ内の相対アドレスとパッケージグループ内ＲＡＩＤタイプ２３０２から、当該要求のアクセス対象となる実ページ内の相対アドレスを計算する。計算した実ページ内相対アドレスと、パッケージグループ内ＲＡＩＤタイプ２３０２と、フラッシュパッケージポインタ２３０５とを基に、リード処理実行部４０００は、どのフラッシュパッケージ２３０のどのアドレスをアクセスかを特定する。また、リード処理実行部４０００は、指定された論理ボリュームの論理ボリューム情報２０００のＧＩＩＤ２００６とＢＫＩＤ２００７を特定する。

ステップ５００５:ステップ５００４で特定したフラッシュパッケージ２３０に対し、リード処理実行部４０００は、特定したアドレスを指定したリード要求を発行する。この際、リード要求は、どの世代の情報かを識別するために特定されたＧＩＩＤ２００６とＢＫＩＤ２００７が示す値を含む。

ステップ５００６：リード処理実行部４０００は、フラッシュパッケージ２３０からデータが送られてくるのを待つ。

ステップ５００７：リード処理実行部４０００は、要求したデータが送られてきたかをチェックする。例えば、本実施例では、多数の世代のバックアップボリュームが生成され、かつ、ライト処理が発生しない領域は、実ページの分割の結果、古い世代のデータとして、リード対象のデータが、別の実ページに移動している可能性がある。この場合、フラッシュパッケージは、要求されたデータが存在しないことを通知してくる。この場合、ストレージコントローラ２２００は、さらに、古い世代のバックアップボリューム内のデータ、あるいは、ＧＩボリューム内のデータを格納した実ページへリード要求を発行する必要がある。データが送られてきた場合、ステップ５００９へジャンプする。

ステップ５００７：リード処理実行部４０００は、当該論理ボリューム情報２０００のＢＫ逆ポインタ２０１４を遡って、実ページが割り当てられている論理ボリューム情報２０００を探す。みつかった場合、リード処理実行部４０００は、当該論理ボリューム情報２０００のアドレスを保持して、ステップ５００１へジャンプする。

ステップ５００８：ＢＫ逆ポインタを最も古いバックアップボリュームまでたどっても、データが見つからない場合、リード処理実行部４０００は、最も古いボリュームタイプのＢＫ逆ポインタ２０１４を基に、ボリュームタイプがオンラインボリュームである論理ボリュームの論理ボリューム情報２０００を見つけ、見つかった情報２０００におけるＧＩポインタ２００８を基に、ゴールデンイメージを格納した論理ボリューム情報２０００を見つけ、ステップ５００１へジャンプする。ＧＩボリュームまでたどれば、該当するデータがみつかるはずである。ＧＩボリュームが定義されていない場合、もっとも古いバックアップボリュームまでたどれば、該当するデータが見つかるはずである。

ステップ５００９：リード処理実行部４０００は、フラッシュパッケージ２３０から送られてきたデータをキャシュメモリ２１０に格納する。

ステップ５０１０：リード処理実行部４０００は、当該リード要求で指定された、キャッシュメモリ２１０上のデータを、ホスト１１０へ送り、ホスト１１０に正常終了報告を行い、処理を完了する。

図２１は、ライト要求受付部４１００の処理フローである。

ライト要求受付部４１００は、ストレージコントローラ２００が、ホスト１１０からライト要求を受け付けたときに実行される。本実施例では、仮想セグメント１つ相当のデータが書き込まれるものとする。なお、本発明は、複数の仮想セグメントにデータが書き込まれる場合、あるいは、仮想セグメントの一部にデータが書き込まれる場合も有効である。

ステップ６０００：ライト要求受付部４１００は、ライト要求で指定された論理ボリュームに対応する論理ボリューム情報２０００を見つける。さらに、ライト要求受付部４１００は、受け取ったライト要求で指定されたライト対象とするアドレスから、対応する仮想ページとアクセスする仮想ページ内の相対アドレスを計算する。

ステップ６００１：ライト要求受付部４１００は、当該論理ボリューム情報２０００の論理ボリュームグループタイプ２００５がバックアップボリューム又はＧＩボリュームかをチェックする。本実施例では、バックアップボリューム又はＧＩボリュームに対するライト処理は無効とする。なお、本発明は、バックアップボリューム又はＧＩボリュームに対するにライト処理を実行しても有効である。ライト先の論理ボリュームがバックアップボリューム又はＧＩボリュームの場合、ステップ６０１０へジャンプする。

ステップ６００２：ライト要求受付部４１００は、ライト要求で指定されている論理ボリューム情報２０００の中で、ステップ６０００で得た仮想ページに実ページが割り当てられているかを、実ページポインタ２０１１を参照して、チェックする。割り当てている場合、ステップ６００９へジャンプする。

ステップ６００３： 残っているのは、論理ボリュームグループタイプ２００５が、オンラインボリュームということになる。ライト要求受付部４１００は、当該論理ボリューム情報２０００のＧＩ順ポインタ２００９、ＧＩ逆ポインタ２０１０、ＢＫ順ポインタ２０１３、ＢＫ逆ポインタ２０１４をヌルでなければ探索する。まず、ライト要求受付部４１００は、ＢＫ逆ポインタ２０１４を探索する。ライト要求受付部４１００は、他の論理ボリュームで、すでに、実ページを割り当てている論理ボリュームがあるかを見つける。みつからなかった場合、ステップ６００６へジャンプする。

ステップ６００４：みつかった場合、ライト要求受付部４１００は、当該実ページに割り当てられていた論理ボリューム情報２０００の数がｋ個になっているかをチェックする。なっていれば、ステップ６００７へジャンプする。

ステップ６００５：なっていない場合、ライト要求受付部４１００は、当該実ベージに新たな論理ボリュームを割り当てることにする。まず、ライト要求受付部４１００は、当該論理ボリューム情報２０００の実ページポインタ２０１１に、見出した実ページポインタ２０１１をコピーする。また、ライト要求受付部４１００は、見出した実ページ情報２１００の論理ボリューム数２１１２を１増やし、論理ボリューム情報ポインタ２１１３に当該論理ボリューム情報２０００のアドレスを設定する。この後、ステップ６００９へジャンプする。

ステップ６００６：次に、ライト要求受付部４１００は、ＧＩ順ポインタ２００９とＧＩ逆ポインタ２０１０をサーチする。ここでは、ライト要求受付部４１００は、ＧＩ逆ポインタを１つたどったあと、ＧＩ順ポインタを１つたどるとする。割り当てられている実ページ情報２１００がなかった場合、ステップ６００８へジャンプする。みつかった場合、ステップ６００４へジャンプする。

ステップ６００７：ライト要求受付部４１００は、実ページの分割を行うため、実ページ分割処理部４３００をコールする。この後、ステップ６００９へジャンプする。

ステップ６００８：当該ステップでは、ライト要求受付部４１００は、対応する仮想ページに実ページを割り当てる。ライト要求受付部４１００は、論理ボリューム情報２０００のＲＡＩＤグループタイプ２００３、フラッシュパッケージグループ情報２３００の、パッケージグループＲＡＩＤタイプ２３０２、空き実ページ数２３０４等を参照して、どのフラッシュパッケージグループ２８０の実ページを割り当てるかを決める
。その後、ライト要求受付部４１００は、対応するフラッシュパッケージグループ２８０の空きページ管理情報ポインタ２２００を参照して、先頭の実ページ情報２１００を、当該実ページポインタ２０１１が示すようにする。これで、仮想ページに実ページが割り当てられたことになる。なお、ライト要求受付部４１００は、空きページ管理情報ポインタ２２００を、次の実ページ情報２１００（仮想ページに割り当てた実ページの実ページ情報２１００の中の空きページポインタ２１０３が示す実ページ情報２１００）を示すようにし、さらに、仮想ページに割り当てた実ページの実ページ情報２１００の中の空きページポインタ２１０３をヌルにする。ライト要求受付部４１００は、論理ボリューム数２１１２に、１を設定する。また、ライト要求受付部４１００は、論理ボリューム情報ポインタ２１１３の先頭に、当該論理ボリューム情報２０００のアドレスを設定する。また、ライト要求受付部４１００は、当該実ページに対応するフラッシュパッケージグループ情報２３００の空きページ数２３０４の数を減らす。仮想ページを実ページに割り当てる処理を、本実施例ではライト要求を受け付けたときに実施したが、この割り当て処理は、フラッシュパッケージ２３０へデータを格納するまでに実行されればよい。

ステップ６００９：ライト要求受付部４１００は、ホスト１１０から当該ライト要求で指定されたライトデータを、キャッシュメモリ２１０に格納する。この際、ライト要求受付部４１００は、ライトデータに、グループ内ＧＩＩＤ２００６、グループ内ＢＫＩＤ２００７を付与する。ライト要求受付部４１００は、ホスト１１０に正常終了報告を行い、処理を完了する。

ステップ６０１０：ライト要求受付部４１００は、ホスト１１０に対し要求は無効ということを報告する。この後、処理を終了する。

フラッシュパッケージグループ２８０は、ＲＡＩＤ構成をとるので、キャッシュメモリ２１０上に格納したライトデータに対して、冗長データを生成する必要があることがある。ただし、これは、公知の方法であるので、詳細に説明はしない。また、実ページの中には、冗長データを格納する領域も含まれているので、ライトデータに対応する冗長データの実ページ内の格納アドレスも一意に定まる。冗長データも、一度、キャッシュメモリ２１０に格納される。なお、キャッシュメモリ２１０上の冗長データも、ライトデータと同様に、どのフラッシュパッケージ２３０のどのアドレスに書き込むべきかを示す情報をつけておく。ライトデータ及び冗長データは、ライトアフタ処理実行部５２００によって、フラッシュパッケージ１６０に書き込まれるが、ライトアフタ処理実行部５２００から見ると、いずれもフラッシュパッケージ２３０へ書き込むデータなので、両者を区別する必要はない。同様に、フラッシュパッケージ２３０も、両者を区別する必要はない。

図２２は、ライトアフタ処理実行部４２００の処理フローである。

ライトアフタ処理実行部４２００は、プロセッサ２６０が、適宜実行する処理である。ライトアフタ処理実行部４２００は、ホスト１１０から受け取ったライトデータ、冗長データをフラッシュパッケージ２３０に書き込む処理を実行する。ただし、ライトアフタ処理実行部４２００は、ライトデータ、冗長データの両者を、フラッシュパッケージ２３０に書き込むべきデータとして、両者を区別せずに処理する。また、フラッシュパッケージ２３０に発行するライト要求には、グループ内ＧＩＩＤ２００６、グループ内ＢＫＩＤ２００７が指定される。

ステップ７０００：ライトアフタ処理実行部４２００は、キャッシュメモリ３００をサーチして、フラッシュパッケージ２３０に書き込むべきデータを決める。ライトアフタ処理実行部４２００は、見出したデータに付与されている、フラッシュパッケージ２３０のＩＤと書き込むべきアドレスとに関する情報を取り出し、その情報を基に、しかるべきフラッシュパッケージ２３０に、書き込むべきアドレスを指定して、ライト要求を発行する。なお、このとき、ライトアフタ処理実行部４２００は、書き込みを行う実ブロックに対応する実ブロック情報３３００の移動中フラグ２１０９をチェックして、そのフラグ２１０９がｏｎの場合、この実ページは移動中であるため、このライト要求の実行を中止し、別の書き込みデータを探す。

ステップ７００１：ライトアフタ処理実行部４２００は、グループ内ＧＩＩＤ２００６、グループ内ＢＫＩＤ２００７が付与した上記ライト要求をフラッシュパッケージ２３０へ送る。

ステップ７００２：ライトアフタ処理実行部４２００は、フラッシュパッケージ２３０からライト要求の完了報告を待つ。

ステップ７００３：ライトアフタ処理実行部４２００は、フラッシュパッケージ２３０から当該ライト要求に関する完了報告をチェックする。完了報告は、例えば、データ格納量（ステップ７００１で送ったライトデータの量）及び圧縮後データ量（ステップ７００１で送ったライトデータの圧縮後の量）を表す情報を含む。この情報は、完了報告とは別のタイミングで、フラッシュパッケージ２３０からストレージコントローラ２００に送られても良い。ライトアフタ処理実行部４２００は、当該ライト要求に対する完了報告が含む情報が表すデータ格納量及び圧縮後データ量を特定し、ライト先の実ページに対応するページデータ格納量２１０４に、特定したデータ格納量を加算し、且つ、ライト先の実ページに対応するページ圧縮後データ格納量２１０５に、特定した圧縮後データ格納量を加算する。

ステップ７００４:ライトアフタ処理実行部４２００は、プラッシュパッケージ２３０の仮想容量に変化があったフラッシュパッケージ２３０がまったくないかをチェックする。ない場合、処理を終了する。

ステップ７００５：仮想容量に変化があったフラッシュパッケージ２３０がある場合、ライトアフタ処理実行部４２００は、変化後の仮想容量を、仮想容量に変化があったフラッシュパッケージ２３０に対応するフラッシュパッケージ仮想容量２５０２に設定する。次に、ライトアフタ処理実行部４２００は、仮想容量に変化があったフラッシュパッケージ２３０を含むフラッシュパッケージグループ２８０を構成する複数のフラッシュパッケージ２３０に対応した複数のフラッシュパッケージ仮想容量２５０２のうちの最小値が変化したかをチェックする。変化した場合、この変化値にあわせて、ライトアフタ処理実行部４２００は、そのフラッシュパッケージグループ２８０に対応する実ページ数２３０３及び空き実ページ数２３０４を更新する。また、ライトアフタ処理実行部４２００は、その数にあわせて、空きページ管理情報キューと使用不可ページ情報管理キューの間で、実ページ情報２１００を移動する。その後、ライトアフタ処理実行部４２００は、ページ移動処理（実ページ移動処理実行部４５００）をコールする。その後、ライトアフタ処理実行部４２００は、処理を完了する。

図２４は、実ページ移動処理実行部４５００の処理フローである。

実ページ移動処理実行部４５００は、ライトアフタ処理実行部４２００、ライトセイムコマンド処理実行部４３００からコールされる。その際、仮想容量に変化があったフラッシュパッケージ２３０を含むフラッシュパッケージグループ２８０が指定される。

ステップ１１０００：実ページ移動処理実行部４５００は、指定されたフラッシュパッケージグループ（図２４の説明において「対象グループ」と言う）２８０に対応する空き実ページ数２３０４が、所定の閾値以下になっていない否か（つまり、対象グループ２８０に基づく空き容量が多いか否か）を判断する。この判断の結果が否定的の場合、処理が終了する。

ステップ１１００１：実ページ移動処理実行部４５００は、対象グループを構成する複数のフラッシュパッケージ２３０に対応した実ページ情報２１００をサーチし、ページ圧縮後データ格納量２１０５が表す値が大きい実ページ情報２１００を見つける。ページ圧縮後データ格納量２１０５が表す値が大きい実ページとは、対象グループに基づく全実ページのうちページ圧縮後データ格納量２１０５が表す値が上位Ｘ％（Ｘは０より大きい値）である１以上の実ページであっても良いし、ページ圧縮後データ格納量２１０５が表す値が所定の閾値Ｚ（Ｚは０より大きい値）以上である実ページでも良い。実ページ移動処理実行部４５００は、見つけた実ページ情報２１００に対応する実ページを、移動の対象候補とし、その実ページに対応する移動待ちフラグ２１１１をオンにする。

ステップ１１００２：ここでは、実ページ移動処理実行部４５００は、移動先となるフラッシュパッケージグループ２８０を選択する。本実施例では、フラッシュパッケージグループ２８０は一つ選択されるが、もちろん、移動先として複数のフラッシュパッケージグループ２８０が選択されても良い。本実施例では、例えば、実ページ移動処理実行部４５００は、空き実ページ数２１０４が比較的少ないフラッシュパッケージグループ２８０（例えば空き実ページ数２１０４が最も少ない或いは所定の閾値未満であるフラッシュパッケージグループ２８０）を移動先として選択する。次に、実ページ移動処理実行部４５００は、選択した移動先のフラッシュパッケージグループ（図２４の説明において「移動先グループ）２８０の中のどの実ページを移動先とするかを決定する。移動先の実ページを決めると、実ページ移動処理実行部４５００は、移動先グループ２８０に対応する空きページ管理情報ポインタ２２００がさす実ページ情報２１００を、移動元の実ページの実ページ情報２１００のコピー先実ページ情報ポインタ２１１０に設定する。実ページ移動処理実行部４５００は、空きページ管理情報ポインタ２２００を、次の空きの実ページに対応するページ管理情報２１００に更新する。以上の処理が、ステップ１１００１で移動を決定したすべての実ページに対して実行される。以上で、各移動元実ページについて移動先ページが決まったことになる。

ステップ１１００３：ここでは、実ページ移動処理実行部４５００は、移動元となる実ページの実ページ情報２１００を決定する。具体的には、実ページ移動処理実行部４５００は、移動待ちフラグ２１１１がオンになっている実ページ情報２１００を見つける。ない場合、処理が終了し、呼び出し元に戻る。

ステップ１１００４：ここでは、実ページ移動処理実行部４５００は、見つけた実ページ情報２１００に対応する実ページがフラッシュパッケージ２３０のどの領域になるかを算出する。見つかった実ページ情報２１００のパッケージグループ２１０１が示すフラッシュパッケージグループ情報２３００が、該当するフラッシュパッケージグループ情報２３００である。このフラッシュパッケージグループ情報２３００に格納されたフラッシュパッケージポインタ２３０５が示すフラッシュパッケージ情報２５００に対応するフラッシュパッケージ２３０が、コピー元の実ページの基になっているフラッシュパッケージ２３０である。次に、実ページ情報２１００内の実ページアドレス２１０２と、フラッシュパッケージ情報２５００のブロック容量２５０３から、実ページ移動処理実行部４５００は、それぞれのフラッシュパッケージ２３０の中の移動対象となる領域を、すべてのフラッシュパッケージ２３０に関して特定する。

ステップ１１００５：実ページ移動処理実行部４５００は、移動元となる実ページの基になっているフラッシュパッケージグループ２８０を構成する各フラッシュパッケージ２３０に、指定した領域の中で、データを格納した領域のデータを、キャッシュメモリ２１０に移動するよう要求する。

ステップ１１００６：実ページ移動処理実行部４５００は、ステップ１１００５での要求の発行先のフラッシュパッケージ２３０からの完了報告をまつ。

ステップ１１００７：フラッシュパッケージ２３０からは、各領域（本実施例では、仮想セグメント）ごとに、仮想セグメントにデータが格納されていたか、いないかの情報と、データが格納されていた場合、その圧縮後のデータ量と格納されていたデータが、フラッシュパッケージ２３０から送られてくる。実ページ移動処理実行部４５００は、これらの情報を、キャッシュメモリ２１０に格納する。

ステップ１１００８：実ページ移動処理実行部４５００は、ここでは、移動先実ページが、その移動元実ページの基になっているフラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０の集合と、それぞれのフラッシュパッケージ２３０のどの仮想セグメントの集合とに該当するかを算出する。この場合、移動元の実ページに対応する実ページ情報２１００の移動先実ページアドレスが示す実ページ情報２１００が、移動先の実ページに対応する実ページ情報２１００となる。実ページ情報２１００から、フラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０の集合と、それぞれのフラッシュパッケージ２３０のどの領域になるかを算出する処理は、ステップ１１００４で説明したので省略する。

ステップ１１００９：実ページ移動処理実行部４５００は、移動先となる実ページが割り当てられているフラッシュパッケージグループ２８０を構成する各フラッシュパッケージ２３０に、指定した領域にデータを格納するよう要求する。このとき、各フラッシュパッケージ２３０に送られるのは、ステップ１１０７でキャッシュメモリ２１０に格納した情報（移動元のフラッシュパッケージ２３０から送られてきた情報）と、移動元の実ページの中で、データを格納している領域のデータとである。

ステップ１１０１０：実ページ移動処理実行部４５００は、ステップ１１００９での要求の発行先のフラッシュパッケージ２３０からの完了報告をまつ。

ステップ１１０１１：実ページ移動処理実行部４５００は、移動元実ページを空き実ページとして管理し、且つ、移動元実ページが割り当てられていた仮想ページにその実ページに代えて移動先実ページを割り当てる。具体的には、例えば、実ページ移動処理実行部４５００は、移動元の実ページに対応する実ページ情報２１００を空き実ページ管理ポインタ２２００につなぎ、移動元の実ページに対応する実ページ情報２１００を示していた実ページポインタ２００４を移動先の実ページ情報を示すようにする。また、実ページ移動処理実行部４５００は、移動元実ページに対応する実ページ情報２１００内のページデータ格納量２１０４及びページ圧縮後データ格納量２１０５を、移動先実ページに対応する実ページ情報２１００にコピーする。その後、実ページ移動処理実行部４５００は、移動元実ページ及び移動先実ページの双方に対応する実ページ情報２１００における移動中フラグ２１０９、移動先実ページポインタ２１１０及び移動待ちフラグ２１１１を、クリアする。

ステップ１１０１２：実ページ移動処理実行部４５００は、移動元のフラッシュパッケージグループ２８０に対応するフラッシュパッケージグループ情報（以下、移動元グループ情報）２３００と移動先のフラッシュパッケージグループ２８０に対応するフラッシュパッケージグループ情報（以下、移動先グループ情報）２３００とを更新する。具体的には、移動元グループ情報２３００内の空き実ページ数２３０４が表す値から１が削減され、移動先グループ情報２３００内の空き実ページ数２３０４が表す値に１が加算される。この後、次に移動対象とする実ページを探すために、ステップ１１００３にジャンプする。

図２３は、実ページ分割処理部４３００の処理フローである。

実ページ分割処理部４３００は、ライト処理実行部４１００から、書き込みを行おうとした実ページに、すでに、上限であるｋ個の論理ボリュームが割り当てられていたとき、実ページを分割するために、コールされる。

ステップ８０００：ここでは、実ページ分割処理部４３００は、新たな実ページを割り当てる。このステップは、図２２のステップ６００８で示した処理なので、詳細な説明を省略する。

ステップ８００１：実ページ分割処理部４３００は、該当する実ページ情報２１００（書き込みを行おうとした実ページの実ページ情報２１００）を参照して、当該実ページに割り当てられている論理ボリューム情報ポインタ２１１３がポイントする論理ボリューム情報２０００の論理ボリュームグループタイプ２００５を分析して、以下のいずれに相当するかを判断する。
（１）論理ボリュームの中に、ゴールデンイメージが入っていて、さらに、その論理ボリュームを含んだ論理ボリュームグループに複数のオンラインボリュームが含まれる。この場合、オンラインボリューム単位に、実ページの分割が行われるとする。本実施例では、実ページ分割処理部４３００は、オンラインボリュームのグループ内ＧＩＩＤ２００６を昇順に並べ、それぞれの実ページに割り当てる論理ボリュームの数を均等に近くなるグループ内ＧＩＩＤ２００６を境界として、それ以下のグループ内ＧＩＩＤ２００６をもつオンラインボリュームと、存在すれば、それぞれのオンラインボリュームのバックアップボリュームを、これまで割り当てていた実ページに割り当てる。また、実ページ分割処理部４３００は、境界となるグループ内ＧＩＩＤ２００６より大きいグループ内ＧＩＩＤ２００６をもつオンラインボリュームと、存在すれば、それぞれのオンラインボリュームのバックアップボリュームを、新しい実ページに割り当てる。ここでは、実ページ分割処理部４３００は、それまでの実ページに割り当てる論理ボリュームの数及びそれら論理ボリュームの集合と、新しい実ページに割り当てる論理ボリュームの数及びそれら論理ボリュームの集合とを分類しておく。
（２）本実施例では、上記以外は、実ページの分割が行われない。当該ライト要求の対象となる論理ボリュームが、新たな実ページに割り当てられる。

当該ステップ８００１では、実ページ分割処理部４３００は、（１）か（２）を分類して、（１）の場合、ステップ８００３へジャンプする。

ステップ８００２：実ページ分割処理部４３００は、新たに割り当てた実ページ情報２１００に対応する実ページに、ライトデータを書き込むことにして、コール元に戻る。

ステップ８００３：実ページ分割処理部４３００は、実ページの分割を行うため、ステップ６００３、ステップ６００６で見出した実ページから全てのデータを読み出す。この処理は、図２４に示したステップ１１００４以下の処理と同様である。ステップ８００３は、ステップ１１００４と同じ処理である。ここでは、当該実ページ情報２１００に対応する実ページが、実ページが割り当てられているフラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０のどの領域になるかが算出される。

ステップ８００４：ステップ１１００５と同じ処理である。実ページ分割処理部４３００は、移動元となる実ページが割り当てられているフラッシュパッケージグループ２８０を構成する各フラッシュパッケージ２３０に、指定した仮想セグメントの中で、データを格納した仮想セグメントのデータをキャッシュメモリ２１０に移動するよう要求する。

ステップ８００５：実ページ分割処理部４３００は、要求を発行したすべてのフラッシュパッケージ２３０からの完了報告をまつ。

ステップ８００６：実ページ分割処理部４３００は、フラッシュパッケージ２３０から、各仮想ブロックグループに相当する領域ごとに、下記の情報（ａ）乃至（ｅ）と、
（ａ）そのデータ格納量、
（ｂ）圧縮後のデータ格納量、
（ｃ）割り当てている世代数と世代ＩＤ、
（ｄ）各部分領域（本実施例では仮想セグメント単位）にデータが格納されていたか、いないかの情報、
（ｅ）その情報が、格納されていることを表す情報の場合、当該データの世代ＩＤと、その圧縮後のデータ長を示す情報、
データを格納している領域のデータとを受ける。実ページ分割処理部４３００は、これらの情報及びデータを、キャッシュメモリ２１０に格納する。

ステップ８００７：実ページ分割処理部４３００は、キャッシュメモリ２１０に格納された情報のうち、ステップ１２００１の（１）で分類した新しい分割先実ページに割り当てる論理ボリュームの集合とそれまで使用していた分割元実ページに割り当てる論理ボリュームの集合により、新しい実ページに書き込む情報とそれまで使用していた情報とに分類する。さらに、実ページ分割処理部４３００は、分割先となる実ページ、分割元なる実ページのそれぞれのページデータ格納量２１０４、ページ圧縮後データ格納量２１０５に設定すべき値を算出して、記憶しておく。

ステップ８００８：ここでは、実ページ分割処理部４３００は、分割先となる実ページと分割元となる実ページが、割り当てられたフラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０の集合と、それぞれのフラッシュパッケージ２３０のどの領域になるかを算出する。フラッシュパッケージグループ２８０を構成するフラッシュパッケージ２３０の集合と、それぞれのフラッシュパッケージ２３０のどの領域になるかとを実ページ情報２１００を基に算出する処理は、ステップ１１００４で説明したので省略する。

ステップ８００９：実ページ分割処理部４３００は、分割元となる実ページと分割先となる実ページが割り当てられているフラッシュパッケージグループ２８０を構成する各フラッシュパッケージ２３０に、指定した領域のデータを格納するよう要求する。ステップ１２００６でキャッシュメモリ２１０に格納した分割元になるフラッシュパッケージ２３０から送られてきた情報を、ステップ１２００７で、分割元の実ページに送るべき情報と分割先の実ページに送るべき情報になるが、それらの情報が、対応するフラッシュパッケージ２３０に送られる。

ステップ８０１０：実ページ分割処理部４３００は、要求を発行したすべてのフラッシュパッケージ２３０からの完了報告をまつ。

ステップ８０１１：実ページ分割処理部４３００は、分割先実ページに、割り当てると決定した論理ボリュームの仮想ページを割り当てる。これは、対応する論理ボリューム情報の対応する仮想ページに相当する実ページポインタ２０１１を分割先の実ページ情報２１００を示すようにすればよい。また、実ページ分割処理部４３００は、移動元の実ページ情報２１００うち、ページデータ格納量２１０４、ページ圧縮後データ格納量２１０５については、ステップ１２００７で記憶した値を設定する。また、実ページ分割処理部４３００は、論理ボリューム数２１１２、論理ボリューム情報ポインタ２１１３については、ステップ１２００１で分類した値を設定する。実ページ分割処理部４３００は、移動先の実ページ情報２１００うち、ページデータ格納量２１０４、ページ圧縮後データ格納量２１０５については、ステップ１２００７で記憶した値を設定する。また、実ページ分割処理部４３００は、論理ボリューム数２１１２、論理ボリューム情報ポインタ２１１３については、ステップ１２００１で分類した値を設定する。

ステップ８０１２：実ページ分割処理部４３００は、分割先となったフラッシュパッケージグループ情報２３００の更新を行う。ここでは、分割先のフラッシュパッケージグループ情報２３００の空き実ページ数２３０４を、１増やす。この後、コール元に戻る。

次に、フラッシュパッケージ２３０が実行する動作の説明を行う。フラッシュパッケージ２３０の動作は、パッケージプロセッサ３１０が実行し、そのプロセッサ３１０によって実行されるプログラムは、パッケージメモリ３２０内に格納されている。

図２５は、パッケージメモリ３２０内に、格納された本実施例に関するプログラムが示されている。

本実施例に関するプログラムは、データリード処理実行部１２０００、データライト処理実行部１２１００、仮想ブロック移動処理実行部１２３００、仮想ブロック格納処理実行部１２４００、仮想容量判定処理部１２５００である。これらのプログラムのうちの少なくとも１つは、下位レベルのウエアレベリング技術、容量仮想化技術を実現するためのプログラムである。本実施例では、フラッシュパッケージ２３０が、下位レベルのウエアレベリング技術、容量仮想化技術を実現する。ただし、下位レベルのウエアレベリング技術、容量仮想化技術は、ストレージコントローラ２００で実現されてもよい。この場合、図２６に示すように、図２５に示した情報とほぼ同様のプログラムが、共有メモリ２２０上に格納されることになる。図２６に示した構成では、これらの情報は、ストレージコントローラ２００が実行するので、図２５に示したそれぞれの情報とは、若干相違が生ずるだけである。したがって、本実施例では、フラッシュパッケージ２３０が、下位レベルのウエアレベリング技術、容量仮想化技術を実現するものとし、図２５に示したデータリード処理実行部１２０００、データライト処理実行部１２１００、実ブロック解放処理実行部１２２００、仮想ブロック移動処理実行部１２３００、仮想ブロック格納処理実行部１２４００、仮想容量判定処理部１２５００の処理フローを詳細に説明する。

図２７は、データリード処理実行部１２０００の処理フローである。

データリード処理実行部１２０００は、ストレージコントローラ２００から、リード要求を受け取ったときに、実行される処理フローである。なお、本実施例で示す図２８の処理フローでは、１つの仮想セグメントに格納されたデータをリードする処理フローを示している。ただし、本発明は、リード要求で、複数の仮想セグメントのデータ、あるいは、仮想セグメントの一部のデータを読み出すようにした場合も有効である。なお、本実施例の１つの特徴として、リード要求に、世代を区別するため、ＧＩＩＤ２００６とＢＫＩＤ２００７が含まれている。

ステップ１３０００：データリード処理実行部１２０００は、受け取ったリード要求がリード対象とするアドレスとパッケージブロック容量３００５とから、対応する仮想ブロックグループと、アクセスする仮想ブロックグループ内の相対アドレスを計算する。これにより、データリード処理実行部１２０００は、リード対象とする仮想ブロック情報３２００を認識する。また、データリード処理実行部１２０００は、受け取ったＧＩＩＤ２００６とＢＫＩＤ２００７から世代ＩＤ３２０８を認識して、仮想ブロック内の相対アドレスから、対応する世代仮想セグメントアドレスポインタ３２０５から、該当する仮想セグメントが、実ブロック内のどのアドレスに格納されているかを認識する。格納されていれば、ステップ１３００３へジャンプする。

ステップ１３００１：格納されていない場合、データリード処理実行部１２０００は、世代ＩＤ３２０８をサーチして、古い世代の仮想セグメントを探す。まず、データリード処理実行部１２０００は、当該実ページに、受け取ったＧＩＩＤ２００６が同じで、ＢＫＩＤ２００７が古い世代の世代ＩＤ３２０８の仮想セグメントが格納されているかを、世代の新しい順にさがしていく。みつかった場合、この仮想セグメントを、ストレージコントローラ２００に送るため、ステップ１３００３へジャンプする。

ステップ１３００２:次に、データリード処理実行部１２０００は、当該実ページの世代ＩＤ３２０８に、グループ内ＧＩＩＤ２００６が０で、かつ、グループ内ＢＫＩＩＤ２００７が０の（ゴールデンイメージの可能性がある）論理ボリュームが存在するかをチェックする。存在しない場合、ステップ１３００９へジャンプする。その場合、対応する仮想セグメントを、ストレージコントローラ２００に送るため、次ステップへ移る。

ステップ１３００３：当該ステップでは、データリード処理実行部１２０００は、リード対象となったそれぞれの仮想セグメントに割り当てた実ページの実ブロック情報３３００を、それぞれの仮想ブロック情報３２００の実ブロック情報ポインタ３２０２から特定する。

ステップ１３００４：データリード処理実行部１２０００は、特定したそれぞれの実ブロック情報３３００の実ブロック識別子３３０１から対応する実ブロックが、どのフラッシュチップ３００のどの先頭アドレスから格納さているかを確認する。次に、データリード処理実行部１２０００は、該当する仮想セグメントアドレスポインタ３２０５から、当該リード要求で指定されそれぞれの仮想セグメントが、当該フラッシュチップ３００のどの当該アドレスに格納されているかを算出する。

ステップ１３００５:データリード処理実行部１２０００は、リードデータが格納されているフラッシュチップ３００に対応したチップ情報３１００をアクセスして、当該フラッシュチップ３００が接続されているパッケージバス３４０を識別し、対応するパッケージバス転送装置３５０を認識する。

ステップ１３００６: データリード処理実行部１２０００は、ステップ１３００３で認識したパッケージバス転送装置３５０に、どのフラッシュチップ３００のどのアドレスから、バッファ３３０に、データを転送するよう指示する。また、データリード処理実行部１２０００は、圧縮・伸長回路３６０に、データ転送と同期して、データを伸長するよう指示する。

ステップ１３００７：データリード処理実行部１２０００は、この後、転送が完了するのを待つ。

ステップ１３００８：データリード処理実行部１２０００は、バッファ３３０に格納した、ストレージコントローラ２００から要求されたリードデータ（ステップ１３００５で伸長された）を、ストレージコントローラ２００に送る。この後、処理を完了する。

ステップ１３００９：データリード処理実行部１２０００は、当該実ページには、データが格納されていなかった旨をストレージコントローラ２００に報告する。この後、処理を完了する。

図２８と図２９は、データライト処理実行部１２１００の処理フローである。

データライト処理実行部１２１００は、ストレージコントローラ２００から、フラッシュパッケージ２３０が、ライト要求を受け付けたときに実行される。なお、本実施例で示す図２８と図２９の処理フローでは、１つの仮想セグメントに格納するデータをライトする処理フローを示している。ただし、本発明は、ライト要求で、複数の仮想セグメントにデータを書き込む、あるいは、仮想セグメントの一部のデータを書き込むようにした場合も有効である。なお、本実施例の１つの特徴として、ライト要求には、世代を区別するため、ＧＩＩＤ２００６とＢＫＩＤ２００７が含まれている。

ステップ１４０００：データライト処理実行部１２１００は、受け取ったライト要求がライト対象とするアドレスとパッケージブロック容量３００５とから、対応する仮想ブロックグループとアクセスする仮想ブロックグループの相対アドレスを計算する。これにより、データライト処理実行部１２１００は、ライト対象とする仮想ブロック情報３２００を認識する。また、データライト処理実行部１２１００は、受け取ったＧＩＩＤ２００６とＢＫＩＤ２００７が世代ＩＤ３２０８に登録されているかをチェックする。登録されていれば、書き込み対象となる世代が認識されたことになる。登録されていない場合、データライト処理実行部１２１００は、世代数３２０７を１増やし、受け取ったＧＩＩＤ２００６とＢＫＩＤ２００７を、世代ＩＤ３２０８に登録する。

ステップ１４００１:また、データライト処理実行部１２１００は、仮想ブロックグループ内の相対アドレスと世代ＩＤ３２０８から、対応する世代仮想セグメントを認識し、対応する世代仮想セグメントアドレスポインタ３２０５を認識する。

ステップ１４００１：データライト処理実行部１２１００は、ホスト１１０から当該ライト要求で指定されたライトデータを、バッファ３３０に格納する。なお、この際、データライト処理実行部１２１００は、圧縮・伸長回路３６０に、圧縮を指示する。バッファ３３０には、圧縮されたデータが格納される。

ステップ１４００２：データライト処理実行部１２１００は、ライト対象となった仮想ブロックグループに対応する仮想ブロック情報３２００の最初の実ブロック情報ポインタ３２０２を特定する。データライト処理実行部１２１００は、この値がヌルかどうか、すなわち、実ブロックが割り当てられているかを、チェックする。割り当てていれば、ステップ１４００５へジャンプする。

ステップ１４００３：このステップは、対応する仮想ブロックグループに空き状態にある実ブロックを割り当てるステップである。なお、ここでは、割り当てる実ブロックは消去されていてデータは格納されていないものとする。データライト処理実行部１２１００は、各チップ情報３１００のチップ内空き実ブロック数３１０３等を参照して、どのフラッシュチップ３００の実ブロックを割り当てるかを決める。その後、データライト処理実行部１２１００は、対応するフラッシュチップ３００の空き実ブロック情報ポインタ３４００を参照して、先頭の実ブロック情報３３００を、当該仮想ブロックグループ管理情報の最初の空き実ブロックポインタ３３０２が示すようにする。これで、仮想ブロックグループに最初の実ブロックを割り当てたことになる。なお、データライト処理実行部１２１００は、空き実ブロック情報ポインタ３４００を、次の実ブロック情報３３００（仮想ブロックグループに割り当てた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２が示す実ブロック情報３３００）を示すようにし、さらに、仮想ブロックグループに割り当てた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２をヌルにする。また、データライト処理実行部１２１００は、当該実ブロックに対応するチップ情報３１００のチップ内空き実ブロック数３１０３の数を減らす。

ステップ１４００４：さらに、データライト処理実行部１２１００は、当該世代の仮想セグメントに対応する世代仮想セグメントポインタに、実ブロックである識別子と先頭アドレスをセットする。データライト処理実行部１２１００は、世代圧縮後仮想セグメントデータ量３２０６に、圧縮・伸長回路が示す値をセットする。また、データライト処理実行部１２１００は、その値と同じ値を、世代圧縮データ格納量３２０４にセットする。さらに、データライト処理実行部１２１００は、上記同じ値を、パッケージ圧縮後データ格納量３００７に加える。さらに、データライト処理実行部１２１００は、ライト対象となる世代の仮想セグメントの容量を、格納データ量３２０３にセットする。また、データライト処理実行部１２１００は、その容量を表す値と同じ値を、パッケージデータ格納量３００６に加える。また、データライト処理実行部１２１００は、受け取ったライトデータ量と圧縮後のデータ長を、ストレージコントローラ２００に返す値として記憶する。

ステップ１４００５: データライト処理実行部１２１００は、パッケージバス転送装置３５０に、どのフラッシュチップ３００のどのアドレスへ、バッファ３３０からデータを書き込むよう指示する。この後、ステップ１４０１４にジャンプする。

ステップ１４００６：データライト処理実行部１２１００は、当該仮想ブロック情報３２００の最後の実ブロック情報ポインタ３２０２が示す実ブロック情報３３００の実ブロック識別子３３０１を参照して、対応する実ブロックが、どのフラッシュチップ３００のどの先頭アドレスから格納されているかを特定する。

ステップ１４００７：データライト処理実行部１２１００は、ライト対象となる実ブロックに対応する実ブロック情報３３００の実ブロック内空き領域３３０４とバッファ３３０に格納したライトデータの長さとから、受け取ったデータを、当該実ブロックの空き領域に書き込めるかをチェックする。書き込めない場合、ステップ１４０１６へジャンプする。

ステップ１４００８：データライト処理実行部１２１００は、当該世代の仮想セグメントの世代仮想セグメントアドレスポインタ３２０５がヌルかを確認する。成立なら、ステップ１４０１０へジャンプする。

ステップ１４００９：成立しないなら、データライト処理実行部１２１００は、当該圧縮・伸長回路３６０が示す値から世代圧縮仮想セグメントデータ量３２０６を減算した値を、圧縮後データ格納量３２０４に加える。さらに、データライト処理実行部１２１００は、その値と同じ値を、パッケージ圧縮データ格納量３００７に加える。この後、データライト処理実行部１２１００は、圧縮・伸長回路３６０が示す値を世代圧縮仮想セグメントデータ量３２０６にセットする。また、データライト処理実行部１２１００は、今回書き込んだライトデータ量に関しては、０を、圧縮後のデータに関しては、世代圧縮仮想セグメントデータ量３２０６に加えた値を、ストレージコントローラ２００に返す値として記憶する。この後、ステップ１４０１１へジャンプする。

ステップ１４０１０：成立の場合、データライト処理実行部１２１００は、当該圧縮・伸長回路３６０が示す値を、圧縮後データ格納量３２０４に加える。さらに、データライト処理実行部１２１００は、その値と同じ値を、パッケージ圧縮データ格納量３００７に加える。この後、データライト処理実行部１２１００は、圧縮・伸長回路が示す値を世代圧縮仮想セグメントデータ量３２０６にセットする。さらに、データライト処理実行部１２１００は、データ格納量３２０３には、圧縮前の値を加算して、加算後の値と同じ値を、パッケージデータ格納量３００６に加える。また、データライト処理実行部１２１００は、今回書き込んだライトデータ量に関しては、ストレージコントローラ２００から受け取った圧縮前のデータ量を、圧縮後のデータに関しては、当該圧縮・伸長回路が示す値を、それぞれ、ストレージコントローラ２００に返す値として記憶する。

ステップ１４０１１：データライト処理実行部１２１００は、実ブロック内空き領域３３０４を、今回受け取ったライトデータの量（圧縮後の値）だけ削減する。データライト処理実行部１２１００は、当該世代の仮想セグメントに対応する世代仮想セグメントアドレスポインタ３２０５に、当該仮想ブロック情報３２００の最後の実ブロック情報ポインタ３２０２と今回転送した相対アドレスをセットする。

ステップ１４０１２: データライト処理実行部１２１００は、ライトデータを格納するフラッシュチップ３００に対応したチップ情報３１００をアクセスして、当該フラッシュチップ３００が接続されているパッケージバス３４０を識別し、対応するパッケージバス転送装置３５０を認識する。

ステップ１４０１３:データライト処理実行部１２１００は、ステップ１４００７で認識したパッケージバス転送装置３５０に、どのフラッシュチップ３００のどのアドレスにバッファ３３０からライトデータを書き込むかを指示する。

ステップ１４０１４：この後、データライト処理実行部１２１００は、書き込みが完了するのを待つ。

ステップ１４０１５：データライト処理実行部１２１００は、ストレージコントローラ２００に、ライト要求が完了したことを報告して、処理を完了する。また、この際、データライト処理実行部１２１００は、圧縮前のライトデータ量と、圧縮後のデータ量をストレージコントローラ２００に報告する。この報告は、ライト要求の完了の報告に含まれていて良い。

ステップ１４０１６：当該ステップは、書き込み対象とした実ブロックの空き領域より、ライトデータの長さが、大きい場合に実行されるステップである。本ステップでは、データライト処理実行部１２１００は、該仮想ブロックグループに、min（ｋ，L（＜１）＊世代数３２０７＊（ｍ＋１）個の実ブロックが割り当てられている場合は、実ブロックを割り当てない。その場合、図２９に示すステップ１４０１９にジャンプする。

ステップ１４０１７：このステップは、対応する仮想ブロックグループに空き状態にある実ブロックを割り当てるステップである。なお、ここでは、割り当てる実ブロックは消去されていてデータは格納されていないものとする。データライト処理実行部１２１００は、各チップ情報３１００のチップ内空き実ブロック数３１０３等を参照して、どのフラッシュチップ３００の実ブロックを割り当てるかを決める。その後、データライト処理実行部１２１００は、対応するフラッシュチップ３００の空きブロック管理情報ポインタ３４００を参照して、先頭の実ブロック情報３３００を、当該仮想ブロックグループ管理情報の最初にヌルになっている空き実ブロックポインタ３３０２が示すようにする。これで、仮想ブロックグループに新たな実ブロックを割り当てたことになる。なお、データライト処理実行部１２１００は、空き実ブロック管理情報ポインタ３４００を、次の実ブロック情報３３００（仮想ブロックに割り当てた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２が示す実ブロック情報３３００）を示すようにし、さらに、仮想ブロックに割り当てた実ブロックの実ブロック情報３３００の中の空き実ブロックポインタ３３０２をヌルにする。また、データライト処理実行部１２１００は、当該実ブロックに対応するチップ情報３１００のチップ内空き実ブロック数３１０３の数を減らす。

ステップ１４０１８：データライト処理実行部１２１００は、当該仮想ブロック情報３２００の新たに割り当てた実ブロック情報ポインタ３２０２が示す実ブロック情報３３００とその１つ前の実ブロック情報ポインタ３２０２が示す実ブロック情報３３００の実ブロック識別子３３０１を参照して、どのフラッシュチップ３００のどのアドレスに、データを格納するかを決定する。この後、ステップ１４００８へジャンプする。

ステップ１４０１９：本ステップでは、データライト処理実行部１２１００は、当該仮想ブロックグループに、別の実ブロックを割り当てる。別の実ブロックを割り当てる理由は、実ブロックの消去回数の偏りを少なくするためである。この処理は、ウエアレベリング処理と呼ばれる。この際、割り当てる実ブロックの数は、世代圧縮後データ格納量３２０６に圧縮・伸長回路３６０に示された値を加えた値を基に決定される。当該ステップでは、データライト処理実行部１２１００は、必要な実ブロックの数を入力値として、ウエアレベリング処理部をコールして、実ブロックを決定する。データライト処理実行部１２１００は、ウエアレベリング処理部からは、ライトデータを格納する実ブロックの実ブロック情報３３００のアドレスを、入力値に等しい数だけ、受け取る。この実ブロックは、消去処理が施された状態にあり、直接データを書き込めるような状態であるとする。また、本実施例では、ウエアレベリング処理部は、例えば、特許文献１のような公知の技術を前提とするので、ここでは、特に詳細に説明しない。

ステップ１４０２０：ここでは、データライト処理実行部１２１００は、当該仮想ブロックグループ内のすべての世代ことの仮想セグメントすべてを一度伸長して、バッファに読み出す。このため、ヌル値でも、世代仮想セグメントアドレスポインタ３２０５と対応する世代圧縮仮想セグメント量３２０６が参照される。データライト処理実行部１２１００は、これらの値と、実ブロック情報３３００から、仮想セグメントのアドレス順に、どのフラッシュチップ３００のどのアドレスから、どの長さだけをバッファに転送するかを示すアドレスリストを生成する。

ステップ１４０２１: データライト処理実行部１２１００は、ステップ１４０２０で認識したフラッシュチップ３００に対応したチップ情報３１００をアクセスして、当該フラッシュチップ３００が接続されているパッケージバス３４０を識別し、対応するパッケージバス転送装置３５０を認識する。

ステップ１４０２２: データライト処理実行部１２１００は、ステップ１４０２０で認識したパッケージバス転送装置３５０に、ステップ１４０２０で生成した指示情報にしたがって、どのフラッシュチップ３００のどのアドレスからバッファ３３０にデータを読み込むよう指示する。なお、この際、データライト処理実行部１２１００は、圧縮・伸長回路３６０には、データを伸長するよう指示する。

ステップ１４０２３：この後、データライト処理実行部１２１００は、バッファ３３０への読み込みが完了するのを待つ。

ステップ１４０２４：データライト処理実行部１２１００は、当該仮想ブロック情報３２００の中で、ヌル値、を格納していないすべての世代仮想セグメントアドレスポインタ３２０５（以下、有効な世代仮想セグメントポインタ３２０５と呼ぶ）を更新する。データライト処理実行部１２１００は、最初の有効な仮想セグメントアドレスポインタ３２０５にブロックアドレスに、最初に割り当てた実ブロックのアドレスと相対アドレスにその先頭アドレスを設定する。データライト処理実行部１２１００は、次の有効な世代仮想セグメントアドレスポインタ３２０５としては、基本的に、ブロックアドレスには、その前の有効な世代仮想セグメントポインタ３２０なブロックアドレスを設定し、相対アドレスとしては、その前の有効な世代圧縮仮想セグメントデータ量さ３２０６の値を加えた値を設定していく。相対アドレスが、実ページ容量をこえた場合、データライト処理実行部１２１００は、相対アドレスとしては、その値から、実ページ容量を減算した値を設定し、ページアドレスとしては、次に割り当てた実ページのアドレスを設定する。データライト処理実行部１２１００は、最後の有効な世代仮想セグメントアドレスポインタ３２０５の値を設定したあと、この相対アドレスの値に、対応する世代圧縮仮想セグメントデータ量３２０６の値を加える。その加算後の値が実ページ容量をこえていなければ、データライト処理実行部１２１００は、最後の有効な世代仮想セグメントアドレスポインタ３２０５のブロックアドレスに対応する実ブロック情報３３００の実ブロック内空き領域３３０４に、実ページ容量からこの計算値を減算した値をセットし、加えて、当該ライト要求に対応した世代仮想セグメントアドレスポインタ３２０５には、ブロックアドレスに当該実ブロックのアドレスを設定する。さらに、この計算値が実ページ容量をこえていれば、データライト処理実行部１２１００は、最後の実ページアドレス情報ポインタが示す実ブロック情報３３００の実ブロック内空き領域３３０４に、実ページ容量の２倍の値からこの計算値を減算した値をセットする。

ステップ１４０２５：データライト処理実行部１２１００は、ストレージコントローラ２００から受け取ったライトデータを、ステップ１４０２３で、転送したデータの後の領域に、伸長して転送する。

ステップ１４０２６：データライト処理実行部１２１００は、当該世代の仮想セグメントの世代仮想セグメントアドレスポインタ３２０５がヌルか否かを判断する。成立なら、ステップ１４０２８へジャンプする。

ステップ１４０２７：成立しないなら、データライト処理実行部１２１００は、ストレージコントローラ２００から転送した際に、使用した圧縮・伸長回路３６０が示す値から世代圧縮仮想セグメントデータ量３２０６を減算した値を、圧縮データ格納量３２０４に加える。さらに、データライト処理実行部１２１００は、その減算後の値と同じ値を、パッケージ圧縮データ格納量３００７に加える。この後、データライト処理実行部１２１００は、圧縮・伸長回路３６０が示す値を世代圧縮仮想セグメントデータ量３２０６に加える。また、データライト処理実行部１２１００は、今回書き込んだライトデータ量に関しては、０を、圧縮後のデータ量に関しては、世代圧縮仮想セグメントデータ量３２０６に加えた値を、それぞれ、ストレージコントローラ２００に返す値として記憶する。この後、ステップ１４０２９へジャンプする。

ステップ１４０２８：成立の場合、データライト処理実行部１２１００は、ストレージコントローラ２００から転送した際に、使用した圧縮・伸長回路３６０が示す値を、圧縮データ格納量３２０４に加える。さらに、データライト処理実行部１２１００は、加算後の値と同じ値を、パッケージ圧縮データ格納量３００７に加える。この後、データライト処理実行部１２１００は、圧縮・伸長回路３６０が示す値を世代圧縮仮想セグメントデータ量３２０６にセットする。さらに、データライト処理実行部１２１００は、データ格納量３２０３には、圧縮前の値を加算して、その加算後の値と同じ値を、パッケージデータ格納量３００６に加える。また、データライト処理実行部１２１００は、今回書き込んだライトデータ量に関しては、ストレージコントローラ２００から受け取った圧縮前のデータ量を、圧縮後のデータ量に関しては、当該圧縮・伸長回路が示す値を、それぞれ、ストレージコントローラ２００に返す値として記憶する。

ステップ１４０２９：データライト処理実行部１２１００は、最後の有効な世代仮想セグメントアドレスポインタ３２０５の値の中で、この相対アドレスの値に、対応する圧縮仮想セグメントデータ長３２０６の値を加えた値を計算値とする。データライト処理実行部１２１００は、この計算値が実ブロック容量をこえていなければ、当該ライト要求に対応した世代仮想セグメントアドレスポインタ３２０５には、ブロックアドレスに最後の有効な世代仮想セグメントアドレスポインタ３２０５が示す実ブロックのアドレスを設定し、相対アドレスとしては、この計算値を設定する。さらに、この計算値が実ブロック容量をこえていなければ、データライト処理実行部１２１００は、最後の実ブロック情報３３００の実ブロック内空き容量３３０４に、実ブロック容量からこの計算値を減算した値を設定する。さらに、データライト処理実行部１２１００は、この計算値が実ブロック容量をこえていれば、最後の実ブロック情報３３００の実ブロック内空き容量３３０４に、実ブロック容量の２倍の値から、この計算値を減算した値を設定する。

ステップ１４０３０：次に、データライト処理実行部１２１００は、新たに割り当てた実ブロックに対応する実ブロック情報３３００の実ブロック識別子３３０１を参照して、この実ページがどのフラッシュチップ３００のどのアドレスから格納されているかを認識し、転送を指示するアドレスリストを生成する。

ステップ１４０３１:データライト処理実行部１２１００は、ステップ１４０１７で認識したライトデータを格納するフラッシュチップ３００に対応したチップ情報３１００をアクセスして、当該フラッシュチップ３００が接続されているパッケージバス３４０を識別し、対応するパッケージバス転送装置３５０を認識する。

ステップ１４０３２: データライト処理実行部１２１００は、ステップ１４０１８で認識したパッケージバス転送装置３５０に、どのフラッシュチップ３００のどのアドレスへバッファ３３０からデータを書き込むよう指示する。この際、データライト処理実行部１２１００は、圧縮・伸長回路３６０には圧縮を指示する。

ステップ１４０３３：この後、データライト処理実行部１２１００は、バッファ３３０からの書き込みが完了するのを待つ。

ステップ１４０３４：この後、データライト処理実行部１２１００は、当該パッケージの仮想容量を変化させる必要があるかを
チェックするのに、仮想容量判定処理部１２５００をコールする。

ステップ１４０３５:このステップは、元々割り当てていた実ブロックを空いた状態にするステップである。まず、データライト処理実行部１２１００は、元々割り当てていた実ブロックのすべてに消去処理を施す。これが完了すると、次に、データライト処理実行部１２１００は、元々割り当てていた実ブロックに対応する空き実ブロックポインタ３３０２に、空き実ブロック情報ポインタ３４００が示していた実ブロック情報３３００のアドレスを設定し、空き実ブロック管理情報ポインタ３４００には、元々割り当てていた実ブロックに対応する実プロック情報３３００のアドレスを設定する。また、データライト処理実行部１２１００は、対応する仮想ブロック情報３２００の実ブロック情報ポインタ３２０２をヌルにする。データライト処理実行部１２１００は、これを、当該仮想ブロックグループに割り当てていた実ブロックの数だけ繰り返す。

ステップ１４０３６:このステップは、新しく割り当てた数の実ブロックを仮想ブロックグループに割り当てる処理である。具体的には、例えば、データライト処理実行部１２１００は、対応する数だけの仮想ブロック情報３２００の実ブロック情報ポインタ３２０２を、新しく割り当てた実ブロックの実ブロック情報３３００を示すようにする。

ステップ１４０３７：データライト処理実行部１２１００は、ストレージコントローラ２００に対して、ライト要求の終了を報告する。なお、当該フラッシュパッケージ２３０の仮想容量を変化させる場合、データライト処理実行部１２１００は、新たな仮想容量を、ストレージコントローラ２００に報告する。また、データライト処理実行部１２１００は、ライトデータの圧縮前の値と圧縮後の値を報告する。

図３１は、仮想ブロック移動処理実行部１２３００の処理フローである。

仮想ブロック移動処理実行部１２３００は、指定された仮想セグメントの集合に格納されているデータを移動することの要求（仮想ブロック移動要求）をフラッシュパッケージ２３０がストレージコントローラ２００から受けたときに実行される。なお、ここでは、実ページ単位の要求なので、仮想ブロックグループの一部のセグメントの転送要求はないものとする。

ステップ１６０００：仮想ブロック移動処理実行部１２３００は、仮想ブロック移動要求で指定された仮想ブロックグループの集合を算出する。

ステップ１６００１:仮想ブロック移動処理実行部１２３００は、指定されたすべての仮想ブロックグループについて、データ格納量３２０３、圧縮後データ格納量３２０４、世代数３２０７、世代ＩＤ３２０８をストレージコントローラ２００に返す情報として記憶する。さらに、仮想ブロック移動処理実行部１２３００は、世代ＩＤ３２０８を参照し、それぞれの仮想ブロックグループのすべての世代の仮想セグメントに対し、対応する世代仮想セグメントアドレスポインタ３２０５を参照して、下記の情報、
（ａ）データが格納されていない（ヌル）かデータが格納されているかを示す情報、
（ｂ）上記（ａ）の情報が、格納されていることを表す情報である場合、どの世代のデータかを示す情報と世代圧縮仮想セグメントデータ量３２０６に格納された情報、
を、ストレージコントローラ２００に戻す値として設定する。

ステップ１６００２：仮想ブロック移動処理実行部１２３００は、指定されたすべての仮想ブロックグループについて、それぞれの仮想ブロックグループのデータ格納量３２０３と圧縮データ格納量３２０４を、ストレージコントローラ２００に戻す値として設定する。また、仮想ブロック移動処理実行部１２３００は、これらの仮想ブロックグループのデータ格納量３２０３と圧縮後データ格納３２０４のそれぞれの合計値を求め、それぞれの合計値を、ストレージコントローラ２００に返却する値として設定する。さらに、仮想ブロック移動処理実行部１２３００は、それぞれの合計値を、パッケージデータ格納量３００６とパッケージ圧縮データ格納量３００７から減算する。その後、仮想ブロック移動処理実行部１２３００は、データ格納量３２０３、圧縮データ格納量３２０４、すべての仮想セグメントアドレスポインタ３２０５と圧縮仮想セグメントデータ量３２０６をクリアする。

ステップ１６００３：仮想ブロック移動処理実行部１２３００は、指定されたすべての仮想セグメントの仮想セグメントアドレスポインタ３２０５がヌルでない（データを格納している）ことを示す、仮想セグメントアドレスポインタ３２０５と対応する圧縮仮想セグメントデータ量３２０６から、ストレージコントローラ２００に送るべき当該仮想ブロックグループの中に格納されているデータが格納されているアドレスとその転送長を示す情報リストを生成する。

ステップ１６００４:仮想ブロック移動処理実行部１２３００は、指定された仮想セグメントに割り当てられている実ブロックが格納されているフラッシュチップ３００に対応したチップ３１００情報をアクセスして、当該フラッシュチップ３００が接続されているパッケージバス３４０を特定し、対応するバス転送装置３５０を特定する。

ステップ１６００５:仮想ブロック移動処理実行部１２３００は、ステップ１６００４で特定したバス転送装置３５０に、ステップ１６００４で生成した情報リストに従うアドレスからバッファ３３０にデータを転送するよう指示する。その際、仮想ブロック移動処理実行部１２３００は、圧縮・伸長回路３６０Ｂには、データを伸長するよう指示する。

ステップ１６００６：仮想ブロック移動処理実行部１２３００は、転送が完了するのを待つ。

ステップ１６００７：仮想ブロック移動処理実行部１２３００は、該当するすべての仮想ブロックグループに対応する仮想ブロック情報３２００の実ブロック情報ポインタ３２０２が示す実ブロック情報３３００に対応する実ブロックの解放処理を行う。このため、仮想ブロック移動処理実行部１２３００は、該当するすべての実ブロック情報３３００の実ブロック識別子３３０１を解析し、解放する実ブロックが、どのフラッシュチップ３００のどのアドレスに属しているかを判断する。

ステップ１６００８：本ステップは、該当するすべての仮想ブロックグループに割り当てたすべての実ブロックを空いた状態にするステップである。処理内容は、図２９のステップ１４０３５とまったく同じであるので、ここでは、説明を省略する。ただし、ステップ１４０３５の処理は、一つの仮想ブロックグループに対する処理であるが、ここでは、ステップ１４０３５の処理は、該当する仮想ブロックグループの数だけ、実行することになる。

ステップ１６００９：仮想ブロック移動処理実行部１２３００は、ストレージコントローラ２００へ、バッファ３３０に格納したデータを送る。まず、仮想ブロック移動処理実行部１２３００は、指定されたすべての仮想ブロックグループについて、データ格納量３２０４、圧縮後データ格納量３２０５、世代数３２０７、世代ＩＤ３２０８をストレージコントローラ２００に返す情報として記憶する。さらに、仮想ブロック移動処理実行部１２３００は、世代ＩＤ３２０８を参照し、それぞれの仮想ブロックグループのすべての世代の仮想セグメントに対し、対応する世代仮想セグメントアドレスポインタ３２０５を参照して、下記の情報、
（ａ）データが格納されていない（ヌル）かデータが格納されているかを示す情報、
（ｂ）上記（ａ）の情報がデータが格納されていることを表す情報である場合、どの世代のデータかを示す情報と世代圧縮仮想セグメントデータ量３２０６に格納された情報、
を送る。最後に、仮想ブロック移動処理実行部１２３００は、すべての有効な世代ごとの仮想セグメントに格納されていたデータを、ストレージコントローラ２００に送る。以上で処理を終了する。

図３２は、仮想ブロック格納処理実行部１２４００の処理フローである。

仮想ブロック格納処理実行部１２４００は、格納要求（指定された仮想ブロックグループに、実ブロックをそれぞれ割り当てて、ストレージコントローラ２００から送られてきたデータを格納せよという要求）を受けたときに、実行される。仮想ブロック移動処理実行部１２３００とは、データの流れが逆ではあるが、共通点が多いので、図３１の処理フローの各ステップを引用しながら説明を行う。

ステップ１７０００：ステップ１６０００と同様。仮想ブロック格納処理実行部１２４００は、格納を指示された仮想セグメントの集合から、対象となる仮想ブロックグループを特定する。

ステップ１７００１：仮想ブロック格納処理実行部１２４００は、ストレージコントローラ２００から以下の情報を受け取る。すなわち、仮想ブロック格納処理実行部１２４００は、指定されたすべての仮想ブロックグループについて、データの格納量、圧縮後のデータの格納量、世代数、世代ＩＤの集合を、ストレージコントローラ２００から受け取る。さらに、仮想ブロック格納処理実行部１２４００は、それぞれの仮想ブロックグループのすべての世代の仮想セグメントについて、下記の情報、
（ａ）データが格納されていない（ヌル）かデータが格納されているかを示す情報、
（ｂ）上記（ａ）の情報が格納されていることを表す情報である場合、どの世代のデータかを示す情報と圧縮後のデータの長さに格納された情報、
を受け取る。最後に、仮想ブロック格納処理実行部１２４００は、仮想セグメントに格納するデータを受け取るが、この際には、圧縮・伸長回路３６０に指示して、圧縮して、バッファ３３０に格納する。また、仮想ブロック格納処理実行部１２４００は、すべてのデータの格納データ量と圧縮データ格納量の変化値をパッケージデータ格納量３００６、パッケージ圧縮データ量３００７に加える。次に、仮想ブロック格納処理実行部１２４００は、指定された仮想セグメントを、仮想ブロックグループごとに分類する。

ステップ１７００２：ステップ１６００２と同様。仮想ブロック格納処理実行部１２４００は、データを格納するよう指示されている仮想ブロックグループを探す。もうなければ、ステップ１７０１０へジャンプする。

ステップ１７００３：仮想ブロック格納処理実行部１２４００は、当該仮想ブロックグループに対応して受け取った格納データ量、圧縮データ格納量、世代の数、世代ＩＤの集合を、対応する仮想ブロック情報３２００のデータ格納量３２０３と圧縮データ格納量３２０４、世代数３２０７、世代ＩＤ３２０８に格納する。また、仮想ブロック格納処理実行部１２４００は、対応する世代の仮想セグメントに関して受け取った、データが格納されているかいないかを表す情報を、対応する世代仮想セグメントアドレスポインタ３２０５に設定する。データが格納されているという情報を受け取った場合、仮想ブロック格納処理実行部１２４００は、対応する圧縮後のデータ長を、世代の情報を参照して、世代圧縮仮想セグメントデータ量３２０６にセットする。

ステップ１７００４:ここでは、実ブロックが当該仮想ブロックグループに割り当てられる。割り当てられる実ブロックの数は、当該仮想ブロック情報３２００の圧縮データ格納量３２０４を基に決定される。ここでは、必要な数の実ブロックが割り当てられる。これは、図２９のステップ１４０１９に示した処理なので、説明を省略する。

ステップ１７００５：仮想ブロック格納処理実行部１２４００は、当該仮想ブロック情報３２００の中で、データを格納していることを示す世代仮想セグメントアドレスポインタ３２０５を更新する。これは、ステップ１４０２４と同じであるため、説明を省略する。

ステップ１７００６:仮想ブロック格納処理実行部１２４００は、仮想セグメント内のデータが格納されているフラッシュチップ３００に対応したチップ情報３１００を基に、当該フラッシュチップ３００が接続されているパッケージバス３４０を特定し、対応するバス転送装置３５０を特定する。

ステップ１７００７:仮想ブロック格納処理実行部１２４００は、ステップ１７００６で特定したバス転送装置３５０に、フラッシュチップ３００のアドレスからバッファ３３０に当該仮想ブロックグループ全体のデータを格納するよう指示する。

ステップ１７００８：仮想ブロック格納処理実行部１２４００は、転送が完了するのを待つ。

ステップ１７００９：ステップ１７００２に戻る。

ステップ１７０１０：仮想ブロック格納処理実行部１２４００は、ストレージコントローラ２００へ、処理要求の完了を報告する。以上で処理を終了する。

図３３は、仮想容量判定処理部１２５００の処理フローである。

仮想容量判定処理部１２５００は、圧縮率を把握し、当該パッケージ２３０の仮想容量を調整する必要があるかを判断する。調整する必要があると判断した場合、その容量を決定し、仮想容量判定処理部１２５００は、仮想パッケージ容量３００２に設定する。さらに、この容量と容量を変更した旨を、呼び出し元に返却する。

ステップ１８０００：仮想容量判定処理部１２５００は、パッケージデータ格納量３００６／仮想パッケージ容量３００２の比を算出する。算出された比をＰとする。比Ｐが、Ｑ（Ｑは、例えば、Ｐよりも十分小さい値）以下の場合、仮想容量の調整を行わず、処理が、呼び出し元に戻る。比Ｐが、Ｑ以下の場合、まだ、それ程多くのデータが格納されていないからである。

ステップ１８００１：次に、仮想容量判定処理部１２５００は、Ｒ＝（仮想パッケージ容量３００２／実パッケージ容量３００３）を算出する。また、仮想容量判定処理部１２５００は、Ｔ＝（パッケージデータ格納量３００６／パッケージ圧縮データ格納量３００７）を算出する。値Ｔは、圧縮率である。

ステップ１８００２：仮想容量判定処理部１２５００は、ＲとＴを比較する。これらの値がほぼ等しければ（例えば、ＲとＴの差が所定値未満であれば）、理想的な仮想パッケージ容量３００２が設定されているということである。このため、仮想容量判定処理部１２５００は、調整を行わないことを決定し、呼び出し元に戻る。ＲのほうがＴより大きい場合（仮想容量が大き過ぎる場合）、又は、ＲのほうがＴより小さい場合（仮想容量が小さすぎる場合）、仮想容量判定処理部１２５００は、仮想パッケージ容量３００２の調整を行う。

ステップ１８００３：仮想容量判定処理部１２５００は、仮想容量を調整する。調整後の仮想容量の値は、例えば、実パッケージ容量３００３＊Ｔである。これは、圧縮率Ｔが今後も変化しなければ理想値となる。調整後の仮想容量の値は、（実パッケージ容量３００３−パッケージ圧縮データ格納量３００７）＊Ｒ＋パッケージ圧縮データ格納量３００７＊Ｔでも良い。仮想容量判定処理部１２５００は、決定した値（調整後の仮想容量の値）を、仮想パッケージ容量３００２に設定し、さらに、呼び出し元に、仮想容量の調整を行うことと、この決定した値とを通知し、処理を完了させる。

本実施例によれば、それぞれが多数のフラッシュメモリを実装したフラッシュパッケージを多数接続した大容量のストレージシステムにおいて、圧縮機能を適用し、データ格納容量を削減しても、性能劣化を抑えて、物理容量よりも大きな容量を格納することが可能となる。

以上、本発明の一実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、前述した世代ＩＤ、ＧＩＩＤ、ＢＫＩＤは、いずれも典型的には番号であるが、番号に代えて又は加えて、世代が増加した場合に規則的に更新される類のＩＤであれば何でも良い。また、例えば、世代ＩＤに代えて、実ページ及び実セグメントについて論理ボリュームの領域のアドレス（例えばＬＢＡ（Logical Block Address）を採用する方法も考えられるが、そうすると、どれが最新の世代かわからないので、上述した実施例のように、世代ＩＤが採用されることが好ましい。

以下、上述した説明を基に、本発明の１以上の観点に従う概要を記載する。

ストレージシステムは、複数のフラッシュパッケージと、上位装置からのライト要求（以下、第１のライト要求）に従うデータに基づくライトデータのライト要求（以下、第２のライト要求）をフラッシュパッケージに送信するストレージコントローラとを有する。上位装置は、ホスト計算機であっても良いし、他のストレージシステムであっても良い。

各フラッシュパッケージは、１以上のフラッシュメモリと、ストレージコントローラ及び１以上のフラッシュメモリに接続されるパッケージコントローラとを有する。各フラッシュメモリは、複数の実ブロックを有する。各実ブロックは、複数の実セグメントで構成されている。そのフラッシュメモリは、ブロック単位でデータが消去され、セグメント単位でデータが読み書きされるタイプのフラッシュメモリ、例えば、ＮＡＮＤ型のフラッシュメモリである。パッケージコントローラは、ストレージコントローラからのライト要求に従うライトデータを、実ブロックに書き込む。

上位の仮想空間と、上位の実空間と、下位の仮想空間と、下位の実空間とがある。上位の仮想空間は、複数の仮想ページ（仮想的な記憶領域）で構成された仮想的な論理ボリューム（シンプロビジョニングに従う仮想的な論理ボリューム）を１つ以上含む。上位の実空間は、複数の実ページで構成された記憶空間である。下位の仮想空間は、複数の仮想ブロックで構成された記憶空間である。実ページが１以上の仮想ブロックで構成されている。下位の実空間は、複数の実ブロックで構成された記憶空間である。実ページが割り当てられていないライト先の仮想ページに実ページが割り当てられる上位の容量仮想化と、実ブロックが割り当てられていないライト先の仮想ブロックに実ブロックが割り当てられる下位の容量仮想化とが行われる。

ストレージコントローラ（又はパッケージコントローラ）が、第１の論理ボリュームをベースとした第２の論理ボリュームを生成する。ストレージコントローラ（又はパッケージコントローラ）が、第１の論理ボリュームと第１の論理ボリュームをベースとして生成された１以上の第２の論理ボリュームとで構成された複数の論理ボリュームを論理ボリュームグループとして管理する。第１の論理ボリュームをベースとした第２の論理ボリュームが新たに生成された場合には、同一の論理ボリュームグループを構成し新たに生成された第２の論理ボリュームを含んだ複数の論理ボリュームのうち、上位装置からの上位のライト要求に従うデータが書き込まれる論理ボリュームの世代ＩＤが最新の世代ＩＤに更新される。世代ＩＤは更新されても、例えば、上位装置からアクセス要求（第１のライト要求及び第１のリード要求）で指定されるボリュームＩＤ（例えばＬＵＮ（Logical Unit Number））は更新されないことが望ましい。ストレージコントローラ（又はパッケージコントローラ）が、論理ボリュームグループを構成する複数の論理ボリュームの同一のアドレスの仮想ページに、同一の実ページを割り当てる。

各実ブロックは複数の実セグメントで構成されている。同一の実ページを構成する仮想ブロックに割り当てられた実ブロックに新たにデータが書き込まれる場合、その実ブロックにおける空きの実セグメントにデータが書き込まれるようになっている。

ストレージコントローラは、論理ボリュームグループを構成する各論理ボリュームの世代ＩＤと、その論理ボリュームグループを構成する複数の論理ボリュームに割り当てられている実ページとの対応を管理する。ストレージコントローラは、第２のライト要求を送信する場合、その第２のライト要求に、第１のライト要求に従うライト先の論理ボリュームの世代ＩＤを含める。パッケージコントローラは、第２のライト要求を受信し、その第２のライト要求に従うアドレスの実ページ（仮想ブロック）に割り当てられた実ブロックの空きの実セグメントにその第２のライト要求に従うライトデータを書き込み、且つ、そのライトデータの書込み先の実セグメントとそのライトデータの第２のライト要求が含む世代ＩＤとを対応付けて管理する。１つの実ページが、複数の世代にそれぞれ対応する複数の論理ボリュームに割り当てられ、その同一の実ページに、複数の世代のデータが書き込まれるが、それらのデータは、フラッシュメモリの特性上、上書きされて消去されることなく、同一の実ページに割り当てられた１以上の実ブロックにおける異なる複数の実セグメントに格納される。世代毎に、有効なデータ（最新のデータ）と無効なデータとがある。リクラメーションの際には、同一の実ページについて、各世代について有効なデータが１以上の実ブロックに集約され、１以上の世代についての無効データのみが格納された実ブロックに対して消去処理が施される。

ストレージコントローラは、上位装置から第１のリード要求を受けその第１のリード要求に基づく第２のリード要求を複数のフラッシュパッケージのうちのリード元のフラッシュパッケージに送信するようになっており、第２のリード要求を送信する場合、その第２のリード要求に、第１のリード要求に従うリード元の論理ボリュームの世代ＩＤを含める。パッケージコントローラは、第２のリード要求を受信し、その第２のリード要求に従うアドレスの実ページ（仮想ブロック）に割り当てられている１以上の実ブロックから、その第２のリード要求が含む世代ＩＤについて有効なデータを記憶している実セグメントを特定する。そのような実セグメントが無ければ、パッケージコントローラは、第２のリード要求が含む世代ＩＤが表す世代よりも古い世代（例えば、第１の論理ボリューム又は最新の第２の論理ボリューム）について有効なデータを記憶している実セグメントを特定する。パッケージコントローラは、特定した実セグメントからデータを読み出し、そのデータをストレージコントローラに送信する。ストレージコントローラが、そのデータを受信し、そのデータを上位装置に送信する。

ストレージコントローラが、論理ボリュームグループ毎に、第１の論理ボリュームが上位装置によって更新される第１のタイプの論理ボリュームグループであるのか、第２の論理ボリュームが上位装置によって更新される第２のタイプの論理ボリュームグループであるのかを管理することができる。第１のタイプの論理ボリュームグループによれば、典型的には、第１の論理ボリュームから第２の論理ボリュームにデータがバックアップされる。第２のタイプの論理ボリュームグループによれば、典型的には、ゴールデンイメージを格納している第１の論理ボリュームを基に生成された第２の論理ボリュームが、上位装置で実行される仮想計算機に使用される。仮想計算機は第２の論理ボリュームからゴールデンイメージに含まれているＯＳを読み出して実行する。

ストレージコントローラ（又はパッケージコントローラ）は、同一の実ページの割当先の論理ボリュームの数（世代数）が一定数を超えているか否かを判断し、その判断の結果が肯定的の場合に、その同一の実ページに割り当てられている１以上の実ブロックに格納されている、その同一の実ページが割り当てられている複数の論理ボリュームに書き込まれた複数のデータ（例えば有効なデータ）を、複数の実ページに分散する。

ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージが有する複数のフラッシュチップの物理的な容量の合計値よりも大きな仮想的な容量をストレージコントローラに定義する。

ストレージコントローラ又はパッケージコントローラが、下位のライト要求に従うライトデータを圧縮する。下位のライト要求の送信先のフラッシュパッケージのパッケージコントローラが、圧縮されたライトデータである圧縮データを、ライト先の仮想ブロックに割り当てられた実ブロックに書き込む。

ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージのデータ格納状況に応じて、そのフラッシュパッケージの仮想容量を変更する。データ格納状況は、典型的には、前述した圧縮率である。フラッシュパッケージの圧縮率は、そのフラッシュパッケージに格納されている有効な圧縮データの圧縮前のライトデータの総容量と、そのフラッシュパッケージに格納されている有効な圧縮データの総容量とに基づく値である。具体的には、例えば、ストレージコントローラ又はパッケージコントローラが、仮想セグメントに書き込まれた有効な圧縮後のデータの量とその有効なデータの圧縮前のデータの量とを仮想セグメントごとに管理する。フラッシュパッケージに格納されている有効な圧縮データの圧縮前のライトデータの総容量は、そのフラッシュパッケージが提供する各仮想セグメントについての、書き込まれた有効なデータの圧縮前のデータの量を基に算出された値である。フラッシュパッケージに格納されている有効な圧縮データの総容量は、そのフラッシュパッケージが提供する各仮想セグメントについての、そのフラッシュパッケージに格納されている有効な圧縮データの量を基に算出された値である。例えば、仮想ブロック＃１に実ブロック＃１が割り当てられていて、仮想ブロック＃１が仮想セグメント＃１及び＃２を含んでいるとする。ここでは、仮想セグメント長を８キロバイトとして説明を行う。仮想セグメント＃１に、データが格納され、圧縮された結果、１キロバイトの圧縮データが格納され、仮想セグメント＃２に、データが格納され、圧縮の結果２キロバイトの圧縮データが格納され、さらに、仮想セグメント＃１が、書きかえられ、圧縮の結果、３キロバイトのデータが格納されたとする。この場合、仮想セグメント＃１の有効なデータ（最新のデータ）は、３キロバイトの圧縮データであり、仮想セグメント＃２の有効なデータ（最新のデータ）は、２キロバイトの圧縮データである。このため、実ブロック＃１について、最新の圧縮データの総量は、３キロバイト＋２キロバイト＝５キロバイトである。また、実ブロック＃１について、最新の圧縮前のデータの総量は、８キロバイト＋８キロバイト＝１６キロバイトである。このように、仮想セグメントに圧縮データが格納されれば、その仮想セグメントを提供するフラッシュパッケージについて、パッケージデータ格納量３００６及びパッケージ圧縮データ格納量３００７が更新される。パッケージコントローラが、ライト先の仮想セグメントを含む仮想ブロックについて、圧縮状況情報（例えば、その仮想セグメントに書き込まれた圧縮データの量とその圧縮データの圧縮前のライトデータの量とを表す情報、及び／又は、それらの量に基づいて算出される、当該ライト時の圧縮率を表す情報）を、ストレージコントローラに送信する。圧縮状況情報は、下位のライト要求に対する完了報告に含められても良い。

ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージの圧縮率が増加した場合、そのフラッシュパッケージの仮想容量を増やす。データ格納量をより削減できるので、より多くのライトデータを格納することが期待されるからである。

ストレージコントローラ又はパッケージコントローラが、フラッシュパッケージの圧縮率が減少した場合、そのフラッシュパッケージの仮想容量を減らす。データ格納量があまり削減されないので、あまり多くのライトデータを格納することができないことが期待されるからである。

各実ページは、複数の仮想ブロックを含んでいる。ストレージコントローラは、フラッシュパッケージの仮想容量を増やす場合、そのフラッシュパッケージに基づく空きの実ページを増やし、そのフラッシュパッケージの仮想容量を減らす場合、そのフラッシュパッケージに基づく空きの実ページを減らす。このように、下位レベルの容量仮想化機能に加えて上位レベルの容量仮想化機能があれば、仮想ブロックと実ブロックの対応関係を変更することなく、仮想容量の増減を行うことができる。

ライトデータの圧縮は、フラッシュチップへのライトのとき、リクラメーション処理のとき、或いは、ページ間のデータ移動のときの少なくとも１つのときに行われる。リクラメーション処理は、フラッシュパッケージにおいて必然的に行われる処理であるから、その処理のときに圧縮が行われるので、性能の低下が生じるのを抑えることが期待できる。

ストレージコントローラが、フラッシュパッケージの圧縮率を基に、フラッシュパッケージ間で、移動元の実ページから移動先の実ページにデータを移動する。ストレージコントローラは、移動元の実ページに関連付けられている管理情報、移動先の実ページに関連付けられている管理情報に適用する。管理情報は、例えば、データが格納されているか、繰り返し情報が格納されているか等を含んで良い。また、フラッシュパッケージ間のデータ移動では、移動元のフラッシュパッケージが、移動元実ページに割り当てられている実ブロック内の有効な圧縮データを伸長して（又は伸長することなく）移動先のフラッシュパッケージに転送し、移動先のフラッシュパッケージが、受信したデータを圧縮して（又は圧縮済みであるため圧縮することなく）、移動先実ページに割り当てられている実ブロックに格納して良い。その際、移動元の実ページに対応する管理情報（例えば、データ格納量及び圧縮データ格納量を表す情報）はリセットされ、移動先の実ページに対応する管理情報（例えば、データ格納量及び圧縮データ格納量を表す情報）は、データ移動に伴い格納された圧縮データの量（及びその圧縮データの圧縮前のデータの量）を基に更新されて良い。

パッケージコントローラは、そのパッケージコントローラにおいてリクラメーション処理を行うことができる。リクラメーション処理では、パッケージコントローラは、満杯になった移動元実ブロック内の有効なデータを移動先実ブロックに移し、移動元実ブロックに対する消去処理（移動元実ブロックに格納されているデータを消去する処理）を行うことで、移動元実ブロックを空きの実ブロックとする。このリクラメーション処理において、データの圧縮及び伸長が行われて良い。

１００…ストレージシステム、１１０…ホスト、１２０…ストレージエリアネットワーク（SAN）、２００…ストレージコントローラ、２１０…キャッシュメモリ、２２０…共有メモリ、２３０…フラッシュパッケージ、２５０…接続装置、２６０…プロセッサ、２７０…メモリ、２８０…フラッシュパッケージグループ、３００…フラッシュチップ、３１０…パッケージプロセッサ、３２０…パッケージメモリ、３３０…バッファ、３４０…パッケージバス、３５０…パッケージ転送装置、３６０…圧縮・伸長回路、２０００…論理ボリューム情報、２１００…実ページ情報、２３００…フラッシュパッケージグループ情報、２５００…フラッシュパッケージ情報、３０００…パッケージ情報、３１００…チップ情報、３２００…仮想ブロックグループ情報、３３００…実ブロック情報、４０００…リード処理実行部、４１００…ライト処理受付部、４２００…ライトアフタ処理実行部、４３００…実ページ分割処理部、４５００…実ページ移動処理実行部、４６００…論理ボリューム生成処理部、１２０００…データリード処理実行部、１２１００…データライト処理実行部、１２３００…仮想ブロック移動処理実行部、１２４００…仮想ブロック格納処理実行部、１２５００…仮想容量判定処理部

Claims (16)

1. 複数のフラッシュパッケージとストレージコントローラとを備えるストレージシステムであって、
   前記複数のフラッシュパッケージのそれぞれは、追記型メモリである複数のフラッシュチップを有し、前記複数のフラッシュチップの物理記憶領域に仮想アドレス空間を対応付けて前記ストレージコントローラに提供し、
   前記ストレージコントローラは、前記複数のフラッシュパッケージが提供する前記仮想アドレス空間を複数のページに分割して管理し、ホスト計算機に対して複数の論理ボリュームを提供し、前記ホスト計算機から前記複数の論理ボリュームのうちの特定の論理ボリュームへの第１のライト要求に応じて、前記複数のページのうちの特定のページを前記特定の論理ボリュームに割り当て、
   前記ストレージコントローラは、前記複数の論理ボリュームのうちの第１の論理ボリュームをベースとした差分ボリュームである第２の論理ボリュームを生成し、
   前記第１の論理ボリュームは、第１のデータを格納する第１の論理アドレスの領域を有し、
   前記第２の論理ボリュームは、前記第１の論理アドレスの領域に対応し、前記第１のデータとは世代の異なる第２のデータを格納する、第２の論理アドレスの領域を有し、
   前記ストレージコントローラは、前記第１の論理アドレスの領域と、前記第２の論理アドレスの領域と、の両方に前記複数のページのうちの１つのページである同一ページを割り当て、
   前記複数のフラッシュパッケージのうち前記同一ページを構成する仮想アドレス空間部分を提供するフラッシュパッケージは、前記第１のデータと前記第２のデータとのそれぞれを前記複数のフラッシュチップの異なる物理記憶領域に格納し、前記第１の論理ボリュームに格納される前記第１のデータと、前記第２の論理ボリュームに格納される第２のデータと、の両方を前記仮想アドレスに対応付ける
   ことを特徴とするストレージシステム。
2. 請求項１記載のストレージシステムであって、
   前記同一ページの割当先の論理ボリュームの数が一定数を超えているか否かを判断し、その判断の結果が肯定的の場合に、前記同一ページに割り当てられている１以上のブロックに格納されている、前記同一ページが割り当てられている複数の論理ボリュームに書き込まれた複数のデータを、複数のページに分散する機能、を更に有することを特徴とするストレージシステム。
3. 請求項１記載のストレージシステムであって、
   前記ストレージコントローラは、前記複数のフラッシュパッケージの少なくとも１つに第２のライト要求又はリード要求を発行する際、論理ボリュームの識別子を指定する、ことを特徴とするストレージシステム。
4. 請求項３記載のストレージシステムであって、
   前記フラッシュパッケージが、
   前記ストレージコントローラに対して、前記フラッシュパッケージの前記複数のフラッシュチップの容量の合計値よりも、見かけ上大きな仮想アドレス空間を定義する機能と、
   前記第２のライト要求で受け付けた前記論理ボリュームの識別子が異なった、前記仮想アドレスのデータを、同一のブロックの中に格納する機能とを有する、ことを特徴とするストレージシステム。
5. 請求項４に記載のストレージシステムであって、
   前記フラッシュパッケージが、
   前記ストレージコントローラに対して、前記フラッシュパッケージの前記複数のフラッシュチップの容量の合計値よりも、見かけ上大きな仮想アドレス空間を定義する機能と、
   前記第２のライト要求で受け付けた前記論理ボリュームの識別子が異なった、前記仮想アドレスのデータを、同一のブロックの中の、空いた領域に格納する機能とを有する、ことを特徴とするストレージシステム。
6. 請求項３記載のストレージシステムであって、
   前記フラッシュパッケージが、
   前記ストレージコントローラに対して、前記フラッシュパッケージの前記複数のフラッシュチップの容量の合計値よりも、見かけ上大きな仮想アドレス空間を定義する機能と、
   前記第２のライト要求で受け付けた前記論理ボリュームの識別子が異なった、前記仮想アドレスデータを、同一のブロックの中の、空いた領域に圧縮して格納する機能とを有する、ことを特徴とするストレージシステム。
7. 請求項５記載のストレージシステムであって、
   前記複数のフラッシュチップのそれぞれは、複数のブロックを有し、前記複数のブロックのそれぞれは、データの消去単位であり、
   前記フラッシュパッケージが、
   前記ブロックの消去処理を行う機能と、
   前記消去処理の実行の前に、前記ブロック内に格納された複数の世代のデータの中で、データアドレスと世代ＩＤが同一であるデータの中の最新のデータを選択する機能と、
   新たなブロックを割り当て、前記選択したデータを、前記割り当てたブロックに書き込む機能とを有する、ことを特徴とするストレージシステム。
8. 請求項６記載のストレージシステムであって、
   前記複数のフラッシュチップのそれぞれは、複数のブロックを有し、前記複数のブロックのそれぞれは、データの消去単位であり、
   前記フラッシュパッケージが、
   前記ブロックの消去処理を行う機能と、
   前記消去処理の実行の前に、前記ブロック内に格納された複数の世代のデータの中で、データアドレスと世代ＩＤが同一であるデータの中の最新のデータを選択する機能と、
   新たなブロックを割り当て、前記選択したデータを圧縮した状態で、前記割り当てたブロックに書き込む機能とを有する、ことを特徴とするストレージシステム。
9. 請求項５記載のストレージシステムであって、
   前記フラッシュパッケージが、
   前記フラッシュチップに書き込まれた前記データの格納状況を把握する機能と、
   前記データの格納状況を、前記ストレージコントローラに通知する機能とを有する、ことを特徴とするストレージシステム。
10. 請求項６記載のストレージシステムであって、
    前記フラッシュパッケージが、
    圧縮した状態で前記フラッシュチップに書き込まれた前記データの格納状況を把握する機能と、
    前記データの格納状況を、前記ストレージコントローラに通知する機能とを有する、ことを特徴とするストレージシステム。
11. 請求項５記載のストレージシステムであって、
    前記フラッシュパッケージが、
    前記フラッシュチップに書き込まれた前記データの格納状況を把握する機能と、
    前記ストレージコントローラに対して定義した前記仮想アドレス空間の容量を変更して、前記ストレージコントローラに、変更した仮想アドレス空間の容量を通知する機能とを有する、ことを特徴とするストレージシステム。
12. 請求項６記載のストレージシステムであって、
    前記フラッシュパッケージが、
    前記フラッシュチップに書き込まれた前記データの格納状況を把握する機能と、
    前記ストレージコントローラに対して定義した前記仮想アドレス空間の容量を変更して、前記ストレージコントローラに、変更した仮想アドレス空間の容量を通知する機能とを有する、ことを特徴とするストレージシステム。
13. 請求項６記載のストレージシステムであって、
    前記フラッシュパッケージが、
    圧縮した状態で前記フラッシュチップに書き込まれた前記データの格納状況を把握する機能と、
    前記ストレージコントローラに対して定義した前記仮想アドレス空間の容量を変更して、前記ストレージコントローラに、変更した仮想アドレス空間の容量を通知する機能とを有する、ことを特徴とするストレージシステム。
14. 請求項５記載のストレージシステムであって、
    前記ストレージコントローラが
    前記フラッシュパッケージの格納状況を把握し、前記フラッシュパッケージ間で前記ページ内のデータを移動することを決定する機能と、
    その決定にしたがって、前記フラッシュパッケージ間で前記ページ内のデータを移動する機能とを有する、ことを特徴とするストレージシステム。
15. 請求項６記載のストレージシステムであって、
    前記ストレージコントローラが、
    前記フラッシュパッケージの圧縮されたデータの格納状況を把握し、前記フラッシュパッケージ間で前記ページ内のデータを移動することを決定する機能と、
    その決定にしたがって、前記フラッシュパッケージ間で前記ページ内のデータを移動する機能とを有する、ことを特徴とするストレージシステム。
16. 請求項２記載のストレージシステムであって、
    前記ストレージコントローラが、前記同一ページに格納されている複数の論理ボリュームのデータの格納状況を把握して、状況によって、複数のページに、前記論理ボリュームのデータを再配置する機能を有する、ことを特徴とするストレージシステム。

Images