(57)【特許請求の範囲】
【請求項１】
プロセッサと、メモリと、を有し、ストレージデバイスに対してデータの入出力を行う情報処理システムにおいて、
前記メモリは、バッファ領域とキャッシュ領域を有し、
前記プロセッサは、ライト処理を行い、
前記ライト処理は、
受信したライト要求にかかる新データを前記メモリに格納することと、
前記新データによって更新される旧データと、前記旧データにかかる旧パリティを、前記ストレージデバイスから読み出して、前記メモリに格納することと、
前記新データと、前記旧データと、前記旧パリティとに基づいて、前記新データにかかる新パリティを生成して前記メモリに格納することと、
前記新データと、前記新パリティと、を前記ストレージデバイスに格納することと
を含み、
前記プロセッサは、前記新データを前記メモリのバッファ領域に格納する第１のライト処理と、前記新データを前記メモリのキャッシュ領域に格納する第２のライト処理と、を選択的に実行可能であり、
前記第１のライト処理を実行中の新データについてリード要求を受信した場合、前記プロセッサは、前記第１のライト処理を第２のライト処理に切り替え、前記第２のライト処理にて前記キャッシュ領域に格納した新データを、前記リード要求の要求元に送信する、
情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記プロセッサは、前記新データのライト要求を受信すると、前記第１のライト処理を行う場合、前記第１のライト処理において、前記メモリ内に、前記新データ、前記旧データ、前記旧パリティ、および、前記新パリティを格納するための格納領域を確保し、前記格納領域を確保した後に、前記新データを受領する、
情報処理システム。
【請求項３】
請求項１又は２に記載の情報処理システムにおいて、
前記プロセッサは、さらに、前記第１のライト処理において、前記新パリティを、前記バッファ領域内に格納する、
情報処理システム。
【請求項４】
請求項１乃至３のうちのいずれか１項に記載の情報処理システムにおいて、
前記プロセッサは、前記第１のライト処理において、前記新データ及び前記新パリティを前記ストレージデバイスに格納すると、前記バッファ領域内に格納した前記旧データおよび前記旧パリティを、前記バッファ領域から削除する、
情報処理システム。
【請求項５】
請求項１乃至４のうちのいずれか１項に記載の情報処理システムにおいて、
前記プロセッサは、前記第１のライト処理において、前記新データおよび前記新パリティを、前記キャッシュ領域に格納する、
情報処理システム。
【請求項６】
請求項１乃至５のうちのいずれか１項に記載の情報処理システムにおいて、
前記プロセッサは、前記第１のライト処理において、前記新データを前記キャッシュ領域に格納した場合に、応答を前記ライト要求の送信元に送信し、前記応答の送信の後に、前記新パリティの生成を行う、
情報処理システム。
【請求項７】
請求項１乃至５のうちのいずれか１項に記載の情報処理システムにおいて、
前記プロセッサは、前記第１のライト処理において、前記新データを前記キャッシュ領域に格納した場合に、応答を前記ライト要求の送信元に送信し、
前記プロセッサは、前記応答の送信とは非同期に前記新パリティの生成を行う、
情報処理システム。
【請求項８】
請求項１乃至７のうちのいずれか１項に記載の情報処理システムにおいて、
前記ストレージデバイスは、データを格納する第１のストレージデバイスと、パリティを格納する第２のストレージデバイスとを有し、
前記第１のストレージデバイスは、前記旧データを読み出すとともに、前記新データを格納し、
前記第２のストレージデバイスは、前記旧パリティを読み出すとともに、前記新パリティを格納する、
情報処理システム。
【請求項９】
プロセッサと、メモリと、を有する情報処理システムが、ストレージデバイスに対してデータの入出力を行う情報処理方法において、
前記メモリは、バッファ領域とキャッシュ領域を有し、
前記プロセッサは、ライト処理を行うようになっており、
前記ライト処理は、
受信したライト要求にかかる新データを前記メモリに格納することと、
前記新データによって更新される旧データと、前記旧データにかかる旧パリティを、前記ストレージデバイスから読み出して、前記メモリに格納することと、
前記新データと、前記旧データと、前記旧パリティとに基づいて、前記新データにかかる新パリティを生成して前記メモリに格納することと、
前記新データと、前記新パリティと、を前記ストレージデバイスに格納することと
を含み、
前記プロセッサは、前記新データを前記メモリのバッファ領域に格納する第１のライト処理と、前記新データを前記メモリのキャッシュ領域に格納する第２のライト処理と、を選択的に実行可能であり、
前記情報処理方法において、
前記第１のライト処理を実行中の新データについてリード要求を受信した場合、前記プロセッサは、前記第１のライト処理を第２のライト処理に切り替え、
前記プロセッサは、前記第２のライト処理にて前記キャッシュ領域に格納した新データを、前記リード要求の要求元に送信する、
情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ライト性能を高速化する情報処理システムに関する。
【背景技術】
【０００２】
近年、インターネットバンキングや電子商取引で利用されるＯＬＴＰ（Online Transaction Process）処理される大量のデータを蓄積するデータベース（Database、DB）としてストレージ装置の記憶デバイスに高速アクセス可能なＮＡＮＤ型フラッシュメモリを記憶媒体とするＳＳＤ（Solid State Drive）の採用が増加している。ＯＬＴＰ処理は、リアルタイムに大量のデータを高速にリード／ライトする必要がある。ＳＳＤはＨＤＤ（Hard Disk Drive）と比較して高速にアクセスすることができ、ストレージ装置の記憶デバイスとして搭載することで、ストレージ装置を高速化できる。
【０００３】
特許文献１には、ユーザデータにパリティ等の冗長データを付与してＨＤＤに記憶するストレージ装置の高速化技術として、高速アクセス可能なＤＲＡＭ（Dynamic Random Access Memory）をキャッシュメモリとして利用し、ライト処理を高速化する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】ＵＳ２０１１／０１５３９５４号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１には、ＤＲＡＭをキャッシュメモリとして利用し、ライト処理を高速化する技術として、下記の技術が記載されている。
【０００６】
ホストからライト要求があったデータ（以下、新データ）をＨＤＤに格納する前にキャッシュメモリに格納し、キャッシュメモリに格納するとホストにライト要求に対する応答を返す。そして、ホストからのライト要求とは非同期のタイミングで、ＨＤＤに格納未済みの新データをキャッシュメモリの中から探し出し、新データに関するパリティを生成し、新データと生成したパリティをＨＤＤに格納する。
【０００７】
要求に対する応答と、パリティ生成処理を非同期で行うと、ライト要求を受けてからホスト応答までの処理とパリティ生成してからＨＤＤにデータを格納する処理の開始および終了する際に、それぞれの処理に必要なキャッシュメモリの領域を確保したり、解放したりする処理を重複して行わなければならなかったり、パリティ生成してからＨＤＤにデータを格納する処理の際に、ＨＤＤに格納未済みのデータをキャッシュメモリから探し出す、というキャッシュ制御のオーバーヘッドが発生する。
【０００８】
ＨＤＤでは、上述のキャッシュ制御のオーバーヘッドによるプロセッサの処理効率の低下は問題にならなかったが、高速なＳＳＤでは目立つようになった。
【０００９】
そこで、本発明では、ＳＳＤを利用したストレージシステムの高速化のため、キャッシュ制御によるオーバーヘッドを削減し、プロセッサの負荷を抑制することを目的としている。
【課題を解決するための手段】
【００１０】
上記課題を解決するための一例として、下記の構成がある。
【００１１】
プロセッサとメモリと複数のドライブと、を有し、
前記プロセッサは、
（１）新データのライト要求を受信すると、
（２）前記新データを前記メモリに格納し、
（３）前記ライト要求に対する応答を前記ライト要求の送信元に送信し、
（４）前記応答を送信したことに応じて、前記複数のドライブのうちの第一のドライブから前記新データによって更新される旧データと、前記複数のドライブのうちの第二のドライブから前記旧データに関する旧パリティと、を読み出して、前記メモリに格納し、
（５）前記メモリに格納した前記新データ、前記旧データ、前記旧パリティから、前記新データに関する新パリティを生成し、
（６）前記新データを前記第一のドライブに格納し、前記新パリティを前記第二のドライブに格納する、
システム。
【発明の効果】
【００１２】
キャッシュ制御によるオーバーヘッドを削減し、プロセッサの負荷を抑制することで、単位時間当たりに処理可能なＩ／Ｏ要求数が増加し、ストレージシステムの高速化が実現できる。
【図面の簡単な説明】
【００１３】
【図１】実施例１の概略図
【図２】実施例１のストレージシステムの構成の一例を示す図
【図３】実施例１のＬＤＥＶページ管理テーブルの一例を示す図
【図４】実施例１のＪＯＢ＃管理テーブルの一例を示す図
【図５】実施例１のバッファ管理情報の一例を示す図
【図６】実施例１のバッファ領域管理の一例を示す図
【図７】実施例１のキャッシュディレクトリ情報の一例を示す図
【図８】実施例１のキャッシュブロック管理情報の一例を示す図
【図９】実施例１のキャッシュ領域管理の一例を示す図
【図１０】実施例１のライト処理フローの一例を示す図
【図１１】実施例１の高速ライト処理フローの一例を示す図
【図１２】実施例１の通常ライト処理Frontend処理フローの一例を示す図
【図１３】実施例１の通常ライト処理Backend処理フローの一例を示す図
【図１４】実施例１のエラー検出処理フローの一例を示す図
【図１５】実施例１のリード処理フローの一例を示す図
【図１６】実施例１の通常ライト切り替え処理フローの一例を示す図
【図１７】実施例２の高速ライト処理フローの一例を示す図
【図１８】実施例２の他の高速ライト処理フローの一例を示す図
【図１９】実施例２の他の高速ライト処理フローの一例を示す図
【図２０】実施例３の概要図
【図２１】実施例３のフラッシュドライブの構成の一例を示す図
【図２２】実施例３の高速ライト処理フローの一例を示す図
【図２３】実施例３の通常ライト切り替え処理フローの一例を示す図
【図２４】実施例１におけるメニュー画面、管理画面の一例を示す図
【発明を実施するための形態】
【００１４】
以下、実施例を説明する。
【実施例１】
【００１５】
＜概要＞
図１は、本実施例の概要を示す図である。
ストレージシステム４２は、プロセッサ１４とメモリ１８を含むストレージコントローラ１２と、複数のドライブ２６を有し、例えば、ＳＡＮ（Storage Area Network）のような通信ネットワークを介してホスト１０と接続される。
【００１６】
以下の説明において、ライト処理においてプロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて、新パリティを生成し、新データと新パリティをドライブ２６に格納することを、「高速ライト処理」という。以下、ストレージシステム４２のプロセッサ１４がホスト１０からライト要求を受信した場合に行われる「高速ライト処理」について説明する。
【００１７】
プロセッサ１４は、（１）ホスト１０から新データ１００のライト要求を受けると、（２）新データ１００をメモリ１８の所定の領域に格納し、（３）ライト要求に対する応答をホスト１０に送信する。（４）ホスト１０に応答を送信したことに応じて、新データ１００によって更新される旧データ１０２と、旧データに関する旧パリティ１０４と、をそれぞれ格納しているドライブ２６からメモリ１８に読み出す。
【００１８】
（５）新データ１００と、読み出した旧データ１０２、旧パリティ１０４から新データ１００に関する新パリティ１０６を生成し、（６）旧データ１０２と旧パリティ１０４が格納されていたそれぞれのドライブ２６に新データ１００と新パリティ１０６を格納する。以上、で高速ライト処理を終了とする。
【００１９】
本実施例の高速ライト処理は、プロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて、新パリティを生成し、新データと新パリティをドライブ２６に格納する。本実施例の高速ライト処理により、ホストからのライト要求に対する応答と、パリティ生成処理を非同期で行うと、ＦＥ処理とＢＥ処理のそれぞれの開始、終了の際に、それぞれの処理に必要なキャッシュメモリの領域を確保したり、解放したりする処理を重複して行わなければならなかったり、ＢＥ処理の際に、ＨＤＤに格納未済みのデータをキャッシュメモリから探し出す、というキャッシュ制御のオーバーヘッドを削減し、プロセッサの負荷を抑制することで、単位時間当たりに処理可能なホストからの要求数が増加し、ストレージシステムの高速化が実現できる。
【００２０】
たとえば、ストレージシステム４２に搭載するディスクが全てフラッシュドライブであるＡＦＡ（All Flash Array）においては、本実施例の高速ライト処理によりデータに対する書き込みを高速処理することができるため、フラッシュドライブの性能を引き出し、システム性能を向上することが出来る。
【００２１】
また、本実施例では、新データ１００をメモリ１８の所定の領域に格納したら、パリティ生成の処理に入る前に、先にライト要求に対する応答をホスト１０に送信することもできるため、速いレスポンスが求められるＯＬＴＰ処理向けデータベースに適している。
【００２２】
よって、本実施例によりユーザに対し高性能な大容量データベース向けプラットフォームを提供することが可能となる。
【００２３】
以上が本実施例の概要である。以下、本実施例を詳細に説明する。
【００２４】
＜詳細説明＞
まず、従来技術のＤＲＡＭをキャッシュメモリとして利用する技術の課題を説明する。ＤＲＡＭをキャッシュメモリとして利用し、ライト処理を高速化する技術では、要求に対する応答と、パリティ生成処理を非同期で行うことのほかに、キャッシングについて記載されている。キャッシングとは、キャッシュメモリに、ホストからのアクセス頻度が高いデータを、ＨＤＤから読み出して格納しておくことで、ホストからＩ／Ｏ（Input / Output）要求があった場合に、当該要求に関するデータがキャッシュメモリに格納されていれば、ＨＤＤに直接アクセスするよりも処理を高速化することができる、という技術である。そのため、プロセッサはまず、キャッシュメモリに当該要求に関するデータが格納されているか否かを探索する。
【００２５】
しかし、ライト処理高速化のためのキャッシュメモリの制御のためにプロセッサのオーバーヘッドが発生するという課題がある。
【００２６】
オーバーヘッドとは、たとえば、キャッシュメモリに格納されているデータの管理である。データを管理するためには、データを探し出すための、多くの管理情報の作成および更新が必要となる。また、新データに関するパリティを生成する際には、生成に必要なデータをＨＤＤから読出してキャッシュメモリに格納するため、生成に必要なデータについても管理情報の作成または更新が必要である。他に、要求に対する応答とは非同期のタイミングでキャッシュメモリからＨＤＤにデータを格納するために、ＨＤＤにデータを格納する際に、多くの管理情報に基づいてＨＤＤに格納されていないデータを探し出す、という処理もオーバーヘッドになる。
【００２７】
そこで、本実施例では、上述のキャッシュ制御によるオーバーヘッドを削減し、プロセッサの負荷を抑制するための構成について説明する。
【００２８】
図２は、本実施例のストレージシステムの構成例を示す図である。
【００２９】
ストレージシステム４２は、ストレージコントローラ１２と、ドライブグループ２８を有する。ストレージコントローラ１２は、故障時に備えてＮ重（Ｎは２以上の整数）に冗長化される。冗長度は設計ポリシーに依存し、本実施例では、ストレージコントローラ１２を二重化した例を示す。
【００３０】
ストレージコントローラ１２は、プロセッサ１４とメモリ１８と、通信インターフェースとしてＦＥ  Ｉ／Ｆ５２とＢＥ  Ｉ／Ｆ５４を有する。
ＦＥ  Ｉ／Ｆ５２は、図１のホスト１０と通信ネットワークを介して接続されており、外部デバイスと通信するためのインターフェースデバイスである。ストレージコントローラ１２は、ＦＥ  Ｉ／Ｆ５２を介して、ホスト１０からのＩ／Ｏ（リード、または、ライト）要求を受信する。ＢＥ  Ｉ／Ｆ５４は、ストレージコントローラ１２がドライブ２６と通信するためのインターフェースデバイスである。
【００３１】
メモリ１８は、プログラム領域２４、バッファ領域２０、キャッシュ領域２２、管理テーブル領域３０を有する。本実施例では、メモリ１８は、ＤＲＡＭにより構成されが、その他に、例えばＳＲＡＭ（Static Random Access Memory）などでも良い。  プログラム領域２４には、たとえばライトプログラム、リードプログラムなど、ストレージ制御プログラムが格納されている。
プロセッサ１４は、メモリ１８のプログラム領域２４に格納されているプログラムを実行することで、各種処理を実施する。
【００３２】
バッファ領域２０は、ホスト１０からライト要求があったデータ（以下、新データ）や、ドライブ２６から読み出されたデータが一時的に格納される記憶領域である。バッファ領域２０から読み出されたデータは、バッファ領域２０から削除、または削除可能な状態にされるようになっている。
【００３３】
キャッシュ領域２２にも、新データや、ドライブ２６から読み出されたデータが一時的に格納される。本実施例では、キャッシュ領域２２からデータが読み出されたからといって、必ずしもキャッシュ領域２２からデータが削除されるわけではない点が、バッファ領域２０との違いの一つである。
【００３４】
本実施例において、バッファ領域２０とキャッシュ領域２２において、ホスト１０からのライトからのライト要求に基づいてドライブ２６に格納される新データがキャッシュ領域書き込まれる領域を「ライト面」、ドライブ２６から読み出されたデータが書き込まれる領域を「リード面」と表現する場合がある。本実施例の説明において特段説明が無い場合、ライト面およびリード面は、バッファ領域２０またはキャッシュ領域２２に存在する。
【００３５】
管理テーブル領域３０は、バッファ領域管理テーブル３２、キャッシュ領域管理テーブル３４、キャッシュディレクトリ管理テーブル３５、ＬＤＥＶページ管理テーブル３６、ＪＯＢ＃管理テーブル３８が格納されている。これらのテーブルの詳細は、後述する。
【００３６】
ドライブグループ２８は、複数のドライブ２６とＳＷ（Switch）５６を有する。それぞれのドライブ２６は、ＳＷ５６を介してストレージコントローラ１２のＢＥ  Ｉ／Ｆ５４に接続される。本実施例では、ドライブ２６は、例えばＳＳＤのような高速アクセス可能な記憶デバイスを想定しているが、ＨＤＤなど他の種類の記憶デバイスとの混在でも良い。また、ドライブグループ２８は、異なる種類の記憶デバイス、たとえば、ＳＳＤとＨＤＤとを有していていも良い。
【００３７】
なお、本実施例では、ＮＡＮＤ型フラッシュメモリを記憶媒体とするＳＳＤを例とするが、記憶媒体は追記型の不揮発性半導体メモリであればよく、例えばＭＲＡＭ（Magnetic Random Access Memory：磁気抵抗メモリ）、ＰＲＡＭ（Phase Change Random Access Memory：相変化メモリ）、ＲｅＲＡＭ（Resistance Random Access Memory：抵抗変化メモリ）などであってもよい。  なお、本実施例ではホスト１０が通信ネットワークを介してストレージコントローラ１２に接続されている例を示すが、ストレージシステム４２のハードウェア構成は、サーバと同様の構成であってもよい。たとえば上の実施例で説明したストレージシステム４２に代えて、パーソナルコンピュータ等の汎用のコンピュータ（以下、これを単に「コンピュータ」と呼ぶ）に複数のドライブ２６または複数のドライブグループ２８を搭載（または接続）し、コンピュータ上で、上で説明した各種プログラムを実行させてもよい。この場合、コンピュータがサーバからＩ／Ｏ要求を受け付けて、ドライブへのデータの格納、またはドライブからのデータの読み出しを行う。
【００３８】
また、コンピュータ上で、上で説明した各種プログラムを実行させる構成の場合、上で述べた実施例で説明した、実ストレージシステム上で実行される各種プログラムとサーバで実行されるプログラムがいずれも、同一コンピュータ上で実行されるように構成されていてもよい。この場合、たとえば仮想マシンを形成するハイパーバイザプログラムをコンピュータ上で実行することで、コンピュータ上に少なくとも、サーバで実行されるプログラムを実行する仮想マシンと、上の実施例で説明した各種プログラムを実行する仮想マシンとを形成するとよい。
【００３９】
図３は、本実施例にかかるＬＤＥＶページ管理テーブル３６の一例を示す。ホスト１０からのＩ／Ｏ要求には、Ｉ／Ｏ先情報が含まれる。Ｉ／Ｏ先情報とは、ライト要求の場合は新データを格納するＬＤＥＶ＃２００とＬＤＥＶ内のアドレス、リード要求の場合は読み出したいデータが格納されているＬＤＥＶ＃２００とＬＤＥＶ内のアドレスを表す情報である。
【００４０】
ＬＤＥＶページ管理テーブル３６には、ストレージシステム４２内に作成された論理Ｖｏｌｕｍｅ（図示しない）であるＬＤＥＶ＃２００の情報が管理されている。ＬＤＥＶは、一定サイズのブロックと呼ばれる単位で論理的に管理され、各ブロックにはブロック＃２０２が付与されている。ブロックよりもさらに小さいサイズのものをサブブロックと定義し、これらにもサブブロック＃２０４が付与されている。ＬＤＥＶページ管理テーブル３６では、各サブブロック＃２０４に対し、メモリ１８上のデータ格納位置を表す物理アドレスの先頭アドレス＃２０６、格納先のドライブ種別２０８、ライト処理中かどうかを識別するライト処理中フラグ２１０、が管理されている。図３において、ドライブ種別２０８にはＳＳＤのみが記載されているが、これは一例である。
【００４１】
図４は、本実施例に係るＪＯＢ＃管理テーブル３８の一例を示す。ＪＯＢとは、１Ｉ／Ｏを処理するためにストレージソフトウェアが実行するプログラムの単位で、各ＪＯＢはプロセッサ１４内で一意に特定できるＪＯＢ＃を持っている。本実施例では、Ｉ／Ｏ処理が高速ライト処理である場合には、ＪＯＢ＃２３０の他に、高速ライトＪＯＢ＃２３１が付与される。
【００４２】
ＪＯＢ＃管理テーブルは、空きＪＯＢ＃キュー２２６、空き高速ライトＪＯＢ＃キュー２２７、ＪＯＢアクセス先情報２２８、を有する。
ＪＯＢ＃、高速ライトＪＯＢ＃はキューで管理され、プロセッサ１４は、ホスト１０からＩ／Ｏ要求を受信すると、空きＪＯＢ＃キュー２２６からデキューしてＪＯＢ＃を取得する。空きＪＯＢ＃キュー２２６にＪＯＢ＃０とＪＯＢ＃１がエンキューされている状態を示している。例えば、ＪＯＢ＃２に係るＩ／Ｏ要求の処理が終了するとＪＯＢ＃２が返却され、ＪＯＢ＃２が空きＪＯＢ＃キューポインタ２２０へエンキューされる。
【００４３】
高速ライト処理する場合は、さらに、空き高速ライトＪＯＢ＃キュー２２７からデキューして高速ライトＪＯＢ＃を取得する。高速ライトＪＯＢ＃も、ＪＯＢ＃と同様に空き管理され、高速ライトＪＯＢ＃２に係るＩ／Ｏ要求の処理が終了すると高速ライトＪＯＢ＃２が返却され、高速ライトＪＯＢ＃２が空き高速ライトＪＯＢ＃キューポインタ２２１へエンキューされる。
【００４４】
ＪＯＢアクセス先情報２２８は、取得したＪＯＢ＃のアクセス先を管理される。ＪＯＢ＃２３０に対し、Ｉ／Ｏ先であるＬＤＥＶの先頭サブブロック＃２３２、Ｉ／Ｏデータのデータサイズ２３４、高速ライトＪＯＢ＃２３１の情報が格納されている。
【００４５】
なお、本実施例では上述のように、通常のＩ／Ｏ処理と高速ライト処理を区別するため、高速ライト処理の場合には、ＪＯＢ＃と高速ライトＪＯＢ＃の両方を付与する。高速ライト処理に必要なプロセッサやメモリなどのリソースの使用量に応じて高速ライト処理を実行できる処理数、すなわち、高速ライトＪＯＢ＃の数を制限しているためである。
しかし、高速ライト処理の場合にも、ＪＯＢ＃だけの付与でもよく、高速ＪＯＢ＃の付与のための処理の簡略化や、ＪＯＢアクセス先情報２２８の情報量を簡素化することが可能である。
【００４６】
図５、６を用いて、本実施例におけるバッファ領域２０の管理、図７〜９を用いて本実施例におけるキャッシュ領域の管理、について説明する。本実施例の高速ライト処理は、新データ、旧データ、旧パリティ、新パリティを、バッファ領域２０に格納する。
【００４７】
図５は、本実施例に係るバッファ領域管理情報１７０の図である。バッファ領域２０は、所定の単位（以下、バッファブロック１７１）毎で論理的に管理される。また、バッファブロックは、さらに小さいサイズのバッファサブブロック（図示しない）に分割されている。バッファ領域管理情報１７０は、バッファブロック毎のバッファブロック管理情報１７６と、バッファ領域容量使用率１８１を含む。
【００４８】
バッファブロック管理情報１７６は、ステータス情報１７８、エラー情報１８０、リード情報１８２、ライト面の先頭アドレス＃及びブロック＃１８３、リード面の先頭アドレス＃及びブロック＃１８４、データ種別１８６、ＪＯＢ＃１８８、使用可否情報１９０が含まれる。
【００４９】
ステータス情報１７８は、当該バッファブロックにデータが格納されているか、パリティ生成済みか否か、格納されているデータがドライブ２６に格納済みか否か、などを示す。エラー情報１８０は、ストレージシステムのエラーの状態を示す情報であり、エラーが発生した際に設定される。
リード情報１８２は、当該バッファブロックに格納されたデータに、リード要求が来たか否かを示す情報である。通常はＯＦＦであり、リード要求がきた場合にＯＮへ更新される。
【００５０】
ライト面先頭アドレス＃およびブロック＃１８３は、新データと生成する新パリティを格納するために確保したバッファ領域２０内の領域のデータ格納位置を表す物理アドレスの先頭アドレス＃と、論理アドレスであるブロック＃を示す。リード面先頭アドレス＃およびブロック＃１８４は、新パリティ生成のためにドライブ２６から読み出す旧データ、旧パリティを格納するために確保したバッファ領域２０内の領域の先頭アドレス＃およびバッファブロック＃を示す。
データ種別１８６は、当該ブロックに格納されているデータが、ユーザデータかパリティかを示す。
【００５１】
高速ライトＪＯＢ＃１８８は、当該バッファブロックを使用している高速ライト処理の高速ライトＪＯＢ＃を示す。本実施例では、高速ライト処理に使用されるバッファ領域２０内の領域は決まっており、バッファブロック＃と高速ライトＪＯＢ＃は一対一で対応している。ただし、バッファブロック＃と高速ライトＪＯＢ＃は一対一でなくても良く、高速ライト処理する際に使用可能なバッファブロックを使用することにより、バッファ領域２０を有効活用することができる。  使用可否情報１９０は、当該バッファブロックに格納されているデータにアクセス（リードまたはライト）可能か否かを示す。
【００５２】
バッファ容量使用率１８１は、バッファ領域２０に空きがあるかどうかを示す。バッファブロックごとのバッファブロック管理情報１７６とは別に、管理される。バッファ容量使用率１８１は定期的に更新してもよいし、バッファ領域２０を使用したタイミングで更新しても良い。使用率に閾値を設定しておき、閾値を超えた場合は、高速ライト処理での新規処理は実施しないようにすることで、たとえば、高速ライト処理の途中でバッファの容量不足による処理の中断を避けることができる。
【００５３】
なお、詳細は図１４〜１６で後述するが、本実施例における高速ライト処理の途中で、ストレージシステムの一部が故障したり、処理がタイムアウトしたり等、エラーが起きた際、または、リード処理の割り込みが入った場合に、高速ライト処理から、図１２、１３で後述する通常ライト処理に切り替える場合がある。処理の切り替えに伴い、バッファ領域２０に格納していたデータをキャッシュ領域２２に移す処理を行う。そのため、本実施例におけるバッファ領域管理情報１７０は、図８で後述するブロック情報１１６のデータ状態１４０に対応する情報として、ステータス情報１７８を備えている。バッファ領域管理情報１７０においてステータス情報１７８を備えていることで、バッファ領域２０からキャッシュ領域２２にデータの移行を行うことが出来るので、データロストを防ぐことができる。
【００５４】
＜バッファ領域の説明＞
図６は、バッファ領域２０の管理の一例の図である。バッファ領域２０はバッファブロック単位で管理され、それぞれのバッファブロックが、バッファ領域管理テーブル３２により管理される。バッファブロック１７１のデータ種別等はバッファ領域管理情報１７０が保持し、バッファの空きブロック管理は空き領域管理Ｂｉｔ  Ｍａｐ（ＢＭ）１７２が管理する。空きブロック管理はキュー管理でも良い。
【００５５】
図６では、バッファ領域２０のバッファブロック＃２にデータが格納されている状態を示す。バッファ領域管理情報１７０のバッファブロック＃２のバッファブロック情報１７６に情報が保持されており、空き領域管理ＢＭ１７２は、バッファブロック＃２はデータ格納済みであることを示している。
＜キャッシュメモリの説明＞
図７、８で、本実施例にかかるキャッシュ領域２２を管理するためのテーブル群を示す。キャッシュ領域２２はキャッシュブロック単位で管理され、キャッシュ管理テーブル４０で制御されている。テーブル群は、キャッシュブロック管理情報１１８と、キャッシュディレクトリ情報１０４を含む。
【００５６】
図７は、本実施例にかかるキャッシュディレクトリ情報１０４である。キャッシュディレクトリ情報は、プロセッサ１４が、Ｉ／Ｏ先であるＬＤＥＶのサブブロック＃２０４のデータの、キャッシュ領域２２における格納状態を検索するために使用するハッシュテーブルである。つまり、キャッシュディレクトリ情報１０４は、キャッシュブロック管理情報１１８への索引である。
【００５７】
キャッシュディレクトリ情報１０４には、ハッシュ情報１５８、ハッシュヘッダ＃０  先頭ポインタ１６０、ハッシュヘッダ＃０  終端ポインタ１６２が含まれる。
【００５８】
ハッシュ情報１５８は、Ｉ／Ｏ先情報のハッシュ値と、ハッシュヘッダとの対応関係を示す情報であるハッシュヘッダの実体として、ブロック情報１１６のアドレスを示す先頭ポインタ１６０と終端ポインタ１６２がある。キャッシュディレクトリ情報１０４は、ハッシュヘッダごとに先頭ポインタ１６０と終端ポインタ１６２を持つが、後述する図９に示すように、アクセス回数が多いハッシュヘッダのポインタを厳選して別テーブルで持つ構造でもよい。この構造により、ポインタ検索時間を早くでき、データキャッシュング処理負荷を低減するためことができる。
【００５９】
図８は、本実施例にかかるブロック情報１１６およびキャッシュブロック管理情報１１８である。ブロック情報１１６は、キャッシュブロックごとの情報であり、キャッシュブロック管理情報１１８は、全キャッシュブロックのブロック情報１１６を含む。ブロック情報１１６は、データ状態１４０、エラー情報１４２、ディレクトリ前方ポインタ１４４とディレクトリ後方ポインタ１４６、キュー前方ポインタ１４８とキュー後方ポインタ１５０、割り当てブロック＃および先頭アドレス＃１５２、ロック中ビット１５４、リード面フラグ１５６及びライト面フラグ１５７を含む。
【００６０】
データ状態１４０は、クリーン、ダーティ（生成前）、ダーティ（生成後）、およびフリー、がある。当該キャッシュブロックに格納されているデータが、ドライブに格納済みである状態を「クリーン」、データに関連するパリティの生成前である状態を「ダーティ（生成前）」、パリティ生成後である状態を「ダーティ（生成後）」、当該キャッシュブロックにデータが格納されていない状態を「フリー」とする。
【００６１】
エラー情報１４２は、ストレージシステムにエラーが発生した際のエラーの状態を示す情報であり、エラーが発生した際に設定される。
ディレクトリ前方ポインタ１４４およびディレクトリ後方ポインタ１４６は、キャッシュディレクトリ情報１０４に接続するためのポインタである。
キュー前方ポインタ１４８とキュー後方ポインタ１５０は、図９で後述するキャッシュ割り当て管理情報１２０に接続するための情報である。
割り当てブロック＃・先頭アドレス＃１５２は、Ｉ／Ｏ処理に際して、実際にキャッシュ領域２２にデータを格納するために確保したキャッシュブロックのキャッシュブロック＃および先頭アドレス＃である。
【００６２】
ロック中ビット１５４は、Ｉ／Ｏ処理に際して、確保したキャッシュブロックで当該Ｉ／Ｏ処理以外の処理が行われないようにするビットである。処理開始の契機でＯＮにする。
リード面フラグ１５６またはライト面フラグ１５７は、それぞれ、キャッシュブロックがリード面またはライト面のいずれかに該当するかを示す。
【００６３】
図９は、キャッシュ領域２２の管理の一例を示す。キャッシュ領域２２は、キャッシュブロック毎にキャッシュ管理テーブル４０で制御されている。キャッシュ管理テーブル４０は、キャッシュ割り当て管理情報１２０、キャッシュブロック管理情報１１８、アドレス情報を管理するキャッシュディレクトリ情報１０４、使用状況情報３で構成される。
【００６４】
キャッシュ割り当て管理情報１２０は、キャッシュブロックがリード面かライト面かを管理する。キャッシュ割り当て管理情報１２０ではキュー管理され、キューヘッダとして「フリー」があり、リード面にもライト面にも割り当てられていないブロック情報１１６がエンキューされている。リード面またはライト面に割当られたキャッシュブロックはデキューされる。
【００６５】
キャッシュブロック管理情報１１８では、キュー管理され、キューヘッダとしてドライブに書き込み済みである状態の「クリーン」、パリティ生成前である状態の「ダーティ（生成前）」、パリティ生成後である状態の「ダーティ（生成後）」、割り当てられていないブロックである状態の「フリー」がある。各ブロックに対し、現状のキャッシュのデータ状態１４０に合致したキューヘッダのキューに、ブロック情報１１６のキュー前方ポインタ１４８をエンキューする。
【００６６】
キャッシュディレクトリ情報１０４では、ブロック情報１１６のアドレスを示すポインタ情報１６０、１６２が管理されている。キャッシュディレクトリ情報１０４は、図９に示すように、アドレス検索速度を速くするため、当該データのアドレス情報１１４にリンクするポインタ情報１１３を用いて当該データのアドレス情報１１４が管理されている。アドレス情報１１４は、ブロック情報１１６と１対１で対応付けられている。ハッシュテーブルであるキャッシュディレクトリ情報１０４のポインタ情報１１３を辿ることで、全てのアドレス情報１１４を検索することなく必要なアドレス情報１１４のみ素早く求められるようになっている。
【００６７】
使用状況情報３では、予めキャッシュ領域の容量使用率の閾値を設定しておき、使用率が閾値に達してしまい容量枯渇していないかを確認する。使用率の更新は、キャッシュ領域を確保解放したタイミングで更新しても良いし、一定時間で定期的に更新しても良い。
【００６８】
本実施例の高速ライト処理は、キャッシュ領域２２より管理情報と制御が容易なバッファ領域２０に、新データ、旧データ、旧パリティ、新パリティを格納することで、多くの管理情報の作成または更新によるオーバーヘッドを削減し、プロセッサの負荷を抑制する。
【００６９】
＜ライト処理の説明＞
図１０〜１３を用いて、本実施例のストレージシステム４２のライト処理について説明する。
【００７０】
図１０は、本実施例のライト処理のフローである。ライト処理は、ストレージシステム４２がホスト１０からライト要求を受信した場合に開始される。
【００７１】
ステップ２４１：プロセッサ１４はホスト１０からライトコマンドを受け取ると、ＪＯＢ＃管理テーブル３８にアクセスしＪＯＢ＃を新規取得する。
【００７２】
ステップ２４２：そして、ＬＤＥＶページ管理情報３６にアクセスし、当該ライト要求があった新データの格納先を示すＬＤＥＶのサブブロック＃２０４のライト処理中フラグをＯＮする。
【００７３】
ステップ２４４：ライト処理を、高速ライト処理で実施するか、または、通常ライト処理で実施するか、を判定する。高速ライト処理に進む条件は、例えば、新データのサイズがサブブロックサイズ以下であること、複数のサブブロックに跨ったライトではないこと、バッファ領域容量使用率１８１が閾値を超えていないこと、高速ライトＪＯＢ＃が枯渇していないこと等がある。これらの条件は、ストレージシステム４２のポリシーによって変更しても良い。高速ライト処理での処理「可」となった場合は、ステップ２５５へ、高速ライト処理での処理「否」となった場合は、通常ライト処理Frontend処理ステップ２４６へ進む。
【００７４】
ステップ２５５：高速ライト処理での処理「可」となった場合は、高速ライト処理用の高速ライトＪＯＢ＃を付与する。ＪＯＢ＃管理情報３８にアクセスして高速ライトＪＯＢ＃を新規取得する。ＪＯＢアクセス先情報２２８の、ステップ２４１で取得したＪＯＢ＃の、高速ライトＪＯＢ＃２３１に情報に追記する。その後、高速ライト処理ステップ２５６に進む。高速ライト処理ステップ２５６は図１１で説明する。
【００７５】
ステップ２４６：高速ライト処理での処理「否」となった場合は、キャッシュ領域２２を使用した通常ライト処理のFrontend処理を実施する。Frontend処理とは、ホスト１０からの新データをキャッシュ領域２２に書き込み、ホスト１０へライト要求に対して応答するまでの処理である。詳細は、図１２で説明する。
【００７６】
ステップ２６０：ステップ２４６でホスト１０に応答をすると、ＬＤＥＶページ管理テーブル３６にアクセスし、ステップ２４２でＯＮにした当該サブブロック＃２０４のライト処理フラグ２１０をＯＦＦする。
【００７７】
ステップ２５０：その後、キャッシュ領域２２を使用した通常ライト処理のBackend処理の実施可否を判定する。通常ライト処理のBackend処理とは、キャッシュ領域２２に格納した新データに関する新パリティを生成し、新データと新パリティをドライブ２６へ書き込む処理である。ステップ２５０の判定は周期的に行う。Backend処理が「可」となるのは、例えば、キャッシュ領域２２の容量使用率が閾値を超えた場合や、プロセッサ１４のアイドルタイムである。また、前回のBackend処理の実施から所定の時間が経過したら、次のBackend処理を実施するなどでもよい。「可」の場合はステップ２５２へ、「不可」の場合は、再度ステップ２５０の判定に戻る。
【００７８】
ステップ２５２：ステップ２５０でBackend処理が実施「可」の場合は、ＬＤＥＶページ管理テーブル３６にアクセスし、ステップ２６０でＯＦＦにした当該サブブロック＃２０４のライト処理フラグ２１０をＯＮする。
【００７９】
ステップ２５４：そして、キャッシュ領域２２を使用した通常ライト処理のBackend処理を実施する。詳細は図１３で説明する。
【００８０】
ステップ２６０：高速ライト処理（ステップ２５６）または通常ライト処理のBackend処理（ステップ２５４）が終わると、ＬＤＥＶページ管理テーブル３６にアクセスし、当該サブブロック＃２０４のライト処理フラグ２１０をＯＦＦする。
【００８１】
ステップ２４８：そして、ステップ２４１で取得したＪＯＢ＃を解放する。具体的には、ＪＯＢ＃管理テーブル３８にアクセスし、ＪＯＢアクセス先情報２２８の、ステップ２４１で取得した当該ＪＯＢ＃２３０の情報を削除する。
以上で、本実施例のライト処理が完了となる。
【００８２】
＜高速ライト処理＞
図１１は、本実施例における高速ライト処理のフローを示す。
【００８３】
図１で説明したように、本実施例の高速ライト処理は、プロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて、新パリティを生成し、新データと新パリティをドライブ２６に格納する。
また、ホスト１０からの新データ１００と、新パリティ１０６を生成するためにドライブ２６から読み出す旧データ１０２、旧パリティ１０４を、従来のキャッシングのようにキャッシュ領域２２に格納するのではなく、本実施例では、バッファ領域２０に格納する。
【００８４】
上述の本実施例の処理により、ホストからのライト要求に対する応答と、パリティ生成処理を非同期で行うと、ＦＥ処理とＢＥ処理のそれぞれの開始、終了の際に、それぞれの処理に必要なキャッシュメモリの領域を確保したり、解放したりする処理を重複して行わなければならなかったり、ＢＥ処理の際に、ＨＤＤに格納未済みのデータをキャッシュメモリ探し出す、というキャッシュ制御のオーバーヘッドを削減することができる。また、新データ１００、旧データ１０２、旧パリティ１０４、新パリティ１０６をバッファ領域２０に格納するため、キャッシュ領域２２の管理情報の作成および更新が不要となる点でも、キャッシュ制御のオーバーヘッドを削減することができる。
【００８５】
高速ライト処理（ステップ２５６）は、ホスト１０からライト要求を受け、図１０のステップ２４４でライト高速処理での処理「可」と判断された場合に開始される。
【００８６】
ステップ３６０：バッファ領域２０に、新データ、新パリティを格納するための領域であるライト面、旧データ、旧パリティを格納するための領域であるリード面を確保する。具体的には、ステップ２５５で取得した高速ライト処理ＪＯＢ＃に対応するバッファブロックのバッファブロック管理情報１７６にアクセスし、初期値を設定し、当該バッファブロックの空き領域管理ＢＭ１７２をＯＮにする。
【００８７】
従来は、ライト要求とは非同期で新パリティの生成と新データおよび新パリティのドライブへの格納を行うため、ホスト１０からデータが転送される前は、新データを格納する領域のみを確保していた。従来のように新データを格納する領域のみ確保して本実施例の高速ライト処理を行うと、たとえば新パリティ１０６を生成する処理の前にバッファ領域２０の容量が枯渇した場合、旧データ１０２と、旧パリティ１０４を格納する領域を確保できずに新パリティ１０６を生成する処理に移れず、高速ライト処理を完了することができない。そのため、本実施例では、ホスト１０からデータが転送される前に、新データ１００、新パリティ１０６、旧データ１０２と、旧パリティ１０４とを格納する領域を確保することで、バッファ領域２０の容量枯渇により処理が未完になることを防ぐ。
【００８８】
また、新データ１００、新パリティ１０６を格納するためのライト面と、旧データ１０２、旧パリティ１０４を格納するためのリード面の計４サブバッファブロック分を、連続領域で確保すると、先頭アドレスと確保した領域数だけ管理しても良いため、バッファブロック管理情報１７６の情報の保持を簡素化できる。４サブバッファブロック連続でなくても、ライト面を計２サブバッファブロック連続、と、リード面を計２サブバッファブロック連続で確保することでも、離れた１サブバッファブロックずつそれぞれ確保するよりも管理情報の簡素化の効果がある。なお、サブバッファブロックとは、バッファブロックを、より小さい単位で管理するための単位を示す。
【００８９】
本実施例では、ストレージコントローラ１２が故障した際のデータロストを防ぐため、ストレージコントローラ１２が二重化されている。そのため、現在処理するプロセッサ１４を有する（以下、自系）ストレージコントローラ１２と、二重化先（以下、他系）ストレージコントローラ１２それぞれで領域を確保するが、他系ストレージコントローラ１２ではリード面の確保は不要である。
【００９０】
ステップ３６２：ステップ３６０で確保したバッファ領域２０のライト面にホスト１０から新データ１００を転送する。具体的には、プロセッサ１４は、バッファ領域２０にライト面、リード面を確保すると、ホスト１０に、バッファ２０にデータ転送してよい旨の信号を送信し、ホスト１０は当該信号を受信すると、新データ１００を転送し、新データ１００がバッファ領域２０のライト面に格納される。
【００９１】
ステップ３６４：ステップ３６０で確保した他系ストレージコントローラ１２のバッファ領域に、二重書きのために新データ１００を転送する。データの二重書は、冗長性を確保し、ストレージシステムとしての信頼性を向上させるためである。
【００９２】
ステップ３６６：ステップ３６０で確保したライト面が存在するバッファブロックの、バッファブロック管理情報１７６のステータス情報１７８を更新する。具体的には、新データが書き込まれたことを示すフラグを立てても良いし、ブロックの中でどのバッファサブブロックに新データが書き込まれたかをビットマップで管理しても良い。バッファブロック管理情報の更新は、自他両方のストレージパッケージ１２で実施する。
【００９３】
ステップ３６８：ホスト１０に、ライト要求処理が完了したと応答をする。本実施例では、このホストへの完了応答に応じて、新パリティ生成のためのステップに進む。具体的には、以下のステップ３７０、ステップ３７２のとおりである。
【００９４】
ステップ３７０：ステップ３６０で確保したリード面に、ドライブ２６から旧データおよび旧パリティを転送する。
ステップ３７２：新データ、旧データ、旧パリティをＸＯＲ演算して新パリティを作成する。新パリティは、ステップ３６０で確保したライト面に格納する。
ステップ３７４：ステップ３６０で確保した他系ストレージコントローラのライト面へ新パリティを転送する。
【００９５】
ステップ３７６：パリティ及びデータを格納するバッファブロックのバッファ領域管理情報１７０を自他両方のストレージコントローラ１２で更新する。ライト面のバッファブロック管理情報１７６の更新内容はステップ３６６と同等で良い。リード面のバッファブロック管理情報１７６の更新内容は、ステップ３６６の内容に加えて、使用可否情報１９０を可から不可に更新する。また、新データと新パリティが記録されているサブバッファブロックのライト面フラグを、リード面フラグに切り替える。リード面に記録されている新データと新パリティを、これからドライブ２６に転送するためである。
【００９６】
ステップ３７８：ドライブ２６に、新データ１００と新パリティ１０６をバッファ領域２０から転送して格納する。
【００９７】
ステップ３８０：ステップ３６０で確保した領域を解放する。解放とは具体的には、データを０書きする。または、当該確保した領域を含むバッファブロックの空き領域管理ＢＭ１７２をＯＦＦすれば良い。バッファを解放すると、当該ライト処理に関してキャッシュ領域２２に格納されたデータが、バッファ領域２０から消去可能な状態、または消去される。なお、バッファブロックが解放されると、当該バッファブロックに対応していたＪＯＢ＃も解放される。
以上で、高速ライト処理が完了する。
【００９８】
＜通常ライト処理  Frontend処理＞
図１２は、本実施例にかかるキャッシュ領域２２を使用する通常ライト処理Frontend処理２４６フローである。
【００９９】
ステップ２７０：ホスト１０からの新データを格納するキャッシュ領域を、新規で確保する必要があるか判定する。例えば、ライト要求が既にドライブ２６に格納されたデータを更新するための要求であり、キャッシュ領域２２に当該データが格納されている場合は、新規でキャッシュ領域２２に当該データを格納する領域を確保する必要はない。判定の結果、確保要（Ｙｅｓ）ならばステップ２７２へ、確保不要（Ｎｏ）ならばステップ２７４へ進む。
【０１００】
ステップ２７２：データを格納するためのキャッシュ領域を新規に確保する。ホスト１０からのデータを格納するための領域であるライト面のみを確保する。キャッシュディレクトリ情報１０４において、ハッシュ情報等１１４を確保し、ブロック情報１１６でダーティ（生成前）１１０、キャッシュ割り当て管理情報１２０でライト面をキューで繋ぐ。
【０１０１】
ステップ２７４：ステップ２７２で確保した領域が存在するキャッシュブロックのロックを取得する。具体的には、ブロック情報１１６のロック中ビット１５４をＯＮにする。ＯＮにすることで、当該キャッシュブロックに対し、例えばリード処理などの他処理が実施されない様にする。
【０１０２】
ステップ２７６：ホスト１０から書き込み対象のデータである新データを当該キャッシュ領域２２に格納する。その後、ステップ２７８へ進む。
【０１０３】
ステップ２７８：ストレージコントローラ１２が故障した際のデータロストを防ぐため、他系ストレージコントローラ１２のキャッシュ領域に新データを転送する。他系ストレージコントローラ１２におけるキャッシュブロックの確保およびロック取得は、それぞれステップ２７２および２７４で実施する。
【０１０４】
ステップ２８０：ブロック情報１１６のデータ情報１４０に、新データがキャッシュ領域２２に書き込みが完了したことを示す情報を格納する。新データの書き込みが完了したことを示す情報は、新データが書き込まれたことが分かるフラグでも良いし、ブロックの中でどのサブブロックに新データが書き込まれたか管理するビットマップでも良い。ブロック情報１１６の更新は、自系他系両方のストレージコントローラ１２で実施する。
【０１０５】
ステップ２８２：ホスト１０に、ライト処理が完了したことを応答する。
【０１０６】
ステップ２８４：ステップ２７４でＯＮにしたブロック情報１１６のキャッシュ領域ロック中ビット１５４をＯＦＦにする。
以上で、通常ライト処理のFrontend処理が完了する。通常ライト処理では、ライト要求とは非同期でパリティ生成を行うため、Frontend処理が完了しても新データ１００はキャッシュ領域２２に格納されたままであるため、確保したキャッシュ領域は解放しない。
【０１０７】
＜通常ライト処理  Backend処理＞
図１３は、本実施例にかかるキャッシュ領域２２を使用する通常ライト処理Backend処理２５８のフローである。本実施例では、一例としてＲＡＩＤ５構成のケースを想定しているが、ＲＡＩＤ６等の他のＲＡＩＤ構成であっても構わない。
【０１０８】
ステップ２９０：新パリティを生成するためにドライブ２６から読み出す旧データと旧パリティを格納するキャッシュ領域と、生成した新パリティを格納するキャッシュ領域を確保し、ロックを取得する。自系と他系のストレージコントローラ１２のそれぞれで、キャッシュ領域２２の確保およびロック取得を実施する。
ステップ２９１：ステップ２８４で解放した新データ用キャッシュ領域のロックを取得する。当該Backend処理中に、新データ用キャッシュ領域に他の処理が実施されないようにするためである。
【０１０９】
ステップ２９２：ステップ２９０で確保した旧パリティ用、旧データ用キャッシュ領域にそれぞれ旧パリティと旧データを格納する。旧パリティおよび旧データの転送は自系のストレージコントローラ１２のみでよい。
【０１１０】
ステップ２９４：新データと旧データと旧パリティをＸＯＲ演算し、新パリティを作成し、ステップ２９０で確保した新パリティ用キャッシュ領域に格納する。
【０１１１】
ステップ２９６：作成した新パリティを他系ストレージコントローラ１２の新パリティ用キャッシュ領域へ転送する。
【０１１２】
ステップ２９８：パリティ及びデータを格納するブロックのブロック情報１１６を自系他系両方のストレージコントローラ１２で更新する。パリティ用キャッシュブロックのリード面に関しては、ブロック情報１１６の更新内容は、ステップ２８０と同等で良い。ライト面に関しては、ステップ２８０の内容に加えて、リード面破棄処理を実施する。データ用、パリティ用それぞれのライト面に最新データが格納されているため、今後ホストから送信されるデータを格納できるようにするため、現状の旧データ・パリティが格納されているリード面は破棄し、ライト面をリード面に切り替える処理を実施する。切り替える処理とは具体的に、現状ライト面として確保された領域に対し、ライト面フラグ１５７をＯＦＦ、リード面フラグ１５６をＯＮにして、リード面として扱えるようにする。
【０１１３】
ステップ３００：新データおよび新パリティをドライブ２６へ転送する。
ステップ３０２：ステップ２９０で取得したパリティ用キャッシュブロックと、データ用キャッシュブロックのロックを解放する。ブロック情報１１６のロック中ビット１５４をＯＦＦにすればよい。ロックの解放は自系他系ストレージコントローラで実施する。
【０１１４】
ステップ３０４：ステップ２９０で確保した領域を含むキャッシュブロックを解放する必要があるか判定する。ステップ３０２でロックを解放しているので、ホスト１０からのライト要求を受領することが出来る。また、ホスト１０からＩ／Ｏ要求があった場合に、当該要求に関するデータがキャッシュメモリに格納されていれば、ＨＤＤに直接アクセスするよりも処理を高速化することができるため、ステップ３０２終了後すぐにキャッシュ領域を解放しなくても良く、定期的にキャッシュ領域解放処理を実施しても良いし、キャッシュ領域容量使用率が閾値に達してからでも良い。
解放要の場合はステップ３０６へ、解放不要の場合はステップ３０４の判定を繰り返す。
【０１１５】
ステップ３０６：新データ用、旧データ用、旧パリティ用、新パリティ用キャッシュ領域を解放する。具体的には、キャッシュ管理テーブル３４から、当該領域を含むブロック情報１１６、キャッシュ割り当て管理情報１２０、キャッシュディレクトリ情報１０４を削除する。
以上で、通常ライト処理Backend処理が完了する。
【０１１６】
本実施例の高速ライト処理では、処理中にストレージシステムでエラーが発生した場合、または、新データに対してリード要求が来た場合に、高速ライト処理から通常ライト処理に切り替えて、エラー処理やリード処理を行う場合がある。そのため、図１４〜１６を用いて、エラーを検出した時の処理、リード要求を受けた時の処理、通常ライト処理へ切り替える処理、についてそれぞれ説明する。
【０１１７】
＜エラー検出処理＞
ライト要求処理中に、ストレージシステムの一部が故障する、または、処理がタイムアウトする等のエラーが発生することがある。図１４は、これらのエラーを検出した時の処理フローである。
【０１１８】
ステップ３８６：エラーを検出すると、処理が中断した時に確保していたブロック情報１１６のエラー情報１４２、または、バッファブロック管理情報１７６のエラー情報１８０に、エラー状態を示す情報を格納する。エラー状態を示す情報は、例えばビットを用いる。
【０１１９】
ステップ３８８：現在実施中のライト処理が高速ライト処理で処理中か否かを確認する。例えば、ＪＯＢアクセス先情報２２８を確認すれば、エラーが起こった時点で高速ライトＪＯＢ＃が付与されていたか否かが分かるので、判断できる。Ｙｅｓの場合はステップ３９０へ、Ｎｏの場合はステップ３９２へ進む。
【０１２０】
ステップ３９０：現在実施中のライト処理について、高速ライト処理２２で処理中の場合は、通常ライト処理に切り替え処理にすすむ。通常ライト処理に切り替えるのは、エラー処理の対応は、通常ライト処理のエラー処理対応を使用するためである。切り替え処理の詳細は、図１６で説明する。
【０１２１】
ステップ３９２：ステップ３８８で設定したエラー状態に基づいて、エラー処理を実施する。エラー処理とは例えば、プロセッサ１４やメモリが故障した場合は、アラートを出したり、ドライブ２６が故障した場合は、データを回復したり、または、他のドライブ２６にデータを移動させたりする処理である。
＜リード処理＞
図１５は、本実施例におけるリード処理のフローである。本実施例では、リード処理は通常ライト処理と同様にキャッシュ領域２２を使用する。
【０１２２】
リード処理は、ストレージシステム４２がホスト１０からリード要求を受けた場合に開始される。
【０１２３】
ステップ４２０：リード要求を受けたデータがライト処理中か否かを判定する。具体的には、ＬＤＥＶページ管理情報３６にアクセスし、リード要求に含まれるＩ／Ｏ先情報に基づいて、リード対象のアドレスに該当するサブブロック＃２０４のライト処理中フラグ２１０がＯＮになっているかどうか判定する。ライト処理中フラグがＯＮ、つまりＹｅｓの場合はステップ４２２へ、ＯＦＦ、つまりＮｏの場合はステップ４３０へ進む。
【０１２４】
ステップ４２２：さらに、リード要求を受けたデータが高速ライト処理中か否かを判定する。具体的には、ＪＯＢアクセス先情報２２８にアクセスし、リード対象のアドレスに該当するサブブロック＃２０４に高速ライトＪＯＢ＃２３１が付与されているか確認する。高速ライトＪＯＢ＃２３１が付与されている場合は、当該リード要求を受けたデータは高速ライト処理中となる。高速ライト処理中（Ｙｅｓ）の場合はステップ４２４へ、高速ライト処理中ではなく通常ライト処理中（Ｎｏ）の場合は再度ステップ４２０の判定を実施する。
【０１２５】
ステップ４２４：リード対象であるデータが格納されているバッファブロックのバッファブロック管理情報１７６のリード情報１８２をＯＮにする。
ステップ３９０：通常ライトへの切り替え処理３９０を行う。ステップ３９０については、図１６で説明する。ステップ３９０終了後、再度ステップ４２０の判定を実施する。
【０１２６】
ステップ４３０：リード対象データがライト処理中ではないので、リード処理を実施する。当該アドレスを含むブロックに既にキャッシュ領域２２が割り当たっているかキャッシュ管理テーブル４０にアクセスして確認する。割り当てあり（Ｙｅｓ）の場合はステップ４３４へ、割り当てなし（Ｎｏ）の場合はステップ４３２へ進む。
【０１２７】
ステップ４３２：キャッシュ領域２２において、リード対象データを格納するためのキャッシュ領域を確保する。
ステップ４３４：ステップ４３２で確保した領域をロックする。ブロック情報１１６のロック中ビット＃１５４をＯＮにする。
【０１２８】
ステップ４３６：ドライブ２６から、リード対象データをステップ４３４でロック取得したキャッシュ領域へ転送する。
ステップ４３８：ステップ４３６キャッシュ領域に格納したデータを、ホスト１０へ転送する。  ステップ４４０：ホストへリード処理完了を応答する。
ステップ４４２：ステップ４３４で確保したロックを解放する。
以上で、リード処理を完了する。
【０１２９】
＜切り替え処理＞
図１６は、本実施例にかかる、通常ライト処理切り替え処理３９０の処理フローである。上述のとおり、エラーを検出した場合、リード要求を受けた場合に、通常ライト処理に切り替える際に実施する処理について説明する。
【０１３０】
ステップ４００：高速ライト処理で新データと新パリティの、ドライブ２６への書き込みが完了済みか判定する。具体的には、図１１ステップ３８０でバッファを解放処理中であれば、書き込み完了と判断する。データ書き込み完了（Ｙｅｓ）の場合は切り替え処理完了、データ書き込みが完了していない場合（Ｎｏ）は、ステップ４０２へ進む。
【０１３１】
ステップ４０２：高速ライト処理で、新パリティ生成済みか否かを判定する。具体的には、バッファブロック管理情報１７６のステータス情報１７８を確認し判定する。新パリティ生成済みであれば、図１１ステップ３７６のバッファ管理情報更新において、当該ステータス情報１７８が更新されているためである。作成済み（Ｙｅｓ）ならばステップ４０４へ、作成されていない（Ｎｏ）ならばステップ４１２へ進む。
【０１３２】
ステップ４０４：バッファ領域２０から新データを転送するための新データ用キャッシュ領域確保し、ロックを取得する。
ステップ４０６：バッファ領域２０から新パリティを転送するための新パリティ用キャッシュ領域確保し、ロック取得を取得する。
【０１３３】
ステップ４０８：バッファ領域２０から、ステップ４０４、４０６で確保したキャッシュ領域へ、新データ及び新パリティをそれぞれコピーする。さらに、バッファ領域管理情報１７０から、ステップ４０４、４０６でそれぞれ確保したキャッシュ領域に対応するキャッシュ管理情報４０へ、データ用及びパリティ用の管理情報１７６のエラー情報をコピーし、バッファ領域管理情報１７０のステータス情報からブロック情報１１６に対し適切なキューヘッダ１００にキューイングし、キャッシュ割り当て管理情報１２０のリード面、ライト面両方にキューイングする。コピー先は自系および他系ストレージコントローラ１２のそれぞれである。
【０１３４】
ステップ４１０：領域確保、データおよび管理情報のコピー等の処理が完了したので、高速ライト処理から通常ライト処理へ処理を切り替える。新パリティを生成済みであるため、通常ライト処理は図１３のステップ２９６から実施すれば良い。
【０１３５】
ステップ４１２：：バッファ領域２０から新データを転送するための新データ用キャッシュ領域確保し、ロックを取得する。
ステップ４１４：ステップ４０８と同等の処理をおこなう。具体的には、バッファ領域２０から、ステップ４１２で確保したキャッシュ領域へ、新データをコピーする。バッファブロック管理情報１７６も、キャッシュ管理テーブル４０にコピーする。
【０１３６】
ステップ４１６：新パリティは生成していないため、通常ライト処理は図１３のステップ２９０から実施すれば良い。
ステップ４１８：バッファを解放する。図１１のステップ３８０と同等の処理である。
以上で、処理完了である。
【０１３７】
本実施例におけるリード処理、通常処理への切り替え処理は、以降の実施例でも同様である。
【０１３８】
図２４は、本実施例におけるメニュー画面２０００、管理画面２１００の一例である。メニュー画面２０００は、Ｆｌａｓｈ高性能モード設定エリア２００１を有する。管理者は、Ｆｌａｓｈ高性能モード設定エリア２００１の“ＥＮＡＢＬＥ”または“ＤＩＳＡＢＬＥ”を選択することで、本実施例の高速ライト処理をイネーブル又はディセーブルすることができる。管理画面２１００は、バッファ領域エリア２１０１を有する。バッファ領域エリア２１０１の「ＥＮＡＢＬＥ」とは、例えば、バッファ領域２０の使用率が閾値以下であり高速ライト処理が可能なことを示す。
以上が、本実施例についての説明である。
【０１３９】
本実施例の高速ライト処理は、プロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて、新パリティを生成し、新データと新パリティをドライブ２６に格納することが特徴である。この特徴により、ホストからのライト要求に対する応答と、パリティ生成処理を非同期で行うと、ＦＥ処理とＢＥ処理のそれぞれの開始、終了の際に、それぞれの処理に必要なキャッシュメモリの領域を確保したり、解放したりする処理を重複して行わなければならなかったり、ＢＥ処理の際に、ＨＤＤに格納未済みのデータをキャッシュメモリ探し出す、というキャッシュ制御のオーバーヘッドを削減することができる。
【０１４０】
また、新データ１００、旧データ１０２、旧パリティ１０４、新パリティ１０６をバッファ領域２０に格納するため、キャッシュ領域２２の管理情報の作成および更新が不要となる点でも、キャッシュ制御のオーバーヘッドを削減することができる。
よって、プロセッサの負荷を抑制することで、単位時間当たりに処理可能なホストからの要求数が増加し、ストレージシステムの高速化が実現できる。
【０１４１】
また、先にホスト１０からのライト要求に対して応答してから、新パリティを生成するため、本実施例の高速ライト処理は、速いレスポンスが求められるシステムに適している。
【０１４２】
また、本実施例における高速ライト処理から、通常ライト処理に切り替える場合があるが、本実施例におけるバッファ領域管理情報１７０では、ブロック情報１１６のデータ状態１４０に対応する情報として、ステータス情報１７８を備えていることで、バッファ領域２０からキャッシュ領域２２にデータの移行を行うことが出来るので、データロストを防ぐことができる。
【実施例２】
【０１４３】
本実施では、高速ライト処理において、旧データ１０２と旧パリティ１０４のみをバッファ領域２０に格納し、新データ１００と新パリティ１０６はキャッシュ領域２２に格納する場合について説明する。以降、実施例１と重複する説明は省略する。
【０１４４】
旧データ１０２と旧パリティ１０４は、バッファ領域２０に格納するため、従来技術と比較すると、キャッシュ領域の管理情報の作成および更新によるキャッシュ制御のオーバーヘッドを低減することができる。
【０１４５】
また、実施例１では、高速ライト処理から通常ライト処理への切り替え時には、ライト処理の進捗にも依るが、新データ、旧データ、旧パリティ、新パリティをバッファ領域２０からキャッシュ領域２２にコピーし、バッファ管理情報もキャッシュ管理情報に引き継ぐ必要があった。しかし、実施例２の構成では、新データと新パリティはキャッシュ領域２２に格納されるため、旧データと旧パリティのみのコピーと、管理情報のコピーを行えばよく、高速ライト処理から通常ライト処理への切り替えの負荷を低減することが出来る。または、管理情報のコピーのみ行い、旧データと旧パリティは再度ドライブからキャッシュ領域２２へリードしても良い。
【０１４６】
図１７は、本実施例における高速ライト処理のフローである。実施例１の図１１高速ライト処理２５６のフローとの差分は、ライト面をキャッシュ領域２２に確保している点である。各処理について、実施例１の図１１〜１３で説明した内容との図１１との差分を説明する。
【０１４７】
ステップ４５０：高速ライト処理「可」となった場合、まず、新データおよび新パリティ用のキャッシュ領域を確保し、ロック処理を行う。実際の動作としては、通常ライト処理の図１２のステップ２７０、２７２、２７４と同等である。
【０１４８】
ステップ４５２：旧データおよび旧パリティ用バッファ領域を確保し、バッファ領域管理情報１７０の初期設定を実施する。詳細は、図１１のステップ３６０と同等である。
本実施例では、リード面のみをバッファ領域２０に確保するため、図５のバッファブロック管理情報１７６のライト面先頭アドレス＃・ブロック＃１８３、リード面先頭アドレス＃・ブロック＃１８４を、本実施例では旧データ用先頭アドレス＃・ブロック＃、旧パリティ用先頭アドレス＃・ブロック＃１８４とすれば良い。また、旧パリティ用と旧データ用の２領域を連続領域で確保し、先頭アドレスと確保したサブブロックの数だけ管理することで、バッファ領域管理情報１７０の保持が簡素化できる。
【０１４９】
なお、本ステップのバッファ領域確保処理に時間がかかるため、ステップ３６８でホスト１０にライト処理完了の応答をしてから、本ステップを実施する方が、ホスト１０への応答時間を短くすることができる。高速ライトＪＯＢ＃を設定したタイミングで、当該高速ライトＪＯＢ＃に対応するバッファ領域はリザーブ済みなので、ステップ３６８より後でバッファ領域を確保しても、バッファ領域の枯渇により領域を確保できない、という問題は生じない。
【０１５０】
その後、二重書きのため他系ストレージコントローラへ新データを転送し（ステップ２７８）、キャッシュ管理情報を更新し（ステップ２８０）、ホスト１０へライト処理完了を応答し（ステップ３６８）する。
【０１５１】
そして、ホスト１０への応答に応じて、旧データおよび旧パリティを、ステップ４５２で確保したバッファ領域に転送して格納し（ステップ３７０）、新パリティを生成する（３７２）し、新パリティを二重書きのために他系ストレージコントローラへ転送（ステップ３７４）する。
【０１５２】
ステップ４５４：そして、ブロック情報１１６のデータ情報１４０に、新データに関する新パリティが生成された旨、新パリティがキャッシュ領域２２に格納された旨を示す情報を格納する。詳細は、図１２のステップ２８０、図１３のステップ２９８と同等である。
【０１５３】
ステップ４５８：ステップ３００で新パリティ、新データをドライブに格納した後、ステップ４５２で確保した旧データ用および旧パリティ用に確保したバッファ領域を解放する。詳細は、図１１の３８０と同等である。
【０１５４】
ステップ４６０：ステップ４５０で確保した新データ用および新パリティ用のキャッシュ領域を解放する。詳細は、図１３のステップ３０６と同等である。
【０１５５】
図１７に示した本実施例の高速ライト処理の構成により、実施例２において上述した効果に加え、プロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて新パリティを生成の処理に進むため、ホストからのライト要求に対する応答とパリティ生成処理を非同期で行うことによるＦＥ処理とＢＥ処理のそれぞれの開始、終了の際に、それぞれの処理に必要なキャッシュメモリの領域を確保したり、解放したりする処理を重複して行ったり、ＢＥ処理の際に、ＨＤＤに格納未済みのデータをキャッシュメモリ探し出す、というキャッシュ制御のオーバーヘッドを削減することができる。
【０１５６】
＜変形例について＞
本実施例の、高速ライト処理において、旧データ１０２と旧パリティ１０４のみをバッファ領域２０に格納し、新データ１００と新パリティ１０６はキャッシュ領域２２に格納する場合の変形例について説明する。
【０１５７】
変形例では、ホスト１０へのライト処理完了の応答と非同期で、新パリティ生成のための処理を行う。すなわち、高速ライト処理もFrontend処理とBackend処理を分ける。これにより、例えばリード処理が割り込まれたタイミングで高速ライト処理を通常ライト処理に切り替える回数が減り、実施例２で上述した処理切り替えの負荷低減をより効果的にすることが出来る。
【０１５８】
本変形例のFrontend処理は、図１２の通常ライト処理Frontend処理と同じであり、新データと新パリティはキャッシュメモリ２２に格納される。そして、Backend処理から高速ライト処理と通常ライト処理に分岐する。
【０１５９】
図１８は本変形例のBackend処理をしめす。以下、Backend処理について、図１１との差分を説明する。
【０１６０】
Backend処理起動可と判定（ステップ２５０）されると、ライト要求があった新データの格納先を示すＬＤＥＶのサブブロック＃２０４のライト処理中フラグをＯＮする（ステップ２４２）。
【０１６１】
ステップ４７０：高速ライト処理の可否を判定する。詳細の条件は、図９のステップ２４４と同じである。ステップ４７０で高速ライト処理が「可」となった場合はステップ２５５で高速ライトＪＯＢ＃を取得する。「否」となった場合はステップ２５８で通常ライト処理Backend処理を行う。
【０１６２】
ステップ４７２：ステップ４７０で高速ライト処理「可」となり、ステップ２５５で高速ライトＪＯＢ＃を取得すると、高速ライト処理のBackend処理を実施する。処理の詳細は、図１９で説明する。
【０１６３】
通常ライト処理Backend処理２５８または、高速ライト処理Backend処理４７２が終了すると、ステップ２４２でＯＮにしたＬＤＥＶのサブブロック＃２０４のライト処理中フラグをＯＦＦにし（ステップ２６０）、ＪＯＢ＃を解放する（ステップ２４８）。
以上で、本変形例のBackend処理が完了する。
【０１６４】
図１９は、本変形例における、高速ライト処理Backend処理のフローである。これは、実施例１の図１１から、ステップ３６８のホスト１０への完了応答以前のステップを分離したものである。以下、図１１との差分を説明する。
【０１６５】
ステップ４８０：新パリティ用のキャッシュ領域の確保とロック処理を行う。Frontend処理で新データ用のキャッシュ領域がすでに確保されているため、新パリティ用のみ確保する。
【０１６６】
ステップ４８２：新データ用キャッシュ領域のロックを取得する。通常ライト処理Frontend処理２４のステップ２８４で新データ用キャッシュ領域のロックを解放したためである。詳細は、図１３のステップ２９１と同様である。
【０１６７】
そして、旧データおよび旧パリティ用のバッファ領域を確保し（ステップ４５２）、旧データと旧パリティを確保したバッファ領域に格納し（ステップ３７０）、新パリティを生成する（３７２）し、新パリティを二重書きのために他系ストレージコントローラへ転送（ステップ３７４）する。
【０１６８】
キャッシュ管理情報を更新し（４５４）、新データと新パリティをドライブに格納し（ステップ３００）、ステップ４５２で確保した旧データおよび旧パリティ用のバッファ領域を解放し（ステップ３５０）、新データ用および新パリティ用のキャッシュ領域のロック解放と、領域解放を実施する（３０６）。
【０１６９】
以上が、本実施例と変形例についての説明である。
本実施例では、新データと新パリティはキャッシュ領域２２に格納されるため、旧データと旧パリティのみのコピーと、管理情報の引き継ぎを行えばよく、高速ライト処理から通常ライト処理への切り替えの負荷を低減することが出来る。
【０１７０】
加えて、プロセッサ１４が、ホスト１０からのライト要求に対して応答したことに応じて新パリティを生成の処理に進むため、ホストからのライト要求に対する応答とパリティ生成処理を非同期で行うことによるキャッシュ制御のオーバーヘッドを削減することができる。
また、変形例では高速ライト処理もFrontend処理とBackend処理を分ける。これにより、実施例２の処理切り替えの負荷低減を、より効果的にすることができる。
【実施例３】
【０１７１】
実施例３では、高速ライト処理におけるパリティ演算処理を、演算処理機構を持ったフラッシュドライブ内で実施する。
【０１７２】
図２０は本実施例の概要図である。ストレージシステム４２は、プロセッサ１４とメモリ１８を含むストレージコントローラ１２と、演算処理機構を持ったフラッシュドライブ６０、６２を有し、例えば、ＳＡＮ（Storage Area Network）のような通信ネットワークを介してホスト１０と接続される。本実施例では、フラッシュドライブ１  ６０にはユーザデータが格納され、フラッシュドライブ２  ６２には、パリティが格納されている。
【０１７３】
本実施例プロセッサ１４が（１）ホスト１０から新データ１００のライト要求を受けると、（２）ホスト１０からの新データ１００は、一旦バッファ領域２０に格納された後、旧データ１０２が格納されているフラッシュドライブ１  ６０へ転送される。実施例１、２では、新データのデータロストを防ぐため、ストレージコントローラ１２間で二重に新データを保持していたが、実施例３では、新データが格納されているフラッシュドライブ２  ６２にも新データを転送することで、フラッシュドライブ６０、６２間で新データを二重に持ちデータロストを防ぐ。（３）フラッシュドライブ６０、６２に新データ１００を二重書したら、プロセッサ１４は、ライト要求に対する応答をホスト１０に送信する。
【０１７４】
（４）ホスト１０に応答を送信したことに応じて、パリティ生成の処理を進める。本実施例では、まず、フラッシュドライブ１  ６０内で、新データ１００と旧データ１０２でＸＯＲ演算して、中間データ４７３を生成する。（５）中間データ４７３をバッファ領域２０を経由しフラッシュドライブ２  ６２へ転送する。（６）フラッシュドライブ２  ６２において中間データ４７３と旧パリティ１０４でＸＯＲ演算し、新パリティ１０６を生成する。（７）新パリティ１０６の生成が完了すると、最終的にはフラッシュドライブ２  ６２に書き込んだ新データ１００は不要であるため、削除する。
【０１７５】
本実施例では、パリティ演算処理をフラッシュドライブ内で実施するため、ストレージコントローラ１２のプロセッサ１４の負荷を低減することが出来、さらにメモリ１８へのアクセス数が減ることでストレージコントローラ１２のメモリ帯域の負荷を下げることが出来る。加えて、実施例１と同様に、ホスト１０への応答に応じて新パリティ生成の処理に進むことによるストレージコントローラ１２のプロセッサ１４の負荷も抑制でき、単位時間当たりに処理可能なホストからの要求数が増加し、ストレージシステムの高速化が実現できる。
【０１７６】
図２１は、同実施例のフラッシュドライブ構成図である。例えば、ストレージコントローラ１２のバッファ領域２０に格納されたデータは、ＦＥ  Ｉ／Ｆ４９０から、データ転送部制御部４９２を介し、フラッシュドライブのコントローラ４９４のバッファ５００へ一旦格納される。その後、ＢＥ  Ｉ／Ｆ５１４を介し、ＦＭチップ５１６へ書き込まれる。なお、バッファ５００はメインメモリ４９６と同じ領域でも構わない。
【０１７７】
フラッシュドライブ６０、６２内の処理は、プロセッサ４９８がメインメモリ４９６内のフラッシュドライブ制御プログラム５０２の下で実施する。必要に応じて、フラッシュドライブ情報５０４、ＦＭチップ情報５０６、物理空間を管理する物理ブロック情報５０８、論理空間を管理する論理ブロック論理ブロック情報５１０、物理空間と論理空間の対応を管理する論理物理マップ５１２の管理情報、バッファの容量使用率５１１にアクセスする。ＦＭチップ５１６以外をコントローラ４９４と定義する。
【０１７８】
同実施例のフラッシュドライブ６０、６２の管理情報である物理ブロック情報５０８、論理ブロック情報５１０、及び、論理物理マップ５１２の説明図である。
【０１７９】
物理ブロック情報５０８は、フラッシュドライブ６０、６２内の物理領域を均一なサイズに区切った空間である物理ブロックを管理する。フラッシュドライブの管理ブロックと、ストレージコントローラで管理しているブロックのサイズは同じでも異なっていても良い。以下、物理ブロックとストレージコントローラ１２のブロックのサイズは一致しているケースを想定する。
各物理ブロックにはＩＤが付与され、物理ブロックＩＤ５２２として、ＩＤ一覧と対応する実アドレスが管理されている。物理ブロックの空き容量は物理ブロック内空き容量５２４で、どのＩＤが空き物理ブロックなのかは空き物理ブロックキューで管理する。
【０１８０】
論理ブロック情報５１０は、フラッシュドライブ６０、６２内の論理領域を均一なサイズに区切った空間である論理ブロックを管理する。各論理ブロックにはＩＤが付与され、論理ブロックＩＤとして、ＩＤ一覧と対応する論理アドレスが管理されている。論理ブロックサイズと物理ブロックサイズは同じであるが、論理ブロックＩＤ数は物理ブロックＩＤ数以上である。以下、論理ブロックＩＤとストレージコントローラ１２のブロック＃は一致しているケースを想定する。一致していない場合は、論理ブロックＩＤとストレージコントローラ１２のブロック＃の変換テーブルが追加で必要である。論理領域として格納可能なデータ量及び現状の使用量が、論理ブロックデータ格納量で示される。
【０１８１】
論理物理マップ５１２は、論理ブロックを表す論理アドレス（Logical Block Address、以下、ＬＢＡ）と、物理ブロックを表す物理アドレス（Physical Block Address、以下、ＰＢＡ）の対応関係を管理する。
【０１８２】
図２２は、同実施例の高速ライト処理のフローである。全体のライト処理のフローについては、図１０と同じである。但し、ステップ２４４：高速ライト処理可否判定の条件については、フラッシュドライブ６０、６２のバッファ５００に空き領域があるかも追加される。
【０１８３】
ステップ５５２：ホスト１０からの新データを一旦格納するバッファとして、ストレージコントローラ１２のバッファ領域２０を確保する。ここでは新データ１００を格納するための１サブブロック分だけ確保すれば良い。
【０１８４】
ステップ５５４：新データにより更新される旧データが格納されているフラッシュドライブ１  ６０に新データを転送するためのバッファ５００を確保する。
【０１８５】
ステップ５５６：旧データに関する旧パリティが格納されているフラッシュドライブ２  ６２に新データを転送するためのバッファ５００を確保する。
【０１８６】
ステップ５５８：ホスト１０からの新データをステップ５５２で格納したバッファを経由して、ステップ５５４及びステップ５５６で格納したフラッシュドライブ１  ６０およびフラッシュドライブ２  ６２のそれぞれのバッファ５００に転送する。
【０１８７】
ステップ５６０：フラッシュドライブ６０、６２への二重転送が完了したので、ステップ５５２で確保したストレージコントローラ１２のバッファ管理情報１７６のステータス情報を、新データ転送済みに更新する。
ステップ５６２：ホスト１０に、ライト処理完了応答を送信する。
【０１８８】
ステップ５６４：フラッシュドライブ１  ６０において、新データ１００と旧データ１０２をＸＯＲ演算し、中間データ４７３を生成する。中間データ４７３はバッファ５００のみに格納すればよく、ＦＭチップ５１６まで書き込む必要はない。
【０１８９】
ステップ５６６：中間データ４７３をバッファ領域２０経由しフラッシュドライブ２  ６２のバッファ５００へ転送する。ここで転送に使用するバッファ領域２０は、ステップ５５２で確保した領域を再利用すれば良い。
【０１９０】
ステップ５６８：フラッシュドライブ２  ６２において、中間データ４７３と旧パリティ１０４でＸＯＲ演算し、新パリティ１０６を生成する。この段階で、新パリティ１０６はバッファ５００のみに格納すればよく、ＦＭチップ５１６まで書き込む必要はない。フラッシュドライブ２のプロセッサ４９８は、パリティ生成完了をストレージコントローラ１２のプロセッサ１４へ通知する。
【０１９１】
ステップ５７０：ストレージコントローラのプロセッサ１４は、フラッシュドライブ２  ６２のプロセッサ４９８に対し、新パリティを確定させるよう指示する。指示を受けたフラッシュドライブ２  ６２は、論理物理マップ５１２において、新パリティ１０６用に物理ブロックアドレスを新規確保し、旧パリティ１０４のＬＢＡに対するＰＢＡを、新パリティ１０６のＰＢＡに更新、すなわち、論物マッピングの切り替えをすることで、旧パリティを破棄し、ストレージコントローラ１２からも新パリティが認識できるようになる。
【０１９２】
ステップ５７２：ステップ５７０と同じ方法で、論理物理マップ５１２で、旧データ１０２のＬＢＡに対するＰＢＡを新データ１００のＰＢＡに更新することで論物マッピングを切り替えて新データを確定させる。
【０１９３】
ステップ５７４：ステップ５５２で確保したストレージコントローラ１２のバッファ領域２０を解放する。解放の方法は、ステップ３８０と同じである。その後、ステップ５７６へ進む。
【０１９４】
ステップ５７６：新データ、新パリティ全て確定したため、ステップ５５６及びステップ５５８でデータロスト用に保持していたフラッシュドライブ２  ６２に格納された新データを削除し、処理完了となる。
【０１９５】
図２３は、同実施例の通常ライト処理切り替え判定５８０の処理フローである。
【０１９６】
ステップ５８２：新パリティ１０６及び新データ１００が確定済みか判定する。これは、フラッシュドライブ１  ６０及びフラッシュドライブ２  ６２に旧データ１０２があるか、もしくはストレージコントローラのバッファ管理情報１７６の有無を確認すれば良い。Ｙｅｓならばステップ５９８へ、Ｎｏならばステップ２７２とステップ２７４へ進む。
【０１９７】
ステップ２７２で、新データ用キャッシュ領域を確保し、ステップ２７４で、新データ用キャッシュ領域のロックを取得する。詳細は、図１２のステップ２７２、２７４と同様である。
【０１９８】
ステップ１１００：フラッシュドライブへ新データが転送済みかを判定する。これは、フラッシュドライブ１  ６０  及びフラッシュドライブ２  ６２に新データ１００があるか、または、ストレージコントローラ１２のバッファ管理情報１７６のステータス情報１７８を確認すれば良い。転送済み（Ｙｅｓ）であればステップ５９６へ、転送が済んでいなければ（Ｎｏ）ステップ４１４へ進む。
【０１９９】
ステップ４１４は、図１６と同様の処理である。バッファ領域２０から、確保したキャッシュ領域２２へ、新データをコピーする。バッファブロック管理情報１７６も、キャッシュ管理情報にコピーする。
【０２００】
ステップ５９６：フラッシュドライブ１  ６０もしくはフラッシュドライブ２  ６２のバッファ５００から、ステップ２７２で確保したキャッシュ領域２２へ、新データをコピーする、さらに、ストレージコントローラ１２の当該バッファ領域管理情報１７０から、前ステップで確保したキャッシュ管理情報４０へ、データ用及びパリティ用の管理情報１７６のエラー情報をコピーし、当該バッファ領域管理情報１７０のステータス情報からブロック情報１１６に対し適切なキューヘッダ１００にキューイングし、キャッシュ割り当て管理情報１２０のライト面１２４両方にキューイングする。コピー先は自他ストレージコントローラ１２それぞれのキャッシュ管理テーブル４０である。
【０２０１】
ステップ５９２：当該ライトＩ／Ｏについて、高速ライト処理２２から通常ライト処理２４へ切り替える。切り替え先の通常ライト処理２４は、図１３のステップ２９０から続ければ良い。
【０２０２】
ステップ５９８：フラッシュドライブ１  ６０のバッファ５００を解放する。解放することで、新データも削除される。
【０２０３】
ステップ５９０：フラッシュドライブ２  ６２の該バッファ５００を解放する。解放することで、新データも削除される。
【０２０４】
ステップ５８８：ストレージコントローラの当該バッファ領域２０を解放する。解放の方法としては、図１１ステップ３８０と同等である。
以上で、処理は完了する。
【０２０５】
本実施例では、パリティ演算処理をフラッシュドライブ内で実施するため、ストレージコントローラ１２のプロセッサ１４の負荷を低減することが出来る。加えて、実施例１と同様に、ホスト１０への応答に応じて新パリティ生成の処理に進むため、ライト要求とは非同期で新パリティを生成する際に新パリティを生成する必要がある新データを探し出す、というオーバーヘッドを削減し、フラッシュドライブのプロセッサ４９８の負荷を抑制することができ、単位時間当たりに処理可能なホストからの要求数が増加し、ストレージシステムの高速化が実現できる。
【０２０６】
＜用語の説明＞
以上の説明では、「×××テーブル」の表現にて情報を説明したが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。
また、以上の説明では、種々の対象のＩＤ（識別情報）として、番号が使用されるが、番号に代えて又は加えて他種の識別情報が使用されてもよい。
【０２０７】
また、以上の説明では、「ドライブ」は、物理的な記憶デバイスを示し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよく、ドライブは、例えばＳＳＤ、またはＨＤＤでよい。
また、以上の説明では、「ＲＡＩＤ」は、Redundant Array of Independent (or Inexpensive) Disksの略である。ＲＡＩＤグループは、複数のドライブで構成され、そのＲＡＩＤグループに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤグループは、パリティグループと呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤグループのことでよい。
【０２０８】
また、以上の説明では、「ＬＤＥＶ」は、Logical Deviceの略である。ドライブをＲＡＩＤ等の制御方法で制御することによって提供される記憶領域（例えばＲＡＩＤグループ（または、パリティグループ）を用いて構成される論理装置を示し、ドライブは、ＬＤＥＶを単位とする記憶領域を提供する。
【０２０９】
また、以上の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置又はシステムが行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【０２１０】
また、以上の説明では、「ホストシステム」は、ストレージシステムにＩ／Ｏ（Input / Output）要求を送信するシステムであり、インターフェースデバイスと、記憶部（例えばメモリ）と、それらに接続されたプロセッサとを有してよい。ホストシステムは、１以上のホスト計算機で構成されてよい。少なくとも１つのホスト計算機は、物理的な計算機でよく、ホストシステムは、物理的なホスト計算機に加えて仮想的なホスト計算機を含んでよい。また、サーバとストレージシステムが一体型の場合、サーバ内の仮想マシンの一つが、Ｉ／Ｏ要求を送信する、という構成でもよい。
【０２１１】
また、以上の説明では、「ストレージシステム」は、１以上のストレージ装置でよく、複数のドライブ（例えば１以上のＲＡＩＤグループ）と、複数のドライブに対するＩ／Ｏを制御するストレージコントローラとを有してよい。ストレージコントローラは、複数のドライブに接続されるバックエンドのインターフェースデバイス（ＢＥ  Ｉ／Ｆ）と、ホストシステム及び管理システムのうちの少なくとも１つに接続されるフロントエンドのインターフェースデバイス（ＦＥ  Ｉ／Ｆ）と、記憶部と、それらに接続されたプロセッサとを有してよい。ストレージコントローラは、冗長化されていてもよい。
【０２１２】
また、以上の説明では、「ＶＯＬ」は、論理ボリュームの略であり、論理的な記憶デバイスでよい。
【０２１３】
以上、いくつかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【符号の説明】
【０２１４】
１０：ホスト、４２：ストレージシステム、１２：ストレージコントローラ、１４：プロセッサ、１８：メモリ、２４：プログラム領域、２０：バッファ領域、２２：キャッシュ領域、２６：ドライブ、２８：ドライブグループ、３０：管理テーブル領域、３２：バッファ領域管理テーブル、３４：キャッシュ領域管理テーブル、３５：キャッシュディレクトリ管理テーブル、３６：ＬＤＥＶページ管理、３８：ＪＯＢ＃管理、５２：ＦＥ  Ｉ／Ｆ、５４：ＢＥ  Ｉ／Ｆ、５６：ＳＷ、１００：新データ、１０２：旧データ、１０４：旧パリティ、１０６：新パリティ
【図１】
0006750011.tif 000002
【図２】
0006750011.tif 000003
【図３】
0006750011.tif 000004
【図４】
0006750011.tif 000005
【図５】
0006750011.tif 000006
【図６】
0006750011.tif 000007
【図７】
0006750011.tif 000008
【図８】
0006750011.tif 000009
【図９】
0006750011.tif 000010
【図１０】
0006750011.tif 000011
【図１１】
0006750011.tif 000012
【図１２】
0006750011.tif 000013
【図１３】
0006750011.tif 000014
【図１４】
0006750011.tif 000015
【図１５】
0006750011.tif 000016
【図１６】
0006750011.tif 000017
【図１７】
0006750011.tif 000018
【図１８】
0006750011.tif 000019
【図１９】
0006750011.tif 000020
【図２０】
0006750011.tif 000021
【図２１】
0006750011.tif 000022
【図２２】
0006750011.tif 000023
【図２３】
0006750011.tif 000024
【図２４】
0006750011.tif 000025