JP3592640B2 - ディスク制御システムおよびディスク制御方法 - Google Patents
ディスク制御システムおよびディスク制御方法 Download PDFInfo
- Publication number
- JP3592640B2 JP3592640B2 JP2001001137A JP2001001137A JP3592640B2 JP 3592640 B2 JP3592640 B2 JP 3592640B2 JP 2001001137 A JP2001001137 A JP 2001001137A JP 2001001137 A JP2001001137 A JP 2001001137A JP 3592640 B2 JP3592640 B2 JP 3592640B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- write
- logical address
- writing
- area
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/064—Management of blocks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0656—Data buffering arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
- G06F3/0689—Disk arrays, e.g. RAID, JBOD
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0614—Improving the reliability of storage systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ディスク制御システムおよびディスク制御方法に関し、特に、ＲＡＩＤ制御装置に用いられていた書き込みバッファやアドレス変換テーブルなどを構成する専用の不揮発性メモリを使用しないで、主メモリとディスク装置だけを用いて、ディスク上のストライプに連続的にライトリクエストのデータを書き込むディスク制御システムおよびディスク制御方法に関するものである。
【０００２】
【従来の技術】
ＲＡＩＤ構成のディスク制御システムのライト方式は、例えば特開平６−２１４７２０号公報や、特開平１１−５３２３５号公報に示すように、ランダムライトを１つの連続した領域としての物理ストライプにまとめて書き込む方式が提案されている。しかしながら、従来技術では、書き込むデータを一度不揮発性メモリ（以下、ＮｖＲＡＭと称する）又は揮発性メモリに書き込み、１ストライプ分の書込みデータが揃った時点で、ディスク装置上の物理ストライプに書込みを行っていた。また、上位ファイルシステムからの論理アドレスをディスク上の物理アドレスに変換したアドレス変換テーブルを上記ＮｖＲＡＭに記憶させていた。
【０００３】
この様に、一度、ＮｖＲＡＭにデータを書き込むことにより、ディスク装置上に書き込む前にシステムが異常停止したとしても、システムリブート後にＮｖＲＡＭを参照し、ＮｖＲＡＭ上の書きかけのデータを正しくディスク装置に書き込むことにより、書き込みを完了させることができる（書き込みデータを失わない）効果が有る。
【０００４】
即ち、ＮｖＲＡＭへのデータ書き込みが終れば、そのライトデータが失われることはない。このため、従来のディスク制御システムでは、書き込みデータをＮｖＲＡＭに書き込んだ時点で、そのライトリクエストに対して「完了」をホストに通知していた。
【０００５】
【発明が解決しようとする課題】
しかしながら、ＮｖＲＡＭはシステムに装着するＩ／Ｏカード（ハードウェア）で提供する必要が有り、その分コストがかかるという問題があり、また、ホスト計算機との相性の問題、互換性、保守等の手間もかかる等の問題がある。
【０００６】
本発明では、ＮｖＲＡＭを使わずに、主メモリとディスク装置だけを用いて、ディスク上のストライプに連続的にライトリクエストのデータを書き込むディスク制御システムおよびディスク制御方法を提供することを目的とする。また、ＮｖＲＡＭを使用せずとも異常停止時にデータを損失することが無く、システムの性能向上を実現させるものである。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられた管理データ領域に、前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【０００８】
本発明によれば、不揮発性メモリに代わりに、ディスク上に設けられた管理データ領域１８ｂ、データ領域１８ｃなどを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。したがって、シーク／回転待ちが少なくなり、不揮発性メモリを使用しなくても高速な書き込み処理が実現される。
【０００９】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、主メモリ上に設けられたライトバッファに、複数のライトリクエストに対応する複数のブロックデータを書き込む手段と、前記複数のライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に、前記ライトバッファに記憶した複数のブロックデータを一括ライトするデータ書き込み手段と、前記複数のブロックデータに対応する前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として、前記複数のディスク上に設けられた管理データ領域に一括ライトするログ書き込み手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに完了を通知する手段とを具備することを特徴とする。
【００１０】
本発明によれば、不揮発性メモリに代わりに、ディスク上に設けられた管理データ領域１８ｂ、データ領域１８ｃなどを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。また、複数のライトリクエストが１度のデータライト処理と１度の論理アドレスログ情報の書き込みとして処理することができるため、書き込み処理回数が減り、書き込みサイズが大きくなることでディスクへのトータルとして書き込みオーバヘッドが小さくなり、結果的に書き込み処理のスループットが向上する。
【００１１】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、および書き込みデータサイズ、および書き込みデータのチェックサムを論理アドレスログ情報として書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【００１２】
本発明によれば、ディスクのデータ領域へのデータ書き込み中にシステムの障害が発生した場合には、書き込み処理途中のストライプに関して、その論理アドレスログ領域に書き込まれているチェックサム値とデータ領域のデータから求めたチェックサム値とが一致するか否かを確認チェックすることにより、一致している場合には、データ書き込みが完了していたと判断し、データを有効とみなし残りの処理（アドレス変換テーブルへの登録等）を行ない、効率的な障害回復処理が実行できる。
【００１３】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、書き込みデータサイズ、書き込みデータのチェックサム、および少なくとも１データブロックを論理アドレスログ情報として書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記論理アドレスログ領域への前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【００１４】
本発明によれば、個々のライトリクエストに対して、論理アドレスログ領域に論理アドレスログ情報とライトデータａの書き込みが完了すれば、その時点でＯＳファイルシステムに対して完了通知することができる。つまり、ＯＳファイルシステムに対するレスポンスが早くなる。
【００１５】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域のヘッダ部に有効／無効を示すフラグ、ストライプＩＤ番号、および最終データの書き込みタイムスタンプを記録し、前記論理アドレスログ領域のエントリ部に書き込みリクエストによって処理される１つ又は複数のブロックデータのタイムスタンプ、１つ又は複数の論理アドレス、および１つ又は複数のチェックサムを論理アドレスログ情報として書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その前記論理アドレスログ領域に書き込まれているチェックサム値が前記データ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし、そのデータを捨てることを特徴とする。
【００１６】
本発明によれば、書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その論理アドレスログ領域に書き込まれているチェックサム値がデータ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし捨てることにより、障害回復処理を効率よく実行することが出来る。
【００１７】
【発明の実施の形態】
先ず、本発明で用いられる各種の用語について説明する。
（データストライプ）
ディスク制御システムが「まとめ書き」（又は「一括書き」とも言われる）するデータの単位を意味する。ディスクのパーティション上で、一続きの領域となっており、ＲＡＩＤコントローラが管理するストライプサイズの整数倍のサイズである。ＲＡＩＤ５に対しては、このサイズをパリティグループにする事により、いわゆる「ＲＡＩＤ５のライトペナルティ」を改善する事ができ、大幅な性能向上を実現できる。ストライプは複数のデータブロックから構成される。
【００１８】
（ストライプ番号）
パーティション上に並んでいる物理ストライプの通し番号を意味する。
【００１９】
（論理ブロック番号＝論理アドレス番号）
「論理ブロック番号」とは、上位ファイルシステムから見た時のディスクパーティション上のデータブロック番号である。ディスク制御システム方式では、上位ファイルシステムがアクセスを要求する時のブロック番号は、論理ブロック番号であり、仮想的なブロック番号である。この論理ブロック番号は、ディスク制御システムが管理する「アドレス変換テーブル」によって物理ブロック番号（物理パーティション上の物理的なブロック番号）と対応づけられる。（物理ブロック番号）×（ブロックサイズ［バイト］）よりパーティション上でのバイトオフセット値（アドレス）が求まる。
【００２０】
（アドレス変換テーブル：ＡＭＴ（Ａｄｄｒｅｓｓ Ｍａｐｐｉｎｇ Ｔａｂｌｅ））
ディスク制御システム方式では、上位ファイルシステムがアクセスを要求する時のブロック番号は、論理ブロック番号であり、仮想的なブロック番号である。この論理ブロック番号はディスク制御システムが管理する「アドレス変換テーブル」によって物理ブロック番号（物理パーティション上の物理的なブロック番号）と対応づけられる。本発明の実施形態では、アドレス変換テーブルは、対象パーティション上に有り、データ部と別の領域が割り当てられる。アドレス変換テーブルは、論理ブロック番号に対する物理ブロック番号が登録されたれたテーブルである。新たにデータブロックを書き込む時には、相当する論理ブロック番号のエントリに、そのブロックを書き込む物理ブロック番号（＝ディスク上のアドレス）を登録する。また、データブロックを参照する際には、その論理アドレスをインデックスとするエントリの値を求め、その値をディスク上の物理ブロック番号として実際のアドレスを求め参照する。
【００２１】
以下、図面を参照して本発明の実施形態について説明する。
図１には、本発明の一実施形態に係るディスク制御システムを適用した計算機システムの構成が示されている。この計算機システムは、例えばサーバ（ＰＣサーバ）として利用されるものであり、複数のＣＰＵ（＃１、＃２、＃Ｎ）１１を搭載することが出来る。これら各ＣＰＵ１１は図示のようにプロセッサバス１を介してブリッジ１２に接続されている。ブリッジ１２はプロセッサバス１とＰＣＩバス２を双方向で接続するためのブリッジＬＳＩであり、ここには主メモリ１３を制御するためのメモリコントローラも内蔵されている。主メモリ１３には、オペレーティングシステム（ＯＳ）、実行対象のアプリケーションプログラム、およびドライバなどがロードされている。また、本発明では、主メモリ１３のドライバ作業領域１７に、ライトバッファ（まとめ書きバッファ）１７１、アドレス変換テーブル（以下、ＡＭＴキャッシュと称する）１７２、ストライプ管理テーブル１７３が設けられている。
【００２２】
ライトバッファ１７１は、書き込みデータブロックを蓄積するためのデータバッファであり、このライトバッファ１７１に例えば１物理ストライプ分の書き込みデータブロックが蓄積された時点でディスクアレイ１８への一括書き込みが開始されるが、本発明においてはそれに限定されるものではない。まとめ書きを行なう場合、物理ストライプは「まとめ書き」の単位であり、ディスクアレイ１８の全記憶領域に形成されたパーティション上で一続きの連続した領域から構成される。各物理ストライプは、ＲＡＩＤコントローラ１６が管理するストライプユニットの整数倍のサイズである。
【００２３】
ＡＭＴキャッシュ１７２は、論理アドレス空間を構成する複数の論理ブロック番号それぞれと、それら論理ブロック番号で指定されるデータブロックが存在するディスクアレイ１８上の物理位置を示す物理ブロック番号との対応関係を示すアドレス変換情報を記憶する。ＯＳファイルシステムがアクセスを要求するときのブロック番号は論理ブロック番号であり、これは仮想的な論理アドレスである。この論理ブロック番号はＡＭＴキャッシュ１７２によって物理ブロック番号（ディスクパーティション上の物理的なブロック番号）と対応づけられる。また、物理ブロック番号×ブロックサイズ（バイト）によって、ディスクパーティションの先頭位置からのバイトオフセット値が求められる。
【００２４】
また、ＡＭＴキャッシュ１７２は、論理ブロック番号それぞれに対応する複数のエントリを有している。新たにデータブロックを書き込むときには、書き込み要求された論理ブロック番号に対応するエントリには、そのデータブロックの実際に書き込まれる物理ブロック番号（物理アドレス）が登録される。データブロックの読み出し時には、読み出し要求された論理ブロック番号に対応するエントリから物理ブロック番号が調べられ、その物理ブロック番号（物理ブロック番号×ブロックサイズ）で指定されるディスクパーティション上の物理位置からデータブロックが読み出される。
【００２５】
ストライプ管理テーブル１７３は、各論理ストライプに関する情報を管理するためのものであり、それら各論理ストライプの情報はデータ再配置のための処理などに利用される。
【００２６】
ＰＣＩバス２には、ＲＡＩＤコントローラ１６が接続されている。ＲＡＩＤコントローラ１６によって制御される複数のディスク装置で構成されるディスクアレイ１８は、各種ユーザデータの記録等に用いられる。
【００２７】
ディスクアレイ１８は、ＲＡＩＤコントローラ１６の制御により、例えばＲＡＩＤ５構成のディスクアレイとして機能する。この場合、ディスクアレイ１８は、データ記憶用のＮ台のディスク装置にパリティ記憶用のディスク装置を１台付加したＮ＋１台（ここでは、ＤＩＳＫ０〜ＤＩＳＫ４の５台）のディスク装置から構成される。これらＮ＋１台のディスク装置はグループ化され、単一の論理ディスクドライブとして使用される。
【００２８】
グループ化されたディスク装置には、図示のように、データ（ＤＡＴＡ）とそのパリティ（ＰＡＲＩＴＹ）とから構成される物理ストライプ（パリティグループ）が割り当てられ、かつ、パリティ位置は物理ストライプ毎にＮ＋１台のディスク装置間で順に移動される。例えば、物理ストライプＳ０では、ＤＩＳＫ０〜ＤＩＳＫ３それぞれの同一位置に割り当てられたストライプ上のデータ（ＤＡＴＡ）群のパリティ（ＰＡＲＩＴＹ）は、ＤＩＳＫ４の対応するストライプ上に記録される。また、物理ストライプＳ１においては、そのストライプＳ１のデータに対応するパリティ（ＰＡＲＩＴＹ）は、ＤＩＳＫ３の対応するストライプ上に記録される。このようにパリティを物理ストライプ単位でＮ＋１台のディスク装置に分散させることによって、パリティディスクへのアクセス集中を防止するように構成されている。
【００２９】
主メモリ１３のドライバ作業領域１７は、ＲＡＩＤ高速化ドライバの実現のために使用される作業領域である。ＲＡＩＤ高速化ドライバは、ディスクアレイ１８に対する書き込み性能を向上させるために用いられる。本実施形態においては、ＯＳファイルシステム５０には改良を加えず、ＯＳに組み込んで用いられるドライバプログラムとドライバ作業領域１７とによってＲＡＩＤ高速化ドライバが実現されている。ここで、図２を参照して、ＲＡＩＤ高速化ドライバによるディスクアレイ１８の書き込み制御の原理について説明する。
【００３０】
ＯＳファイルシステム５０と物理ディスク（ディスクアレイ１８）の間に位置するフィルタドライバとしてＲＡＩＤ高速化ドライバ１００が設けられる。ＲＡＩＤ高速化ドライバ１００は、ファイルシステム５０からのライトリクエストに対して、▲１▼アドレス変換を行い、書き込み先物理アドレス（ＲＡＩＤ上の論理パーティション内アドレス）を書き込み対象データストライプの次の空き領域とし、実際に書き込む機能、▲２▼ライトリクエストの書き込み先アドレスをＡＭＴキャッシュ１７２に登録する機能を有する。
【００３１】
このＲＡＩＤ高速化ドライバ１００は、ＯＳファイルシステム５０からのライトリクエストに対して、そのリクエストされた論理アドレスを物理アドレスにＡＭＴキャッシュ１７２を用いて変換し、（例え、ターゲットアドレスが連続していない一連のライトリクエストに対しても）ディスクアレイ１８に形成されるデータストライプに転送された書き込みデータを書き込む。このデータストライプを構成するディスク上の連続したアドレスである連続領域は、ディスクに効率良く書き込めるアライン、及びサイズである。このアライン、サイズはディスクを直接操作するドライバやＲＡＩＤコントローラ１６に依存して決まる。特に、書き込み対象のディスクアレイ１８がＲＡＩＤ５で構成されている場合には、上記連続領域が「パリティグループ」、あるいはその整数倍である。
【００３２】
ＲＡＩＤ高速化ドライバ１００を使用した書き込み方式では、ホスト計算機（本実施形態ではＯＳファイルシステム５０）から書き込み要求された論理アドレスに従ってデータ書き込み位置を決定するのではなく、ホスト計算機から書き込み要求された順番で書き込みデータを順次蓄積することによって複数の書き込みデータブロックから構成される大きなデータブロックを構成し、その大きなデータブロックを一括してディスクアレイ１８の空き領域に上から順番に「まとめ書き」する。「まとめ書き」の単位は物理ストライプである。つまり、「まとめ書き」の度に１つの空き物理ストライプを生成し、そこに１物理ストライプ分のデータブロックがシーケンシャルに書き込まれる。これにより、ランダムなアクセスをシーケンシャルなアクセスに変換することが出来、書き込み性能を大幅に向上させることができる。しかしながら、本発明では、上記の「まとめ書き」による一括書き込みに限定されず、ＯＳファイルシステム５０からのライトリクエスト単位、又は複数のライトリクエスト単位に応じて書き込み処理を実行しても良い。
【００３３】
図２では、上記した「まとめ書き」による書き込み動作が示されている。ＯＳファイルシステム５０から送られてくる書き込みデータのブロックデータサイズが２ＫＢ、１ストライプユニットのデータサイズが６４ＫＢ、１物理ストライプ（パリティグループ）分のデータサイズが２５６ＫＢ（＝６４ＫＢ×４）の場合の例である。２ＫＢの書き込みデータブロックは、ＯＳに組み込んで用いられるＲＡＩＤ高速化ドライバ１００によって取得され、主メモリ１３のドライバ作業領域１７のライトバッファ１７１に蓄積される。
【００３４】
基本的には、２５６ＫＢ分のデータブロック（２ＫＢ×１２８個のデータブロック）がドライバ作業領域１７のライトバッファ１７１に蓄積された時点で、ＲＡＩＤ高速化ドライバ１００の制御の下、ディスクアレイ１８の１物理ストライプに対する書き込みが１度にまとめて行われる。この場合、ＲＡＩＤコントローラ１６は、２５６ＫＢ分の書き込みデータブロックのみからパリティを生成できるので、パリティ計算のために旧データを読み出す等の処理が不要となり、良く知られたＲＡＩＤ５の書き込みペナルティーを減らすことができる。
【００３５】
（第１の実施形態）
次に、図３を使ってＲＡＩＤ高速化ドライバ１００によるディスクアレイ１８への書き込み動作について説明する。この図３は、上位のファイルシステム５０から送られてきたライトリクエストＲｅｑ１，Ｒｅｑ２，Ｒｅｑ３，Ｒｅｑ４，‥‥をＲＡＩＤ高速化ドライバ１００が処理する様子を示している。
【００３６】
なお、図３では、１つのディスクに対して書き込み／参照処理をしているように示されているが、図３のディスク１８０は論理的なものであり、実際には図１又は図２に示すように複数の物理ディスク（ＤＩＳＫ０〜ＤＩＳＫ４）から構成されるＲＡＩＤ構成をとっているものとする。そして、ディスク１８０全体が１つのパーティションを構成している様子を示している。
【００３７】
図３において、ディスク１８０のパーティション内は、アドレス変換テーブル領域（以下、ＡＭＴ領域と称する）１８ａと、ストライプＩＤログ領域１８ｂ１、論理アドレスログ領域１８ｂ２から成る管理データ領域１８ｂと、データ領域１８ｃに分けて管理されている。
【００３８】
例えば、現在の書き込み対象の物理データストライプがデータ領域１８ｃの「ストライプ３４」であると想定する。ＲＡＩＤ高速化ドライバ１００は、書き込み対象データストライプ３４に対して全ての領域に書き込みデータが割り当てられた時点で、新しい空ストライプが次の書込み対象ストライプとして割り当てる。以降、ライトリクエストデータのライト処理は、新たに割り当てたストライプの領域に対して行うようになる。
【００３９】
ＲＡＩＤ高速化ドライバ１００は、ＯＳファイルシステム５０からのライトリクエストReq1,Req2,Req3,Req4,‥に対して、ライトバッファ１７１に記憶したデータをディスク１８０のデータ領域１８ｃのストライプ３４に書き込むと共に、ＡＭＴキャッシュ１７２にライトした実際の物理アドレスを登録する。また、ＯＳファイルシステム５０からのリード要求に対しては、ＡＭＴキャッシュ１７２を参照して、指定された論理アドレスに対する物理アドレスを求め、ディスク１８０からその物理アドレスをリードした結果のデータをＯＳファイルシステム５０に返す。
【００４０】
データ領域１８ｃの各データストライプの最後の１ブロックには「ＴＡＧ領域」ＴＡＧが設けられる。各ストライプへの書き込みに際して、このＴＡＧ領域に、そのデータストライプに関して、▲１▼そのデータストライプを書き込んだ時刻（あるいは書込みに関するシーケンス番号としてのタイムスタンプＴＳ）、▲２▼有効データブロックに関してデータストライプの各ブロックの論理アドレスが記録保存されている。
【００４１】
また、データストライプへの書き込みに際し、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２には、現在書き込み中のデータストライプに書き込んだデータブロックの「論理アドレス」がデータブロック毎に記録される。
【００４２】
また、管理データ領域１８ｂのストライプＩＤログ領域１８ｂ１には、書き込み対象データストライプとして選んだストライプＩＤが時系列順に記録される。この例では、ストライプＩＤ「３４」の書き込みの前に、ストライプＩＤ「３１」の書き込みが行なわれたことが分かる。
【００４３】
図３の上部には、主メモリ１３上に確保したドライバ作業領域１７が示されている。この図３では、この領域１７にライトバッファ１７１、およびＡＭＴキャッシュ１７２の２つの領域が確保されていることを示している。ＡＭＴキャッシュ１７２は、ＡＭＴ領域１８ａに記憶されるアドレス変換テーブルの一部が記憶されており、システム稼働中はこのＡＭＴキャッシュ１７２がアクセスされる。ＡＭＴキャッシュ１７２に登録されていない論理アドレスによるアクセス要求があった場合、ＡＭＴ領域１８ａのアドレス変換テーブルから該当する変換テーブルの内容が読み出され、ＡＭＴキャッシュ１７２に登録される。ＡＭＴキャッシュの内容が更新された場合、あるいはシステムがシャットダウンされる場合には、ＡＭＴキャッシュ１７２の内容はＡＭＴ領域１８ａのアドレス変換テーブルに書き戻される。
【００４４】
ライトバッファ１７１は、ＯＳファイルシステム５０からの書き込みリクエストについて、そのデータを最初にバッファリングするための領域である。１つのライトバッファは１データストライプの大きさであり、図３では図面スペースの都合上１つのライトバッファしか記載していないが、複数のライトバッファが用意される。第１の実施形態の発明では、このライトバッファ１７１は必ずしも必要なものではない。例えば、１データブロックまたは複数データブロックを記憶するバッファメモリであっても構わない。
【００４５】
ＡＭＴキャッシュ１７２は、ディスク上のＡＭＴ領域１８ａのアドレス変換テーブルをキャッシュして記憶した領域である。ＲＡＩＤ高速化ドライバ１００は、ＡＭＴキャッシュ１７２を参照、または変更する場合には、決められた固定サイズ（たとえば４ＫＢ）の単位でＡＭＴ領域１８ａからＡＭＴキャッシュ１７２に読み込んで、主メモリ１３上で参照、または変更を行う。変更を行った場合には、そのキャッシュされたＡＭＴキャッシュ１７２は元のＡＭＴ領域１８ａに書き戻される。
【００４６】
次に、ＲＡＩＤ高速化ドライバ１００によるディスク１８０のパーティションに対するデータ書き込み処理の動作を図４に示すフローチャートを用いて説明する。なお、以下の説明では、書き込み対象データストライプを「ストライプ３４」であるとして説明する。
【００４７】
図４は、ライト処理のメインルーチンの処理を示す。ＯＳファイルシステム５０からライトリクエストＲｅｑｉ（ｉ＝１，２，３，４‥）が入力され、そのライトリクエストＲｅｑｉは、論理アドレスａｄｄｒｉから始まる２ＫＢ単位のライトブロックデータＢ０〜Ｂｎからなるものとする（ステップＳ４０１）。
【００４８】
このライトリクエストReqiに対して、空き領域を有するストライプが、書込み対象ストライプとして割り当てられているか否かがチェックされ（ステップＳ４０２）、割り当てられていなければディスク上の空ストライプを１つ選択する（ステップＳ４０３）。そして、そのストライプＩＤ（この例では、ストライプ３４）をＩＤｋとして、管理データ領域１８ｂのストライプＩＤログ領域18b1に次のエントリとして書き込む（ステップＳ４０４）。ストライプＩＤログ領域18b1には、書き込み対象に選ばれたストライプのＩＤが時系列順に記録されていく。
【００４９】
次に、ＲＡＩＤ高速化ドライバ１００は、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２を割り当てる（ステップＳ４０５）。論理アドレスログ領域１８ｂ２は、ライトリクエストＲｅｑｉのデータをデータストライプ３４に書き込んだ時に、そのデータの論理アドレスを憶えておくための領域である。この論理アドレスログ領域１８ｂ２の先頭には、書き込み対象のデータストライプＩＤが記録され、以降、ストライプを構成する物理ブロックがどの論理アドレスのデータを保持しているかが記録される。なお、ステップＳ４０２で、書き込み対象データストライプ３４が既に割り当てられている場合には、ステップＳ４０３，Ｓ４０４，Ｓ４０５の処理が省略されて、ステップＳ４０６への進む。
【００５０】
次に、ＲＡＩＤ高速化ドライバ１００は、ライトリクエストＲｅｑｉによるライトデータを２ＫＢのブロック単位で書込み対象データストライプ３４の空き領域に割り当てる。これは、データストライプ３４の空き領域が無くなるまで、あるいは、ライトリクエストＲｅｑｉの全てのブロックを割り当てるまで行われる（ステップＳ４０６）。
【００５１】
次に、ＲＡＩＤ高速化ドライバ１００は、データストライプ３４に対するデータ書き込みのＩ／Ｏ要求を発行する（ステップＳ４０７）。この際、書き込みできるデータはライトバッファ１７１上で１つに纏められ、Ｉ／Ｏ要求が発行される。例えば、図３のライトリクエストＲｅｑ１は、２ＫＢのブロックデータを２個書き込むものであるが、これを１つのライトリクエストとしてＩ／Ｏ要求を発行する。これにより、ディスクの特性から効率の良い書き込みが行われる。更に、ライトデータに関する論理アドレス情報を、ステップＳ４０５で割り当てられた論理アドレスログ領域１８ｂ２に書き込むためのＩ／Ｏ要求が発行される。この例では、論理アドレスログ領域１８ｂ２の先頭にストライプＩＤ＝３４が書き込まれ、それ以降に書き込まれたデータの論理アドレスＶとして、ライトリクエストＲｅｑ１の２ブロックデータの書き込みに対応してＶ＝１００，１０２が、同様にＲｅｑ２の３ブロックデータに対応してＶ＝７６，７７，７８が、Ｒｅｑ３の１ブロックデータに対応してＶ＝６０が、Ｒｅｑ４の４ブロックデータに対応してＶ＝７９，８０，８１，８２が書き込まれる（ステップＳ４０８）。なお、上記したステップＳ４０７、４０８で発行したＩ／Ｏ要求は非同期に処理される。
【００５２】
次に、書き込み対象データストライプ３４に空き領域が有るか否かが調べられる（ステップＳ４０９）。空き領域が無い場合、つまり書き込み対象データストライプ３４の全容量分の書き込みデータが揃った場合には、ＴＡＧ情報（対象データストライプ３４に書き込んだブロックの論理ブロック番号テーブル）の書き込みＩ／Ｏ要求を発行する（ステップＳ４１０）。ＴＡＧ情報は原則として、ディスク１８０上のどこに配置しても良いが、この実施例ではデータストライプ３４の１つのブロックとして存在している。ステップＳ４１０のＴＡＧ情報の書き込み処理は非同期に行われる。そして、その書き込み対象データストライプ３４に書き込んだデータブロックのＴＡＧ情報をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュを更新する（ステップＳ４１１）。この処理についてもＡＭＴキャッシュ１７２の操作にＩ／Ｏ要求が伴う場合があり、非同期に処理が行われる。一方、ステップＳ４０９において、書き込み対象データストライプ３４に空き領域が有る場合には、上記ステップＳ４１０、Ｓ４１１の処理をせず、ステップＳ４１２に進む。
【００５３】
最後に、ＲＡＩＤ高速化ドライバ１００は、ライトリクエストＲｅｑｉに対して全てのデータブロックの書き込みＩ／Ｏ要求が発行されたか否かを判断する（ステップＳ４１２）。まだライトすべきデータが残っている場合には、ステップＳ４０２に戻り、新たなストライプを割り当てて、同様にライトリクエストを書いていく。
【００５４】
上記ステップＳ４１２で、ライトリクエストＲｅｑｉに対する全てのデータブロックの書き込みＩ／Ｏ要求が発行していた場合には、ディスクへの書き込み処理が終了する。
【００５５】
図５は、上記ステップＳ４０７、Ｓ４０８で発行したＩ／Ｏ要求の完了処理（通常は完了割り込みの処理である）の動作を示すフローチャートである。Ｉ／Ｏ完了処理１は、ステップＳ４０７に対応した完了処理であり、また、Ｉ／Ｏ完了処理２はステップＳ４０８に対応した完了処理である。
【００５６】
ＲＡＩＤ高速化ドライバ１００は、データ書き込み完了（Ｉ／Ｏ完了処理１）では、完了したデータ書き込みに対応する論理アドレスログ番号の書き込み処理が完了しているか否かをチェックし（ステップＳ５０１）、一方、論理アドレスログ書き込み完了（Ｉ／Ｏ完了処理２）では、完了した論理アドレスログの書き込みに対応するデータ書き込み処理が完了したか否かをチェックする（ステップＳ５１０）。それらの書き込みが完了していれば、元々のライトリクエストＲｅｑｉに関して、全てのデータ書き込みと、論理アドレスログの書き込みとが完了しているか否かをチェックする（ステップＳ５０２）。それらが完了していれば、ＯＳファイルシステム５０にライトリクエストＲｅｑｉに対するディスクへの書き込みが全て完了したことを通知する（ステップＳ５０３）。即ち、全ての書き込みブロックがデータストライプ３４に書き込まれ、かつ、それらのブロックの論理アドレス情報が論理アドレスログ領域１８ｂ２に書き込まれた時点で、ＲＡＩＤ高速化ドライブ１００はライトリクエストＲｅｑｉの完了通知をリクエスト発行元のＯＳファイルシステム５０に通知する。
【００５７】
図６は、図４のステップＳ４１０における、ＴＡＧ書き込みＩ／Ｏ要求の完了実行処理の動作を示すフローチャートである。ＴＡＧ書き込みＩ／Ｏ要求の完了実行処理（Ｉ／Ｏ完了処理３）では、ＴＡＧ書き込みＩ／Ｏ要求処理が終ったストライプ３４に割り当てた論理アドレスログ領域を開放して（ステップＳ６００）、ＴＡＧ情報の書き込みを終了する。
【００５８】
上記した第１の実施形態によれば、本来、ランダムライトリクエストに関して、ディスク上には物理的に離れた領域に書き込みが起こり、ディスクのシークや回転待ちによる性能低下があった。本発明によれば、不揮発性メモリの代わりに、ディスク上に設けられたＡＭＴ領域１８ａ（主メモリ上のＡＭＴキャッシュ１７２を含む）、管理データ領域１８ｂ、データ領域１８ｃを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。したがって、シーク／回転待ちが少なくなり、結果として高速な書き込み処理が実現される。ＲＡＩＤ５のディスクに対しては、パリティグループ単位での書き込みになるようにストライプ境界とサイズを合わせれば、ストライプへの書き込みが全て終った段階で、ＲＡＩＤコントローラのキャッシュメモリ上でパリティグループが揃うため、パリティ計算のためのディスクリード処理が不要となり、所謂「ＲＡＩＤ５のライトペナルティ」を無くすことが可能になり、結果として高速な書込み処理が実現される。
【００５９】
また、一連のデータ書き込み処理が完了しない状態で、不慮のシステムダウンによる処理停止が起こった場合、論理アドレスログ領域１８ｂ２に記録した論理アドレスログ情報を用いて、システムリブート後のデータ回復処理が実行できる。なお、論理アドレスログ情報は、書き込み対象データストライプ３４に書き込まれる全ての書き込みデータブロックの論理アドレスと物理アドレスの関係が、データストライプ３４のＴＡＧ情報として登録された時点で不要になる。
【００６０】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
図４に示した第１の実施形態では、論理アドレスログ領域１８ｂ２の割り当ては、ステップＳ４０３〜Ｓ４０５で空ストライプを割り当てる際に行っている。論理アドレスログ領域１８ｂ２は、図３に示すように固定的に１つ、あるいは複数用意されている。この第２の実施形態では、複数の論理アドレスログ領域１８ｂ３を用いて書き込み処理するものである。
【００６１】
先ず、図４のステップＳ４０５で行なった新しい論理アドレスログ領域を割り当てに際して、この実施形態では、複数の論理アドレスログ領域（１８ｂ２−１〜１８ｂ２−ｍ）のうち、一番最近使用されて開放された論理アドレスログ領域を選ぶようにする。
【００６２】
これを実現するために、使用した論理アドレスログ領域１８ｂ２をＬＲＵで管理する仕組みを用意する。また、論理アドレスログ領域（１８ｂ２−１〜１８ｂ２−ｍ）を示すＩＤ番号に関するスタック状のフリーリソース管理手段（図示せず）を用意する。なお、システム初期化時には、フリーリソース管理手段に全ての論理アドレスログ領域で示されるストライプＩＤが登録される。
【００６３】
図４のステップＳ４１０の処理によってＴＡＧ書き込みが完了した時点で、ＲＡＩＤ高速化ドライバ１００はそのストライプに割り当てていた論理アドレスログ領域を開放する（図６のステップＳ６００）。ここで、開放された論理アドレスログ領域（仮に１８ｂ２−１とする）を示すＩＤ番号は、フリーリソース管理手段のスタックに上から積まれる。図４のステップＳ４０５において、論理アドレスログ領域を新しく必要とする場合には、そのスタックの一番上に蓄積されたＩＤ番号が読み出され、そのアドレスに対応する論理アドレスログ領域１８ｂ２−１が確保される。即ち、一番最近開放された論理アドレスログ領域１８ｂ２−１が確保されることになる。このように管理することにより、常に「最も最近書き込み処理が行われ、そして開放された論理アドレスログ領域」が使用できるようになる。
【００６４】
一般的に、バッテリバックアップされたキャッシュを搭載したＲＡＩＤコントローラでは、繰り返し同じ領域に書込みを行うと、キャッシュに長い時間保持されるようになるために、引き続き発生するそれらの領域に対するライト処理は高速になる。この第２の実施形態では、この特性を利用することにより、上記のように論理アドレスログ領域１８ｂ２を管理して、なるべく同じ論理アドレスログ領域１８ｂ２−１を使用することにより、書き込みのオーバヘッドを少なくすることが可能となる。
【００６５】
この第２の実施形態の効果について更に解説する。
データ書き込みはパリティグループとしてのストライプ単位の連続領域への書き込みとなり効率が良いが、論理アドレスログ情報に関しては、パリティグループ単位での書き込みになるとは限らず、書き込み効率は悪い。ライトリクエストに対する完了通知は、「データの書き込み」と「論理アドレスログ情報の書き込み」の両方の完了をもって行われる。このため、論理アドレスログ情報の書き込みが遅くなると「書き込み処理全体」が遅くなってしまう。
【００６６】
一方、ディスクの読み書きデータのアドレスを管理するキャッシュメモリを有し、ライトバックキャッシュ機能を持つＲＡＩＤコントローラの場合は、同じアドレスに対するライトリクエストが続けて行われると、２回目以降のライトが早く完了することが多い。これは、ライトバックキャッシュに直前に書いたデータが記憶されており、同じアドレスへのデータは、キャッシュ上のデータの変更のみ完了するからである。したがって、実際のディスクへの書き込みを待たない。そのキャッシュ領域は、ＲＡＩＤコントローラのキャッシュ制御のポリシーにより、いつかはディスクに書き込まれ開放されるが、同じアドレスへのライトが短い間隔で定期的に続けば、恒常的にキャッシュ領域が確保されつづけ、比較的早くアクセスすることが可能になる。
【００６７】
第２の実施形態では、この特性を活かして論理アドレスログの書き込み処理を高速化する。例えば、（１）１ストライプのデータ書き込み分に相当するデータの論理アドレスログ情報をセーブするための領域（論理アドレスログ領域）を複数設ける。（２）書き込み対象データストライプを新規に割り当てる場合には、現在使っていないもので一番最近使った「論理アドレスログ領域」を１つ選び、ストライプにデータを書き込む際に、論理アドレスログ情報を書き込む領域として使用する。（３）対象データストライプに全てのデータを書き込んだ後には、それら書き込んだブロックを対象データストライプのＴＡＧ情報に登録する。全てのブロックに付いて登録が完了した時点で使用していた「論理アドレスログ領域」を解放する。
【００６８】
上記のように「論理アドレスログ領域」をＬＲＵで管理することにより、論理アドレスログ情報を書き込む領域が、ディスク上の限定された固定領域（領域が複数の場合も含む）になり、論理アドレス領域への書込みが高速になる結果、書込み処理の完了タイミングも早くなる。
【００６９】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。
図７は、第３の実施形態の動作を示すフローチャートである。
この第３の実施形態では、複数のライトリクエストを１つに纏めて書き込み処理するものである。ＲＡＩＤ高速化ドライバ１００が処理している未完了のライトリクエスト数を変数（Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ）で管理することにより実現する。Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔは初め「０」で初期化されているものとする。
【００７０】
図７において、ＯＳファイルシステム５０からのライトリクエストＲｅｑｉを受信すると（ステップＳ７０１）、ＲＡＩＤ高速化ドライバ１００はそのライトリクエストＲｅｑｉを変数としてＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔに登録する（ステップＳ７０２）。つまり、変数Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ（カウンタ値）の内容が＋１される。そして、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値がある定数「Ａ」より多いか否かがチェックされ（ステップＳ７０３）、定数「Ａ」より少ない場合には、そのライトリクエストＲｅｑｉはステップＳ７０４に進み、図４で示したライトリクエストＲｅｑｉのＩ／Ｏ要求の発行処理（図４のステップＳ４０７）が実行される。
【００７１】
一方、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔがある定数「Ａ」より大きい場合には、そのライトリクエストＲｅｑｉは一旦保留（ペンディング）され、ペンディングリクエストキューＰＬｉｓｔに入れられる（ステップＳ７０５）。ペンディングリクエストキューＰＬｉｓｔに入れられたライトリクエストＲｅｑｉ（複数登録可能）は、以下の条件が満たされた時に一まとめにされて書き込み処理が行われる。
（ペンディングされたライトリクエストのＩ／Ｏ要求発行条件）
ａ）ペンディングしているリクエストＲｅｑｉの数Ｐｃｏｕｎｔが定数「Ｂ」以上になった（ステップＳ７０７のチェック）。
ｂ）ペンディングしているリクエストＲｅｑｉのデータサイズＰｓｉｚｅの合計が定数「Ｃ」以上になった（ステップＳ７０８のチェック）。
ｃ）ペンディングしているリクエストＲｅｑｉのデータサイズＰｓｉｚｅの合計が現在の書込み対象データストライプの残りの空き領域を越えた（ステップＳ７０９のチェック）。
ｄ）タイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）が指定時間を経過して起動された（ステップＳ７１０のチェック）。
【００７２】
ここでタイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）とは、時間と関数を指定すると、指定した時間が経過した時点で指定した関数を実行してくれるＯＳ（オペレーティングシステム）のサービスで登録した関数のことである。この場合、例えば「３０ｍｓ時間後に指定する関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）を実行せよ」というようにＯＳに登録する。ステップＳ７１０でセットするタイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）の処理は図８に示している。
【００７３】
上記の条件ａ）〜ｄ）を判定するために、図７では以下の変数で管理している。
ペンディングリクエストの数 ・・・ Ｐｃｏｕｎｔ
ペンディングリクエストのデータサイズの合計 ・・・ Ｐｓｉｚｅ
【００７４】
上記した条件ａ）〜 ｄ）のいずれかが満たされた場合には（ステップＳ７０７のＹｅｓ、又はＳ７０８のＹｅｓ、又はＳ７０９のＹｅｓ、又はＳ７１０）、変数Ｐｃｏｕｎｔ、Ｐｓｉｚｅを０クリアする（ステップＳ７１１、Ｓ７１２、図８のステップＳ８０１、Ｓ８０２）。さらにタイマ関数Ｔｉｍｅｒ Ｒｏｕｔｉｎｅ（）がセットされているか否かがチェックされ（ステップＳ７１３）、タイマ関数Ｔｉｍｅｒ Ｒｏｕｔｉｎｅ（）がセットされていればそれをリセットする（ステップＳ７１４）。そして、ペンディングリストＰＬｉｓｔのライトリクエストを１つのライトリクエストＷＲｅｑ として、図４のステップＳ４０７の手順に従ってライト処理を行なう（ステップＳ７１５、図８のステップＳ８０３）。
【００７５】
なお、ここで、ペンディングリストＰＬｉｓｔにつながっているリクエストをまとめた ＷＲｅｑ の書き込み対象データストライプ（例えばストライプ３４）へのデータ書き込みは、それを構成する複数のライトリクエスト毎にはライトせず、一まとめにして１つのライトリクエストで書き込む。また、論理アドレスログ領域１８ｂ２への書き込みに関しても、ＷＲｅｑ全体に関して１回の書き込みとする。これらの完了時処理を図９に示す。
【００７６】
図９において、ＲＡＩＤ高速化ドライバ１００はライトリクエストＲｅｑｉに関して、データ書き込み完了（Ｉ／Ｏ完了処理１）では論理アドレスログ番号の書き込み処理が完了しているか否かをチェックし（ステップＳ９０１）、一方、論理アドレスログ書き込み完了（Ｉ／Ｏ完了処理２）ではデータ書き込み処理が完了したか否かをチェックする（ステップＳ９１０）。それらの書き込みが完了していれば、元々のライトリクエストＲｅｑｉに関して全てのデータ書き込みと論理アドレスログの書き込みが完了しているものとしてＯＳファイルシステム５０にＩ／Ｏ完了を通知する（ステップＳ９０２）。そして、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値から完了したライトリクエストＲｅｑｉを引いた値をＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値として更新記録して、処理を終了する（ステップＳ９０３）。
【００７７】
この第３の実施形態の具体的な動作の例について、図１０〜図１１を用いて説明する。先ず、以下の動作例では、ＲＡＩＤ高速化ドライバ１００にＯＳファイルシステム５０からライトリクエストＲｅｑｉがマルチストリームで並行して多数到来してきている状況とする。図１０（ａ）は、この内４つのライトリクエストＲｅｑ１〜Ｒｅｑ４が到来したところを示している。なお、この時点で、ＲＡＩＤ高速化ドライバ１００は既に複数のライトリクエストを処理中であり、これらリクエスト到着時には既にＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ≧Ａの条件を満たしているものとする。即ち、図７のステップＳ７０３がＹｅｓの条件で進む。
【００７８】
図１０（ａ）で、各ライトリクエストＲｅｑ１〜Ｒｅｑ４について、ライトサイズ、論理ブロック番号を示した。なお、ここではＲＡＩＤ高速化ドライバ１００のデータ管理単位は２ＫＢであるとし、ＯＳファイルシステム５０からの書き込みアドレスは、書き込み先の論理ブロック番号で示している。例えば、論理ブロック番号１００とは、論理アドレス（ＯＳファイルシステムが指定した書き込み先アドレス）で１００×２ＫＢ＝２００ＫＢのアドレスを意味する。また、ライトリクエストＲｅｑ１は書き込み先の論理アドレス番号１００に４ＫＢのデータを書き込むものであるのに対し、ＲＡＩＤ高速化ドライバ１００のデータ管理単位は２ＫＢであることから、このリクエストＲｅｑ１は論理アドレス番号Ｖとして、１００、１０１が割り当てられることを理解する。同様に、リクエストＲｅｑ２では６ＫＢであるから、論理アドレス番号Ｖ＝７６、７７、７８が割り当てられ、リクエストＲｅｑ３は２ＫＢであるから論理アドレス番号Ｖ＝６０が割り当てられ、リクエストＲｅｑ４は８ＫＢであるから、論理アドレス番号Ｖ＝７９、８０、８１、８２が割り当てられることを理解する。ここで、定数Ｂ＝４とし、ステップＳ７０７のＰｃｏｕｎｔ≧Ｂの条件が成立した場合を考える。
【００７９】
初め、ペンディングリクエストＰＬｉｓｔにライトリクエストが１つも無かった状態の場合に、ライトリクエストＲｅｑ１〜Ｒｅｑ４がこの順に到来したとする。これらのリクエストは、先ずペンディングリクエストＰＬｉｓｔに順次格納され、ライトリクエストＲｅｑ４が来た時点で図１０（ｂ）の状態に格納される。
【００８０】
この時点で、図７のステップＳ７０７の条件が成立し、ステップＳ７１１に制御が移り、ステップＳ７１５で、ペンディングリストＰＬｉｓの４つのリクエストＲｅｑ１〜Ｒｅｑ４（全２０ＫＢ）が１つのライトリクエストＷＲｅｑとして、図４で示した手順によりディスク１８０にライト処理される。この時、ライトリクエストＷＲｅｑによる２０ＫＢのデータが書き込み対象データストライプ（例えばストライプ３４）の残りの空き領域に入りきらない場合には、その空き領域に入るサイズ（例えば、１０ＫＢ）で切り、その単位で処理する。残りの１０ＫＢは、別な空き領域のストライプに、別なもう１つのライトリクエストＷＲｅｑに纏めてＩ／Ｏ要求を発行する。
【００８１】
この時のディスク１８０へのライト処理の様子を図１１に示す。ファイルシステムからのライトリクエストＲｅｑ１〜Ｒｅｑ４は、本来４つのライトリクエストであるが、書き込み先アドレスは連続した１つのデータストライプ３４であるので、まとめて１つのライトリクエストＷＲｅｑによって書き込み処理が行われる。同時に、論理アドレスログ情報も、一括ライトを発行したデータに対応した論理アドレスログ領域１８ｂ２へ論理アドレス情報Ｖ＝１００，１０１，７６，７７，・・・，８２が１つのライトＩ／Ｏ要求によって書き込まれる。
【００８２】
この結果、書き込み対象データストライプ３４へのデータライトに４つのＩ／Ｏ要求が、また論理アドレスログ領域１８ｂ２への論理アドレスログ情報の書込みに４つのＩ／Ｏ要求が必要だったところが、ペンディングリストＰＬｉｓｔに格納して書き込むことにより、２つのライトＩ／Ｏ要求で書き込み処理を行なうことが可能となり、Ｉ／Ｏ要求の発行を少なくして、まとめ書きによる高速化が達成される。なお、上記した例では定数Ｂ＝４とし、Ｐｃｏｕｎｔ≧Ｂの条件が成立した場合を考えたが、上述した他の条件ｂ），ｃ），ｄ）の各条件が成立した場合（ステップＳ７０８、Ｓ７０９、Ｓ７１０）も、全く同様である。
【００８３】
この第３の実施形態によれば、ある時点でＲＡＩＤ高速化ドライバが処理中でまだ完了を通知していない、上位から送られてきたリクエスト（具体的には、ディスク制御システムドライバに入ったリクエストで、まだ完了通知を行っていないリクエスト）の個数をカウンタで管理することにより、任意時点での「ライトリクエストの同時Ｉ／Ｏ発行数」を得ることができる。この「ライトリクエストの同時Ｉ／Ｏ発行数」が所定値Ａよりも大きな値の時には、以降のライトリクエストに関して、データ及び論理アドレスログ情報の書き込みを一定時間待つ。そして、▲１▼一定以上の個数のライトリクエストが新たに到着した。▲２▼到着したライトリクエストのライトサイズの合計が、一定サイズを越えた。▲３▼到着したライトリクエストのライトサイズの合計が、現在書込み対象になっているストライプの残り空領域のサイズを越えた。▲４▼一定時間が経過した。の場合に、それまでペンディングしていたライトリクエストのデータを１まとめにして対象のストライプに書き込む。同時に書き込むデータブロック（複数）の論理アドレスログ情報をまとめて１回の書込みとして「論理アドレスログ領域」に書き込む。
【００８４】
この結果、複数のライトリクエストが１度のデータライト処理と１度の論理アドレスログ情報の書き込み処理となる。各データリクエストの開始は遅れるが、書き込み処理回数が減り、書き込みサイズが大きくなることでディスクへのトータルとして書込みオーバヘッドが小さくなり、結果的に書き込み処理のスループット向上を実現できる。
【００８５】
（第４の実施形態）
次に、本発明の第４の実施形態について説明する。
この第４の実施形態では、論理アドレスログ領域１８ｂ２に論理アドレスログ情報のみならず、書き込みデータサイズおよびチェックサムを併せて記録するものである。図１２は、ライトリクエストＲｅｑ１のライトデータａに対して、書き込み対象データストライプ３４に対応する論理アドレスログ領域１８ｂ２に、
▲１▼論理アドレス Ｖ＝１００、１０１
▲２▼ライトサイズ Ｓｉｚｅ＝４ＫＢ
▲３▼チェックサム ＣｈｋＳｕｍ＝０ｘ１６ｆ９２ａａｂ
を書き込む様子を示している。このチェックサムＣｈｋＳｕｍは、ライトデータａを４バイト単位で加算した結果の値である。このように、ライトデータサイズおよびそのチェックサムを論理アドレスログ領域に記録することにより、障害回復を容易にする。
【００８６】
即ち、ディスク１８のデータ領域１８ｃへのデータ書き込み中にシステムの障害が発生した場合には、書き込み処理途中のストライプに関して、その論理アドレスログ領域１８ｂ２に書き込まれているチェックサム値とデータ領域１８ｃのデータから求めたチェックサム値とが一致するか否かを確認チェックする。一致した場合には、データ書き込みが完了していたと判断し、データを有効とみなし残りの処理（アドレス変換テーブルへの登録等）を行い、書き込み処理を完了させる。一致しなかった場合には、書き込みは完了しなかったとみなし、そのデータを捨てる。
【００８７】
（第５の実施形態）
次に、第５の実施形態について説明する。
第５の実施形態では、ライトデータａを書き込み対象データストライプ３４に書き込むだけでなく、論理アドレスログ領域１８ｂ２にも論理アドレスログ情報と一緒に書き込むものである。
【００８８】
図１３は、この第５の実施形態による論理アドレスログ領域１８ｂ２への書き込みデータの構成を示している。即ち、論理アドレスログ領域１８ｂ２には、
▲１▼論理アドレス Ｖ＝１００、１０１
▲２▼ライトサイズ Ｓｉｚｅ＝４ＫＢ
▲３▼チェックサム ＣｈｋＳｕｍ＝０ｘ１６ｆ９２ａａｂ
▲４▼ライトデータａ（４ＫＢ）
が書き込まれる。実際には上記した▲１▼〜▲４▼は１つのライトＩ／Ｏ要求で処理するものであり、これによりオーバヘッドを減らすことができる。
【００８９】
図１４は、この第５の実施形態によるＲＡＩＤ高速化ドライバ１００の動作手順を示すフローチャートである。ＯＳファイルシステム５０からライトリクエストＲｅｑｉ（ｉ＝１，２，３，４‥）が入力され、そのライトリクエストＲｅｑｉは、論理アドレスａｄｄｒｉから始まる２ＫＢ単位のライトブロックデータＢ０〜Ｂｎからなるものとする（ステップＳ１４０１）。
【００９０】
このライトリクエストReqiに対して、空き領域を有するデータストライプが、書込み対象ストライプとして割り当てられているか否かがチェックされ（ステップＳ１４０２）、割り当てられていなければディスク上の空ストライプを１つ選択する（ステップＳ１４０３）。そして、データストライプと同じサイズのバッファＷＢを主メモリ１３上に確保する（ステップＳ１４０４）。バッファＷＢはライトバッファ１７１に確保される。割り当てられたストライプＩＤをＩＤｋとして、管理データ領域１８ｂのストライプＩＤログ領域18b1に次のエントリとして書き込む（ステップＳ１４０５）。ストライプＩＤログ領域18b1には、書き込み対象に選ばれたストライプのＩＤが時系列順に記録（３１，３４，…）されていく。
【００９１】
次に、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２を割り当てる（ステップＳ１４０６）。書き込み対象データストライプ（例えば、ストライプ３４）中の次の空き領域に、まだライト領域を割り当てていないデータストライプＢｊのための領域を可能な限り確保する（ステップＳ１４０７）。
【００９２】
ＲＡＩＤ高速化ドライバ１００は、このステップＳ１４０７で確保したサイズのデータを主メモリ１３に用意したバッファＷＢにコピーする（ステップＳ１４０８）。バッファＷＢは、ストライプ領域に等しい大きさを持った主メモリ１３上に確保したライトバッファである。
【００９３】
次に、ステップＳ１４０９では図１３のように、▲１▼論理アドレス情報と▲２▼ライトデータを１つのライトＩ／Ｏ要求によって論理アドレスログ領域１８ｂ２に書き込む。そして、データストライプに空き領域がなく、ストライプに対する書込みデータがバッファＷＢで全て揃った場合には（ステップＳ１４１０）、バッファＷＢの内容を書き込み対象データストライプ３４に一括ライトするＩ／Ｏ要求が発行され、ディスク１８０の書き込み対象データストライプ３４に書き込まれる（ステップＳ１４１１）。また、その書き込み対象データストライプ３４に書き込んだＴＡＧ情報をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュ１７２を更新する（ステップＳ１４１２）。一方、ステップＳ１４１０において、書き込み対象データストライプに空き領域がない場合には、上記ステップＳ１４１１、Ｓ１４１２の処理をせず、ステップＳ１４１３に進む。ステップＳ１４１３では、ライトリクエストＲｅｑｉに対して全てのデータブロックの書き込みＩ／Ｏ要求が発行されたか否かが判断される。まだライトすべきデータが残っている場合には、ステップＳ１４０２に戻り、新たなストライプを割り当てて、同様にライトリクエストを書いていく。
【００９４】
なお、この実施例では、書き込み対象データストライプ３４内の１データブロックをＴＡＧ領域としている。従って、ステップＳ１４１１において、予めＴＡＧデータをバッファＷＢ上にセットした状態で、バッファＷＢの書き込みが終了すれば、ＴＡＧデータの書き込みも同時に終了する。
【００９５】
図１５は、図１４のステップＳ１４０９、およびステップＳ１４１１のＩ／Ｏ完了処理の動作を示すフローチャートである。図１５（ａ）はステップＳ１４１１の書き込み対象データストライプにおける完了処理（Ｉ／Ｏ完了処理１）であり、書き込みが完了したライトリクエストＲｅｑｉの「完了」をＯＳファイルシステム５０に通知する（ステップＳ１５０１）。一方、図１５（ｂ）はステップＳ１４０９の論理アドレスログ領域１８ｂ２への書き込み完了処理（Ｉ／Ｏ完了処理２）であり、論理アドレスログ領域１８ｂ２への書き込みが完了すると、バッファＷＢを開放して（ステップＳ１５１０）、更に論理アドレスログ領域１８ｂ２を開放して終了する（ステップＳ１５１１）。
【００９６】
この第５の実施形態と、上述の第１の実施形態を比較すると、第５の実施形態では個々のライトリクエストＲｅｑｉに対して、論理アドレスログ領域１８ｂ２に論理アドレスログ情報とライトデータａの書き込みが完了すれば、その時点でＯＳファイルシステム５０に対して完了通知することができる。つまり、ＯＳファイルシステムに対するレスポンスが早くなる。これに対し、第１の実施形態では、論理アドレスログ領域１８ｂ２への書き込みと、書き込み対象データストライプ３４への書き込みの、２つのライトＩ／Ｏ要求完了まで完了通知が待たされる。
【００９７】
一方で個々のライトデータに付いて考えると、第５の実施形態では、結果的には論理アドレスログ領域１８ｂ２と、データストライプ３４へ、２つの書き込みとなる。論理アドレスログ領域１８ｂ２は、ライトデータａを２重に書くというのは、実施形態２を用いて同じ領域への書き込みになるよう、キャッシュを有効利用したとしても、ＲＡＩＤコントローラ１６の特性によっては大きな負荷となる可能性がある。このため、第１の実施形態の方式にするか、第５の実施形態の方式にするかは、使用しているＲＡＩＤコントローラ１６の特性によって結果的に性能が良い方式を選ぶようにする。
【００９８】
（第６の実施形態）
ＲＡＩＤ高速化ドライバ１００が、書き込み処理中にシステムに障害が発生した場合には、データや論理アドレスログ情報等の書き込みが完了しない状態でシステムが立ち上がってくる場合がある。このようなときに、データ書き込みが完了していたものについては、書き込み対象データストライプに対応するＴＡＧ領域とＡＭＴキャッシュ１７２にそのブロックを登録し直すことにより、以降、そのデータへのアクセスが可能になる。ここで、データがディスク１８に正しく書き込めたか否かの判断は、論理アドレスログ情報としてセーブしたデータのチェックサム情報と、書き込み先のデータの領域から再計算したチェックサムが一致することが検出されれば、「正しいデータである」と判断出来る。その場合、論理アドレスログ領域１８ｂ２にセーブした（データのチェックサムの値を含む）値が、「本当に正しい値であるか」を保証する必要が有る。このため、例えば論理アドレスログ領域１８ｂ２の各エントリ毎に、
（ｘ）エントリ書き込み時に、特定の文字列（ｓｉｇｎａｔｕｒｅ）をエントリの領域の最初と最後に入れておき、読み出し時にチェックする。
（ｙ）エントリ全体のチェックサムを計算して記録する。
（ｚ）ターゲットのストライプＩＤを記録して、論理ストライプログ領域１８ｂ２の先頭のブロックに記録されるストライプＩＤとの一致を確認する。
等して、各エントリのデータ整合性を確認すれば良い。
【００９９】
上記した処理を、図１６のフローチャートに示す。なお、書き込み方式は第１の実施形態の方式であることを前提として説明する。
【０１００】
ステップＳ１６０１では、論理アドレスログ領域１８ｂ２を参照して使用中のものが有るか確認する。論理アドレスログ領域１８ｂ２が使用中か否かの判断は、例えば図１７に示すように、予め、論理アドレスログ領域１８ｂ２の先頭（ヘッダ部）に、使用中を示すフラグ（Ｖａｌｉｄ）を設け、論理アドレスログ領域１８ｂ２が使用中の間は、このフラグをセット（Ｖａｌｉｄ＝”１”）し、論理アドレスログ領域１８ｂ２を解放する時にリセット（Ｖａｌｉｄ＝”０”）すれば良い。図１７の例では、論理アドレスログ領域１８ｂ２が４つある例を示しており、この論理アドレスログ領域１８ｂ２の中では、使用中フラグ（Ｖａｌｉｄ＝”１”）を示している、論理アドレスログＬＡ１、ＬＡ２が使用中であると判断できる。これに従って、使用中リストＳにはＬＡ１、ＬＡ２として記録される。
【０１０１】
次に、ステップＳ１６０２では、上記のリストＳをヘッダ部のタイムスタンプＴＳの値によりソートする。このソートにより、結果的に時系列順にソートされる。図１７の例では、論理アドレスログＬＡ２のタイムスタンプＴＳ＝１１６７９が論理アドレスログＬＡ１のタイムスタンプＴＳ＝１１６８０より小さい（即ち、古い）ので、ステップＳ１６０２におけるソート結果のリストＳは、ＬＡ２、 ＬＡ１の順となる。
【０１０２】
次に、ステップＳ１６０３にて使用中の論理アドレスログ領域１８ｂ２（要素）があることを判断し、ステップＳ１６０４で、リストＳから一番古いタイムスタンプＴＳを持つ要素を選択（最初に論理アドレスログＬＡ２を選択）する。ステップＳ１６０５では、ＴＡＧイメージ用に確保した主メモリ１３の領域（ライトバッファ１７１に確保される）を初期化し、「対象データストライプの全ブロックが無効である」状態にする。そして、ステップＳ１６０６では、変数ｋ＝０に設定する。ステップＳ１６０７以降は、論理アドレスログＬＡ２内の各有効なエントリに対してデータのチェックサム値を読み出して、実際にストライプに書き込んであるデータのチェックサムと一致するか否かを確認する。有効なエントリの判断は、上述した（ｘ）〜（ｚ）のようにすれば良い。
【０１０３】
図１７の論理アドレスログＬＡ２の例では、エントリＥ０、Ｅ１、Ｅ２、・・が有効なエントリであると想定している。エントリＥ０に注目すると、論理アドレスログの先頭から２つの物理ブロックに、論理アドレスＶ＝４６３，４６４と、それぞれのデータブロックのチェックサムＣＳ（ＣｈｋＳｕｍ０）＝ＣＳ０，ＣＳ１が登録されている。そこでステップＳ１６０８では、実際にデータストライプ３４（論理アドレスログＬＡ２に対応するデータストライプ）の１番目、２番目のデータブロックを読み出して、チェックサムＣｈｋＳｕｍ１＝ＣＳ０’，ＣＳ１’を求める。
【０１０４】
ステップＳ１６０９では、チェックサムＣｈｋＳｕｍ０とＣｈｋＳｕｍ１（ＣＳ０とＣＳ０’、およびＣＳ１とＣＳ２’）を比較して等しいか否かを判断する。その比較結果が一致するブロックについては正しいデータであると判断し、ステップＳ１６１０でデータストライプ３４のＴＡＧ領域にその論理ブロック番号を登録する。図１８は、このようにして、エントリＥ０、Ｅ１までの５データブロックを処理した時点のＴＡＧ領域の状態が示されている。なお、ここではデータストライプ３４の先頭ブロックの物理ブロック番号が２０００であると仮定している。そして、ステップＳ１６１１で、変数ｋ＝ｋ＋１とし、更にステップＳ１６１２にてｋ≦Ｎ（Ｎはデータストライプを構成するデータブロック数）の比較を行なう。
【０１０５】
論理アドレスログＬＡ２の全てのエントリに付いて、ステップＳ１６０７〜Ｓ１６１２の処理を終えたら、ＴＡＧ情報が完成する。そして、ステップＳ１６１３およびＳ１６１４にて、ＴＡＧ情報を本来のアドレスに書き込み（ストライプ３４の場合、一番最後の物理ブロック）、同じ内容をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュ１７２を更新する。最後にＳ１６１５でＬＡ２の使用中フラグをリセット（ｖａｌｉｄ＝”０”）して、論理アドレスログＬＡ２の回復処理は終了する。同様の処理を論理アドレスログＬＡ１について行えば、障害発生時に書き込み途中であった論理アドレスログＬＡ１、ＬＡ２の書き込みを終了させることができる。
【０１０６】
なお、図１８のＴＡＧ領域には有効なデータに関しては、その論理アドレス値、無効なアドレスに関しては無効である旨を示す論理アドレス値を使って、ＴＡＧデータを作成しＴＡＧを書き込む。無効論理アドレス値としては、例えばそのパーティションに存在しない論理アドレス値を使用する。
【０１０７】
以上、本実施形態では、第１の実施形態の書き込み方式（データはリクエスト単位で対象ストライプに書き込む）を前提にしたが、第６の実施形態の書き込み方式（データは一旦論理アドレスログ領域に書き込み、バッファＷＢが一杯になった時点でバッファＷＢの単位で対象ストライプに書き込み）の場合でも、
（イ）ステップＳ１６０８で論理アドレスログ領域１８ｂ２の書き込みデータからＣｈｋＳｕｍ１を求める。
（ロ）ステップＳ１６０９、Ｓ１６１０の間で、書き込みデータを対象ストライプに書き込む。
という変更を行うことによりほぼ同様に処理できる。
【０１０８】
【発明の効果】
以上、発明によれば、ログ形式のデータブロック管理方式を採用したディスクシステムにおいて、ファイルシステムのライトアドレス情報をディスク上の固定領域に書き込むことによりＲＡＩＤコントローラのキャッシュを有効利用し書き込み時間を短縮することができる。アドレス変換テーブルの管理にチェックサムを導入することにより、不意のシステムダウン後の障害回復処理後等にアドレス変換テーブルの整合性を確認し信頼性を向上する。
【図面の簡単な説明】
【図１】本発明のディスク制御システムを適用した計算機システムの構成を示すブロック図。
【図２】本発明のＲＡＩＤ高速化ドライバによるディスクアレイの書き込み制御の原理を示すブロック図。
【図３】本発明の第１の実施形態における、ＲＡＩＤ高速化ドライバとディスクとの関係と、ＲＡＩＤ高速化ドライバによる書き込み制御を示すブロック図。
【図４】本発明の第１の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図５】本発明の第１の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図６】本発明の第１の実施形態における、Ｉ／Ｏ完了処理３の手順を示すフローチャート。
【図７】本発明の第３の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図８】本発明の第３の実施形態における、タイマ関数のセット処理の手順を示すフローチャート。
【図９】本発明の第３の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図１０】本発明の第３の実施形態における、ライトリクエストＲｅｑｉの構成、およびペンディングリストへの格納状況を示す図。
【図１１】本発明の第３の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１２】本発明の第４の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１３】本発明の第５の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１４】本発明の第５の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図１５】本発明の第５の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図１６】本発明の第６の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図１７】本発明の第６の実施形態における、論理アドレスログＬＡ０〜ＬＡ３の構成例を示す図。
【図１８】本発明の第６の実施形態における、データストライプのＴＡＧ情報の書き込み状態を示す図。
【符号の説明】
１…プロセッサバス
２…ＰＣＩバス
１１…ＣＰＵ＃１、＃２、＃３
１２…ブリッジ
１３…主メモリ
１６…ＲＡＩＤコントローラ
１７…ドライバ作業領域
１７１…ライトバッファ（ログメモリ）
１７２…アドレス変換テーブルＡＭＴ（キャッシュ）
１７３…ストライプ管理テーブル
１８…ディスクアレイ
１８ａ…ＡＭＴ領域
１８ｂ…管理データ領域
１８ｂ１…ストライプＩＤログ領域
１８ｂ２…論理アドレスログ領域
１８ｃ…データ領域
５０…ＯＳファイルシステム
１００…ＲＡＩＤ高速化ドライバ
【発明の属する技術分野】
本発明は、ディスク制御システムおよびディスク制御方法に関し、特に、ＲＡＩＤ制御装置に用いられていた書き込みバッファやアドレス変換テーブルなどを構成する専用の不揮発性メモリを使用しないで、主メモリとディスク装置だけを用いて、ディスク上のストライプに連続的にライトリクエストのデータを書き込むディスク制御システムおよびディスク制御方法に関するものである。
【０００２】
【従来の技術】
ＲＡＩＤ構成のディスク制御システムのライト方式は、例えば特開平６−２１４７２０号公報や、特開平１１−５３２３５号公報に示すように、ランダムライトを１つの連続した領域としての物理ストライプにまとめて書き込む方式が提案されている。しかしながら、従来技術では、書き込むデータを一度不揮発性メモリ（以下、ＮｖＲＡＭと称する）又は揮発性メモリに書き込み、１ストライプ分の書込みデータが揃った時点で、ディスク装置上の物理ストライプに書込みを行っていた。また、上位ファイルシステムからの論理アドレスをディスク上の物理アドレスに変換したアドレス変換テーブルを上記ＮｖＲＡＭに記憶させていた。
【０００３】
この様に、一度、ＮｖＲＡＭにデータを書き込むことにより、ディスク装置上に書き込む前にシステムが異常停止したとしても、システムリブート後にＮｖＲＡＭを参照し、ＮｖＲＡＭ上の書きかけのデータを正しくディスク装置に書き込むことにより、書き込みを完了させることができる（書き込みデータを失わない）効果が有る。
【０００４】
即ち、ＮｖＲＡＭへのデータ書き込みが終れば、そのライトデータが失われることはない。このため、従来のディスク制御システムでは、書き込みデータをＮｖＲＡＭに書き込んだ時点で、そのライトリクエストに対して「完了」をホストに通知していた。
【０００５】
【発明が解決しようとする課題】
しかしながら、ＮｖＲＡＭはシステムに装着するＩ／Ｏカード（ハードウェア）で提供する必要が有り、その分コストがかかるという問題があり、また、ホスト計算機との相性の問題、互換性、保守等の手間もかかる等の問題がある。
【０００６】
本発明では、ＮｖＲＡＭを使わずに、主メモリとディスク装置だけを用いて、ディスク上のストライプに連続的にライトリクエストのデータを書き込むディスク制御システムおよびディスク制御方法を提供することを目的とする。また、ＮｖＲＡＭを使用せずとも異常停止時にデータを損失することが無く、システムの性能向上を実現させるものである。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられた管理データ領域に、前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【０００８】
本発明によれば、不揮発性メモリに代わりに、ディスク上に設けられた管理データ領域１８ｂ、データ領域１８ｃなどを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。したがって、シーク／回転待ちが少なくなり、不揮発性メモリを使用しなくても高速な書き込み処理が実現される。
【０００９】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、主メモリ上に設けられたライトバッファに、複数のライトリクエストに対応する複数のブロックデータを書き込む手段と、前記複数のライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に、前記ライトバッファに記憶した複数のブロックデータを一括ライトするデータ書き込み手段と、前記複数のブロックデータに対応する前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として、前記複数のディスク上に設けられた管理データ領域に一括ライトするログ書き込み手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに完了を通知する手段とを具備することを特徴とする。
【００１０】
本発明によれば、不揮発性メモリに代わりに、ディスク上に設けられた管理データ領域１８ｂ、データ領域１８ｃなどを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。また、複数のライトリクエストが１度のデータライト処理と１度の論理アドレスログ情報の書き込みとして処理することができるため、書き込み処理回数が減り、書き込みサイズが大きくなることでディスクへのトータルとして書き込みオーバヘッドが小さくなり、結果的に書き込み処理のスループットが向上する。
【００１１】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、および書き込みデータサイズ、および書き込みデータのチェックサムを論理アドレスログ情報として書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【００１２】
本発明によれば、ディスクのデータ領域へのデータ書き込み中にシステムの障害が発生した場合には、書き込み処理途中のストライプに関して、その論理アドレスログ領域に書き込まれているチェックサム値とデータ領域のデータから求めたチェックサム値とが一致するか否かを確認チェックすることにより、一致している場合には、データ書き込みが完了していたと判断し、データを有効とみなし残りの処理（アドレス変換テーブルへの登録等）を行ない、効率的な障害回復処理が実行できる。
【００１３】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、書き込みデータサイズ、書き込みデータのチェックサム、および少なくとも１データブロックを論理アドレスログ情報として書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、前記上位ファイルシステムからのライトリクエストに対して、前記論理アドレスログ領域への前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とする。
【００１４】
本発明によれば、個々のライトリクエストに対して、論理アドレスログ領域に論理アドレスログ情報とライトデータａの書き込みが完了すれば、その時点でＯＳファイルシステムに対して完了通知することができる。つまり、ＯＳファイルシステムに対するレスポンスが早くなる。
【００１５】
また、本発明のディスク制御システムは、論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域のヘッダ部に有効／無効を示すフラグ、ストライプＩＤ番号、および最終データの書き込みタイムスタンプを記録し、前記論理アドレスログ領域のエントリ部に書き込みリクエストによって処理される１つ又は複数のブロックデータのタイムスタンプ、１つ又は複数の論理アドレス、および１つ又は複数のチェックサムを論理アドレスログ情報として書き込む手段と、前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その前記論理アドレスログ領域に書き込まれているチェックサム値が前記データ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし、そのデータを捨てることを特徴とする。
【００１６】
本発明によれば、書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その論理アドレスログ領域に書き込まれているチェックサム値がデータ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし捨てることにより、障害回復処理を効率よく実行することが出来る。
【００１７】
【発明の実施の形態】
先ず、本発明で用いられる各種の用語について説明する。
（データストライプ）
ディスク制御システムが「まとめ書き」（又は「一括書き」とも言われる）するデータの単位を意味する。ディスクのパーティション上で、一続きの領域となっており、ＲＡＩＤコントローラが管理するストライプサイズの整数倍のサイズである。ＲＡＩＤ５に対しては、このサイズをパリティグループにする事により、いわゆる「ＲＡＩＤ５のライトペナルティ」を改善する事ができ、大幅な性能向上を実現できる。ストライプは複数のデータブロックから構成される。
【００１８】
（ストライプ番号）
パーティション上に並んでいる物理ストライプの通し番号を意味する。
【００１９】
（論理ブロック番号＝論理アドレス番号）
「論理ブロック番号」とは、上位ファイルシステムから見た時のディスクパーティション上のデータブロック番号である。ディスク制御システム方式では、上位ファイルシステムがアクセスを要求する時のブロック番号は、論理ブロック番号であり、仮想的なブロック番号である。この論理ブロック番号は、ディスク制御システムが管理する「アドレス変換テーブル」によって物理ブロック番号（物理パーティション上の物理的なブロック番号）と対応づけられる。（物理ブロック番号）×（ブロックサイズ［バイト］）よりパーティション上でのバイトオフセット値（アドレス）が求まる。
【００２０】
（アドレス変換テーブル：ＡＭＴ（Ａｄｄｒｅｓｓ Ｍａｐｐｉｎｇ Ｔａｂｌｅ））
ディスク制御システム方式では、上位ファイルシステムがアクセスを要求する時のブロック番号は、論理ブロック番号であり、仮想的なブロック番号である。この論理ブロック番号はディスク制御システムが管理する「アドレス変換テーブル」によって物理ブロック番号（物理パーティション上の物理的なブロック番号）と対応づけられる。本発明の実施形態では、アドレス変換テーブルは、対象パーティション上に有り、データ部と別の領域が割り当てられる。アドレス変換テーブルは、論理ブロック番号に対する物理ブロック番号が登録されたれたテーブルである。新たにデータブロックを書き込む時には、相当する論理ブロック番号のエントリに、そのブロックを書き込む物理ブロック番号（＝ディスク上のアドレス）を登録する。また、データブロックを参照する際には、その論理アドレスをインデックスとするエントリの値を求め、その値をディスク上の物理ブロック番号として実際のアドレスを求め参照する。
【００２１】
以下、図面を参照して本発明の実施形態について説明する。
図１には、本発明の一実施形態に係るディスク制御システムを適用した計算機システムの構成が示されている。この計算機システムは、例えばサーバ（ＰＣサーバ）として利用されるものであり、複数のＣＰＵ（＃１、＃２、＃Ｎ）１１を搭載することが出来る。これら各ＣＰＵ１１は図示のようにプロセッサバス１を介してブリッジ１２に接続されている。ブリッジ１２はプロセッサバス１とＰＣＩバス２を双方向で接続するためのブリッジＬＳＩであり、ここには主メモリ１３を制御するためのメモリコントローラも内蔵されている。主メモリ１３には、オペレーティングシステム（ＯＳ）、実行対象のアプリケーションプログラム、およびドライバなどがロードされている。また、本発明では、主メモリ１３のドライバ作業領域１７に、ライトバッファ（まとめ書きバッファ）１７１、アドレス変換テーブル（以下、ＡＭＴキャッシュと称する）１７２、ストライプ管理テーブル１７３が設けられている。
【００２２】
ライトバッファ１７１は、書き込みデータブロックを蓄積するためのデータバッファであり、このライトバッファ１７１に例えば１物理ストライプ分の書き込みデータブロックが蓄積された時点でディスクアレイ１８への一括書き込みが開始されるが、本発明においてはそれに限定されるものではない。まとめ書きを行なう場合、物理ストライプは「まとめ書き」の単位であり、ディスクアレイ１８の全記憶領域に形成されたパーティション上で一続きの連続した領域から構成される。各物理ストライプは、ＲＡＩＤコントローラ１６が管理するストライプユニットの整数倍のサイズである。
【００２３】
ＡＭＴキャッシュ１７２は、論理アドレス空間を構成する複数の論理ブロック番号それぞれと、それら論理ブロック番号で指定されるデータブロックが存在するディスクアレイ１８上の物理位置を示す物理ブロック番号との対応関係を示すアドレス変換情報を記憶する。ＯＳファイルシステムがアクセスを要求するときのブロック番号は論理ブロック番号であり、これは仮想的な論理アドレスである。この論理ブロック番号はＡＭＴキャッシュ１７２によって物理ブロック番号（ディスクパーティション上の物理的なブロック番号）と対応づけられる。また、物理ブロック番号×ブロックサイズ（バイト）によって、ディスクパーティションの先頭位置からのバイトオフセット値が求められる。
【００２４】
また、ＡＭＴキャッシュ１７２は、論理ブロック番号それぞれに対応する複数のエントリを有している。新たにデータブロックを書き込むときには、書き込み要求された論理ブロック番号に対応するエントリには、そのデータブロックの実際に書き込まれる物理ブロック番号（物理アドレス）が登録される。データブロックの読み出し時には、読み出し要求された論理ブロック番号に対応するエントリから物理ブロック番号が調べられ、その物理ブロック番号（物理ブロック番号×ブロックサイズ）で指定されるディスクパーティション上の物理位置からデータブロックが読み出される。
【００２５】
ストライプ管理テーブル１７３は、各論理ストライプに関する情報を管理するためのものであり、それら各論理ストライプの情報はデータ再配置のための処理などに利用される。
【００２６】
ＰＣＩバス２には、ＲＡＩＤコントローラ１６が接続されている。ＲＡＩＤコントローラ１６によって制御される複数のディスク装置で構成されるディスクアレイ１８は、各種ユーザデータの記録等に用いられる。
【００２７】
ディスクアレイ１８は、ＲＡＩＤコントローラ１６の制御により、例えばＲＡＩＤ５構成のディスクアレイとして機能する。この場合、ディスクアレイ１８は、データ記憶用のＮ台のディスク装置にパリティ記憶用のディスク装置を１台付加したＮ＋１台（ここでは、ＤＩＳＫ０〜ＤＩＳＫ４の５台）のディスク装置から構成される。これらＮ＋１台のディスク装置はグループ化され、単一の論理ディスクドライブとして使用される。
【００２８】
グループ化されたディスク装置には、図示のように、データ（ＤＡＴＡ）とそのパリティ（ＰＡＲＩＴＹ）とから構成される物理ストライプ（パリティグループ）が割り当てられ、かつ、パリティ位置は物理ストライプ毎にＮ＋１台のディスク装置間で順に移動される。例えば、物理ストライプＳ０では、ＤＩＳＫ０〜ＤＩＳＫ３それぞれの同一位置に割り当てられたストライプ上のデータ（ＤＡＴＡ）群のパリティ（ＰＡＲＩＴＹ）は、ＤＩＳＫ４の対応するストライプ上に記録される。また、物理ストライプＳ１においては、そのストライプＳ１のデータに対応するパリティ（ＰＡＲＩＴＹ）は、ＤＩＳＫ３の対応するストライプ上に記録される。このようにパリティを物理ストライプ単位でＮ＋１台のディスク装置に分散させることによって、パリティディスクへのアクセス集中を防止するように構成されている。
【００２９】
主メモリ１３のドライバ作業領域１７は、ＲＡＩＤ高速化ドライバの実現のために使用される作業領域である。ＲＡＩＤ高速化ドライバは、ディスクアレイ１８に対する書き込み性能を向上させるために用いられる。本実施形態においては、ＯＳファイルシステム５０には改良を加えず、ＯＳに組み込んで用いられるドライバプログラムとドライバ作業領域１７とによってＲＡＩＤ高速化ドライバが実現されている。ここで、図２を参照して、ＲＡＩＤ高速化ドライバによるディスクアレイ１８の書き込み制御の原理について説明する。
【００３０】
ＯＳファイルシステム５０と物理ディスク（ディスクアレイ１８）の間に位置するフィルタドライバとしてＲＡＩＤ高速化ドライバ１００が設けられる。ＲＡＩＤ高速化ドライバ１００は、ファイルシステム５０からのライトリクエストに対して、▲１▼アドレス変換を行い、書き込み先物理アドレス（ＲＡＩＤ上の論理パーティション内アドレス）を書き込み対象データストライプの次の空き領域とし、実際に書き込む機能、▲２▼ライトリクエストの書き込み先アドレスをＡＭＴキャッシュ１７２に登録する機能を有する。
【００３１】
このＲＡＩＤ高速化ドライバ１００は、ＯＳファイルシステム５０からのライトリクエストに対して、そのリクエストされた論理アドレスを物理アドレスにＡＭＴキャッシュ１７２を用いて変換し、（例え、ターゲットアドレスが連続していない一連のライトリクエストに対しても）ディスクアレイ１８に形成されるデータストライプに転送された書き込みデータを書き込む。このデータストライプを構成するディスク上の連続したアドレスである連続領域は、ディスクに効率良く書き込めるアライン、及びサイズである。このアライン、サイズはディスクを直接操作するドライバやＲＡＩＤコントローラ１６に依存して決まる。特に、書き込み対象のディスクアレイ１８がＲＡＩＤ５で構成されている場合には、上記連続領域が「パリティグループ」、あるいはその整数倍である。
【００３２】
ＲＡＩＤ高速化ドライバ１００を使用した書き込み方式では、ホスト計算機（本実施形態ではＯＳファイルシステム５０）から書き込み要求された論理アドレスに従ってデータ書き込み位置を決定するのではなく、ホスト計算機から書き込み要求された順番で書き込みデータを順次蓄積することによって複数の書き込みデータブロックから構成される大きなデータブロックを構成し、その大きなデータブロックを一括してディスクアレイ１８の空き領域に上から順番に「まとめ書き」する。「まとめ書き」の単位は物理ストライプである。つまり、「まとめ書き」の度に１つの空き物理ストライプを生成し、そこに１物理ストライプ分のデータブロックがシーケンシャルに書き込まれる。これにより、ランダムなアクセスをシーケンシャルなアクセスに変換することが出来、書き込み性能を大幅に向上させることができる。しかしながら、本発明では、上記の「まとめ書き」による一括書き込みに限定されず、ＯＳファイルシステム５０からのライトリクエスト単位、又は複数のライトリクエスト単位に応じて書き込み処理を実行しても良い。
【００３３】
図２では、上記した「まとめ書き」による書き込み動作が示されている。ＯＳファイルシステム５０から送られてくる書き込みデータのブロックデータサイズが２ＫＢ、１ストライプユニットのデータサイズが６４ＫＢ、１物理ストライプ（パリティグループ）分のデータサイズが２５６ＫＢ（＝６４ＫＢ×４）の場合の例である。２ＫＢの書き込みデータブロックは、ＯＳに組み込んで用いられるＲＡＩＤ高速化ドライバ１００によって取得され、主メモリ１３のドライバ作業領域１７のライトバッファ１７１に蓄積される。
【００３４】
基本的には、２５６ＫＢ分のデータブロック（２ＫＢ×１２８個のデータブロック）がドライバ作業領域１７のライトバッファ１７１に蓄積された時点で、ＲＡＩＤ高速化ドライバ１００の制御の下、ディスクアレイ１８の１物理ストライプに対する書き込みが１度にまとめて行われる。この場合、ＲＡＩＤコントローラ１６は、２５６ＫＢ分の書き込みデータブロックのみからパリティを生成できるので、パリティ計算のために旧データを読み出す等の処理が不要となり、良く知られたＲＡＩＤ５の書き込みペナルティーを減らすことができる。
【００３５】
（第１の実施形態）
次に、図３を使ってＲＡＩＤ高速化ドライバ１００によるディスクアレイ１８への書き込み動作について説明する。この図３は、上位のファイルシステム５０から送られてきたライトリクエストＲｅｑ１，Ｒｅｑ２，Ｒｅｑ３，Ｒｅｑ４，‥‥をＲＡＩＤ高速化ドライバ１００が処理する様子を示している。
【００３６】
なお、図３では、１つのディスクに対して書き込み／参照処理をしているように示されているが、図３のディスク１８０は論理的なものであり、実際には図１又は図２に示すように複数の物理ディスク（ＤＩＳＫ０〜ＤＩＳＫ４）から構成されるＲＡＩＤ構成をとっているものとする。そして、ディスク１８０全体が１つのパーティションを構成している様子を示している。
【００３７】
図３において、ディスク１８０のパーティション内は、アドレス変換テーブル領域（以下、ＡＭＴ領域と称する）１８ａと、ストライプＩＤログ領域１８ｂ１、論理アドレスログ領域１８ｂ２から成る管理データ領域１８ｂと、データ領域１８ｃに分けて管理されている。
【００３８】
例えば、現在の書き込み対象の物理データストライプがデータ領域１８ｃの「ストライプ３４」であると想定する。ＲＡＩＤ高速化ドライバ１００は、書き込み対象データストライプ３４に対して全ての領域に書き込みデータが割り当てられた時点で、新しい空ストライプが次の書込み対象ストライプとして割り当てる。以降、ライトリクエストデータのライト処理は、新たに割り当てたストライプの領域に対して行うようになる。
【００３９】
ＲＡＩＤ高速化ドライバ１００は、ＯＳファイルシステム５０からのライトリクエストReq1,Req2,Req3,Req4,‥に対して、ライトバッファ１７１に記憶したデータをディスク１８０のデータ領域１８ｃのストライプ３４に書き込むと共に、ＡＭＴキャッシュ１７２にライトした実際の物理アドレスを登録する。また、ＯＳファイルシステム５０からのリード要求に対しては、ＡＭＴキャッシュ１７２を参照して、指定された論理アドレスに対する物理アドレスを求め、ディスク１８０からその物理アドレスをリードした結果のデータをＯＳファイルシステム５０に返す。
【００４０】
データ領域１８ｃの各データストライプの最後の１ブロックには「ＴＡＧ領域」ＴＡＧが設けられる。各ストライプへの書き込みに際して、このＴＡＧ領域に、そのデータストライプに関して、▲１▼そのデータストライプを書き込んだ時刻（あるいは書込みに関するシーケンス番号としてのタイムスタンプＴＳ）、▲２▼有効データブロックに関してデータストライプの各ブロックの論理アドレスが記録保存されている。
【００４１】
また、データストライプへの書き込みに際し、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２には、現在書き込み中のデータストライプに書き込んだデータブロックの「論理アドレス」がデータブロック毎に記録される。
【００４２】
また、管理データ領域１８ｂのストライプＩＤログ領域１８ｂ１には、書き込み対象データストライプとして選んだストライプＩＤが時系列順に記録される。この例では、ストライプＩＤ「３４」の書き込みの前に、ストライプＩＤ「３１」の書き込みが行なわれたことが分かる。
【００４３】
図３の上部には、主メモリ１３上に確保したドライバ作業領域１７が示されている。この図３では、この領域１７にライトバッファ１７１、およびＡＭＴキャッシュ１７２の２つの領域が確保されていることを示している。ＡＭＴキャッシュ１７２は、ＡＭＴ領域１８ａに記憶されるアドレス変換テーブルの一部が記憶されており、システム稼働中はこのＡＭＴキャッシュ１７２がアクセスされる。ＡＭＴキャッシュ１７２に登録されていない論理アドレスによるアクセス要求があった場合、ＡＭＴ領域１８ａのアドレス変換テーブルから該当する変換テーブルの内容が読み出され、ＡＭＴキャッシュ１７２に登録される。ＡＭＴキャッシュの内容が更新された場合、あるいはシステムがシャットダウンされる場合には、ＡＭＴキャッシュ１７２の内容はＡＭＴ領域１８ａのアドレス変換テーブルに書き戻される。
【００４４】
ライトバッファ１７１は、ＯＳファイルシステム５０からの書き込みリクエストについて、そのデータを最初にバッファリングするための領域である。１つのライトバッファは１データストライプの大きさであり、図３では図面スペースの都合上１つのライトバッファしか記載していないが、複数のライトバッファが用意される。第１の実施形態の発明では、このライトバッファ１７１は必ずしも必要なものではない。例えば、１データブロックまたは複数データブロックを記憶するバッファメモリであっても構わない。
【００４５】
ＡＭＴキャッシュ１７２は、ディスク上のＡＭＴ領域１８ａのアドレス変換テーブルをキャッシュして記憶した領域である。ＲＡＩＤ高速化ドライバ１００は、ＡＭＴキャッシュ１７２を参照、または変更する場合には、決められた固定サイズ（たとえば４ＫＢ）の単位でＡＭＴ領域１８ａからＡＭＴキャッシュ１７２に読み込んで、主メモリ１３上で参照、または変更を行う。変更を行った場合には、そのキャッシュされたＡＭＴキャッシュ１７２は元のＡＭＴ領域１８ａに書き戻される。
【００４６】
次に、ＲＡＩＤ高速化ドライバ１００によるディスク１８０のパーティションに対するデータ書き込み処理の動作を図４に示すフローチャートを用いて説明する。なお、以下の説明では、書き込み対象データストライプを「ストライプ３４」であるとして説明する。
【００４７】
図４は、ライト処理のメインルーチンの処理を示す。ＯＳファイルシステム５０からライトリクエストＲｅｑｉ（ｉ＝１，２，３，４‥）が入力され、そのライトリクエストＲｅｑｉは、論理アドレスａｄｄｒｉから始まる２ＫＢ単位のライトブロックデータＢ０〜Ｂｎからなるものとする（ステップＳ４０１）。
【００４８】
このライトリクエストReqiに対して、空き領域を有するストライプが、書込み対象ストライプとして割り当てられているか否かがチェックされ（ステップＳ４０２）、割り当てられていなければディスク上の空ストライプを１つ選択する（ステップＳ４０３）。そして、そのストライプＩＤ（この例では、ストライプ３４）をＩＤｋとして、管理データ領域１８ｂのストライプＩＤログ領域18b1に次のエントリとして書き込む（ステップＳ４０４）。ストライプＩＤログ領域18b1には、書き込み対象に選ばれたストライプのＩＤが時系列順に記録されていく。
【００４９】
次に、ＲＡＩＤ高速化ドライバ１００は、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２を割り当てる（ステップＳ４０５）。論理アドレスログ領域１８ｂ２は、ライトリクエストＲｅｑｉのデータをデータストライプ３４に書き込んだ時に、そのデータの論理アドレスを憶えておくための領域である。この論理アドレスログ領域１８ｂ２の先頭には、書き込み対象のデータストライプＩＤが記録され、以降、ストライプを構成する物理ブロックがどの論理アドレスのデータを保持しているかが記録される。なお、ステップＳ４０２で、書き込み対象データストライプ３４が既に割り当てられている場合には、ステップＳ４０３，Ｓ４０４，Ｓ４０５の処理が省略されて、ステップＳ４０６への進む。
【００５０】
次に、ＲＡＩＤ高速化ドライバ１００は、ライトリクエストＲｅｑｉによるライトデータを２ＫＢのブロック単位で書込み対象データストライプ３４の空き領域に割り当てる。これは、データストライプ３４の空き領域が無くなるまで、あるいは、ライトリクエストＲｅｑｉの全てのブロックを割り当てるまで行われる（ステップＳ４０６）。
【００５１】
次に、ＲＡＩＤ高速化ドライバ１００は、データストライプ３４に対するデータ書き込みのＩ／Ｏ要求を発行する（ステップＳ４０７）。この際、書き込みできるデータはライトバッファ１７１上で１つに纏められ、Ｉ／Ｏ要求が発行される。例えば、図３のライトリクエストＲｅｑ１は、２ＫＢのブロックデータを２個書き込むものであるが、これを１つのライトリクエストとしてＩ／Ｏ要求を発行する。これにより、ディスクの特性から効率の良い書き込みが行われる。更に、ライトデータに関する論理アドレス情報を、ステップＳ４０５で割り当てられた論理アドレスログ領域１８ｂ２に書き込むためのＩ／Ｏ要求が発行される。この例では、論理アドレスログ領域１８ｂ２の先頭にストライプＩＤ＝３４が書き込まれ、それ以降に書き込まれたデータの論理アドレスＶとして、ライトリクエストＲｅｑ１の２ブロックデータの書き込みに対応してＶ＝１００，１０２が、同様にＲｅｑ２の３ブロックデータに対応してＶ＝７６，７７，７８が、Ｒｅｑ３の１ブロックデータに対応してＶ＝６０が、Ｒｅｑ４の４ブロックデータに対応してＶ＝７９，８０，８１，８２が書き込まれる（ステップＳ４０８）。なお、上記したステップＳ４０７、４０８で発行したＩ／Ｏ要求は非同期に処理される。
【００５２】
次に、書き込み対象データストライプ３４に空き領域が有るか否かが調べられる（ステップＳ４０９）。空き領域が無い場合、つまり書き込み対象データストライプ３４の全容量分の書き込みデータが揃った場合には、ＴＡＧ情報（対象データストライプ３４に書き込んだブロックの論理ブロック番号テーブル）の書き込みＩ／Ｏ要求を発行する（ステップＳ４１０）。ＴＡＧ情報は原則として、ディスク１８０上のどこに配置しても良いが、この実施例ではデータストライプ３４の１つのブロックとして存在している。ステップＳ４１０のＴＡＧ情報の書き込み処理は非同期に行われる。そして、その書き込み対象データストライプ３４に書き込んだデータブロックのＴＡＧ情報をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュを更新する（ステップＳ４１１）。この処理についてもＡＭＴキャッシュ１７２の操作にＩ／Ｏ要求が伴う場合があり、非同期に処理が行われる。一方、ステップＳ４０９において、書き込み対象データストライプ３４に空き領域が有る場合には、上記ステップＳ４１０、Ｓ４１１の処理をせず、ステップＳ４１２に進む。
【００５３】
最後に、ＲＡＩＤ高速化ドライバ１００は、ライトリクエストＲｅｑｉに対して全てのデータブロックの書き込みＩ／Ｏ要求が発行されたか否かを判断する（ステップＳ４１２）。まだライトすべきデータが残っている場合には、ステップＳ４０２に戻り、新たなストライプを割り当てて、同様にライトリクエストを書いていく。
【００５４】
上記ステップＳ４１２で、ライトリクエストＲｅｑｉに対する全てのデータブロックの書き込みＩ／Ｏ要求が発行していた場合には、ディスクへの書き込み処理が終了する。
【００５５】
図５は、上記ステップＳ４０７、Ｓ４０８で発行したＩ／Ｏ要求の完了処理（通常は完了割り込みの処理である）の動作を示すフローチャートである。Ｉ／Ｏ完了処理１は、ステップＳ４０７に対応した完了処理であり、また、Ｉ／Ｏ完了処理２はステップＳ４０８に対応した完了処理である。
【００５６】
ＲＡＩＤ高速化ドライバ１００は、データ書き込み完了（Ｉ／Ｏ完了処理１）では、完了したデータ書き込みに対応する論理アドレスログ番号の書き込み処理が完了しているか否かをチェックし（ステップＳ５０１）、一方、論理アドレスログ書き込み完了（Ｉ／Ｏ完了処理２）では、完了した論理アドレスログの書き込みに対応するデータ書き込み処理が完了したか否かをチェックする（ステップＳ５１０）。それらの書き込みが完了していれば、元々のライトリクエストＲｅｑｉに関して、全てのデータ書き込みと、論理アドレスログの書き込みとが完了しているか否かをチェックする（ステップＳ５０２）。それらが完了していれば、ＯＳファイルシステム５０にライトリクエストＲｅｑｉに対するディスクへの書き込みが全て完了したことを通知する（ステップＳ５０３）。即ち、全ての書き込みブロックがデータストライプ３４に書き込まれ、かつ、それらのブロックの論理アドレス情報が論理アドレスログ領域１８ｂ２に書き込まれた時点で、ＲＡＩＤ高速化ドライブ１００はライトリクエストＲｅｑｉの完了通知をリクエスト発行元のＯＳファイルシステム５０に通知する。
【００５７】
図６は、図４のステップＳ４１０における、ＴＡＧ書き込みＩ／Ｏ要求の完了実行処理の動作を示すフローチャートである。ＴＡＧ書き込みＩ／Ｏ要求の完了実行処理（Ｉ／Ｏ完了処理３）では、ＴＡＧ書き込みＩ／Ｏ要求処理が終ったストライプ３４に割り当てた論理アドレスログ領域を開放して（ステップＳ６００）、ＴＡＧ情報の書き込みを終了する。
【００５８】
上記した第１の実施形態によれば、本来、ランダムライトリクエストに関して、ディスク上には物理的に離れた領域に書き込みが起こり、ディスクのシークや回転待ちによる性能低下があった。本発明によれば、不揮発性メモリの代わりに、ディスク上に設けられたＡＭＴ領域１８ａ（主メモリ上のＡＭＴキャッシュ１７２を含む）、管理データ領域１８ｂ、データ領域１８ｃを用いることにより、ランダムライトが物理的に連続した領域への書き込みとして実行することが出来る。したがって、シーク／回転待ちが少なくなり、結果として高速な書き込み処理が実現される。ＲＡＩＤ５のディスクに対しては、パリティグループ単位での書き込みになるようにストライプ境界とサイズを合わせれば、ストライプへの書き込みが全て終った段階で、ＲＡＩＤコントローラのキャッシュメモリ上でパリティグループが揃うため、パリティ計算のためのディスクリード処理が不要となり、所謂「ＲＡＩＤ５のライトペナルティ」を無くすことが可能になり、結果として高速な書込み処理が実現される。
【００５９】
また、一連のデータ書き込み処理が完了しない状態で、不慮のシステムダウンによる処理停止が起こった場合、論理アドレスログ領域１８ｂ２に記録した論理アドレスログ情報を用いて、システムリブート後のデータ回復処理が実行できる。なお、論理アドレスログ情報は、書き込み対象データストライプ３４に書き込まれる全ての書き込みデータブロックの論理アドレスと物理アドレスの関係が、データストライプ３４のＴＡＧ情報として登録された時点で不要になる。
【００６０】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。
図４に示した第１の実施形態では、論理アドレスログ領域１８ｂ２の割り当ては、ステップＳ４０３〜Ｓ４０５で空ストライプを割り当てる際に行っている。論理アドレスログ領域１８ｂ２は、図３に示すように固定的に１つ、あるいは複数用意されている。この第２の実施形態では、複数の論理アドレスログ領域１８ｂ３を用いて書き込み処理するものである。
【００６１】
先ず、図４のステップＳ４０５で行なった新しい論理アドレスログ領域を割り当てに際して、この実施形態では、複数の論理アドレスログ領域（１８ｂ２−１〜１８ｂ２−ｍ）のうち、一番最近使用されて開放された論理アドレスログ領域を選ぶようにする。
【００６２】
これを実現するために、使用した論理アドレスログ領域１８ｂ２をＬＲＵで管理する仕組みを用意する。また、論理アドレスログ領域（１８ｂ２−１〜１８ｂ２−ｍ）を示すＩＤ番号に関するスタック状のフリーリソース管理手段（図示せず）を用意する。なお、システム初期化時には、フリーリソース管理手段に全ての論理アドレスログ領域で示されるストライプＩＤが登録される。
【００６３】
図４のステップＳ４１０の処理によってＴＡＧ書き込みが完了した時点で、ＲＡＩＤ高速化ドライバ１００はそのストライプに割り当てていた論理アドレスログ領域を開放する（図６のステップＳ６００）。ここで、開放された論理アドレスログ領域（仮に１８ｂ２−１とする）を示すＩＤ番号は、フリーリソース管理手段のスタックに上から積まれる。図４のステップＳ４０５において、論理アドレスログ領域を新しく必要とする場合には、そのスタックの一番上に蓄積されたＩＤ番号が読み出され、そのアドレスに対応する論理アドレスログ領域１８ｂ２−１が確保される。即ち、一番最近開放された論理アドレスログ領域１８ｂ２−１が確保されることになる。このように管理することにより、常に「最も最近書き込み処理が行われ、そして開放された論理アドレスログ領域」が使用できるようになる。
【００６４】
一般的に、バッテリバックアップされたキャッシュを搭載したＲＡＩＤコントローラでは、繰り返し同じ領域に書込みを行うと、キャッシュに長い時間保持されるようになるために、引き続き発生するそれらの領域に対するライト処理は高速になる。この第２の実施形態では、この特性を利用することにより、上記のように論理アドレスログ領域１８ｂ２を管理して、なるべく同じ論理アドレスログ領域１８ｂ２−１を使用することにより、書き込みのオーバヘッドを少なくすることが可能となる。
【００６５】
この第２の実施形態の効果について更に解説する。
データ書き込みはパリティグループとしてのストライプ単位の連続領域への書き込みとなり効率が良いが、論理アドレスログ情報に関しては、パリティグループ単位での書き込みになるとは限らず、書き込み効率は悪い。ライトリクエストに対する完了通知は、「データの書き込み」と「論理アドレスログ情報の書き込み」の両方の完了をもって行われる。このため、論理アドレスログ情報の書き込みが遅くなると「書き込み処理全体」が遅くなってしまう。
【００６６】
一方、ディスクの読み書きデータのアドレスを管理するキャッシュメモリを有し、ライトバックキャッシュ機能を持つＲＡＩＤコントローラの場合は、同じアドレスに対するライトリクエストが続けて行われると、２回目以降のライトが早く完了することが多い。これは、ライトバックキャッシュに直前に書いたデータが記憶されており、同じアドレスへのデータは、キャッシュ上のデータの変更のみ完了するからである。したがって、実際のディスクへの書き込みを待たない。そのキャッシュ領域は、ＲＡＩＤコントローラのキャッシュ制御のポリシーにより、いつかはディスクに書き込まれ開放されるが、同じアドレスへのライトが短い間隔で定期的に続けば、恒常的にキャッシュ領域が確保されつづけ、比較的早くアクセスすることが可能になる。
【００６７】
第２の実施形態では、この特性を活かして論理アドレスログの書き込み処理を高速化する。例えば、（１）１ストライプのデータ書き込み分に相当するデータの論理アドレスログ情報をセーブするための領域（論理アドレスログ領域）を複数設ける。（２）書き込み対象データストライプを新規に割り当てる場合には、現在使っていないもので一番最近使った「論理アドレスログ領域」を１つ選び、ストライプにデータを書き込む際に、論理アドレスログ情報を書き込む領域として使用する。（３）対象データストライプに全てのデータを書き込んだ後には、それら書き込んだブロックを対象データストライプのＴＡＧ情報に登録する。全てのブロックに付いて登録が完了した時点で使用していた「論理アドレスログ領域」を解放する。
【００６８】
上記のように「論理アドレスログ領域」をＬＲＵで管理することにより、論理アドレスログ情報を書き込む領域が、ディスク上の限定された固定領域（領域が複数の場合も含む）になり、論理アドレス領域への書込みが高速になる結果、書込み処理の完了タイミングも早くなる。
【００６９】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。
図７は、第３の実施形態の動作を示すフローチャートである。
この第３の実施形態では、複数のライトリクエストを１つに纏めて書き込み処理するものである。ＲＡＩＤ高速化ドライバ１００が処理している未完了のライトリクエスト数を変数（Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ）で管理することにより実現する。Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔは初め「０」で初期化されているものとする。
【００７０】
図７において、ＯＳファイルシステム５０からのライトリクエストＲｅｑｉを受信すると（ステップＳ７０１）、ＲＡＩＤ高速化ドライバ１００はそのライトリクエストＲｅｑｉを変数としてＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔに登録する（ステップＳ７０２）。つまり、変数Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ（カウンタ値）の内容が＋１される。そして、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値がある定数「Ａ」より多いか否かがチェックされ（ステップＳ７０３）、定数「Ａ」より少ない場合には、そのライトリクエストＲｅｑｉはステップＳ７０４に進み、図４で示したライトリクエストＲｅｑｉのＩ／Ｏ要求の発行処理（図４のステップＳ４０７）が実行される。
【００７１】
一方、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔがある定数「Ａ」より大きい場合には、そのライトリクエストＲｅｑｉは一旦保留（ペンディング）され、ペンディングリクエストキューＰＬｉｓｔに入れられる（ステップＳ７０５）。ペンディングリクエストキューＰＬｉｓｔに入れられたライトリクエストＲｅｑｉ（複数登録可能）は、以下の条件が満たされた時に一まとめにされて書き込み処理が行われる。
（ペンディングされたライトリクエストのＩ／Ｏ要求発行条件）
ａ）ペンディングしているリクエストＲｅｑｉの数Ｐｃｏｕｎｔが定数「Ｂ」以上になった（ステップＳ７０７のチェック）。
ｂ）ペンディングしているリクエストＲｅｑｉのデータサイズＰｓｉｚｅの合計が定数「Ｃ」以上になった（ステップＳ７０８のチェック）。
ｃ）ペンディングしているリクエストＲｅｑｉのデータサイズＰｓｉｚｅの合計が現在の書込み対象データストライプの残りの空き領域を越えた（ステップＳ７０９のチェック）。
ｄ）タイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）が指定時間を経過して起動された（ステップＳ７１０のチェック）。
【００７２】
ここでタイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）とは、時間と関数を指定すると、指定した時間が経過した時点で指定した関数を実行してくれるＯＳ（オペレーティングシステム）のサービスで登録した関数のことである。この場合、例えば「３０ｍｓ時間後に指定する関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）を実行せよ」というようにＯＳに登録する。ステップＳ７１０でセットするタイマ関数ＴｉｍｅｒＲｏｕｔｉｎｅ（）の処理は図８に示している。
【００７３】
上記の条件ａ）〜ｄ）を判定するために、図７では以下の変数で管理している。
ペンディングリクエストの数 ・・・ Ｐｃｏｕｎｔ
ペンディングリクエストのデータサイズの合計 ・・・ Ｐｓｉｚｅ
【００７４】
上記した条件ａ）〜 ｄ）のいずれかが満たされた場合には（ステップＳ７０７のＹｅｓ、又はＳ７０８のＹｅｓ、又はＳ７０９のＹｅｓ、又はＳ７１０）、変数Ｐｃｏｕｎｔ、Ｐｓｉｚｅを０クリアする（ステップＳ７１１、Ｓ７１２、図８のステップＳ８０１、Ｓ８０２）。さらにタイマ関数Ｔｉｍｅｒ Ｒｏｕｔｉｎｅ（）がセットされているか否かがチェックされ（ステップＳ７１３）、タイマ関数Ｔｉｍｅｒ Ｒｏｕｔｉｎｅ（）がセットされていればそれをリセットする（ステップＳ７１４）。そして、ペンディングリストＰＬｉｓｔのライトリクエストを１つのライトリクエストＷＲｅｑ として、図４のステップＳ４０７の手順に従ってライト処理を行なう（ステップＳ７１５、図８のステップＳ８０３）。
【００７５】
なお、ここで、ペンディングリストＰＬｉｓｔにつながっているリクエストをまとめた ＷＲｅｑ の書き込み対象データストライプ（例えばストライプ３４）へのデータ書き込みは、それを構成する複数のライトリクエスト毎にはライトせず、一まとめにして１つのライトリクエストで書き込む。また、論理アドレスログ領域１８ｂ２への書き込みに関しても、ＷＲｅｑ全体に関して１回の書き込みとする。これらの完了時処理を図９に示す。
【００７６】
図９において、ＲＡＩＤ高速化ドライバ１００はライトリクエストＲｅｑｉに関して、データ書き込み完了（Ｉ／Ｏ完了処理１）では論理アドレスログ番号の書き込み処理が完了しているか否かをチェックし（ステップＳ９０１）、一方、論理アドレスログ書き込み完了（Ｉ／Ｏ完了処理２）ではデータ書き込み処理が完了したか否かをチェックする（ステップＳ９１０）。それらの書き込みが完了していれば、元々のライトリクエストＲｅｑｉに関して全てのデータ書き込みと論理アドレスログの書き込みが完了しているものとしてＯＳファイルシステム５０にＩ／Ｏ完了を通知する（ステップＳ９０２）。そして、Ｏｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値から完了したライトリクエストＲｅｑｉを引いた値をＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔの値として更新記録して、処理を終了する（ステップＳ９０３）。
【００７７】
この第３の実施形態の具体的な動作の例について、図１０〜図１１を用いて説明する。先ず、以下の動作例では、ＲＡＩＤ高速化ドライバ１００にＯＳファイルシステム５０からライトリクエストＲｅｑｉがマルチストリームで並行して多数到来してきている状況とする。図１０（ａ）は、この内４つのライトリクエストＲｅｑ１〜Ｒｅｑ４が到来したところを示している。なお、この時点で、ＲＡＩＤ高速化ドライバ１００は既に複数のライトリクエストを処理中であり、これらリクエスト到着時には既にＯｕｔｓｔａｎｄｉｎｇ Ｒｅｑ Ｃｏｕｎｔ≧Ａの条件を満たしているものとする。即ち、図７のステップＳ７０３がＹｅｓの条件で進む。
【００７８】
図１０（ａ）で、各ライトリクエストＲｅｑ１〜Ｒｅｑ４について、ライトサイズ、論理ブロック番号を示した。なお、ここではＲＡＩＤ高速化ドライバ１００のデータ管理単位は２ＫＢであるとし、ＯＳファイルシステム５０からの書き込みアドレスは、書き込み先の論理ブロック番号で示している。例えば、論理ブロック番号１００とは、論理アドレス（ＯＳファイルシステムが指定した書き込み先アドレス）で１００×２ＫＢ＝２００ＫＢのアドレスを意味する。また、ライトリクエストＲｅｑ１は書き込み先の論理アドレス番号１００に４ＫＢのデータを書き込むものであるのに対し、ＲＡＩＤ高速化ドライバ１００のデータ管理単位は２ＫＢであることから、このリクエストＲｅｑ１は論理アドレス番号Ｖとして、１００、１０１が割り当てられることを理解する。同様に、リクエストＲｅｑ２では６ＫＢであるから、論理アドレス番号Ｖ＝７６、７７、７８が割り当てられ、リクエストＲｅｑ３は２ＫＢであるから論理アドレス番号Ｖ＝６０が割り当てられ、リクエストＲｅｑ４は８ＫＢであるから、論理アドレス番号Ｖ＝７９、８０、８１、８２が割り当てられることを理解する。ここで、定数Ｂ＝４とし、ステップＳ７０７のＰｃｏｕｎｔ≧Ｂの条件が成立した場合を考える。
【００７９】
初め、ペンディングリクエストＰＬｉｓｔにライトリクエストが１つも無かった状態の場合に、ライトリクエストＲｅｑ１〜Ｒｅｑ４がこの順に到来したとする。これらのリクエストは、先ずペンディングリクエストＰＬｉｓｔに順次格納され、ライトリクエストＲｅｑ４が来た時点で図１０（ｂ）の状態に格納される。
【００８０】
この時点で、図７のステップＳ７０７の条件が成立し、ステップＳ７１１に制御が移り、ステップＳ７１５で、ペンディングリストＰＬｉｓの４つのリクエストＲｅｑ１〜Ｒｅｑ４（全２０ＫＢ）が１つのライトリクエストＷＲｅｑとして、図４で示した手順によりディスク１８０にライト処理される。この時、ライトリクエストＷＲｅｑによる２０ＫＢのデータが書き込み対象データストライプ（例えばストライプ３４）の残りの空き領域に入りきらない場合には、その空き領域に入るサイズ（例えば、１０ＫＢ）で切り、その単位で処理する。残りの１０ＫＢは、別な空き領域のストライプに、別なもう１つのライトリクエストＷＲｅｑに纏めてＩ／Ｏ要求を発行する。
【００８１】
この時のディスク１８０へのライト処理の様子を図１１に示す。ファイルシステムからのライトリクエストＲｅｑ１〜Ｒｅｑ４は、本来４つのライトリクエストであるが、書き込み先アドレスは連続した１つのデータストライプ３４であるので、まとめて１つのライトリクエストＷＲｅｑによって書き込み処理が行われる。同時に、論理アドレスログ情報も、一括ライトを発行したデータに対応した論理アドレスログ領域１８ｂ２へ論理アドレス情報Ｖ＝１００，１０１，７６，７７，・・・，８２が１つのライトＩ／Ｏ要求によって書き込まれる。
【００８２】
この結果、書き込み対象データストライプ３４へのデータライトに４つのＩ／Ｏ要求が、また論理アドレスログ領域１８ｂ２への論理アドレスログ情報の書込みに４つのＩ／Ｏ要求が必要だったところが、ペンディングリストＰＬｉｓｔに格納して書き込むことにより、２つのライトＩ／Ｏ要求で書き込み処理を行なうことが可能となり、Ｉ／Ｏ要求の発行を少なくして、まとめ書きによる高速化が達成される。なお、上記した例では定数Ｂ＝４とし、Ｐｃｏｕｎｔ≧Ｂの条件が成立した場合を考えたが、上述した他の条件ｂ），ｃ），ｄ）の各条件が成立した場合（ステップＳ７０８、Ｓ７０９、Ｓ７１０）も、全く同様である。
【００８３】
この第３の実施形態によれば、ある時点でＲＡＩＤ高速化ドライバが処理中でまだ完了を通知していない、上位から送られてきたリクエスト（具体的には、ディスク制御システムドライバに入ったリクエストで、まだ完了通知を行っていないリクエスト）の個数をカウンタで管理することにより、任意時点での「ライトリクエストの同時Ｉ／Ｏ発行数」を得ることができる。この「ライトリクエストの同時Ｉ／Ｏ発行数」が所定値Ａよりも大きな値の時には、以降のライトリクエストに関して、データ及び論理アドレスログ情報の書き込みを一定時間待つ。そして、▲１▼一定以上の個数のライトリクエストが新たに到着した。▲２▼到着したライトリクエストのライトサイズの合計が、一定サイズを越えた。▲３▼到着したライトリクエストのライトサイズの合計が、現在書込み対象になっているストライプの残り空領域のサイズを越えた。▲４▼一定時間が経過した。の場合に、それまでペンディングしていたライトリクエストのデータを１まとめにして対象のストライプに書き込む。同時に書き込むデータブロック（複数）の論理アドレスログ情報をまとめて１回の書込みとして「論理アドレスログ領域」に書き込む。
【００８４】
この結果、複数のライトリクエストが１度のデータライト処理と１度の論理アドレスログ情報の書き込み処理となる。各データリクエストの開始は遅れるが、書き込み処理回数が減り、書き込みサイズが大きくなることでディスクへのトータルとして書込みオーバヘッドが小さくなり、結果的に書き込み処理のスループット向上を実現できる。
【００８５】
（第４の実施形態）
次に、本発明の第４の実施形態について説明する。
この第４の実施形態では、論理アドレスログ領域１８ｂ２に論理アドレスログ情報のみならず、書き込みデータサイズおよびチェックサムを併せて記録するものである。図１２は、ライトリクエストＲｅｑ１のライトデータａに対して、書き込み対象データストライプ３４に対応する論理アドレスログ領域１８ｂ２に、
▲１▼論理アドレス Ｖ＝１００、１０１
▲２▼ライトサイズ Ｓｉｚｅ＝４ＫＢ
▲３▼チェックサム ＣｈｋＳｕｍ＝０ｘ１６ｆ９２ａａｂ
を書き込む様子を示している。このチェックサムＣｈｋＳｕｍは、ライトデータａを４バイト単位で加算した結果の値である。このように、ライトデータサイズおよびそのチェックサムを論理アドレスログ領域に記録することにより、障害回復を容易にする。
【００８６】
即ち、ディスク１８のデータ領域１８ｃへのデータ書き込み中にシステムの障害が発生した場合には、書き込み処理途中のストライプに関して、その論理アドレスログ領域１８ｂ２に書き込まれているチェックサム値とデータ領域１８ｃのデータから求めたチェックサム値とが一致するか否かを確認チェックする。一致した場合には、データ書き込みが完了していたと判断し、データを有効とみなし残りの処理（アドレス変換テーブルへの登録等）を行い、書き込み処理を完了させる。一致しなかった場合には、書き込みは完了しなかったとみなし、そのデータを捨てる。
【００８７】
（第５の実施形態）
次に、第５の実施形態について説明する。
第５の実施形態では、ライトデータａを書き込み対象データストライプ３４に書き込むだけでなく、論理アドレスログ領域１８ｂ２にも論理アドレスログ情報と一緒に書き込むものである。
【００８８】
図１３は、この第５の実施形態による論理アドレスログ領域１８ｂ２への書き込みデータの構成を示している。即ち、論理アドレスログ領域１８ｂ２には、
▲１▼論理アドレス Ｖ＝１００、１０１
▲２▼ライトサイズ Ｓｉｚｅ＝４ＫＢ
▲３▼チェックサム ＣｈｋＳｕｍ＝０ｘ１６ｆ９２ａａｂ
▲４▼ライトデータａ（４ＫＢ）
が書き込まれる。実際には上記した▲１▼〜▲４▼は１つのライトＩ／Ｏ要求で処理するものであり、これによりオーバヘッドを減らすことができる。
【００８９】
図１４は、この第５の実施形態によるＲＡＩＤ高速化ドライバ１００の動作手順を示すフローチャートである。ＯＳファイルシステム５０からライトリクエストＲｅｑｉ（ｉ＝１，２，３，４‥）が入力され、そのライトリクエストＲｅｑｉは、論理アドレスａｄｄｒｉから始まる２ＫＢ単位のライトブロックデータＢ０〜Ｂｎからなるものとする（ステップＳ１４０１）。
【００９０】
このライトリクエストReqiに対して、空き領域を有するデータストライプが、書込み対象ストライプとして割り当てられているか否かがチェックされ（ステップＳ１４０２）、割り当てられていなければディスク上の空ストライプを１つ選択する（ステップＳ１４０３）。そして、データストライプと同じサイズのバッファＷＢを主メモリ１３上に確保する（ステップＳ１４０４）。バッファＷＢはライトバッファ１７１に確保される。割り当てられたストライプＩＤをＩＤｋとして、管理データ領域１８ｂのストライプＩＤログ領域18b1に次のエントリとして書き込む（ステップＳ１４０５）。ストライプＩＤログ領域18b1には、書き込み対象に選ばれたストライプのＩＤが時系列順に記録（３１，３４，…）されていく。
【００９１】
次に、管理データ領域１８ｂの論理アドレスログ領域１８ｂ２を割り当てる（ステップＳ１４０６）。書き込み対象データストライプ（例えば、ストライプ３４）中の次の空き領域に、まだライト領域を割り当てていないデータストライプＢｊのための領域を可能な限り確保する（ステップＳ１４０７）。
【００９２】
ＲＡＩＤ高速化ドライバ１００は、このステップＳ１４０７で確保したサイズのデータを主メモリ１３に用意したバッファＷＢにコピーする（ステップＳ１４０８）。バッファＷＢは、ストライプ領域に等しい大きさを持った主メモリ１３上に確保したライトバッファである。
【００９３】
次に、ステップＳ１４０９では図１３のように、▲１▼論理アドレス情報と▲２▼ライトデータを１つのライトＩ／Ｏ要求によって論理アドレスログ領域１８ｂ２に書き込む。そして、データストライプに空き領域がなく、ストライプに対する書込みデータがバッファＷＢで全て揃った場合には（ステップＳ１４１０）、バッファＷＢの内容を書き込み対象データストライプ３４に一括ライトするＩ／Ｏ要求が発行され、ディスク１８０の書き込み対象データストライプ３４に書き込まれる（ステップＳ１４１１）。また、その書き込み対象データストライプ３４に書き込んだＴＡＧ情報をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュ１７２を更新する（ステップＳ１４１２）。一方、ステップＳ１４１０において、書き込み対象データストライプに空き領域がない場合には、上記ステップＳ１４１１、Ｓ１４１２の処理をせず、ステップＳ１４１３に進む。ステップＳ１４１３では、ライトリクエストＲｅｑｉに対して全てのデータブロックの書き込みＩ／Ｏ要求が発行されたか否かが判断される。まだライトすべきデータが残っている場合には、ステップＳ１４０２に戻り、新たなストライプを割り当てて、同様にライトリクエストを書いていく。
【００９４】
なお、この実施例では、書き込み対象データストライプ３４内の１データブロックをＴＡＧ領域としている。従って、ステップＳ１４１１において、予めＴＡＧデータをバッファＷＢ上にセットした状態で、バッファＷＢの書き込みが終了すれば、ＴＡＧデータの書き込みも同時に終了する。
【００９５】
図１５は、図１４のステップＳ１４０９、およびステップＳ１４１１のＩ／Ｏ完了処理の動作を示すフローチャートである。図１５（ａ）はステップＳ１４１１の書き込み対象データストライプにおける完了処理（Ｉ／Ｏ完了処理１）であり、書き込みが完了したライトリクエストＲｅｑｉの「完了」をＯＳファイルシステム５０に通知する（ステップＳ１５０１）。一方、図１５（ｂ）はステップＳ１４０９の論理アドレスログ領域１８ｂ２への書き込み完了処理（Ｉ／Ｏ完了処理２）であり、論理アドレスログ領域１８ｂ２への書き込みが完了すると、バッファＷＢを開放して（ステップＳ１５１０）、更に論理アドレスログ領域１８ｂ２を開放して終了する（ステップＳ１５１１）。
【００９６】
この第５の実施形態と、上述の第１の実施形態を比較すると、第５の実施形態では個々のライトリクエストＲｅｑｉに対して、論理アドレスログ領域１８ｂ２に論理アドレスログ情報とライトデータａの書き込みが完了すれば、その時点でＯＳファイルシステム５０に対して完了通知することができる。つまり、ＯＳファイルシステムに対するレスポンスが早くなる。これに対し、第１の実施形態では、論理アドレスログ領域１８ｂ２への書き込みと、書き込み対象データストライプ３４への書き込みの、２つのライトＩ／Ｏ要求完了まで完了通知が待たされる。
【００９７】
一方で個々のライトデータに付いて考えると、第５の実施形態では、結果的には論理アドレスログ領域１８ｂ２と、データストライプ３４へ、２つの書き込みとなる。論理アドレスログ領域１８ｂ２は、ライトデータａを２重に書くというのは、実施形態２を用いて同じ領域への書き込みになるよう、キャッシュを有効利用したとしても、ＲＡＩＤコントローラ１６の特性によっては大きな負荷となる可能性がある。このため、第１の実施形態の方式にするか、第５の実施形態の方式にするかは、使用しているＲＡＩＤコントローラ１６の特性によって結果的に性能が良い方式を選ぶようにする。
【００９８】
（第６の実施形態）
ＲＡＩＤ高速化ドライバ１００が、書き込み処理中にシステムに障害が発生した場合には、データや論理アドレスログ情報等の書き込みが完了しない状態でシステムが立ち上がってくる場合がある。このようなときに、データ書き込みが完了していたものについては、書き込み対象データストライプに対応するＴＡＧ領域とＡＭＴキャッシュ１７２にそのブロックを登録し直すことにより、以降、そのデータへのアクセスが可能になる。ここで、データがディスク１８に正しく書き込めたか否かの判断は、論理アドレスログ情報としてセーブしたデータのチェックサム情報と、書き込み先のデータの領域から再計算したチェックサムが一致することが検出されれば、「正しいデータである」と判断出来る。その場合、論理アドレスログ領域１８ｂ２にセーブした（データのチェックサムの値を含む）値が、「本当に正しい値であるか」を保証する必要が有る。このため、例えば論理アドレスログ領域１８ｂ２の各エントリ毎に、
（ｘ）エントリ書き込み時に、特定の文字列（ｓｉｇｎａｔｕｒｅ）をエントリの領域の最初と最後に入れておき、読み出し時にチェックする。
（ｙ）エントリ全体のチェックサムを計算して記録する。
（ｚ）ターゲットのストライプＩＤを記録して、論理ストライプログ領域１８ｂ２の先頭のブロックに記録されるストライプＩＤとの一致を確認する。
等して、各エントリのデータ整合性を確認すれば良い。
【００９９】
上記した処理を、図１６のフローチャートに示す。なお、書き込み方式は第１の実施形態の方式であることを前提として説明する。
【０１００】
ステップＳ１６０１では、論理アドレスログ領域１８ｂ２を参照して使用中のものが有るか確認する。論理アドレスログ領域１８ｂ２が使用中か否かの判断は、例えば図１７に示すように、予め、論理アドレスログ領域１８ｂ２の先頭（ヘッダ部）に、使用中を示すフラグ（Ｖａｌｉｄ）を設け、論理アドレスログ領域１８ｂ２が使用中の間は、このフラグをセット（Ｖａｌｉｄ＝”１”）し、論理アドレスログ領域１８ｂ２を解放する時にリセット（Ｖａｌｉｄ＝”０”）すれば良い。図１７の例では、論理アドレスログ領域１８ｂ２が４つある例を示しており、この論理アドレスログ領域１８ｂ２の中では、使用中フラグ（Ｖａｌｉｄ＝”１”）を示している、論理アドレスログＬＡ１、ＬＡ２が使用中であると判断できる。これに従って、使用中リストＳにはＬＡ１、ＬＡ２として記録される。
【０１０１】
次に、ステップＳ１６０２では、上記のリストＳをヘッダ部のタイムスタンプＴＳの値によりソートする。このソートにより、結果的に時系列順にソートされる。図１７の例では、論理アドレスログＬＡ２のタイムスタンプＴＳ＝１１６７９が論理アドレスログＬＡ１のタイムスタンプＴＳ＝１１６８０より小さい（即ち、古い）ので、ステップＳ１６０２におけるソート結果のリストＳは、ＬＡ２、 ＬＡ１の順となる。
【０１０２】
次に、ステップＳ１６０３にて使用中の論理アドレスログ領域１８ｂ２（要素）があることを判断し、ステップＳ１６０４で、リストＳから一番古いタイムスタンプＴＳを持つ要素を選択（最初に論理アドレスログＬＡ２を選択）する。ステップＳ１６０５では、ＴＡＧイメージ用に確保した主メモリ１３の領域（ライトバッファ１７１に確保される）を初期化し、「対象データストライプの全ブロックが無効である」状態にする。そして、ステップＳ１６０６では、変数ｋ＝０に設定する。ステップＳ１６０７以降は、論理アドレスログＬＡ２内の各有効なエントリに対してデータのチェックサム値を読み出して、実際にストライプに書き込んであるデータのチェックサムと一致するか否かを確認する。有効なエントリの判断は、上述した（ｘ）〜（ｚ）のようにすれば良い。
【０１０３】
図１７の論理アドレスログＬＡ２の例では、エントリＥ０、Ｅ１、Ｅ２、・・が有効なエントリであると想定している。エントリＥ０に注目すると、論理アドレスログの先頭から２つの物理ブロックに、論理アドレスＶ＝４６３，４６４と、それぞれのデータブロックのチェックサムＣＳ（ＣｈｋＳｕｍ０）＝ＣＳ０，ＣＳ１が登録されている。そこでステップＳ１６０８では、実際にデータストライプ３４（論理アドレスログＬＡ２に対応するデータストライプ）の１番目、２番目のデータブロックを読み出して、チェックサムＣｈｋＳｕｍ１＝ＣＳ０’，ＣＳ１’を求める。
【０１０４】
ステップＳ１６０９では、チェックサムＣｈｋＳｕｍ０とＣｈｋＳｕｍ１（ＣＳ０とＣＳ０’、およびＣＳ１とＣＳ２’）を比較して等しいか否かを判断する。その比較結果が一致するブロックについては正しいデータであると判断し、ステップＳ１６１０でデータストライプ３４のＴＡＧ領域にその論理ブロック番号を登録する。図１８は、このようにして、エントリＥ０、Ｅ１までの５データブロックを処理した時点のＴＡＧ領域の状態が示されている。なお、ここではデータストライプ３４の先頭ブロックの物理ブロック番号が２０００であると仮定している。そして、ステップＳ１６１１で、変数ｋ＝ｋ＋１とし、更にステップＳ１６１２にてｋ≦Ｎ（Ｎはデータストライプを構成するデータブロック数）の比較を行なう。
【０１０５】
論理アドレスログＬＡ２の全てのエントリに付いて、ステップＳ１６０７〜Ｓ１６１２の処理を終えたら、ＴＡＧ情報が完成する。そして、ステップＳ１６１３およびＳ１６１４にて、ＴＡＧ情報を本来のアドレスに書き込み（ストライプ３４の場合、一番最後の物理ブロック）、同じ内容をＡＭＴキャッシュ１７２に登録してＡＭＴキャッシュ１７２を更新する。最後にＳ１６１５でＬＡ２の使用中フラグをリセット（ｖａｌｉｄ＝”０”）して、論理アドレスログＬＡ２の回復処理は終了する。同様の処理を論理アドレスログＬＡ１について行えば、障害発生時に書き込み途中であった論理アドレスログＬＡ１、ＬＡ２の書き込みを終了させることができる。
【０１０６】
なお、図１８のＴＡＧ領域には有効なデータに関しては、その論理アドレス値、無効なアドレスに関しては無効である旨を示す論理アドレス値を使って、ＴＡＧデータを作成しＴＡＧを書き込む。無効論理アドレス値としては、例えばそのパーティションに存在しない論理アドレス値を使用する。
【０１０７】
以上、本実施形態では、第１の実施形態の書き込み方式（データはリクエスト単位で対象ストライプに書き込む）を前提にしたが、第６の実施形態の書き込み方式（データは一旦論理アドレスログ領域に書き込み、バッファＷＢが一杯になった時点でバッファＷＢの単位で対象ストライプに書き込み）の場合でも、
（イ）ステップＳ１６０８で論理アドレスログ領域１８ｂ２の書き込みデータからＣｈｋＳｕｍ１を求める。
（ロ）ステップＳ１６０９、Ｓ１６１０の間で、書き込みデータを対象ストライプに書き込む。
という変更を行うことによりほぼ同様に処理できる。
【０１０８】
【発明の効果】
以上、発明によれば、ログ形式のデータブロック管理方式を採用したディスクシステムにおいて、ファイルシステムのライトアドレス情報をディスク上の固定領域に書き込むことによりＲＡＩＤコントローラのキャッシュを有効利用し書き込み時間を短縮することができる。アドレス変換テーブルの管理にチェックサムを導入することにより、不意のシステムダウン後の障害回復処理後等にアドレス変換テーブルの整合性を確認し信頼性を向上する。
【図面の簡単な説明】
【図１】本発明のディスク制御システムを適用した計算機システムの構成を示すブロック図。
【図２】本発明のＲＡＩＤ高速化ドライバによるディスクアレイの書き込み制御の原理を示すブロック図。
【図３】本発明の第１の実施形態における、ＲＡＩＤ高速化ドライバとディスクとの関係と、ＲＡＩＤ高速化ドライバによる書き込み制御を示すブロック図。
【図４】本発明の第１の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図５】本発明の第１の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図６】本発明の第１の実施形態における、Ｉ／Ｏ完了処理３の手順を示すフローチャート。
【図７】本発明の第３の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図８】本発明の第３の実施形態における、タイマ関数のセット処理の手順を示すフローチャート。
【図９】本発明の第３の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図１０】本発明の第３の実施形態における、ライトリクエストＲｅｑｉの構成、およびペンディングリストへの格納状況を示す図。
【図１１】本発明の第３の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１２】本発明の第４の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１３】本発明の第５の実施形態における、データストライプ、および論理アドレスログ領域への書き込み操作を示す図。
【図１４】本発明の第５の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図１５】本発明の第５の実施形態における、Ｉ／Ｏ完了処理１および２の手順を示すフローチャート。
【図１６】本発明の第６の実施形態における、ライト処理のメインルーチンを示すフローチャート。
【図１７】本発明の第６の実施形態における、論理アドレスログＬＡ０〜ＬＡ３の構成例を示す図。
【図１８】本発明の第６の実施形態における、データストライプのＴＡＧ情報の書き込み状態を示す図。
【符号の説明】
１…プロセッサバス
２…ＰＣＩバス
１１…ＣＰＵ＃１、＃２、＃３
１２…ブリッジ
１３…主メモリ
１６…ＲＡＩＤコントローラ
１７…ドライバ作業領域
１７１…ライトバッファ（ログメモリ）
１７２…アドレス変換テーブルＡＭＴ（キャッシュ）
１７３…ストライプ管理テーブル
１８…ディスクアレイ
１８ａ…ＡＭＴ領域
１８ｂ…管理データ領域
１８ｂ１…ストライプＩＤログ領域
１８ｂ２…論理アドレスログ領域
１８ｃ…データ領域
５０…ＯＳファイルシステム
１００…ＲＡＩＤ高速化ドライバ
Claims (28)
- 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた管理データ領域に、前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として書き込む手段と、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とするディスク制御システム。 - 前記上位ファイルシステムからの前記ライトリクエストによって転送された複数のデータブロックに対して、１つのライトリクエストとしてのＩ／Ｏ要求を発行して、前記複数のデータブロックを同時に前記書き込み対象データストライプの空き領域に書き込むことを特徴とする請求項１記載のディスク制御システム。
- 前記論理アドレスログ情報は、前記管理データ領域に１つ又は複数個設けられた論理アドレスログ領域に書き込まれることを特徴とする請求項１記載のディスク制御システム。
- 前記複数個の論理アドレスログ領域で構成した場合、現在使っていないもので一番最近使用した論理アドレスログ領域を使用することを特徴とする請求項３記載のディスク制御システム。
- 前記論理アドレスログ領域は、前記ディスク上に固定的に設けられていることを特徴とする請求項３記載のディスク制御システム。
- 前記データ書き込み処理が完了しない状態で、システムダウンを起した場合、前記論理アドレスログ領域に記録した前記論理アドレスログ情報を用いてシステムリブート後のデータ回復を行なうことを特徴とする請求項３記載のディスク制御システム。
- 前記管理データ領域には、書き込みが行われたストライプＩＤ、およびこれから書き込みが行われるストライプＩＤを記録するストライプＩＤログ領域を更に有することを特徴とする請求項１記載のディスク制御システム。
- 前記書き込み対象データストライプの一部をタグ情報の書き込み領域として用い、前記書き込み対象データストライプの全領域のデータが揃った時の前記論理アドレスログ領域に書き込まれた論理アドレス情報が前記タグ情報として書き込まれることを特徴とする請求項１記載のディスク制御システム。
- 主メモリの一部に書き込みデータに関する論理アドレスと物理アドレスの対応を記憶するアドレス変換テーブルキャッシュを設け、前記書き込み対象データストライプへのデータおよびタグ情報の書き込みが終了した時、前記アドレス変換テーブルキャッシュを前記タグ情報を基に更新することを特徴する請求項８記載のディスク制御システム。
- 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、
主メモリ上に設けられたライトバッファに、複数のライトリクエストに対応する複数のブロックデータを書き込む手段と、
前記複数のライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に、前記ライトバッファに記憶した複数のブロックデータを一括ライトするデータ書き込み手段と、
前記複数のブロックデータに対応する前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として、前記複数のディスク上に設けられた管理データ領域に一括ライトするログ書き込み手段と、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに完了を通知する手段とを具備することを特徴とするディスク制御システム。 - 前記ライトリクエストの数を変数として管理し、前記変数が所定値以上の場合は、前記ライトリクエストをペンディングリクエストとして保留し前記データおよびログ書き込み手段による一括ライト処理を実行し、前記変数が所定値より小さい場合は、前記ライトリクエスト単位の書き込み処理を実行することを特徴とする請求１０記載のディスク制御システム。
- 前記一括ライト処理の実行判断は、前記ペンディングリクエストのリクエスト数が所定値を越えた時、または前記ペンディングリクエストのデータサイズ合計が所定値を越えた時、または前記ペンディングリクエストのデータサイズ合計が前記書き込み対象データストライプの残りの空き領域を越えた時、または前記ペンディングしている時間が所定時間経過した時に行なわれることを特徴とする請求項１１記載のディスク制御システム。
- 前記論理アドレスログ情報は、前記管理データ領域に１つ又は複数個設けられた論理アドレスログ領域に書き込まれることを特徴とする請求項１０記載のディスク制御システム。
- 前記複数個の論理アドレスログ領域で構成した場合、現在使っていないもので一番最近使用した論理アドレスログ領域を使用することを特徴とする請求項１０記載のディスク制御システム。
- 前記論理アドレスログ領域は、前記ディスク上に固定的に設けられていることを特徴とする請求項１０記載のディスク制御システム。
- 前記データ書き込み処理が完了しない状態で、システムダウンを起した場合、前記論理アドレスログ領域に記録した前記論理アドレスログ情報を用いてシステムリブート後のデータ回復を行うことを特徴とする請求項１５記載のディスク制御システム。
- 前記管理データ領域には、書き込みが行われたストライプＩＤ、およびこれから書き込みが行われるストライプＩＤを記録するストライプＩＤログ領域を更に有することを特徴とする請求項１０記載のディスク制御システム。
- 前記書き込み対象データストライプの一部をタグ情報の書き込み領域として用い、前記書き込み対象データストライプの全領域のデータ揃った時の前記論理アドレスログ領域に書き込まれた論理アドレス情報が前記タグ情報として書き込まれることを特徴とする請求項１０記載のディスク制御システム。
- 主メモリの一部に書き込みデータに関する論理アドレスと物理アドレスの対応を記憶するアドレス変換テーブルキャッシュを設け、前記書き込み対象データストライプへのデータおよびタグ情報の書き込みが終了した時、前記アドレス変換テーブルキャッシュを前記タグ情報を基に更新することを特徴する請求項１８記載のディスク制御システム。
- 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、および書き込みデータサイズ、および書き込みデータのチェックサムを論理アドレスログ情報として書き込む手段と、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とするディスク制御システム。 - 書き込み中にシステムの障害が発生した場合には、書込み処理途中のストライプに関して、その前記論理アドレスログ領域に書き込まれているチェックサム値が前記データ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし、そのデータを捨てることを特徴とする請求項２０記載のディスク制御システム。
- 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、書き込みデータサイズ、書き込みデータのチェックサム、および少なくとも１データブロックを論理アドレスログ情報として書き込む手段と、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、
前記上位ファイルシステムからのライトリクエストに対して、前記論理アドレスログ領域への前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知する手段とを具備することを特徴とするディスク制御システム。 - 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御システムにおいて、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域のヘッダ部に有効／無効を示すフラグ、ストライプＩＤ番号、および最終データの書き込みタイムスタンプを記録し、前記論理アドレスログ領域のエントリ部に書き込みリクエストによって処理される１つ又は複数のブロックデータのタイムスタンプ、１つ又は複数の論理アドレス、および１つ又は複数のチェックサムを論理アドレスログ情報として書き込む手段と、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込む手段と、
書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その前記論理アドレスログ領域に書き込まれているチェックサム値が前記データ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし、そのデータを捨てることを特徴とするディスク制御システム。 - 前記チェックサムが一致した場合、前記データストライプのＴＡＧ領域に物理アドレスおよび論理アドレスの対応表を記録し、そのＴＡＧ領域の対応表を主メモリのアドレス変換テーブルキャッシュに反映させることを特徴とする請求項２３記載のディスク制御システム。
- 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御方法において、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込み、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた管理データ領域に、前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として書き込み、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知することを特徴とするディスク制御方法。 - 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御方法において、
主メモリ上に設けられたライトバッファに、複数のライトリクエストに対応する複数のブロックデータを書き込み、
前記複数のライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に、前記ライトバッファに記憶した複数のブロックデータを一括ライトするデータ書き込み、
前記複数のブロックデータに対応する前記上位ファイルシステムからの前記論理アドレスを論理アドレスログ情報として、前記複数のディスク上に設けられた管理データ領域に一括ライトするログ書き込み、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに完了を通知することを特徴とするディスク制御方法。 - 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御方法において、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込み、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域に、前記上位ファイルシステムからの前記論理アドレス、および書き込みデータサイズ、および書き込みデータのチェックサムを論理アドレスログ情報として書き込み、
前記上位ファイルシステムからのライトリクエストに対して、前記データと前記論理アドレスログ情報の書き込み完了をもって、上位ファイルシステムに書き込み完了を通知することを特徴とするディスク制御方法。 - 論理アドレスを用いた少なくとも１つのデータブロックからなるデータの書き込みを行うための上位ファイルシステムから出力されるライトリクエストに応答して、論理アドレスから物理アドレスへのアドレス変換を行い、複数のディスク装置により構成される書き込み領域であるデータストライプに対して連続的にライトリクエストのデータを書いていくディスク制御方法において、
前記ライトリクエストに応答して、前記複数のディスク上に設けられた論理アドレスログ領域のヘッダ部に有効／無効を示すフラグ、ストライプＩＤ番号、および最終データの書き込みタイムスタンプを記録し、前記論理アドレスログ領域のエントリ部に書き込みリクエストによって処理される１つ又は複数のブロックデータのタイムスタンプ、１つ又は複数の論理アドレス、および１つ又は複数のチェックサムを論理アドレスログ情報として書き込み、
前記ライトリクエストに応答して、前記複数のディスク上に設けられたデータ領域の割り当てられた書き込み対象データストライプの空き領域に前記データを書き込み、
書き込み中にシステムの障害が発生した場合には、書込み処理途中の有効なフラグがセットされているストライプに関して、その前記論理アドレスログ領域に書き込まれているチェックサム値が前記データ領域の書き込みデータから求めたチェックサム値との一致を確認し、一致した時には、そのデータは有効なデータとして取り扱い、一致しなかった時には書き込みが完了しなかったとみなし、そのデータを捨てることを特徴とするディスク制御方法。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001001137A JP3592640B2 (ja) | 2001-01-09 | 2001-01-09 | ディスク制御システムおよびディスク制御方法 |
| EP01122025A EP1221646A3 (en) | 2001-01-09 | 2001-09-13 | Disk control system and method |
| US09/954,303 US7216199B2 (en) | 2001-01-09 | 2001-09-18 | Disk control system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001001137A JP3592640B2 (ja) | 2001-01-09 | 2001-01-09 | ディスク制御システムおよびディスク制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002207572A JP2002207572A (ja) | 2002-07-26 |
| JP3592640B2 true JP3592640B2 (ja) | 2004-11-24 |
Family
ID=18869807
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001001137A Expired - Fee Related JP3592640B2 (ja) | 2001-01-09 | 2001-01-09 | ディスク制御システムおよびディスク制御方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7216199B2 (ja) |
| EP (1) | EP1221646A3 (ja) |
| JP (1) | JP3592640B2 (ja) |
Families Citing this family (82)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6904441B2 (en) * | 2001-03-27 | 2005-06-07 | Hewlett-Packard Development Company, L.P. | Method and apparatus for providing file system access to a disk array |
| US7200715B2 (en) * | 2002-03-21 | 2007-04-03 | Network Appliance, Inc. | Method for writing contiguous arrays of stripes in a RAID storage system using mapped block writes |
| US7222129B2 (en) * | 2002-03-29 | 2007-05-22 | Canon Kabushiki Kaisha | Database retrieval apparatus, retrieval method, storage medium, and program |
| US7171396B2 (en) | 2002-04-04 | 2007-01-30 | Hewlett-Packard Development Company, L.P. | Method and program product for specifying the different data access route for the first data set includes storing an indication of the different access for the first data set providing alternative data access routes to a data storage |
| US6910117B2 (en) * | 2003-04-16 | 2005-06-21 | Megawin Technology Co., Ltd. | Method for detecting logical addresses of nonvolatile storage medium |
| JP2005135126A (ja) * | 2003-10-30 | 2005-05-26 | Hitachi Ltd | フラグメント防止ファイルシステム |
| US20050144396A1 (en) * | 2003-12-31 | 2005-06-30 | Eschmann Michael K. | Coalescing disk write back requests |
| US7529904B2 (en) * | 2004-03-31 | 2009-05-05 | International Business Machines Corporation | Storing location identifier in array and array pointer in data structure for write process management |
| US7213103B2 (en) * | 2004-04-22 | 2007-05-01 | Apple Inc. | Accessing data storage systems without waiting for read errors |
| US7577804B2 (en) * | 2004-10-06 | 2009-08-18 | International Business Machines Corporation | Detecting data integrity |
| US8495015B2 (en) | 2005-06-21 | 2013-07-23 | Apple Inc. | Peer-to-peer syncing in a decentralized environment |
| US7523146B2 (en) | 2005-06-21 | 2009-04-21 | Apple Inc. | Apparatus and method for peer-to-peer N-way synchronization in a decentralized environment |
| US20070250737A1 (en) * | 2005-09-13 | 2007-10-25 | Agere Systems Inc. | Method and Apparatus for Aligned Data Storage Addresses in a Raid System |
| US8521955B2 (en) | 2005-09-13 | 2013-08-27 | Lsi Corporation | Aligned data storage for network attached media streaming systems |
| JP2007242207A (ja) * | 2006-03-13 | 2007-09-20 | Fujitsu Ltd | ディスク装置の媒体スキャン方法 |
| US7797670B2 (en) * | 2006-04-14 | 2010-09-14 | Apple Inc. | Mirrored file system |
| KR100827677B1 (ko) * | 2006-06-20 | 2008-05-07 | 한국과학기술원 | 행렬 스트라이프 캐쉬를 이용한 ｒａｉｄ 시스템의 입출력성능 향상 방법 |
| JP2008009829A (ja) * | 2006-06-30 | 2008-01-17 | Fujitsu Ltd | ストレージ制御プログラム、ストレージ制御装置、ストレージ制御方法 |
| US7860826B2 (en) | 2006-08-04 | 2010-12-28 | Apple Inc. | Method and system for using global equivalency sets to identify data during peer-to-peer synchronization |
| US7904619B2 (en) | 2006-11-24 | 2011-03-08 | Sandforce, Inc. | System, method, and computer program product for reducing memory write operations using difference information |
| US7904672B2 (en) | 2006-12-08 | 2011-03-08 | Sandforce, Inc. | System and method for providing data redundancy after reducing memory writes |
| JP2010511963A (ja) * | 2006-12-08 | 2010-04-15 | サンドフォース インコーポレイテッド | 複数のストレージデバイスでのデータ冗長性 |
| US8918427B1 (en) * | 2006-12-29 | 2014-12-23 | Symantec Operating Corporation | Virtualization of file input/output operations |
| US7657769B2 (en) * | 2007-01-08 | 2010-02-02 | Marcy M Scott | N-way synchronization of data |
| US20080276124A1 (en) * | 2007-05-04 | 2008-11-06 | Hetzler Steven R | Incomplete write protection for disk array |
| KR101447188B1 (ko) | 2007-07-31 | 2014-10-08 | 삼성전자주식회사 | 플래시 메모리에 최적화된 입출력 제어 방법 및 장치 |
| US20110314216A1 (en) * | 2007-12-07 | 2011-12-22 | Thales | Method and Device for Reducing the Remanence of Data Stored on a Recording Medium |
| US7877626B2 (en) * | 2007-12-31 | 2011-01-25 | Datadirect Networks, Inc. | Method and system for disk storage devices rebuild in a data storage system |
| US9311184B2 (en) * | 2010-02-27 | 2016-04-12 | Cleversafe, Inc. | Storing raid data as encoded data slices in a dispersed storage network |
| CN102253810B (zh) * | 2010-05-17 | 2014-02-05 | 深圳市世纪光速信息技术有限公司 | 数据读取方法、装置和系统 |
| US8850114B2 (en) | 2010-09-07 | 2014-09-30 | Daniel L Rosenband | Storage array controller for flash-based storage devices |
| US9003153B2 (en) * | 2010-11-08 | 2015-04-07 | Greenliant Llc | Method of storing blocks of data in a plurality of memory devices in a redundant manner, a memory controller and a memory system |
| US10817502B2 (en) * | 2010-12-13 | 2020-10-27 | Sandisk Technologies Llc | Persistent memory management |
| US10817421B2 (en) * | 2010-12-13 | 2020-10-27 | Sandisk Technologies Llc | Persistent data structures |
| US9767098B2 (en) | 2012-08-08 | 2017-09-19 | Amazon Technologies, Inc. | Archival data storage system |
| US9563681B1 (en) | 2012-08-08 | 2017-02-07 | Amazon Technologies, Inc. | Archival data flow management |
| JP2013020504A (ja) * | 2011-07-12 | 2013-01-31 | Nec Corp | ディスクアレイ装置、論理ディスク制御方法および制御プログラム |
| US9417823B2 (en) * | 2011-07-12 | 2016-08-16 | Violin Memory Inc. | Memory system management |
| US9335939B2 (en) | 2011-07-12 | 2016-05-10 | Violin Memory Inc. | RAIDed memory system |
| TWI521343B (zh) | 2011-08-01 | 2016-02-11 | Toshiba Kk | An information processing device, a semiconductor memory device, and a semiconductor memory device |
| JP5762930B2 (ja) * | 2011-11-17 | 2015-08-12 | 株式会社東芝 | 情報処理装置および半導体記憶装置 |
| US8769196B1 (en) * | 2011-09-30 | 2014-07-01 | Lenovo (Singapore) Pte. Ltd. | Configuring I/O cache |
| JP5884602B2 (ja) * | 2012-03-30 | 2016-03-15 | 富士通株式会社 | ストレージ制御装置、およびストレージシステム |
| US9779035B1 (en) | 2012-08-08 | 2017-10-03 | Amazon Technologies, Inc. | Log-based data storage on sequentially written media |
| US9904788B2 (en) | 2012-08-08 | 2018-02-27 | Amazon Technologies, Inc. | Redundant key management |
| US8805793B2 (en) | 2012-08-08 | 2014-08-12 | Amazon Technologies, Inc. | Data storage integrity validation |
| US9830111B1 (en) | 2012-08-08 | 2017-11-28 | Amazon Technologies, Inc. | Data storage space management |
| US9225675B2 (en) | 2012-08-08 | 2015-12-29 | Amazon Technologies, Inc. | Data storage application programming interface |
| US8959067B1 (en) | 2012-08-08 | 2015-02-17 | Amazon Technologies, Inc. | Data storage inventory indexing |
| US9652487B1 (en) * | 2012-08-08 | 2017-05-16 | Amazon Technologies, Inc. | Programmable checksum calculations on data storage devices |
| US10120579B1 (en) | 2012-08-08 | 2018-11-06 | Amazon Technologies, Inc. | Data storage management for sequentially written media |
| CN104704569B (zh) * | 2012-12-19 | 2017-11-14 | 慧与发展有限责任合伙企业 | Nvram路径选择 |
| US9542101B2 (en) * | 2013-01-22 | 2017-01-10 | Avago Technologies General Ip (Singapore) Pte. Ltd. | System and methods for performing embedded full-stripe write operations to a data volume with data elements distributed across multiple modules |
| US9292228B2 (en) | 2013-02-06 | 2016-03-22 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Selective raid protection for cache memory |
| US10558581B1 (en) | 2013-02-19 | 2020-02-11 | Amazon Technologies, Inc. | Systems and techniques for data recovery in a keymapless data storage system |
| US8954657B1 (en) * | 2013-09-27 | 2015-02-10 | Avalanche Technology, Inc. | Storage processor managing solid state disk array |
| US10013217B1 (en) * | 2013-06-28 | 2018-07-03 | EMC IP Holding Company LLC | Upper deck file system shrink for directly and thinly provisioned lower deck file system in which upper deck file system is stored in a volume file within lower deck file system where both upper deck file system and lower deck file system resides in storage processor memory |
| US9547448B2 (en) * | 2014-02-24 | 2017-01-17 | Netapp, Inc. | System and method for transposed storage in raid arrays |
| US9471448B2 (en) * | 2014-12-10 | 2016-10-18 | Intel Corporation | Performing an atomic write operation across multiple storage devices |
| JP6367704B2 (ja) * | 2014-12-25 | 2018-08-01 | 株式会社バイオス | 記憶制御システム及び記憶制御装置 |
| KR20160083762A (ko) * | 2015-01-02 | 2016-07-12 | 삼성전자주식회사 | 스토리지 시스템에서의 매핑 테이블 관리 방법 및 이를 적용한 스토리지 시스템 |
| CN104714900B (zh) * | 2015-03-26 | 2019-07-05 | 百度在线网络技术（北京）有限公司 | 数据读取方法和装置 |
| US20160357462A1 (en) * | 2015-06-08 | 2016-12-08 | Samsung Electronics Co., Ltd. | Nonvolatile Memory Modules and Data Management Methods Thereof |
| TWI537728B (zh) * | 2015-09-23 | 2016-06-11 | 群聯電子股份有限公司 | 緩衝記憶體管理方法、記憶體控制電路單元及記憶體儲存裝置 |
| US11386060B1 (en) | 2015-09-23 | 2022-07-12 | Amazon Technologies, Inc. | Techniques for verifiably processing data in distributed computing systems |
| CN106557432B (zh) * | 2015-09-29 | 2019-08-06 | 群联电子股份有限公司 | 缓冲存储器管理方法、存储器控制电路单元及存储装置 |
| US9910786B2 (en) | 2015-11-03 | 2018-03-06 | Intel Corporation | Efficient redundant array of independent disks (RAID) write hole solutions |
| US9921914B2 (en) | 2015-11-03 | 2018-03-20 | Intel Corporation | Redundant array of independent disks (RAID) write hole solutions |
| US10423581B1 (en) * | 2016-03-30 | 2019-09-24 | EMC IP Holding Company LLC | Data storage system employing file space reclaim without data movement |
| CN105956090B (zh) * | 2016-04-27 | 2019-06-11 | 中国科学技术大学 | 一种基于i/o自适应的日志文件系统数据存储方法 |
| KR102585214B1 (ko) * | 2016-09-22 | 2023-10-05 | 삼성전자주식회사 | 가변 소거 유닛 크기를 가지는 스토리지 디바이스 및 이를 포함하는 레이드 스토리지 시스템 |
| US10203880B1 (en) * | 2016-09-29 | 2019-02-12 | EMC IP Holding Company LLC | Selectively operating data storage equipment in a “stripe write” mode and a “fill hole” mode |
| US9933945B1 (en) | 2016-09-30 | 2018-04-03 | EMC IP Holding Company LLC | Efficiently shrinking a dynamically-sized volume |
| US10372368B2 (en) * | 2016-10-13 | 2019-08-06 | International Business Machines Corporation | Operating a RAID array with unequal stripes |
| CN109213430B (zh) * | 2017-06-30 | 2021-09-10 | 伊姆西Ip控股有限责任公司 | 存储管理方法和系统 |
| US10643707B2 (en) * | 2017-07-25 | 2020-05-05 | Western Digital Technologies, Inc. | Group write operations for a data storage device |
| US10936441B2 (en) * | 2017-12-15 | 2021-03-02 | Microsoft Technology Licensing, Llc | Write-ahead style logging in a persistent memory device |
| CN111435286B (zh) * | 2019-01-14 | 2023-12-05 | 深圳市茁壮网络股份有限公司 | 一种数据存储方法、装置和系统 |
| CN112732163B (zh) * | 2019-10-14 | 2023-02-03 | 成都华为技术有限公司 | 一种数据校验方法和装置 |
| CN111026335A (zh) * | 2019-12-12 | 2020-04-17 | 天地伟业技术有限公司 | 一种优化存储性能提升硬盘兼容性的方法 |
| US20230068324A1 (en) * | 2021-08-30 | 2023-03-02 | Micron Technology, Inc. | Direct logical-to-physical address mapping |
| CN116339646B (zh) * | 2023-05-30 | 2023-08-11 | 西安中飞航空测试技术发展有限公司 | 飞行试验数据存储方法、装置、设备及存储介质 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2986880B2 (ja) | 1990-09-19 | 1999-12-06 | 株式会社日立製作所 | アレイディスク |
| KR970004255B1 (ko) | 1992-12-07 | 1997-03-26 | 인터내셔널 비지네스 머신즈 코포레이션 | 병렬 디스크 상에서의 고속 데이타 갱신 방법 |
| US5860091A (en) * | 1996-06-28 | 1999-01-12 | Symbios, Inc. | Method and apparatus for efficient management of non-aligned I/O write request in high bandwidth raid applications |
| JPH1153235A (ja) * | 1997-08-08 | 1999-02-26 | Toshiba Corp | ディスク記憶装置のデータ更新方法、ならびにディスク記憶制御システム |
| JPH11119923A (ja) * | 1997-10-20 | 1999-04-30 | Fujitsu Ltd | データアクセス制御装置及びデータアクセス制御プログラムを記録した媒体 |
| JP3616487B2 (ja) * | 1997-11-21 | 2005-02-02 | アルプス電気株式会社 | ディスクアレイ装置 |
| JPH11194899A (ja) * | 1997-12-26 | 1999-07-21 | Toshiba Corp | ディスク記憶システム及び同システムに適用するデータ更新方法 |
| JP2000047832A (ja) * | 1998-07-27 | 2000-02-18 | Toshiba Corp | ディスクアレイ装置、及びそのデータ制御方法 |
| US6134586A (en) * | 1998-07-31 | 2000-10-17 | Philips Electronics N.A. Corp. | Striping data across disk zones |
| US6883031B1 (en) * | 2000-09-14 | 2005-04-19 | Lucent Technologies Inc. | RUSH-DCS—an adaptable high performance interface for services |
| US6606694B2 (en) * | 2000-12-22 | 2003-08-12 | Bull Hn Information Systems Inc. | Write logging in mirrored disk subsystems |
-
2001
- 2001-01-09 JP JP2001001137A patent/JP3592640B2/ja not_active Expired - Fee Related
- 2001-09-13 EP EP01122025A patent/EP1221646A3/en active Pending
- 2001-09-18 US US09/954,303 patent/US7216199B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002207572A (ja) | 2002-07-26 |
| US7216199B2 (en) | 2007-05-08 |
| US20020091903A1 (en) | 2002-07-11 |
| EP1221646A3 (en) | 2008-07-23 |
| EP1221646A2 (en) | 2002-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3592640B2 (ja) | ディスク制御システムおよびディスク制御方法 | |
| US5701516A (en) | High-performance non-volatile RAM protected write cache accelerator system employing DMA and data transferring scheme | |
| US8977781B1 (en) | Computer system | |
| US20160342545A1 (en) | Data memory device | |
| JP4186602B2 (ja) | ジャーナルログを利用した更新データ書込方法 | |
| US5446855A (en) | System and method for disk array data transfer | |
| US6341342B1 (en) | Method and apparatus for zeroing a transfer buffer memory as a background task | |
| JP3590381B2 (ja) | ディスクアレイ装置及び同装置におけるデータ更新方法 | |
| US8131969B2 (en) | Updating system configuration information | |
| US7100074B2 (en) | Storage system, and control method, job scheduling processing method, and failure handling method therefor, and program for each method | |
| US8719524B2 (en) | Storage system including flash drives for improving performance by controlling data caching | |
| US20080294698A1 (en) | Foresight data transfer type hierachical storage system | |
| US6148369A (en) | Method and apparatus for providing logical devices spanning several physical volumes | |
| EP2220551A1 (en) | Improved system and method for efficient updates of sequential block storage | |
| US9916249B2 (en) | Space allocation in a multi-grained writeback cache | |
| US7032093B1 (en) | On-demand allocation of physical storage for virtual volumes using a zero logical disk | |
| CN100351767C (zh) | 适配器读取和写入系统存储器的方法和系统 | |
| US20110082950A1 (en) | Computer system and computer system input/output method | |
| US9189407B2 (en) | Pre-fetching in a storage system | |
| JP4053208B2 (ja) | ディスクアレイ制御装置 | |
| US7484038B1 (en) | Method and apparatus to manage storage devices | |
| EP3293625B1 (en) | Method and device for accessing file, and storage system | |
| WO2017072868A1 (ja) | ストレージ装置 | |
| US10282301B2 (en) | Method and system for hardware accelerated read-ahead caching | |
| US20050038958A1 (en) | Disk-array controller with host-controlled NVRAM |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040326 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040525 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040615 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040810 |
|
| 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: 20040824 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040825 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070903 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080903 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090903 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100903 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100903 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110903 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120903 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120903 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130903 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |