JP6750011B2 - 情報処理システム - Google Patents

情報処理システム Download PDF

Info

Publication number
JP6750011B2
JP6750011B2 JP2018523089A JP2018523089A JP6750011B2 JP 6750011 B2 JP6750011 B2 JP 6750011B2 JP 2018523089 A JP2018523089 A JP 2018523089A JP 2018523089 A JP2018523089 A JP 2018523089A JP 6750011 B2 JP6750011 B2 JP 6750011B2
Authority
JP
Japan
Prior art keywords
data
write
parity
new
new data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018523089A
Other languages
English (en)
Other versions
JPWO2017216887A1 (ja
Inventor
美保 今崎
美保 今崎
山本　彰
山本　　彰
朋宏 吉原
朋宏 吉原
講平 鑪
講平 鑪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2017216887A1 publication Critical patent/JPWO2017216887A1/ja
Application granted granted Critical
Publication of JP6750011B2 publication Critical patent/JP6750011B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/12—Replacement control
    • G06F12/121—Replacement control using replacement algorithms
    • G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0871—Allocation or management of cache space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/10—Indexing scheme relating to G06F11/10
    • G06F2211/1002—Indexing scheme relating to G06F11/1076
    • G06F2211/1019—Fast writes, i.e. signaling the host that a write is done before data is written to disk
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1032—Reliability improvement, data loss prevention, degraded operation etc
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/26—Using a specific storage system architecture
    • G06F2212/261—Storage comprising a plurality of storage devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/30—Providing cache or TLB in specific location of a processing system
    • G06F2212/304—In main memory subsystem
    • G06F2212/3042—In main memory subsystem being part of a memory device, e.g. cache DRAM

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Detection And Correction Of Errors (AREA)

Description

本発明は、ライト性能を高速化する情報処理システムに関する。
近年、インターネットバンキングや電子商取引で利用されるＯＬＴＰ（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）要求を送信するシステムであり、インターフェースデバイスと、記憶部（例えばメモリ）と、それらに接続されたプロセッサとを有してよい。ホストシステムは、１以上のホスト計算機で構成されてよい。少なくとも１つのホスト計算機は、物理的な計算機でよく、ホストシステムは、物理的なホスト計算機に加えて仮想的なホスト計算機を含んでよい。また、サーバとストレージシステムが一体型の場合、サーバ内の仮想マシンの一つが、Ｉ／Ｏ要求を送信する、という構成でもよい。
また、以上の説明では、「ストレージシステム」は、１以上のストレージ装置でよく、複数のドライブ（例えば１以上のＲＡＩＤグループ）と、複数のドライブに対するＩ／Ｏを制御するストレージコントローラとを有してよい。ストレージコントローラは、複数のドライブに接続されるバックエンドのインターフェースデバイス（ＢＥ Ｉ／Ｆ）と、ホストシステム及び管理システムのうちの少なくとも１つに接続されるフロントエンドのインターフェースデバイス（ＦＥ Ｉ／Ｆ）と、記憶部と、それらに接続されたプロセッサとを有してよい。ストレージコントローラは、冗長化されていてもよい。
また、以上の説明では、「ＶＯＬ」は、論理ボリュームの略であり、論理的な記憶デバイスでよい。
以上、いくつかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
１０：ホスト、４２：ストレージシステム、１２：ストレージコントローラ、１４：プロセッサ、１８：メモリ、２４：プログラム領域、２０：バッファ領域、２２：キャッシュ領域、２６：ドライブ、２８：ドライブグループ、３０：管理テーブル領域、３２：バッファ領域管理テーブル、３４：キャッシュ領域管理テーブル、３５：キャッシュディレクトリ管理テーブル、３６：ＬＤＥＶページ管理、３８：ＪＯＢ＃管理、５２：ＦＥ Ｉ／Ｆ、５４：ＢＥ Ｉ／Ｆ、５６：ＳＷ、１００：新データ、１０２：旧データ、１０４：旧パリティ、１０６：新パリティ

Claims (9)

  1. プロセッサと、メモリと、を有し、ストレージデバイスに対してデータの入出力を行う情報処理システムにおいて、
    前記メモリは、バッファ領域とキャッシュ領域を有し、
    前記プロセッサは、ライト処理を行い、
    前記ライト処理は、
    受信したライト要求にかかる新データを前記メモリに格納することと、
    前記新データによって更新される旧データと、前記旧データにかかる旧パリティを、前記ストレージデバイスから読み出して、前記メモリに格納することと、
    前記新データと、前記旧データと、前記旧パリティとに基づいて、前記新データにかかる新パリティを生成して前記メモリに格納することと、
    前記新データと、前記新パリティと、を前記ストレージデバイスに格納することと
    を含み、
    前記プロセッサは、前記新データを前記メモリのバッファ領域に格納する第１のライト処理と、前記新データを前記メモリのキャッシュ領域に格納する第２のライト処理と、を選択的に実行可能であり、
    前記第１のライト処理を実行中の新データについてリード要求を受信した場合、前記プロセッサは、前記第１のライト処理を第２のライト処理に切り替え、前記第２のライト処理にて前記キャッシュ領域に格納した新データを、前記リード要求の要求元に送信する、
    情報処理システム。
  2. 請求項１に記載の情報処理システムにおいて、
    前記プロセッサは、前記新データのライト要求を受信すると、前記第１のライト処理を行う場合、前記第１のライト処理において、前記メモリ内に、前記新データ、前記旧データ、前記旧パリティ、および、前記新パリティを格納するための格納領域を確保し、前記格納領域を確保した後に、前記新データを受領する、
    情報処理システム。
  3. 請求項１又は２に記載の情報処理システムにおいて、
    前記プロセッサは、さらに、前記第１のライト処理において、前記新パリティを、前記バッファ領域内に格納する、
    情報処理システム。
  4. 請求項１乃至３のうちのいずれか１項に記載の情報処理システムにおいて、
    前記プロセッサは、前記第１のライト処理において、前記新データ及び前記新パリティを前記ストレージデバイスに格納すると、前記バッファ領域内に格納した前記旧データおよび前記旧パリティを、前記バッファ領域から削除する、
    情報処理システム。
  5. 請求項１乃至４のうちのいずれか１項に記載の情報処理システムにおいて、
    前記プロセッサは、前記第１のライト処理において、前記新データおよび前記新パリティを、前記キャッシュ領域に格納する、
    情報処理システム。
  6. 請求項１乃至５のうちのいずれか１項に記載の情報処理システムにおいて、
    前記プロセッサは、前記第１のライト処理において、前記新データを前記キャッシュ領域に格納した場合に、応答を前記ライト要求の送信元に送信し、前記応答の送信の後に、前記新パリティの生成を行う、
    情報処理システム。
  7. 請求項１乃至５のうちのいずれか１項に記載の情報処理システムにおいて、
    前記プロセッサは、前記第１のライト処理において、前記新データを前記キャッシュ領域に格納した場合に、応答を前記ライト要求の送信元に送信し、
    前記プロセッサは、前記応答の送信とは非同期に前記新パリティの生成を行う、
    情報処理システム。
  8. 請求項１乃至７のうちのいずれか１項に記載の情報処理システムにおいて、
    前記ストレージデバイスは、データを格納する第１のストレージデバイスと、パリティを格納する第２のストレージデバイスとを有し、
    前記第１のストレージデバイスは、前記旧データを読み出すとともに、前記新データを格納し、
    前記第２のストレージデバイスは、前記旧パリティを読み出すとともに、前記新パリティを格納する、
    情報処理システム。
  9. プロセッサと、メモリと、を有する情報処理システムが、ストレージデバイスに対してデータの入出力を行う情報処理方法において、
    前記メモリは、バッファ領域とキャッシュ領域を有し、
    前記プロセッサは、ライト処理を行うようになっており、
    前記ライト処理は、
    受信したライト要求にかかる新データを前記メモリに格納することと、
    前記新データによって更新される旧データと、前記旧データにかかる旧パリティを、前記ストレージデバイスから読み出して、前記メモリに格納することと、
    前記新データと、前記旧データと、前記旧パリティとに基づいて、前記新データにかかる新パリティを生成して前記メモリに格納することと、
    前記新データと、前記新パリティと、を前記ストレージデバイスに格納することと
    を含み、
    前記プロセッサは、前記新データを前記メモリのバッファ領域に格納する第１のライト処理と、前記新データを前記メモリのキャッシュ領域に格納する第２のライト処理と、を選択的に実行可能であり、
    前記情報処理方法において、
    前記第１のライト処理を実行中の新データについてリード要求を受信した場合、前記プロセッサは、前記第１のライト処理を第２のライト処理に切り替え、
    前記プロセッサは、前記第２のライト処理にて前記キャッシュ領域に格納した新データを、前記リード要求の要求元に送信する、
    情報処理方法。
JP2018523089A 2016-06-15 2016-06-15 情報処理システム Active JP6750011B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/067718 WO2017216887A1 (ja) 2016-06-15 2016-06-15 情報処理システム

Publications (2)

Publication Number Publication Date
JPWO2017216887A1 JPWO2017216887A1 (ja) 2019-01-17
JP6750011B2 true JP6750011B2 (ja) 2020-09-02

Family

ID=60663054

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018523089A Active JP6750011B2 (ja) 2016-06-15 2016-06-15 情報処理システム

Country Status (3)

Country Link
US (1) US10853268B2 (ja)
JP (1) JP6750011B2 (ja)
WO (1) WO2017216887A1 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109725824A (zh) * 2017-10-27 2019-05-07 伊姆西Ip控股有限责任公司 用于向存储系统中的盘阵列写入数据的方法和设备
WO2019183958A1 (zh) * 2018-03-30 2019-10-03 华为技术有限公司 数据写入方法、客户端服务器和系统
US11151037B2 (en) * 2018-04-12 2021-10-19 International Business Machines Corporation Using track locks and stride group locks to manage cache operations
CN110147205A (zh) * 2019-05-23 2019-08-20 江苏芯盛智能科技有限公司 一种ssd及raid实现方法、系统、设备、介质
SG11202002775RA (en) 2019-09-12 2020-04-29 Alibaba Group Holding Ltd Log-structured storage systems
EP3682340A4 (en) 2019-09-12 2020-12-02 Advanced New Technologies Co., Ltd. LOG-STRUCTURED STORAGE SYSTEMS
US10942852B1 (en) 2019-09-12 2021-03-09 Advanced New Technologies Co., Ltd. Log-structured storage systems
WO2019228572A2 (en) 2019-09-12 2019-12-05 Alibaba Group Holding Limited Log-structured storage systems
WO2019228574A2 (en) 2019-09-12 2019-12-05 Alibaba Group Holding Limited Log-structured storage systems
WO2019233500A2 (en) * 2019-09-12 2019-12-12 Alibaba Group Holding Limited Log-structured storage systems
CN115398874A (zh) 2019-09-12 2022-11-25 创新先进技术有限公司 日志结构存储系统
WO2019228570A2 (en) 2019-09-12 2019-12-05 Alibaba Group Holding Limited Log-structured storage systems
CN111886582A (zh) 2019-09-12 2020-11-03 创新先进技术有限公司 日志结构存储系统
US11550728B2 (en) * 2019-09-27 2023-01-10 Advanced Micro Devices, Inc. System and method for page table caching memory
US11126378B1 (en) 2020-05-27 2021-09-21 Western Digital Technologies, Inc. Rate limit on the transitions of zones to open
US11194521B1 (en) * 2020-05-27 2021-12-07 Western Digital Technologies, Inc. Rate limit on the transitions of streams to open
US20230229556A1 (en) * 2022-01-19 2023-07-20 Micron Technology, Inc. Parity cache for raid reliability, accessibility, and serviceability of a memory device

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3409859B2 (ja) * 1991-01-31 2003-05-26 株式会社日立製作所 制御装置の制御方法
US5579474A (en) * 1992-12-28 1996-11-26 Hitachi, Ltd. Disk array system and its control method
US5870625A (en) * 1995-12-11 1999-02-09 Industrial Technology Research Institute Non-blocking memory write/read mechanism by combining two pending commands write and read in buffer and executing the combined command in advance of other pending command
JPH1031563A (ja) * 1996-07-16 1998-02-03 Hitachi Ltd 記憶装置
JPH10269695A (ja) * 1997-03-25 1998-10-09 Hitachi Ltd コンピュータシステムにおける記憶装置の制御方式
US6012123A (en) * 1997-06-10 2000-01-04 Adaptec Inc External I/O controller system for an independent access parity disk array
US6243795B1 (en) 1998-08-04 2001-06-05 The Board Of Governors For Higher Education, State Of Rhode Island And Providence Plantations Redundant, asymmetrically parallel disk cache for a data storage system
US6370611B1 (en) * 2000-04-04 2002-04-09 Compaq Computer Corporation Raid XOR operations to synchronous DRAM using a read buffer and pipelining of synchronous DRAM burst read data
JP2004213470A (ja) * 2003-01-07 2004-07-29 Nec Corp ディスクアレイ装置及びディスクアレイ装置におけるデータ書き込み方法
US7188219B2 (en) * 2004-01-30 2007-03-06 Micron Technology, Inc. Buffer control system and method for a memory system having outstanding read and write request buffers
US7231497B2 (en) * 2004-06-15 2007-06-12 Intel Corporation Merging write-back and write-through cache policies
US7366846B2 (en) * 2005-01-14 2008-04-29 International Business Machines Corporation Redirection of storage access requests
TWI320139B (en) * 2005-08-01 2010-02-01 Method for improving writing data efficiency and storage subsystem and system implementing the same
JP4977583B2 (ja) 2007-11-22 2012-07-18 株式会社日立製作所 記憶制御装置及び記憶制御装置の制御方法
JP5245472B2 (ja) * 2008-03-13 2013-07-24 富士通株式会社 制御方法、ディスクアレイ装置
US7774522B2 (en) * 2008-11-17 2010-08-10 Applied Micro Circuits Corporation Cache stashing processor control messages
WO2010131373A1 (en) 2009-05-15 2010-11-18 Hitachi,Ltd. Storage subsystem
US8285931B2 (en) * 2010-02-26 2012-10-09 Red Hat, Inc. Methods for reducing cache memory pollution during parity calculations of RAID data
JP6017065B2 (ja) * 2013-01-31 2016-10-26 株式会社日立製作所 ストレージシステム及びキャッシュコントロール方法
US20150339058A1 (en) 2013-03-26 2015-11-26 Hitachi, Ltd. Storage system and control method
US20170286114A1 (en) * 2016-04-02 2017-10-05 Intel Corporation Processors, methods, and systems to allocate load and store buffers based on instruction type

Also Published As

Publication number Publication date
JPWO2017216887A1 (ja) 2019-01-17
US10853268B2 (en) 2020-12-01
US20190012270A1 (en) 2019-01-10
WO2017216887A1 (ja) 2017-12-21

Similar Documents

Publication Publication Date Title
JP6750011B2 (ja) 情報処理システム
US11163699B2 (en) Managing least recently used cache using reduced memory footprint sequence container
CN107967124B (zh) 一种分布式持久性内存存储系统及方法
US9983993B2 (en) Apparatus, system, and method for conditional and atomic storage operations
US9442844B2 (en) Apparatus, system, and method for a storage layer
US9606914B2 (en) Apparatus, system, and method for allocating storage
JP5937697B2 (ja) ストレージシステム
US10133663B2 (en) Systems and methods for persistent address space management
US9251086B2 (en) Apparatus, system, and method for managing a cache
US9223655B2 (en) Storage system and method for controlling storage system
CN111587423A (zh) 分布式存储系统的分层数据策略
US10740189B2 (en) Distributed storage system
WO2015141219A1 (ja) ストレージシステム、制御装置、記憶装置、データアクセス方法及びプログラム記録媒体
JP6163588B2 (ja) ストレージシステム
CN112346658B (zh) 在具有高速缓存体系结构的存储设备中提高数据热量跟踪分辨率
US11782842B1 (en) Techniques for reclaiming dirty cache pages

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180904

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180904

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191023

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20191220

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200623

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200629

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200714

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200812

R150 Certificate of patent or registration of utility model

Ref document number: 6750011

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150