図面 (/)

この項目の情報は公開日時点(2016年11月10日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

フラッシュパッケージ内のそれぞれのブロックの消去回数偏りを少なくする。

解決手段

多数のフラッシュパッケージ230を有するストレージシステム100は、ブロック単位の容量仮想化機能をもつ一方、それぞれのフラッシュパッケージ230の消去回数、データ占有率を算出して、これらの消去回数やデータ占有率の値に基づき、フラッシュパッケージ230間でデータを移動する機能もつことで、ストレージシステム100全体で、消去回数の偏りの軽減とデータ格納容量の削減を効率的に実現する。

概要

背景

フラッシュメモリは、メモリの特性上、データを書き換えようとした時、そのデータが元々格納されていた物理領域上に、そのデータを、直接上書きすることは不可能である。データの書換えを行う際には、フラッシュメモリの消去単位であるブロックと呼ばれる単位で、消去処理を実行した後、データを書き換える必要がある。このブロックに対する消去処理の実行回数には、物理的な制約から限界がある。フラッシュメモリのブロックは、消去回数がこの限界数をこえると、そのブロックにはデータを格納できなくなってしまうという性質をもっている。

このため、フラッシュメモリの各々のブロックに対して、データを格納するアドレスを固定的に割り当てる方式をとると、通常はアドレスごとに書換え頻度が異なるので、消去回数のばらつきがブロックごとに生ずることになる。このため、ある特定のブロックの消去回数が限界数を超えると、そのブロックに割り当てたアドレスのデータを格納できなくなってしまう。以上の問題を解決するため、このばらつきを少なくする技術として、ウエアレベリングと呼ばれる技術が公開されている(例えば、特許文献1)。ウエアレベリングの基本的な考え方は、外側に見せるアドレス層として、物理的なアドレスとは別に、論理的なアドレス層を設け、物理的なアドレスに割り当てる論理的なアドレスを適宜変更していく、例えば、頻繁にアクセスされる論理的なアドレスには、消去回数の少ないアドレスを割り当てることによって、物理的なブロックの消去回数の偏りを削減しようというものである。また、物理的なアドレスが変更になっても、論理的なアドレスは変わらないので、外側からは、同一のアドレスでデータクセスが可能であるため、使い勝手の良さも維持できる。

次に、格納容量削減技術について述べる。近年、ストレージシステムでは、格納容量を削減する技術が注目されている。その代表的な技術の一つが、容量の仮想化技術である。容量の仮想化技術とは、ストレージシステムがもっている物理的な容量より大きな仮想的な容量をホスト側に見せる技術である。これは、ユーザが実際にストレージを使用する場合、ユーザが定義したユーザボリューム(ユーザからみた記憶装置)の容量に対し、実際に格納するデータの量は、この定義容量には、なかなか達しないという特性を利用したものである。すなわち、容量仮想化技術がない場合には、ボリューム定義時に、定義された物理的な容量を確保していたのに対し、容量仮想化技術を適用した場合には、実際にストレージシステムにデータが格納されたとき、初めて容量を確保することになる。これによって、格納容量を削減でき、かつ、ユーザはボリューム容量を厳密に定義する必要なく、単純に大きく余裕をもった値を定義すればよいため、使い勝手も向上できる。この技術において、データが書き込まれたときに確保される物理的な記憶領域は、ページと呼ばれる。一般に、ページのサイズは、多様性にとんでいるが、本発明では、ページのサイズのほうが、フラッシュメモリの消去単位であるブロックのサイズより大きいものとする。一方、フラッシュメモリにおいては、一般的に、消去の単位は、前述したようにブロックと呼ぶのに対し、ブロックの中での読み書きの単位をページとよぶ。当然、フラッシュメモリにおいては、ブロックのサイズのほうが、ページサイズより大きくなる。しかし、本発明では、ページという言葉は、容量仮想化におけるページをさすことにする。また、繰り返しになるが、本発明においては、ページのサイズは、フラッシュメモリのブロックのサイズよりも大きいとする。

ただし、本発明の対象となるストレージシステムは、上記の容量仮想化技術をもっていることが必ずしも必要条件とはならない。一方、容量仮想化技術をもったストレージステムにおいては、ページ単位で、ページを記憶装置(典型的には、HDD(Hard Disk Drive))の間で移動させ、性能向上を実現させる技術が、公開されている(特許文献2)。さらに、価格性能比がことなる記憶装置間で、ページを移動させ、価格性能比を向上させる技術も公開されている。一方、通常、HDDには、ユーザのデータを格納する前に、特定のパターン、例えば、オール0などでフォーマティングする。この際、ホストが書き込むこの特定パターンを、ストレージシステムで検出して、すでに割り当てているページを解放する技術も公開されている(特許文献3)。

概要

フラッシュパッケージ内のそれぞれのブロックの消去回数の偏りを少なくする。多数のフラッシュパッケージ230を有するストレージシステム100は、ブロック単位の容量仮想化機能をもつ一方、それぞれのフラッシュパッケージ230の消去回数、データ占有率を算出して、これらの消去回数やデータ占有率の値に基づき、フラッシュパッケージ230間でデータを移動する機能もつことで、ストレージシステム100全体で、消去回数の偏りの軽減とデータ格納容量の削減を効率的に実現する。

目的

本発明において解決しようとする課題は、第1に、多数のフラッシュメモリチップ記憶媒体として構成する大規模ストレージシステムにおいて、ストレージシステム全体で、フラッシュメモリの消去回数の偏りを効率的に少なくすることであり、第2に、フラッシュメモリへの格納データ容量を削減することである

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数のフラッシュパッケージと、複数の記憶デバイスと、ストレージコントローラと、を有するストレージシステムであって、前記複数のフラッシュパッケージはそれぞれ、データの消去単位である複数の物理ブロックを各々有する複数のフラッシュチップと、前記複数の物理ブロックの各々の消去回数を管理し、前記フラッシュパッケージ内の物理ブロック間の消去回数の偏りを少なくさせる機能を実行する第1デバイスコントローラを含み、前記複数の記憶デバイスはそれぞれ、第2デバイスコントローラを含み、前記ストレージコントローラは、複数のデータレコードと該複数のデータレコードからRAID機能によって生成されるパリティレコードとを含むレコードセットを少なくとも1つ格納する第1データ領域と、前記レコードセットを少なくとも1つ格納する第2データ領域と、をそれぞれ複数構成し、前記第1データ領域は前記複数のフラッシュパッケージに基づく記憶領域であり、前記第2データ領域は前記複数の記憶デバイスに基づく記憶領域であり、前記ストレージコントローラはまた、前記複数のフラッシュパッケージの各々から、前記第1デバイスコントローラによって管理されている消去回数に関する第1情報を取得し、前記複数の第1データ領域の中から前記第1情報に基づいて、前記レコードセットの転送元となる少なくとも1つの転送元データ領域を選択し、前記複数の第2データ領域の中から、前記レコードセットの転送先となる少なくとも1つの転送先データ領域を選択し、前記転送元データ領域から前記レコードセットを、前記転送先データ領域へと転送する、ことを特徴とするストレージシステム。

請求項2

請求項1に記載のストレージシステムにおいて、前記ストレージコントローラは、ホストコンピュータに対し、複数の仮想データ領域を有する仮想ボリュームを提供するよう構成され、前記複数の第1及び第2データ領域の各々は、前記仮想データ領域に割り当て可能であることを特徴とするストレージシステム。

請求項3

請求項1に記載のストレージシステムにおいて、前記ストレージコントローラは、ホストコンピュータから、特定のパターンを有するデータについて記憶領域に書き込みする要求を受け付け、前記記憶領域に関係する前記フラッシュパッケージを特定し、前記特定されたフラッシュパッケージに対して消去要求を送信するよう構成され、前記特定されたフラッシュパッケージの前記第1デバイスコントローラは、前記消去要求を受け付けると、前記消去要求で指定された複数の物理ブロックを消去することを特徴とする、ストレージシステム。

請求項4

請求項1に記載のストレージシステムにおいて、一の前記第1デバイスコントローラから前記ストレージコントローラに対して提供される論理ブロック群の合計記憶容量は、前記複数のフラッシュパッケージのうちの1つのフラッシュパッケージが有する全物理ブロックの合計記憶容量よりも大きいことを特徴とするストレージシステム。

請求項5

請求項4に記載のストレージシステムにおいて、前記第1デバイスコントローラは、前記ストレージコントローラから書き込み要求を受け付け、前記書き込み要求で指定された前記論理ブロックに物理ブロックが割り当てられていない場合には、前記指定された論理ブロックに対して前記複数の物理ブロックのうちの1つを割り当てるように構成されていることを特徴とするストレージシステム。

請求項6

複数のフラッシュパッケージと、複数の記憶デバイスと、ストレージコントローラと、を有するストレージシステムの制御方法であって、前記複数のフラッシュパッケージはそれぞれ、データの消去単位である複数の物理ブロックを各々有する複数のフラッシュチップと、前記複数の物理ブロックの各々の消去回数を管理し、前記フラッシュパッケージ内の物理ブロック間の消去回数の偏りを少なくさせる機能を実行する第1デバイスコントローラを含み、前記複数の記憶デバイスはそれぞれ、第2デバイスコントローラを含み、前記ストレージコントローラは、複数のデータレコードと該複数のデータレコードからRAID機能によって生成されるパリティレコードとを含むレコードセットを少なくとも1つ格納する第1データ領域と、前記レコードセットを少なくとも1つ格納する第2データ領域と、をそれぞれ複数構成し、前記第1データ領域は前記複数のフラッシュパッケージに基づく記憶領域であり、前記第2データ領域は前記複数の記憶デバイスに基づく記憶領域であり、前記方法は前記ストレージコントローラが、前記複数のフラッシュパッケージの各々から、前記第1デバイスコントローラによって管理されている消去回数に関する第1情報を取得し、前記複数の第1データ領域の中から前記第1情報に基づいて、前記レコードセットの転送元となる少なくとも1つの転送元データ領域を選択し、前記複数の第2データ領域の中から、前記レコードセットの転送先となる少なくとも1つの転送先データ領域を選択し、前記転送元データ領域から前記レコードセットを、前記転送先データ領域へと転送する、工程を実行する、ストレージシステムの制御方法。

請求項7

前記ストレージコントローラは、ホストコンピュータに対し、複数の仮想データ領域を有する仮想ボリュームを提供するよう構成され、前記複数の第1及び第2データ領域の各々は、前記仮想データ領域に割り当て可能である、請求項6に記載のストレージシステムの制御方法。

請求項8

前記ストレージコントローラは、ホストコンピュータから、特定のパターンを有するデータについて記憶領域に書き込みする要求を受け付け、前記記憶領域に関係する前記フラッシュパッケージを特定し、前記特定されたフラッシュパッケージに対して消去要求を送信するよう構成され、前記特定されたフラッシュパッケージの前記第1デバイスコントローラは、前記消去要求を受け付けると、前記消去要求で指定された複数の物理ブロックを消去するよう構成されている、請求項6に記載のストレージシステムの制御方法。

請求項9

一の前記第1デバイスコントローラから前記ストレージコントローラに対して提供される論理ブロック群の合計記憶容量は、前記複数のフラッシュパッケージのうちの1つのフラッシュパッケージが有する全物理ブロックの合計記憶容量よりも大きい、請求項6に記載のストレージシステムの制御方法。

請求項10

前記第1デバイスコントローラは、前記ストレージコントローラから書き込み要求を受け付け、前記書き込み要求で指定された前記論理ブロックに物理ブロックが割り当てられていない場合には、前記指定された論理ブロックに対して前記複数の物理ブロックのうちの1つを割り当てるように構成されている、請求項9に記載のストレージシステムの制御方法。

技術分野

0001

本発明は、ストレージシステムに関する。

背景技術

0002

フラッシュメモリは、メモリの特性上、データを書き換えようとした時、そのデータが元々格納されていた物理領域上に、そのデータを、直接上書きすることは不可能である。データの書換えを行う際には、フラッシュメモリの消去単位であるブロックと呼ばれる単位で、消去処理を実行した後、データを書き換える必要がある。このブロックに対する消去処理の実行回数には、物理的な制約から限界がある。フラッシュメモリのブロックは、消去回数がこの限界数をこえると、そのブロックにはデータを格納できなくなってしまうという性質をもっている。

0003

このため、フラッシュメモリの各々のブロックに対して、データを格納するアドレスを固定的に割り当てる方式をとると、通常はアドレスごとに書換え頻度が異なるので、消去回数のばらつきがブロックごとに生ずることになる。このため、ある特定のブロックの消去回数が限界数を超えると、そのブロックに割り当てたアドレスのデータを格納できなくなってしまう。以上の問題を解決するため、このばらつきを少なくする技術として、ウエアレベリングと呼ばれる技術が公開されている(例えば、特許文献1)。ウエアレベリングの基本的な考え方は、外側に見せるアドレス層として、物理的なアドレスとは別に、論理的なアドレス層を設け、物理的なアドレスに割り当てる論理的なアドレスを適宜変更していく、例えば、頻繁にアクセスされる論理的なアドレスには、消去回数の少ないアドレスを割り当てることによって、物理的なブロックの消去回数の偏りを削減しようというものである。また、物理的なアドレスが変更になっても、論理的なアドレスは変わらないので、外側からは、同一のアドレスでデータクセスが可能であるため、使い勝手の良さも維持できる。

0004

次に、格納容量削減技術について述べる。近年、ストレージシステムでは、格納容量を削減する技術が注目されている。その代表的な技術の一つが、容量の仮想化技術である。容量の仮想化技術とは、ストレージシステムがもっている物理的な容量より大きな仮想的な容量をホスト側に見せる技術である。これは、ユーザが実際にストレージを使用する場合、ユーザが定義したユーザボリューム(ユーザからみた記憶装置)の容量に対し、実際に格納するデータの量は、この定義容量には、なかなか達しないという特性を利用したものである。すなわち、容量仮想化技術がない場合には、ボリューム定義時に、定義された物理的な容量を確保していたのに対し、容量仮想化技術を適用した場合には、実際にストレージシステムにデータが格納されたとき、初めて容量を確保することになる。これによって、格納容量を削減でき、かつ、ユーザはボリューム容量を厳密に定義する必要なく、単純に大きく余裕をもった値を定義すればよいため、使い勝手も向上できる。この技術において、データが書き込まれたときに確保される物理的な記憶領域は、ページと呼ばれる。一般に、ページのサイズは、多様性にとんでいるが、本発明では、ページのサイズのほうが、フラッシュメモリの消去単位であるブロックのサイズより大きいものとする。一方、フラッシュメモリにおいては、一般的に、消去の単位は、前述したようにブロックと呼ぶのに対し、ブロックの中での読み書きの単位をページとよぶ。当然、フラッシュメモリにおいては、ブロックのサイズのほうが、ページサイズより大きくなる。しかし、本発明では、ページという言葉は、容量仮想化におけるページをさすことにする。また、繰り返しになるが、本発明においては、ページのサイズは、フラッシュメモリのブロックのサイズよりも大きいとする。

0005

ただし、本発明の対象となるストレージシステムは、上記の容量仮想化技術をもっていることが必ずしも必要条件とはならない。一方、容量仮想化技術をもったストレージステムにおいては、ページ単位で、ページを記憶装置(典型的には、HDD(Hard Disk Drive))の間で移動させ、性能向上を実現させる技術が、公開されている(特許文献2)。さらに、価格性能比がことなる記憶装置間で、ページを移動させ、価格性能比を向上させる技術も公開されている。一方、通常、HDDには、ユーザのデータを格納する前に、特定のパターン、例えば、オール0などでフォーマティングする。この際、ホストが書き込むこの特定パターンを、ストレージシステムで検出して、すでに割り当てているページを解放する技術も公開されている(特許文献3)。

先行技術

0006

日本国特許3507132
特開2007−66259号公報
特開2007−199922号公報

発明が解決しようとする課題

0007

本発明の対象となるフラッシュメモリを記憶媒体とする大容量ストレージシステムにおいては、フラッシュメモリチップの数は、例えば数万に及ぶ。このため、数百のチップを搭載したフラッシュパッケージを数百枚、ストレージシステムのコントローラに接続するのが典型的な構成となる。

0008

本発明において解決しようとする課題は、第1に、多数のフラッシュメモリチップを記憶媒体として構成する大規模ストレージシステムにおいて、ストレージシステム全体で、フラッシュメモリの消去回数の偏りを効率的に少なくすることであり、第2に、フラッシュメモリへの格納データ容量を削減することである。まず、第1の課題について述べる。フラッシュメモリを搭載したストレージシステムにおいては、ウエアレベリング技術が大変重要になる。しかし、本発明の対象となる数万のフラッシュメモリを有するストレージシステムにおいて、従来のウエアレベリングの考え方を、そのまま適用すると、数万個のすべてのフラッシュメモリチップのブロック消去回数の偏りを少なくしようとするので、ウエアレベリングの制御オーバヘッドが大きくなってしまうという課題があった。

0009

第2の課題について説明する。容量仮想化技術を適用したストレージシステムにおいては、データの書き込みが行われると、ページを確保することになる。したがって、ページサイズを小さくしたほうが、容量の削減効果は大きいことになる。ただ、本技術を適用すると、ホストから見て連続しているボリュームのアドレスが、ページごとに、HDD上でバラバラに格納される可能性がでてくる。通常、HDDの連続した領域へのアクセス(シーケンシャルアクセス)は、バラバラな領域へのアクセス(ランダムアクセス)に比較すると格段に高速になるので、ホスト上のアプリションソフトは、この性能差を意識して構築される。したがって、容量仮想化を導入しても、シーケンシャルアクセスに対する性能を維持しようとすると、ページサイズをある程度より、大きくする必要があった。このため、容量の削減効率が十分でないという課題があった(すでに述べたように、本発明では、ページのサイズは、フラッシュメモリのブロックのサイズよりも大きいとしている)。

課題を解決するための手段

0010

前記第1の課題を解決するための、本発明の第1の特徴は、階層的なウエアレベリングを行う点である。すなわち、上位レベルのウエアレベリングと下位レベルのウエアレベリングにより構成される点が特徴となる。階層化することで、効率的に、ストレージシステム全体の数万個のすべてのフラッシュメモリチップのブロック消去回数の偏りを少なくす
ることができる。本発明の第1の特徴では、階層的なウエアレベリングを行う点であるので、上位レベルのウエアレベリングの単位を特に規定しない。(任意の単位である。)。下位レベルのウエアレベリングは、複数のチップ(例えば数百のチップ)を搭載したフラッシュパッケージ上のブロック消去回数の偏りを少なくしようとするウエアレベリングであり、特許文献1のような公知技術を適用してよい。基本的には、下位レベルのウエアレベリングの単位は、フラッシュメモリの消去単位であるブロックであるのが一般的である。なお、一つのフラッシュパッケージを一つのSSD(Solid State Drive)としても、本発明は有効である。フラッシュパッケージがプロセッサをもつ場合、下位レベルのウエアレベリングは、当該プロセッサがそのパッケージ内のフラッシュメモリのブロックの消去回数の偏りを少なくするのが一つの方法である。ただし、ストレージシステムのコントンローラプロセッサで、下位レベルのウエアレベリングを行ってもよい。一方、本発明の第2の特徴は、上位レベルのウエアレベリングを、ストレージシステムの容量仮想化のために導入した、ベージ単位で行う点である。(これは、本発明の第1の特徴を実現するだけであれば、ストレージシステムのコントローラが、容量仮想化機能をもつことが必須の条件ではないことを意味している。)一方で、容量仮想化を実現しているストレージシステムにおいては、ページ単位での移動制御を行うのが今後の潮流となっており、フラッシュメモリの上位レベルのウエアレベリングをページとすることにより、このページ単位制御の一環とすることができるメリットが大きい。また、ページというブロックより大きなサイズでウエアレベリングを行うことにより、オーバヘッドを少なくできる。

0011

また、本発明における上位レベルのウエアレベリングでは、ブロック消去回数の偏りを少なくしてもよいし、ブロック消去回数が限界数に達するまでの予測時間がある一定時間以上になるように制御してもよい。

0012

第2の課題の解決を狙った、本発明の第3の特徴は、階層的な容量仮想化を実現する点である。上位レベルの容量仮想化は、従来のように、ストレージシステムのコントローラで実現し、ホストに仮想容量を適用する。したがって、第2の課題を解決する本発明の第3の特徴は、下位レベルの容量仮想化であり、フラッシュパッケージの容量を仮想化し、実際、フラッシュパッケージがもっているフラッシュメモリの容量より大きな容量を仮想容量として定義し、下位レベルで、データを書き込もうとしたとき、ブロックを割り当てられているかどうかをチェックして、いないとき初めてブロックを割り当てることが本発明の特徴である。これにより、実際に割り当てる契機を遅らせることができ、割り当てる容量もページに比べブロックという小さいサイズにすることができる。また、フラッシュメモリの特質として、ランダムアクセスもシーケンシャルアクセスも性能差が、ほとんどないため、割り当てサイズを小さくしても性能上の問題がほとんどない。

0013

また、本発明の課題2を解決する第4の特徴として、オール0などのフォーマット情報を認識した場合も、下位レベルの容量仮想化機能で、ブロック単位の解放を行い、容量の削減効果を可能にする。ただし、フラッシュメモリの特性として、解放を行うブロックを他の領域に割り当てるには、一度、消去する必要がある。なお、通常のWriteコマンドで、オール0などのフォーマットパターンを書き込んだ場合にも、ストレージシステムで、フォーマットパターンを認識して、対応するブロックを解放させ、容量削減を図ることも可能である。下位レベルの容量仮想化は、フラッシュパッケージがプロセッサをもつ場合、当該プロセッサがそのパッケージ内の容量を仮想化するのが、一つの方法である。ただし、ストレージシステムのコントンローラプロセッサで、下位レベルの容量仮想化を行ってもよい。また、記憶媒体をフラッシュメモリとし、実容量より大きい仮想容量を持ち、消去単位であるブロックを割り当て単位とした、容量仮想化機能を、従来の上位レベルの容量仮想化機能なしに、ホストに提供してもよい。

発明の効果

0014

本発明によれば、それぞれが多数のフラッシュメモリを実装したフラッシュパッケージを多数接続した大容量のストレージシステムにおいて、効率的なウエアレベリングを実現できる。さらに、従来技術に比べ、性能劣化をほとんど招かずに、データ格納容量の削減も可能となる。

図面の簡単な説明

0015

図1は、本発明の一実施形態に係るストレージシステム100を有する情報 システムを示す図である。
図2は、ストレージシステム100の構成を示す図である。
図3は、フラッシュパッケージ230の構成を示す図である。
図4は、共有メモリ220に記憶される情報を示す図である。
図5は、論理ボリューム情報2000を示す図である。
図6は、スケジュール情報2700を示す図である。
図7は、実ページ情報2100を示す図である。
図8は、本発明の一実施形態における複数種類の記憶領域の対応関係を示す 図である。
図9は、空きページ管理情報ポインタ2200によって管理される空きペー ジの集合を表した図である。
図10は、パッケージグループ情報2300を示す図である。
図11は、フラッシュパッケージ情報2500を示す図である。
図12は、パッケージメモリ320に記憶される管理情報を示す図である 。
図13は、図12に示した管理情報と同様の管理情報が共有メモリ160 に記憶された例を示す図である。
図14は、パッケージ情報3000を示す図である。
図15は、チップ情報3100を示す図である。
図16は、仮想ブロック情報3200を示す図である。
図17は、実ブロック情報3300を示す図である。
図18は、空きブロック情報ポインタ3400によって管理される空きブロックの集合を表した図である。
図19は、メモリ270に格納されたプログラムを示す図である。
図20は、リード処理実行部4000の処理フローを示す図である。
図21は、ライト要求受付部4100の処理フローを示す図である。
図22は、ライトアフタ処理実行部4200の処理フローを示す図である 。
図23は、ライトセイムコマンド処理実行部4300の処理フローを示す 図である。
図24は、ページ移動スケジュール部4400の処理フローを示す図であ る。
図25は、ページ移動処理実行部4500の処理フローを示す図である。
図26は、パッケージメモリ320に格納されているプログラムを示す図 である。
図27は、下位レベルのプログラムがメモリ270に格納された例を示す 図である。
図28は、データリード処理実行部12000の処理フローを示す図であ る。
図29は、データライト処理実行部12100の処理フローの一部を示す 図である。
図30は、データライト処理実行部12100の処理フローの残りを示す 図である。
図31は、実ブロック解放処理実行部12200の処理フローを示す図で ある。
図32は、仮想ブロック移動処理実行部12300の処理フローを示す図 である。
図33は、仮想ブロック格納処理実行部12400の処理フローを示す図 である。

実施例

0016

以下、図面を参照して、本実施形態を詳細に説明する。

0017

図1は、本発明の一実施形態に係るストレージシステムを有する情報システムを示す。

0018

情報システムは、ストレージシステム100と、ホスト110と、それらを接続するSAN(Storage Area Network)120とを有する。ホスト110は、ストレージシステム100に、SAN120経由で、データの読み書きを行う。図1には、示してはいないが、ストレージシステム100は、SAN経由で、別のストレージシステム100と接続されていて、ストレージシステム100の間で、ディザスタリカバリに対応したリモートコピー機能を実行してもよい。

0019

ホスト110は、ユーザアプリケーションが動作するシステム(例えば計算機)である。ホスト110は、SAN120を介して、ストレージステム100が提供する論理ボリュームにアクセスする。論理ボリュームは、前述した上位レベルの容量仮想化に従う論理ボリューム(複数の仮想ページで構成されたボリューム)であってもよいし、通常の論理ボボリュームであってもよい。ただし、以下では、容量仮想化にしたがう論理ボリュームを前提に説明する。なお、SAN120では、SCSI(Small Computer System Interface)コマンドが転送可能なプロトコル(例えば、Fibre Channel等のプロトコル)が用いられる。

0020

本実施形態は、多数のフラッシュメモリを記憶媒体として構成するストレージシステム100において、第1の技術として、フラッシュメモリの消去回数の偏りを少なくしようとする技術、および、第2の技術として、フラッシュメモリへの格納データ容量削減技術を実現するものである。第1の技術は、階層型ウエアレベリング技術であり、第2の技術は、階層型容量仮想化技術である。本実施形態では、階層型のウエアレベリング技術、階層型の容量仮想化技術の双方を実現しているが、本発明は、それぞれ単独に、階層型のウエアレベリングング技術だけ、階層型の容量仮想化技術だけを実現しても有効である。また、本実施形態においては、上位レベルのウエアレリング技術、容量仮想化技術の制御単位は、ページとよばれる単位である。本実施形態におけるページは、従来の特許文献2に示される容量仮想化技術で開示されているページである。なお、以下の説明では、階層型ウエアレベリングにおける上位レベルの制御単位は、ページであるが、本発明は、その制御単位がページでなくとも有効である。例えば、上位レベルのウエレベリングの制御単位を、下位レベルの制御単位と同じように、フラッシュメモリの消去単位であるブロックを基本にしてもよい。本実施形態では、ページのサイズは、フラッシュメモリにおける消去単位であるブロックよりも大きい。通常、フラッシュメモリにおいては、リード・ライトの単位をページと呼ぶので、ページはブロックよりも小さい。しかし、すでに述べたように、本実施形態では、ページは、容量仮想化技術示されるページを意味しており、そのサイズは、ブロックよりも大きい。また、下位レベルのウエアレリング技術、容量仮想化技術の制御単位は、基本的には、フラッシュメモリの消去単位である1つのブロックであるが、ブロックの整数倍の単位としてもよい。ただし、本実施形態では、1つのブロックを制御単位とすることを前提にして、説明を行う。また、本発明は、記憶媒体をフラッシュメモリとし、実容量より大きい仮想容量を持ち、消去単位であるブロックを割り当て単位とした、下位レベルの容量仮想化機能を、単独に、従来の上位レベルの容量仮想化機能なしに、ホスト110に提供しても有効である。また、本実施形態においては、フラッシュメモリの消去回数の偏りを少なくしようとする技術に加えて、フラッシュメモリの寿命を所定の期間より延ばそうという技術を実現している。このため、ウエアレベリング機能については、さらに広い技術が加わったことを考慮して、長寿命化制御とも呼ぶ。

0021

図2は、ストレージシステム100の構成を示す。

0022

ストレージシステム100は、複数のフラッシュパッケージ230と、一以上のストレージコントローラ200と、キャッシュメモリ210と、共有メモリ220と、タイマ240と、これらの構成要素を接続する一以上の接続装置250とを有する。なお、一つのフラッシュパッケージ230が、1つのSSD(Solid State Drive)であっても、本発明は有効である。また、フラッシュパッケージ230に加えて、ハードディスクドライブ(HDD)などが備えられても良い。なお、本発明において、上位レベルの長寿命化制御(ウエアレベリング機能)と容量仮想化機能は、ストレージコントローラ200が実行する。一方、下位レベルの長寿命化制御(ウエアレベリング機能)と容量仮想化機能は、ストレージコントローラ200が実行しても、フラッシュパッケージ230が実行してもよい。ただし、本実施形態では、フラッシュパッケージ230が実施する形態を、中心に説明を行う。

0023

タイマ240は、すべてのストレージコントローラ200から参照可能である。タイマ240が表す情報は、時刻である必要は無く、例えば、経過時間に相当する値を示すかカウント値でもよい。

0024

全てのフラッシュパッケージ230の記憶容量(実ブロックの総記憶容量)が等しい必要は無いが(すなわち、記憶容量の異なるフラッシュパッケージ230が混在していても良いが)、本実施形態では、全てのフラッシュパッケージ230の記憶容量(実ブロックの総記憶容量)が等しいとする。

0025

ストレージコントローラ200は、SAN120を通じて、ホスト110から、ライト要求及びそれに付随するデータ、又は、リード要求受け付ける。ストレージコントローラ200は、メモリ270とプロセッサ260とを有する。メモリ270は、プログラム及び情報を記憶する。プロセッサ260は、メモリ270に記憶されているコンピュータプログラムを実行する。

0026

接続装置250は、ストレージシステム100内の各構成要素を接続する装置(例えばクロスバスイッチ)である。本実施形態では、各ストレージコントローラ200及び各フラッシュパッケージ230が複数の接続装置250に接続されている。しかし、必ずしも複数の接続装置250に接続されている必要はなく、例えば、一つのフラッシュパッケージ230及び/又は一つのストレージコントローラ200が一つの接続装置250にしか接続されていなくても良い。

0027

キャッシュメモリ210及び共有メモリ220は、揮発メモリ(例えばDRAM(Dynamic Random Access Memory)で構成されるが、バッテリーなどにより不揮発化されている。ただし、キャッシュメモリ210が不揮発化されていなくても本発明は有効であるし、共有メモリ220が、不揮発化されていなくとも本発明は有効である。また、キャッシュメモリ210が二重化さていてもよいし、共有メモリ220が二重化されていてもよい。キャッシュメモリ210には、例えば、フラッシュパッケージ230に格納されたデータの中で、ストレージコントローラ200から頻繁にアクセスされるデータが格納される。ストレージコントローラ200は、ホスト110から受け付けたライト要求に付随するデータをキャッシュメモリ210に書き込んだ時点で、ライト処理の完了としても良いし、そのデータをキャッシュメモリ210からフラッシュパッケージ230に格納した時点でライト処理の完了としても良い。共有メモリ220は、キャッシュメモリ210の制御情報、ストレージシステム100に関する管理情報などを記憶する。

0028

フラッシュパッケージ230は、ストレージコントローラ200からは、一台の記憶装置に見えているものとする。ストレージコントローラ200が、高信頼化のために、所定数(例えば一台又は二台)のフラッシュパッケージ230が故障してもそのフラッシュパッケージ230のデータを回復できるRAID(Redundant Array of Independent (or Inexpensive) Disks)機能を有する。(なお、‘RAID’という用語の’D’は’Disk’の略であるが、ある記憶装置に障害が発生したときに、別の記憶装置の冗長データなどから故障した装置のデータを復元する機能は、Disk以外の記憶装置にも適用可能である。)RAID機能がある場合、複数のフラッシュパッケージ230で一つのRAID構成が構築される。そのRAID構成に従うグループを、以下、「パッケージグループ」と呼ぶ。ストレージシステム100はRAID構成を有していなくても良い。

0029

図3は、フラッシュパッケージ230の構成を示す。

0030

フラッシュパッケージ230は、複数のフラッシュチップ300と、パッケージコントローラ315とを有する。

0031

パッケージコントローラ315は、パッケージプロセッサ310と、パッケージメモリ320と、バッファ330と、パッケージバス340と、パッケージバス転送装置350とを有する。パッケージプロセッサ310は、ストレージコントローラ200からのライト指示リード指示を処理する。

0032

バッファ330は、ストレージコントローラ200とフラッシュチップ300との間で読み書きされるデータを格納する。本実施形態では、バッファ330は揮発メモリである。ストレージコントローラ200から受けたライト指示の処理は、そのライト指示に従うデータがフラッシュチップ300に書き込まれた時点で完了となる。ただし、バッファ330が、不揮発化されていて、ストレージコントローラ200へのライト指示の完了報告の後、データをフラッシュチップ300に書き込んでも、本発明は有効である。パッケージメモリ320には、パッケージプロセッサ310が実行するコンピュータプログラム、フラッシュパッケージ230の管理情報が格納される。ただし、パッケージメモリ320が不揮発化されていても本発明は有効である。

0033

パッケージバス340は、バッファ330とフラッシュチップ300との間でデータ転送を行うバスで、一本以上存在する。一本のパッケージバス340に、一つ以上のフラッシュチップ300が接続される。

0034

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

0035

図4は、共有メモリ220に記憶される情報を示す。

0036

共有メモリ220は、例えば、論理ボリューム情報2000、スケジュール時間情報2700、実ページ情報2100、空きページ管理情報ポインタ2200、パッケージグループ情報2300、フラッシュパッケージ情報2500及び仮想ページ容量2600を記憶する。これらの情報は、上位レベルの長寿命化制御と、上位レベルの容量仮想化機能とに必要である。

0037

仮想ページ容量2600は、仮想ページの容量を表す情報である。なお、仮想ページの容量(サイズ)と実ページの容量(サイズ)は等しくないことがある。例えば、仮想ページの容量と実ページの容量との関係は、RAID構成に依存する。具体的には、例えば、RAID1のようにデータを2重に書き込む場合、実ページの容量は、仮想ページの容量の2倍になる。また、例えば、RAID5のように、N台の記憶装置の容量に対し1台分の記憶装置の容量の冗長データを格納する場合、実ページの容量は、仮想ページの容量の(N+1)/Nの容量である。また、例えば、RAID0のように、冗長性がない場合、実ページの容量は、仮想ページの容量と等しい。なお、本実施形態においては、仮想ページ容量2600はストレージシステム100の中で共通であるが、ストレージシステム100に仮想ページ容量2600に異なったものがあっても、本発明は有効である。

0038

本実施形態では、ストレージステム100は、前述した上位レベルの容量仮想化機能を有するが、その機能を必ずしも有していなくても良い。上位レベルの容量仮想化機能について、記憶領域の割り当て単位は「ページ」であり、下位レベルの容量仮想化機能について、記憶領域の割り当て単位は「ブロック」である。

0039

図8は、複数種類の記憶領域の対応関係を示す。

0040

本実施形態においては、それぞれのフラッシュパッケージ230は、容量仮想化機能をもっており、ストレージコントローラ200には、見かけ上、実際の物理容量より大きな容量を提供している。フラッシュパッケージ230の容量仮想化の単位は、本実施形態では、フラッシュメモリの消去単位であるブロックとする。以下、ストレージコントローラ200から見たブロックを「仮想ブロック」と呼び、フラッシュパッケージ230が、実際に割り当てているブロックを「実ブロック」と呼ぶ。したがって、本実施形態では、実ページは、仮想ブロックにより構成されることになる。また、本実施形態では、仮想ブロックにより構成される容量空間のほうが、実ブロックにより構成される容量空間より大きいことになる。図8は、仮想ページ、実ページ、仮想ブロック、実ブロックの関係を示したものである。すでに述べたように、実ページには、仮想ページにはない、冗長データが含まれている。一方、仮想ブロック、実ブロックに含まれるデータは同じである。また、本実施形態では、フラッシュパッケージ230は、実ブロック数より多くの仮想ブロックをもっているように、ストレージコントローラ200に見せていることになる。ただし、本実施形態では、ストレージコントローラ200は、実際にフラッシュパッケージ230がいくつの実ブロックをもっているかを意識して、実ページの再配置を行う。本実施形態では、フラッシュパッケージ230が、まだ実ブロックを割り当てていない仮想ブロックに、書き込み要求を受け付けたとき、実ブロックを割り当てることが特徴である。

0041

以下、ストレージコントローラ200から実ブロックへのアクセスの流れを説明する。なお、ストレージコントローラ200は、どの仮想ページにどの実ページが割り当てられているかの対応関係(ページ対応関係)を管理している。ただし、以下では、下位レベルの長寿命化制御(ウエアレベリング機能)と容量仮想化機能は、フラッシュパッケージ230が実施する形態で説明を行う。

0042

ストレージコントローラ200は、ホスト110からライト要求を受けた場合、そのライト要求から特定される仮想ページ(ライト先の仮想ページ)に実ページが割り当てられているか否かをページ対応関係を基に判断する。その判断の結果が否定的の場合、ストレージコントローラ200は、ライト先の仮想ページに未割当ての実ページを割り当て、割り当てた実ページに、ライト要求に付随するデータを書き込む。

0043

ストレージコントローラ200は、実ページにデータを書き込む場合、その実ページに基づくアドレスを指定したライト指示を、そのアドレスを管理するパッケージコントローラ315に送信する。そのライト指示を受けたパッケージコントローラ315が、ブロック対応関係を基に、そのライト指示で指定されているアドレスを有する仮想ブロック(ライト先の仮想ブロック)に実ブロックが割り当てられているか否かを判断する。その判断の結果が否定的の場合に、パッケージコントローラ315は、ライト先の仮想ブロックに未割当ての実ブロック(空きの実ブロック)を割当て、割り当てた実ブロックに、そのライト指示の対象のデータを書き込む。

0044

ストレージコントローラ200は、ホスト110からリード要求を受けた場合、そのリード要求から特定される仮想ページ(リード元の仮想ページ)に割り当てられている実ページをページ対応関係を基に特定する。ストレージコントローラ200は、特定された実ページからデータを読み出し、読み出したデータをホスト110に送信する。

0045

ストレージコントローラ200は、実ページからデータを読み出す場合、その実ページに基づくアドレスを指定したリード指示を、そのアドレスを管理するパッケージコントローラ315に送信する。そのリード指示を受けたパッケージコントローラ315が、そのリード指示で指定されているアドレスを有する仮想ブロックに割り当てられている実ブロックをブロック対応関係を基に特定する。パッケージコントローラ315が、特定された実ブロックからデータを読み出し、そのデータをストレージコントローラ200に送信する。

0046

なお、例えばNAND型のフラッシュメモリでは、一般に、消去単位は「ブロック」と呼ばれ、書込み単位は「ページ」と呼ばれる。具体的には、複数の物理セクタで一つの物理ページが構成され、複数の物理ページで一つの実ブロックが構成される。しかし、本実施形態で言う「ページ」は、上位レベルの容量仮想化機能が行う領域割当ての単位であることは明らかであり、何ら混同は生じない。

0047

さて、以下、図4に示した各種情報を詳細に説明する。

0048

図5は、論理ボリューム情報2000を示す。

0049

論理ボリュームは、ホスト110からアクセスされる論理的な記憶装置である。ホスト110から発行されるアクセス要求は、論理ボリュームのID(例えばLUN(Logical Unit Number))と、論理ボリューム内のアドレス(例えばLBA(Logical Block Address))と、書き込む又は読み出すデータの長さとを含む。論理ボリュームのIDからアクセス先の論理ボリュームが特定され、アドレスとデータの長さとから、その論理ボリュームにおけるアクセス先の一以上の仮想ページが特定される。

0050

論理ボリューム情報2000は、論理ボリュームごとに存在する情報である。以下、一つの論理ボリューム(図5の説明において「対象ボリューム」と言う)を例に採り、情報2000を説明する。

0051

情報2000は、論理ボリュームID2001、論理容量2002、論理RAIDタイプ2003、実ページポインタ2004及びフォーマット情報2005を含む。

0052

論理ボリュームID2001は、対象ボリュームのIDである。

0053

論理容量2002は、ホスト110から見た対象ボリュームの容量を表す。

0054

論理RAIDタイプ2003は、対象ボリュームに対応したRAID構成のタイプ(RAIDタイプ(例えば、RAID0、RAID1))を表す情報である。なお、RAIDタイプが、N台の記憶装置に対し所定台数分の冗長データが格納されるタイプ(例えば、RAID5、RAID6)である場合、Nの具体的数値が情報2003に含まれる。ただし、任意のRAIDタイプが指定できるわけでなく、少なくとも一つのパッケージグループ280がもつRAIDタイプである必要がある。

0055

実ページポインタ2004は、対象ボリュームの仮想ページに割り当てた実ページ情報2100へのポインタである。実ページポインタ2004の数は、対象ボリュームが有する仮想ページの数(例えば、論理ボリューム容量2002を仮想ページ容量2600で割った数、もし余りがでれば+1)である。最初の実ページポインタ2004に対応する実ページが、対象ボリュームの先頭の仮想ページに割り当てられた実ページである。以降、次の実ページポインタ2004には、次の仮想ページに割り当てられた実ページに対応するポインタが格納される。上位レベルの容量仮想化機能によれば、実ページが割り当てられるのは、対象ボリュームを定義された契機ではなく、仮想ページを指定したライト要求を受けた契機(仮想ページにライトが発生した契機)である。したがって、まだライトが発生していない仮想ページに対応した実ページポインタ2004は、未割当てを意味する情報(例えばヌル値)になっている。

0056

フォーマット情報2005も、対象ボリュームの仮想ページ毎に存在する情報である。ホスト110は、アプリケーションプログラムのデータを格納する前に、特定の情報(例えば前述したパターンデータ)で記憶装置(例えば論理ボリューム)を初期化することが多い。パターンデータは、一般的なライト要求に付随することもあれば、明示的な要求(以下、ライトセイムコマンド)に付随することもある。パターンデータ(繰り返し情報)を、フォーマット情報2005に含めることで、その情報2005に対応した仮想ページにそのパターンデータが格納されていると認識することができる。このため、パターンデータが格納されている仮想ページに対する実ページの割当てを解除する(その実ページを解放する)ことができる。本実施形態では、ライトセイムコマンドをストレージコントローラ200が受信した場合、下位レベルの容量仮想化機能(例えばパッケージコントローラ315)に、ライトセイムコマンドで指定された仮想ページに割り当てられている実ページに対応した仮想ブロックを通知する(具体的には、その仮想ブロックを指定した解放指示が送信される)。その解放指示で指定された仮想ブロックに対する実ブロックの割当てが、解除される(解放される)。これにより、消費記憶容量が節約される。なお、通常のライト要求に応答してパターンデータ(例えばオール0などのフォーマットデータ)が書き込まれる場合にも、ストレージコントローラ200が、パターンデータを認識して、下位レベルの容量仮想化機能に、パターンデータのライト先の論ブロックに対する実ブロックを解放させても良い。また、フォーマット情報2005を設定した場合、そのフォーマット情報2005に対応した仮想ページに実ページを割り当てる必要はないので、その仮想ページに対応した実ページポインタ2004は、未割当てを意味する情報(例えばヌル値)となる。フォーマット情報2005に格納されたパターンデータ以外のデータがライト対象である場合には、ライト先の仮想ページに実ページが割り当てられるので、フォーマット情報2005が、無効な情報(例えばヌル値)になる。

0057

図6は、スケジュール情報2700を示す。

0058

本実施形態では、上位レベルの長寿命化制御は、所定のスケジュールに従って開始される。情報2700は、前回スケジュール時刻2701と次回スケジュール時刻2702とを含む。

0059

前回スケジュール時刻2701は、上位レベルの長寿命化制御が最近実行された時刻(
過去)である。

0060

次回スケジュール時刻2702は、上位レベルの長寿命化制御が次に実行される予定時刻(将来)である。

0061

なお、上位レベルの長寿命化制御は、所定のスケジュールに代えて又は加えて、任意の時点に実行されても良い。例えば、ストレージコントローラ200がユーザから上位レベルの長寿命化制御の実行を要求されたとき、及び、実ページに対するライト(実ブロックに対するライト)に失敗したときなどのうちの少なくとも一つのときに実行されて良い。

0062

図7は、実ページ情報2100を示す。

0063

情報2100は、実ページの管理情報であり、実ページごとに存在する。以下、一つの実ページ(図7の説明において「対象実ページ」)を例に採り、情報2100を詳細に説明する。

0064

情報2100は、パッケージグループ2101、実ページアドレス2102、空きページポインタ2103、実ブロック割り当て数2104、追加実ブロック割り当て数2105、累積実ブロック割り当て時間2106、累積実ブロック消去回数2107、追加実ブロック割り当て時間2108、移動中フラグ2109、移動先実ページ情報2110、移動待ちフラグ2111及び累積ライトデータ量2112を含む。

0065

パッケージグループ2101は、対象実ページがどのパッケージグループ280に基づく実ページであるかを示す情報であり、例えば、対象実ページの基になっているパッケージグループ280の識別子(パッケージグループID)である。

0066

実ページアドレス2102は、対象実ページの基になっているパッケージグループ280のうちのどの相対的なアドレスに対象実ページが割り当てられているかを示す情報である。

0067

空きページポインタ2103は、対象実ページが仮想ページに割り当てられていない場合に有効な値となる。この場合、その有効な値は、仮想ページに割り当てられていない別の物理ページに対応した空きページ情報2100を指している。対象実ページに仮想ページが割り当てられている場合、空きページポインタ2103はヌル値となる。

0068

実ブロック割り当て数2104、及び、追加実ブロック割り当て数2105は、対象実ページの基になっているパッケージグループ280が有するフラッシュパッケージ230の数だけ存在する。

0069

本実施形態では、それぞれのフラッシュパッケージ230のパッケージコントローラ315は、下位レベルの容量仮想化機能を有する。そのため、ストレージコントローラ200には、見かけ上、実際の物理容量より大きな仮想容量が提供されている。フラッシュパッケージ230の容量仮想化の単位は、前述の通り「ブロック」である。図8で説明した通り、実ページに複数の仮想ブロックが割り当てられ、各仮想ブロックに実ブロックが割り当てられる。したがって、実ページは複数の仮想ブロックから構成されていると言うことになる。また、本実施形態では、仮想ブロックにより構成される容量空間のほうが、実ブロックにより構成される容量空間より大きい。

0070

すでに述べたように、本実施形態では、実ページには、仮想ページに対するデータには含まれてない冗長データが格納されることがある。一方、仮想ブロックに対するデータと
実ブロックに格納されるデータは同じである。また、本実施形態では、フラッシュパッケージ230は、実ブロック数より多くの仮想ブロックをもっているように、ストレージコントローラ200に見せていることになる。ただし、本実施形態では、ストレージコントローラ200は、フラッシュパッケージ230が実際にいくつの実ブロックをもっているかを意識して、実ページの再配置を行う。

0071

下位レベルの長寿命化制御(ウエアレベリング機能)と容量仮想化機能を、フラッシュパッケージ230が実施する形態の場合、ストレージコントローラ200が、対象実ページにデータを書き込む際には、対象実ページに割り当てられている仮想ブロック内のアドレスを指定したライト指示を、その仮想ブロックを管理するフラッシュパッケージ230に送信する。フラッシュパッケージ230は、そのライト指示で指定されている仮想ブロックにまだ実ブロックが割り当てられていない場合、その仮想ブロックに実ブロックを割り当てる。新たに実ブロックが割り当てられた場合、パッケージコントローラ315は、新たに実ブロックが割り当てられたことを、ストレージコントローラ200に通知する。これにより、ストレージコントローラ200は、対象実ページに実ブロックが割り当てられたことを検知し、実ブロック割り当て数2104あるいは追加実ブロック数2105を更新する。

0072

実ブロック割り当て数2104は、その情報2104に対応するフラッシュパッケージ230が有し、対象実ページに割り当てられている実ブロックのうちの、前回スケジュール時刻2701以前に対象実ページに割り当てられた実ブロックの数である。なお、「前回スケジュール時刻2701以前」とは、前回スケジュール時刻2701を含んでも含まなくても良い。

0073

追加実ブロック数2105は、その情報2105に対応するフラッシュパッケージ230が有し、対象実ページに割り当てられている実ブロックのうちの、前回スケジュール時刻2701以降に対象実ページに割り当てられた実ブロックの数である。なお、「前回スケジュール時刻2701以降」とは、前回スケジュール時刻2701を含んでも含まなくても良い。例えば、「前回スケジュール時刻2701以前」が前回スケジュール時刻2701を含む場合、「前回スケジュール時刻2701以降」は前回スケジュール時刻2701を含まず、一方、「前回スケジュール時刻2701以前」が前回スケジュール時刻2701を含まない場合、「前回スケジュール時刻2701以降」は前回スケジュール時刻2701を含む。

0074

累積実ブロック割り当て時間2106、累積実ブロック消去回数2107、及び、追加実ブロック割り当て時間2108、累積ライトデータ量2112も、それぞれ、対象実ページの基になっているパッケージグループ280が有するフラッシュパッケージ230の数だけ存在する。ただし、これらの情報は、対象実ページに含まれる仮想ブロックの属性情報ではなく、対象実ページの割当先の仮想ページに対するデータに関する属性情報である。したがって、その仮想ページに、対象実ページに代えて別の実ページが割り当てられ、対象実ページ内のデータがその別の実ページに移動された場合、累積実ブロック割り当て時間2106、累積実ブロック消去回数2107、及び、追加実ブロック割り当て時間2108、累積ライトデータ量2112も、その別の実ページの管理情報として引き継がれる。

0075

累積実ブロック割り当て時間2106は、対象実ページに割り当てられているすべての仮想ブロックについての経過時間の合計である。ここで言う「経過時間」とは、対象実ページに割り当てられている仮想ブロックに実ブロックが割り当てられた契機から前回スケジュール時間2701までの、その仮想ブロックについての時間である。なお、その契機は、対象実ページについてではなく、過去に別の実ページについて起こった可能性もある。

0076

累積実ブロック消去回数2107は、対象実ページに割り当てられているすべての仮想ブロックについての消去回数の合計である。ここで言う「消去回数」とは、対象実ページに割り当てられている仮想ブロックに実ブロックが割り当てられた契機からの、その実ブロックの消去回数である。

0077

累積ライトデータ量2112は、累積実ブロック消去回数2107の代わりに(又は加えて)、実ページ情報2100に含まれる情報である。累積ライトデータ量2112は、対象実ページの基になっているパッケージグループ280が有するフラッシュパッケージ230の数だけ存在し、対象実ページの割当先の仮想ページに対するデータに関する属性情報である。累積ライトデータ量2112は、対象実ページに割り当てられているすべての仮想ブロックについてのライトデータ量の合計である。ここで言う「ライトデータ量」とは、対象実ページに割り当てられている仮想ブロックに実ブロックが割り当てられた契機からの、仮想ブロックが割り当てられていた実ブロックのライト対象データの量(サイズ)である。累積ライトデータ量2112を基に、累積実ブロック消去回数2107に相当する値を算出することが可能である。詳細は後述する。

0078

追加実ブロック割り当て時間2108は、前回スケジュール時間2701以降に仮想ブロックに割り当てられた実ブロックが割り当てられている時間長である。実ブロックが新たに一つ割り当てられると、追加実ブロック割り当て時間2108には、次回スケジュール時間2702と割り当てを行った時刻との差分に相当する時間長(差分時間)が加算される。この差分時間を加算する理由については、後で説明する。

0079

移動中フラグ2109、移動先実ページ情報2110、及び、移動待ちフラグ2111は、対象実ページ内のデータを別の実ページに移動するときに使用される情報である。移動中フラグ2109は、対象実ページ内のデータを別の実ページに移動中のときにONになるフラグである。移動先実ページ情報2110は、対象実ページ内のデータの移動先の実ページのアドレスを表す情報である。移動待ちフラグ2111は、対象実ページ内のデータを移動すると決定したときにONになるフラグである。

0080

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

0081

空きページ管理情報ポインタ2200は、パッケージグループ280ごとに設けられる情報である。

0082

「空きページ」とは、仮想ページに割り当てられていない実ページ(未割当ての実ページ)である。また、空きページに対応した実ページ情報2100を、「空きページ情報」と呼ぶ。空きページ管理情報ポインタ2200は、先頭の空きページ情報のアドレスをさす。次に、先頭の実ページ情報2100の中の空きページポインタ2103が、次の空きページ情報を指す。図9では、最後の空きページ情報の空きページポインタ2103は、空きページ管理情報ポインタ2200を示しているが、ヌル値でもよい。ストレージコントローラ200は、実ページが割り当てられていない仮想ページを指定したライト要求をホスト110から受け付けた場合、論理RAIDタイプ2003と同一のRAIDタイプを有するいずれかのパッケージグループ280(例えば、空きページ数の最も多いパッケージグループ280)から、空きページ管理情報ポインタ2200を基に空きページを探し、見つかった空きページを仮想ページに割り当てる。

0083

図10は、パッケージグループ情報2300を示す。

0084

パッケージグループ情報2300は、パッケージグループ280毎に存在する。以下、一つのパッケージグループ280(図10の説明において「対象パッケージグループ280」と言う)を例に採り、パッケージグループ情報2300を説明する。

0085

パッケージグループ情報2300は、パッケージグループID2301、パッケージグループRAIDタイプ2302、実ページ数2303、空きページ数2304及びフラッシュパッケージポインタ2305を含む。

0086

パッケージグループID2301は、対象パッケージグループ280の識別子である。

0087

パッケージグループRAIDタイプ2302は、対象パッケージグループ280のRAIDタイプである。本実施形態におけるRAIDタイプは、論理RAIDタイプ2003についての説明で述べたとおりである。

0088

実ページ数2303は、対象パッケージグループ280が有する実ページの数を表し、空きページ数2304は、対象パッケージグループ280が有する空きページの数を表す。

0089

フラッシュパッケージポインタ2305は、対象パッケージグループ280に属するフラッシュパッケージ230のフラッシュパッケージ情報2500へのポインタである。フラッシュパッケージポインタ2305の数は、対象パッケージグループ280が有するフラッシュパッケージ230の数と同じであるが、これは、パッケージグループRAIDタイプ2302によって決まる値である。

0090

図11は、フラッシュパッケージ情報2500を示す。

0091

フラッシュパッケージ情報2500は、フラッシュパッケージ230毎に存在する。以下、一つのフラッシュパッケージ(図11の説明において「対象フラッシュパッケージ」と言う)を例に採り、情報2500を説明する。

0092

情報2500は、フラッシュパッケージID2501、フラッシュパッケージ仮想容量2502、ブロック容量2503、パッケージ内割り当て可能実ブロック数2504、パッケージ内実ブロック割り当て数2505、パッケージ内追加実ブロック割り当て数2506、パッケージ内累積実ブロック割り当て時間2507、パッケージ内累積実ブロック消去回数2508、パッケージ内追加実ブロック割り当て時間2509、パッケージ内累積ライトデータ量2510、保証期間終了時刻2511及び限界消去回数2512を含む。

0093

フラッシュパッケージID2501は、対象フラッシュパッケージ230の識別子である。

0094

フラッシュパッケージ仮想容量2502は、対象フラッシュパッケージ230の仮想的な容量である。

0095

ブロック容量2503は、仮想ブロック及び実ブロックに含まれるデータの容量である。仮想ブロックに対するデータと実ブロックに格納されるデータは同じである。従って、フラッシュパッケージ容量2502をブロック容量2503で割った値が、対象プラッシュパッケージ230が有する仮想ブロックの数となる。

0096

割り当て可能実ブロック数2504は、対象フラッシュパッケージ230の中で割り当て可能な実ブロックの数である。フラッシュパッケージ230中で、例えばx個の実ブロックが障害状態不良ブロック)になると、割り当て可能実ブロック数2504が示す値からxが引かれる。下位レベルの長寿命化制御(ウエアレベリング機能)と容量仮想化機能を、フラッシュパッケージ230が実施する形態の場合、割り当て可能な実ブロックの数が減ると、パッケージコントローラ315から、ストレージコントローラ200に、割り当て可能な実ブロックの数が減ったことが通知される。

0097

パッケージ内実ブロック割り当て数2505は、対象パッケージグループ280に基づく全ての実ページについての実ブロック割り当て数2104の合計である。

0098

パッケージ内追加実ブロック割り当て数2506は、対象パッケージグループ280に基づく全ての実ページについての追加実ブロック割り当て数2105の合計である。

0099

パッケージ内累積実ブロック割り当て時間2507は、対象パッケージグループ280に基づく全ての実ページについての累積実ブロック割り当て時間2106の合計である。

0100

パッケージ内累積実ブロック消去回数2508は、対象パッケージグループ280に基づく全ての実ページについての累積実ブロック消去回数2107の合計である。

0101

パッケージ内追加実ブロック割り当て時間2509は、対象パッケージグループ280に基づく全ての実ページについての追加実ブロック割り当て時間2108の合計である。

0102

パッケージ内累積ライトデータ量2510は、対象パッケージグループ280に基づく全ての実ページについての累積ライトデータ量2112の合計である。ただし、累積ライトデータ量2512は、累積実ブロック消去回数2107の代わりに存在する情報で、必ずしも存在する情報ではない。

0103

保証期間終了時刻2511は、対象フラッシュパッケージ230の保障期間が終了する時間(時刻)である。

0104

消去限界数2512は、対象フラッシュパッケージ230の実ブロックの限界消去回数を表す。フラッシュメモリには、いくつかの種類があり、それぞれ限界消去回数が異なる。例えば、一般に、SLC(Single Level Cell)は約10万回、MLC(Multi Level Cell)は5千〜1万回と言われている。

0105

次に、フラッシュパッケージ230のパッケージメモリ320に記憶される、フラッシュパッケージ230の管理情報を説明する。

0106

図12は、パッケージメモリ320に記憶される管理情報を示す。

0107

その管理情報は、パッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300及び空きブロック情報ポインタ3400を含む。この管理情報は、下位レベルのウエアレベリング制御及び容量仮想化機能に利用される情報である。本実施形態では、フラッシュパッケージ230が、下位レベルの長寿命化制御(ウエアレベリング機能)を行い、且つ、下位レベルの容量仮想化機能を有する。下位レベルの長寿命化制御(ウエアレベリング機能)及び容量仮想化機能は、ストレージコントローラ200で実現されてもよい。この場合、例えば、図13に示すように、図12に示した管理情報とほぼ同様の管理情報が、共有メモリ220に格納される。図13に示した管理情報は、ストレージコントローラ200が参照及び更新するので、図12に示した管理情報
とは若干違っていて良い。

0108

本実施形態では、前述した通り、フラッシュパッケージ230が、下位レベルの長寿命化制御(ウエアレベリング制御)及び容量仮想化機能を実現し、図12に示した管理情報を保持する。以下その管理情報に含まれる情報3000、3100、3200、3300及び3400を詳細に説明する。

0109

図14は、パッケージ情報3000を示す。

0110

以下、一つのフラッシュパッケージ230(図14の説明において「対象フラッシュパッケージ」と言う)を例に採り、パッケージ情報3000を説明する。

0111

パッケージ情報3000は、パッケージID3001、仮想パッケージ容量3002、実パッケージ容量3003、フラッシュブロック容量3004、パッケージブロック容量3005、パッケージ割り当て可能ブロック数3006、パッケージ空きブロック数3007、障害ブロック数3008、内部情報格納ブロック数3009及び内部情報格納アドレス3010を含む。

0112

パッケージID3001は、対象フラッシュパッケージ230の識別子である。

0113

仮想パッケージ容量3002は、ストレージコントローラ200から見た対象フラッシュパッケージ230の仮想的な記憶容量を示す。

0114

実パッケージ容量3003は、対象パッケージグループ280内に、ストレージコントローラ200が実際にデータを格納できる記憶容量を示す。

0115

フラッシュブロック容量3004は、フラッシュメモリの消去単位であるブロックの物理的な容量である。一方、パッケージブロック容量3005は、すでに述べた仮想ブロック及び実ブロックに格納されるデータの容量である。二つの容量3004及び3005に違いがあるのは、主に、高性能化やブロックの長寿命化のためである。以下、この理由について説明する。仮に、二つの容量3004及び3005を同じにしたとする。その場合、フラッシュメモリの実ブロックのすべてに、データが格納されることになる。このとき、実ブロック内の一部のデータを書き換える指示(普通のライト指示)を、ストレージコントローラ200からパッケージコントローラ315が受け取ったとする。フラッシュメモリの実ブロックは書き換えができないので、パッケージコントローラ315は、その実ブロックの全データをバッファ330に読み出し、書き換え部分だけ更新して、当該実ブロックを一度消去した後、更新後の全データを当該実ブロックに格納しなければならない。フラッシュパッケージ230がライト指示を受け取るたびに、このような処理を実行すると、処理時間が長くなる。これを解決するため、本実施形態では、パッケージブロック容量3005の値は、フラッシュブロック容量3004より小さい値にされる。これにより、実ブロックには、空き領域が存在することになり、書き換えデータが空き領域に入れば、空き領域に追加書き込みが行われる。なお、この追加書き込みを行った場合、対応する仮想ブロック内のどのアドレス(相対アドレスでよい)のデータを書き込んだかが管理される。空き領域が小さくなって書き換えデータが入らなくなった場合、消去処理が行われる。これにより、消去処理は、n回(nは1以上の整数)のライト指示について一回実行されればよいので、性能を向上させることができる。また、消去処理の回数の削減は、フラッシュメモリの長寿命化にもつながる。

0116

パッケージ割り当て可能ブロック数3006は、対象フラッシュパッケージ230が有する複数の実ブロックのうちの、ストレージコントローラ200から受け取ったデータを格納可能な実ブロックの数を示す。

0117

パッケージ空きブロック数3007は、ストレージコントローラ300からのデータを格納可能な実ブロックのうちの、仮想ブロックに割り当てられていない実ブロック(空きブロック)の数を示す。

0118

障害ブロック数3008は、障害状態になってデータを格納できなくなってしまった実ブロック(不良ブロック)の数を示す。

0119

内部情報格納ブロック数3009は、パッケージメモリ320に格納されているパッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300及び空きブロックポインタ3400の退避先(例えば停電障害発生時での退避先)となる実ブロックの数を示す。内部情報格納アドレス3010は、退避先の実ブロックのアドレスを示す。パッケージ情報3000、チップ情報3100、仮想ブロック情報3200、実ブロック情報3300及び空きブロックポインタ3400は、重要な情報なので、退避する情報は、n重化(nは2以上の整数)されてもよい。また、退避される回数はそう多くないと考えられるので、実ブロックの消去回数なども問題にならないと考えられる。パッケージ割り当て可能ブロック数3006、障害ブロック数3008及び内部情報格納ブロック数3009の合計が、対象フラッシュパッケージ230が有する実ブロックの数である。

0120

図15は、チップ情報3100を示す。

0121

チップ情報3100は、フラッシュチップ300毎に存在する情報である。以下、一つのフラッシュチップ(図15の説明で「対象チップ」と言う)を例に採り、チップ情報3100を説明する。

0122

チップ情報3100は、チップID3101、チップ内実ブロック数3102、チップ内空きブロック数3103及び接続バスID3104を含む。

0123

チップID3101は、対象チップ300の識別子である。

0124

チップ内実ブロック数3102は、対象チップ300が有する実ブロックの数を示す。

0125

チップ内空きブロック数3103は、対象チップ300が有する空きブロックの数を示す。

0126

接続バスID3104は、対象チップ300が接続されているパッケージバス340の識別子である。

0127

図16は、仮想ブロック情報3200を示す。

0128

仮想ブロック情報3200は、仮想ブロック毎に存在する情報である。以下、一つの仮想ブロック(図16の説明で「対象仮想ブロック」と言う)を例に採り、仮想ブロック情報3200を説明する。なお、仮想ブロック情報3200は、仮想ブロックのアドレス順に並んでいるとする。最初の仮想ブロック情報3200が、先頭の仮想ブロックに対応する。

0129

仮想ブロック情報3200は、仮想ブロックID3201、仮想ブロック情報ポインタ3202、仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204を含む。

0130

仮想ブロックID3201は、対象仮想ブロックの識別子である。

0131

実ブロック情報ポインタ3202は、対象仮想ブロックに割り当てられた実ブロックの実ブロック情報3300へのポインタである。

0132

仮想ブロック割り当て時刻3203は、実ブロックが割り当てられていない対象仮想ブロック内のアドレスを指定したライト指示をストレージコントローラ200から受け付けた時刻である。

0133

仮想ブロック消去回数3204は、仮想ブロック割り当て時刻3203以降に対象仮想ブロックに割り当てられていた実ブロックの消去回数である。仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204は、階層型の長寿命化制御、及び、階層型の容量仮想化を実行するため、対象仮想ブロックを含む実ページ内のデータが別の実ページに移動されるときに、移動先の実ページに対して引き継がれる。この引継ぎ処理は、ストレージコントローラ200が、移動元の実ページに割り当てられているそれぞれの仮想ブロックについての仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204を読み出し、移動先の実ページに割り当てられているそれぞれの仮想ブロックの仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204に引き継ぐ

0134

図17は、実ブロック情報3300を示す。

0135

実ブロック情報3300は、実ブロック毎に存在する情報である。以下、一つの実ブロック(図17の説明で「対象実ブロック」と言う)を例に採り、情報3300を説明する。

0136

実ブロック情報3300は、実ブロックID3301、空きブロックポインタ3302、実ブロック障害フラグ3303、実ブロック内空き容量3304、追加書き込みデータアドレス情報3305及び実ブロック消去回数3306を含む。

0137

実ブロックID3301は、対象実ブロックの識別子である。このID3301が、どのフラッシュチップ300のどのアドレスに相当する実ブロックかを示している。

0138

空きブロックポインタ3302は、対象実ブロックが空きブロック場合(いずれの仮想ブロックにも割り当てられていない場合)、次の空きブロックの実ブロック情報3300を指している。

0139

実ブロック障害フラグ3303は、対象実ブロックが障害状態になり、データを格納できなくなったとき、ONとされる。

0140

実ブロック内空き容量3304は、対象実ブロックの現在の空き容量を示している。この値は、当初は、例えば、(フラッシュブロック容量3004−パッケージブロック容量3005)である。パッケージプロセッサ310は、対象実ブロックに対し、この空き容量以下のデータを書くことのライト指示を、ストレージコントローラ200から受け、この空き領域に、ライト指示の対象のデータを書き込む。書き込んだ後、書き込まれたデータ量だけ、実ブロック内空き容量3304の値が小さくされる。

0141

追加書き込みデータアドレス情報3305は、当初の空き領域(((フラッシュブロック容量3004−パッケージブロック3005))の容量の領域)に追加書き込みを行ったすべてのデータの仮想ブロック内の相対アドレスとデータ長集合値である。

0142

実ブロック消去回数3306は、対象実ブロックの現在までの消去回数を示している。

0143

図18は、空きブロック情報ポインタ3400によって管理される空きブロックの集合を表している。

0144

空きブロック管理情報ポインタ3400は、先頭の空きブロックの実ブロック情報3300のアドレスをさす。次に、先頭の空きブロックの実ブロック情報3300の中の空きブロックポインタ3302が、次の空きブロックの実ブロック情報3300を示す。図18では、最後の空きブロックの実ブロック情報3300の空きブロックポインタ2103は、空きブロック情報ポインタ3400を示しているが、ヌル値でもよい。パッケージプロセッサ310は、実ブロックが割り当てられていない仮想ブロック内のアドレスを指定したライト指示を受け付けると、いずれかのフラッシュチップ300(例えば、空きブロックの数の最も多いチップ)から、そのチップに対応する空きブロック情報ポインタ3400を基に空きブロックを探し、見つかった空きブロック(実ブロック)を仮想ブロックに割り当てる。

0145

次に、ストレージコントローラ200及びパッケージコントローラ315が行う処理を説明する。

0146

まず、ストレージコントローラ200が行う処理を説明する。ストレージコントローラ200が行う処理は、プロセッサ260がメモリ270内に格納されているプログラムを実行することにより実現される。以下、メモリ270内のプログラムを主語として説明する処理は、実際にはプロセッサ260が行う処理である。

0147

図19は、メモリ270に格納されているプログラムを示す。

0148

プログラムとして、例えば、リード処理実行部4000、ライト要求受付部4100、ライトアフタ処理実行部4200、ライトセイムコマンド処理実行部4300、ページ移動スケジュール部4400及びページ移動処理実行部4500がある。これらのプログラムが、上位レベルの長寿命化制御及び容量仮想化機能を含む。なお、すでに述べたが、本実施形態は、下位レベルの長寿命化制御及び容量仮想化機能を実現するのは、パッケージコントローラ315であるが、下位レベルの長寿命化制御及び容量仮想化機能はストレージコントローラ200によって実現されてもよい。この場合、上位レベルのプログラムと下位レベルのプログラム双方が、ストレージコントローラ200で実行されるので、プログラム間インターフェイスが異なってくるが、上位レベルのプログラムが実行する内容は基本的に大きな相違はない。したがって、本実施形態では、下位レベルの長寿命化制御及び容量仮想化機能を実現するのはパッケージコントローラ315であることを前提に、リード処理実行部4000、ライト要求受付部4100、ライトアフタ処理実行部4200、ライトセイムコマンド処理実行部4300、ページ移動スケジュール部4400、ページ移動処理実行部4500がそれぞれ行う処理のフローを詳細に説明する。

0149

図20は、リード処理実行部4000の処理フローを示す。

0150

リード処理実行部4000は、ストレージコントローラ200がホスト110からリード要求を受け付けたときに実行される。図20の説明において、リード要求の対象のデータを「リード対象データ」と言い、リード要求から特定される論理ボリューム、仮想ページ、及びその仮想ページにおける領域を、「リード元論理ボリューム」、「リード元仮想ページ」、及び「リード元領域」と言う。

0151

テップ5000:実行部4000は、受け取ったリード要求で指定されたリード対象とするアドレスから、リード元仮想ページとリード元領域の相対アドレスとを計算する。

0152

ステップ5001:実行部4000は、リード対象データが、キャッシュメモリ210に存在するか否か(キャッシュヒットしたか否か)を判断する。キャッシュヒットならば、ステップ5010が行われ、キャッシュミスならば、ステップ50002が行われる。

0153

ステップ5002:キャッシュミスの場合、まず、実行部4000は、リード元仮想ページに対応するフォーマット情報2005が有効な値か否かを判断する。有効でなければ、ステップ5004へジャンプする。

0154

ステップ5003:フォーマット情報2005が有効な場合、実行部4000は、リード元領域には、このパターンデータ(繰り返し情報)が格納されていることになる。このため、実行部4000は、キャッシュメモリ210に、その情報2005が有するパターンデータを格納し、ステップ5010へジャンプする。

0155

ステップ5004:ここでは、リード対象データをキャッシュメモリ210にロードする必要がある。ます、実行部4000は、リード元仮想ページに割り当てられている実ページ(以下、図20の説明において「リード元実ページ」と言う)に対応する実ページ情報2100を、リード元論理ボリュームに対応した情報2000内の実ページポインタ2004から獲得する。

0156

ステップ5005:実行部4000は、獲得した実ページ管理情報2100内のパッケージグループ2101及び実ページアドレス2102から、リード元実ページが属するパッケージグループ280とリード元実ページのパッケージグループ280内での先頭アドレスとを得る。

0157

ステップ5006:実行部4000は、リード元仮想ページ内の相対アドレスとパッケージグループRAIDタイプ2302とから、リード元実ページ内の相対アドレスを計算する。実行部4000は、計算した実ページ内相対アドレスと、リード元実ページに対応するパッケージグループRAIDタイプ2302及びフラッシュパッケージポインタ2305とを基に、どのフラッシュパッケージ230のどのアドレスにアクセスするかを特定する。

0158

ステップ5007:実行部4000は、ステップ5006で特定されたフラッシュパッケージ230に対し、そのステップ5006で特定されたアドレスを指定したリード指示を送信する。

0159

ステップ5008:実行部4000は、リード指示の送信先のフラッシュパッケージ230から、リード指示の対象のデータが送られてくるのを待つ。

0160

ステップ5009:実行部4000は、フラッシュパッケージ230から送られてきたデータをキャシュメモリ150に格納する。

0161

ステップ5010:実行部4000は、キャッシュメモリ210に格納されているリード対象データをホスト110へ送る。

0162

図21は、ライト要求受付部4100の処理フローを示す。

0163

ライト要求受付部4100は、ストレージコントローラ200が、ホスト110からライト要求を受け付けたときに実行される。図21の説明において、ライト要求に付随するデータを「ライト対象データ」と言い、ライト要求から特定される論理ボリューム、仮想ページ、及びその仮想ページにおける領域を、「ライト先論理ボリューム」、「ライト先仮想ページ」、及び「ライト先領域」と言う。

0164

ステップ6000:受付部4100は、受け取ったライト要求がライト対象とするアドレスから、対応するライト先仮想ページとライト先領域の相対アドレスとを計算する。

0165

ステップ6001:受付部4100は、ステップ6000で得たライト先仮想ページに実ページが割り当てられているか否かを、ライト先仮想ページに対応した実ページポインタ(ライト先論理ボリュームに対応した情報2000内のポインタ)2004を参照して、判断する。割り当てられていない場合、ステップ6002が行われ、割り当てられている場合、ステップ6003へジャンプする。

0166

ステップ6002:受付部4100は、ライト先仮想ページに空きページを割り当てる。具体的には、例えば、受付部4100は、以下の(a)〜(e):
(a)ライト先論理ボリュームに対応した情報2000内のRAIDタイプ2002と、パッケージグループ情報2300内のパッケージグループRAIDタイプ2303及び空きページ数2304等を参照して、どのパッケージグループ280の基になっている実ページをライト先仮想ページに割り当てるかを決める;
(b)決めたパッケージグループ280に対応する空きページ管理情報ポインタ2400を参照して、ライト先仮想ページに対応した実ページポインタ2004を、先頭の空きページ情報2100を示すよう更新する(これで、ライト先仮想ページに空きページが割り当てられたことになる);
(c)空きページ管理情報ポインタ2400を、次の実ページ情報2100(仮想ページに割り当てられた実ページの実ページ情報2100の中の空きページポインタ2103が示す実ページ情報2100)を示すよう更新する;
(d)ライト先仮想ページに割り当てた実ページの実ページ情報2100の中の空きページポインタ2103をヌル値にする;
(e)割り当てた実ページに対応するパッケージグループ情報2300の空きページ数2304が示す値を減らす、
を行う。仮想ページに空きページを割り当てる処理を、本実施形態では、ライト要求を受け付けたときに実行するが、この割り当て処理は、フラッシュパッケージ230へデータを格納するまでに実行されればよい。この後、ステップ6005へジャンプする。

0167

ステップ6003:受付部4100は、ライト先仮想ページに対応したフォーマット情報2005が有効な値であるかを判断する。有効でなければ、ステップ6005へジャンプする。

0168

ステップ6004:当該ライト要求の実行により、ライト先仮想ページに対応したフォーマット情報2005は無効な値となる。このため、当該ライト要求で、ライト先仮想ページにおけるライト先領域以外の領域には、ライト先仮想ページに対応したこれまでのフォーマット情報2005で、書き込む必要がある。したがって、ここでは、受付部4100は、キャッシュメモリ210に、ライト先仮想ページに対応したフォーマット情報2005が有するパターンデータを格納する(当該ライト要求で、ライト対象データは、次のステップ6005で受け取る)。また、受付部4100は、そのパターンデータには、どのフラッシュパッケージ230のどのアドレスに書き込むべきかを示す情報をつけておく。これらの情報を獲得するために、ここでも、受付部4100は、図20のステップ5004及び5005の処理を実行することになる。この後、ライト先仮想ページに対応したフォーマット情報2005が無効な値にされる。

0169

ステップ6005:受付部4100は、ホスト110からのライト対象データをキャッシュメモリ210に格納する。ステップ6004でパターンデータがキャッシュメモリ210に格納された場合、ライト先領域の繰り返しパターンが、このとき受け取ったライト対象データに置き換えられる。このときも、このライト対象データには、どのフラッシュパッケージ230のどのアドレスに書き込むべきかを示す情報をつけておく。これらの情報を獲得するために、ここでも、図20のステップ5004及び5005の処理を実行することになる。

0170

パッケージグループ280は、RAID構成を有する。このため、キャッシュメモリ210上に格納したライト対象データに冗長データを生成しなければならない場合がある。また、実ページは、冗長データを格納する領域を有するので、ライト対象データに対応する冗長データの実ページ内のライト先アドレスも一意に定まる。冗長データも、一度、キャッシュメモリ210に格納される。なお、キャッシュメモリ210上の冗長データも、ライト対象データと同様に、どのフラッシュパッケージ230のどのアドレスに書き込むべきかを示す情報をつけておく。ライト対象データ及び冗長データは、ライトアフタ処理実行部5200によって、フラッシュパッケージ230に書き込まれる。これらのデータは、ライトアフタ処理実行部5200から見ると、いずれもフラッシュパッケージ230へ書き込むデータなので、両者(つまりライト対象データであるか冗長データであるか)を区別する必要はない。同様に、フラッシュパッケージ230も、両者を区別する必要はない。

0171

図22は、ライトアフタ処理実行部4200の処理フローを示す。

0172

ライトアフタ処理実行部4200は、適宜に(例えば定期的に)実行される。実行部4200は、キャッシュメモリ210内のライト対象データ及び冗長データをフラッシュパッケージ230に書き込むライトアフタ処理を行う。ただし、実行部4200は、ライト対象データ及び冗長データの両者を、フラッシュパッケージ230に書き込むべきデータ(図22の説明において「デステージ対象データ」と言う)として、両者を区別せずに処理する。

0173

ステップ7000:実行部4200は、キャッシュメモリ210をサーチして、デステージ対象データを決める。

0174

ステップ7001:実行部4200は、見つけたデステージ対象データに付与されているアドレス情報を取得し、アドレス情報を基に特定されるフラッシュパッケージ230に、アドレス情報を基に特定されるライト先アドレスを指定したライト指示とデステージ対象データとを送信する。なお、ライト先実ページ(ライト先アドレスを有する仮想ブロックが割り当てられている実ページ)に対応する移動中フラグ2109がONの場合、ライト先実ページ内のデータは移動中である。この場合、実行部4200は、ステップ7000で決定されたデステージ対象データのライトを中止し、別のデステージ対象データを探す。また、実行部4200は、フラッシュパッケージ230に送信するライト指示に、タイマ240から取得される現在時刻(ストレージシステム100内一意に定まるカウンタのようなものでもよい)を付与する。ライト指示に付与された時刻は、後述する平均消去回数の算出に使用される(具体的には、累積実ページ割り当て時間2106、パッケージ内累積実ページ割り当て時間2507の更新に使用される)。

0175

ステップ7002: 実行部4200は、フラッシュパッケージ230からライト完了報告(ライト指示に対する完了報告)を受けるのを待つ。

0176

ステップ7003:実行部4200は、以下の(a)〜(c):
(a)フラッシュパッケージ230からのライト完了報告を基に、ライト指示で指定したアドレスを有する仮想ブロック(ライト先の仮想ブロック)に実ブロックが割り当てられたかを判断する;
(b)実ブロックが割り当てられたのであれば((a)の判断結果が肯定的であれば)、割り当てられた実ブロックの数(図22の説明において「今回割当て数」という)を、ライト先実ページに対応した追加実ブロック割り当て数2105と、ライト先パッケージ(ライト先実ページの基になっているフラッシュパッケージ)230に対応したパッケージ内追加実ブロック割り当て数2506とに加算する;
(c)今回割当て数に、(次回スケジュール時刻2701−現在時刻(現在のタイマ240の値))を乗算し、この乗算値を、ライト先実ページに対応した追加実ブロック割り当て時間2108と、ライト先パッケージ230に対応したパッケージ内追加実ブロック割り当て時間2509とに加算する、
を実行する。(c)では、例えば、今回割当て数が3で、(次回スケジュール時刻2701−現在時刻)が40分であれば、120分が乗算値となり、120分が、ライト先実ページに対応した時間2108とライト先パッケージ230に対応した時間2509とにそれぞれ加算されることになる。

0177

ステップ7004: 実行部4200は、以下の(a)及び(b):
(a)フラッシュパッケージ230からのライト完了報告を基に、実ブロックに対する消去処理が発生したかを判断する;
(b)消去処理が発生したのであれば((a)の判断結果が肯定的であれば)、発生した消去回数(例えば、2個の実ブロックに1回の消去処理が発生したのであれば、消去回数は2である)を、ライト先実ページに対応する累積実ブロック消去回数2107と、ライト先パッケージに対応するパッケージ内累積実ブロック消去回数2508とに加える(累積ライトデータ量2112及びパッケージ内累積ライトデータ量2510がある場合、本ライトアフタ処理で書き込んだデステージ対象データの量を、それらの情報2112及び2510にそれぞれ加える)、
を実行する。

0178

ステップ7005:実行部4200は、以下の(a)及び(b):
(a)フラッシュパッケージ230からのライト完了報告を基に、ブロック消去回数が一定値以上になった(障害状態になった)実ブロックがあるか否かを判断する;
(b)障害状態になった実ブロックがあれば((a)の判断結果が肯定的であれば)、障害状態になった実ブロックの数を、ライト先パッケージに対応する割り当て可能実ブロック数2504から減算する、
を実行する。

0179

図23は、ライトセイムコマンド処理実行部4300の処理フローを示す。

0180

ライトセイムコマンド処理実行部4300は、ライトセイムコマンドを、ストレージコントローラ200が、ホスト110から受け取ったときに実行される。ライトセイムコマンドは、パターンデータ(例えば短いパターンデータ)を或る記憶領域に繰り返し書き込むことの要求である。ストレージコントローラ200は、このパターンデータを、ライトセイムコマンドで指定されている記憶領域(仮想ページ内の記憶領域)に書き込むのではなく、指定された記憶領域に対応する仮想ページにパターンデータが格納されているということを記憶して、その仮想ページに割り当てられている実ページを解放する(実ページの割当てを解除する)。これにより、消費記憶容量が節約される。なお、解放された実ページに対応する仮想ブロックに割り当てられている実ブロック(図23の説明において「解放実ブロック」という)を他の仮想ブロックに割り当てるためには、解放実ブロックに対する消去処理が必要である。本実施形態では、ストレージコントローラ200は、ライトセイムコマンドを受け取った場合、フラッシュパッケージ230に、解放実ブロックの消去処理を指示する。ライトセイムコマンドは、ストレージコントローラ200からパッケージコントローラ315に送信され、パッケージコントローラ315が、その要求に応答して、実ブロックの解放及び消去処理を行ってもよい。なお、通常のライト要求に応答してオール0などのパターンデータ(例えばフォーマットデータ)が書き込まれる場合にも、ストレージコントローラ200、あるいは、パッケージコントローラ315が、パターンデータを認識して、解放実ブロックを解放させてもよい。

0181

ステップ8000:実行部4300は、受けたライトセイムコマンドで指定されている記憶領域(以下、ライト指定領域)に係る仮想ページの集合を特定する。ライト指定領域は、例えば、仮想ページの一部領域(以下、仮想一部領域)、一以上の仮想ページ全域、あるいは、それらの組合せに相当する。

0182

ステップ8001:本実施形態では、仮想ページ全体が指定されていれば対応する実ページが解放の対象となる。また、仮想ブロック全体が指定されていれば、フラッシュパッケージ160の中の実ブロックを解放できる可能性がある。RAID0やRAID1の場合には、仮想ブロック全体が指定されていれば、対応する実ブロックを解放することができる。しかし、仮想ブロック全体が指定されていても、RAID5のように、N個のデータから1つの冗長データを生成する場合、単純に対応する実ブロックを解放することはできない。本実施形態では、RAID5を構成するN個の仮想ブロック全体が指定された場合、対応するN個の実ブロッックとその冗長データを格納した1個の実ブロックを解放するようにする。仮想ブロックの一部の領域や、RAID5を構成するN個の仮想ブロックの一部の領域が、指定された場合、指定された記憶領域には、指定された情報パターンを書き込む必要がある。当該ステップでは、実行部4300は、フラッシュパッケージ230に情報パターンを書き込む必要がある領域と実ブロックの解放が可能なフラッシュパッケージ230内の領域を分類する。情報パターンを、フラッシュパッケージ230へ書き込む必要がない場合、ステップ8003へジャンプする。

0183

ステップ8002:実行部4300は、フラッシュパッケージ230に書き込むパターンデータを、キャッシュメモリ210に格納する。その際、どのフラッシュパッケージ230のどの領域に書き込むのかというアドレス情報がそのパターンデータに付与される。この後、そのパターンデータは、ライト要求に付随するライト対象データと同じように、フラッシュパッケージ230へ書き込まれる。

0184

ステップ8003:実行部4300は、解放できる実ブロック及び実ページがあるかを判断する。いずれもない場合、本処理フローが終了する。

0185

ステップ8004:実行部4300は、ステップ8001で判別したフラッシュパッケージ230の記憶領域を指定した解放指示を、そのフラッシュパッケージ230に送信する。その解放指示は、パッケージグループ280を構成する一以上のフラッシュパッケージ230に送信される可能性がある。

0186

ステップ8005:実行部4300は、解放指示の送信先のすべてのフラッシュパッケージ230から処理報告を待つ。

0187

ステップ8006:各フラッシュパッケージ230内のパッケージコントローラ315は、その解放指示の応答として、各仮想ブロックについて、実際に解放した仮想ブロックの個数(=実ブロックの個数)と、各仮想ブロックごとに、実ブロックを割り当てた時刻と仮想ブロックの消去回数を、ストレージコントローラ200に報告する。本ステップでは、実行部4300は、仮想ブロックごとの実ブロック割り当て時刻を判断して、前回スケジュール時刻2701以前の値をもつ仮想ブロックと、前回スケジュール時刻2701以降の値をもつ仮想ブロックとに分類する。以下のステップ8007及び8008では、実ページ情報2100及びフラッシュパッケージ情報2500がもっている情報から、解放した実ブロックに関する属性(例えば、割当て時間)が削減される。

0188

ステップ8007:本ステップの処理は、前回スケジュール時刻2701以前の値をもつ仮想ブロックの集合に対する処理である。実行部4300は、以下の(a)〜(f):
(a)それぞれの実ブロック割り当て時刻ごとに、(実ブロック割り当て時刻−前回スケジュール時刻2701)を計算し、この値を、対応する実ページ及びフラッシュパッケージ230ごとに加算する(実ブロック割当て時刻は、例えば、ストレージコントローラ200のライト指示に付与されていた時刻である);
(b)それぞれの加算された値を、対応するすべての実ページ情報2100内の累積実ページ割り当て時間2106と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内累積実ページ割り当て時間2507から減算する;
(c)それぞれの仮想ブロックの消去回数を、対応する実ページ及びフラッシュパッケージ230ごとに加算する;
(d)それぞれの加算された値を、対応するすべての実ページ情報2100内の累積実ページ消去回数2107と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内累積実ページ消去回数2508から減算する;
(e)実ブロック割り当て時刻をもつ仮想ブロックが、実ページ及びフラッシュパッケージ230ごとにいくつあるかをそれぞれカウントする;
(f)それぞれのカウント値を、対応するすべての実ページ情報2100内の累積実ページ割り当て数2104と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内実ページ割り当て数2505から削減する、
を実行する。

0189

ステップ8008:本ステップの処理は、前回スケジュール時刻2701以降の値をもつ仮想ブロックの集合に対する処理である。実行部4300は、以下の(a)〜(f):
(a)それぞれの実ブロック割り当て時刻ごとに、(次回スケジュール時刻2701−実ブロック割り当て時刻)を計算し、この値を、対応する実ページ及びフラッシュパッケージ230ごとに加算する;
(b)それぞれの加算した値を、対応するすべての実ページ情報2100内の追加実ページ割り当て時間2108と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内追加実ページ時間2509とから減算する;
(c)それぞれの仮想ブロックの消去回数を、対応する実ページ及びフラッシュパッケージ230ごとに加算する;
(d)それぞれの加算された値を、対応するすべての実ページ情報2100内の追加実ページ消去回数2109と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内追加パページ消去回数2510から減算する;
(e)実ブロック割り当て時刻をもつ仮想ブロックが、実ページ及びフラッシュパッケージ230ごとにいくつあるかをそれぞれカウントする(なお、この処理は、ステップ8007でも行われているので省略されてもよい);
(f)それぞれのカウント値を、対応するすべての実ページ情報2100内の追加実ブロック割り当て数2105と、対応するすべてのフラッシュパッケージ管理情報2500内のパッケージ内追加実ページ割り当て数2506から減算する、
を実行する。

0190

ステップ8009:実行部4300は、上記受けたライトセイムコマンドで、仮想ページから実ページを解放できるものがあるかを判断する。なければ、本処理フローが終了する。

0191

ステップ8010:本ステップの処理は、仮想ページから実ページを解放する処理である。実行部4300は、(a)〜(e):
(a)解放可能な実ページに対応する実ページ情報2100を、空きページ管理情報ポインタ2200のキュー登録する;
(b)解放可能な実ページの基になっているフラッシュパケッージグループ280ごとに、解放できる実ページ数を計算する;
(c)パッケージグループ280ごとに計算した値を、対応するパッケージグループ情報2300内の空きページ数2304から減算する;
(d)解放する実ページごとに、論理ボリューム情報2000内の実ページポインタ2004をヌル値にする;
(e)ライトセイムコマンドに付随するパターンデータを、フォーマット情報2005に含める、
を実行する。これにより、ライト指定領域に係る仮想ページにはフォーマット情報2005に含まれたパターンデータが格納されていることをストレージコントローラ200が認識することができる。

0192

図24は、ページ移動スケジュール部4400の処理フローを示す。

0193

ページ移動スケジュール部4400は、タイマ240が、次回スケジュール時刻2702になったときに、実行を開始する。

0194

ステップ10000:スケジュール部4400は、各フラッシュパッケージ230について、以下の(a)〜(e):
(a)パッケージ内実ブロック割り当て数2505に(次回スケジジュ−ル時刻2702−前回スケジュール時刻2701)を乗算した値を、パッケージ内累積実ブロック割り当て時間2507に加える;
(b)パッケージ内累積実ブロック割り当て時間2507に、パッケージ内追加実ブロック割り当て時間2509を加える;
(c)ブロックパッケージ内追加実ブロック割り当て時間2509を0にする;
(d)パッケージ内実ブロック割り当て数2505に、パッケージ内追加実ブロック数2506加える、
(e)パッケージ内追加実ブロック数2506を0にする、
を実行する。(a)と(b)により、前回スケジュール時刻2701以降に割り当てられた実ブロックの割り当て時間を反映(加算)できたことになる。なぜなら、パッケージ内追加実ブロック割り当て時間2509は、前回スケジュール時刻2701以降に割り当てられた、当該フラッシュパッケージの実ブロックごとに、(次回スケジュール実時刻2702−実ブロック割り当て時刻)が加算されてきたからである。

0195

ステップ10001:スケジュール部4400は、各実ページについて、以下の(a)〜(e):
(a)実ブロック割り当て数2104に(次回スケジュール時刻2702−前回スケジュール時刻2701)を乗算した値を、累積実ブロック割り当て時間2106に加える;
(b)累積実ブロック割り当て時間2106に、追加実ブロック割り当て時間2108を加える;
(c)追加実ブロック割り当て時間2108を0にする;
(d)実ブロック割り当て数2104に、追加実ブロック数2105を加える;
(e)追加実ブロック数2105を0にする、
を実行する。(a)と(b)により、前回スケジュール時刻2701以降に割り当てられた実ブロックの割り当て時間を反映(加算)できたことになる。なぜなら、追加実ブロック割り当て時間2108には、前回スケジュール時刻2701以降に割り当てられた、当該実ページの実ブロックごとに、(次回スケジュール実時刻2702−実ブロック割り当て時刻)が加算されてきたからである。

0196

ステップ10002:スケジュール部4400は、各フラッシュパッケージ230について、以下の(a)〜(d):
(a)パッケージ内累積実ブロック消去回数2508をパッケージ内累積実ブロック割り当て時間2507で割る;
(b)パッケージ内実ブロック割り当て数2505を、割り当て可能実ブロック数2504で割る、
(c)複数のパッケージグループ280から移動元パッケージグループを決定する;
(d)複数のパッケージグループ280から移動先パッケージグループを決定する、
を実行する。

0197

(a)で得られた値は、実ページの割り当ての変更を行わなかった場合のそれぞれのフラシュパッケージ230の実ブロックの単位時間当りの平均消去回数(以下、単に「平均消去回数」と言う)となる。なお、パッケージ内累積実ブロック消去回数2508の代わりにパッケージ内累積ライトデータ量2510がある場合、そのライトデータ量2510からパッケージ内累積実ブロック消去回数2508の値が推測される。具体的には、例えば、パッケージ内累積ライトデータ量2510/(フラッシュブロック容量3004—パッケージブロック容量3005)で算出された値が、パッケージ内累積実ブロック消去回数2508の推測値である。これは、当初、(フラッシュブロック容量3004−パッケージブロック容量3005)が空き容量になっていて、この空き容量がなくなると、消去処理が発生するためである。

0198

スケジュール部4400は、余命が短いパッケージグループを移動元パッケージグループとして決定することができるが、「余命」は、平均消去回数と消去限界数2512を基に算出される。具体的には、例えば、{(消去限界数2512−パッケージ内累積実ブロック消去回数2508)/平均消去回数}+現在時刻(タイマ240から取得される時刻)を計算することにより、一つのパッケージグループ230についての余命が得られる。

0199

(b)で得られた値は、実ページの割り当ての変更を行わなかった場合のそれぞれのフラシュパッケージ230の実ブロックの占有率になる。

0200

本実施形態では、この平均消去回数や実ブロックの占有率に基づき、移動元パッケージグループが決定される。以下、それぞれのケースを説明する。

0201

<平均消去回数>。

0202

スケジュール部4400は、例えば、平均消去回数が多い或いは余命が短いパッケージグループを移動元パッケージグループとして決定する。具体的には、例えば、スケジュール部4400は、下記(A1)〜(A3)の少なくとも一つに適合するフラッシュパッケージを含んだパッケージグループ:
(A1)平均消去回数が所定の第1の閾値を超えている;
(A2)余命が保障期間終了時刻2511より短い;
(A3)平均消去回数が、他のフラッシュパッケージ230に比べて一定の割合以上に多い(すなわち、フラッシュパッケージ230間で、平均消去回数の偏りが大きい)、
を、移動元パッケージグループとして決定する。

0203

スケジュール部4400は、例えば、平均消去回数が少ない或いは余命が長いパッケージグループを移動先パッケージグループとして決定する。具体的には、例えば、スケジュール部4400は、下記(B1)〜(B3)の少なくとも一つに適合するフラッシュパッケージを含んだパッケージグループ:
(B1)平均消去回数が所定の第2の閾値以下である(第2の閾値は前述の第1の閾値以下);
(B2)余命が保障期間終了時刻2511より長い;
(B3)平均消去回数が、他のフラッシュパッケージ230に比べて一定の割合未満に少ない、
を、移動先パッケージグループとして決定する。より具体的には、例えば、上記(A1)のフラッシュパッケージ230を含んだ移動元パッケージグループに対して、(B1)のフラッシュパッケージ230を含んだパッケージグループ280が移動先として決定され、上記(A2)のフラッシュパッケージ230を含んだ移動元パッケージグループに対して、(B2)のフラッシュパッケージ230を含んだパッケージグループ280が移動先として決定され、上記(A3)のフラッシュパッケージ230を含んだ移動元パッケージグループに対して、(B3)のフラッシュパッケージ230を含んだパッケージグループ280が移動先として決定される。その際、移動先となるパッケージグループ280は、例えば、移動元との平均消去回数の差、又は、余命の差を基に、決定される。

0204

<実ブロックの占有率>。

0205

スケジュール部4400は、例えば、下記(X1)及び(X2)の少なくとも一つに適合するフラッシュパッケージを含んだパッケージグループ280:
(X1)実ブロックの占有率が所定の第3の閾値を越えている(フラッシュパッケージ230が満杯になる可能性がある);
(X2)割り当て可能実ブロック数2504がある基準を満たしていない(例えば所定の第5の閾値以下である)、
を、移動元パッケージグループとして決定する。

0206

スケジュール部4400は、例えば、下記(Y1)及び(Y2)の少なくとも一つに適合するフラッシュパッケージを含んだパッケージグループ:
(Y1)平均消去回数が所定の第4の閾値以下である(第4の閾値は前述の第3の閾値以下);
(Y2)割り当て可能実ブロック数2504がある基準を満たしている(例えば所定の第6の閾値を超えている(第6の閾値は前述の第5の閾値以上))、
を、移動先パッケージグループとして決定する。

0207

ステップ10003:スケジュール部4400は、
(a)移動元ページ(データの移動元の実ページ)と移動先ページ(データの移動先の実ページ)とを決定する(すなわち、スケジュール部4400は、移動元パッケージグループに基づく複数の実ページから移動元ページを決定し、且つ、移動先パッケージグループに基づく複数の実ページから移動先ページを決定する);
(b)決定されたすべての移動元ページに対応する移動待ちフラグ2111をONに更新する;
(c)移動先ページを割り当てるパッケージグループ280に対応する空きページ管理情報ポインタ2200がさす実ページ情報2100を、移動元ページのコピー先実ページ情報ポインタ2110に設定する;
(d)空きページ管理情報ポインタ2200を、次の空いた状態にあるページ管理情報2100を示すように更新する、
を実行する。上記(c)及び(d)は、決定された全ての移動元ページについて実行される。これにより、移動元ページと移動先ページのペアが決まったことになる。

0208

(a)において、スケジュール部4400は、例えば、移動元パッケージグループ280に属する各実ブロック情報2100の、累積実ブロック割り当て時間2106、累積実ブロック消去回数2107(代わりに、累積ライトデータ量2112)、実ブロック割り当て数2104などのうちの少なくとも一つを基に、移動元ページを決定する。具体的には、例えば、スケジュール部4400が決定した移動元ページは、下記(x)又は(y)の特徴:
(x)決定された移動元ページの累積実ブロック消去回数2107は、その移動元ページの累積実ブロック消去回数2107と移動先ページ(移動先の実ページ)の累積実ブロック消去回数2107との差になるべく近い(好ましくは等しい);
(y)決定された移動元ページの実ブロック占有率は、その移動元ページの実ブロック占有率と移動先ページの実ブロック占有率との差になるべく近い(好ましくは等しい)、
を有する。(x)の特徴を有する移動元ページは、例えば、移動元パッケージグループが上記(A1)〜(A3)のいずれかに対応したグループの場合に決定される。(y)の特徴を有する移動元ページは、移動元パッケージグループが上記(B1)又は(B2)に対応したグループの場合に決定される。

0209

ステップ10004:スケジュール部4400は、パッケージグループ160ごとに存在するページ移動処理実行部4500の中で、少なくとも一つの移動元ページを有するパッケージグループ280に対応したページ移動処理実行部4500を起動する。

0210

ステップ10005:スケジュール部4400は、以下の(a)及び(b):
(a)次回スケジュール時刻2701を前回スケジュール時刻2701にコピーする;
(b)次回スケジュール時刻2701に次のスケジュール時間を設定する(例えば、次回スケジュール時刻2701を、現在の次回スケジュール時刻2701に所定の時間を加算することにより得られた時刻に更新する)、
を実行する。

0211

図25は、ページ移動処理実行部4500の処理フローを示す。

0212

ページ移動処理実行部4500は、パッケージグループ280毎に存在する。また、図24のステップ10004で述べたように、少なくとも一つの移動元ページを有するパッケージグループ280に対応したページ移動処理実行部4500が、ページ移動スケジュール部4400から起動される。

0213

ステップ11000:実行部4500は、ONになっている移動待ちフラグ2111を含んだ実ページ情報2100を探す。この実ページ情報2100に対応した実ページが移動元ページである。もし、ONになった移動待ちフラグ2111を含んだ実ページ情報2100がない場合、本処理フローは終了する。

0214

ステップ11001:実行部4500は、見つかった実ページ情報2100内の移動待ちフラグ2111をOFFにして、移動中フラグ2109をONにする。

0215

ステップ11002:実行部4500は、移動元ページに割り当てられている仮想ブロックの集合を特定する。移動元ページに対応するパッケージグループ2101が示すパッケージグループ情報2300が、該当するパッケージグループ情報2300である。このパッケージグループ情報2300内のフラッシュパッケージポインタ2305が示すフラッシュパッケージ情報2500に対応するフラッシュパッケージ230が、移動元ページの基になっているフラッシュパッケージ(移動元パッケージ)230である。実行部4500は、移動元ページに対応した実ページアドレス2102と、移動元パッケージに対応したブロック容量2503とを基に、それぞれのフラッシュパッケージ230の中の移動対象となる仮想ブロックの集合を、すべてのフラッシュパッケージ230に関して特定する。

0216

ステップ11003:実行部4500は、移動元グループ(移動元ページの基になっているパッケージグループ)280を構成する各フラッシュパッケージ230のパッケージコントローラ315に、特定された仮想ブロックの集合に格納されているデータのリード指示を送信する。

0217

ステップ11004:実行部4500は、ステップ11003での指示の送信先のすべてのフラッシュパッケージ230から、完了報告をまつ。
ステップ11005:実行部4500は、フラッシュパッケージ230からの完了報告に含まれている情報を、キャッシュメモリ210に格納する。なお、その完了報告には、ステップ11003で送信した指示で指定した各仮想ブロック(リード元仮想ブロック)に実ブロックが割りてられていたか否かを表す情報が含まれている。リード元仮想ブロックに実ブロックが割り当てられていた場合、完了報告には、以下の情報(A)〜(C);、
(A)リード元仮想ブロックに割り当てられていた実ブロックに格納されていたデータ;
(B)リード元仮想ブロックに実ブロックが割り当てられていない状態から初めて実ブロック(現在割り当てられている実ブロックとは限らない)を割り当てた時刻;
(C)(D)の時刻以降の、リード元仮想ブロックに割り当てられていた実ブロックの消去回数、
が含まれている。

0218

ステップ11006:実行部4500は、移動先ページに割り当てられている仮想ブロックの集合を特定する。この場合、移動元ページに対応した実ページ情報2100内の移動先ページポインタ2110が示す実ページ情報2100が、移動先ページに対応する実ページ情報2100である。

0219

ステップ11007:実行部4500は、移動先グループ(移動先ページの基になっているパッケージグループ)280を構成する各フラッシュパッケージ230のパッケージコントローラ315に、特定された仮想ブロック(ライト先仮想ブロック)にデータを格納することのライト指示を送信する。このとき、各パッケージコントローラ315に送られる情報は、ステップ1105でキャッシュメモリ210に格納された情報(移動元パッケージ230から送られてきた情報)である。

0220

ステップ11008:実行部4500は、ライト指示の送信先のすべてのフラッシュパッケージ230から、完了報告をまつ。

0221

ステップ11009:実行部4500は、以下の(a)〜(c):
(a)移動元ページを空きページに更新し、且つ、移動先ページを、これまで移動元ページが割り当てられていた仮想ページに割り当てる(具体的には、移動元ページに対応した実ページ情報2100に空きページ管理ポインタ2200をつなぎ、これまで移動元ページを示していた実ページポインタ2004を移動先ページに対応した実ページ情報2100を示すようにする);
(b)、移動元ページに対応した実ページ情報2100のうち、実ブロック割り当て数2104、追加実ブロック割り当て数2105、累積実ブロック割り当て時間2106、累積実ブロック消去回数2107(累積ライトデータ量2112)、追加実ブロック割り当て時間2108を、移動先ページに対応した実ページ情報2100にコピーする;
(c)移動元ページに対応した実ページ情報2100のうち、情報2104〜2111をクリアする、
を実行する。

0222

ステップ11010:実行部4500は、移動元に対応したすべてのパッケージグループ情報2300と移動先に対応したすべてのパッケージグループ情報2300とを更新する。具体的には、実行部4500は、移動元に対応したパッケージグループ情報2300内の実ページ数2303から移動元ページの数(例えば1)を減らし、移動先に対応したパッケージグループ情報2300内の実ページ数2303に、移動先ページの数を加算する。

0223

ステップ11011:実行部4500は、移動元に対応したすべてのフラッシュパッケージ情報2500と移動先に対応したすべてのフラッシュパッケージ情報2500とを更新する。具体的には、実行部4500は、例えば、以下の(a)及び(b):
(a)移動元に対応したそれぞれのフラッシュパッケージ情報2500内の下記(A)〜(F)のそれぞれの値から、移動先ページに対応した実ページ情報2100のうちの、それぞれのフラッシュパッケージ230に対応する下記(U)〜(Z)のそれぞれの値を減算する(つまり、(A)−(U)、(B)−(V)、(C)−(W)、(D)−(X)、(E)−(Y)、及び((F)−(Z))を行う);
(A)パッケージ内実ブロック割り当て数2505、
(B)パッケージ内追加実ブロック割り当て数2506、
(C)パッケージ内累積実ブロック割り当て時間2507、
(D)パッケージ内累積実ブロック消去回数2508、
(E)パッケージ内追加実ブロック割り当て時間2509
((F)パッケージ内累積ライトデータ量2510))
(U)実ブロック割り当て数2104、
(V)追加実ブロック割り当て数2105
(W)累積実ブロック割り当て時間2106、
(X)累積実ブロック消去回数2107
(Y)追加実ブロック割り当て時間2108
((Z)累積ライトデータ量2112))
(パッケージ内累積ライトデータ量2510と累積ライトデータ量2112は存在しない場合があるが、その場合、パッケージ内累積ライトデータ量2510から累積ライトデータ量2112が減算される処理は実行されない。)、
(b)移動元に対応したそれぞれのフラッシュパッケージ情報2500内の下記(G)〜(L)のそれぞれの値に、移動先ページに対応した実ページ情報2100のうちの、それぞれのフラッシュパッケージ230に対応する下記(O)〜(T)のそれぞれの値を加算する(つまり、(G)+(O)、(H)+(P)、(I)+(Q)、(J)+(R)、(K)+(S)、及び((L)+(T))を行う);
(G)パッケージ内実ブロック割り当て数2505、
(H)パッケージ内追加実ブロック割り当て数2506、
(I)パッケージ内累積実ブロック割り当て時間2507、
(J)パッケージ内累積実ブロック消去回数2508、
(K)パッケージ内追加実ブロック割り当て時間2509
((L)パッケージ内累積ライトデータ量2510))
(O)実ブロック割り当て数2104、
(P)追加実ブロック割り当て数2105
(Q)累積実ブロック割り当て時間2106、
(R)累積実ブロック消去回数2107
(S)追加実ブロック割り当て時間2108
((T)累積ライトデータ量2112))
(パッケージ内累積ライトデータ量2510と累積ライトデータ量2112が存在しない場合があるが、その場合には、パッケージ内累積ライトデータ量2510に累積ライトデータ量2112を加算する処理は実行されない。)、
を実行する。この後、ステップ11000へ戻る。

0224

(a)の累積割当て時間は、本実施形態よりも簡単に管理されても良い。例えば、直前回の上位レベルの長寿命化制御が行われてから今回の上位レベルの長寿命化制御が行われるまでの間に、割り当てられる実ブロックの数に変更があっても、その変更は適宜に無視されても良い。

0225

ストレージコントローラ200は、実ブロックの消去回数や割当て時間を、例えば、フラッシュパッケージ230から受ける情報を基に特定することができ、特定された消去回数及び割当て時間を、フラッシュパッケージ毎の累積割当て時間や全体消去回数に反映することができる。

0226

次に、フラッシュパッケージ230が実行する動作の説明を行う。フラッシュパッケージ230の動作は、パッケージコントローラ315(典型的にはパッケージプロセッサ310)が実行し、そのプログラムは、パッケージメモリ320内に格納されている。

0227

図26は、パッケージメモリ320に格納されているプログラムを示す。

0228

プログラムとして、例えば、データリード処理実行部12000、データライト処理実行部12100、実ブロック解放処理実行部12200、仮想ブロック移動処理実行部12300及び仮想ブロック格納処理実行部12400がある。これらのプログラムは、下位レベルのウエアレベリング制御及び容量仮想化機能を実現するためのプログラムである。前述したように、本実施形態では、フラッシュパッケージ230が、下位レベルのウエアレベリング制御及び容量仮想化機能を実現するが、それらはストレージコントローラ200で実現されてもよい。その場合、図27に示すように、図26に示したプログラムとほぼ同様のプログラムが、共有メモリ220に格納される。図27に示した構成では、これらの情報は、ストレージコントローラ200が実行するので、図26に示したそれぞれのプログラムとは、若干相違が生ずる。

0229

以下、パッケージメモリ320内のプログラム12000、12100、12200、12300及び12400を主語として説明する処理は、実際にはパッケージプロセッサ310が行う処理である。

0230

図28は、データリード処理実行部12000の処理フローを示す。

0231

データリード処理実行部12000は、ストレージコントローラ200から、リード指示を受け取ったときに、実行される。以下の説明では、一つの仮想ブロックからデータを読み出すことを例に採るが、図28の処理フローは、複数の仮想ブロックからデータを読み出すことにも有効である。

0232

ステップ13000:実行部12000は、受けたリード指示が指定するアドレスと、パッケージブロック容量3005とを基に、リード元となる仮想ブロックと、リード元仮想ブロック内の相対アドレスとを計算する。

0233

ステップ13001:実行部12000は、リード元の仮想ブロックに割り当てられている実ブロック(リード元実ブロック)に対応した実ブロック情報3300を、リード元仮想ブロックに対応した仮想ブロック情報3200内の実ブロック情報ポインタ3202から獲得する。

0234

ステップ13002:実行部12000は、以下の(a)及び(b):
(a)獲得した実ブロック情報3300内の実ブロックID3301から、そのID3301に対応する実ブロックの先頭が、どのフラッシュチップ300のどのアドレスであるかを特定する;
(b)(a)で特定されたアドレスと、上記獲得した実ブロック情報3300内の追加書き込みデータアドレス情報3305と、ステップ13000で得たリード指示でアクセス対象となる仮想ブロック内の相対アドレスとを基に、そのリード指示から特定された仮想ブロックが、当該フラッシュチップ300のどの当該アドレスに格納されているかを算出する、
を実行する。

0235

ステップ13003: 実行部12000は、リード対象のデータが格納されているフラッシュチップ300に対応したチップ情報3100を参照し、当該フラッシュチップ300が接続されているパッケージバス340を識別し、対応するパッケージバス転送装置350を認識する。

0236

ステップ13004: 実行部12000は、ステップ13003で認識したパッケージバス転送装置350に対して、どのフラッシュチップ300のどのアドレス(実ブロックのアドレス)からバッファ330にデータを転送するのかを、指示する。

0237

ステップ13005:実行部12000は、転送が完了するのを待つ。

0238

ステップ13006:実行部12000は、バッファ330に格納されたデータ(ストレージコントローラ200からのリード指示の対象のデータ)を、ストレージコントローラ200に送る。

0239

図29図30は、データライト処理実行部12100の処理フローを示す。

0240

データライト処理実行部12100は、フラッシュパッケージ230がストレージコントローラ200からライト指示を受け付けたときに実行される。以下の説明では、一つの仮想ブロックにデータを書き込むことを例に採るが、図29及び30の処理フローは、複数の仮想ブロックにデータを書き込むことにも有効である。

0241

ステップ14000: 実行部12100は、受けたライト指示が指定するアドレスと、パッケージブロック容量3005とを基に、ライト先の仮想ブロックとその仮想ブロックの相対アドレスとを計算する。

0242

ステップ14001:実行部12100は、上記ライト指示に付随するライト対象データを、バッファ330に格納する。

0243

ステップ14002:実行部12100は、ライト先仮想ブロックに対応する仮想ブロック情報3200内の実ブロック情報ポインタ3202を参照する。実行部12100は、そのポインタ3202の値がヌル値かどうか、すなわち、実ブロックが割り当てられているか否かを判断する。割り当てられていれば(その判断の結果が肯定的であれば)、ステップ14005へジャンプする。

0244

ステップ14003:本ステップは、ライト先仮想ブロックに空きブロックを割り当てるステップである。なお、ここでは、割り当てられる空きブロックは消去されていてデータは格納されていないものとする。実行部12100は、以下の(a)〜(e):
(a)各チップ情報3100のチップ内空きブロック数3103等を参照して、どのフラッシュチップ300空きブロックを割り当てるかを決める;
(b)決めた空きブロックを有するフラッシュチップ300に対応した空きブロック管理情報ポインタ3400を参照して、ライト先仮想ブロックに対応した実ブロック情報ポインタ3302を、先頭の実ブロック情報3300を示すよう更新する(これで、ライト先仮想ブロックに実ブロックを割り当てられたことになる);
(c)空きブロック管理情報ポインタ3400を、次の実ブロック情報3300(仮想ブロックに割り当てられた実ブロックに対応した実ブロック情報3300内の空きブロックポインタ3302が示す実ブロック情報3300)を示すよう更新する;
(d)ライト先仮想ブロックに割り当てられた実ブロックに対応する実ブロック情報3300内の空きブロックポインタ3302をヌル値にする;
(e)その割り当てられた実ブロックに対応するチップ情報3100内のチップ内空きブロック数3103の値から、割り当てられた実ブロックの数(例えば1)減算する、
を実行する。

0245

ステップ14004:実行部12100は、以下の(a)〜(c):
(a)上記ライト指示に付与されている時刻情報を、ライト先仮想ブロックに対応した仮想ブロック情報3200内の仮想ページ割り当て時刻3203に設定する;
(b)ライト先仮想ブロックに対応した仮想ブロック消去回数3204に0を設定する;
(c)バッファ330上に、パッケージブロック容量3005分の初期パターン(ストレージコントローラ200からライト対象データ(図29及び図30の説明において、ライト指示に付随するデータ)を受け取っていないことを意味するパターン)を生成する、
を実行する。ここで、ライト先仮想ブロックに割り当てられた実ブロック(図29及び図30の説明において「ライト先実ブロック」という)には、ライト対象データ以外は、この初期パターンが書き込まれることになる。これを実行するため、図30のステップ14016へジャンプする。

0246

ステップ14005:実行部12100は、ライト先実ブロックに対応する実ブロック情報3300内の実ブロックID3301を参照して、ライト先実ブロックの先頭が、どのフラッシュチップ300のどのアドレスであるかを特定する。

0247

ステップ14006:実行部12100は、ライト先実ブロックに対応する実ブロック内空き領域3304と、ライト対象データの長さとを基に、ライト対象データをライト先実ブロックの空き領域に書き込めるか否かを判断する。書き込めない場合(その判断の結果が否定的の場合)、図30のステップ14011へジャンプする。

0248

ステップ14007: 実行部12100は、ライト先実ブロックを有するフラッシュチップ300に対応したチップ情報3100を参照し、そのフラッシュチップ300が接続されているパッケージバス340を識別し、対応するパッケージバス転送装置350を認識する。

0249

ステップ14008: 実行部12100は、ステップ14007で認識したパッケージバス転送装置350に対して、どのフラッシュチップ300のどのアドレスにバッファ330からライト対象データを書き込むかを指示する。

0250

ステップ14009:実行部12100は、書き込みが完了するのを待つ。
ステップ14010:実行部12100は、以下の(a)〜(c):
(a)ライト先実ブロックに対応した実ブロック内空き領域3304から、ライト対象データの量を減算する;
(b)ライト先実ブロックに対応した追加書き込みデータアドレス情報3305に、ライト先実ブロック内の相対アドレスとライト対象データの長さとを加える;
(c)ストレージコントローラ200に、ライト指示が完了したことの完了報告を送信する、
を実行する。

0251

ステップ14011:本ステップは、ライト先実ブロックの空き領域よりもライト対象データの長さが大きい場合に実行されるステップである。この場合、ライト対象データは、ライト先実ブロックには、消去処理を実行することなしに、格納できない。本実施形態では、実ブロックの消去回数の偏りを少なくするために、ライト対象データは別の実ブロックに格納するようにする。したがって、本ステップでは、実行部12100は、下位レベルのウエアレベリング制御部をコールする。実行部12100は、下位レベルのウエアレベリング制御部から、ライト対象データを格納すべき実ブロックに対応する実ブロック情報3300のアドレスを受け取る。下位レベルのウエアレベリング制御は、実ブロックの消去回数の偏りを少なくするように、新しい実ブロックを選択する。その実ブロックは、例えば、消去された状態にあり、直接データを書き込めるような状態であるとする。なお、下位レベルのウエアレベリング技術は、特許文献1のような公知技術を適用すればよいため、ここでは詳細に説明しない。

0252

ステップ14012:実行部12100は、新たに指定された実ブロックに、ライト対象データだけでなく、ライト先仮想ブロックに元々割り当てられていた実ブロック(図29及び図30の説明において「元の実ブロック」と言う)内の全てのデータ(パッケージブロック容量3005分のデータ)を書き込む必要がある。このため、実行部12100は、元の実ブロックに対応した追加書き込みデータアドレス情報3205を参照して、元の実ブロックのパッケージブロック容量3005分の容量のデータを仮想ブロックのアドレス順にバッファ330に格納するため、フラッシュチップ300への指示を生成する。

0253

ステップ14013: 実行部12100は、ステップ14005で認識したフラッシュチップ300に対応したチップ情報3100を参照し、そのフラッシュチップ300が接続されているパッケージバス340を識別し、対応するパッケージバス転送装置350を認識する。

0254

ステップ14014: 実行部12100は、ステップ14007で認識したパッケージバス転送装置350に、ステップ140011で生成した指示にしたがって、どのフラッシュチップ300のどのアドレスからバッファ330にデータを読み込むかを指示する。

0255

ステップ14015:実行部12100は、バッファ330への読み込みが完了するのを待つ。

0256

ステップ14016:実行部12100は、新たに割り当てた実ブロックにパッケージブロック容量3005分のデータを書き込む。具体的には、本ステップでは、実行部12100は、ステップ14004、あるいは、ステップ14014で、バッファ330に格納したパッケージブロック容量3005分のデータ(ステップ14004で格納したのは初期パターンのデータ)に対し、ストレージコントローラ200から受けたライト対象データを、ステップ14000で認識した相対アドレスから上書きする。

0257

ステップ14017:次に、実行部12100は、新たに割り当てた実ブロックに対応する実ブロック情報3300内の実ブロックID3301を参照して、新たに割り当てた実ブロックがどのフラッシュチップ300のどのアドレスに格納するかを特定する。

0258

ステップ14018: 実行部12100は、ステップ14017で認識したライト対象データを格納するフラッシュチップ300に対応したチップ情報3100を参照し、そのフラッシュチップ300が接続されているパッケージバス340を識別し、対応するパッケージバス転送装置350を認識する。

0259

ステップ14019: 実行部12100は、ステップ14018で認識したパッケージバス転送装置350に、どのフラッシュチップ300のどのアドレスへバッファ330からパッケージブロック容量3005分のデータを書き込むかを指示する。

0260

ステップ14020:実行部12100は、バッファ330からの書き込みが完了するのを待つ。

0261

ステップ14021:実行部12100は、元の実ブロックにライト対象データを格納できないために新しい実ブロックを割り当てた場合、ステップ14022及び14023を行う。そうではない場合、ステップ14024へジャンプする。

0262

ステップ14022:本ステップは、実行部12100は、実ブロックを空いた状態にするステップである。実行部12100は、以下の(a)〜(f):
(a)元の実ブロックに対して消去処理を行う;
(b)元の実ブロックに対応した実ブロック消去回数3306の値に1を加算する;
(c)実ブロック消去回数3306が上限値を超えた場合、元の実ブロックに対応する実ブロック障害フラグ3303をONにし、上記のライト指示に起因して障害状態になった実ブロックが発生したことを記憶する;
(d)元の実ブロックが割り当てられていた仮想ブロックに対応する仮想ブロック消去回数3204の値に1を加算する;
(e)元の実ブロックに対応する空きブロックポインタ3302に、空きブロック管理情報ポインタ3400が示していた実ブロック情報3300のアドレスを設定する;
(f)空きブロック管理情報ポインタ3400には、元の実ブロックに対応する実プロック情報3300のアドレスを設定する;
を実行する。

0263

ステップ14023:本ステップは、新たな実ブロックをライト先仮想ブロックに割り当てるステップである。具体的には、実行部12100は、ライト先仮想ブロック対応する実ブロック情報ポインタ3202を、新たな実ブロックに対応した実ブロック情報3300を示す値に更新する。

0264

ステップ14024:実行部12100は、ストレージコントローラ200に対して、ライト完了報告を送信する。その完了報告は、例えば、ストレージコントローラ200からのライト指示に伴って消去処理が施された実ブロックがあれば、その実ブロックの数を含む。また、その完了報告は、そのライト指示に伴って障害状態になった実ブロックがあれば、その実ブロックの数を含む。また、ステップ14004で、仮想ブロックに、実ブロックを割り当てていない状態から、新たに実ブロックを割り当てた場合、その割り当てた個数と、ライト指示に含まれていた時刻情報も、ストレージコントローラ200に対する完了報告に含まれる。

0265

図31は、実ブロック解放処理実行部12200の処理フローを示す。

0266

実ブロック解放処理実行部12200は、ストレージコントローラ200から、領域の範囲(仮想ブロックの集合)を解放せよという解放指示を受け付けたときに実行する。

0267

ステップ15000:実行部12200は、解放指示で指定された領域の範囲とパッケージブロック容量3005とを基に、解放を指示された仮想ブロックの集合を算出する。

0268

ステップ15001:実行部12200は、ステップ15000で特定した仮想ブロックの集合に対し、それぞれの仮想ブロックに対応する仮想ブロック情報3200の実ブロック情報ポインタ3202を参照し、実ブロックが割り当てられているか否かを判断する。ここでは、実行部12200は、指定されたすべての仮想ブロックに対して、それぞれの仮想ブロックに実ブロックが割り当てられているか否かを示す情報を作成する。実行部12200は、作成した情報を、ストレージコントローラ200に送るため、バッファ330に書き込む。

0269

ステップ15002:実行部12200は、ステップ15000で特定した仮想ブロックの集合のうちの、実ブロックが割り当てられている仮想ブロックを探す。なければ、ステップ15006へジャンプする。

0270

ステップ15003:実行部12200は、見つかった仮想ブロックに対応する実ブロック情報ポインタ3202が示す実ブロック情報3300に対応する実ブロックの解放処理を行う。このため、実行部12200は、その実ブロック情報3300内の実ブロックID3301を解析し、解放する実ブロックが、どのフラッシュチップ1302のどのアドレスに存在するかを特定する。

0271

ステップ15004:本ステップは、実ブロックを空いた状態にするステップである。対象となる実ブロックは、ステップ15003で特定された実ブロックであるが、処理内容は、図30のステップ14022と同じである。このため、ここでは説明を省略する。

0272

ステップ15005:実行部12200は、空いた状態にされた実ブロックに割り当てられていた仮想ブロック(空き仮想ブロック)に対応する仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204を、バッファ330へコピーする。それらの情報3203及び3204をストレージコントローラ200に送るためである。コピー後、実行部12200は、空き仮想ブロックに対応する仮想ブロック情報2000内の仮想ページ割り当て時刻3203及び仮想ブロック消去回数3204を初期化する。この後、ステップ15002に戻る。

0273

ステップ15006:実行部12200は、ストレージコントローラ200に、下記情報(A)及び(B)の情報:
(A)解放指示で指定された領域の範囲に属する仮想ブロックごとに、実ブロックが割り当てられていたか否かを示す情報;
(B)解放された実ブロックが割り当てられていた仮想ブロック毎の、仮想ブロック割り当て時刻3203と仮想ブロック消去回数3204、
を含んだ解放完了報告を、ストレージコントローラ200に送る。

0274

図32は、仮想ブロック移動処理実行部12300の処理フローを示す。

0275

仮想ブロック移動処理実行部12300は、ストレージコントローラ200から、指定された仮想ブロックの集合に格納されているデータをストレージコントローラ200に送る指示を受けたときに、実行する。移動されたデータを格納していた実ブロックは解放されるので、図31と異なるのは、実ブロックに格納されていたデータをストレージコントローラ200に送る点である。このため、図31の処理フローの各ステップを引用しながら、図32の説明を行う。

0276

ステップ16000:ステップ15000と同様。実行部12300は、解放を指示された仮想ブロックの集合を特定する。

0277

ステップ16001:ステップ15001と同様。実行部12300は、指定されたすべての仮想ブロックについて、実ブロックが割り当てられているか否かを示す情報を作成し、その情報をバッファ330にコピーする。

0278

ステップ16002:ステップ15002と同様。実行部12300は、実ブロックが割り当てられている仮想ブロックを探す。なければ、ステップ16010へジャンプする。

0279

ステップ16003:基本的にはステップ15003と同様。このため、実行部12300は、移動元の実ブロックに対応する実ブロックID3301を解析し、移動元の実ブロックが、どのフラッシュチップ300のどのアドレスから存在するかを特定する。

0280

ステップ16004:実行部12300は、移動元の実ブロックに対応する実ブロック情報3300の先頭アドレスと、その情報3300内の追加書き込みデータアドレス情報3305と、ステップ16003で得た格納先アドレスとを基に、アドレスリストを作成する。そのアドレスリストは、移動元の実ブロックについてのアドレスのリストであって、ストレージコントローラ200に送るべきパッケージブロック容量3005分のデータが格納されているアドレスのリストである。

0281

ステップ16005: 実行部12300は、移動元の実ブロックを有するフラッシュチップ300に対応したチップ3100情報を参照し、そのフラッシュチップ300が接続されているパッケージバス340を識別し、対応するパッケージバス転送装置350を認識する。

0282

ステップ16006: 実行部12300は、ステップ16005で認識したパッケージバス転送装置350に、移動元の実ブロックを有するフラッシュチップ300にアドレスリストを渡し、且つ、そのアドレスリストにしたがってバッファ330にデータを転送することを指示する。

0283

ステップ16007:実行部12300は、転送が完了するのを待つ。

0284

ステップ16008:本ステップは、実ブロックを空いた状態にするステップである。対象となる実ブロックは、移動元の実ブロックであるが、処理内容は、図30のステップ14022と同じである。このため、ここでは、説明を省略する。

0285

ステップ16009:ステップ15005と同様。実行部12300は、空いた状態にされた実ブロックに割り当てられていた仮想ブロック(空き仮想ブロック)に対応する仮想ブロック割り当て時刻3203及び仮想ブロック消去回数3204を、バッファ330へコピーする。コピー後、実行部12300は、空き仮想ブロックに対応する仮想ブロック情報2000内の仮想ページ割り当て時刻3203及び仮想ブロック消去回数3204を初期化する。この後、ステップ16002に戻る。

0286

ステップ16010:実行部12300は、ストレージコントローラ200へ、バッファ330に格納されたデータを送る。具体的には、例えば、実行部12300は、下記情報(A)〜(C)の情報:
(A)移動元の仮想ブロックごとに、実ページが割り当てられていたか否かを示す情報;
(B)解放された実ブロックが割り当てられていた仮想ブロック毎の、仮想ページ割り当て時刻3203と仮想ブロック消去回数3204;
(C)バッファ330に格納されたデータ(移動元の仮想ブロックに割り当てられていた実ブロック内のデータ)、
を含んだ完了報告を、ストレージコントローラ200に送る。

0287

図33は、仮想ブロック格納処理実行部12400の処理フローを示す。

0288

仮想ブロック格納処理実行部12400は、指定された仮想ブロックの集合に、実ブロックをそれぞれ割り当て、且つ、ストレージコントローラ200から送られてきたデータを格納せよというライト指示を受けたときに、実行する。仮想ブロック移動処理実行部12300とは、データの流れが逆であるが、共通点が多いので、図32の処理フローの各ステップを引用しながら説明を行う。

0289

ステップ17000:ステップ16000と同様。実行部12400は、格納を指示された仮想ブロックの集合を算出する。

0290

ステップ17001:フラッシュパッケージ230内のパッケージコントローラ315が、ストレージコントローラ200から、以下の(A)〜(C)を含んだ情報:
(A)格納先の仮想ブロックの集合のうちの各仮想ブロックについて、実ブロックが割り当てられていたか否かを示す情報;
(B)実ブロックが割り当てられていたすべての仮想ブロックに関して、その仮想ブロック全体のデータ(具体的には、その仮想ブロックに割り当てられていた実ブロック内のデータ)、
(C)実ブロックが割り当てられていた仮想ブロックに対応した仮想ページ割り当て時刻3203及び仮想ブロック消去回数3204、
を受ける。その情報は、バッファ330に格納される。さらに、パッケージコントローラ315(パッケージプロセッサ310)は、仮想ブロック毎の情報(実ブロックが割り当てられるか否かを示す情報)を、バッファ330から取得する。

0291

ステップ17002:ステップ16002と同様。実行部12400は、取得した情報を基に、実ブロックが割り当てられていた仮想ブロックを探す。なければ、ステップ17010へジャンプする。

0292

ステップ17003:実行部12400は、ステップ17002で見つかった仮想ブロックに空きブロックを割り当てる。この処理は、図29のステップ14003と同様であるので、詳細な説明は省略する。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ