JP2017167740A - ストレージ、ストレージシステム - Google Patents

Abstract

【課題】ライト効率を向上できるストレージ、ストレージシステムを提供する。
【解決手段】実施形態によれば、ストレージ１Ａは、外部から指定されるキーとキーに対応づけられたバリューとを記憶する記憶媒体１０と、記憶媒体にキーとライトデータであるバリューとをライトするコントローラ１３０と、を具備する。コントローラ１３０は、ライトコマンドを受信するコマンド受信部５１と、第１パラメータＰ１を含む第１拡張ライトコマンドＷ１を受信する第１拡張コマンド受信部１１１とを備え、第１パラメータＰ１は、ライトコマンドに基づくライトデータへの第１アクセス単位よりも第１拡張ライトコマンドに基づく第１ライトデータへの第２アクセス単位の方が大きく、前記第２アクセス単位が複数の前記第１アクセス単位により構成される１単位であることを示す。
【選択図】図１

Description

本実施形態は、概して、ストレージ、ストレージシステムに関する。

近年、キーと当該キーに対応づけられたバリューとを記憶媒体に記憶したストレージおよび当該ストレージを備えるストレージシステムが知られている。

米国特許第８６２６９８９号明細書

ライト効率を向上できるストレージ、ストレージシステムを提供する。

本実施形態によれば、ストレージは、外部から指定されるキーと前記キーに対応づけられたバリューとを記憶する記憶媒体と、前記記憶媒体に、前記キーとライトデータである前記バリューとをライトするコントローラと、を具備し、前記コントローラは、ライトコマンドを受信するコマンド受信部と、第１パラメータを含む第１拡張ライトコマンドを受信する第１拡張コマンド受信部とを備え、前記第１パラメータは、前記ライトコマンドに基づくライトデータへの第１アクセス単位よりも前記第１拡張ライトコマンドに基づく第１ライトデータへの第２アクセス単位の方が大きく、前記第２アクセス単位が複数の前記第１アクセス単位で構成された１単位であることを示し、前記コントローラは、前記第１拡張コマンド受信部で前記外部から送信された前記第１拡張ライトコマンドを受信すると、前記第１パラメータに基づき前記第１ライトデータを１単位として前記記憶媒体にライトする。

第１実施形態に係るストレージシステムを示すブロック図。 記憶媒体に格納されるバリューおよびキーを説明するための図。 第１拡張ライトコマンド（ＲＨＤ ＦＩＳデータ構造）を示す図。 第１拡張ライトコマンドが有するパラメータのビットを示す図。 第１拡張ライトコマンドが有するパラメータを説明するための図。 第１実施形態に係るストレージシステムのライト（予告通知）処理を示すフローチャート。 第１実施形態に係るストレージシステムのライト（予告通知）処理を示すタイミングチャート。 ホストが取り扱うデータサイズと比較例および第１実施形態に係るストレージシステムがライトする記録媒体の記憶状態を説明するための図。 第２実施形態に係るストレージシステムを示すブロック図。 第２拡張ライトコマンド（ＲＨＤ ＦＩＳデータ構造）を示す図。 第２拡張ライトコマンドが有するパラメータのビットを示す図。 第２拡張ライトコマンドが有するパラメータを説明するための図。 第２実施形態に係るストレージシステムのライト（予告通知）処理を示すフローチャート。 第２実施形態に係るストレージシステムのライト（予告通知）処理を示すタイミングチャート。 ホストが取り扱うデータサイズと比較例および第２実施形態に係るストレージシステムがライトする記録媒体の記憶状態を説明するための図。 第３実施形態に係るストレージシステムを示すブロック図。 第３実施形態に係るストレージシステムのＰＵＴ（ライト）動作を示すブロック図。

以下、図面を参照して、発明の実施形態について説明する。この説明においては、全図にわたり共通の部分には共通の参照符号を付す。
（第１実施形態）
［１．構成］
１−１．ストレージシステム
図１を用い、第１実施形態に係るストレージシステム１Ａについて説明する。ストレージシステム１Ａは、記憶媒体である磁気ディスク１０を備え、ＩＰ（Internet Protocol）等のネットワーク３０１を介して外部のストレージアクセスクライアント（以下、「クライアント」）３００が、ＡＰＩ（Application Programming Interface）２３０を用いてアクセス可能であるように構成される。ここで、ＡＰＩとは、あるプロセッサ（ここでは、ＣＰＵ２１０）のプログラムの機能等を、外部（ここでは、クライアント３００）のプログラムから呼び出して利用するための手順やデータ形式などを定めたインタフェースをいう。例えば、クライアント３００は、ＡＰＩ２３０を用いて、定められた所定の手順（例えば、ＣＰＵ２１０の汎用的なリード機能を呼び出すためのコマンドを指定すること）に従って、ストレージシステム１Ａにリード要求を行うことができる。リード要求を受信したストレージシステム１Ａは、クライアント３００からのリード要求に従い、リードデータを返信する。このように、クライアント３００は、共通して利用する汎用的な機能を、ＡＰＩ２３０に定められた所定の手順に従ってＣＰＵ２１０から呼び出し、当該機能を利用することができる。従って、クライアント３００は、当該汎用的な機能を利用するための複雑なプログラム等をいちから作成することが不要となり、リード要求等の汎用的な機能を利用するための簡単な命令をクライアント３００が知っていれば、ストレージシステム１Ａにアクセスすることができる。

また、ストレージシステム１Ａは、磁気ディスク１０にキーＫと当該キーＫに対応づけられたバリューＶとを記憶する。
図２に示すように、バリューＶは、クライアント３００からライト要求またはリード要求される情報である。一例として、バリューＶは、クライアント３００から送信された動画データ、画像データ、およびテキストデータ等のユーザデータである。

図２に示すように、キーＫは、バリューＶ以外の情報であって、キーＫと対応するバリューＶに関連して意味付けられた情報である。一例として、キーＫは、ＩＤ情報、構成ブロック数、組織名、ファイル名、ファイル形式等を含む。ＩＤ情報は、対応づけられたバリューＶを識別する固有の識別情報であって、例えば2150333等である。構成ブロック数は、バリューＶを構成するブロックの数を示す情報である。組織名は、例えば、ＨＤＤ１等である。ファイル名は、例えば、File_A等である。なお、これらのキーＫを構成する情報（構成情報）は、上記のものに限定されない。例えば、キーＫを構成する構成情報は、バリューＶのサイズ、タイトル、および注釈等のその他のバリューＶの属性データを含んでもよい。

上記説明したようなストレージシステム（ＫＶ型ストレージシステム）１Ａでは、任意のサイズの識別情報であるキーＫと、当該キーＫに対応づけられた任意のサイズのデータＶとが、ストレージ１００に記憶される。上記構成によれば、クライアント３００がキーＫを指定すると、キーＫに関連付けられたバリューＶを、ＰＵＴ（ライト）、ＧＥＴ（リード）およびＤＥＬＥＴＥ（イレーズ）することが可能となる。この詳細については、後述する。

図１に戻り、ストレージシステム１Ａは、外部のクライアント３００からの要求を受け付けるホスト２００と、ホスト２００により管理される複数のストレージ１００とを備える。
ホスト２００は、ストレージシステム１Ａとクライアント３００とを含む全体から見れば、クライアント３００と複数のストレージ１００とが互いにアクセスを行うための仲立ちを行うブリッジ部である。ホスト２００は、例えば、サーバ、パーソナルコンピュータ、またはインターフェースデバイス等である。ここで、ホスト２００とは、クライアント３００とストレージ１００とが互いにアクセスを行うための制御を行うものをいう。第１実施形態において、ホスト２００は、複数のストレージ１００を集中的に制御し、クライアント３００からの要求に応答する。ホスト２００に備えられるアプリケーション等は、上記ＡＰＩ２３０を用いて各ストレージ１００にアクセスする。

ホスト２００は、ストレージＩ／Ｆを介して各ストレージ１００を制御し、ストレージシステム１Ａの全体の動作（例えば、リード、ライト等）を制御するＣＰＵ（Central Processing Unit）２１０を備える。ＣＵＰ２１０は、ライトコマンド、リードコマンド等の所定のコマンドを生成するコマンド生成部２０１と、ＫＶ管理部２２０と、ＡＰＩ２３０とを備える。

コマンド生成部２０１は、拡張ライトコマンド（第１拡張ライトコマンド）Ｗ１を生成（発行）する第１拡張ライトコマンド生成部（第１発行部）２１１を備える。拡張ライトコマンドＷ１は、ストレージＩ／Ｆにより定義されるライトコマンドが拡張されたコマンドであって、少なくとも第１パラメータ（情報、指示）Ｐ１を含む。拡張ライトコマンドＷ１の詳細については、後述する。

ＫＶ管理部２２０は、クライアント３００からの指令を処理する。具体的には、ＫＶ管理部２２０は、クライアント３００から受信した一対のキーおよびバリュー（Ｋ,Ｖ）に基づき、ＳＳＤ１にキーＫを記憶させ、ＨＤＤ１またはＨＤＤ２にバリューＶおよび当該バリューＶの位置を示すＬＢＡ（Logical Block Address）を記憶させる。そのため、ＫＶ管理部２２０は、キーＫとＬＢＡとの対応関係を示す所定のテーブル等を用いてもよい。

第１実施形態では、ストレージ１００として、記憶媒体である磁気ディスク（以下、「ディスク」）１０を備えるＨＤＤ１を一例に挙げて説明する。
ＨＤＤ１は、後述するヘッドディスクアセンブリ（head-disk assembly：ＨＤＡ）と、ドライバＩＣ２０と、ヘッドアンプ集積回路（以下、「ヘッドアンプＩＣ」）３０と、揮発性メモリ７０と、不揮発性メモリ８０と、バッファメモリ（キャッシュメモリ）９０と、１チップの集積回路からなるシステムコントローラ１３０とを備える。ＨＤＤ１は、ホスト２００と、デバイスＩ／ＦであるＳＡＴＡ Ｉ／Ｆを介して接続される。ＨＤＤ１は、ホスト２００から転送されたライトデータをディスク１０にライトし、ディスク１０からリードしたデータをホスト２００に転送する。

ＨＤＡは、ディスク１０と、スピンドルモータ（ＳＰＭ）１２と、ヘッド１５を搭載するアーム１３と、ボイスコイルモータ（ＶＣＭ）１４とを有する。ディスク１０は、スピンドルモータ１２により回転する。アーム１３およびＶＣＭ１４は、アクチュエータを構成する。アクチュエータは、ＶＣＭ１４の駆動により、アーム１３に搭載されるヘッド１５をディスク１０上の所定の位置まで移動させる。ディスク１０およびヘッド１５は、２つ以上であってもよい。

ヘッド１５は、先端部に設けられたライトヘッド１５Ｗおよびリードヘッド１５Ｒを備える。ライトヘッド１５Ｗは、ディスク１０の表面に対して垂直方向の磁界を発生させ、ディスク１０の表面のトラックにライトデータをライトする。リードヘッド１５Ｒは、ディスク１０のトラックに記録されたデータをリードする。

ドライバＩＣ２０は、システムコントローラ１３０（詳細には、後述するＭＰＵ６０）の制御に従い、ＳＰＭ１２およびＶＣＭ１４の駆動を制御する。
ヘッドアンプＩＣ３０は、リードアンプおよびライトドライバを有する。リードアンプは、リードヘッド１５Ｒにより読み出されたリード信号を増幅して、リード／ライト（Ｒ／Ｗ）チャネル４０に伝送する。ライトドライバは、Ｒ／Ｗチャネル４０から出力されるライトデータに応じたライト電流をライトヘッド１５Ｗに伝送する。

揮発性メモリ７０は、電力供給が断たれると保存しているデータが失われる半導体メモリである。揮発性メモリ７０は、ストレージシステム１Ａの各部での処理に必要なデータ等を格納する。揮発性メモリ７０は、例えば、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）である。

不揮発性メモリ８０は、電力供給が断たれても保存しているデータを保持する半導体メモリである。不揮発性メモリ８０は、例えば、フラッシュＲＯＭ（Flash Read Only Memory : FROM）である。
バッファメモリ９０は、ディスク１０とホスト２００との間で送受信されるデータ等を一時的に保持する半導体メモリである。なお、バッファメモリ９０は、揮発性メモリ７０と一体に配置されていてもよい。バッファメモリ９０は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）、ＳＤＲＡＭ、ＦｅＲＡＭ（Ferroelectric Random Access memory）、およびＭＲＡＭ（Magnetoresistive Random Access Memory）等である。

システムコントローラ（メモリコントローラ）１３０は、例えば、複数の素子が単一チップに集積されたSystem-on-a-Chip(SoC)と称される大規模集積回路（ＬＳＩ）を用いて実現される。システムコントローラ１３０は、リード／ライト（Ｒ／Ｗ）チャネル４０と、ハードディスクコントローラ（ＨＤＣ）５０と、マイクロプロセッサ（ＭＰＵ）６０とを含む。

Ｒ／Ｗチャネル４０は、リードデータおよびライトデータの信号処理を実行する。Ｒ／Ｗチャネル４０は、リードデータの信号品質を測定する回路、又は機能を有する。
ＨＤＣ５０は、ＭＰＵ６０からの指示に応じて、ホスト２００とＲ／Ｗチャネル４０との間のデータ転送を制御する。ＨＤＣ５０は、拡張ライトコマンド認識部（拡張コマンド受信部）１１１を有するコマンド認識部（コマンド受信部）５１を備える。コマンド認識部５１は、ライトコマンドおよびリードコマンド等の拡張されていないコマンドを認識（受信）する。拡張ライトコマンド認識部１１１は、拡張ライトコマンドＷ１を認識（受信）する。認識（受信）結果に基づき、ＭＰＵ６０は、後述するようにライトデータをディスク１０にライトする。

ＭＰＵ６０は、ＨＤＤ１の各部を制御し、全体（ここでの「全体」とは、ホスト２００を除き、ＭＰＵ６０が制御するストレージ（ＨＤＤ１）１００の全体をいう。）の動作を制御するメインコントローラである。ＭＰＵ６０は、例えば、ドライバＩＣ２０を介してＶＣＭ１４を制御し、ヘッド１５の位置決めを行うサーボ制御を実行する。

なお、ＨＤＤ２の構成は、ＨＤＤ１と同様である。また、ホスト２００やＨＤＤ１の構成は、上述したものに限られない。例えば、ＫＶ管理テーブル２４０やテーブルＴ１のように、テーブル形式に限定されず、所定の関数や数式、および所定のマッピング形式等であってもよい。これらが配置される場所も限定されない。

また、ＳＳＤ１は、記憶媒体としてＮＡＮＤ型フラッシュメモリやＮＯＲ型フラッシュメモリ等のフラッシュメモリを備える。フラッシュメモリは、ワード線とビット線との交際位置に複数のメモリセルが配置されたメモリセルアレイを備える。各メモリセルは、制御ゲートと浮遊ゲートを備える。各メモリセルは、ワード線に接続される制御ゲートの電圧制御に従い、浮遊ゲートに電子が注入されることで、データを不揮発に記憶する。その他の構成の詳細な説明については、省略する。

１−２．拡張ライトコマンドＷ１
図３は、拡張ライトコマンドＷ１を示す図である。ここでは、拡張ライトコマンドＷ１は、ＳＡＴＡ Ｉ／Ｆのライトコマンドの拡張例として示す。具体的には、拡張ライトコマンドＷ１は、ＳＡＴＡ Ｉ／Ｆのコマンド発行に使用するＲＨＤ（Register Host to Device）のＦＩＳ（Frame Instruction Structure）として示される。拡張ライトコマンドＷ１は、現在使用されていない未使用領域（Dword4, Bit7:0）に、第１パラメータＰ１が追加される。

図３では、ＳＡＴＡ（SerialATA）で定義されているRegister Host to Device FISの構成と、この構成に添った形での拡張ライトコマンドＷ１の実装方法とが示されている。各フィールドのうち、（Dword4, bit31:0）として定義されているAuxiliary(31:0)フィールドは、この例では未使用領域である。

ここで、拡張ライトコマンドＷ１は、未使用領域であるAuxiliary（Dword4, Bit7:0）に埋め込まれた第１乃至第３パラメータＰ１からＰ３を有し、少なくとも第１パラメータＰ１は、有効な（または認識される）状態（ビット“１”状態）で埋め込まれる。

図４に示すように、未使用領域であるAuxiliary（Dword4, Bit7:0）に埋め込まれた各パラメータのビット状態は、次の通りである。
Auxiliary（Dword4, Bit7）に埋め込まれる第２パラメータＰ２は、ビット“０”である。Auxiliary（Dword4, Bit6）に埋め込まれる第１パラメータＰ１は、ビット“１”である。Auxiliary（Dword4, Bit5:0）に埋め込まれる第３パラメータＰ１は、ビット“００００００”である。そのため、拡張ライトコマンドＷ１の各パラメータの説明は、図５に示す通りである。

図５に示すように、第１パラメータＰ１は、ビット“１”である。そのため、この拡張ライトコマンドＷ１でライトするライトデータＷＤ１は、１単位を形成し、必ず転送されるブロックの先頭から最後まで連続してアクセスされる。換言すれば、第１パラメータＰ１は、コマンド認識部５１で認識されるライトコマンドに基づくライトデータへの第１アクセス単位（セクタ単位／ブロック単位）よりも拡張ライトコマンドＷ１によるライトデータＷＤ１への第２アクセス単位（後述するＵＷＤ１等）の方が大きく、第２アクセス単位が複数の第１アクセス単位により構成された１つのアクセス単位であることを示す。そのため、形成した１単位である第２アクセス単位の途中からアクセス（リード／ライト）されることはない。

第２パラメータＰ２は、ビット“０”である。そのため、本実施形態では、第２パラメータＰ２は、未使用である（有効ではない）。換言すれば、この拡張ライトコマンドＷ１の後に続くライトデータはないことを示す。
第３パラメータＰ３は、ビット“００００００”である。そのため、本実施形態では、第３パラメータＰ３は、未使用である（有効ではない）。換言すれば、この拡張ライトコマンドＷ１のＴＡＧ番号（ＮＣＱ（Native Command Queuing）の場合）は示されないことを示す。第２，第３パラメータＰ２，Ｐ３の詳細については、第２実施形態で詳細に説明する。

なお、ここでは、ホスト２００が、第１パラメータＰ１を用いて「この拡張ライトコマンドＷ１でライトするライトデータＷＤ１は、１単位を形成し、必ず転送されるブロックの先頭から最後まで連続してアクセスされる」ことを、ストレージ１００に通知する場合を一例に挙げて説明する。しかし、当該内容を通知する方法や手段は、第１実施形態で示したもの限定されるものではなく、他の方法や手段でもよい。例えば、新たな機能として定義し、既存コマンド（ライトコマンド等）とは別のコマンドコードを割り当て、ストレージ１００に通知してもよい。

また、ストレージ１００のストレージＩ／Ｆは、ＳＡＴＡ Ｉ／Ｆに限定されない。例えば、ＳＡＳ Ｉ／Ｆについても同様の情報を追加して、イニシエータ（ホスト）からターゲット（ストレージ）に対して「必ず先頭から連続したデータとしてアクセスされる」等を通知する手段を設けることも可能である。この際、当該指示内容を既存のコマンドの未使用領域や予約領域に追加してもよいし、新たなコマンド定義してもよい。ＳＡＳ Ｉ／ＦのコマンドはＣＤＢ（command descriptor block）の形式で規定され、ＣＤＢのバイト数はある程度増やすことが可能である。そのため、ＳＡＴＡ Ｉ／Ｆに比べ、ＳＡＳ Ｉ／Ｆの方が、追加方法および追加手段の点で柔軟に対応可能である。

［２．動作］
２−１．ライト（予約通知）処理
図６および図７を用い、ストレージシステム１Ａのライト（予約通知）処理について説明する。ここでは、ホスト２００が、クライアント３００から１単位のデータであるバリューＶ１（ライトデータＷＤ１（転送ブロック数：１〜ｎ））のライト要求を受けた場合を一例に挙げる。

図６のステップＳ１１において、ホスト２００の拡張ライトコマンドＷ１生成部２１１は、第１パラメータＰ１が埋め込まれた拡張ライトコマンドＷ１を生成（発行）し、生成した拡張ライトコマンドＷ１をストレージ１００であるＨＤＤ１に通知する。上記の通り、第１パラメータＰ１は、「拡張ライトコマンドＷ１でライトするライトデータＷＤ１は、１単位を形成し、転送ブロックの先頭から最後まで連続してアクセスされること」を示すパラメータである。例えば、図７の時刻ｔ１において、ホストが送信するRegHDの内容(転送ブロック数ｎ等)に、第１パラメータＰ１を追加して送信する。

ステップＳ１２において、ストレージ１００の拡張ライトコマンドＷ１認識部１１１は、通知された拡張ライトコマンドＷ１の記述内容を認識する。
ステップＳ１３において、ホスト２００のＫＶ管理部２２０は、拡張ライトコマンドＷ１に基づくライトデータＷＤ１を、ストレージ１００に送信する。例えば、図７の時刻ｔ２において、ＫＶ管理部２２０は、拡張ライトコマンドＷ１に基づくライトデータＷＤ１（転送ブロック数：１〜ｎ）を、ＨＤＤ１に送信する。

ステップＳ１４において、ストレージ１００のＭＰＵ６０は、認識した第１パラメータＰ１に基づき、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを連続した１単位として、ディスク１０にライトする。例えば、図７の時刻ｔ３からｔ４において、ＨＤＤ１のＭＰＵ６０は、第１パラメータＰ１に基づき、ライトデータＷＤ１を、先頭ブロック１から最終ブロックｎまで連続した１単位ＵＷＤ１として、ディスク１０にライトする。この際、ＭＰＵ６０は、ＨＤＤ１において都合のよい書き方でライトデータＷＤ１をディスク１０にライトする。そのため、ホストインターフェースのセクタ／ブロックの区切りを無視することができる。具体的には、ＭＰＵ６０は、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを、サーボ領域ＳＶを除いて、３つの小単位ＵＷＤ１ａ〜ＵＷＤ１ｃから構成される連続した１単位ＵＷＤ１として、ディスク１０にライトすることができる。

このように、第１実施形態に係る拡張プロトコルの使用の可否については、IDENTIFY DEVICEコマンドによって「事前通知が可能な拡張ライトコマンドＷ１に対応している」という内容を(IDENTIFY DEVICEコマンドで交換する情報の一つとして)提示する。ホスト２００およびデバイス１００の双方が対応している場合に、追加情報（第１乃至第３パラメータＰ１〜Ｐ３）を取り扱う。

なお、その他のストレージ１００であるＨＤＤ２やＳＳＤ１等のライト処理ついても、上記ＨＤＤ１と実質的に同様である。そのため、その詳細な説明を省略する。
［３．作用効果］
以上説明したように、第１実施形態に係るストレージシステム１Ａの構成および動作によれば、少なくとも下記（１）および（２）の効果が得られる。

（１）余剰領域が不要になることで実質的なライト容量を増大でき、ライト効率を向上できる。
拡張ライトコマンドＷ１生成部２１１は、少なくとも第１パラメータＰ１が埋め込まれた拡張ライトコマンドＷ１を生成し、生成した拡張ライトコマンドＷ１をストレージ１００であるＨＤＤ１に通知する（図６のＳ１１、図７の時刻ｔ１）。拡張ライトコマンドＷ１認識部１１１は、通知された拡張ライトコマンドＷ１の記述内容を認識する（図６のＳ１２）。

ＫＶ管理部２２０は、拡張ライトコマンドＷ１に基づくライトデータＷＤ１を、ストレージ１００に送信する（図６のＳ１３、図７の時刻ｔ２）。ＭＰＵ６０は、認識した第１パラメータＰ１に基づき、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを連続した１単位として、ディスク１０にライトする（図６のＳ１４、図７の時刻ｔ３〜ｔ４）。

そのため、ＭＰＵ６０は、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを、サーボ領域ＳＶを除いて、３つの小単位ＵＷＤ１ａ〜ＵＷＤ１ｃから構成される連続した１単位ＵＷＤ１として、ディスク１０にライトすることができる。
図８を用いて、上記についてより具体的に説明する。

図８（ｂ）に示すように、ＳＡＴＡ Ｉ／ＦやＳＡＳ Ｉ／Ｆや等の「ブロックアクセス型インターフェース規格」では、データのアクセスサイズを示す単位としてセクタやブロックが用いられる。例えば、ＳＡＴＡ Ｉ／Ｆにおけるブロックサイズは、４ＫＢである。そのため、ストレージ１００は、セクタ／ブロックを１単位として、任意のセクタ／ブロックに対してアクセス（ライト／リード）を行う必要がある。

一方、図８（ａ）に示すように、ライトしたいデータを扱うホスト２００のアプリケーションは、上記で記述したセクタ／ブロックのサイズよりも大きなサイズのデータ（バリュー）Ｖ１を、データの１単位として、かつデータＶ１について必ず先頭ＨＡＤＤから最後ＦＡＤＤまで連続してアクセスを行うことが明らかである、という場合がある。

そこで、図８（ｃ）に示すように、このような場合、ストレージ１００のディスク１０に、セクタ／ブロックのサイズよりも大きなサイズを記録単位とすること（Long sector）ができれば、ディスク１０上の無駄な余剰領域ＲＡをなくし、データをライトできる。

しかしながら、図８（ｄ１）に示す比較例の場合、既存インターフェース規格の「任意のセクタ／ブロックに対してリードアクセスおよびライトアクセスを行う必要がある」という制限がある。この制限のため、セクタ／ブロックよりも大きなサイズを１単位としたライトが行えない状況がある。具体的には、比較例の場合、４ＫＢ単位でのリード／ライトに対応するため、プリアンブル等のための斜線で示す余剰領域ＲＡが４ＫＢごとに必要となる。そのため、ディスク１０に６４ＫＢより多くの記録領域が必要となる。さらに、新たなインターフェース規格において、上記状況を考慮した規格は存在するが、まだ一般に普及している状況ではない。

図８（ｄ２）に示す第１実施形態の場合、上記状況に鑑み、セクタ／ブロックのサイズより大きなサイズであるライトデータＷＤ１をライトすることが可能であり、かつライト効率を向上することができる。例えば、第１実施形態の場合、上記４ＫＢごとの余剰領域が不要となる。そのため、ディスク１０に必要なサイズを実質的に６４ＫＢ程度とでき、ホストアプリケーションが必要なデータＶ１のサイズと同程度とすることができる。比較例と比べ、第１実施形態は、斜線で示す記憶領域１０Ａを削減することができる。換言すると、第１実施形態は、上記４ＫＢごとの余剰領域が不要となるため、ディスク１０の実質的な記憶容量を増大することができる。

このように、第１実施形態によれば、“連続した１単位のデータＶ１について、その途中の一部分へのアクセスが行われる事は無い”という事が前提として保証される。そのため、各ストレージ１００の記憶媒体（ディスク１０やフラッシュメモリ）ごとに異なる効率的なライトサイズ／ライト方法を選択し、データをライトできる。

（２）ライト速度およびリード速度を向上でき、応答速度を向上できる。
上述の通り、第１実施形態に係るストレージシステム１Ａは、上記４ＫＢごとの余剰領域が不要となるため、ライト速度を向上できる。さらに、データＷＤ１をリードする際にも、ホスト２００は、データＷＤ１を１単位（１ＵＷＤ１）として、リードすることができる。そのため、リード速度をも向上することができる。

このように、第１実施形態に係るストレージシステム１Ａは、システム全体の応答速度の向上やデータ転送速度を高速化できる。そのため、第１実施形態によれば、ストレージ１００の記録再生速度を向上できる点でも有利である。
（第２実施形態）
第２実施形態に係るストレージシステム１Ｂについて説明する。この説明において、上記第１実施形態と重複する部分の詳細な説明を省略する。

［構成］
ストレージシステム
図９に示すように、第２実施形態に係るストレージシステム１Ｂは、ホスト２００のコマンド生成部２０１が拡張ライトコマンドＷ２生成部２１２を更に備え、ストレージ１００のコマンド認識部５１が拡張ライトコマンドＷ２認識部１１２を更に備える点で、第１実施形態と相違する。

拡張ライトコマンドＷ２生成部（第２発行部）２１２は、第１乃至第３パラメータＰ１〜Ｐ３が埋め込まれた拡張ライトコマンド（第２拡張ライトコマンド）ＷＤ２を生成（発行）し、生成した拡張ライトコマンドＷ２をストレージ１００であるＨＤＤ１に通知する。

拡張ライトコマンドＷ２認識部１１２は、拡張ライトコマンドＷ２を認識する。認識結果に基づき、ＭＰＵ６０は、後述するようにライトデータをディスク１０にライトする。
拡張ライトコマンドＷ２
図１０は、拡張ライトコマンドＷ２を示す図である。ここでは、拡張ライトコマンドＷ２は、ＳＡＴＡ Ｉ／Ｆでのコマンドの拡張例として示す。拡張ライトコマンドＷ２は、現在使用されていない未使用領域（Dword4, Bit7:0）に、第１乃至第３パラメータＰ１〜Ｐ３が追加される。未使用領域であるAuxiliary（Dword4, Bit7:0）に埋め込まれた第１乃至第３パラメータＰ１〜Ｐ３は、有効な（認識される）状態で埋め込まれる。

図１１に示すように、未使用領域であるAuxiliary（Dword4, Bit7:0）に埋め込まれた各パラメータの状態は、次の通りである。
Auxiliary（Dword4, Bit7）に埋め込まれる第２パラメータＰ２は、ビット“１”である。Auxiliary（Dword4, Bit6）に埋め込まれる第１パラメータＰ１は、ビット“１”である。Auxiliary（Dword4, Bit5:0）に埋め込まれる第３パラメータＰ１は、ビット“０１１０１０”である。そのため、拡張ライトコマンドＷ２の各パラメータの説明は、図１２に示す通りである。

図１２に示すように、第１パラメータＰ１は、ビット“１”である。そのため、この拡張ライトコマンドＷ２でライトするライトデータＷＤ２は、１単位を形成し、必ず転送されるブロックの先頭から最後まで連続してアクセスされる。換言すれば、第１パラメータＰ１は、拡張ライトコマンドＷ２によりライトされたライトデータＷＤ２は、形成した１単位の途中からアクセス（リード／ライト）されることはないことを示す。

第２パラメータＰ２は、ビット“１”である。そのため、第２パラメータＰ２は、この拡張ライトコマンドＷ２の後に続いて通知される拡張ライトコマンドＷ１のライトデータＷＤ１についても、ライトデータＷＤ２と連続してアクセスされることを示す。
第３パラメータＰ３は、ビット“０１１０１０”である。そのため、第３パラメータＰ３は、この拡張ライトコマンドＷ２の後に続いて通知される拡張ライトコマンドＷ１のＴＡＧ番号（ＮＣＱコマンドの場合）を示す。なお、第３パラメータＰ３は、アクセスした情報を特定するための情報であるＴＡＧ番号に限られない。第３パラメータは、後続する拡張ライトコマンドを識別するＩＤ情報やその他の認識情報等であればよい。

その他の構成については、第１実施形態と実質的に同様であるため、その詳細な説明を省略する。
［動作］
ライト（予約通知）処理
図１３および図１４を用い、ストレージシステム１Ｂのライト（予約通知）処理について説明する。ここでは、ホスト２００が、クライアント３００から１単位のデータであるバリューＶ２（ライトデータＷＤ２およびＷＤ１（転送ブロック数：１〜ｍおよび１〜ｎ））のライト要求を受けた場合を一例に挙げる。

図１３のステップＳ２１において、ホスト２００の拡張ライトコマンドＷ２生成部２１２は、第１乃至第３パラメータＰ１〜Ｐ３が埋め込まれた拡張ライトコマンドＷ２を生成し、生成した拡張ライトコマンドＷ２をストレージ１００であるＨＤＤ１に通知する。第１乃至第３パラメータＰ１〜Ｐ３の機能は、上記の通りである。例えば、図１４の時刻ｔ１において、ホストが送信するRegHDの内容(転送ブロック数ｎ等)に、第１乃至第３パラメータＰ１〜Ｐ３を追加して送信する。

ステップＳ２２において、ストレージ１００の拡張ライトコマンドＷ２認識部１１２は、通知された拡張ライトコマンドＷ２の記述内容を認識する。
ステップＳ２３において、ホスト２００のＫＶ管理部２２０は、拡張ライトコマンドＷ２に基づくライトデータＷＤ２を、ストレージ１００に送信する。例えば、図１４の時刻ｔ２において、ＫＶ管理部２２０は、拡張ライトコマンドＷ２に基づくライトデータＷＤ２（転送ブロック数：１〜ｍ）を、ＨＤＤ１に送信する。

ステップＳ２４において、ストレージ１００のＭＰＵ６０は、認識した第１パラメータＰ１に基づき、ライトデータＷＤ２の先頭ブロック１から最終ブロックｍまでを連続した１単位として、ディスク１０にライトする。例えば、図１４の時刻ｔ３からｔ４において、ＨＤＤ１のＭＰＵ６０は、第１パラメータＰ１に基づき、ライトデータＷＤ２を、先頭ブロック１から連続した１単位として、ディスク１０にライトする。この際、ＭＰＵ６０は、ＨＤＤ１において都合のよい書き方でライトデータＷＤ２をディスク１０にライトする。そのため、ホストインターフェースのセクタ／ブロックの区切りを無視することができる。具体的には、ＭＰＵ６０は、ライトデータＷＤ２の先頭ブロック１から途中ブロックｋまでを、サーボ領域ＳＶを除いて、２つの小単位ＵＷＤ２ａ〜ＵＷＤ２ｂで構成される連続した１単位として、ディスク１０にライトすることができる。

ステップＳ２５において、ストレージ１００のＭＰＵ６０は、ディスク１０の記憶状態に基づき、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）とライトデータＷＤ１の先頭部分（ブロック１〜２）とをディスク１０に連続してライトできるか否かを判定する。換言すれば、ＭＰＵ６０は、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）が、ディスク１０の記憶領域でのセクタ／ブロックの区切りのよい位置であるか否かを判定する。ステップＳ２５の条件を満たす場合（セクタ／ブロックの区切りのよい位置であった場合）、処理はステップＳ２７に続く。

ステップＳ２５の条件を満たさない場合（セクタ／ブロックの区切りのよい位置でなかった場合）、ステップＳ２６において、ＨＤＣ５０は、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）を一時記憶領域であるバッファメモリ９０等に一時的に記憶させる。これは、続いて通知される拡張ライトコマンドＷ１の準備のためである。例えば、図１４の時刻ｔ５において、ＨＤＣ５０は、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）を一時記憶領域に記憶させ、記憶したライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）のライトを一時保留とする。

ステップＳ２７において、拡張ライトコマンドＷ１生成部２１１は、第１パラメータＰ１が埋め込まれた拡張ライトコマンドＷ１を生成し、生成した拡張ライトコマンドＷ１をＨＤＤ１に通知する。例えば、図１４の時刻ｔ６において、ホストが送信するRegHDの内容(転送ブロック数ｎ等)に、第１パラメータＰ１を追加して送信する。

ステップＳ２８において、拡張ライトコマンドＷ１認識部１１１は、通知された拡張ライトコマンドＷ１の記述内容を認識する。
ステップＳ２９において、ホスト２００のＫＶ管理部２２０は、拡張ライトコマンドＷ１に基づくライトデータＷＤ１を、ストレージ１００に送信する。例えば、図１４の時刻ｔ７において、ＫＶ管理部２２０は、拡張ライトコマンドＷ１に基づくライトデータＷＤ１（転送ブロック数：１〜ｎ）を、ＨＤＤ１に送信する。

ステップＳ３０において、ストレージ１００のＭＰＵ６０は、送信されたライトデータが、（一時記憶領域に記憶した）ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）に連続するライトデータＷＤ１であるか否かを判定する。具体的には、ＭＰＵ６０は、第３パラメータに基づくＴＡＧ番号と、通知された拡張ライトコマンドＷＤ１のそれとが一致するか否かを判定する。ステップＳ３０の条件を満たさない場合（Ｓ３０でＮｏ）、処理はステップＳ２９に戻る。

ステップＳ３０の条件を満たす場合（Ｓ３０でＹｅｓ）、ステップＳ３１において、ＭＰＵ６０は、認識した第１，第２パラメータＰ１，Ｐ２に基づき、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）と、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを連続させてディスク１０にライトする。その結果、ライトデータＷＤ２およびＷＤ１（転送ブロック数：１〜ｍおよび１〜ｎ）が連続した１単位としてディスク１０にライトされる。例えば、図１４の時刻ｔ８からｔ９において、ＭＰＵ６０は、第１，第２パラメータＰ１，Ｐ２に基づき、ライトデータＷＤ２の最後部分（ブロックｋ＋１〜ｍ）と、ライトデータＷＤ１の先頭ブロック１から最終ブロックｎまでを連続させてディスク１０にライトする。この際、ＭＰＵ６０は、ＨＤＤ１において都合のよい書き方でライトデータＷＤ１，ＷＤ２をディスク１０にライトする。その結果、ＭＰＵ６０は、ライトデータＷＤ２，ＷＤ１のブロック１〜ｍ，１〜ｎを、サーボ領域ＳＶを除いて、５つの小単位ＵＷＤ２ａ〜ＵＷＤ２ｂ，ＵＷＤ１ａ〜ＵＷＤ１ｃから構成される連続した１単位ＵＷＤ２１として、ディスク１０にライトすることができる。

その他の動作については、第１実施形態と実質的に同様であるため、その詳細な説明を省略する。
［作用効果］
以上説明したように、第２実施形態に係るストレージシステム１Ｂの構成および動作によれば、少なくとも上記（１）および（２）の効果が得られる。さらに、第２実施形態に係るストレージシステム１Ｂによれば、下記（３）の効果が得られる。

（３）ストレージシステム１Ｂまたはアプリケーション（ソフトウェア）を含めたオペレーティングシステムからの視点での無駄な動作を削減でき、利便性を向上できる。
第２実施形態に係るストレージシステム１Ｂは、拡張ライトコマンドＷ２生成部２１２と、拡張ライトコマンドＷ２認識部１１２とを更に備える。

そのため、拡張ライトコマンドＷ２生成部２１２は、第１乃至第３パラメータＰ１〜Ｐ３が埋め込まれた拡張ライトコマンドＷ２を生成し、生成した拡張ライトコマンドＷ２をストレージ１００であるＨＤＤ１に通知する（図１３のＳ２１、図１４の時刻ｔ１）。拡張ライトコマンドＷ２認識部１１２は、通知された拡張ライトコマンドＷ２の記述内容を認識する（図１３のＳ２２）。同様に、拡張ライトコマンドＷ１認識部１１１は、通知された拡張ライトコマンドＷ１の記述内容を認識し（図１３のＳ２８）、ライトデータＷＤ２，ＷＤ１の先頭ブロック１から最終ブロックｎまでを連続させてディスク１０にライトする。その結果、ライトデータＷＤ２およびＷＤ１（転送ブロック数：１〜ｍおよび１〜ｎ）が連続した１単位ＵＷＤ２１としてディスク１０にライトされる（図１４の時刻ｔ８〜ｔ９）。そのため、無駄な動作を削減でき、利便性を向上できる。

図１５を用いて、上記についてより具体的に説明する。
図１５（ａ）に示すように、ライトしたいデータを扱うホスト２００のアプリケーションは、第１実施形態で説明したサイズよりも大きなサイズのデータ（バリュー）Ｖ２をデータの１単位として扱い、かつこのサイズのデータＶ２について必ず先頭ＨＡＤＤから最後ＦＡＤＤまで連続してアクセスを行いたい場合がある。例えば、日本のＢＳデジタル放送等の場合、データＶ２は、６４ＫＢよりもサイズが大きく、最大で１．５ＭＢ程度（１ＧＯＰのサイズ）となる。

しかしながら、図１５（ｄ１）に示す比較例の場合、同様に、既存インターフェース規格の制限があるため、大きなサイズを１単位としたデータ記録が行えない。比較例の場合、４ＫＢ単位でのリード／ライトに対応するため、斜線で示すプリアンブル等のための余剰領域ＲＡが４ＫＢごとに必要となる。

図１５（ｄ２）に示す第２実施形態の場合、連続した１単位ＵＷＤ２１として、ライトデータＷＤ２およびＷＤ１をライトすることが可能である。そのため、ホストアプリケーションが必要なデータＶ２のサイズを連続してディスク１０にライトできる。比較例と比べ、第２実施形態は、斜線で示す記憶領域１０Ｂを削減することができる（１０Ｂ＞１０Ａ）。

（第３実施形態）
第３実施形態に係るストレージシステム１について説明する。この説明において、上記第１，第２実施形態と重複する部分の詳細な説明を省略する。ここでは、ストレージシステム１の構成およびＰＵＴ（ライト）動作の概略について説明する。

［構成］
ストレージシステム
図１６に示すように、ストレージシステム１は、ＩＰ等のネットワーク３０１を用い、外部のクライアント３００からＡＰＩ２３０を介してアクセス可能であるように構成される。ストレージシステム１は、データＶと、このデータＶを識別するための識別情報であるキーＫとをストレージ１００に記憶する。このようなＫＶ型ストレージシステム１では、任意のサイズの識別情報であるキーＫと、当該キーＫに対応づけられた任意のサイズのバリューＶとが、ストレージ１００に記憶される。上記構成によれば、クライアント３００がキーＫを指定すると、キーＫに対応づけられたバリューＶを、ＰＵＴ（ライト）、ＧＥＴ（リード）、およびＤＥＬＥＴＥ（イレーズ）することが可能となる。

ストレージシステム１は、さらに複数のストレージ１００（ＳＳＤ１，ＳＳＤ２，，，ＨＤＤ１，ＨＤＤ２，ＨＤＤ３，，，）を備え、ＫＶ管理部２２０によりこれらを管理する。
ＳＳＤのリード速度ＶＳＳＤは、ＨＤＤのリード速度ＶＨＤＤよりも速い（ＶＳＳＤ ＞ＶＨＤＤ）。一方、ＳＳＤのデータ容量ＣＳＳＤは、ＨＤＤのデータ容量ＣＨＤＤよりも小さい（ＣＳＳＤ ＜ ＣＨＤＤ）。後述するように、ストレージシステム１は、ストレージの特性に基づく上記関係を利用して、動作を行う。

なお、ストレージシステム１の構成は、図１６に示したものに限られない。例えば、ストレージシステム１は、キーＫに対応するデータＶを記憶しているストレージ１００がいずれであるかというキー構成を管理する管理部等を更に備えてもよい。
［動作］
ＰＵＴ（ライト）処理
図１７に示すように、ＰＵＴ（ライト）処理を行う場合、クライアント３００は、ホスト２００に、キーＫとバリューＶとがペアとなったＰＵＴ要求であるＰＵＴ（Ｋ，Ｖ）を送信する。

続いて、ホスト２００のＫＶ管理部２２０は、受信したＰＵＴ（Ｋ，Ｖ）に基づき、ＳＳＤ１およびＳＳＤ２にキーＫをライトし、ＨＤＤ１およびＨＤＤ２にバリューＶをライトする。このようにして、同一のキーＫが記憶されたＳＳＤ１，ＳＳＤ２、および同一のバリューＶが記憶されたＨＤＤ１，ＨＤＤ２は、所定のＲＡＩＤグループを形成してもよい。

続いて、ＫＶ管理部２２０は、キーＫおよびバリューＶとこれを記憶したストレージ（ＳＳＤ１，ＳＳＤ２，ＨＤＤ１，ＨＤＤ２）１００との対応関係を記憶する。
続いて、ＫＶ管理部２２０は、ＰＵＴ処理が完了した旨を、クライアント３００に応答してもよい。

上記処理により、ストレージ装置１００に、ＰＵＴ要求に係るペア（Ｋ，Ｖ）が記憶される。
ＧＥＴ（リード）処理
ＧＥＴ（リード）処理を行う場合、クライアント３００は、ＧＥＴ要求として所望のバリューＶに対応するキーＫをストレージシステム１に送信する。キーＫを受信したＫＶ管理部２２０は、当該キーＫに基づき、ＳＳＤ１，ＳＳＤ２に記憶されたキーＫを検索し、キーＫ構造である例えばエントリ構造体等を得る。

続いて、ＫＶ管理部２２０は、エントリ構造体が示すＨＤＤ１，ＨＤＤ２のポインタが示す位置に記憶されているバリューＶを、ストレージ１００であるＨＤＤ１，ＨＤＤ２からリードする。
続いて、ＫＶ管理部２２０は、リードしたキーＫとペアとなるバリューＶをクライアント３００送信し、クライアント３００に応答する。なお、ＫＶ管理部２２０がＳＳＤ１，ＳＳＤ２に記憶されているキーを検索してもヒットしなかった場合、ＫＶ管理部２２０は、クライアント３００に対して、エラー応答またはペアとなるバリューＶがなかった旨を応答してもよい。

［作用効果］
以上説明したように、第３実施形態に係るストレージシステム１の構成および動作によれば、少なくとも上記（１）乃至（３）の効果が得られる。
さらに、上述したように第３実施形態に係るストレージシステム１は、ＳＡＴＡ Ｉ／Ｆ等の既存のインターフェースを用いながらも、可変長のキーＫを指定して可変長のバリューＶのライトおよびリードを行うことができる。そのため、非構造化データを処理でき、ソフトウェア構成を簡略化することができる。

ホスト（ブリッジ部）２００のＫＶ管理部２２０が、一括してストレージ１００を管理する。そのため、大規模ストレージを構成しても、ストレージ１００を管理するための管理サーバの数を削減または管理サーバの数を不要とすることができる。そのため、ストレージシステム１は、低ＴＣＯ（Total Cost of Ownership）化および高性能化に有利である。

ストレージシステム１は、応答速度やデータ容量が異なるＳＳＤやＨＤＤ等の複数の種類のストレージを一括して制御する。そのため、処理目的に合わせたストレージの選択が不要となる。
さらに、ストレージシステム１は、ＳＳＤのリード速度とＨＤＤのリード速度ＶＨＤＤとの関係（ＶＳＳＤ ＞ＶＨＤＤ）、およびＳＳＤのデータ容量ＣＳＳＤとＨＤＤのデータ容量ＣＨＤＤとの関係（ＣＳＳＤ ＜ ＣＨＤＤ）を利用することで、ＰＵＴ処理およびＧＥＴ処理を効率化できる。例えば、ＰＵＴ処理において、ＫＶ管理部２２０は、サイズの大きいバリューＶをＨＤＤ１，ＨＨＤ２にライトすることで、ＰＵＴ要求を満たすことができる。例えば、ＧＥＴ処理において、ＫＶ管理部２２０は、リード速度の速いＳＳＤ１，ＳＳＤ２からキーＫを検索することで、クライアント３００の所定の応答速度内にＧＥＴ要求を満たすことができる。

加えて、上記（１）乃至（３）の効果に示したように、セクタ／ブロックの管理サイズにかかわらず、バリューＶ１，Ｖ２を１単位としてライトおよびリードできる。そのため、上記（１）乃至（３）の効果とＫＶ型ストレージシステムとの相乗効果が期待される。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

３００…ストレージアクセスクライアント、３０１…ネットワーク、２００…ホスト（ブリッジ部）、２０１…コマンド生成部、２１０…ＣＰＵ、２１１…第１拡張ライトコマンド生成部（第１発行部）、２２０…ＫＶ管理部、２３０…ＡＰＩ、１３０…システムコントローラ、１００…ストレージ、９０…バッファメモリ、８０…不揮発性メモリ、７０…揮発性メモリ、６０…ＭＰＵ、５０…ＨＤＣ、５１…コマンド認識部、４０…Ｒ／Ｗチャネル、３０…ヘッドアンプＩＣ、２０…ドライバＩＣ、１５…ヘッド、１４…ＶＣＭ、１３…アーム、１２…ＳＰＭ、１０…磁気ディスク、１，１Ａ，１Ｂ…ストレージシステム。

Claims (9)

1. 外部から指定されるキーと前記キーに対応づけられたバリューとを記憶する記憶媒体と、
   前記記憶媒体に、前記キーとライトデータである前記バリューとをライトするコントローラと、を具備し、
   前記コントローラは、ライトコマンドを受信するコマンド受信部と、
   第１パラメータを含む第１拡張ライトコマンドを受信する第１拡張コマンド受信部とを備え、
   前記第１パラメータは、前記ライトコマンドに基づくライトデータへの第１アクセス単位よりも前記第１拡張ライトコマンドに基づく第１ライトデータへの第２アクセス単位の方が大きく、前記第２アクセス単位が複数の前記第１アクセス単位により構成された１単位であることを示し、
   前記コントローラは、前記第１拡張コマンド受信部で前記外部から送信された前記第１拡張ライトコマンドを受信すると、前記第１パラメータに基づき前記第１ライトデータを１単位として前記記憶媒体にライトする
   ストレージ。
2. 前記コントローラは、前記第１パラメータと第２および第３パラメータとを含む第２拡張ライトコマンドを受信する第２拡張コマンド受信部を更に備え、
   前記第２パラメータは、前記第２拡張ライトコマンドの後に通知される前記第１拡張ライトコマンドに基づく第１ライトデータが、前記第２拡張ライトコマンドに基づく第２ライトデータと連続してアクセスされることを示し、
   前記第３パラメータは、前記第２ライトデータと連続する前記第１ライトデータを他のデータと識別するための固有の識別情報である
   請求項１に記載のストレージ。
3. データを一時的に記憶するメモリを更に具備し、
   前記コントローラは、前記第２ライトデータの一部を前記メモリに一時的に記憶させることで、ライトを一時的に停止する
   請求項２に記載のストレージ。
4. 前記コントローラは、前記第３パラメータに基づき、送信されたライトデータが前記第１拡張ライトコマンドに基づく前記第１ライトデータであるか否かを判定する
   請求項２乃至３に記載のストレージ。
5. 前記コントローラは、送信されたライトデータが前記第１拡張ライトコマンドに基づく前記第１ライトデータであると判定する場合、前記第１および第２ライトデータを１単位として前記記憶媒体にライトする
   請求項４に記載のストレージ。
6. キーと前記キーに対応づけられたバリューとを記憶する記憶媒体を備えるストレージと、
   前記記憶媒体に前記キーとライトデータである前記バリューとをライトするように前記ストレージを管理するホストと、を具備し、
   前記ストレージは、ライトコマンドを受信するコマンド受信部と、第１パラメータを含む第１拡張ライトコマンドを受信する第１拡張コマンド受信部とを備え、
   前記ホストは、前記ライトコマンドを生成するコマンド生成部と、前記第１パラメータを含む前記第１拡張ライトコマンドを生成する第１拡張コマンド生成部とを備え、
   前記第１パラメータは、前記ライトコマンドに基づくライトデータへの第１アクセス単位よりも前記第１拡張ライトコマンドに基づく第１ライトデータへの第２アクセス単位の方が大きく、前記第２アクセス単位が複数の前記第１アクセス単位で構成される１単位であることを示し、
   前記ホストは、前記第１拡張コマンド生成部で生成した前記第１拡張コマンドを、前記ストレージに送信し、
   前記ストレージは、前記第１拡張コマンド受信部で前記ホストから送信された前記第１拡張ライトコマンドを受信すると、前記第１パラメータに基づき前記第１ライトデータを１単位として前記記憶媒体にライトする
   ストレージシステム。
7. 前記ストレージは、前記記憶媒体である磁気ディスクを有するハードディスクドライブと、前記記憶媒体であるフラッシュメモリを有するソリッドステートドライブと、を備える
   請求項６に記載のストレージシステム。
8. 前記ホストは、外部からのライト要求に基づき、前記ソリッドステートドライブに前記外部から受信したキーをライトし、前記ハードディスクドライブに前記外部から受信した前記キーおよび前記キーに対応づけられたバリューをライトする
   請求項７に記載のストレージシステム。
9. 前記ストレージは、前記記憶媒体である磁気ディスクをそれぞれ有する複数のハードディスクドライブと、前記記憶媒体であるフラッシュメモリをそれぞれ有する複数のソリッドステートドライブと、を更に備え、
   前記ホストは、前記外部からのライト要求に基づき、前記複数のソリッドステートドライブに前記外部から受信したキーをライトし、前記複数のハードディスクドライブに前記外部から受信した前記キーおよび前記キーに対応づけられたバリューをライトし、ＲＡＩＤグループを形成する
   請求項７または８に記載のストレージシステム。

Images