(57)【要約】【課題】同時に利用可能な書き込み先ブロックの数を増やすことができるメモリシステムを実現する。【解決手段】メモリシステムは、一つの書き込み先ブロックに関連付けられた第１の識別子と、書き込むべき第１のデータが格納されている前記ホストのメモリ上のライトバッファ内の位置を示す記憶位置情報とを含むライト要求を前記ホストから受信する。メモリシステムは、第１のデータを不揮発性メモリに書き込む際に、前記記憶位置情報を含む転送要求をホストに送出することによって第１のデータをライトバッファから取得し、第１のデータを前記不揮発性メモリに転送し、第１のデータを前記一つの書き込み先ブロックに書き込む。【選択図】図６
2019105873.tif 000002
【特許請求の範囲】
【請求項１】
ホストに接続可能なメモリシステムであって、
不揮発性メモリと、
前記不揮発性メモリに電気的に接続され、前記不揮発性メモリ内の複数のブロックから割り当てられた複数の書き込み先ブロックを管理するように構成されたコントローラとを具備し、
前記コントローラは、
一つの書き込み先ブロックに関連付けられた第１の識別子と、書き込むべき第１のデータが格納されている前記ホストのメモリ上のライトバッファ内の位置を示す記憶位置情報とを含むライト要求を前記ホストから受信し、前記第１の識別子と前記記憶位置情報とを保持し、
前記第１のデータを前記不揮発性メモリに書き込む際に、前記記憶位置情報を含む転送要求を前記ホストに送信することによって前記第１のデータを前記ライトバッファから取得し、前記第１のデータを前記不揮発性メモリに転送し、前記第１のデータを前記一つの書き込み先ブロックに書き込み、
前記不揮発性メモリへの前記第１のデータの転送が終了するまで前記第１のデータを保持し、
前記第１のデータの書き込みが終了し且つ前記第１のデータが前記不揮発性メモリから読み出し可能になった場合、前記ライトバッファに保持されている前記第１のデータが不要になったことを前記ホストに通知するように構成されている、メモリシステム。
【請求項２】
前記第１のデータの書き込みは、前記第１のデータを前記不揮発性メモリに複数回転送することを伴う複数段階のプログラム動作によって実行され、
前記コントローラは、前記第１のデータの各段階のプログラム動作の開始の度に、前記記憶位置情報を含む前記転送要求を前記ホストに送信することによって前記第１のデータを前記ライトバッファから取得するように構成されている請求項１記載のメモリシステム。
【請求項３】
前記コントローラは、前記第１のデータの書き込み開始から前記第１のデータが読み出し可能になるまでの期間中に前記第１のデータをリードするためのリード要求を前記ホストから受信した場合、前記ライトバッファから前記第１のデータを前記リード要求に対する応答として返すように要求する転送要求を、前記ホストに送出するように構成されている請求項１記載のメモリシステム。
【請求項４】
前記ライトバッファは前記複数の書き込み先ブロックに対応する複数のライトバッファ領域を含み、
前記コントローラは、前記一つの書き込み先ブロックの全体がデータで満たされた場合、前記一つの書き込み先ブロックに対応する前記ライトバッファ内のライトバッファ領域が不要になったことを前記ホストに通知するように構成されている請求項１記載のメモリシステム。
【請求項５】
前記メモリシステムは前記ホストにｅｔｈｅｒｎｅｔ（登録商標）を介して接続される請求項１記載のメモリシステム。
【請求項６】
前記第１の識別子は、特定の書き込み先ブロックを指定するブロック識別子である請求項１記載のメモリシステム。
【請求項７】
前記複数の書き込み先ブロックは複数のストリームにそれぞれ関連付けられており、
前記第１の識別子は、前記複数のストリーム内の一つのストリームの識別子である請求項１記載のメモリシステム。
【請求項８】
前記ライトバッファは前記複数の書き込み先ブロックに対応する複数のライトバッファ領域を含み、
前記転送要求は前記第１の識別子と前記記憶位置情報とを含む請求項１記載のメモリシステム。
【請求項９】
不揮発性メモリを制御する制御方法であって、
前記不揮発性メモリ内の複数のブロックから割り当てられた複数の書き込み先ブロックを管理することと、
一つの書き込み先ブロックに関連付けられた第１の識別子と、書き込むべき第１のデータが格納されているホストのメモリ上のライトバッファ内の位置を示す記憶位置情報とを含むライト要求を前記ホストから受信し、前記第１の識別子と前記記憶位置情報とを保持することと、
前記第１のデータを前記不揮発性メモリに書き込む際に、前記記憶位置情報を含む転送要求を前記ホストに送信することによって前記第１のデータを前記ライトバッファから取得し、前記第１のデータを前記不揮発性メモリに転送し、前記第１のデータを前記一つの書き込み先ブロックに書き込むことと、
前記不揮発性メモリへの前記第１のデータの転送が終了するまで前記第１のデータを保持することと、
前記第１のデータの書き込みが終了し且つ前記第１のデータが前記不揮発性メモリから読み出し可能になった場合、前記ライトバッファに保持されている前記第１のデータが不要になったことを前記ホストに通知することとを具備する制御方法。
【請求項１０】
前記第１のデータの書き込みは、前記第１のデータを前記不揮発性メモリに複数回転送することを伴う複数段階のプログラム動作によって実行され、
前記書き込むことは、前記第１のデータの各段階のプログラム動作の開始の度に、前記記憶位置情報を含む前記転送要求を前記ホストに送信することによって前記第１のデータを前記ライトバッファから取得することを含む請求項９記載の制御方法。
【請求項１１】
前記第１のデータの書き込み開始から前記第１のデータが読み出し可能になるまでの期間中に前記第１のデータをリードするためのリード要求を前記ホストから受信した場合、前記ライトバッファから前記第１のデータを前記リード要求に対する応答として返すように要求する転送要求を、前記ホストに送出することをさらに具備する請求項９記載の制御方法。
【請求項１２】
前記ライトバッファは前記複数の書き込み先ブロックに対応する複数のライトバッファ領域を含み、
前記一つの書き込み先ブロックの全体がデータで満たされた場合、前記一つの書き込み先ブロックに対応する前記ライトバッファ内のライトバッファ領域が不要になったことを前記ホストに通知することをさらに具備する請求項９記載の制御方法。
【請求項１３】
前記第１の識別子は、特定のブロックを指定するブロック識別子である請求項９記載の制御方法。
【請求項１４】
前記複数の書き込み先ブロックは複数のストリームにそれぞれ関連付けられており、
前記第１の識別子は、前記複数のストリーム内の一つのストリームの識別子である請求項９記載の制御方法。
【請求項１５】
前記ライトバッファは前記複数の書き込み先ブロックに対応する複数のライトバッファ領域を含み、
前記転送要求は前記第１の識別子と前記記憶位置情報とを含む請求項９記載の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、不揮発性メモリを制御する技術に関する。
【背景技術】
【０００２】
近年、不揮発性メモリを備えるメモリシステムが広く普及している。このようなメモリシステムの一つとして、ＮＡＮＤフラッシュ技術ベースのソリッドステートドライブ（ＳＳＤ）が知られている。
【０００３】
データセンターのサーバにおいても、ストレージデバイスとしてＳＳＤが使用されている。
【０００４】
サーバのようなホスト計算機システムにおいて利用されるストレージデバイスにおいては、高いＩ／Ｏ性能が求められている。
【０００５】
このため、最近では、ホストとストレージデバイスとの間の新たなインタフェースが提案され始めている。
【０００６】
また、最近のストレージデバイスにおいては、異なる種類のデータを異なる書き込み先ブロックに書き込むことを可能にすることが求められる場合がある。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Yiying Zhang, 外, "De-indirection for flash-based SSDs with nameless writes." FAST. 2012, [online], [平成29年9月13日検索], インターネット<URL: https://www.usenix.org/system/files/conference/fast12/zhang.pdf >
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、同時に利用可能な書き込み先ブロックの数が増えると、個々の書き込み先ブロックに書き込むべきライトデータを一時的に格納するために必要なライトバッファの数も増やすことが必要となる。通常、ストレージデバイス内のランダムアクセスメモリの容量は限られているので、ストレージデバイスにとっては、十分な数のライトバッファを用意することは困難な場合がある。このため、実際上、同時に利用可能な書き込み先ブロックの数は制限される結果となる。
【０００９】
本発明が解決しようとする課題は、同時に利用可能な書き込み先ブロックの数を増やすことができるメモリシステムおよび制御方法を提供することである。
【課題を解決するための手段】
【００１０】
実施形態によれば、ホストに接続可能なメモリシステムは、不揮発性メモリと、前記不揮発性メモリに電気的に接続され、前記不揮発性メモリ内の複数のブロックから割り当てられた複数の書き込み先ブロックを管理するように構成されたコントローラとを具備する。前記コントローラは、一つの書き込み先ブロックに関連付けられた第１の識別子と、書き込むべき第１のデータが格納されている前記ホストのメモリ上のライトバッファ内の位置を示す記憶位置情報とを含むライト要求を前記ホストから受信し、前記第１の識別子と前記記憶位置情報とを保持する。前記コントローラは、前記第１のデータを前記不揮発性メモリに書き込む際に、前記記憶位置情報を含む転送要求を前記ホストに送出することによって前記第１のデータを前記ライトバッファから取得し、前記第１のデータを前記不揮発性メモリに転送し、前記第１のデータを前記一つの書き込み先ブロックに書き込む。前記コントローラは、前記第１のデータの書き込みが終了し且つ前記第１のデータが前記不揮発性メモリから読み出し可能になった場合、前記ライトバッファに保持されている前記第１のデータが不要になったことを前記ホストに通知する。
【図面の簡単な説明】
【００１１】
【図１】ホストとメモリシステム（フラッシュストレージデバイス）との関係を示すブロック図。
【図２】フラッシュストレージデバイスの構成例を示すブロック図。
【図３】フラッシュストレージデバイスにおいて使用される複数のチャンネルと複数のＮＡＮＤ型フラッシュメモリチップとの関係を示すブロック図。
【図４】フラッシュストレージデバイスにおいて使用される、あるスーパーブロックの構成例を示す図。
【図５】複数のエンドユーザに対応する複数の書き込み先ブロックと複数のライトバッファ領域との関係を示す図。
【図６】フラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。
【図７】複数の書き込み先ブロックと複数のライトバッファ領域（ＵＷＢ領域）との関係の例を示す図。
【図８】フラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。
【図９】フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。
【図１０】フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。
【図１１】ホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理の手順を示すシーケンス図。
【図１２】フラッシュストレージデバイスによって実行される通知処理の手順を示すフローチャート。
【図１３】転送要求の受信に応じて実行されるホスト側処理の手順を示すフローチャート。
【図１４】リード要求の受信に応じてフラッシュストレージデバイスによって実行されるデータ読み出し動作の手順を示すフローチャート。
【図１５】データ読み出しのためのホスト側処理の手順を示すフローチャート。
【図１６】ストリーム書き込みをサポートするフラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ書き込み処理を説明するためのブロック図。
【図１７】複数のストリームＩＤとこれらストリームＩＤに関連付けられた複数の書き込み先ブロックとの関係を示す図。
【図１８】ストリーム書き込みをサポートするフラッシュストレージデバイスとホスト側ＵＷＢとの関係とホストとフラッシュストレージデバイスとによって実行されるデータ読み出し処理を説明するためのブロック図。
【図１９】フォギー・ファイン書き込みをサポートするフラッシュストレージデバイスとホストとによって実行されるデータ書き込み処理の手順を示すシーケンス図。
【図２０】ホストの構成例を示すブロック図。
【図２１】ホスト内のプロセッサ（ＣＰＵ）によって実行されるデータ書き込み処理の手順を示すフローチャート。
【図２２】ホスト内のプロセッサによって実行されるデータ読み出し処理の手順を示すフローチャート。
【図２３】ホスト内のプロセッサによって実行されるデータ読み出し処理の別の手順を示すフローチャート。
【図２４】ホスト内のプロセッサによって実行されるＵＷＢ領域解放処理の手順を示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、実施形態を説明する。  
【００１３】
まず、図１を参照して、ホストとメモリシステムとの関係を説明する。
【００１４】
このメモリシステムは、不揮発性メモリにデータを書き込み、不揮発性メモリからデータを読み出すように構成された半導体ストレージデバイスである。このメモリシステムは、ＮＡＮＤフラッシュ技術ベースのフラッシュストレージデバイス３として実現されている。
【００１５】
ホスト（ホストデバイス）２は、複数のフラッシュストレージデバイス３を制御するように構成されている。ホスト２は、複数のフラッシュストレージデバイス３によって構成されるフラッシュアレイをストレージとして使用するように構成された情報処理装置によって実現される。この情報処理装置はパーソナルコンピュータであとてもよいし、サーバコンピュータであってもよい。
【００１６】
なお、フラッシュストレージデバイス３は、ストレージアレイ内に設けられる複数のストレージデバイスの一つとして利用されてもよい。ストレージアレイは、サーバコンピュータのような情報処理装置にケーブルまたはネットワークを介して接続されてもよい、ストレージアレイは、このストレージアレイ内の複数のストレージ（例えば複数のフラッシュストレージデバイス３）を制御するコントローラを含む。フラッシュストレージデバイス３がストレージアレイに適用された場合には、このストレージアレイのコントローラが、フラッシュストレージデバイス３のホストとして機能してもよい。
【００１７】
以下では、サーバコンピュータのような情報処理装置がホスト２として機能する場合を例示して説明する。
【００１８】
ホスト（サーバ）２と複数のフラッシュストレージデバイス３は、インタフェース５０を介して相互接続される（内部相互接続）。この相互接続のためのインタフェース５０としては、これに限定されないが、ＰＣＩ  Ｅｘｐｒｅｓｓ（ＰＣＩｅ）（登録商標）、ＮＶＭ  Ｅｘｐｒｅｓｓ（ＮＶＭｅ）（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＮＶＭｅ  ｏｖｅｒ  Ｆａｂｒｉｃｓ（ＮＶＭｅＯＦ）等を使用し得る。
【００１９】
ホスト２として機能するサーバコンピュータの典型例としては、データセンター内のサーバコンピュータ（以下、サーバと称する）が挙げられる。
【００２０】
ホスト２がデータセンター内のサーバによって実現されるケースにおいては、このホスト（サーバ）２は、ネットワーク５１を介して複数のエンドユーザ端末（クライアント）６１に接続されてもよい。ホスト２は、これらエンドユーザ端末６１に対して様々なサービスを提供することができる。
【００２１】
ホスト（サーバ）２によって提供可能なサービスの例には、（１）システム稼働プラットフォームを各クライアント（各エンドユーザ端末６１）に提供するプラットホーム・アズ・ア・サービス（ＰａａＳ）、（２）仮想サーバのようなインフラストラクチャを各クライアント（各エンドユーザ端末６１）に提供するインフラストラクチャ・アズ・ア・サービス（ＩａａＳ）、等がある。
【００２２】
複数の仮想マシンが、このホスト（サーバ）２として機能する物理サーバ上で実行されてもよい。ホスト（サーバ）２上で走るこれら仮想マシンの各々は、対応する幾つかのクライアント（エンドユーザ端末６１）に各種サービスを提供するように構成された仮想サーバとして機能することができる。
【００２３】
ホスト（サーバ）２は、フラッシュアレイを構成する複数のフラッシュストレージデバイス３を管理するストレージ管理機能と、エンドユーザ端末６１それぞれに対してストレージアクセスを含む様々なサービスを提供するフロントエンド機能とを含む。
【００２４】
フラッシュストレージデバイス３は、ＮＡＮＤ型フラッシュメモリのような不揮発性メモリを含む。一つのフラッシュストレージデバイス３は、不揮発性メモリ内の複数のブロックから割り当てられた複数の書き込み先ブロックを管理する。書き込み先ブロックとは、データが書き込まれるべきブロックを意味する。ホスト２からフラッシュストレージデバイス３に送出されるライト要求（ライトコマンド）には、データが書き込まれるべき一つの書き込み先ブロックに関連づけられた識別子が含まれる。このライト要求に含まれるこの識別子に基づいて、フラッシュストレージデバイス３は、複数の書き込み先ブロックから、このデータが書き込まれるべき一つの書き込み先ブロックを決定する。
【００２５】
このライト要求に含まれる識別子は、特定の書き込み先ブロックを指定するブロック識別子であってもよい。ブロック識別子は、ブロックアドレス（ブロック番号）によって表されてもよい。あるいは、フラッシュストレージデバイス３が複数のＮＡＮＤ型フラッシュメモリチップを含むケースにおいては、ブロック識別子は、ブロックアドレス（ブロック番号）とチップ番号との組み合わせによって表されてもよい。
【００２６】
フラッシュストレージデバイス３がストリーム書き込みをサポートしているケースにおいては、このライト要求に含まれる識別子は、複数のストリーム内の一つのストリームの識別子（ストリームＩＤ）であってもよい。ストリーム書き込みにおいては、複数の書き込み先ブロックが複数のストリームにそれぞれ関連付けられる。換言すれば、フラッシュストレージデバイス３があるストリームＩＤを含むライト要求をホスト２から受信した場合、このフラッシュストレージデバイス３は、このストリームＩＤに対応するストリームに関連づけられた書き込み先ブロックにデータを書き込む。フラッシュストレージデバイス３が別のストリームＩＤを含むライト要求をホスト２から受信した場合、このフラッシュストレージデバイス３は、この別のストリームＩＤに対応する別のストリームに関連づけられた別の書き込み先ブロックにデータを書き込む。
【００２７】
フラッシュストレージデバイス３によって管理される複数の書き込み先ブロックは、このフラッシュストレージデバイス３を共有する複数のエンドユーザ（クライアント）によってそれぞれ使用されてもよい。この場合、フラッシュストレージデバイス３においては、フラッシュストレージデバイス３を共有するエンドユーザの数と同数またはそれ以上の書き込み先ブロックがオープンされる。
【００２８】
このように、同時に利用可能な複数の書き込み先ブロックがフラッシュストレージデバイス３に存在する環境においては、これら書き込み先ブロックの数と同数のライトバッファを用意することが必要となる。
【００２９】
なぜなら、最近のＮＡＮＤ型フラッシュメモリの多くはメモリセル当たりに複数ビットのデータを書き込むように構成されており、書き込み先ブロック毎に、この書き込み先ブロックに書き込まれるべき複数ページ分のデータを保持しておくことが必要となるからである。
【００３０】
また、最近のＮＡＮＤ型フラッシュメモリにおいては、プログラムディスターブを削減するために、ライトデータをＮＡＮＤ型フラッシュメモリに複数回転送することを伴う複数段階のプログラム動作によってライトデータをＮＡＮＤ型フラッシュメモリに書き込むというライト方法が適用されるケースがある。このようなライト方法の典型例としては、フォギー・ファイン・プログラム動作が挙げられる。この場合においても、複数段階のプログラム動作が終了するまでライトデータを保持する必要があるので、書き込み先ブロックの数と同数のライトバッファを用意することが必要となる。
【００３１】
フォギー・ファイン・プログラム動作では、例えば、複数ページ分の第１のライトデータがＮＡＮＤ型フラッシュメモリに転送され、そして第１のライトデータが最初の物理ページ（あるワード線に接続されたメモリセル群）に書き込まれる（一段階目の書き込み：フォギー書き込み）。この後、最初の物理ページに隣接する別の物理ページ（別のワード線に接続されたメモリセル群）に対するフォギー書き込みが実行される。そして、上述の複数ページ分の第１のライトデータがＮＡＮＤ型フラッシュメモリに再び転送され、そしてこの第１のライトデータが最初の物理ページに書き込まれる（二段階目の書き込み：ファイン書き込み）。この後、上述の別の物理ページに対するファイン書き込みが実行される。
【００３２】
しかし、フラッシュストレージデバイス３内のランダムアクセスメモリの容量は限られているので、十分な数のライトバッファをフラッシュストレージデバイス３内のランダムアクセスメモリ上に用意することは困難な場合がある。また、たとえフラッシュストレージデバイス３に大容量のランダムアクセスメモリを用意したとしても、フラッシュストレージデバイス３を共有するエンドユーザの数が少ない場合には、大容量のランダムアクセスメモリが無駄になる結果となる。
【００３３】
そこで、本実施形態では、ホスト２のメモリ上の所定の記憶領域がライトバッファ（以下、ＵＷＢ：Ｕｎｉｆｉｅｄ  Ｗｒｉｔｅ  Ｂｕｆｆｅｒと称する）２Ａとして利用される。ホスト２側のＵＷＢ２Ａは、複数の書き込み先ブロックに対応する複数のライトバッファ領域を含む。
【００３４】
ホスト２は、一つの書き込み先ブロックに書き込むべきライトデータをＵＷＢ２Ａ（この書き込み先ブロックに対応するライトバッファ領域）に格納する。そして、ホスト２は、この一つの書き込み先ブロックに関連付けられた識別子（ブロック識別子またはストリームＩＤ）と、このライトデータが格納されているＵＷＢ２Ａ内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス３に送出する。
【００３５】
フラッシュストレージデバイス３は、このライト要求をホスト２から受信し、識別子と記憶位置情報とを保持する。フラッシュストレージデバイス３は、このライトデータをＮＡＮＤ型フラッシュメモリに書き込む際に、上述の記憶位置情報を含む転送要求をホスト２に送出することによって上述のライトデータをＵＷＢ２Ａから取得する。例えば、ＮＡＮＤ型フラッシュメモリがメモリセル当たりに３ビットのデータを格納するＴＬＣ（トリプル・レベル・セル）−フラッシュメモリである場合には、同一の物理ページに書き込むべき３ページ分のライトデータがＵＷＢ２Ａから取得される。一つの物理ページには３つのページアドレスが割り当てられてもよい。そして、フラッシュストレージデバイス３は、このライトデータを一つの書き込み先ブロック（この書き込み先ブロックのある物理ページ）に書き込む。
【００３６】
フラッシュストレージデバイス３は、フル・シーケンス・プログラム動作によってこのライトデータを一つの書き込み先ブロックに書き込んでもよい。
【００３７】
あるいは、フラッシュストレージデバイス３は、ライトデータ（例えば３ページ分のライトデータ）をＮＡＮＤ型フラッシュメモリに複数回転送することを伴う複数段階のプログラム動作（例えばフォギー・ファイン・プログラム動作）によってこのライトデータを一つの書き込み先ブロックに書き込んでもよい。この場合には、フラッシュストレージデバイス３は、最初に、一段階目の書き込み動作を実行する。その後、二段階目の書き込み動作を実行するタイミングになった時に、フラッシュストレージデバイス３は、上述の記憶位置情報を含む転送要求をホスト２に再び送出する。ホスト２は、上述の記憶位置情報を含む転送要求をフラッシュストレージデバイス３から受信する度に、このライトデータをＵＷＢ２Ａからフラッシュストレージデバイス３に転送する。上述のライトデータをＵＷＢ２Ａから再び取得すると、フラッシュストレージデバイス３は、二段階目の書き込み動作を実行する。
【００３８】
フラッシュストレージデバイス３は、このライトデータの書き込みが終了し且つこのライトデータがＮＡＮＤ型フラッシュメモリから読み出し可能になった場合（フル・シーケンス・プログラム動作においてはフル・シーケンス・プログラム動作が終了した場合、フォギー・ファイン・プログラム動作においてはフォギー書き込み動作とファイン書き込み動作の双方が終了した場合）に、ＵＷＢ２Ａに保持されているこのライトデータが不要になったことをホスト２に通知する。
【００３９】
したがって、本実施形態においては、フラッシュストレージデバイス３に多数のライトバッファを用意することなく、多数の書き込み先ブロックを同時に利用することが可能となる。したがって、フラッシュストレージデバイス３に大容量のランダムアクセスメモリを設ける必要が無くなるので、フラッシュストレージデバイス３のコストアップを招くことなく、フラッシュストレージデバイス３を共有するエンドユーザの数を容易に増やすことが可能となる。
【００４０】
図２は、フラッシュストレージデバイス３の構成例を示す。
【００４１】
フラッシュストレージデバイス３は、コントローラ４および不揮発性メモリ（ＮＡＮＤ型フラッシュメモリ）５を備える。フラッシュストレージデバイス３は、ランダムアクセスメモリ、例えば、ＤＲＡＭ６も備えていてもよい。
【００４２】
ＮＡＮＤ型フラッシュメモリ５は、マトリクス状に配置された複数のメモリセルを含むメモリセルアレイを含む。ＮＡＮＤ型フラッシュメモリ５は、２次元構造のＮＡＮＤ型フラッシュメモリであってもよいし、３次元構造のＮＡＮＤ型フラッシュメモリであってもよい。
【００４３】
ＮＡＮＤ型フラッシュメモリ５のメモリセルアレイは、複数のブロックＢＬＫ０〜ＢＬＫｍ−１を含む。ブロックＢＬＫ０〜ＢＬＫｍ−１の各々は多数のページ（ここではページＰ０〜Ｐｎ−１）によって編成される。ブロックＢＬＫ０〜ＢＬＫｍ−１は、消去単位として機能する。ブロックは、「消去ブロック」、「物理ブロック」、または「物理消去ブロック」と称されることもある。ページＰ０〜Ｐｎ−１の各々は、同一ワード線に接続された複数のメモリセルを含む。ページＰ０〜Ｐｎ−１は、「物理ページ」と称されることもある。ページＰ０〜Ｐｎ−１は、データ書き込み動作およびデータ読み込み動作の単位である。
【００４４】
コントローラ４は、Ｔｏｇｇｌｅ、オープンＮＡＮＤフラッシュインタフェース（ＯＮＦＩ）のようなフラッシュプログラミングコントローラ１３を介して、不揮発性メモリであるＮＡＮＤ型フラッシュメモリ５に電気的に接続されている。コントローラ４は、ＮＡＮＤ型フラッシュメモリ５を制御するように構成されたメモリコントローラとして動作する。このコントローラ４は、Ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ（ＳｏＣ）のような回路によって実現されてもよい。
【００４５】
ＮＡＮＤ型フラッシュメモリ５は、図３に示すように、複数のＮＡＮＤ型フラッシュメモリチップ（ＮＡＮＤ型フラッシュメモリダイ）を含んでいてもよい。個々のＮＡＮＤ型フラッシュメモリチップは独立して動作可能である。このため、ＮＡＮＤ型フラッシュメモリチップは、並列動作可能な単位として機能する。図３においては、フラッシュプログラミングコントローラ１３に１６個のチャンネルＣｈ．１〜Ｃｈ．１６が接続されており、１６個のチャンネルＣｈ．１〜Ｃｈ．１６の各々に２つのＮＡＮＤ型フラッシュメモリチップが接続されている場合が例示されている。この場合、チャンネルＣｈ．１〜Ｃｈ．１６に接続された１６個のＮＡＮＤ型フラッシュメモリチップ＃１〜＃１６がバンク＃０として編成されてもよく、またチャンネルＣｈ．１〜Ｃｈ．１６に接続された残りの１６個のＮＡＮＤ型フラッシュメモリチップ＃１７〜＃３２がバンク＃１として編成されてもよい。バンクは、複数のメモリモジュールをバンクインタリーブによって並列動作させるための単位として機能する。図３の構成例においては、１６チャンネルと、２つのバンクを使用したバンクインタリーブとによって、最大３２個のＮＡＮＤ型フラッシュメモリチップを並列動作させることができる。
【００４６】
消去動作は、一つのブロック（物理ブロック）の単位で実行されてみよいし、並列動作可能な複数の物理ブロックの集合を含むスーパーブロックの単位で実行されてもよい。一つのスーパーブロックは、これに限定されないが、ＮＡＮＤ型フラッシュメモリチップ＃１〜＃３２から一つずつ選択される計３２個の物理ブロックを含んでいてもよい。なお、ＮＡＮＤ型フラッシュメモリチップ＃１〜＃３２の各々はマルチプレーン構成を有していてもよい。例えば、ＮＡＮＤ型フラッシュメモリチップ＃１〜＃３２の各々が、２つのプレーンを含むマルチプレーン構成を有する場合には、一つのスーパーブロックは、ＮＡＮＤ型フラッシュメモリチップ＃１〜＃３２に対応する６４個のプレーンから一つずつ選択される計６４個の物理ブロックを含んでいてもよい。
【００４７】
図４には、３２個の物理ブロック（ここでは、ＮＡＮＤ型フラッシュメモリチップ＃１内の物理ブロックＢＬＫ２、ＮＡＮＤ型フラッシュメモリチップ＃２内の物理ブロックＢＬＫ３、ＮＡＮＤ型フラッシュメモリチップ＃３内の物理ブロックＢＬＫ７、ＮＡＮＤ型フラッシュメモリチップ＃４内の物理ブロックＢＬＫ４、ＮＡＮＤ型フラッシュメモリチップ＃５内の物理ブロックＢＬＫ６、…ＮＡＮＤ型フラッシュメモリチップ＃３２内の物理ブロックＢＬＫ３）を含む一つのスーパーブロック（ＳＢ）が例示されている。
【００４８】
書き込み先ブロックは一つの物理ブロックであってもよいし、一つのスーパーブロックであってもよい。なお、一つのスーパーブロックが一つの物理ブロックのみを含む構成が利用されてもよく、この場合には、一つのスーパーブロックは一つの物理ブロックと等価である。
【００４９】
次に、図１のコントローラ４の構成について説明する。
【００５０】
コントローラ４は、ホストインタフェース１１、ＣＰＵ１２、フラッシュプログラミングコントローラ１３、およびＤＲＡＭインタフェース１４等を含む。これらＣＰＵ１２、フラッシュプログラミングコントローラ１３、ＤＲＡＭインタフェース１４は、バス１０を介して相互接続される。
【００５１】
このホストインタフェース１１は、ホスト２との通信を実行するように構成されたホストインタフェース回路である。このホストインタフェース１１は、例えば、ＰＣＩｅコントローラ（ＮＶＭｅコントローラ）であってもよい。あるいは、フラッシュストレージデバイス３がＥｔｈｅｒｎｅｔ（登録商標）を介してホスト２に接続される構成においては、ホストインタフェース１１は、ＮＶＭｅ  ｏｖｅｒ  Ｆａｂｒｉｃｓ（ＮＶＭｅＯＦ）コントローラであってもよい。フラッシュストレージデバイス３がＥｔｈｅｒｎｅｔ（登録商標）を介してホスト２に接続される構成は、必要に応じて、フラッシュストレージデバイス３の数を容易に増やすことを可能にする。さらに、ホスト２の数を容易に増やすことも可能である。
【００５２】
ホストインタフェース１１は、ホスト２から様々な要求（コマンド）を受信する。これら要求（コマンド）には、ライト要求（ライトコマンド）、リード要求（リードコマンド）、他の様々な要求（コマンド）が含まれる。
【００５３】
ＣＰＵ１２は、ホストインタフェース１１、フラッシュプログラミングコントローラ１３、ＤＲＡＭインタフェース１４を制御するように構成されたプロセッサである。ＣＰＵ１２は、フラッシュストレージデバイス３の電源オンに応答してＮＡＮＤ型フラッシュメモリ５または図示しないＲＯＭから制御プログラム（ファームウェア）をＤＲＡＭ６にロードし、そしてこのファームウェアを実行することによって様々な処理を行う。なお、ファームウェアはコントローラ４内の図示しないＳＲＡＭ上にロードされてもよい。このＣＰＵ１２は、ホスト２からの様々なコマンドを処理するためのコマンド処理等を実行することができる。ＣＰＵ１２の動作は、ＣＰＵ１２によって実行される上述のファームウェアによって制御される。なお、コマンド処理の一部または全部は、コントローラ４内の専用ハードウェアによって実行してもよい。
【００５４】
ＣＰＵ１２は、ブロック識別子／バッファアドレス受信部２１、転送要求送信部２２、および通知部２３として機能することができる。
【００５５】
ブロック識別子／バッファアドレス受信部２１は、ブロック識別子とバッファアドレスとを含むライト要求をホスト２から受信し、これらブロック識別子とバッファアドレスを所定の記憶領域に保持する。ライト要求に含まれるブロック識別子は、ある特定の書き込み先ブロックを指定するブロックアドレスであってもよい。あるいは、ライト要求は、ブロック識別子の代わりに、ストリームＩＤを含んでいてもよい。ブロック識別子またはストリームＩＤは、一つの書き込み先ブロックに関連付けられた識別子として機能する。ライト要求に含まれるバッファアドレスは、書き込むべきデータ（ライトデータ）が格納されているＵＷＢ２Ａ内の位置を示す記憶位置情報である。あるいは、ライト要求は、バッファアドレスの代わりに、バッファ内オフセットを記憶位置情報として含んでいてもよい。バッファ内オフセットは、ライトデータが格納されているＵＷＢ２Ａ内のオフセット位置を示す。
【００５６】
転送要求送信部２２は、上述のライトデータをＮＡＮＤ型フラッシュメモリ５に書き込む際に、記憶位置情報（例えばバッファアドレス）を含む転送要求をホスト２に送出し、これによってライトデータをＵＷＢ２Ａから取得する。
【００５７】
通知部２３は、上述のライトデータの書き込みが終了し且つ上述のライトデータがＮＡＮＤ型フラッシュメモリ５から読み出し可能になった場合、ＵＷＢ２Ａに保持されている上述のライトデータが不要になったことをホスト２に通知する。
【００５８】
フラッシュプログラミングコントローラ１３は、ＣＰＵ１２の制御の下、ＮＡＮＤ型フラッシュメモリ５を制御するように構成されたメモリ制御回路である。
【００５９】
ＤＲＡＭインタフェース１４は、ＣＰＵ１２の制御の下、ＤＲＡＭ６を制御するように構成されたＤＲＡＭ制御回路である。ＤＲＡＭ６の記憶領域の一部は、リードバッファ（ＲＢ）３０、ライトバッファ（ＷＢ）３１、ブロック管理テーブル３２、不良情報管理テーブル３３の格納のために使用される。なお、これらリードバッファ（ＲＢ）３０、ライトバッファ（ＷＢ）３１、ブロック管理テーブル３２、不良情報管理テーブル３３は、コントローラ４内の図示しないＳＲＡＭに格納されてもよい。ブロック管理テーブル３２は、各ブロックに格納されているデータが有効データまたは無効データのいずれであるかを管理する。不良情報管理テーブル３３は、不良ブロックのリストを管理する。
【００６０】
図５は、複数のエンドユーザに対応する複数の書き込み先ブロックと複数のライトバッファ領域との関係を示す。
【００６１】
フラッシュストレージデバイス３においては、ブロックの状態は、有効データを格納しているアクティブブロックと、有効データを格納していないフリーブロックとに大別される。アクティブブロックである各ブロックは、アクティブブロックプールと称されるリストによって管理される。一方、フリーブロックである各ブロックは、フリーブロックプールと称されるリストによって管理される。
【００６２】
本実施形態では、コントローラ４は、フリーブロックプールから選択された複数のブロック（フリーブロック）を、ホスト２から受信されたライトデータが書き込まれるべき書き込み先ブロックとして割り当てる。この場合、コントローラ４は、まず、選択された各ブロック（フリーブロック）に対する消去動作を実行し、これによって各ブロックを、書き込み可能な消去状態にする。書き込み可能な消去状態にされたブロックが、オープンされた書き込み先ブロックとなる。ある書き込み先ブロックの全体がホスト２からのライトデータで満たされると、コントローラ４は、この書き込み先ブロックをアクティブブロックプールに移動し、フリーブロックプールから新たな一つのブロック（フリーブロック）を新たな書き込み先ブロックとして割り当てる。
【００６３】
フラッシュストレージデバイス３においては、フラッシュストレージデバイス３を共有するエンドユーザ（エンドユーザ端末）と同数またはそれよりも多い書き込み先ブロック（フラッシュブロック）がオープンされる。ホスト２側のＵＷＢ２Ａは、これら書き込み先ブロック（フラッシュブロック）と同数のライトバッファ領域（ＵＷＢ領域）を含んでいてもよい。
【００６４】
図５においては、ライトバッファ領域＃１は書き込み先ブロック＃１に関連付けられており、書き込み先ブロック＃１に書き込むべき全てのデータはライトバッファ領域＃１に格納される。ライトバッファ領域＃２は書き込み先ブロック＃２に関連付けられており、書き込み先ブロック＃２に書き込むべき全てのデータはライトバッファ領域＃２に格納される。ライトバッファ領域＃３は書き込み先ブロック＃３に関連付けられており、書き込み先ブロック＃４に書き込むべき全てのデータはライトバッファ領域＃３に格納される。同様に、ライトバッファ領域＃ｎは書き込み先ブロック＃ｎに関連付けられており、書き込み先ブロック＃ｎに書き込むべき全てのデータはライトバッファ領域＃ｎに格納される。
【００６５】
ホスト２は、エンドユーザ端末＃１からのライトデータをライトバッファ領域＃１に格納し、エンドユーザ端末＃２からのライトデータをライトバッファ領域＃２に格納し、エンドユーザ端末＃３からのライトデータをライトバッファ領域＃３に格納し、エンドユーザ端末＃４からのライトデータをライトバッファ領域＃４に格納し、そして、エンドユーザ端末＃ｎからのライトデータをライトバッファ領域＃ｎに格納する。
【００６６】
ホスト２は、書き込み先ブロック＃１に関連付けられた識別子と、エンドユーザ端末＃１からのライトデータが格納されているライトバッファ領域＃１内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス３に送出する。書き込み先ブロック＃１に関連付けられた識別子は、書き込み先ブロック＃１を指定するブロック識別子（ブロックアドレス）であってもよいし、書き込み先ブロック＃１に関連付けられストリームＩＤであってもよい。
【００６７】
フラッシュストレージデバイス３は、この記憶位置情報を含む転送要求をホスト２に送出することによって１物理ページのサイズに相当するライトデータ（例えば、ＴＬＣ−フラッシュメモリの場合には３ページ分のライトデータ）をライトバッファ領域＃１から取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック＃１に関連付けられた識別子（例えば、書き込み先ブロック＃１を指定するブロック識別子、または書き込み先ブロック＃１に関連付けられストリームＩＤ）を含んでいてもよい。これにより、ホスト２は、フラッシュストレージデバイス３に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置（記憶位置）とを容易に特定することができる。
【００６８】
ホスト２は、書き込み先ブロック＃２に関連付けられた識別子（例えば、書き込み先ブロック＃２を指定するブロック識別子、または書き込み先ブロック＃２に関連付けられストリームＩＤ）と、エンドユーザ端末＃２からのライトデータが格納されているライトバッファ領域＃２内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス３に送出する。
【００６９】
フラッシュストレージデバイス３は、この記憶位置情報を含む転送要求をホスト２に送出することによって１物理ページのサイズに相当するライトデータ（例えば、ＴＬＣ−フラッシュメモリの場合には３ページ分のライトデータ）をライトバッファ領域＃２から取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック＃２に関連付けられた識別子（例えば、書き込み先ブロック＃２を指定するブロック識別子、または書き込み先ブロック＃２に関連付けられストリームＩＤ）を含んでいてもよい。これにより、ホスト２は、フラッシュストレージデバイス３に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置（記憶位置）とを容易に特定することができる。
【００７０】
同様に、ホスト２は、書き込み先ブロック＃ｎに関連付けられた識別子（例えば、書き込み先ブロック＃ｎを指定するブロック識別子、または書き込み先ブロック＃ｎに関連付けられストリームＩＤ）と、エンドユーザ端末＃ｎからのライトデータが格納されているライトバッファ領域＃ｎ内の位置を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス３に送出する。
【００７１】
フラッシュストレージデバイス３は、この記憶位置情報を含む転送要求をホスト２に送出することによって１物理ページのサイズに相当するライトデータ（例えば、ＴＬＣ−フラッシュメモリの場合には３ページ分のライトデータ）をライトバッファ領域＃ｎから取得する。なお、この転送要求は、記憶位置情報のみならず、書き込み先ブロック＃ｎに関連付けられた識別子（例えば、書き込み先ブロック＃ｎを指定するブロック識別子、または書き込み先ブロック＃ｎに関連付けられストリームＩＤ）を含んでいてもよい。これにより、ホスト２は、フラッシュストレージデバイス３に転送すべきライトデータが格納されているライトバッファ領域とこのライトバッファ領域内の位置（記憶位置）とを容易に特定することができる。
【００７２】
図６は、フラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ書き込み処理を示す。
【００７３】
ここでは、図示を簡単にするために、ある一つの書き込み先ブロックＢＬＫに対するデータ書き込み処理を例示して説明する。また、ここでは、フル・シーケンス・プログラム動作によってライトデータを一つの書き込み先ブロックＢＬＫに書き込む場合を想定する。
【００７４】
（１）  ホスト２においては、フラッシュストレージデバイス３を管理するホストソフトウェアであるフラッシュストレージマネージャが実行される。フラッシュストレージマネージャは、フラッシュストレージデバイス３用のデバイスドライバ内に組み込まれていてもよい。フラッシュストレージマネージャは、ＵＷＢ２Ａを管理する。上位ソフトウェア（アプリケーションプログラムまたはファイルシステム）からのデータを書き込む要求に応じて、フラッシュストレージマネージャは、書き込むべきデータ、タグ、ブロック識別子を伴うライト要求をＵＷＢ２Ａに格納する。タグは、このデータを識別可能な識別子である。タグは、論理ブロックアドレス（ＬＢＡ）のような論理アドレスであってもよいし、キー・バリュー・ストアのキーであってもよいし、ファイル名のようなファイル識別子であってもよい。ブロック識別子は、書き込み先ブロックＢＬＫのブロックアドレスであってもよい。なお、このライト要求は、書き込むべきデータの長さ（Ｌｅｎｇｔｈ）を含んでもよいし、固定長のライトデータの書き込みを要求するケースにおいては、このライト要求は、長さ（Ｌｅｎｇｔｈ）を含まなくてもよい。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をＵＷＢ２Ａに格納してもよい。
【００７５】
（２）  フラッシュストレージマネージャは、フラッシュストレージデバイス３にライト要求（ライトコマンド）を送出する。このライト要求は、タグ、ブロック識別子（ブロックアドレス）、バッファアドレス（またはバッファ内オフセット）を含む。バッファアドレスは、書き込むべきデータが格納されているＵＷＢ２Ａ内の位置を示す。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。フラッシュストレージデバイス３のコントローラ４は、このライト要求を受信し、このライト要求に含まれるタグ、ブロック識別子、バッファアドレス（またはバッファ内オフセット）を保持する。
【００７６】
（３）  フラッシュプログラミングコントローラ１３がこのデータを書き込み先ブロックＢＬＫに書き込む際に、フラッシュストレージデバイス３のコントローラ４は、転送要求（Ｔｒａｎｓｆｅｒ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、この転送要求は、保持されているタグと、保持されているバッファアドレス（またはバッファ内オフセット）とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）と、保持されているブロック識別子（ブロックアドレス）を含んでいてもよい。
【００７７】
（４）  ホスト２のフラッシュストレージマネージャは、少なくともバッファアドレス（またはバッファ内オフセット）を含む転送要求を受信すると、このバッファアドレス（またはバッファ内オフセット）によって指定されるＵＷＢ２Ａ内の位置に格納されているデータをＵＷＢ２Ａからフラッシュストレージデバイス３に転送する。例えば、ＮＡＮＤ型フラッシュメモリ５がＴＬＣ−フラッシュメモリである場合には、３ページ分のデータがＵＷＢ２Ａからフラッシュストレージデバイス３に転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
【００７８】
（５）  フラッシュストレージデバイス３のコントローラ４は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ１３を介してＮＡＮＤ型フラッシュメモリ５に転送し、このデータを書き込み先ブロックＢＬＫに書き込む。フル・シーケンス・プログラム動作によって３ページ分のデータをある物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ１３は、３ページ分のデータをＮＡＮＤ型フラッシュメモリ５内のページバッファ群に順次転送し、そして書き込み指示をＮＡＮＤ型フラッシュメモリ５に送出する。フラッシュプログラミングコントローラ１３は、ＮＡＮＤ型フラッシュメモリ５からのステータスをモニタすることによって書き込み動作（フル・シーケンス・プログラム動作）が終了したかどうかを判定することができる。
【００７９】
（６）  書き込み動作が終了し且つこのデータ（ここでは３ページ分のデータ）の読み出しが可能になった場合、つまりフル・シーケンス・プログラム動作が成功で終了した場合、コントローラ４は、ＵＷＢ２Ａに保持されているこのデータ（ここでは３ページ分のデータ）が不要になったことをホスト２に通知する。この場合、フラッシュストレージデバイス３のコントローラ４は、タグ、ページアドレス、長さを含む書き込み完了（Ｗｒｉｔｅ  Ｄｏｎｅ）をホスト２に送出してもよいし、無効化要求（ｉｎｖａｌｉｄａｔｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、無効化要求は、読み出し可能になったデータのタグと、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含んでいてもよい。あるいは、この書き込み先ブロックＢＬＫの最後の物理ページへのフル・シーケンス・プログラム動作が終了してこの書き込み先ブロックＢＬＫの全体がデータで満たされた場合には、コントローラ４は、書き込み先ブロックＢＬＫに対応するＵＷＢ領域が不要になったことをホスト２に通知する。この場合、コントローラ４は、クローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。クローズ要求は、書き込み先ブロックＢＬＫのブロック識別子（ブロックアドレス）を含んでいてもよい。書き込み先ブロックＢＬＫのブロック識別子を含むクローズ要求を受信した場合、ホスト２のフラッシュストレージマネージャは、この書き込み先ブロックＢＬＫに関連づけられているＵＷＢ領域を解放し、このＵＷＢ領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したＵＷＢ領域を、他の書き込み先ブロック（例えば新たにオープンされた書き込み先ブロック）用のＵＷＢ領域として再利用してもよい。
【００８０】
図７は、複数の書き込み先ブロックと複数のライトバッファ領域（ＵＷＢ領域）との関係の例を示す。
【００８１】
ある書き込み先ブロックＢＬＫ＃１に対応するライトバッファ領域（ＵＷＢ領域＃１）は、例えば、複数ページ分のデータを一時的に格納するための複数の記憶領域を含んでいてもよい。この場合、各記憶領域は、タグフィールド、バリッド／インバリッドフィールド、データ記憶フィールド、ページアドレスフィールドを含んでいてもよい。タグフィールドは、対応するデータのタグを格納する。バリッド／インバリッドフィールドは、対応するデータを保持することが必要であるか否かを示すバリッド／インバリッドフラグを保持する。データ記憶フィールドは、書き込み先ブロックＢＬＫ＃１に書き込むべきデータを格納する。データ記憶フィールドは１ページ分のサイズを有していてもよい。ページアドレスフィールドはオプショナルなフィールドであり、ライト要求がページアドレスを含むならば、このページアドレスがページアドレスフィールドに格納される。
【００８２】
ＵＷＢ領域＃１に保持されているあるデータが不要になったことがフラッシュストレージデバイス３から通知された場合、ホスト２（フラッシュストレージマネージャ）は、このデータに対応する記憶領域内のバリッド／インバリッドフラグを無効を示す値に更新する。バリッド／インバリッドフラグを無効を示す値に更新された記憶領域は、書き込み先ブロックＢＬＫ＃１に書き込むべき他のデータの格納に再利用される。
【００８３】
図７に示されるＵＷＢ領域のデータ構造は一例であり、例えば、ページサイズとは異なるサイズでデータ（ライトデータ）がＵＷＢ領域で管理されてもよい。
【００８４】
図８は、フラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ読み出し処理を示す。
【００８５】
（１）  上位ソフトウェアからのデータをリードするための要求に応答して、ホスト２のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス３に送出する。このリード要求は、たとえば、タグ、ブロック識別子（ブロックアドレス）、ページアドレス、長さを含んでいてもよい。
【００８６】
（２）  このリード要求で指定されたデータの書き込み先ブロックＢＬＫへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、フラッシュストレージデバイス３のコントローラ４は、フラッシュプログラミングコントローラ１３を介してこのデータを書き込み先ブロックＢＬＫからリードする。
【００８７】
（３）  フラッシュストレージデバイス３のコントローラ４は、リードされたデータを、このデータのタグと一緒に、ホスト２に送出する。
【００８８】
（３’）  このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト２から受信した場合、フラッシュストレージデバイス３のコントローラ４は、ＵＷＢ２Ａからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト２に送出する。この転送要求は、転送すべきＵＷＢ２Ａ内のデータを特定可能な情報として、このデータに対応するバッファアドレス、またはこのデータに対応するバッファアドレスとこのデータに対応するブロック識別子の双方を含んでいてもよい。あるいは、この転送要求は、このデータに対応するタグを含んでいてもよいし、このデータに対応するブロック識別子とページアドレスを含んでいてもよい。
【００８９】
（４’）  ホスト２のフラッシュストレージマネージャは、このデータをＵＷＢ２Ａからリードし、リードしたデータを、このデータのタグと一緒に、上位ソフトウェアに返す。
【００９０】
あるいは、ホスト２のフラッシュストレージマネージャは、ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス３に送出せずに、このデータをＵＷＢ２Ａから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
【００９１】
（１”）  ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、ホスト２のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をＵＷＢ２Ａに送出してこのデータをＵＷＢ２Ａからリードする。このリード要求は、例えば、タグ、バッファアドレス、長さを含んでいてもよい。
【００９２】
（２”）  フラッシュストレージマネージャは、ＵＷＢ２Ａからリードされたデータを、このデータのタグと一緒に上位ソフトウェアに返す。
【００９３】
図９は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ書き込み処理を示す。
【００９４】
ここでは、複数段階の書き込み動作（フォギー・ファイン・プログラム動作）によってライトデータを一つの書き込み先ブロックＢＬＫに書き込む場合を想定する。
【００９５】
（１）  ホスト２においては、フラッシュストレージマネージャは、上位ソフトウェアからのデータを書き込む要求に応じて、書き込むべきデータ、タグ、ブロック識別子を伴うライト要求をＵＷＢ２Ａに格納する。なお、このライト要求は、書き込むべきデータの長さ（Ｌｅｎｇｔｈ）を含んでもよいし、固定長のライトデータの書き込みを要求するケースにおいては、このライト要求は、長さ（Ｌｅｎｇｔｈ）を含まなくてもよい。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をＵＷＢ２Ａに格納してもよい。
【００９６】
（２）  フラッシュストレージマネージャは、フラッシュストレージデバイス３にライト要求（ライトコマンド）を送出する。このライト要求は、タグ、ブロック識別子（ブロックアドレス）、バッファアドレス（またはバッファ内オフセット）を含む。また、このライト要求は、データを書き込むべきページを示すページアドレスを含んでいてもよい。フラッシュストレージデバイス３のコントローラ４は、このライト要求を受信し、このライト要求に含まれるタグ、ブロック識別子、バッファアドレス（またはバッファ内オフセット）を保持する。
【００９７】
（３）  フラッシュプログラミングコントローラ１３がこのデータの一段階目の書き込み動作（フォギー書き込み）を開始する際に、フラッシュストレージデバイス３のコントローラ４は、転送要求（Ｔｒａｎｓｆｅｒ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、この転送要求は、保持されているタグと、保持されているバッファアドレス（またはバッファ内オフセット）とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）と、保持されているブロック識別子（ブロックアドレス）を含んでいてもよい。
【００９８】
（４）  ホスト２のフラッシュストレージマネージャは、少なくともバッファアドレス（またはバッファ内オフセット）を含む転送要求を受信すると、このバッファアドレス（またはバッファ内オフセット）によって指定されるＵＷＢ２Ａ内の位置に格納されているデータ（ここでは、「Ｆｏｇｇｙ  Ｄａｔａ」として図示されている）をＵＷＢ２Ａからフラッシュストレージデバイス３に転送する。例えば、ＮＡＮＤ型フラッシュメモリ５がＴＬＣ−フラッシュメモリである場合には、３ページ分のデータがＵＷＢ２Ａからフラッシュストレージデバイス３にＦｏｇｇｙ  Ｄａｔａとして転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
【００９９】
（５）  フラッシュストレージデバイス３のコントローラ４は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ１３を介してＮＡＮＤ型フラッシュメモリ５に転送し、このデータを書き込み先ブロックＢＬＫの書き込み先物理ページに書き込む（一段階目の書き込み：フォギー書き込み）。フォギー書き込みによって３ページ分のデータをある書き込み先物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ１３は、３ページ分のデータをＮＡＮＤ型フラッシュメモリ５内のページバッファ群に順次転送し、そして一段階目の書き込み指示をＮＡＮＤ型フラッシュメモリ５に送出する。フラッシュプログラミングコントローラ１３は、ＮＡＮＤ型フラッシュメモリ５からのステータスをモニタすることによって書き込み動作（一段階目の書き込み動作）が終了したかどうかを判定することができる。通常、フォギー・ファイン・プログラム動作は、プログラムディスターブを削減するために、例えば、物理ページ＃１のフォギー書き込み、物理ページ＃２のフォギー書き込み、物理ページ＃１のファイン書き込み、物理ページ＃２のファイン書き込みのように、複数のワード線（複数の物理ページ）を往復しながら実行される。
【０１００】
（６）  この書き込み先物理ページへの二段階目の書き込み（ファイン書き込み）を実行するタイミングが到来すると、フラッシュストレージデバイス３のコントローラ４は、ファイン書き込みで書き込まれるべきデータ（フォギー書き込みで書き込まれたデータと同じデータ）を取得するために、転送要求（Ｔｒａｎｓｆｅｒ  Ｒｅｑｕｅｓｔ）をホスト２に再び送出する。この転送要求は、上述の保持されているバッファアドレス、つまり、処理（３）で送出した転送要求に含まれていたバッファアドレスと同じバッファアドレスを含む。
【０１０１】
（７）  ホスト２のフラッシュストレージマネージャは、少なくともバッファアドレス（またはバッファ内オフセット）を含む転送要求を受信すると、このバッファアドレス（またはバッファ内オフセット）によって指定されるＵＷＢ２Ａ内の位置に格納されているデータ（ここでは、「Ｆｉｎｅ  Ｄａｔａ」として図示されている）をＵＷＢ２Ａからフラッシュストレージデバイス３に転送する。Ｆｉｎｅ  Ｄａｔａは、Ｆｏｇｇｙ  Ｄａｔａと同じデータである。例えば、ＮＡＮＤ型フラッシュメモリ５がＴＬＣ−フラッシュメモリである場合には、上述の３ページ分のデータがＵＷＢ２Ａからフラッシュストレージデバイス３にＦｉｎｅ  Ｄａｔａとして転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。なお、ホスト２は、転送すべきデータがＦｏｇｇｙ  ＤａｔａまたはＦｉｎｅ  Ｄａｔａのいずれであるかを認識する必要は無い。
【０１０２】
（８）  フラッシュストレージデバイス３のコントローラ４は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ１３を介してＮＡＮＤ型フラッシュメモリ５に転送し、このデータを書き込み先ブロックＢＬＫの上述の書き込み先物理ページに書き込む（二段階目の書き込み：ファイン書き込み）。ファイン書き込みによって３ページ分のデータをこの書き込み先物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ１３は、フォギー書き込みで使用した３ページ分のデータと同じ３ページ分のデータをＮＡＮＤ型フラッシュメモリ５内のページバッファ群に順次転送し、そして二段階目の書き込み指示をＮＡＮＤ型フラッシュメモリ５に送出する。フラッシュプログラミングコントローラ１３は、ＮＡＮＤ型フラッシュメモリ５からのステータスをモニタすることによって書き込み動作（二段階目の書き込み動作）が終了したかどうかを判定することができる。
【０１０３】
（９）二段階目の書き込み動作が終了し且つこのデータ（ここでは３ページ分のデータ）の読み出しが可能になった場合、つまりフォギー・ファイン・プログラム動作全てが成功で終了した場合、コントローラ４は、ＵＷＢ２Ａに保持されているこのデータ（ここでは３ページ分のデータ）が不要になったことをホスト２に通知する。この場合、フラッシュストレージデバイス３のコントローラ４は、タグ、ページアドレス、長さを含む書き込み完了（Ｗｒｉｔｅ  Ｄｏｎｅ）をホスト２に送出してもよいし、無効化要求（ｉｎｖａｌｉｄａｔｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、無効化要求は、読み出し可能になったデータのタグと、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含んでいてもよい。あるいは、この書き込み先ブロックＢＬＫの最後の物理ページへのフォギー・ファイン・プログラム動作が終了してこの書き込み先ブロックＢＬＫの全体がデータで満たされた場合には、コントローラ４は、書き込み先ブロックＢＬＫに対応するＵＷＢ領域が不要になったことをホスト２に通知する。この場合、コントローラ４は、クローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。クローズ要求は、書き込み先ブロックＢＬＫのブロック識別子（ブロックアドレス）を含んでいてもよい。書き込み先ブロックＢＬＫのブロック識別子を含むクローズ要求を受信した場合、ホスト２のフラッシュストレージマネージャは、この書き込み先ブロックＢＬＫに関連づけられているＵＷＢ領域を解放し、このＵＷＢ領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したＵＷＢ領域を、他の書き込み先ブロック（例えば新たにオープンされた書き込み先ブロック）用のＵＷＢ領域として再利用してもよい。
【０１０４】
図１０は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ読み出し処理を示す。
【０１０５】
（１）  上位ソフトウェアからのデータをリードするための要求に応答して、ホスト２のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス３に送出する。このリード要求は、たとえば、タグ、ブロック識別子（ブロックアドレス）、ページアドレス、長さを含んでいてもよい。
【０１０６】
（２）  このリード要求で指定されたデータの書き込み先ブロックＢＬＫへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、つまりこのデータのフォギー書き込みとこのデータのファイン書き込みの双方が終了しているならば、フラッシュストレージデバイス３のコントローラ４は、フラッシュプログラミングコントローラ１３を介してこのデータを書き込み先ブロックＢＬＫからリードする。
【０１０７】
（３）  フラッシュストレージデバイス３のコントローラ４は、リードされたデータを、このデータのタグと一緒に、ホスト２に送出する。
【０１０８】
（３’）  このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト２から受信した場合、フラッシュストレージデバイス３のコントローラ４は、ＵＷＢ２Ａからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト２に送出する。この転送要求は、このデータに対応するバッファアドレスを含んでいてもよい。
【０１０９】
（４’）  ホスト２のフラッシュストレージマネージャは、このデータをＵＷＢ２Ａからリードし、リードしたデータを、このデータのタグと一緒に、上位ソフトウェアに返す。
【０１１０】
あるいは、ホスト２のフラッシュストレージマネージャは、ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス３に送出せずに、このデータをＵＷＢ２Ａから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
【０１１１】
（１”）  ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、ホスト２のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をＵＷＢ２Ａに送出してこのデータをＵＷＢ２Ａからリードする。このリード要求は、例えば、タグ、バッファアドレス、長さを含んでいてもよい。
【０１１２】
（２”）  フラッシュストレージマネージャは、ＵＷＢ２Ａからリードされたデータを、このデータのタグと一緒に上位ソフトウェアに返す。
【０１１３】
図１１のシーケンス図は、ホスト２とフラッシュストレージデバイス２とによって実行されるデータ書き込み処理の手順を示す。
【０１１４】
ホスト２は、ある書き込み先ブロックに書き込むべきデータ（ライトデータ）をこの書き込み先ブロックに関連づけられたＵＷＢ領域に格納し、そしてブロック識別子とバッファアドレス（またはバッファ内オフセット）とを含むライト要求をフラッシュストレージデバイス３に送出する（ステップＳ１１）。ブロック識別子は、このライトデータが書き込まれるべき書き込み先ブロックのブロックアドレスである。バッファアドレスは、このライトデータが格納されているＵＷＢ領域内の位置を示す。
【０１１５】
フラッシュストレージデバイス３のコントローラ４は、このライト要求をホスト２から受信し、このライト要求内のブロック識別子とバッファアドレス（またはバッファ内オフセット）を保持する（ステップＳ２１）。この場合、コントローラ４は、ブロック識別子とバッファアドレスをＤＲＡＭ６上のライトバッファ３１に格納することによってこれらブロック識別子とバッファアドレスを保持してもよい。
【０１１６】
保持しているブロック識別子によって指定される書き込み先ブロックにこのライト要求に対応するライトデータを書き込む際、フラッシュストレージデバイス３のコントローラ４は、保持しているバッファアドレス（またはバッファ内オフセット）を含む転送要求をホスト２に送出する（ステップＳ２２）。
【０１１７】
ホスト２がこの転送要求を受信すると、ホスト２は、このライトデータをＵＷＢ領域からフラッシュストレージデバイス３に転送する（ステップＳ１２）。
【０１１８】
フラッシュストレージデバイス３のコントローラ４は、ホスト２から転送されるこのライトデータを受信する（ステップＳ２３）。コントローラ４は、受信したライトデータを例えばＤＲＡＭ６上のライトバッファ３１等に格納することによって保持する（ステップＳ２４）。
【０１１９】
コントローラ４は、受信したライトデータをＮＡＮＤ型フラッシュメモリ５に転送する（ステップＳ２５）。ＮＡＮＤ型フラッシュメモリ５へのライトデータの転送が完了するまで、コントローラ４は、このライトデータを保持する。そして、コントローラ４は、このライトデータを、保持しているブロック識別子によって指定される書き込み先ブロックに書き込む（ステップＳ２６）。この場合、ライトデータが書き込まれるべき書き込み先ブロック内の書き込み先ページはコントローラ４によって決定される。なお、ライト要求が書き込み先ページを指定するページアドレスを含んでいてもよい。
【０１２０】
このライトデータの書き込み動作が終了し且つこのライトデータが読み出し可能になった場合（フル・シーケンス・プログラム動作においてはフル・シーケンス・プログラム動作が終了した場合）、コントローラ４は、ＵＷＢ領域に格納されているこのライトデータが不要になったことをホスト２に通知する（ステップＳ２７）。
【０１２１】
図１２のフローチャートは、フラッシュストレージデバイス３によって実行される通知処理の手順を示す。
【０１２２】
フラッシュストレージデバイス３のコントローラ４は、書き込み先ブロックへのデータの書き込み動作が終了し且つこのデータが読み出し可能になったか否かを判定する（ステップＳ３１）。
【０１２３】
データの書き込み動作が終了し且つこのデータが読み出し可能になったならば（ステップＳ３１のＹＥＳ）、コントローラ４は、この書き込み先ブロックの最後のページ（最後の物理ページ）への書き込み動作が終了してこの書き込み先ブロックの全体がデータで満たされたか否かを判定する（ステップＳ３２）。
【０１２４】
この書き込み先ブロックに利用可能な物理ページ（未書き込みの物理ページ）が残っているならば（ステップＳ３２のＮＯ）、コントローラ４は、ＵＷＢ領域に保持されている読み出し可能になったデータが不要になったことをホスト２に通知するために、書き込み完了（Ｗｒｉｔｅ  Ｄｏｎｅ）または無効化要求（ｉｎｖａｌｉｄａｔｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出する（ステップＳ３３）。
【０１２５】
この書き込み先ブロックの最後のページ（最後の物理ページ）への書き込み動作が終了してこの書き込み先ブロックの全体がデータで満たされたならば（ステップＳ３２のＹＥＳ）、コントローラ４は、この書き込み先ブロックに対応するＵＷＢ領域全体が不要になったことをホスト２に通知するために、クローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出する（ステップＳ３４）。
【０１２６】
図１３のフローチャートは、転送要求の受信に応じて実行されるホスト側処理の手順を示す。
【０１２７】
ホスト２は、ブロック識別子とバッファアドレス（またはバッファ内オフセット）とを含むライト要求をフラッシュストレージデバイス３に送出する（ステップＳ４０）。ホスト２は、フラッシュストレージデバイス３から転送要求が受信された否かを判定する（ステップＳ４１）。
【０１２８】
フラッシュストレージデバイス３から転送要求が受信されたならば（ステップＳ４１のＹＥＳ）、ホスト２は、転送要求内のバッファアドレス（またはバッファ内オフセット）によって指定されるＵＷＢ領域内の位置に格納されているデータをフラッシュストレージデバイス３に転送する（ステップＳ４２）。そして、ホスト２は、ＵＷＢ領域内の不要データがフラッシュストレージデバイス３から通知されたか否か、またはクローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）がフラッシュストレージデバイス３から受信されたか否かを判定する（ステップＳ４３、Ｓ４４）。
【０１２９】
ＵＷＢ領域内の不要データがフラッシュストレージデバイス３から通知されたならば（ステップＳ４３のＹＥＳ）、ホスト２は、この不要データに対応するバリッド／インバリッドフラグを無効を示す値に更新して、この不要データが格納されているＵＷＢ領域内の一つの記憶領域を解放する（ステップＳ４４）。ホスト２は、この解放された記憶領域を、このＵＷＢ領域に対応する書き込み先ブロックに書き込むべき新たなライトデータのための記憶領域として再利用することができる。
【０１３０】
このように、本実施形態では、あるデータの書き込み動作が終了してこのデータが読み出し可能になると、ＵＷＢ領域内のこのデータが不要になったことがフラッシュストレージデバイス３からホスト２に通知される。したがって、このデータがＮＡＮＤ型フラッシュメモリ５から読み出し可能になるまでは、このデータはＵＷＢ領域内に保持される。
【０１３１】
クローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）がフラッシュストレージデバイス３から受信されたならば（ステップＳ４５のＹＥＳ）、ホスト２は、クローズ要求に含まれるブロック識別子の書き込み先ブロックに関連付けられたＵＷＢ領域全体を解放する（ステップＳ４６）。ホスト２は、この解放されたＵＷＢ領域を、フラッシュストレージデバイス３によって新たに割り当てられた書き込み先ブロック用のＵＷＢ領域として再利用することができる。
【０１３２】
図１４のフローチャートは、リード要求の受信に応じてフラッシュストレージデバイス３によって実行されるデータ読み出し動作の手順を示す。
【０１３３】
フラッシュストレージデバイス３のコントローラ４は、リード要求をホスト２から受信する（ステップＳ５１）。コントローラ４は、リード要求によって指定されたリードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータであるか否かを判定する（ステップＳ５２）。
【０１３４】
リードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータであるならば（ステップＳ５２のＹＥＳ）、コントローラ４は、リードすべきデータをＮＡＮＤ型フラッシュメモリ５からリードし（ステップＳ５３）、このリードしたデータをホスト２に返す（ステップＳ５４）。
【０１３５】
一方、リードすべきデータが、書き込み先ブロックへの書き込み動作が終了し且つ読み出し可能なデータではないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間内にこのデータに対するリード要求がホスト２から受信されたならば（ステップＳ５２のＮＯ）、コントローラ４は、ＵＷＢ領域からこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト２に送出する（ステップＳ５５）。
【０１３６】
図１５のフローチャートは、データ読み出しのためのホスト側処理の手順を示す。
【０１３７】
ホスト２は、リードすべきデータがＵＷＢ領域内に存在するか否かにかかわらず、このデータのリードを要求するリード要求をフラッシュストレージデバイス３に送出する（ステップＳ６１）。
【０１３８】
そして、ホスト２は、ＵＷＢ領域からこのデータを返す（リードする）ように要求する転送要求がフラッシュストレージデバイス３から受信されたか否かを判定する（ステップＳ６２）。
【０１３９】
この転送要求がフラッシュストレージデバイス３から受信されたならば（ステップＳ６２のＹＥＳ）、ホスト２は、このデータをＵＷＢ領域からリードする（ステップＳ６３）。
【０１４０】
図１６は、ストリーム書き込みをサポートするフラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ書き込み処理を示す。
【０１４１】
ここでは、フル・シーケンス・プログラム動作によってライトデータを一つの書き込み先ブロックＢＬＫに書き込む場合を想定する。
【０１４２】
（１）  ホスト２においては、上位ソフトウェア（アプリケーションプログラムまたはファイルシステム）からのデータを書き込む要求に応じて、フラッシュストレージマネージャは、書き込むべきデータ、ストリームＩＤ、ＬＢＡ、長さを伴うライト要求をＵＷＢ２Ａに格納する。ストリームＩＤは、複数の書き込み先ブロックに関連付けられている複数のストリーム内のあるストリームの識別子である。なお、上位ソフトウェアがこのライト要求を発行してもよく、そしてフラッシュストレージマネージャがこのライト要求を上位ソフトウェアから受信し、受信したライト要求をＵＷＢ２Ａに格納してもよい。
【０１４３】
（２）  フラッシュストレージマネージャは、フラッシュストレージデバイス３にライト要求（ライトコマンド）を送出する。このライト要求は、ストリームＩＤ、ＬＢＡ、長さ、バッファアドレス（またはバッファ内オフセット）を含む。バッファアドレスは、書き込むべきデータが格納されているＵＷＢ２Ａ内の位置を示す。フラッシュストレージデバイス３のコントローラ４は、このライト要求を受信し、このライト要求に含まれるストリームＩＤ、ＬＢＡ、長さ、バッファアドレスを保持する。
【０１４４】
（３）  フラッシュプログラミングコントローラ１３がこのデータを書き込み先ブロックＢＬＫに書き込む際に、フラッシュストレージデバイス３のコントローラ４は、転送要求（Ｔｒａｎｓｆｅｒ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、この転送要求は、保持されているＬＢＡと、保持されているバッファアドレス（またはバッファ内オフセット）とを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）と、保持されているストリームＩＤを含んでいてもよい。あるいは、この転送要求は、保持されているバッファアドレス（またはバッファ内オフセット）と、保持されているストリームＩＤに関連付けられている書き込み先ブロックのブロック識別子（ブロックアドレス）を含んでもよい。
【０１４５】
（４）  ホスト２のフラッシュストレージマネージャは、少なくともバッファアドレス（またはバッファ内オフセット）を含む転送要求を受信すると、このバッファアドレス（またはバッファ内オフセット）によって指定されるＵＷＢ２Ａ内の位置に格納されているデータをＵＷＢ２Ａからフラッシュストレージデバイス３に転送する。例えば、ＮＡＮＤ型フラッシュメモリ５がＴＬＣ−フラッシュメモリである場合には、３ページ分のデータがＵＷＢ２Ａからフラッシュストレージデバイス３に転送される。転送要求は、転送されるべきデータの長さを含んでいてもよい。
【０１４６】
（５）  フラッシュストレージデバイス３のコントローラ４は、このデータを受信し、そしてこのデータをフラッシュプログラミングコントローラ１３を介してＮＡＮＤ型フラッシュメモリ５に転送し、このデータを書き込み先ブロックＢＬＫに書き込む。フル・シーケンス・プログラム動作によって３ページ分のデータをある物理ページに書き込むケースにおいては、フラッシュプログラミングコントローラ１３は、３ページ分のデータをＮＡＮＤ型フラッシュメモリ５内のページバッファ群に順次転送し、そして書き込み指示をＮＡＮＤ型フラッシュメモリ５に送出する。フラッシュプログラミングコントローラ１３は、ＮＡＮＤ型フラッシュメモリ５からのステータスをモニタすることによって書き込み動作（フル・シーケンス・プログラム動作）が終了したかどうかを判定することができる。
【０１４７】
（６）  書き込み動作が終了し且つこのデータ（ここでは３ページ分のデータ）の読み出しが可能になった場合、つまりフル・シーケンス・プログラム動作が成功で終了した場合、コントローラ４は、ＵＷＢ２Ａに保持されているこのデータ（ここでは３ページ分のデータ）が不要になったことをホスト２に通知する。この場合、フラッシュストレージデバイス３のコントローラ４は、ＬＢＡ、長さを含む書き込み完了（Ｗｒｉｔｅ  Ｄｏｎｅ）をホスト２に送出してもよいし、無効化要求（ｉｎｖａｌｉｄａｔｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出してもよい。無効化要求は、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含む。あるいは、無効化要求は、読み出し可能になったデータのＬＢＡと、読み出し可能になったデータが格納されているバッファアドレス（またはバッファ内オフセット）を含んでいてもよい。あるいは、この書き込み先ブロックＢＬＫの最後の物理ページへのフル・シーケンス・プログラム動作が終了してこの書き込み先ブロックＢＬＫの全体がデータで満たされた場合には、コントローラ４は、書き込み先ブロックＢＬＫに対応するＵＷＢ領域が不要になったことをホスト２に通知する。この場合、コントローラ４は、クローズ要求（Ｃｌｏｓｅ  Ｒｅｑｕｅｓｔ）をホスト２に送出する。クローズ要求は、書き込み先ブロックＢＬＫのブロック識別子（ブロックアドレス）を含んでいてもよい。書き込み先ブロックＢＬＫのブロック識別子を含むクローズ要求を受信した場合、ホスト２のフラッシュストレージマネージャは、この書き込み先ブロックＢＬＫに関連づけられているＵＷＢ領域を解放し、このＵＷＢ領域を他の用途に使用する。この場合、フラッシュストレージマネージャは、この解放したＵＷＢ領域を、他の書き込み先ブロック（例えば新たにオープンされた書き込み先ブロック）用のＵＷＢ領域として再利用してもよい。
【０１４８】
図１７は、複数のストリームＩＤとこれらストリームＩＤに関連付けられた複数の書き込み先ブロックとの関係を示す。
【０１４９】
ここでは、ストリームＩＤ＃１のストリームに書き込み先フロックＢＬＫ＃１が関連付けられており、ストリームＩＤ＃２のストリームに書き込み先フロックＢＬＫ＃２が関連付けられており、ストリームＩＤ＃３のストリームに書き込み先フロックＢＬＫ＃３が関連付けられており、そしてストリームＩＤ＃ｎのストリームに書き込み先フロックＢＬＫ＃ｎが関連付けられている場合が例示されている。
【０１５０】
ストリームＩＤ＃１を含むライト要求によって指定されるライトデータは、書き込み先フロックＢＬＫ＃１に書き込まれる。ストリームＩＤ＃２を含むライト要求によって指定されるライトデータは、書き込み先フロックＢＬＫ＃２に書き込まれる。ストリームＩＤ＃３を含むライト要求によって指定されるライトデータは、書き込み先フロックＢＬＫ＃３に書き込まれる。ストリームＩＤ＃ｎを含むライト要求によって指定されるライトデータは、書き込み先フロックＢＬＫ＃ｎに書き込まれる。
【０１５１】
図１８は、ストリーム書き込みをサポートするフラッシュストレージデバイス３とホスト側ＵＷＢ２Ａとの関係とホスト２とフラッシュストレージデバイス３とによって実行されるデータ読み出し処理を示す。
【０１５２】
（１）  上位ソフトウェアからのデータをリードするための要求に応答して、ホスト２のフラッシュストレージマネージャは、このデータをリードするためのリード要求をフラッシュストレージデバイス３に送出する。このリード要求は、たとえば、ＬＢＡ、長さを含んでいてもよい。
【０１５３】
（２）  このリード要求で指定されたデータの書き込み先ブロックＢＬＫへの書き込み動作が既に終了し且つこのデータが読み出し可能であるならば、フラッシュストレージデバイス３のコントローラ４は、フラッシュプログラミングコントローラ１３を介してこのデータを書き込み先ブロックＢＬＫからリードする。
【０１５４】
（３）  フラッシュストレージデバイス３のコントローラ４は、リードされたデータを、このデータのＬＢＡと一緒に、ホスト２に送出する。
【０１５５】
（３’）  このリード要求で指定されたデータが読み出し可能でないならば、つまりこのデータの書き込み開始からこのデータが読み出し可能になるまでの期間中にこのデータをリードするためのリード要求をホスト２から受信した場合、フラッシュストレージデバイス３のコントローラ４は、ＵＷＢ２Ａからこのデータをリード要求に対する応答として返すように要求する転送要求を、ホスト２に送出する。この転送要求は、このデータに対応するバッファアドレスを含んでいてもよい。
【０１５６】
（４’）  ホスト２のフラッシュストレージマネージャは、このデータをＵＷＢ２Ａからリードし、リードしたデータを、このデータのＬＢＡと一緒に、上位ソフトウェアに返す。
【０１５７】
あるいは、ホスト２のフラッシュストレージマネージャは、ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をフラッシュストレージデバイス３に送出せずに、このデータをＵＷＢ２Ａから直接リードしてもよい。この場合、データリード処理は以下のように実行される。
【０１５８】
（１”）  ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、ホスト２のフラッシュストレージマネージャは、上位ソフトウェアからのこのデータをリードするための要求に応答して、リード要求をＵＷＢ２Ａに送出してこのデータをＵＷＢ２Ａからリードする。このリード要求は、例えば、ＬＢＡ、長さを含んでいてもよい。
【０１５９】
（２”）  フラッシュストレージマネージャは、ＵＷＢ２Ａからリードされたデータを、このデータのＬＢＡと一緒に上位ソフトウェアに返す。
【０１６０】
図１９のシーケンス図は、フォギー・ファイン書き込みをサポートするフラッシュストレージデバイス３とホスト２とによって実行されるデータ書き込み処理の手順を示す。
【０１６１】
ここでは、ライト要求がブロック識別子とバッファアドレス（またはバッファ内オフセット）を含む場合を例示して説明する。
【０１６２】
ホスト２は、ある書き込み先ブロックに書き込むべきデータ（ライトデータ）をこの書き込み先ブロックに関連づけられたＵＷＢ領域に格納し、そしてブロック識別子とバッファアドレス（またはバッファ内オフセット）とを含むライト要求をフラッシュストレージデバイス３に送出する（ステップＳ７１）。ブロック識別子は、このライトデータが書き込まれるべき書き込み先ブロックのブロックアドレスである。バッファアドレスは、このライトデータが格納されているＵＷＢ領域内の位置を示す。
【０１６３】
フラッシュストレージデバイス３のコントローラ４は、このライト要求をホスト２から受信し、このライト要求内のブロック識別子とバッファアドレス（またはバッファ内オフセット）を保持する（ステップＳ８１）。この場合、コントローラ４は、ブロック識別子とバッファアドレスをＤＲＡＭ６上のライトバッファ３１に格納することによってこれらブロック識別子とバッファアドレスを保持してもよい。
【０１６４】
保持しているブロック識別子によって指定される書き込み先ブロックにこのライト要求に対応するライトデータを複数段階のプログラム動作（フォギー・ファイン・プログラム動作）で書き込む際、フラッシュストレージデバイス３のコントローラ４は、まず、フォギー書き込みのために使用されるライトデータ（フォギーデータ）をＵＷＢ領域から取得するために、保持しているバッファアドレス（またはバッファ内オフセット）を含む転送要求をホスト２に送出する（ステップＳ８２）。
【０１６５】
ホスト２がこの転送要求を受信すると、ホスト２は、このライトデータをＵＷＢ領域からフラッシュストレージデバイス３に転送する（ステップＳ７２）。
【０１６６】
フラッシュストレージデバイス３のコントローラ４は、ホスト２から転送されるこのライトデータをフォギーデータとして受信する（ステップＳ８３）。コントローラ４は、受信したライトデータ（フォギーデータ）を例えばＤＲＡＭ６上のライトバッファ３１等に格納することによって保持する（ステップＳ８４）。
【０１６７】
コントローラ４は、受信したライトデータ（フォギーデータ）をＮＡＮＤ型フラッシュメモリ５に転送する（ステップＳ８５）。ＮＡＮＤ型フラッシュメモリ５へのライトデータ（フォギーデータ）の転送が完了するまで、コントローラ４は、このライトデータ（フォギーデータ）を保持する。そして、コントローラ４は、このライトデータ（フォギーデータ）を、保持しているブロック識別子によって指定される書き込み先ブロックの書き込み先物理ページに書き込む（一段階目の書き込み：フォギー書き込み）（ステップＳ８６）。
【０１６８】
この後、この書き込み先物理ページへの二段階目の書き込み（ファイン書き込み）を実行するタイミングが到来すると、フラッシュストレージデバイス３のコントローラ４は、ファイン書き込みのために使用されるライトデータ（ファインデータ）をＵＷＢ領域から取得するために、保持しているバッファアドレス（またはバッファ内オフセット）を含む転送要求をホスト２に再び送出する（ステップＳ８７）。ファインデータは、フォギーデータと同じデータである。
【０１６９】
ホスト２がこの転送要求を受信すると、ホスト２は、このライトデータをＵＷＢ領域からフラッシュストレージデバイス３に転送する（ステップＳ７３）。
【０１７０】
フラッシュストレージデバイス３のコントローラ４は、ホスト２から転送されるこのライトデータをファインデータとして受信する（ステップＳ８８）。コントローラ４は、受信したライトデータ（ファインデータ）を例えばＤＲＡＭ６上のライトバッファ３１等に格納することによって保持する（ステップＳ８９）。
【０１７１】
コントローラ４は、受信したライトデータ（ファインデータ）をＮＡＮＤ型フラッシュメモリ５に転送する（ステップＳ９０）。ＮＡＮＤ型フラッシュメモリ５へのライトデータ（ファインデータ）の転送が完了するまで、コントローラ４は、このライトデータ（ファインデータ）を保持する。そして、コントローラ４は、このライトデータ（ファインデータ）を、この書き込み先ブロックのこの書き込み先物理ページに書き込む（二段階目の書き込み：ファイン書き込み）（ステップＳ９１）。
【０１７２】
書き込み動作が終了し且つこのライトデータが読み出し可能になった場合（つまり、フォギー書き込み動作とファイン書き込み動作の双方が終了した場合）、コントローラ４は、ＵＷＢ領域に格納されているこのライトデータが不要になったことをホスト２に通知する（ステップＳ９２）。
【０１７３】
図２０は、ホスト２（情報処理装置）の構成例を示す。
【０１７４】
このホスト２は、プロセッサ（ＣＰＵ）１０１、メインメモリ１０２、ＢＩＯＳ−ＲＯＭ１０３、ネットワークコントローラ１０５、周辺インタフェースコントローラ１０６、コントローラ１０７、およびエンベデッドコントローラ（ＥＣ）１０８等を含む。
【０１７５】
プロセッサ１０１は、この情報処理装置内の各コンポーネントの動作を制御するように構成されたＣＰＵである。このプロセッサ１０１は、メインメモリ１０２上の様々なプログラムを実行する。メインメモリ１０２は、ＤＲＡＭのようなランダムアクセスメモリから構成される。プロセッサ１０１によって実行されるプログラムは、アプリケーションソフトウェアレイヤ４１、オペレーティングシステム（ＯＳ）４２、ファイルシステム４３、デバイスドライバ４４、等を含む。
【０１７６】
様々なアプリケーションプログラムがアプリケーションソフトウェアレイヤ４１上で走る。一般に知られているように、ＯＳ４２は、この情報処理装置全体を管理し、この情報処理装置内のハードウェアを制御し、ソフトウェアがハードウェアおよびフラッシュストレージデバイス３を使用することを可能にするための制御を実行するように構成されたソフトウェアである。ファイルシステム４３は、ファイルの操作（クリエイト、保存、更新、削除等）のための制御を行うために使用される。
【０１７７】
デバイスドライバ４４は、フラッシュストレージデバイス３を制御および管理するためのプログラムである。このデバイスドライバ４４は、上述のフラッシュストレージマネージャを含む。このフラッシュストレージマネージャ４５は、メインメモリ１０２上のＵＷＢ２Ａを管理するための命令群、フラッシュストレージデバイス３にライト要求、リード要求等を送出するための命令群、フラッシュストレージデバイス３から転送要求を受信する度にＵＷＢ２Ａからフラッシュストレージデバイス３にデータを転送するための命令群、ＵＷＢ２Ａに格納されているあるデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、このデータをＵＷＢ２Ａからリードするための命令群、等を含む。プロセッサ１０１は、デバイスドライバ４４内のフラッシュストレージマネージャ４５の命令群を実行することによって、データ書き込み処理、データ読み出し処理、ＵＷＢ領域解放処理、等を実行する。
【０１７８】
ネットワークコントローラ１０５は、ｅｔｈｅｒｎｅｔコントローラのような通信デバイスである。周辺インタフェースコントローラ１０６は、ＵＳＢデバイスのような周辺デバイスとの通信を実行するように構成されている。
【０１７９】
コントローラ１０７は、複数のコネクタ１０７Ａにそれぞれ接続されるデバイスとの通信を実行するように構成されている。本実施形態では、複数のフラッシュストレージデバイス３が複数のコネクタ１０７Ａにそれぞれ接続されてもよい。コントローラ１０７は、ＳＡＳ  ｅｘｐａｎｄｅｒ、ＰＣＩｅ  Ｓｗｉｔｃｈ、ＰＣＩｅ  ｅｘｐａｎｄｅｒ、フラッシュアレイコントローラ、またはＲＡＩＤコントローラでもよい。あるいは、複数のフラッシュストレージデバイス３は、ｅｔｈｅｒｎｅｔを介してネットワークコントローラ１０５に接続されてもよい。
【０１８０】
図２１のフローチャートは、プロセッサ１０１によって実行されるデータ書き込み処理の手順を示す。
【０１８１】
データ書き込み処理においては、プロセッサ１０１は、一つの書き込み先ブロックに書き込むべきライトデータをＵＷＢ２Ａ（この書き込み先ブロックに対応するＵＷＢ領域）に格納する（ステップＳ１０１）。プロセッサ１０１は、この書き込み先ブロックに関連付けられた識別子と、ライトデータが格納されているＵＷＢ２Ａ内の位置（ＵＷＢ領域無いとの位置）を示す記憶位置情報とを含むライト要求をフラッシュストレージデバイス３に送出する（ステップＳ１０２）。書き込み先ブロックに関連付けられた識別子は、上述したように、書き込み先ブロックのブロック識別子（ブロックアドレス）であってもよい。記憶位置情報は、上述したように、バッファアドレス（またはバッファ内オフセット）であってもよい。この場合、プロセッサ１０１は、タグ、ブロック識別子、バッファアドレス（またはバッファ内オフセット）を含むライト要求をフラッシュストレージデバイス３に送出してもよい。また、ホスト２がブロックのみならず、ページも指定する構成においては、ライト要求は、タグ、ブロック識別子（ブロックアドレス）、ページアドレス、バッファアドレス（またはバッファ内オフセット）を含んでもよい。
【０１８２】
あるいは、ストリーム書き込みを使用するケースにおいては、ブロック識別子（ブロックアドレス）の代わりに、ストリームＩＤが利用されてもよい。この場合、ライト要求は、ストリームＩＤ、ＬＢＡ、バッファアドレス（またはバッファ内オフセット）を含んでもよい。
【０１８３】
プロセッサ１０１がライト要求をフラッシュストレージデバイス３に送出した後、プロセッサ１０１は、バッファアドレス（またはバッファ内オフセット）を含む転送要求をフラッシュストレージデバイス３から受信する度に、上述のライトデータをＵＷＢ２Ａ（ＵＷＢ領域）からフラッシュストレージデバイス３に転送する（ステップＳ１０３、Ｓ１０４）。より詳しくは、プロセッサ１０１は、バッファアドレス（またはバッファ内オフセット）を含む転送要求がフラッシュストレージデバイス３から受信されたか否かを判定する（ステップＳ１０３）。そして、この転送要求がフラッシュストレージデバイス３から受信されたならば（ステップＳ１０３のＹＥＳ）、プロセッサ１０１は、上述のライトデータをＵＷＢ２Ａ（ＵＷＢ領域）からフラッシュストレージデバイス３に転送する。
【０１８４】
上述したように、複数段階のプログラム動作（フォギー・ファイン・プログラム動作）でライトデータが書き込み先ブロックに書き込まれるケースにおいては、プロセッサ１０１は、同じバッファアドレス（または同じバッファ内オフセット）を含む転送要求をフラッシュストレージデバイス３から複数回受信する。そして、この転送要求を受信する度に、プロセッサ１０１は、上述のライトデータをＵＷＢ２Ａ（ＵＷＢ領域）からフラッシュストレージデバイス３に転送する。
【０１８５】
図２２のフローチャートは、プロセッサ１０１によって実行されるデータ読み出し処理の手順を示す。
【０１８６】
ＵＷＢ２Ａ（ＵＷＢ領域）に格納されているデータが不要になったことがフラッシュストレージデバイス３から通知されるまでは、プロセッサ１０１は、上位ソフトウェアからのこのデータをリードするための要求に応答してこのデータをＵＷＢ２Ａ（ＵＷＢ領域）からリードし、このリードしたデータを上位ソフトウェアに返す。
【０１８７】
すなわち、上位ソフトウェアからデータのリードが要求されたならば（ステップＳ１１１のＹＥＳ）、プロセッサ１０１は、ＵＷＢ２Ａ（ＵＷＢ領域）上のこのデータが不要になったことがフラッシュストレージデバイス３から既に通知されているか否かを判定する（ステップＳ１１２）。
【０１８８】
このデータが不要になったことがまだ通知されていないならば（ステップＳ１１２のＮＯ）、プロセッサ１０１は、このデータをＵＷＢ２Ａ（ＵＷＢ領域）からリードし、リードしたデータを上位ソフトウェアに返す（ステップＳ１１２）。
【０１８９】
一方、このデータが不要になったことが既に通知されているならば（ステップＳ１１２のＹＥＳ）、プロセッサ１０１は、このデータをリードするためのリード要求をフラッシュストレージデバイス３に送出し、これによってこのデータをフラッシュストレージデバイス３からリードする（ステップＳ１１４）。
【０１９０】
図２３のフローチャートは、プロセッサ１０１によって実行されるデータ読み出し処理の別の手順を示す。
【０１９１】
上位ソフトウェアからデータをリードするための要求が受信されたならば（ステップＳ１２１のＹＥＳ）、プロセッサ１０１は、このデータがＵＷＢ２Ａ（ＵＷＢ領域）に存在するか否かにかかわらず、つまりこのデータが不要になったことが既にフラッシュストレージデバイス３から通知されているか否かにかかわらず、このデータをリードするためのリード要求をフラッシュストレージデバイス３に送出する（ステップＳ１２２）。
【０１９２】
フラッシュストレージデバイス３は、このリード要求によって指定されたデータがまだ読み出し可能になっていないならば、このデータをＵＷＢ２Ａ（ＵＷＢ領域）から返すように要求する転送要求をホスト２に送出する。
【０１９３】
この転送要求がフラッシュストレージデバイス３から受信されたならば（ステップＳ１２３のＹＥＳ）、プロセッサ１０１は、このデータをＵＷＢ２Ａ（ＵＷＢ領域）からリードし、このリードしたデータを上位ソフトウェアに返す（ステップＳ１２４）。
【０１９４】
この転送要求がフラッシュストレージデバイス３から受信されなかったならば（ステップＳ１２３のＮＯ）、プロセッサ１０１は、リード要求に対する応答としてフラッシュストレージデバイス３から返されるデータを受信し、このデータを上位ソフトウェアに返す（ステップＳ１２５）。
【０１９５】
図２４のフローチャートは、プロセッサ１０１によって実行されるＵＷＢ領域解放処理の手順を示す。
【０１９６】
一つの書き込み先ブロックに関連付けられたＵＷＢ領域全体が不要になったことを示す通知（クローズ要求）をプロセッサ１０１がフラッシュストレージデバイス３から受信した場合（ステップＳ１３１のＹＥＳ）、プロセッサ１０１は、このＵＷＢ領域全体を解放する（ステップＳ１３２）。ステップＳ１３２では、プロセッサ１０１は、この解放したＵＷＢ領域に対応するメモリスペースを他の任意の用途に使用することができる。例えば、プロセッサは、フラッシュストレージデバイス３のコントローラ４によって新たに割り当てられた書き込み先ブロックに関連付けられたＵＷＢ領域としてこの解放したＵＷＢ領域を再利用してもよい。この新たに割り当てられた書き込み先ブロックにデータを書き込むことが必要な時、プロセッサ１０１は、まず、この新たに割り当てられた書き込み先ブロックに関連付けられたＵＷＢ領域にこのデータを格納し、そして、この新たに割り当てられた書き込み先ブロックに関連付けられた識別子（ブロック識別子、またはストリームＩＤ）と、このデータが格納されているこのＵＷＢ領域内の位置を示す記憶位置情報（例えばバッファアドレス）とを含むライト要求をフラッシュストレージデバイス３に送出する。
【０１９７】
以上説明したように、本実施形態によれば、フラッシュストレージデバイス３のコントローラ４は、一つの書き込み先ブロックに関連付けられた第１の識別子（ブロック識別子、またはストリームＩＤ）と、書き込むべき第１のデータが格納されているホスト２のメモリ上のライトバッファ（ＵＷＢ２Ａ）内の位置を示す記憶位置情報（バッファアドレス、またはバッファ内アドレス）とを含むライト要求をホスト２から受信する。そして、第１のデータをＮＡＮＤ型フラッシュメモリ５に書き込む際に、コントローラ４は、記憶位置情報を含む転送要求をホスト２に送出することによって第１のデータをライトバッファ（ＵＷＢ２Ａ）から取得する。したがって、書き込み動作のために必要なデータをホスト２のライトバッファ（ＵＷＢ２Ａ）から取得できるので、フラッシュストレージデバイス３に多数のライトバッファを用意することなく、同時に利用可能な書き込み先ブロックの数を増やすことができる。よって、フラッシュストレージデバイス３のコストアップを招くことなく、フラッシュストレージデバイス３を共有するエンドユーザの数を容易に増やすことが可能となる。
【０１９８】
また、コントローラ４は、第１のデータの書き込みが終了し且つ第１のデータがＮＡＮＤ型フラッシュメモリ５から読み出し可能になった場合、ライトバッファ（ＵＷＢ２Ａ）に保持されている第１のデータが不要になったことをホスト２に通知する。この通知に応じて、ホスト２は、必要に応じてこのデータを破棄することができる。したがって、書き込むべきデータがＮＡＮＤ型フラッシュメモリ５から読み出し可能になるまでは、コントローラ４は、必要に応じて、このデータをライトバッファ（ＵＷＢ２Ａ）から繰り返し取得することもできる。したがって、フォギー・ファイン・プログラム動作のような複数段階のプログラム動作を実行する場合であっても、コントローラ４は、各段階のプログラム動作の開始の度に、必要なデータをライトバッファ（ＵＷＢ２Ａ）から取得することができる。
【０１９９】
なお、本実施形態では、不揮発性メモリとしてＮＡＮＤ型フラッシュメモリを例示した。しかし、本実施形態の機能は、例えば、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＰＲＡＭ（Ｐｈａｓｅ  ｃｈａｎｇｅ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲｅＲＡＭ（Ｒｅｓｉｓｔｉｖｅ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、又は、ＦｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）のような他の様々な不揮発性メモリにも適用できる。
【０２００】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０２０１】
２…ホスト、２Ａ…ライトバッファ、３…フラッシュストレージデバイス、４…コントローラ、５…ＮＡＮＤ型フラッシュメモリ、２１…ブロック識別子／バッファアドレス受信部、２２…転送要求送信部、２３…通知部。
【図１】
2019105873.tif 000003
【図２】
2019105873.tif 000004
【図３】
2019105873.tif 000005
【図４】
2019105873.tif 000006
【図５】
2019105873.tif 000007
【図６】
2019105873.tif 000008
【図７】
2019105873.tif 000009
【図８】
2019105873.tif 000010
【図９】
2019105873.tif 000011
【図１０】
2019105873.tif 000012
【図１１】
2019105873.tif 000013
【図１２】
2019105873.tif 000014
【図１３】
2019105873.tif 000015
【図１４】
2019105873.tif 000016
【図１５】
2019105873.tif 000017
【図１６】
2019105873.tif 000018
【図１７】
2019105873.tif 000019
【図１８】
2019105873.tif 000020
【図１９】
2019105873.tif 000021
【図２０】
2019105873.tif 000022
【図２１】
2019105873.tif 000023
【図２２】
2019105873.tif 000024
【図２３】
2019105873.tif 000025
【図２４】
2019105873.tif 000026