JP2019079464A - メモリシステムおよび制御方法 - Google Patents

Abstract

【課題】異なる種類のインタフェースに対応した複数の領域を選択的に利用することができるメモリシステムを実現する。【解決手段】ホストから受信したリード要求が第１領域を示す第１の識別子を含む場合、メモリシステムは、受信したリード要求から論理アドレスを取得し、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記一つの第１領域の物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得し、取得した物理アドレスに基づいて、前記一つの第１領域からデータをリードする。受信したリード要求が第２領域を示す第２の識別子を含む場合、メモリシステムは、受信したリード要求から物理アドレス情報を取得し、取得した物理アドレス情報に基づいて、第２の領域からデータをリードする。【選択図】図２

Description

本発明の実施形態は、不揮発性メモリを制御する技術に関する。

近年、不揮発性メモリを備えるメモリシステムが広く普及している。

このようなメモリシステムの一つとして、ＮＡＮＤフラッシュ技術ベースのソリッドステートドライブ（ＳＳＤ）が知られている。

最近では、ホストとストレージとの間の新たなインタフェースが提案され始めている。

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 >

本発明が解決しようとする課題は、異なる種類のインタフェースに対応した複数の領域を選択的に利用することができるメモリシステムおよび制御方法を提供することである。

実施形態によれば、ホストに接続可能なメモリシステムは、各々が複数のページを含む複数のブロックを含む不揮発性メモリと、前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するコントローラとを具備する。前記コントローラは、前記不揮発性メモリを論理的に分割することによって得られる複数の領域を管理する。前記複数の領域は、前記ホストが論理アドレスを指定し前記不揮発性メモリの物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる一つ以上の第１領域と、前記ホストが前記不揮発性メモリの物理アドレスの一部または全体を指定する第２タイプのインタフェースを使用してリードアクセスされる一つ以上の第２領域とを含む。前記コントローラは、前記ホストからリード要求を受信する。前記コントローラは、前記受信したリード要求が前記一つ以上の第１領域の一つの第１領域を示す第１の識別子を含む場合、前記第１タイプのインタフェースを選択し、前記受信したリード要求から論理アドレスを取得し、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記一つの第１領域の物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得し、取得した物理アドレスに基づいて、前記一つの第１領域からデータをリードする。前記コントローラは、前記受信したリード要求が前記一つ以上の第２領域の一つの第２領域を示す第２の識別子を含む場合、前記第２タイプのインタフェースを選択し、前記受信したリード要求から前記一つの第２の領域の物理アドレスの一部または全てを指定する物理アドレス情報を取得し、前記取得した物理アドレス情報に基づいて、前記一つの第２の領域からデータをリードする。

ホストと実施形態のメモリシステム（フラッシュストレージデバイス）との関係を示すブロック図。 同実施形態のフラッシュストレージデバイスによってサポートされる複数種のインタフェースを説明するための図。 同実施形態のフラッシュストレージデバイスの構成例を示すブロック図。 同実施形態のフラッシュストレージデバイスに設けられたＮＡＮＤインタフェースと複数のＮＡＮＤ型フラッシュメモリダイとの関係を示すブロック図。 複数のブロックの集合によって構築されるスーパーブロックの構成例を示す図。 同実施形態のフラッシュストレージデバイスに適用される拡張ネームスペース管理コマンドを説明するための図。 同実施形態のフラッシュストレージデバイスによって実行される領域（ネームスペース）作成処理を示すシーケンスチャート。 従来型ＳＳＤとホストとの間の役割分担と、第１タイプのインタフェース（物理アドレスＡＰＩ（タイプ＃１））をサポートする同実施形態のフラッシュストレージデバイスとホストとの間の役割分担とを説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるライトコマンドを説明するための図。 図９のライトコマンドに対するレスポンスを説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるＴｒｉｍコマンドを説明するための図。 図１０のレスポンスに含まれる物理アドレスを規定するブロック番号およびオフセットを説明するための図。 ライトコマンドに応じて実行される書き込み動作とこのライトコマンドに対するレスポンスに含まれる返値との関係を説明するための図。 不良ページをスキップする書き込み動作を説明するための図。 不良ページをスキップする書き込み動作の別の例を説明するための図。 論理アドレスとデータのペアをブロック内のページに書き込む動作を説明するための図。 データをブロック内のページのユーザデータ領域に書き込み、このデータの論理アドレスをこのページの冗長領域に書き込む動作を説明するための図。 スーパーブロックが使用される場合におけるブロック番号とオフセットとの関係を説明するための図。 ホストと同実施形態のフラッシュストレージデバイスとによって実行される書き込み動作処理のシーケンスを示すシーケンスチャート。 すでに書き込まれているデータに対する更新データを書き込むデータ更新動作を示す図。 同実施形態のフラッシュストレージデバイスによって管理されるブロック管理テーブルを更新する動作を説明するための図。 ホストによって管理されるルックアップテーブル（論理物理アドレス変換テーブル）を更新する動作を説明するための図。 無効化すべきデータに対応する物理アドレスを示すホストからの通知に応じてブロック管理テーブルを更新する動作を説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるリードコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃１）に対応するリード動作を説明するための図。 物理アドレスＡＰＩ（タイプ＃１）に対応するリード処理のシーケンスを示すシーケンスチャート。 物理アドレスＡＰＩ（タイプ＃１）で使用されるガベージコレクション（ＧＣ）制御コマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるＧＣ用コールバックコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃１）に対応するガベージコレクション（ＧＣ）動作の手順を示すシーケンスチャート。 ガベージコレクション（ＧＣ）のために実行されるデータコピー動作の例を説明するための図。 図３０のデータコピー動作の結果に基づいて更新されるホストのルックアップテーブルの内容を説明するための図。 ライトコマンドに対するレスポンスとＧＣ用コールバック処理との関係を説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるガベージコレクション（ＧＣ）制御コマンドの別の例を説明するための図。 物理アドレスＡＰＩ（タイプ＃１）で使用されるＧＣ用コールバックコマンドの別の例を説明するための図。 物理アドレスＡＰＩ（タイプ＃１）に対応する書き込み／リード／ＧＣ動作を説明するための図。 従来型ＳＳＤとホストとの間の役割分担と、第２タイプのインタフェース（物理アドレスＡＰＩ（タイプ＃２））をサポートする同実施形態のフラッシュストレージデバイスとホストとの間の役割分担を説明するための図。 ホストによって管理されるブロックレベルアドレス変換テーブルと同実施形態のフラッシュストレージデバイスによって管理されるブロック内アドレス変換テーブルを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）で使用されるライトコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）で使用されるＴｒｉｍコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）に対応する書き込み処理のシーケンスを示すシーケンスチャート。 すでに書き込まれているデータに対する更新データを書き込むデータ更新動作を示す図。 同実施形態のフラッシュストレージデバイスによって管理されるブロック番号ＢＬＫ＃１用のブロック内ＬＵＴを説明するための図。 同実施形態のフラッシュストレージデバイスによって管理されるブロック管理テーブルを更新する動作を説明するための図。 ホストによって管理されるブロックレベルＬＵＴを更新する動作を説明するための図。 無効化すべきデータに対応するブロック番号および論理アドレスを示すホストからの通知に応じてブロック内ＬＵＴおよびブロック管理テーブルを更新する動作を説明するための図。 物理アドレスＡＰＩ（タイプ＃２）で使用されるリードコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）に対応するリード動作を説明するためのシーケンスチャート図。 物理アドレスＡＰＩ（タイプ＃２）で使用されるガベージコレクション（ＧＣ）制御コマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）で使用されるＧＣ用コールバックコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃２）に対応するガベージコレクション（ＧＣ）動作の手順を示すシーケンスチャート。 従来型ＳＳＤとホストとの間の役割分担と、第３タイプのインタフェース（物理アドレスＡＰＩ（タイプ＃３））をサポートする同実施形態のフラッシュストレージデバイスとホストとの間の役割分担とを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）に対応するデータ書き込み動作と、物理アドレスＡＰＩ（タイプ＃３）に対応するデータ読み出し動作とを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）で使用されるライトコマンドを説明するための図。 図５３のライトコマンドに対するレスポンスを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）で使用されるＴｒｉｍコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）に対応する書き込み処理のシーケンスを示すシーケンスチャート。 物理アドレスＡＰＩ（タイプ＃３）で使用されるリードコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）で使用されるガベージコレクション（ＧＣ）制御コマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）で使用されるＧＣ用コールバックコマンドを説明するための図。 物理アドレスＡＰＩ（タイプ＃３）に対応するガベージコレクション（ＧＣ）動作の手順を示すシーケンスチャート。

以下、図面を参照して、実施形態を説明する。

まず、図１を参照して、一実施形態に係るメモリシステムを含む計算機システムの構成を説明する。

このメモリシステムは、不揮発性メモリにデータを書き込み、不揮発性メモリからデータを読み出すように構成された半導体ストレージデバイスである。このメモリシステムは、ＮＡＮＤフラッシュ技術ベースのフラッシュストレージデバイス３として実現されている。

この計算機システムは、ホスト（ホストデバイス）２と、複数のフラッシュストレージデバイス３とを含んでいてもよい。ホスト２は、複数のフラッシュストレージデバイス３によって構成されるフラッシュアレイをストレージとして使用するように構成されたサーバであってもよい。ホスト（サーバ）２と複数のフラッシュストレージデバイス３は、インタフェース５０を介して相互接続される（内部相互接続）。この内部相互接続のためのインタフェース（物理インタフェース）５０としては、これに限定されないが、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）（登録商標）、ＮＶＭ Ｅｘｐｒｅｓｓ（ＮＶＭｅ）（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＮＶＭｅ ｏｖｅｒ Ｆａｂｒｉｃｓ（ＮＶＭｅＯＦ）等を使用し得る。

ホスト２として機能するサーバの典型例としては、データセンター内のサーバが挙げられる。

ホスト２がデータセンター内のサーバによって実現されるケースにおいては、このホスト（サーバ）２は、ネットワーク５１を介して複数のエンドユーザ端末（クライアント）６１に接続されてもよい。ホスト２は、これらエンドユーザ端末６１に対して様々なサービスを提供することができる。

ホスト（サーバ）２によって提供可能なサービスの例には、（１）システム稼働プラットフォームを各クライアント（各エンドユーザ端末６１）に提供するプラットホーム・アズ・ア・サービス（ＰａａＳ）、（２）仮想サーバのようなインフラストラクチャを各クライアント（各エンドユーザ端末６１）に提供するインフラストラクチャ・アズ・ア・サービス（ＩａａＳ）、等がある。

複数の仮想マシンが、このホスト（サーバ）２として機能する物理サーバ上で実行されてもよい。ホスト（サーバ）２上で走るこれら仮想マシンの各々は、対応する幾つかのクライアント（エンドユーザ端末６１）に各種サービスを提供するように構成された仮想サーバとして機能することができる。

ホスト（サーバ）２は、フラッシュアレイを構成する複数のフラッシュストレージデバイス３を管理するストレージ管理機能と、エンドユーザ端末６１それぞれに対してストレージアクセスを含む様々なサービスを提供するフロントエンド機能とを含む。

従来型ＳＳＤにおいては、ＮＡＮＤ型フラッシュメモリのブロック／ページの階層構造はＳＳＤ内のフラッシュトランスレーション層（ＦＴＬ）によって隠蔽されている。つまり、従来型ＳＳＤのＦＴＬは、（１）論理物理アドレス変換テーブルとして機能するルックアップテーブルを使用して、論理アドレスそれぞれとＮＡＮＤ型フラッシュメモリの物理アドレスそれぞれとの間のマッピングを管理する機能、（２）ページ単位のリード／ライトとブロック単位の消去動作とを隠蔽するための機能、（３）ＮＡＮＤ型フラッシュメモリのガベージコレクション（ＧＣ）を実行する機能、等を有している。論理アドレスそれぞれとＮＡＮＤ型フラッシュメモリの物理アドレスの間のマッピングは、ホストからは見えない。ＮＡＮＤ型フラッシュメモリのブロック／ページ構造もホストからは見えない。

一方、ホストにおいても、一種のアドレス変換（アプリケーションレベルアドレス変換）が実行されることがある。このアドレス変換は、アプリケーションレベルアドレス変換テーブルを使用して、アプリケーション用の論理アドレスそれぞれとＳＳＤ用の論理アドレスそれぞれとの間のマッピングを管理する。また、ホストにおいても、ＳＳＤ用の論理アドレス空間上に生じるフラグメントの解消のために、この論理アドレス空間上のデータ配置を変更するための一種のＧＣ（アプリケーションレベルＧＣ）が実行される。

しかし、ホストおよびＳＳＤがそれぞれアドレス変換テーブルを有するという冗長な構成（ＳＳＤは論理物理アドレス変換テーブルとして機能するルックアップテーブルを有し、ホストはアプリケーションレベルアドレス変換テーブルを有する）においては、これらアドレス変換テーブルを保持するために膨大なメモリリソースが消費される。さらに、ホスト側のアドレス変換とＳＳＤ側のアドレス変換とを含む２重のアドレス変換は、Ｉ／Ｏ性能を低下させる要因にもなる。

さらに、ホスト側のアプリケーションレベルＧＣは、ＳＳＤへのデータ書き込み量を実際のユーザデータ量の数倍（例えば２倍）程度に増やす要因となる。このようなデータ書き込み量の増加は、ＳＳＤのライトアンプリフィケーションを増加させてはいないが、システム全体のストレージ性能を低下させ、またＳＳＤの寿命も短くする。

このような問題点を解消するために、従来型ＳＳＤのＦＴＬの機能の全てをホストに移すという対策も提案されている。

しかし、この対策を実装するためには、ＮＡＮＤ型フラッシュメモリのブロックおよびページをホストが直接的にハンドリングすることが必要となる。ＮＡＮＤ型フラッシュメモリの容量はＮＡＮＤ型フラッシュメモリの世代毎に増加しており、これに伴ってＮＡＮＤ型フラッシュメモリのブロックサイズ／ページサイズも世代毎に異なる。このためホスト２では異なるブロックサイズ・ページサイズのＮＡＮＤ型フラッシュメモリを混在して使用することが必要となる場合がありうる。異なるブロックサイズ／ページサイズを扱うことはホストにとっては困難である。また、様々な製造上の理由などにより発生する予測不可能な数の不良ページ（バッドページ）が存在することがありうるので、ブロック内の実質的に利用可能なページ数がブロック毎に異なることが想定され、そのＮＡＮＤ型フラッシュメモリ内のブロックサイズがブロック毎に異なる場合もあり得る。バッドページおよび不均一なブロックサイズをハンドリングすることは、ホストにとってはなおさら困難である。

そこで、本実施形態のフラッシュストレージデバイス３では、ＮＡＮＤ型フラッシュメモリをアクセスするための複数種のインタフェース（ソフトウェアインタフェース）がサポートされており、ＮＡＮＤ型フラッシュメモリ内のアクセス対象の領域毎に、使用すべきインタフェースを切り替えることができる。したがって、用途に応じて、より適切なインタフェースを使用することが可能となる。

より詳しくは、フラッシュストレージデバイス３は、ＮＡＮＤ型フラッシュメモリを論理的に分割することによって得られる複数の領域を管理する。

これら複数の領域には、ホスト２が論理アドレスのみを指定しＮＡＮＤ型フラッシュメモリの物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる一つ以上の第１領域が含まれる。

第１タイプのインタフェースにおいては、ホスト２は、ＮＡＮＤ型フラッシュメモリの物理アドレスを指定する必要は無く、リードすべきデータに対応する論理アドレスのみを指定すればよい。

したがって、第１領域に関しては、ホスト２は、ＮＡＮＤ型フラッシュメモリを直接的にハンドリングする必要はない。ＮＡＮＤ型フラッシュメモリを直接的にハンドリングするためには、ＮＡＮＤ型フラッシュメモリを直接的にハンドリングするために必要な機能群がホスト２上で既に実行されていることが必要となる。しかし、第１領域からデータをリードする場合にはこれら機能群は不要であるので、第１領域は、オペレーティングシステムをブートするためのブータブル領域として利用可能である。

さらに、これら複数の領域には、ホスト２がＮＡＮＤ型フラッシュメモリの物理アドレスの一部（例えばブロック番号のみ）または物理アドレスの全体（例えばブロック番号とブロック内オフセット）を指定する第２タイプのインタフェースを使用してリードアクセスされる一つ以上の第２領域も含まれる。

第２タイプのインタフェース（以下、物理アドレスＡＰＩと称する）を使用してデータをリードする場合においては、ＮＡＮＤ型フラッシュメモリの物理アドレスの一部または全体がホスト２によって指定される。

したがって、ホスト２は、必要に応じて物理アドレスＡＰＩを使用することにより、ＮＡＮＤ型フラッシュメモリを直接的にアクセスすることができる。

物理アドレスＡＰＩを実現するに際しては、ＦＴＬの役割はホスト２とフラッシュストレージデバイス３との間で適切に分担されてもよい。この場合、従来型ＳＳＤのＦＴＬの機能の一部のみがホスト２に移されてもよい。以下では、ホスト２に移されたＦＴＬ機能をグローバルＦＴＬと称する。

ホスト２のグローバルＦＴＬは、ストレージサービスを実行する機能、論理アドレスそれぞれとＮＡＮＤ型フラッシュメモリの物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルとして機能するルックアップテーブル（ＬＵＴ）（または論理アドレスそれぞれとＮＡＮＤ型フラッシュメモリのブロック番号それぞれとの間のマッピングのみを管理するブロックレベルＬＵＴ）を管理する機能、ウェアー制御機能、高可用性を実現するための機能、同じ内容を有する複数の重複データ部がストレージに格納されることを防止する重複排除（Ｄｅ−ｄｕｐｌｉｃａｔｉｏｎ）機能、等を有していてもよい。

一方、フラッシュストレージデバイス３は、ローレベルアブストラクション（ＬＬＡ）のための機能を有していてもよい。ＬＬＡはＮＡＮＤ型フラッシュメモリのアブストラクションのための機能である。ＬＬＡは、物理アドレスＡＰＩを実現するために利用し得る。

図２は、フラッシュストレージデバイス３によってサポートされる複数種のインタフェース（複数種のＡＰＩ）を示す。

フラッシュストレージデバイス３は、コントローラ４と、ＮＡＮＤ型フラッシュメモリ５とを含む。コントローラ４は、複数種のＡＰＩをサポートしている。これらＡＰＩには、ＬＢＡ ＡＰＩ、物理アドレスＡＰＩ、キー・バリューＡＰＩ、他のＡＰＩ（例えば可変長ＬＵＴ等）が含まれてもよい。

ＬＢＡ ＡＰＩは、上述の第１タイプのインタフェースとして利用される。ＬＢＡ ＡＰＩにおいては、ホスト２からのリード要求は、ＬＢＡのような論理アドレスのみを指定し、ＮＡＮＤ型フラッシュメモリ５の物理アドレスを指定しない。また、ＬＢＡ ＡＰＩにおいては、ホスト２からのライト要求も、ＬＢＡのような論理アドレスのみを指定し、ＮＡＮＤ型フラッシュメモリ５の物理アドレスを指定しない。

物理アドレスＡＰＩは、上述の第２タイプのインタフェースとして利用される。本実施形態では、３種類の物理アドレスＡＰＩ、つまり物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）が、ＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部または全体を指定する上述の第２タイプのインタフェースとしてそれぞれ利用され得る。コントローラ４は、物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）の全てを利用可能な物理アドレスＡＰＩとしてサポートしてもよいし、物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）内の任意の１種類だけを利用可能な物理アドレスＡＰＩとしてサポートしてもよい。

これら物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）は、以下の特徴を有している。

＜物理アドレスＡＰＩ（タイプ＃１）＞
物理アドレスＡＰＩ（タイプ＃１）においては、ホスト２から受信されるリード要求はＮＡＮＤ型フラッシュメモリ５の物理アドレス全体（ブロック番号とブロック内オフセットの双方）を指定する。ブロック内オフセットは、ブロック内の位置を指定するブロック内物理アドレスである。ホスト２から受信されるライト要求は、論理アドレスのみを指定する。

つまり、ホスト２は論理物理アドレス変換テーブルとして機能するルックアップテーブルを管理するが、書き込みに使用すべきブロックの選択は、ホスト２ではなく、フラッシュストレージデバイス３のコントローラ４によって実行される。

＜物理アドレスＡＰＩ（タイプ＃２）＞
物理アドレスＡＰＩ（タイプ＃２）においては、ホスト２から受信されるリード要求は、ＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部（ブロック番号）と、論理アドレスとを指定する。一方、ホスト２から受信されるライト要求は、ＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部（ブロック番号）と、論理アドレスとを指定する。

つまり、ホスト２は、論理アドレスそれぞれとブロック番号それぞれとの間のマッピングを管理するためのブロックレベルアドレス変換テーブルであるブロックレベルルックアップテーブル（ブロックレベルＬＵＴ）を管理し、フラッシュストレージデバイス３は、論理アドレスそれぞれと各ブロックのブロック内物理アドレスとの間のマッピングを管理するためのページレベルアドレス変換テーブルであるブロック内ルックアップテーブル（ブロック内ＬＵＴ）を管理する。

＜物理アドレスＡＰＩ（タイプ＃３）＞
物理アドレスＡＰＩ（タイプ＃３）においては、ホスト２から受信されるリード要求はＮＡＮＤ型フラッシュメモリ５の物理アドレス全体（ブロック番号およびブロック内オフセットの双方）を指定する。一方、ホスト２から受信されるライト要求は、ＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部（ブロック番号）と、論理アドレスとを指定する。

つまり、ホスト２は論理物理アドレス変換テーブルとして機能するルックアップテーブルを管理するが、ホスト２はデータが書き込まれるべきブロックのブロック番号とこのデータに対応する論理アドレスだけを指定し、このデータが書き込まれるべきこのブロック内の位置（書き込み先位置）はフラッシュストレージデバイス３によって決定される。決定されたこのブロック内の位置（書き込み先位置）を示すブロック内オフセット（ブロック内物理アドレス）は、フラッシュストレージデバイス３からホスト２に通知される。

キー・バリューＡＰＩは以下の特徴を有する。

キー・バリューＡＰＩにおいては、キー・バリュー・ストアのキー（タグ）、あるいはキーのハッシュ値が、一種の論理アドレスとして使用される。

キー・バリューＡＰＩにおいては、ホスト２からのリード要求は、キーを論理アドレスとして指定し、ＮＡＮＤ型フラッシュメモリ５の物理アドレスを指定しない。また、キー・バリューＡＰＩにおいては、ホスト２からのライト要求も、キーを論理アドレスとして指定し、ＮＡＮＤ型フラッシュメモリ５の物理アドレスを指定しない。

上述の物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）においては、論理アドレスとしてＬＢＡが使用されてもよいし、キー・バリュー・ストアのキー（タグ）、あるいはキーのハッシュ値が使用されてもよい。

可変長ＬＵＴに対応するＡＰＩは以下の特徴を有する。

可変長ＬＵＴに対応するＡＰＩは、可変長データを扱うためのＡＰＩである。コントローラ４は、複数の論理アドレスに対応する複数のエントリを含む可変長ＬＵＴを管理する。各エントリは、あるデータに対応する論理アドレスを保持するフィールドと、このデータが書き込まれた物理記憶位置を示す物理アドレスを保持するフィールドと、このデータの長さを保持するフィールドとを含む。可変長ＬＵＴに対応するＡＰＩは、任意の論理アドレスに任意の長さのデータを書き込むことを可能にする。

本実施形態においては、コントローラ４は、任意のＡＰＩをＮＡＮＤ型フラッシュメモリ５の任意の領域に適用することができる。領域それぞれとＡＰＩそれぞれとの対応関係は、ホスト２が指定することができる。

図２においては、ＮＡＮＤ型フラッシュメモリ５が論理的に複数の領域（ここでは、領域＃０〜＃６）に分割されており、領域＃０、＃１に対応するＡＰＩがＬＢＡ ＡＰＩに設定され、領域＃２に対応するＡＰＩが物理アドレスＡＰＩ（タイプ＃１）に設定され、領域＃３に対応するＡＰＩが物理アドレスＡＰＩ（タイプ＃２）に設定され、領域＃４に対応するＡＰＩが物理アドレスＡＰＩ（タイプ＃３）に設定され、領域＃５に対応するＡＰＩがキー・バリューＡＰＩに設定され、領域＃６に対応するＡＰＩが他のＡＰＩに設定されているケースが例示されている。

ホスト２からのリード要求およびライト要求等は、アクセス対象の領域を示す識別子（ＩＤ）を含む。コントローラ４は、リード要求／ライト要求に含まれる識別子（ＩＤ）に基づいて、使用すべきＡＰＩを選択する。

例えば、領域＃０を指定するＩＤ＃０を含むリード要求をホスト２から受信した場合、コントローラ４は、領域＃０からのデータリードをＬＢＡ ＡＰＩを使用して実行する。一方、領域＃２〜＃４のいずれかを指定するＩＤ（ＩＤ＃２〜＃４のいずれか）を含むリード要求をホスト２から受信した場合、コントローラ４は、指定された領域からのデータリードを物理アドレスＡＰＩを使用して実行する。

より詳しくは、コントローラ４は、以下のリード処理の手順を実行する。

（１）コントローラ４は、ホスト２からリード要求（リードコマンド）を受信する。

（２）コントローラ４は、受信したリード要求に含まれるＩＤをチェックする。

（３）受信したリード要求がＩＤ＃０を含むならば、コントローラ４は、領域＃０に対応するＡＰＩであるＬＢＡ ＡＰＩを選択する。ＬＢＡ ＡＰＩを使用して領域＃０をリードアクセスするために、コントローラ４は、受信したリード要求から論理アドレスを取得し、取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと領域＃０の物理アドレスそれぞれとの間のマッピングを管理するＬＵＴ（論理物理アドレス変換テーブル）から取得する。そして、コントローラ４は、取得した物理アドレスに基づいて、領域＃０からデータをリードする。

（４）受信したリード要求が領域＃２〜＃４のいずれかを指定するＩＤ（ＩＤ＃２〜＃４のいずれか）を含むならば、コントローラ４は、領域＃２〜＃４に対応するＡＰＩである物理アドレスＡＰＩを選択する。指定された領域を物理アドレスＡＰＩを使用してリードアクセスするために、コントローラ４は、受信したリード要求から、物理アドレスの一部または全てを指定する物理アドレス情報を取得する。そして、コントローラ４は、取得した物理アドレス情報に基づいて、指定された領域からデータをリードする。

このように、アクセス対象の領域に応じて、使用すべきＡＰＩが自動的に選択される。

複数の領域（ここでは、領域＃０〜＃６）は、複数のネームスペースによって実現されてもよい。各ネームスペースは、ＮＡＮＤ型フラッシュメモリ５内の一種の領域（記憶領域）であり、論理アドレス空間（ＬＢＡ範囲）が割り当てられる。個々のネームスペースは、これらネームスペースの識別子（ＮＳＩＤ）によって識別される。各領域には、ＬＢＡ範囲（ＬＢＡ０〜ＬＢＡｎ−１）が割り当てられる。ＬＢＡ範囲のサイズ（つまりＬＢＡの数）は、領域（ネームスペース）毎に可変である。各ＬＢＡ範囲は、ＬＢＡ０から始まる。

領域＃０〜＃６がそれぞれネームスペースによって実現されている場合には、ホスト２からの各リード／ライト要求は、アクセス対象のネームスペースに対応する識別子（ＮＳＩＤ）を含む。

コントローラ４がリード要求を受信した時、コントローラ４は、このリード要求に含まれるＮＳＩＤをチェックする。受信したリード要求がＮＳＩＤ＃０を含むならば、コントローラ４は、領域＃０に対応するＡＰＩであるＬＢＡ ＡＰＩを選択する。ＬＢＡ ＡＰＩを使用してネームスペース＃０をリードアクセスするために、コントローラ４は、受信したリード要求から論理アドレスを取得し、取得した論理アドレスに対応する物理アドレスを、ネームスペース＃０に対応する論理アドレスそれぞれとＮＡＮＤ型フラッシュメモリ５の物理アドレスそれぞれとの間のマッピングを管理するＬＵＴ（ネームスペース＃０用のＬＵＴ）から取得する。そして、コントローラ４は、取得した物理アドレスに基づいて、ネームスペース＃０（つまり、ネームスペース＃０に対応するＮＡＮＤ型フラッシュメモリ５内の領域）からデータをリードする。

受信したリード要求がＮＳＩＤ＃２〜＃４のいずれかを含むならば、コントローラ４は、物理アドレスＡＰＩを選択する。指定されたネームスペースを物理アドレスＡＰＩを使用してリードアクセスするために、コントローラ４は、受信したリード要求から、物理アドレスの一部または全てを指定する物理アドレス情報を取得する。そして、コントローラ４は、取得した物理アドレス情報に基づいて、指定されたネームスペース（つまり、指定されたネームスペースに対応するＮＡＮＤ型フラッシュメモリ５内の領域）からデータをリードする。

図３は、フラッシュストレージデバイス３の構成例を示す。

フラッシュストレージデバイス３は、上述したように、コントローラ４およびＮＡＮＤ型フラッシュメモリ５を備える。フラッシュストレージデバイス３は、ランダムアクセスメモリ、例えば、ＤＲＡＭ６も備えていてもよい。

ＮＡＮＤ型フラッシュメモリ５は、マトリクス状に配置された複数のメモリセルを含むメモリセルアレイを含む。ＮＡＮＤ型フラッシュメモリ５は、２次元構造のＮＡＮＤ型フラッシュメモリであってもよいし、３次元構造のＮＡＮＤ型フラッシュメモリであってもよい。

ＮＡＮＤ型フラッシュメモリ５のメモリセルアレイは、複数のブロックＢＬＫ０〜ＢＬＫｍ−１を含む。ブロックＢＬＫ０〜ＢＬＫｍ−１の各々は多数のページ（ここではページＰ０〜Ｐｎ−１）によって編成される。ブロックＢＬＫ０〜ＢＬＫｍ−１は、消去単位として機能する。ブロックは、「消去ブロック」、「物理ブロック」、または「物理消去ブロック」と称されることもある。ページＰ０〜Ｐｎ−１の各々は、同一ワード線に接続された複数のメモリセルを含む。ページＰ０〜Ｐｎ−１は、データ書き込み動作およびデータ読み込み動作の単位である。

コントローラ４は、Ｔｏｇｇｌｅ、オープンＮＡＮＤフラッシュインタフェース（ＯＮＦＩ）のようなＮＡＮＤインタフェース１３を介して、不揮発性メモリであるＮＡＮＤ型フラッシュメモリ５に電気的に接続されている。コントローラ４は、ＮＡＮＤ型フラッシュメモリ５を制御するように構成されたメモリコントローラ（制御回路）である。

ＮＡＮＤ型フラッシュメモリ５は、図４に示すように、複数のＮＡＮＤ型フラッシュメモリダイを含む。各ＮＡＮＤ型フラッシュメモリダイは、複数のブロックＢＬＫを含むメモリセルアレイとこのメモリセルアレイを制御する周辺回路とを含む不揮発性メモリダイである。個々のＮＡＮＤ型フラッシュメモリダイは独立して動作可能である。このため、ＮＡＮＤ型フラッシュメモリダイは、並列動作単位として機能する。ＮＡＮＤ型フラッシュメモリダイは、「ＮＡＮＤ型フラッシュメモリチップ」または「不揮発性メモリチップ」とも称される。図４においては、ＮＡＮＤインタフェース１３に１６個のチャンネルＣｈ１、Ｃｈ２、…Ｃｈ１６が接続されており、これらチャンネルＣｈ１、Ｃｈ２、…Ｃｈ１６の各々に、同数（例えばチャンネル当たり２個のダイ）のＮＡＮＤ型フラッシュメモリダイそれぞれが接続されている場合が例示されている。各チャンネルは、対応するＮＡＮＤ型フラッシュメモリダイと通信するための通信線（メモリバス）を含む。

コントローラ４は、チャンネルＣｈ１、Ｃｈ２、…Ｃｈ１６を介してＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２を制御する。コントローラ４は、チャンネルＣｈ１、Ｃｈ２、…Ｃｈ１６を同時に駆動することができる。

チャンネルＣｈ１〜Ｃｈ１６に接続された１６個のＮＡＮＤ型フラッシュメモリダイ＃１〜＃１６は第１のバンクとして編成されてもよく、またチャンネルＣｈ１〜Ｃｈ１６に接続された残りの１６個のＮＡＮＤ型フラッシュメモリダイ＃１７〜＃３２は第２のバンクとして編成されてもよい。バンクは、複数のメモリモジュールをバンクインタリーブによって並列動作させるための単位として機能する。図５の構成例においては、１６チャンネルと、２つのバンクを使用したバンクインタリーブとによって、最大３２個のＮＡＮＤ型フラッシュメモリダイを並列動作させることができる。

本実施形態では、コントローラ４は、各々が複数のブロックＢＬＫから構成される複数のブロック（以下、スーパーブロックと称する）を管理してもよく、スーパーブロックの単位で消去動作を実行してもよい。

スーパーブロックは、これに限定されないが、ＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２から一つずつ選択される計３２個のブロックＢＬＫを含んでいてもよい。なお、ＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２の各々はマルチプレーン構成を有していてもよい。例えば、ＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２の各々が、２つのプレーンを含むマルチプレーン構成を有する場合には、一つのスーパーブロックは、ＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２に対応する６４個のプレーンから一つずつ選択される計６４個のブロックＢＬＫを含んでいてもよい。図５には、一つのスーパーブロックＳＢが、ＮＡＮＤ型フラッシュメモリダイ＃１〜＃３２から一つずつ選択される計３２個のブロックＢＬＫ（図４においては太枠で囲まれているブロックＢＬＫ）から構成される場合が例示されている。

図３に示されているように、コントローラ４は、ホストインタフェース１１、ＣＰＵ１２、ＮＡＮＤインタフェース１３、およびＤＲＡＭインタフェース１４等を含む。これらＣＰＵ１２、ＮＡＮＤインタフェース１３、ＤＲＡＭインタフェース１４は、バス１０を介して相互接続される。

このホストインタフェース１１は、ホスト２との通信を実行するように構成されたホストインタフェース回路である。このホストインタフェース１１は、例えば、ＰＣＩｅコントローラ（ＮＶＭｅコントローラ）であってよい。ホストインタフェース１１は、ホスト２から様々な要求（コマンド）を受信する。これら要求（コマンド）には、ライト要求（ライトコマンド）、リード要求（リードコマンド）、他の様々な要求（コマンド）が含まれる。

ＣＰＵ１２は、ホストインタフェース１１、ＮＡＮＤインタフェース１３、ＤＲＡＭインタフェース１４を制御するように構成されたプロセッサである。ＣＰＵ１２は、フラッシュストレージデバイス３の電源オンに応答してＮＡＮＤ型フラッシュメモリ５または図示しないＲＯＭから制御プログラム（ファームウェア）をＤＲＡＭ６にロードし、そしてこのファームウェアを実行することによって様々な処理を行う。なお、ファームウェアはコントローラ４内の図示しないＳＲＡＭ上にロードされてもよい。このＣＰＵ１２は、ホスト２からの様々なコマンドを処理するためのコマンド処理等を実行することができる。ＣＰＵ１２の動作は、ＣＰＵ１２によって実行される上述のファームウェアによって制御される。なお、コマンド処理の一部または全部は、コントローラ４内の専用ハードウェアによって実行してもよい。

ＣＰＵ１２は、ＡＰＩ設定／選択部２０、ライト動作制御部２１、リード動作制御部２２、およびＧＣ動作制御部２３として機能することができる。

ＡＰＩ設定／選択部２０は、ホスト２からの要求に基づき、個々の領域毎に、使用すべきＡＰＩを設定する。また、ＡＰＩ設定／選択部２０は、ホスト２から受信されるリード／ライト要求に含まれるＩＤに基づいて、リード／ライトアクセスのために使用されるべきＡＰＩを選択する。

ライト動作制御部２１は、上述の複数種のＡＰＩに対応する複数種の書き込み処理を実行することができる。リード動作制御部２２も、上述の複数種のＡＰＩに対応する複数種のリード処理を実行することができる。同様に、ＧＣ動作制御部２３も、上述の複数種のＡＰＩに対応する複数種のＧＣ動作を実行することができる。

＜物理アドレスＡＰＩ（タイプ＃１）に対応する書き込み処理＞
物理アドレスＡＰＩ（タイプ＃１）においては、ライト動作制御部２１は、論理アドレスを指定するライト要求（ライトコマンド）をホスト２から受信する。論理アドレスは、書き込むべきデータ（ユーザデータ）を識別可能な識別子であり、例えば、ＬＢＡであってもよいし、あるいはキー・バリュー・ストアのキーのようなタグであってもよいし、キーのハッシュ値であってもよい。

ライトコマンドを受信した場合、ライト動作制御部２１は、まず、ホスト２からのデータを書き込むべきブロック（書き込み先ブロック）およびこのブロック内の位置（書き込み先位置）を決定する。次いで、ライト動作制御部２１は、ホスト２からのデータ（ライトデータ）を、この書き込み先ブロックの書き込み先位置に書き込む。この場合、ライト動作制御部２１は、ホスト２からのデータのみならず、このデータとこのデータの論理アドレスの双方を書き込み先ブロックに書き込むことができる。そして、ライト動作制御部２１は、指定された論理アドレスと、データ（ライトデータ）が書き込まれたＮＡＮＤ型フラッシュメモリ５内の位置（物理記憶位置）を示す物理アドレスとをホスト２に返す。

この場合、この物理アドレスは、（１）この書き込み先ブロックのブロック番号と、（２）この書き込み先ブロック内の書き込み先位置を示すブロック内オフセットとによって表される。ブロック番号は、データが書き込まれたブロックを指定する識別子である。ブロック番号としては、複数のブロック内の任意の一つを一意に識別可能な様々な値を使用し得る。

ブロック内オフセットは、書き込み先ブロック内の位置を示すブロック内物理アドレスである。このブロック内オフセットは、書き込み先ブロックの先頭から書き込み先位置までのオフセット、つまり書き込み先ブロックの先頭に対する書き込み先位置のオフセットを示す。書き込み先ブロックの先頭から書き込み先位置までのオフセットのサイズは、ページサイズとは異なるサイズを有する粒度（Ｇｒａｉｎ）の倍数で示される。粒度（Ｇｒａｉｎ）は、アクセス単位である。粒度（Ｇｒａｉｎ）のサイズの最大値は、ブロックサイズまでに制限される。換言すれば、ブロック内オフセットは、書き込み先ブロックの先頭から書き込み先位置までのオフセットをページサイズとは異なるサイズを有する粒度の倍数で示す。

粒度（Ｇｒａｉｎ）は、ページサイズよりも小さいサイズを有していてもよい。例えば、ページサイズが１６Ｋバイトである場合、粒度（Ｇｒａｉｎ）は、そのサイズが４Ｋバイトであってもよい。この場合、ある一つのブロックにおいては、各々サイズが４Ｋバイトである複数のオフセット位置が規定される。ブロック内の最初のオフセット位置に対応するブロック内オフセットは、例えば０であり、ブロック内の次のオフセット位置に対応するブロック内オフセットは、例えば１である、ブロック内のさらに次のオフセット位置に対応するブロック内オフセットは、例えば２である。

あるいは、粒度（Ｇｒａｉｎ）は、ページサイズよりも大きなサイズを有していてもよい。例えば、粒度（Ｇｒａｉｎ）は、ページサイズの数倍のサイズであってもよい。ページサイズが１６Ｋバイトである場合、粒度は、３２Ｋバイトのサイズであってもよい。

このように、ライト動作制御部２１は、データを書き込むべきブロックおよびこのブロック内の位置の双方を自身で決定し、そしてホスト２からのデータ（ユーザデータ）が書き込まれた位置を示す物理アドレスをホスト２に通知する。この物理アドレスとしては、ブロック番号およびブロック内オフセットを使用することができる。ブロック番号によって指定されるブロックは、物理ブロックであってもよいし、上述のスーパーブロックであってもよい。

ホスト２は、ブロックサイズ、ページ書き込み順序制約、バッドページ、ページサイズ等を意識することなく、ユーザデータをＮＡＮＤ型フラッシュメモリ５に書き込むことができ、さらに、ブロック番号およびブロック内オフセットによって表された物理アドレスを、このユーザデータの論理アドレスにマッピングすることができる。

＜物理アドレスＡＰＩ（タイプ＃１）に対応するリード処理＞
物理アドレスＡＰＩ（タイプ＃１）においては、リード動作制御部２２は、物理アドレス（すなわち、ブロック番号およびブロック内オフセット（ブロック内物理アドレス））を指定するリード要求（リードコマンド）をホスト２から受信する。リードコマンドをホスト２から受信した場合、リード動作制御部２２は、これらブロック番号およびブロック内オフセットに基づいてＮＡＮＤ型フラッシュメモリ５からデータをリードする。リード対象のブロックは、ブロック番号によって特定される。このブロック内のリード対象の物理記憶位置は、ブロック内オフセットによって特定される。

リード対象の物理記憶位置を得るために、リード動作制御部２２は、まず、このブロック内オフセットを、ページサイズを表す粒度の数（ここでは、４）で除算し、そしてこの除算によって得られる商および余りを、リード対象のページ番号およびリード対象のページ内オフセットとしてそれぞれ決定してもよい。

＜物理アドレスＡＰＩ（タイプ＃１）に対応するＧＣ動作＞
物理アドレスＡＰＩ（タイプ＃１）においては、ＧＣ動作制御部２３は、ガベージコレクションのためのコピー元ブロック（ＧＣソースブロック）およびコピー先ブロック（ＧＣデスティネーションブロック）をＮＡＮＤ型フラッシュメモリ５内の多数のブロックから選択する。この場合、ＧＣ動作制御部２３は、通常、複数のコピー元ブロック（ＧＣソースブロック）と、一つ以上のコピー先ブロック（ＧＣデスティネーションブロック）とを選択する。コピー元ブロック（ＧＣソースブロック）を選択するための条件（ＧＣポリシー）は、ホスト２によって指定されてもよい。例えば、有効データ量が最も少ないブロックをコピー元ブロック（ＧＣソースブロック）として優先的に選択するというＧＣポリシーが使用されてもよいし、別のＧＣポリシーが使用されてもよい。このように、コピー元ブロック（ＧＣソースブロック）およびコピー先ブロック（ＧＣデスティネーションブロック）の選択は、ホスト２ではなく、フラッシュストレージデバイス３のコントローラ４（ＧＣ動作制御部２３）によって実行される。コントローラ４は、各ブロック管理テーブルを使用して、各ブロックの有効データ量を管理してもよい。

有効データ／無効データの管理は、ブロック管理テーブル３２を使用して実行されてもよい。このブロック管理テーブル３２は、例えば、ブロック毎に存在してもよい。あるブロックに対応するブロック管理テーブル３２においては、このブロック内のデータそれぞれの有効／無効を示すビットマップフラグが格納されている。ここで、有効データとは、ＬＵＴから参照されているデータ（すなわち論理アドレスから最新のデータとして紐付けられているデータ）であって、後にホスト２からリードされる可能性があるデータを意味する。無効データとは、もはやホスト２からリードされる可能性が無いデータを意味する。例えば、ある論理アドレスに関連付けられているデータは有効データであり、どの論理アドレスにも関連付けられていないデータは無効データである。

ＧＣ動作制御部２３は、コピー元ブロック（ＧＣソースブロック）内に格納されている有効データを書き込むべきコピー先ブロック（ＧＣデスティネーションブロック）内の位置（コピー先位置）を決定し、有効データをコピー先ブロック（ＧＣデスティネーションブロック）のこの決定された位置（コピー先位置）にコピーする。この場合、ＧＣ動作制御部２３は、有効データとこの有効データの論理アドレスの双方を、コピー先ブロック（ＧＣデスティネーションブロック）にコピーしてもよい。ＧＣ動作制御部２３は、コピー元ブロック（ＧＣソースブロック）に対応するブロック管理テーブル３２を参照することによってＧＣソースブロック内の有効データを特定してもよい。あるいは、別の実施形態では、有効データ／無効データの管理がホスト２によって実行されてもよい。この場合には、ＧＣ動作制御部２３は、ＧＣソースブロック内の各データの有効／無効を示す情報をホスト２から受信し、この受信した情報に基づいて、ＧＣソースブロック内の有効データを特定してもよい。

そして、ＧＣ動作制御部２３は、コピーされた有効データの論理アドレスと、コピー先ブロック（ＧＣデスティネーションブロック）のブロック番号と、コピー先ブロック（ＧＣデスティネーションブロック）の先頭からコピー先位置までのオフセットを上述の粒度の倍数で示すブロック内オフセットとをホスト２に通知する。

上述したように、ライト動作制御部２１は、ホスト２からのデータ（ライトデータ）とホスト２からの論理アドレスの双方を書き込み先ブロックに書き込むことができる。このため、ＧＣ動作制御部２３は、コピー元ブロック（ＧＣソースブロック）内の各データの論理アドレスをこのコピー元ブロック（ＧＣソースブロック）から容易に取得することができるので、コピーされた有効データの論理アドレスをホスト２に容易に通知することができる。

＜物理アドレスＡＰＩ（タイプ＃２）に対応する書き込み処理＞
物理アドレスＡＰＩ（タイプ＃２）においては、ライト動作制御部２１は、ブロック番号と論理アドレスを指定するライト要求（ライトコマンド）をホスト２から受信する。論理アドレスは、書き込むべきデータ（ユーザデータ）を識別可能な識別子であり、例えば、ＬＢＡであってもよいし、あるいはキー・バリュー・ストアのキーのようなタグであってもよいし、キーのハッシュ値であってもよい。ライトコマンドを受信した場合、ライト動作制御部２１は、まず、ホスト２からのデータを書き込むべき、この指定されたブロック番号を有するブロック（書き込み先ブロック）内の位置（書き込み先位置）を決定する。次いで、ライト動作制御部２１は、ホスト２からのデータ（ライトデータ）を、この書き込み先ブロックの書き込み先位置に書き込む。この場合、ライト動作制御部２１は、ホスト２からのデータのみならず、このデータとこのデータの論理アドレスの双方を書き込み先ブロックに書き込むことができる。

そして、ライト動作制御部２１は、論理アドレスそれぞれとこのブロックのブロック内物理アドレスそれぞれとの間のマッピングを管理するブロック内ＬＵＴを更新して、この書き込み先ブロックの上述の書き込み先位置を示すブロック内物理アドレスをライトデータの論理アドレスにマッピングする。

この場合、このブロック内物理アドレスは、この書き込み先ブロック内の書き込み先位置を示すブロック内オフセットによって表される。

このように、ライト動作制御部２１は、ホスト２からのブロック番号を有するブロック内の書き込み先位置を自身で決定し、そしてホスト２からのライトデータをこのブロック内のこの書き込み先位置に書き込む。そして、ライト動作制御部２１は、このブロックに対応するブロック内ＬＵＴを更新して、書き込み先位置を示すブロック内物理アドレス（ブロック内オフセット）をライトデータの論理アドレスにマッピングする。これにより、フラッシュストレージデバイス３は、ブロック番号をホスト２にハンドリングさせつつ、ページ書き込み順序制約、バッドページ、ページサイズ等を隠蔽することができる。

この結果、ホスト２は、ブロック境界は認識できるが、ページ書き込み順序制約、バッドページ、ページサイズについては意識することなく、どのユーザデータがどのブロック番号に存在するかを管理することができる。

＜物理アドレスＡＰＩ（タイプ＃２）に対応するリード処理＞
物理アドレスＡＰＩ（タイプ＃２）においては、リード動作制御部２２は、論理アドレスとブロック番号を指定するリード要求（リードコマンド）をホスト２から受信する。論理アドレスは、書き込むべきデータ（ユーザデータ）を識別可能な識別子であり、例えば、ＬＢＡであってもよいし、あるいはキー・バリュー・ストアのキーのようなタグであってもよいし、キーのハッシュ値であってもよい。リードコマンドをホスト２から受信した場合、リード動作制御部２２は、この論理アドレスを使用して、このリード要求によって指定されたブロック番号を有するブロックに対応するブロック内ＬＵＴ３２を参照する。これにより、リード動作制御部２２は、この論理アドレスに対応するデータが格納されている、このブロックのブロック内物理アドレス（ブロック内オフセット）を取得することができる。そして、リード動作制御部２２は、リード要求によって指定されたブロック番号と、取得されたブロック内物理アドレスとに基づいて、この論理アドレスに対応するデータをＮＡＮＤ型フラッシュメモリ５からリードする。

この場合、リード対象のブロックは、ブロック番号によって特定される。このブロック内のリード対象の物理記憶位置は、ブロック内オフセットによって特定される。リード対象の物理記憶位置を得るために、リード動作制御部２２は、まず、このブロック内オフセットを、ページサイズを表す粒度の数（ここでは、４）で除算し、そしてこの除算によって得られる商および余りを、リード対象のページ番号およびリード対象のページ内オフセットとしてそれぞれ決定してもよい。

＜物理アドレスＡＰＩ（タイプ＃２）に対応するＧＣ動作＞
物理アドレスＡＰＩ（タイプ＃２）においては、ＧＣ動作制御部２３は、ＮＡＮＤ型フラッシュメモリ５のガベージコレクションのためのコピー元ブロック番号（ＧＣソースブロック番号）およびコピー先ブロック番号（ＧＣデスティネーションブロック番号）を指定するＧＣ制御コマンドをホスト２から受信する。ＧＣ制御コマンドをホスト２から受信した場合、ＧＣ動作制御部２３は、ＮＡＮＤ型フラッシュメモリ５の複数のブロックから、指定されたコピー元ブロック番号を有するブロックと指定されたコピー先ブロック番号を有するブロックとをコピー元ブロック（ＧＣソースブロック）およびコピー先ブロック番号（ＧＣデスティネーションブロック）として選択する。ＧＣ動作制御部２３は、選択されたＧＣソースブロックに格納されている有効データを書き込むべきＧＣデスティネーションブロック内のコピー先位置を決定し、有効データをＧＣデスティネーションブロック内のコピー先位置にコピーする。

そして、ＧＣ動作制御部２３は、有効データの論理アドレスにマッピングされているブロック内物理アドレス（ブロック内オフセット）が、この有効データが格納されているＧＣソースブロック内のコピー元位置を示すブロック内物理アドレスから、ＧＣデスティネーションブロック内のコピー先位置を示すブロック内物理アドレスに変更されるように、ＧＣソースブロックに対応するブロック内ＬＵＴとＧＣデスティネーションブロックに対応するブロック内ＬＵＴを更新する。

上述したように、ＧＣ動作制御部２３は、コピー元ブロック（ＧＣソースブロック）内に格納されている有効データを書き込むべきコピー先ブロック（ＧＣデスティネーションブロック）内の位置（コピー先位置）を決定し、有効データをコピー先ブロック（ＧＣデスティネーションブロック）のこの決定された位置（コピー先位置）にコピーする。この場合、ＧＣ動作制御部２３は、有効データとこの有効データの論理アドレスの双方を、コピー先ブロック（ＧＣデスティネーションブロック）にコピーしてもよい。

上述したように、ライト動作制御部２１は、ホスト２からのデータ（ライトデータ）とホスト２からの論理アドレスの双方を書き込み先ブロックに書き込むことができる。このため、ＧＣ動作制御部２３は、コピー元ブロック（ＧＣソースブロック）内の各データの論理アドレスをこのコピー元ブロック（ＧＣソースブロック）から容易に取得することができるので、コピー元ブロックに対応するブロック内ＬＵＴおよびコピー先ブロックに対応するブロック内ＬＵＴを容易に更新することができる。

＜物理アドレスＡＰＩ（タイプ＃３）に対応する書き込み処理＞
物理アドレスＡＰＩ（タイプ＃３）は、物理アドレスＡＰＩ（タイプ＃２）と物理アドレスＡＰＩ（タイプ＃１）の中間のＡＰＩである。物理アドレスＡＰＩ（タイプ＃３）においては、物理アドレスＡＰＩ（タイプ＃２）とは異なり、ブロック内ＬＵＴは使用されない。

物理アドレスＡＰＩ（タイプ＃３）においては、ライト動作制御部２１は、ブロック番号と論理アドレスを指定するライト要求（ライトコマンド）をホスト２から受信する。論理アドレスは、書き込むべきデータ（ユーザデータ）を識別可能な識別子であり、例えば、ＬＢＡであってもよいし、あるいはキー・バリュー・ストアのキーのようなタグであってもよいし、キーのハッシュ値であってもよい。ライトコマンドを受信した場合、ライト動作制御部２１は、まず、ホスト２からのデータを書き込むべき、この指定されたブロック番号を有するブロック（書き込み先ブロック）内の位置（書き込み先位置）を決定する。次いで、ライト動作制御部２１は、ホスト２からのデータ（ライトデータ）を、この書き込み先ブロックの書き込み先位置に書き込む。この場合、ライト動作制御部２１は、ホスト２からのデータのみならず、このデータとこのデータの論理アドレスの双方を書き込み先ブロックに書き込むことができる。

そして、ライト動作制御部２１は、この書き込み先ブロックの上述の書き込み先位置を示すブロック内物理アドレスをホスト２に通知する。このブロック内物理アドレスは、この書き込み先ブロック内の書き込み先位置を示すブロック内オフセットによって表される。

このように、ライト動作制御部２１は、ホスト２からのブロック番号を有するブロック内の書き込み先位置を自身で決定し、そしてホスト２からのライトデータをこのブロック内のこの書き込み先位置に書き込む。そして、ライト動作制御部２１は、この書き込み先位置を示すブロック内物理アドレス（ブロック内オフセット）をライト要求に対応するレスポンス（返り値）としてホスト２に通知する。あるいは、ライト動作制御部２１は、ブロック内物理アドレス（ブロック内オフセット）のみをホスト２に通知するのではなく、論理アドレスとブロック番号とブロック内物理アドレス（ブロック内オフセット）との組をホスト２に通知してもよい。

したがって、フラッシュストレージデバイス３は、ブロック番号をホスト２にハンドリングさせつつ、ページ書き込み順序制約、バッドページ、ページサイズ等を隠蔽することができる。

この結果、ホスト２は、ブロック境界は認識できるが、ページ書き込み順序制約、バッドページ、ページサイズについては意識することなく、どのユーザデータがどのブロック番号に存在するかを管理することができる。

＜物理アドレスＡＰＩ（タイプ＃３）に対応するリード処理＞
物理アドレスＡＰＩ（タイプ＃３）においては、リード動作制御部２２は、物理アドレス（すなわち、ブロック番号およびブロック内オフセット）を指定するリード要求（リードコマンド）をホスト２から受信する。リードコマンドをホスト２から受信した場合、リード動作制御部２２は、これらブロック番号およびブロック内オフセットに基づいて、リード対象のブロック内のリード対象の物理記憶位置からデータをリードする。リード対象のブロックは、ブロック番号によって特定される。このブロック内のリード対象の物理記憶位置は、ブロック内オフセットによって特定される。

リード対象の物理記憶位置を得るために、リード動作制御部２２は、まず、このブロック内オフセットを、ページサイズを表す粒度の数（ページサイズが１６Ｋバイトで粒度（Ｇｒａｉｎ）が４Ｋバイトである場合には、ページサイズを表す粒度の数は４）で除算し、そしてこの除算によって得られる商および余りを、リード対象のページ番号およびリード対象のページ内オフセットとしてそれぞれ決定してもよい。

＜物理アドレスＡＰＩ（タイプ＃３）に対応するＧＣ動作＞
物理アドレスＡＰＩ（タイプ＃３）においては、ＧＣ動作制御部２３は、ＮＡＮＤ型フラッシュメモリ５のガベージコレクションのためのコピー元ブロック番号（ＧＣソースブロック番号）およびコピー先ブロック番号（ＧＣデスティネーションブロック番号）を指定するＧＣ制御コマンドをホスト２から受信する。ＧＣ制御コマンドをホスト２から受信した場合、ＧＣ動作制御部２３は、ＮＡＮＤ型フラッシュメモリ５の複数のブロックから、指定されたコピー元ブロック番号を有するブロックと指定されたコピー先ブロック番号を有するブロックとをコピー元ブロック（ＧＣソースブロック）およびコピー先ブロック（ＧＣデスティネーションブロック）として選択する。ＧＣ動作制御部２３は、選択されたＧＣソースブロックに格納されている有効データを書き込むべきＧＣデスティネーションブロック内のコピー先位置を決定し、有効データをＧＣデスティネーションブロック内のコピー先位置にコピーする。そして、ＧＣ動作制御部２３は、有効データの論理アドレスと、コピー先ブロック番号と、ＧＣデスティネーションブロック内のコピー先位置を示すブロック内物理アドレス（ブロック内オフセット）とを、ホスト２に通知する。

ＮＡＮＤインタフェース１３は、ＣＰＵ１２の制御の下、ＮＡＮＤ型フラッシュメモリ５を制御するように構成されたメモリ制御回路である。ＤＲＡＭインタフェース１４は、ＣＰＵ１２の制御の下、ＤＲＡＭ６を制御するように構成されたＤＲＡＭ制御回路である。ＤＲＡＭ６の記憶領域の一部は、ライトバッファ（ＷＢ）３１の格納のために使用される。また、ＤＲＡＭ６の記憶領域の他の一部は、ブロック管理テーブル３２の格納のために使用される。物理アドレスＡＰＩ（タイプ＃２）を使用するケースにおいては、ＤＲＡＭ６の記憶領域の他の一部は、ブロック内ＬＵＴの格納のために使用される。なお、これらライトバッファ（ＷＢ）３１、ブロック管理テーブル３２、ブロック内ＬＵＴは、コントローラ４内の図示しないＳＲＡＭに格納されてもよい。

図６は、拡張ネームスペース管理コマンドを示す。

拡張ネームスペース管理コマンドは、領域（ここではネームスペース）を作成または削除するための管理コマンドである。

拡張ネームスペース管理コマンドは、以下のパラメータを含む。

（１）作成／削除
（２）ＬＢＡ範囲
（３）物理リソースサイズ
（４）ＡＰＩタイプ
作成／削除のパラメータの値０ｈは、ネームスペースの作成をＳＳＤ３に要求する。作成／削除のパラメータの値１ｈは、ネームスペースの削除をＳＳＤ３に要求する。ネームスペースの削除を要求する場合には、削除対象のネームスペースのＩＤを示すパラメータが拡張ネームスペース管理コマンドに設定される。

ＬＢＡ範囲のパラメータは、ネームスペースのＬＢＡ範囲（ＬＢＡ０〜ｎ−１）を示す。このＬＢＡ範囲は、このネームスペースのユーザ領域にマッピングされる。

物理リソースサイズのパラメータは、ネームスペース用に確保されるべきブロックの個数を示す。

別の実施形態では、拡張ネームスペース管理コマンドは、物理リソースサイズのパラメータ代わりに、オーバープロビジョンのサイズを示すパラメータを含んでいてもよい。

オーバープロビジョンのサイズのパラメータは、ネームスペースに関連付けられた領域内のオーバープロビジョン領域用に確保されるべきブロックの個数を示す。もし拡張ネームスペース管理コマンドがオーバープロビジョンのサイズのパラメータを含むならば、ＳＳＤ３は、ネームスペースを作成し、且つこのネームスペースに関連付けられた領域内のオーバープロビジョン領域に、このパラメータによって指定された個数のブロックを割り当ててもよい。

ＡＰＩタイプのパラメータの値とＡＰＩタイプとの関係は、次の通りである。

０００： ＬＢＡ ＡＰＩ
００１： 物理アドレスＡＰＩ（タイプ＃１）
０１０： 物理アドレスＡＰＩ（タイプ＃２）
０１１： 物理アドレスＡＰＩ（タイプ＃３）
１００： キー・バリューＡＰＩ
１０１： 他のＡＰＩ（例えば可変長ＬＵＴ）
図７は、フラッシュストレージデバイス３によって実行される領域（ここでは、ネームスペース）作成処理を示す。

ホスト２は、ネームスペースの作成を要求する拡張ネームスペース管理コマンドをＳＳＤ３に送出する。この拡張ネームスペース管理コマンドは、作成対象の領域（ここでは、ネームスペース）用に確保すべきブロックの個数を指定する物理リソースサイズパラメータ、および作成対象の領域（ここでは、ネームスペース）に対して設定すべきＡＰＩタイプを指定するＡＰＩタイプパラメータを含む。ＳＳＤ３内の一つのブロックの容量はＳＳＤ３からホスト２に報告されているので、ホスト２は、作成対象の領域（ここでは、ネームスペース）に適した個数のブロックを要求することができる。また、ホスト２は、作成対象の領域（ここでは、ネームスペース）に適したＡＰＩを指定することができる。例えば、オペレーティングシステムをブート可能なブータブル領域を作成する場合には、ホスト２は、ＬＢＡ ＡＰＩを指定すればよい。また、Ｉ／Ｏ性能を優先すべき領域を作成する場合には、ホスト２は、物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、または物理アドレスＡＰＩ（タイプ＃３）を指定すればよい。

この拡張ネームスペース管理コマンドの受信に応答して、ＳＳＤ３のコントローラ４は、ネームスペース（ＮＳ＃０）を作成し、このネームスペース（ＮＳ＃０）に対して指定された個数のブロックを予約し、さらに、このネームスペース（ＮＳ＃０）のＡＰＩタイプを指定された種類のＡＰＩタイプに設定する（ステップＳ１）。コントローラ４は、コマンド完了を示すレスポンスをホスト２に送出する。このレスポンスは、作成されたネームスペースのＩＤを含んでいてもよい。

ホスト２は、次のネームスペースの作成を要求する拡張ネームスペース管理コマンドをＳＳＤ３に送出する。この拡張ネームスペース管理コマンドは、作成対象の領域（ここでは、ネームスペース）用に確保すべきブロックの個数を指定する物理リソースサイズパラメータ、および作成対象の領域（ここでは、ネームスペース）に対して設定すべきＡＰＩタイプを指定するＡＰＩタイプパラメータを含む。この拡張ネームスペース管理コマンドの受信に応答して、ＳＳＤ３のコントローラ４は、ネームスペース（ＮＳ＃１）を作成し、このネームスペース（ＮＳ＃１）に対して指定された個数のブロックを予約し、さらに、このネームスペース（ＮＳ＃１）のＡＰＩタイプを指定された種類のＡＰＩタイプに設定する（ステップＳ２）。コントローラ４は、コマンド完了を示すレスポンスをホスト２に送出する。このレスポンスは、作成されたネームスペースのＩＤを含んでいてもよい。

同様にして、ホスト２は、さらに次のネームスペースの作成を要求する拡張ネームスペース管理コマンドをＳＳＤ３に送出する。この拡張ネームスペース管理コマンドは、作成対象の領域（ここでは、ネームスペース）用に確保すべきブロックの個数を指定する物理リソースサイズパラメータ、および作成対象の領域（ここでは、ネームスペース）に対して設定すべきＡＰＩタイプを指定するＡＰＩタイプパラメータを含む。この拡張ネームスペース管理コマンドの受信に応答して、ＳＳＤ３のコントローラ４は、ネームスペース（ＮＳ＃ｎ）を作成し、このネームスペース（ＮＳ＃ｎ）に対して指定された個数のブロックを予約し、さらに、このネームスペース（ＮＳ＃ｎ）のＡＰＩタイプを指定された種類のＡＰＩタイプに設定する（ステップＳ３）。コントローラ４は、コマンド完了を示すレスポンスをホスト２に送出する。このレスポンスは、作成されたネームスペースのＩＤを含んでいてもよい。

このようにして、ネームスペースを作成する処理が繰り返されることによって、ＮＡＮＤ型フラッシュメモリ５は複数の領域に論理的に分割され、さらに領域毎に、ＡＰＩタイプが設定される。領域それぞれとＡＰＩタイプそれぞれとの間の対応関係は、フラッシュストレージデバイス３のコントローラ４によって管理されるＡＰＩタイプ管理テーブルによって管理される。

フラッシュストレージデバイス３のコントローラ４は、アクセス対象の領域を示す識別子（ネームスペースのＩＤ：ＮＳＩＤ）を含むコマンド（リードコマンド、ライトコマンド、ＧＣ制御コマンド、等）をホスト２から受信する。そして、受信したコマンドに含まれるＮＳＩＤと、ＡＰＩタイプ管理テーブルとに基づいて、コントローラ４は、使用すべきＡＰＩを選択する。

以下、物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）の詳細について説明する。

これら物理アドレスＡＰＩ（タイプ＃１）、物理アドレスＡＰＩ（タイプ＃２）、物理アドレスＡＰＩ（タイプ＃３）において使用される様々なコマンドの各々は、ある領域（ここではネームスペース）を指定するＮＳＩＤを含むが、以下の各コマンドの説明では、コマンドの特徴を主として説明し、ＮＳＩＤの説明については省略する。

＜物理アドレスＡＰＩ（タイプ＃１）の詳細＞
まず、図８〜図３５を参照して、物理アドレスＡＰＩ（タイプ＃１）について説明する。

図８は、従来型ＳＳＤとホストとの間の役割分担と、物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３とホスト２との間の役割分担とを示す。

図８の左部は、従来型ＳＳＤと仮想ディスクサービスを実行するホストとを含む計算機システム全体の階層構造を表している。

ホスト（サーバ）においては、複数のエンドユーザに複数の仮想マシンを提供するための仮想マシンサービス１０１が実行される。仮想マシンサービス１０１上の各仮想マシンにおいては、対応するエンドユーザによって使用されるオペレーティングシステムおよびユーザアプリケーション１０２が実行される。

また、ホスト（サーバ）においては、複数のユーザアプリケーション１０２に対応する複数の仮想ディスクサービス１０３が実行される。各仮想ディスクサービス１０３は、従来型ＳＳＤ内のストレージリソースの容量の一部を、対応するユーザアプリケーション１０２用のストレージリソース（仮想ディスク）として割り当てる。各仮想ディスクサービス１０３においては、アプリケーションレベルアドレス変換テーブルを使用して、アプリケーションレベルの論理アドレスをＳＳＤ用の論理アドレスに変換するアプリケーションレベルアドレス変換も実行される。さらに、ホストにおいては、アプリケーションレベルＧＣ１０４も実行される。

ホスト（サーバ）から従来型ＳＳＤへのコマンドの送信および従来型ＳＳＤからホスト（サーバ）へのコマンド完了のレスポンスの返送は、ホスト（サーバ）および従来型ＳＳＤの各々に存在するＩ／Ｏキュー２００を介して実行される。

従来型ＳＳＤは、ライトバッファ（ＷＢ）３０１、ルックアップテーブル（ＬＵＴ）３０２、ガベージコレクション機能３０３、ＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）３０４を含む。従来型ＳＳＤは、一つのルックアップテーブル（ＬＵＴ）３０２のみを管理しており、ＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）３０４のリソースは複数の仮想ディスクサービス１０３によって共有される。

この構成においては、仮想ディスクサービス１０３下のアプリケーションレベルＧＣ１０４と従来型ＳＳＤ内のガベージコレクション機能３０３（ＬＵＴレベルＧＣ）とを含む重複したＧＣにより、ライトアンプリフィケーションが大きくなる。また、従来型ＳＳＤにおいては、あるエンドユーザまたはある仮想ディスクサービス１０３からのデータ書き込み量の増加によってＧＣの頻度が増加し、これによって他のエンドユーザまたは他の仮想ディスクサービス１０３に対するＩ／Ｏ性能が劣化するというノイジーネイバー問題が生じうる。

また、各仮想ディスクサービス内のアプリケーションレベルアドレス変換テーブルと従来型ＳＳＤ内のＬＵＴ３０２とを含む重複したリソースの存在により、多くのメモリリソースが消費される。

図８の右部は、物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３とホスト２とを含む計算機システム全体の階層構造を表している。

ホスト（サーバ）２においては、複数のエンドユーザに複数の仮想マシンを提供するための仮想マシンサービス４０１が実行される。仮想マシンサービス４０１上の各仮想マシンにおいては、対応するエンドユーザによって使用されるオペレーティングシステムおよびユーザアプリケーション４０２が実行される。

また、ホスト（サーバ）２においては、複数のユーザアプリケーション４０２に対応する複数のＩ／Ｏサービス４０３が実行される。これらＩ／Ｏサービス４０３には、ＬＢＡベースのブロックＩ／Ｏサービス、キー・バリュー・ストアサービスなどが含まれてもよい。各Ｉ／Ｏサービス４０３は、論理アドレスそれぞれとフラッシュストレージデバイス３の物理アドレスそれぞれとの間のマッピングを管理するルックアップテーブル（ＬＵＴ）を含む。ここで、論理アドレスとは、アクセス対象のデータを識別可能な識別子を意味する。この論理アドレスは、論理アドレス空間上の位置を指定する論理ブロックアドレス（ＬＢＡ）であってもよいし、あるいは、キー・バリュー・ストアのキー（タグ）であってもよい。

ＬＢＡベースのブロックＩ／Ｏサービスにおいては、論理アドレス（ＬＢＡ）それぞれとフラッシュストレージデバイス３の物理アドレスそれぞれとの間のマッピングを管理するＬＵＴが使用されてもよい。

キー・バリュー・ストアサービスにおいては、論理アドレス（つまり、キーのようなタグ）それぞれとこれら論理アドレス（つまり、キーのようなタグ）に対応するデータが格納されているフラッシュストレージデバイス３の物理アドレスそれぞれとの間のマッピングを管理するＬＵＴが使用されてもよい。このＬＵＴにおいては、タグと、このタグによって識別されるデータが格納されている物理アドレスと、このデータのデータ長との対応関係が管理されてもよい。

各エンドユーザは、使用すべきアドレッシング方法（ＬＢＡ、キー・バリュー・ストアのキー、等）を選択することができる。

これら各ＬＵＴは、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３用の論理アドレスそれぞれに変換するのではなく、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３の物理アドレスそれぞれに変換する。つまり、これら各ＬＵＴは、フラッシュストレージデバイス３用の論理アドレスを物理アドレスに変換するテーブルとアプリケーションレベルアドレス変換テーブルとが統合（マージ）されたテーブルである。

ホスト（サーバ）２においては、上述のＱｏＳドメイン毎にＩ／Ｏサービス４０３が存在する。あるＱｏＳドメインに属するＩ／Ｏサービス４０３は、対応するＱｏＳドメイン内のユーザアプリケーション４０２によって使用される論理アドレスそれぞれと対応するＱｏＳドメインに割り当てられたリソースグループに属するブロック群の物理アドレスそれぞれとの間のマッピングを管理する。

ホスト（サーバ）２からフラッシュストレージデバイス３へのコマンドの送信およびフラッシュストレージデバイス３からホスト（サーバ）２へのコマンド完了のレスポンス等の返送は、ホスト（サーバ）２およびフラッシュストレージデバイス３の各々に存在するＩ／Ｏキュー５００を介して実行される。これらＩ／Ｏキュー５００も、複数のＱｏＳドメインに対応する複数のキューグループに分類されていてもよい。

フラッシュストレージデバイス３は、複数のＱｏＳドメインに対応する複数のライトバッファ（ＷＢ）６０１、複数のＱｏＳドメインに対応する複数のガベージコレクション（ＧＣ）機能６０２、ＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）６０３を含む。

この図８の右部に示す構成においては、従来型ＳＳＤ内のＬＵＴ３０２とアプリケーションレベルアドレス変換テーブルとがＩ／Ｏサービス４０３内の一つのＬＵＴとしてマージされているので、アドレス変換情報の格納のために消費されるメモリリソースの量を低減できる。また、アドレス変換ステージの数が減少するので、Ｉ／Ｏ性能を向上することが可能となる。

さらに、アプリケーションレベルＧＣとＬＵＴレベルＧＣを含む重複したＧＣではなく、フラッシュストレージデバイス３のみがＧＣ（ユニファイドＧＣ）のためのデータコピーを実行する。したがって、重複したＧＣが実行される構成に比し、システム全体のライトアンプリフィケーションを大幅に低減することが可能となる。この結果、Ｉ／Ｏ性能を改善することができ、且つフラッシュストレージデバイス３の寿命を最大化することが可能となる。

図９は、物理アドレスＡＰＩ（タイプ＃１）で使用されるライトコマンドを示す。

ライトコマンドは、フラッシュストレージデバイス３にデータの書き込みを要求するコマンドである。このライトコマンドは、コマンドＩＤ、ＱｏＳドメインＩＤ、論理アドレス、長さ、等を含んでもよい。

コマンドＩＤはこのコマンドがライトコマンドであることを示すＩＤ（コマンドコード）であり、ライトコマンドにはライトコマンド用のコマンドＩＤが含まれる。

ＱｏＳドメインＩＤは、データが書き込まれるべきＱｏＳドメインを一意に識別可能な識別子である。あるエンドユーザからのライト要求に応じてホスト２から送信されるライトコマンドは、このエンドユーザに対応するＱｏＳドメインを指定するＱｏＳドメインＩＤを含んでもよい。ネームスペースＩＤがＱｏＳドメインＩＤとして扱われてもよい。

論理アドレスは、書き込まれるべきライトデータを識別するための識別子である。この論理アドレスは、上述したように、ＬＢＡであってもよいし、キー・バリュー・ストアのキーであってもよい。論理アドレスがＬＢＡである場合には、このライトコマンドに含まれる論理アドレス（開始ＬＢＡ）は、ライトデータが書き込まれるべき論理位置（最初の論理位置）を示す。

長さは、書き込まれるべきライトデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、ＬＢＡの数によって指定されてもよいし、あるいはそのサイズがバイトによって指定されてもよい。

コントローラ４は、ＮＡＮＤ型フラッシュメモリ５内の多数のブロックの各々が一つのグループのみに属するようにＮＡＮＤ型フラッシュメモリ５内の多数のブロックを複数のグループ（複数のＱｏＳドメイン）に分類することができる。そして、コントローラ４は、グループ（ＱｏＳドメイン）毎に、フリーブロックリスト（フリーブロックプール）とアクティブブロックリスト（アクティブブロックプール）とを管理することができる。

各ブロックの状態は、有効データを格納しているアクティブブロックと、有効データを格納していないフリーブロックとに大別される。アクティブブロックである各ブロックは、アクティブブロックリストによって管理される。一方、フリーブロックである各ブロックは、フリーブロックリストによって管理される。

ホスト２からライトコマンドを受信した時、コントローラ４は、ホスト２からのデータが書き込まれるべきブロック（書き込み先ブロック）およびこの書き込み先ブロック内の位置（書き込み先位置）を決定する。コントローラ４は、ＱｏＳドメインＩＤに対応するＱｏＳドメインに属するフリーブロック群の一つを書き込み先ブロックとして決定してもよい。書き込み先位置は、ページ書き込み順序の制約およびバッドページ等を考慮して決定される。そして、コントローラ４は、ホスト２からのデータを、書き込み先ブロック内の書き込み先位置に書き込む。

なお、この書き込み先ブロック全体がユーザデータで満たされたならば、コントローラ４は、この書き込み先ブロックをアクティブブロックリスト（アクティブブロックプール）に移動する。そして、コントローラ４は、このＱｏＳドメインに対応するフリーブロックリストからフリーブロックを再び選択し、この選択したフリーブロックを新たな書き込み先ブロックとして割り当てる。

もしフリーブロックリストによって管理されている残りフリーブロックの数が所定のポリシーによって定められる閾値以下に低下した場合あるいはホスト２からガベージコレクションを実施する指示があった場合、コントローラ４は、このＱｏＳドメインのガベージコレクションを開始してもよい。

このＱｏＳドメインのガベージコレクションでは、コントローラ４は、このＱｏＳドメインに対応するアクティブブロック群からコピー元ブロック（ＧＣソースブロック）とコピー先ブロック（ＧＣデスティネーションブロック）を選択する。どのブロックをＧＣ候補（コピー元ブロック）として選択するかは、ホスト２によって指定される上述のポリシーに従って決定されてもよいし、ホスト２から指定されても良い。ポリシーも基づく場合には例えば、有効データ量が最も少ないブロックがＧＣ候補（コピー元ブロック）として選択されてもよい。

図１０は、図９のライトコマンドに対するレスポンスを示す。

このレスポンスは、論理アドレス、物理アドレス、長さを含む。

論理アドレスは、図９のライトコマンドに含まれていた論理アドレスである。

物理アドレスは、図９のライトコマンドに応じてデータが書き込まれたＮＡＮＤ型フラッシュメモリ５内の物理記憶位置を示す。物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３では、この物理アドレスは、ブロック番号とオフセット（ブロック内オフセット）との組み合わせによって指定される。ブロック番号は、フラッシュストレージデバイス３内の全てのブロックの任意の一つを一意に識別可能な識別子である。全てのブロックに異なるブロック番号が付与されている場合には、これらブロック番号を直接使用してもよい。あるいは、ブロック番号は、ダイ番号と、ダイ内ブロック番号との組み合わせによって表現されてもよい。長さは、書き込まれるべきライトデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、ＬＢＡの数によって指定されてもよいし、あるいはそのサイズがバイトによって指定されてもよい。

図１１は、物理アドレスＡＰＩ（タイプ＃１）で使用されるＴｒｉｍコマンドを示す。

このＴｒｉｍコマンドは、無効にすべきデータが格納されている物理記憶位置を示すブロック番号およびブロック内オフセットを含むコマンドである。つまり、このＴｒｉｍコマンドは、ＬＢＡのような論理アドレスではなく、物理アドレスを指定可能である。このＴｒｉｍコマンドは、コマンドＩＤ、物理アドレス、長さを含む。

コマンドＩＤはこのコマンドがＴｒｉｍコマンドであることを示すＩＤ（コマンドコード）であり、ＴｒｉｍコマンドにはＴｒｉｍコマンド用のコマンドＩＤが含まれる。

物理アドレスは、無効化すべきデータが格納されている最初の物理記憶位置を示す。物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３では、この物理アドレスは、ブロック番号とオフセット（ブロック内オフセット）との組み合わせによって指定される。

長さは、無効化すべきデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、バイトによって指定されてもよい。

コントローラ４は、複数のブロックの各々に含まれるデータそれぞれの有効／無効を示すフラグ（ビットマップフラグ）をブロック管理テーブル３２を使用して管理する。無効にすべきデータが格納されている物理記憶位置を示すブロック番号およびオフセット（ブロック内オフセット）を含むＴｒｉｍコマンドをホスト２から受信した場合、コントローラ４は、ブロック管理テーブル３２を更新して、Ｔｒｉｍコマンドに含まれるブロック番号およびブロック内オフセットに対応する物理記憶位置のデータに対応するフラグ（ビットマップフラグ）を無効を示す値に変更する。

図１２は、図１０のレスポンスに含まれる物理アドレスを規定するブロック番号およびオフセット（ブロック内オフセット）の例を示す。

ブロック番号はある一つのブロックＢＬＫを指定する。各ブロックＢＬＫは、図１２に示されているように、複数のページ（ここでは、ページ０〜ページｎ）を含む。

ページサイズ（各ページのユーザデータ格納領域）が１６Ｋバイトであり、粒度（Ｇｒａｉｎ）が４ＫＢのサイズであるケースにおいては、このブロックＢＬＫは、４×（ｎ＋１）個の領域に論理的に分割される。

オフセット＋０はページ０の最初の４ＫＢ領域を示し、オフセット＋１はページ０の２番目の４ＫＢ領域を示し、オフセット＋２はページ０の３番目の４ＫＢ領域を示し、オフセット＋３はページ０の４番目の４ＫＢ領域を示す。

オフセット＋４はページ１の最初の４ＫＢ領域を示し、オフセット＋５はページ１の２番目の４ＫＢ領域を示し、オフセット＋６はページ１の３番目の４ＫＢ領域を示し、オフセット＋７はページ１の４番目の４ＫＢ領域を示す。

図１３は、ライトコマンドに応じて実行される書き込み動作とこのライトコマンドに対するレスポンスに含まれる返値との関係を示す。

フラッシュストレージデバイス３のコントローラ４は、有効データを含まないフリーブロック群をフリーブロックリストによって管理しており、これらフリーブロック群から一つのブロック（フリーブロック）を選択し、選択したブロックを書き込み先ブロックとして割り当てる。いま、ブロックＢＬＫ＃１が書き込み先ブロックとして割り当てられた場合を想定する。コントローラ４は、ページ０、ページ１、ページ２、…ページｎという順序で、データをページ単位でブロックＢＬＫ＃１に書き込む。

図１３においては、ブロックＢＬＫ＃１のページ０に１６Ｋバイト分のデータがすでに書き込まれている状態で、論理アドレス（ＬＢＡｘ）および長さ（＝４）を指定するライトコマンドがホスト２から受信された場合が想定されている。コントローラ４は、ブロックＢＬＫ＃１のページ１を書き込み先位置として決定し、ホスト２から受信される１６Ｋバイト分のライトデータをブロックＢＬＫ＃１のページ１に書き込む。そして、コントローラ４は、このライトコマンドに対するレスポンス（論理アドレス、ブロック番号、オフセット（ブロック内オフセット）、長さ）をホスト２に返す。このケースにおいては、論理アドレスはＬＢＡｘであり、ブロック番号はＢＬＫ＃１であり、オフセット（ブロック内オフセット）は＋５であり、長さは４である。

図１４は、不良ページ（バッドページ）をスキップする書き込み動作を示す。

図１４においては、ブロックＢＬＫ＃１のページ０、ページ１にデータがすでに書き込まれている状態で、論理アドレス（ＬＢＡｘ＋１）および長さ（＝４）を指定するライトコマンドがホスト２から受信された場合が想定されている。もしブロックＢＬＫ＃１のページ２が不良ページであるならば、コントローラ４は、ブロックＢＬＫ＃１のページ３を書き込み先位置として決定し、ホスト２から受信される１６Ｋバイト分のライトデータをブロックＢＬＫ＃１のページ３に書き込む。そして、コントローラ４は、このライトコマンドに対するレスポンス（論理アドレス、ブロック番号、オフセット（ブロック内オフセット）、長さ）をホスト２に返す。このケースにおいては、論理アドレスはＬＢＡｘ＋１であり、ブロック番号はＢＬＫ＃１であり、オフセット（ブロック内オフセット）は＋１２であり、長さは４である。

図１５は、不良ページをスキップする書き込み動作の別の例を示す。

図１５においては、不良ページを挟む２つのページに跨がってデータが書き込まれる場合が想定されている。いま、ブロックＢＬＫ＃２のページ０、ページ１にデータがすでに書き込まれており、且つライトバッファ３１に未書き込みの８Ｋバイト分のライトデータが残っている場合を想定する。この状態で、論理アドレス（ＬＢＡｙ）および長さ（＝６）を指定するライトコマンドが受信されたならば、コントローラ４は、未書き込みの８Ｋバイトライトデータと、ホスト２から新たに受信される２４Ｋバイトライトデータ内の最初の８Ｋバイトライトデータとを使用して、ページサイズに対応する１６Ｋバイトライトデータを準備する。そして、コントローラ４は、この準備した１６ＫバイトライトデータをブロックＢＬＫ＃２のページ２に書き込む。

もしブロックＢＬＫ＃２の次のページ３が不良ページであるならば、コントローラ４は、ブロックＢＬＫ＃２のページ４を次の書き込み先位置として決定し、ホスト２から受信された２４Ｋバイトライトデータ内の残りの１６Ｋバイトライトデータを、ブロックＢＬＫ＃２のページ４に書き込む。

そして、コントローラ４は、このライトコマンドに対するレスポンス（論理アドレス、ブロック番号、オフセット（ブロック内オフセット）、長さ）をホスト２に返す。このケースにおいては、このレスポンスは、ＬＢＡｙ、ブロック番号（＝ＢＬＫ＃２）、オフセット（＝＋１０）、長さ（＝２）、ブロック番号（＝ＢＬＫ＃２）、オフセット（＝＋１６）、長さ（＝４）を含んでもよい。

図１６、図１７は、論理アドレスとデータのペアをブロック内のページに書き込む動作を示す。

各ブロックにおいて、各ページは、ユーザデータを格納するためのユーザデータ領域と管理データを格納するための冗長領域とを含んでもよい。ページサイズは１６ＫＢ＋アルファである。

コントローラ４は、４ＫＢユーザデータとこの４ＫＢユーザデータに対応する論理アドレス（例えばＬＢＡ）との双方を書き込み先ブロックＢＬＫに書き込む。この場合、図１６に示すように、各々がＬＢＡと４ＫＢユーザデータとを含む４つのデータセットが同じページに書き込まれてもよい。ブロック内オフセットは、セット境界を示してもよい。

あるいは、図１７に示されているように、４つの４ＫＢユーザデータがページ内のユーザデータ領域に書き込まれ、これら４つの４ＫＢユーザデータに対応する４つのＬＢＡがこのページ内の冗長領域に書き込まれてもよい。

図１８は、スーパーブロックが使用される場合におけるブロック番号とオフセット（ブロック内オフセット）との関係を示す。以下では、ブロック内オフセットは単にオフセットとしても参照される。

ここでは、図示を簡単化するために、ある一つのスーパーブロックＳＢ＃１が４つのブロックＢＬＫ＃１１、ＢＬＫ＃２１、ＢＬＫ＃３１、ＢＬＫ＃４１から構成されている場合が想定されている。コントローラ４は、ブロックＢＬＫ＃１１のページ０、ブロックＢＬＫ＃２１のページ０、ブロックＢＬＫ＃３１のページ０、ブロックＢＬＫ＃４１のページ０、ブロックＢＬＫ＃１１のページ１、ブロックＢＬＫ＃２１のページ１、ブロックＢＬＫ＃３１のページ１、ブロックＢＬＫ＃４１のページ１、…という順序でデータを書き込む。

オフセット＋０はブロックＢＬＫ＃１１のページ０の最初の４ＫＢ領域を示し、オフセット＋１はブロックＢＬＫ＃１１のページ０の２番目の４ＫＢ領域を示し、オフセット＋２はブロックＢＬＫ＃１１のページ０の３番目の４ＫＢ領域を示し、オフセット＋３はブロックＢＬＫ＃１１のページ０の４番目の４ＫＢ領域を示す。

オフセット＋４はブロックＢＬＫ＃２１のページ０の最初の４ＫＢ領域を示し、オフセット＋５はブロックＢＬＫ＃２１のページ０の２番目の４ＫＢ領域を示し、オフセット＋６はブロックＢＬＫ＃２１のページ０の３番目の４ＫＢ領域を示し、オフセット＋７はブロックＢＬＫ＃２１のページ０の４番目の４ＫＢ領域を示す。

同様に、オフセット＋１２はブロックＢＬＫ＃４１のページ０の最初の４ＫＢ領域を示し、オフセット＋１３はブロックＢＬＫ＃４１のページ０の２番目の４ＫＢ領域を示し、オフセット＋１４はブロックＢＬＫ＃４１のページ０の３番目の４ＫＢ領域を示し、オフセット＋１５はブロックＢＬＫ＃４１のページ０の４番目の４ＫＢ領域を示す。

オフセット＋１６はブロックＢＬＫ＃１１のページ１の最初の４ＫＢ領域を示し、オフセット＋１７はブロックＢＬＫ＃１１のページ１の２番目の４ＫＢ領域を示し、オフセット＋１８はブロックＢＬＫ＃１１のページ１の３番目の４ＫＢ領域を示し、オフセット＋１９はブロックＢＬＫ＃１１のページ１の４番目の４ＫＢ領域を示す。

オフセット＋２０はブロックＢＬＫ＃２１のページ１の最初の４ＫＢ領域を示し、オフセット＋２１はブロックＢＬＫ＃２１のページ１の２番目の４ＫＢ領域を示し、オフセット＋２２はブロックＢＬＫ＃２１のページ１の３番目の４ＫＢ領域を示し、オフセット＋２３はブロックＢＬＫ＃２１のページ１の４番目の４ＫＢ領域を示す。

同様に、オフセット＋２８はブロックＢＬＫ＃４１のページ１の最初の４ＫＢ領域を示し、オフセット＋２９はブロックＢＬＫ＃４１のページ１の２番目の４ＫＢ領域を示し、オフセット＋３０はブロックＢＬＫ＃４１のページ１の３番目の４ＫＢ領域を示し、オフセット＋３１はブロックＢＬＫ＃４１のページ１の４番目の４ＫＢ領域を示す。

例えば、あるＬＢＡ（ＬＢＡｘ）を指定するライトコマンドに対応する４Ｋバイトデータをオフセット＋８に対応する位置に書き込んだ場合には、コントローラ４は、論理アドレス（＝ＬＢＡｘ）、ブロック番号（＝ＳＢ＃１）、オフセット（＝＋８）、長さ（＝１）をこのライトコマンドに対するレスポンスとしてホスト２に返してもよい。

図１９のシーケンスチャートは、ホスト２と物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３とによって実行される書き込み動作処理のシーケンスを示す。

ホスト２は、ＱｏＳドメインＩＤ、ＬＢＡ、長さを含むライトコマンドをフラッシュストレージデバイス３に送信する。フラッシュストレージデバイス３のコントローラ４がこのライトコマンドを受信した時、コントローラ４は、ホスト２からのライトデータを書き込むべき書き込み先ブロックおよびこの書き込み先ブロック内の位置を決定する。より詳しくは、コントローラ４は、フリーブロックリストから一つのフリーブロックを選択し、選択したフリーブロックを書き込み先ブロックとして割り当てる（ステップＳ１１）。つまり、この選択されたフリーブロックおよびこの選択されたフリーブロック内の利用可能な最初のページが、ホスト２からのライトデータを書き込むべき書き込み先ブロックおよびこの書き込み先ブロック内の位置として決定される。もし書き込み先ブロックがすでに割り当てられている場合には、このステップ１１における書き込み先ブロック割り当て処理を実行する必要は無い。すでに割り当てられている書き込み先ブロック内の利用可能な次のページが、ホスト２からのライトデータを書き込むべき書き込み先ブロック内の位置として決定される。

コントローラ４は、複数のＱｏＳドメインに対応する複数のフリーブロックリストを管理してもよい。あるＱｏＳドメインに対応するフリーブロックリストにおいては、このＱｏＳドメインに対して予約されたブロック群のみが登録されてもよい。この場合、ステップＳ１２では、コントローラ４は、ライトコマンドのＱｏＳドメインＩＤによって指定されるＱｏＳドメインに対応するフリーブロックリストを選択し、この選択したフリーブロックリストから一つのフリーブロックを選択し、この選択したフリーブロックを書き込み先ブロックとして割り当ててもよい。これにより、異なるＱｏＳドメインに対応するデータが同じブロックに混在されてしまうことを防止することができる。

コントローラ４は、ホスト２から受信されるライトデータを書き込み先ブロックに書き込む（ステップＳ１２）。ステップＳ１２では、コントローラ４は、論理アドレス（ここではＬＢＡ）とライトデータの双方を書き込み先ブロックに書き込む。

コントローラ４は、ブロック管理テーブル３２を更新して、書き込まれたデータに対応するビットマップフラグ（つまり、このデータが書き込まれた物理記憶位置の物理アドレスに対応するビットマップフラグ）を０から１に変更する（ステップＳ１３）。例えば、図２０に示されているように、開始ＬＢＡがＬＢＡｘである１６Ｋバイト更新データがブロックＢＬＫ＃１のオフセット＋４〜＋７に対応する物理記憶位置に書き込まれた場合を想定する。この場合、図２１に示されているように、ブロックＢＬＫ＃１用のブロック管理テーブルにおいては、オフセット＋４〜＋７に対応するビットマップフラグそれぞれが０から１に変更される。

コントローラ４は、このライトコマンドに対するレスポンスをホスト２に返す（ステップＳ１４）。例えば、図２０に示されているように、開始ＬＢＡがＬＢＡｘである１６Ｋバイト更新データがブロックＢＬＫ＃１のオフセット＋４〜＋７に対応する物理記憶位置に書き込まれたならば、ＬＢＡｘ、ブロック番号（＝ＢＬＫ１）、オフセット（＝＋４）、長さ（＝４）を含むレスポンスがコントローラ４からホスト２に送信される。

ホスト２がこのレスポンスを受信した時、ホスト２は、ホスト２によって管理されているＬＵＴを更新して、書き込まれたライトデータに対応する論理アドレスそれぞれに物理アドレスをマッピングする。図２２に示されているように、ＬＵＴは、複数の論理アドレス（例えばＬＢＡ）それぞれに対応する複数のエントリを含む。ある論理アドレス（例えばあるＬＢＡ）に対応するエントリには、このＬＢＡに対応するデータが格納されているＮＡＮＤ型フラッシュメモリ５内の位置（物理記憶位置）を示す物理アドレスＰＢＡ、つまりブロック番号、オフセット（ブロック内オフセット）が格納される。図２０に示されているように、開始ＬＢＡがＬＢＡｘである１６Ｋバイト更新データがブロックＢＬＫ＃１のオフセット＋４〜＋７に対応する物理記憶位置に書き込まれたならば、図２２に示されているように、ＬＵＴが更新されて、ＬＢＡｘに対応するエントリにＢＬＫ＃１、オフセット＋４が格納され、ＬＢＡｘ＋１に対応するエントリにＢＬＫ＃１、オフセット＋５が格納され、ＬＢＡｘ＋２に対応するエントリにＢＬＫ＃１、オフセット＋６が格納され、ＬＢＡｘ＋３に対応するエントリにＢＬＫ＃１、オフセット＋７が格納される。

この後、ホスト２は、上述の更新データの書き込みによって不要になった以前のデータを無効化するためのＴｒｉｍコマンドをフラッシュストレージデバイス３に送信する（ステップＳ２１）。図２０に示されているように、以前のデータがブロックＢＬＫ＃０のオフセット＋０、オフセット＋１、オフセット＋２、オフセット＋３に対応する位置に格納されている場合には、図２３に示すように、ブロック番号（＝ＢＬＫ＃０）、オフセット（＝＋０）、長さ（＝４）を指定するＴｒｉｍコマンドがホスト２からフラッシュストレージデバイス３に送信される。フラッシュストレージデバイス３のコントローラ４は、このＴｒｉｍコマンドに応じて、ブロック管理テーブル３２を更新する（ステップＳ１５）。ステップＳ１５においては、図２３に示すように、ブロックＢＬＫ＃０用のブロック管理テーブルにおいて、オフセット＋０〜＋３に対応するビットマップフラグそれぞれが１から０に変更される。

図２４は、物理アドレスＡＰＩ（タイプ＃１）で使用されるリードコマンドを示す。

リードコマンドは、フラッシュストレージデバイス３にデータの読み出しを要求するコマンドである。このリードコマンドは、コマンドＩＤ、物理アドレスＰＢＡ、長さ、転送先ポインタを含む。

コマンドＩＤはこのコマンドがリードコマンドであることを示すＩＤ（コマンドコード）であり、リードコマンドにはリードコマンド用のコマンドＩＤが含まれる。

物理アドレスＰＢＡは、データが読み出されるべき最初の物理記憶位置を示す。物理アドレスＰＢＡは、ブロック番号、オフセット（ブロック内オフセット）によって指定される。

長さは、リードすべきデータの長さを示す。このデータ長は、Ｇｒａｉｎの数によって指定可能である。

転送先ポインタは、読み出されたデータが転送されるべきホスト２内のメモリ上の位置を示す。

一つのリードコマンドは、物理アドレスＰＢＡ（ブロック番号、オフセット）と長さの組を複数指定することができる。

図２５は、物理アドレスＡＰＩ（タイプ＃１）に対応するリード動作を示す。

ここでは、ブロック番号（＝ＢＬＫ＃２）、オフセット（＝＋５）、長さ（＝３）を指定するリードコマンドがホスト２から受信された場合が想定されている。フラッシュストレージデバイス３のコントローラ４は、ブロック番号（＝ＢＬＫ＃２）、オフセット（＝＋５）、長さ（＝３）に基づいて、ＢＬＫ＃２からデータｄ１〜ｄ３をリードする。この場合、コントローラ４は、ＢＬＫ＃２のページ１から１ページサイズ分のデータをリードし、このリードデータからデータｄ１〜データｄ３を抽出する。次いで、コントローラ４は、データｄ１〜データｄ３を、転送先ポインタによって指定されるホストメモリ上に転送する。

図２６のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃１）に対応するリード処理のシーケンスを示す。

ホスト２は、ホスト２によって管理されているＬＵＴを参照して、ユーザアプリケーションからのリード要求に含まれる論理アドレスをブロック番号、オフセットに変換する。そして、ホスト２は、このブロック番号、オフセット、長さを指定するリードコマンドをフラッシュストレージデバイス３に送信する。

フラッシュストレージデバイス３のコントローラ４がリードコマンドをホスト２から受信した時、コントローラ４は、このリードコマンドによって指定されたブロック番号に対応するブロックをリード対象のブロックとして決定するとともに、このリードコマンドによって指定されたオフセットに基づいてリード対象のページを決定する（ステップＳ３１）。ステップＳ３１では、コントローラ４は、まず、リードコマンドによって指定されたオフセットを、ページサイズを表す粒度の数（ここでは、４）で除算してもよい。そして、コントローラ４は、この除算によって得られる商および余りを、リード対象のページ番号およびリード対象のページ内オフセット位置としてそれぞれ決定してもよい。

コントローラ４は、ブロック番号、オフセット、長さによって規定されるデータをＮＡＮＤ型フラッシュメモリ５からリードし（ステップＳ３２）、このリードデータをホスト２に送信する。

図２７は、物理アドレスＡＰＩ（タイプ＃１）で使用されるガベージコレクション（ＧＣ）制御コマンドを示す。

ＧＣ制御コマンドは、コマンドＩＤ、ポリシー、ソースＱｏＳドメインＩＤ、デスティネーションＱｏＳドメインＩＤ、等を含んでもよい。

コマンドＩＤはこのコマンドがＧＣ制御コマンドであることを示すＩＤ（コマンドコード）であり、ＧＣ制御コマンドにはＧＣ制御コマンド用のコマンドＩＤが含まれる。

ポリシーは、ＧＣ候補ブロック（ＧＣソースブロック）を選択するための条件（ＧＣポリシー）を指定するパラメータである。フラッシュストレージデバイス３のコントローラ４は、複数のＧＣポリシーをサポートしている。

コントローラ４によってサポートされているＧＣポリシーには、有効データ量が少ないブロックを優先的にＧＣ候補ブロック（ＧＣソースブロック）として選択するというポリシー（Ｇｒｅｅｄｙ）が含まれてもよい。

また、コントローラ４によってサポートされているＧＣポリシーには、低い更新頻度を有するデータ（コールドデータ）が集められているブロックを、高い更新頻度を有するデータ（ホットデータ）が集められているブロックよりも優先的にＧＣ候補ブロック（ＧＣソースブロック）として選択するというポリシーが含まれていてもよい。

さらに、ＧＣポリシーは、ＧＣ開始条件を指定してもよい。ＧＣ開始条件は、例えば、残りフリーブロックの個数を示してもよい。

コントローラ４は、有効データを含むブロック群をアクティブブロックリストによって管理しており、ＧＣを実行する場合には、ＧＣ制御コマンドによって指定されたＧＣポリシーに基づいて、アクティブブロックリストによって管理されているブロック群から一つ以上のＧＣ候補ブロック（ＧＣソースブロック）を選択する。

ソースＱｏＳドメインＩＤは、どのＱｏＳドメインをＧＣソースとすべきかを指定するパラメータである。コントローラ４は、ソースＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するブロック群、つまりこのＱｏＳドメインに対応するアクティブブロックリストから、一つ以上のＧＣ候補ブロック（ＧＣソースブロック）を選択する。

デスティネーションＱｏＳドメインＩＤは、どのＱｏＳドメインをＧＣデスティネーションとすべきかを指定するパラメータである。コントローラ４は、デスティネーションＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するフリーブロック群内の一つ以上のフリーブロックをＧＣデスティネーションブロックとして選択することができる。

ソースＱｏＳドメインＩＤおよびデスティネーションＱｏＳドメインＩＤは、同じＱｏＳドメインを指定してもよいし、互いに異なるＱｏＳドメインを指定してもよい。つまり、ソースＱｏＳドメインＩＤおよびデスティネーションＱｏＳドメインＩＤの各々は、複数のＱｏＳドメインの任意の一つを指定するパラメータである。

コントローラ４は、ソースＱｏＳドメインに対応する残りフリーブロックの数がポリシーによって指定される閾値以下になった場合に、ＧＣを開始してもよい。もしＧＣの強制実行を指定するポリシーを含むＧＣ制御コマンドを受信したならば、コントローラ４は、ホスト２からこのＧＣ制御コマンドを受信した時にＧＣを即座に開始してもよい。

図２８は、物理アドレスＡＰＩ（タイプ＃１）で使用されるＧＣ用コールバックコマンドを示す。

ＧＣ用コールバックコマンドは、ＧＣによってコピーされた有効データの論理アドレスとこの有効データのコピー先位置を示すブロック番号およびオフセットとをホスト２に通知するために使用される。

ＧＣ用コールバックコマンドは、コマンドＩＤ、論理アドレス、長さ、デスティネーション物理アドレス、ソース物理アドレス（オプショナル）を含んでよい。

コマンドＩＤはこのコマンドがＧＣ用コールバックコマンドであることを示すＩＤ（コマンドコード）であり、ＧＣ用コールバックコマンドにはＧＣ用コールバックコマンド用のコマンドＩＤが含まれる。

論理アドレスは、ＧＣによってＧＣソースブロックからＧＣデスティネーションブロックにコピーされた有効データの論理アドレスを示す。

長さは、このコピーされたデータの長さを示す。このデータ長は、粒度（Ｇｒａｉｎ）の数によって指定されてもよい。

デスティネーション物理アドレスは、有効データがコピーされたＧＣデスティネーションブロック内の位置を示す。デスティネーション物理アドレスは、ブロック番号、オフセット（ブロック内オフセット）によって指定される。

ソース物理アドレス（オプショナル）は、有効データが格納されていたＧＣソースブロック内の位置を示す。ソース物理アドレスは、ブロック番号、オフセット（ブロック内オフセット）によって指定される。

図２９のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃１）に対応するガベージコレクション（ＧＣ）動作の手順を示す。

フラッシュストレージデバイス３のコントローラ４は、ホスト２によって指定されたポリシーに基づいて、ソースＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するブロック群から、有効データと無効データとが混在する一つ以上のＧＣソースブロック（コピー元ブロック）を選択する（ステップＳ４１）。次いで、コントローラ４は、デスティネーションＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するフリーブロック群から一つ以上のフリーブロックを選択し、選択したフリーブロックをＧＣデスティネーションブロック（コピー先ブロック）として割り当てる（ステップＳ４２）。

コントローラ４は、ＧＣソースブロック（コピー元ブロック）内の全ての有効データをＧＣデスティネーションブロック（コピー先ブロック）にコピーする（ステップＳ４３）。ステップＳ４３では、コントローラ４は、ＧＣソースブロック（コピー元ブロック）内の有効データのみならず、この有効データとこの有効データに対応する論理アドレスの双方を、ＧＣソースブロック（コピー元ブロック）からＧＣデスティネーションブロック（コピー先ブロック）にコピーする。これにより、ＧＣデスティネーションブロック（コピー先ブロック）内にデータと論理アドレスとのペアを保持することができる。

そして、コントローラ４は、コピーされた有効データの論理アドレスと、この有効データがコピーされたＧＣデスティネーションブロック（コピー先ブロック）内の位置を示すデスティネーション物理アドレス（ブロック番号、オフセット（ブロック内オフセット））を、ＧＣ用コールバックコマンドを使用してホスト２に通知する（ステップＳ４４）。なお、ステップＳ４４では、コントローラ４は、コピーされた有効データの論理アドレスとデスティネーション物理アドレスとみならず、ソース物理アドレスもホスト２に通知してもよい。

ホスト２がこのＧＣ用コールバックコマンドを受信した時、ホスト２は、ホスト２によって管理されているＬＵＴを更新して、コピーされた有効データに対応する論理アドレスそれぞれにデスティネーション物理アドレスをマッピングする（ステップＳ５１）。

図３０は、ガベージコレクション（ＧＣ）のために実行されるデータコピー動作の例を示す。

図３０では、ＧＣソースブロック（ここではブロックＢＬＫ＃５０）のオフセット＋４に対応する位置に格納されている有効データ（ＬＢＡ＝１０）が、ＧＣデスティネーションブロック（ここではブロックＢＬＫ＃１００）のオフセット＋０に対応する位置にコピーされ、ＧＣソースブロック（ここではブロックＢＬＫ＃５０）のオフセット＋１０に対応する位置に格納されている有効データ（ＬＢＡ＝２０）が、ＧＣデスティネーションブロック（ここではブロックＢＬＫ＃１００）のオフセット＋１に対応する位置にコピーされた場合が想定されている。この場合、コントローラ４は、｛ＬＢＡ１０、ＢＬＫ＃１００、オフセット（＝＋０）、ＬＢＡ２０、ＢＬＫ＃１００、オフセット（＝＋１）｝をホストに通知する（ＧＣ用コールバック処理）。

図３１は、図３０のデータコピー動作の結果に基づいて更新されるホスト２のＬＵＴの内容を示す。

このＬＵＴにおいては、ＬＢＡ１０に対応するブロック番号およびオフセットは、ＢＬＫ＃５０、オフセット（＝＋４）から、ＢＬＫ＃１００、オフセット（＝＋０）に更新される。同様に、ＬＢＡ２０に対応するブロック番号およびオフセットは、ＢＬＫ＃５０、オフセット（＝＋１０）から、ＢＬＫ＃１００、オフセット（＝＋１）に更新される。

ＬＵＴが更新された後、ホスト２は、ＢＬＫ＃５０およびオフセット（＝＋４）を指定するＴｒｉｍコマンドをフラッシュストレージデバイス３に送信して、ＢＬＫ＃５０のオフセット（＝＋４）に対応する位置に格納されているデータを無効化してもよい。さらに、ホスト２は、ＢＬＫ＃５０およびオフセット（＝＋１０）を指定するＴｒｉｍコマンドをフラッシュストレージデバイス３に送信して、ＢＬＫ＃５０のオフセット（＝＋１０）に対応する位置に格納されているデータを無効化してもよい。

図３２は、ライトコマンドに対するレスポンスとＧＣ用コールバック処理との関係を示す。

コントローラ４がある論理アドレスに対応する有効データをコピーしている間に、この論理アドレスを指定するライトコマンドがホスト２から受信されるというケースが起こる場合がある。

図３２では、図３０のデータコピー動作（ＬＢＡ１０に対応するデータコピー動作）の実行中に、ＬＢＡ１０を指定するライトコマンドがホスト２から受信された場合が想定されている。

コントローラ４は、ホスト２から受信されるライトデータを書き込み先ブロックに書き込む（ここではＢＬＫ＃３のオフセット＋０に対応する位置に書き込まれる）。そして、コントローラ４は、｛ＬＢＡ１０、ＢＬＫ＃３、オフセット（＝＋０）｝をホスト２に通知する。

ホスト２は、ＬＵＴを更新して、ＬＢＡ１０に対応するブロック番号およびオフセットを、ＢＬＫ＃５０、オフセット（＋４）から、ＢＬＫ＃３、オフセット（＋０）に変更する。

もしこの後に、ＬＢＡ１０のデスティネーション物理アドレスがコントローラ４からホスト２に通知されたならば、ＬＢＡ１０に対応する最新データが格納されている位置を示すブロック番号およびオフセット（ＢＬＫ＃３、オフセット（＋０））が、ＬＢＡ１０に対応するデスティネーション物理アドレス（ここでは、ＢＬＫ＃１００、オフセット（＝＋０））に誤って変更されてしまう可能性がある。

物理アドレスＡＰＩ（タイプ＃１）をサポートするフラッシュストレージデバイス３では、コントローラ４は、ＬＢＡ１０とデスティネーション物理アドレス（ＢＬＫ＃１００、オフセット（＝＋０））のみならず、ソース物理アドレス（ＢＬＫ＃５０、オフセット（＝＋４））もホスト２に通知することができる。ホスト２は、ソース物理アドレス（ＢＬＫ＃５０、オフセット（＝＋４））が、ＬＵＴによってＬＢＡ１０に現在マッピングされているブロック番号、オフセットに一致しない場合には、ＬＵＴを更新しない。これにより、ＬＢＡ１０に対応する最新データが格納されている位置を示すブロック番号およびオフセット（ＢＬＫ＃３、オフセット（＋０））が、ＬＢＡ１０に対応するデスティネーション物理アドレス（ここでは、ＢＬＫ＃１００、オフセット（＝＋０））に誤って変更されてしまうことを防止することができる。

図３３は、物理アドレスＡＰＩ（タイプ＃１）で使用されるガベージコレクション（ＧＣ）制御コマンドの別の例を示す。

この図３３のＧＣ制御コマンドは、ソースＱｏＳドメインＩＤの代わりに、ソースデバイスＩＤとソースＱｏＳドメインＩＤのペアを指定してもよい。さらに、この図３３のＧＣ制御コマンドは、デスティネーションＱｏＳドメインＩＤの代わりに、デスティネーションデバイスＩＤとデスティネーションＱｏＳドメインＩＤのペアを指定してもよい。これにより、あるフラッシュストレージデバイス３をＧＣソースとして動作させ、別のフラッシュストレージデバイス３をＧＣデスティネーションとして動作させることが可能となる。ソースデバイスＩＤとデスティネーションデバイスＩＤが同じである場合には、一つのフラッシュストレージデバイス３内でＧＣが実行される。

図３４は、物理アドレスＡＰＩ（タイプ＃１）で使用されるＧＣ用コールバックコマンドの別の例を示す。

図３４のＧＣ用コールバックコマンドは、デスティネーション物理アドレスの代わりに、デスティネーションデバイスＩＤとデスティネーション物理アドレスのペアを含む。また、図３４のＧＣ用コールバックコマンドは、ソース物理アドレス（オプショナル）の代わりに、ソースデバイスＩＤとソース物理アドレスのペア（オプショナル）を含んでもよい。

いま、デバイスＩＤが１のフラッシュストレージデバイス３をＧＣソースとして動作させ、デバイスＩＤが２のフラッシュストレージデバイス３をＧＣデスティネーションとして動作させる場合を想定する。ホスト２は、ソースデバイスＩＤ＃１およびデスティネーションデバイスＩＤ＃２を指定するＧＣ制御コマンドを、デバイスＩＤ＃１のフラッシュストレージデバイス３と、デバイスＩＤ＃２のフラッシュストレージデバイス３に送信してもよい。

デバイスＩＤ＃１のフラッシュストレージデバイス３は、ソースＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するブロック群からＧＣソースブロックを選択し、ＧＣソースブロック内の有効データとこの有効データの論理アドレスとを、デスティネーションデバイスＩＤによって指定されるフラッシュストレージデバイス（デバイスＩＤ＃２のフラッシュストレージデバイス）宛てに送信する。ＧＣソースブロック内の有効データとこの有効データの論理アドレスは、例えば、図１のインタフェース５０を介して、デバイスＩＤ＃１のフラッシュストレージデバイス３からデバイスＩＤ＃２のフラッシュストレージデバイス３に転送される。

デバイスＩＤ＃２のフラッシュストレージデバイス３は、デスティネーションＱｏＳドメインＩＤによって指定されるＱｏＳドメインに属するフリーブロック群からＧＣデスティネーションブロックを選択し、スイッチ１を介して受信される有効データおよび論理ドレスをＧＣデスティネーションブロックに書き込む（コピーする）。

デバイスＩＤ＃２のフラッシュストレージデバイス３は、コピーされた有効データの論理アドレスと、この有効データがコピーされたデスティネーション物理アドレス（ブロック番号、オフセット）を、ＧＣ用コールバックコマンドによってホスト２に通知する。

デバイスＩＤ＃１のフラッシュストレージデバイス３は、コピーされた有効データの論理アドレスと、この有効データが格納されているソース物理アドレス（ブロック番号、オフセット）を、ＧＣ用コールバックコマンドによってホスト２に通知する。

図３５は、物理アドレスＡＰＩ（タイプ＃１）に対応する書き込み／リード／ＧＣ動作を示す。

まず、ホスト２からのデータを書き込むホストライト動作について説明する。

（１）コントローラ４は、ホスト２からＬＢＡとライトデータを受信する。

（２）コントローラ４は、ＬＢＡとライトデータの双方を書き込み先ブロックに書き込む。書き込み先ブロックが割り当てられていない場合には、コントローラ４は、フリーブロックリストから一つのフリーブロックを選択し、この選択したフリーブロックを新たな書き込み先ブロックとして割り当てる。そして、コントローラ４は、ＬＢＡとライトデータの双方をこの新たな書き込み先ブロックに書き込む。

（３）コントローラ４は、このＬＢＡと、このライトデータが書き込まれた書き込み先ブロック内の位置を示す物理アドレスＰＢＡをホスト２に通知する。この物理アドレスＰＢＡは、ブロック番号およびオフセットによって表される。書き込み先ブロック全体がデータで満たされると、コントローラ４は、この書き込み先ブロックをアクティブブロックリストに登録する。

次に、リード動作について説明する。

（４）ホスト２は、ホスト２によって管理されているＬＵＴを参照して、ユーザアプリケーションからのリード要求に含まれるＬＢＡをリード用物理アドレスＰＢＡ（ブロック番号、オフセット）に変換する。

（５）ホスト２から受信されるリード用物理アドレスＰＢＡ（ブロック番号、オフセット）に基づいて、コントローラ４は、このブロック番号を有するブロックをリード対象のブロックとして決定する。リード対象のブロックは、アクティブブロックリストによって管理されているブロック群（アクティブブロック）のいずれか一つ、または現在のＧＣソースブロック、または現在の書き込み先ブロックである。そして、コントローラ４は、オフセットに基づいて、リード対象のブロックからデータをリードする。

次に、ＧＣ動作について説明する。

（６）コントローラ４は、ＧＣソースブロック（コピー元ブロック）およびＧＣデスティネーションブロック（コピー先ブロック）を選択し、ＧＣソースブロック内に格納されている有効データとこの有効データのＬＢＡの双方をＧＣデスティネーションブロックにコピーする。

（７）コントローラ４は、コピーされた有効データのＬＢＡと、この有効データがコピーされたＧＣデスティネーションブロック内の位置を示すＰＢＡ（ブロック番号、オフセット）の双方を、ホスト２に通知する。

あるいは、コントローラ４は、コピーされた有効データのＬＢＡと、この有効データがコピーされたＧＣデスティネーションブロック内の位置を示すＰＢＡ（ブロック番号、オフセット）と、この有効データが格納されているＧＣソースブロック内の位置を示すＰＢＡ（ブロック番号、オフセット）とを、ホスト２に通知してもよい。

＜物理アドレスＡＰＩ（タイプ＃２）の詳細＞
次に、図３６〜図５０を参照して、物理アドレスＡＰＩ（タイプ＃２）について説明する。

図３６は、従来型ＳＳＤとホストとの間の役割分担と、物理アドレスＡＰＩ（タイプ＃２）をサポートするフラッシュストレージデバイス３とホスト２との間の役割分担を示す。

図３６の右部は、物理アドレスＡＰＩ（タイプ＃２）をサポートするフラッシュストレージデバイス３とホスト２とを含む計算機システム全体の階層構造を表している。

ホスト（サーバ）２においては、複数のエンドユーザに複数の仮想マシンを提供するための仮想マシンサービス４０１が実行される。仮想マシンサービス４０１上の各仮想マシンにおいては、対応するエンドユーザによって使用されるオペレーティングシステムおよびユーザアプリケーション４０２が実行される。

また、ホスト（サーバ）２においては、複数のユーザアプリケーション４０２に対応する複数のＩ／Ｏサービス４０３が実行される。これらＩ／Ｏサービス４０３には、ＬＢＡベースのブロックＩ／Ｏサービス、キー・バリュー・ストアサービスなどが含まれてもよい。各Ｉ／Ｏサービス４０３は、論理アドレスそれぞれとフラッシュストレージデバイス３のブロック番号それぞれとの間のマッピングを管理するブロックレベルＬＵＴを含む。ここで、論理アドレスとは、アクセス対象のデータを識別可能な識別子を意味する。この論理アドレスは、論理アドレス空間上の位置を指定する論理ブロックアドレス（ＬＢＡ）であってもよいし、あるいは、キー・バリュー・ストアのキー（タグ）であってもよいし、キーのハッシュ値であってもよい。

ＬＢＡベースのブロックＩ／Ｏサービスにおいては、論理アドレス（ＬＢＡ）それぞれとフラッシュストレージデバイス３のブロック番号それぞれとの間のマッピングを管理するブロックレベルＬＵＴが使用されてもよい。

キー・バリュー・ストアサービスにおいては、論理アドレス（つまり、キーのようなタグ）それぞれとこれら論理アドレス（つまり、キーのようなタグ）に対応するデータが格納されているフラッシュストレージデバイス３のブロック番号それぞれとの間のマッピングを管理するブロックレベルＬＵＴが使用されてもよい。このブロックレベルＬＵＴにおいては、タグと、このタグによって識別されるデータが格納されているブロック番号と、このデータのデータ長との対応関係が管理されてもよい。

各エンドユーザは、使用すべきアドレッシング方法（ＬＢＡ、キー・バリュー・ストアのキー、等）を選択することができる。

これら各ブロックレベルＬＵＴは、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３用の論理アドレスそれぞれに変換するのではなく、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３のブロック番号それぞれに変換する。つまり、これら各ブロックレベルＬＵＴは、フラッシュストレージデバイス３用の論理アドレスをブロック番号に変換するテーブルとアプリケーションレベルアドレス変換テーブルとが統合（マージ）されたテーブルである。

また、各Ｉ／Ｏサービス４０３は、ＧＣブロック選択機能を含む。ＧＣブロック選択機能は、対応するブロックレベルＬＵＴを使用して各ブロックの有効データ量を管理することができ、これによってＧＣソースブロックを選択することができる。

ホスト（サーバ）２においては、上述のＱｏＳドメイン毎にＩ／Ｏサービス４０３が存在してもよい。あるＱｏＳドメインに属するＩ／Ｏサービス４０３は、対応するＱｏＳドメイン内のユーザアプリケーション４０２によって使用される論理アドレスそれぞれと対応するＱｏＳドメインに割り当てられたリソースグループに属するブロック群のブロック番号それぞれとの間のマッピングを管理する。

ホスト（サーバ）２からフラッシュストレージデバイス３へのコマンドの送信およびフラッシュストレージデバイス３からホスト（サーバ）２へのコマンド完了のレスポンス等の返送は、ホスト（サーバ）２およびフラッシュストレージデバイス３の各々に存在するＩ／Ｏキュー５００を介して実行される。これらＩ／Ｏキュー５００も、複数のＱｏＳドメインに対応する複数のキューグループに分類されていてもよい。

フラッシュストレージデバイス３は、複数のＱｏＳドメインに対応する複数のライトバッファ（ＷＢ）６０１、複数のＱｏＳドメインに対応する複数のブロック内ＬＵＴ６０２Ａ、複数のＱｏＳドメインに対応する複数のガベージコレクション（ＧＣ）機能６０３Ａ、ＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）６０３を含む。

この図３６の右部に示す構成においては、上位階層（ホスト２）はブロック境界を認識することができるので、ブロック境界／ブロックサイズを考慮してユーザデータを各ブロックに書き込むことができる。つまり、ホスト２はＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）６０３の個々のブロックを認識することができ、これにより、例えば、一つのブロック全体に一斉にデータを書き込む、一つのブロック内のデータ全体を削除または更新によって無効化する、といった制御を行うことが可能となる。この結果、一つのブロックに有効データと無効データが混在されるという状況を起こりにくくすることが可能となる。したがって、ＧＣを実行することが必要となる頻度を低減することができる。ＧＣの頻度を低減することにより、ライトアンプリフィケーションが低下され、フラッシュストレージデバイス３の性能の向上、フラッシュストレージデバイス３の寿命の最大化を実現できる。このように、上位階層（ホスト２）がブロック番号を認識可能な構成は有用である。

一方、ページ書き込み順序制約により、現在書き込み可能なページはブロックあたり１ページのみである。このため、ページ番号を上位階層に見せることは、ブロック番号を上位階層に見せることに比較して有用ではない。

図３７は、ホスト２によって管理されるブロックレベルＬＵＴ（ブロックレベルアドレス変換テーブル）と物理アドレスＡＰＩ（タイプ＃２）をサポートするフラッシュストレージデバイス３によって管理されるブロック内ＬＵＴ（ブロック内アドレス変換テーブル）を示す。

ブロックレベルＬＵＴは、論理アドレスそれぞれとフラッシュストレージデバイス３の複数のブロックそれぞれに対応するブロック番号それぞれとの間のマッピングを管理する。このブロックレベルＬＵＴは、ある論理アドレスをあるブロック番号ＢＬＫ＃に変換するテーブルである。

フラッシュストレージデバイス３においては、複数のブロックそれぞれに対応する複数のブロック内ＬＵＴが管理される。各ブロック内ＬＵＴは、論理アドレスそれぞれと対応するブロック内のブロック内物理アドレス（フロック内オフセット）それぞれの間のマッピングを管理する。各ブロック内ＬＵＴは、ある論理アドレスをあるブロック内物理アドレス（ブロック内ＰＢＡ）に変換するテーブルである。ブロック内物理アドレス（ブロック内ＰＢＡ）は、上述したようにブロック内オフセットによって表される。

アドレス変換は以下のように実行される。

例えば、リード動作においては、ホスト２は、ある論理アドレス（例えば、あるＬＢＡ）を使用してブロックレベルＬＵＴを参照して、この論理アドレス（ＬＢＡ）をブロック番号ＢＬＫ＃に変換する。この論理アドレスおよびブロック番号ＢＬＫ＃がホスト２からフラッシュストレージデバイス３に送信される。物理アドレスＡＰＩ（タイプ＃２）をサポートするフラッシュストレージデバイス３においては、各ブロックに特定の論理アドレス範囲を割り当てるのではなく、どのブロックに対しても任意の論理アドレスに対応するデータを格納できるようにするために、この論理アドレスそのものがブロック番号ＢＬＫ＃と一緒にホスト２からフラッシュストレージデバイス３に送信される。

フラッシュストレージデバイス３においては、コントローラ４は、ブロック番号ＢＬＫ＃に対応するブロック内ＬＵＴを選択する。例えば、ホスト２からのブロック番号ＢＬＫ＃がブロック番号ＢＬＫ＃０を示すならば、ブロック番号ＢＬＫ＃０に対応するブロック内ＬＵＴが選択され、ホスト２からのブロック番号ＢＬＫ＃がブロック番号ＢＬＫ＃１を示すならば、ブロック番号ＢＬＫ＃１に対応するブロック内ＬＵＴが選択され、ホスト２からのブロック番号ＢＬＫ＃がブロック番号ＢＬＫ＃２を示すならば、ブロック番号ＢＬＫ＃２に対応するブロック内ＬＵＴが選択される。

選択されたブロック内ＬＵＴは、ホスト２からの論理アドレスによって参照される。そして、この論理アドレスに対応するブロック内ＰＢＡが選択されたブロック内ＬＵＴから取得される。

図３８は、物理アドレスＡＰＩ（タイプ＃２）で使用されるライトコマンドを示す。

ライトコマンドは、フラッシュストレージデバイス３にデータの書き込みを要求するコマンドである。このライトコマンドは、コマンドＩＤ、ブロック番号ＢＬＫ＃、論理アドレス、長さ、等を含んでもよい。

コマンドＩＤはこのコマンドがライトコマンドであることを示すＩＤ（コマンドコード）であり、ライトコマンドにはライトコマンド用のコマンドＩＤが含まれる。

ブロック番号ＢＬＫ＃は、データが書き込まれるべきブロックを一意に識別可能な識別子（ブロックアドレス）である。

論理アドレスは、書き込まれるべきライトデータを識別するための識別子である。この論理アドレスは、上述したように、ＬＢＡであってもよいし、キー・バリュー・ストアのキーであってもよいし、キーのハッシュ値であってもよい。論理アドレスがＬＢＡである場合には、このライトコマンドに含まれる論理アドレス（開始ＬＢＡ）は、ライトデータが書き込まれるべき論理位置（最初の論理位置）を示す。

長さは、書き込まれるべきライトデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、ＬＢＡの数によって指定されてもよいし、あるいはそのサイズがバイトによって指定されてもよい。

ホスト２からライトコマンドを受信した時、コントローラ４は、ライトコマンドによって指定されたブロック番号を有するブロック内の書き込み先位置を決定する。この書き込み先位置は、ページ書き込み順序の制約およびバッドページ等を考慮して決定される。そして、コントローラ４は、ホスト２からのデータを、ライトコマンドによって指定されたブロック番号を有するこのブロック内のこの書き込み先位置に書き込む。

図３９は、物理アドレスＡＰＩ（タイプ＃２）で使用されるＴｒｉｍコマンドを示す。

このＴｒｉｍコマンドは、無効にすべきデータが格納されているブロックのブロック番号およびこのデータの論理アドレスを含むコマンドである。このＴｒｉｍコマンドは、コマンドＩＤ、ブロック番号ＢＬＫ＃、論理アドレス、長さを含む。

コマンドＩＤはこのコマンドがＴｒｉｍコマンドであることを示すＩＤ（コマンドコード）であり、ＴｒｉｍコマンドにはＴｒｉｍコマンド用のコマンドＩＤが含まれる。

ブロック番号は、無効化すべきデータが格納されているブロックを示す。

論理アドレスは、無効化すべきデータの最初の論理位置を示す。

長さは、無効化すべきデータの長さを示す。この長さ（データ長）は、論理アドレスの数によって指定されてもよいし、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、バイトによって指定されてもよい。

コントローラ４は、複数のブロックの各々に含まれるデータそれぞれの有効／無効を示すフラグ（ビットマップフラグ）をブロック管理テーブル３２を使用して管理する。無効にすべきデータが格納されているブロックを示すブロック番号および論理アドレスを含むＴｒｉｍコマンドをホスト２から受信した場合、コントローラ４は、ブロック管理テーブル３２を更新して、Ｔｒｉｍコマンドに含まれるブロック番号および論理アドレスによって特定されるブロック内物理アドレスに対応するフラグ（ビットマップフラグ）を無効を示す値に変更する。

図４０のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃２）に対応する書き込み処理のシーケンスを示す。

ホスト２は、まず、書き込みのために使用すべきブロック（フリーブロック）を自身で選択するか、またはブロックアロケートコマンドをフラッシュストレージデバイス３に送信することによってフリーブロックを割り当てるようにフラッシュストレージデバイス３に要求する。そして、ホスト２は、自身で選択したブロックのブロック番号ＢＬＫ＃（またはフラッシュストレージデバイス３によって割り当てられたフリーブロックのブロック番号ＢＬＫ＃）と、論理アドレス（ＬＢＡ）と、長さとを含むライトコマンドをフラッシュストレージデバイス３に送信する（ステップＳ２０Ａ）。

フラッシュストレージデバイス３のコントローラ４がこのライトコマンドを受信した時、コントローラ４は、ホスト２からのライトデータを書き込むべき、このブロック番号ＢＬＫ＃を有するブロック（書き込み先ブロックＢＬＫ＃）内の書き込み先位置を決定し、この書き込み先ブロックＢＬＫ＃の書き込み先位置にライトデータを書き込む（ステップＳ１１Ａ）。ステップＳ１１Ａでは、コントローラ４は、論理アドレス（ここではＬＢＡ）とライトデータの双方を書き込み先ブロックに書き込んでもよい。

コントローラ４は、書き込み先ブロックＢＬＫ＃に対応するブロック内ＬＵＴを更新して、書き込み先位置を示すオフセット（ブロック内オフセット）をこの論理アドレスにマッピングする（ステップＳ１２Ａ）。

次いで、コントローラ４は、書き込み先ブロックＢＬＫ＃に対応するブロック管理テーブル３２を更新して、書き込まれたデータに対応するビットマップフラグ（つまり、このデータが書き込まれたオフセット（ブロック内オフセット）に対応するビットマップフラグ）を０から１に変更する（ステップＳ１３Ａ）。

例えば、図４１に示されているように、開始ＬＢＡがＬＢＡｘである１６Ｋバイト更新データがブロックＢＬＫ＃１のオフセット＋４〜＋７に対応する物理記憶位置に書き込まれた場合を想定する。この場合、図４２に示されているように、ブロックＢＬＫ＃１用のブロック内ＬＵＴにおいては、オフセット＋４〜＋７がＬＢＡｘ〜ＬＢＡｘ＋３にマッピングされる。また、図４３に示されているように、ブロックＢＬＫ＃１用のブロック管理テーブルにおいては、オフセット＋４〜＋７に対応するビットマップフラグそれぞれが０から１に変更される。

コントローラ４は、このライトコマンドに対するレスポンス（成功／失敗）をホスト２に返す（ステップＳ１４Ａ）。

ホスト２がこのレスポンスを受信した時、ホスト２は、ホスト２によって管理されているブロックレベルＬＵＴを更新して、書き込み先ブロックＢＬＫ＃のブロック番号ＢＬＫ＃を、書き込まれたライトデータに対応する論理アドレスにマッピングする（ステップＳ２１Ａ）。図４４に示されているように、ブロックレベルＬＵＴは、複数の論理アドレス（例えばＬＢＡ）それぞれに対応する複数のエントリを含む。ある論理アドレス（例えばあるＬＢＡ）に対応するエントリには、このＬＢＡに対応するデータが格納されているＮＡＮＤ型フラッシュメモリ５のブロック番号が格納される。図４１に示されているように、開始ＬＢＡがＬＢＡｘである１６Ｋバイト更新データがブロックＢＬＫ＃１に書き込まれたならば、図４４に示されているように、ブロックレベルＬＵＴが更新されて、ＬＢＡｘ〜ＬＢＡｘ＋３に対応するブロック番号がＢＬＫ＃０からＢＬＫ＃１に変更される。

この後、図４０に示すように、ホスト２は、上述の更新データの書き込みによって不要になった以前のデータを無効化するためのＴｒｉｍコマンドをフラッシュストレージデバイス３に送信する。フラッシュストレージデバイス３のコントローラ４は、このＴｒｉｍコマンドに応じて、ブロック内ＬＵＴ、ブロック管理テーブルを更新する（ステップＳ１５Ａ、Ｓ１６Ａ）。

もし図４１に示されているように、以前のデータがブロックＢＬＫ＃０に格納されている場合には、図４５に示すように、ブロック番号（＝ＢＬＫ＃０）、ＬＢＡｘ、長さ（＝４）を指定するＴｒｉｍコマンドがホスト２からフラッシュストレージデバイス３に送信される。フラッシュストレージデバイス３のコントローラ４は、このＴｒｉｍコマンドに応じて、ＢＬＫ＃０に対応するブロック内ＬＵＴを更新して、ＬＢＡｘ〜ＬＢＡｘ＋３それぞれとオフセット＋１〜＋３それぞれとの間のマッピングを示す情報を削除する。この場合、コントローラ４は、これらＬＢＡｘ〜ＬＢＡｘ＋３とオフセット＋１〜＋３を無効を示す値（ｎｕｌｌ）に変更してもよい。さらに、コントローラ４は、ＢＬＫ＃０に対応するブロック管理テーブル３２を更新して、オフセット＋０〜＋３に対応するビットマップフラグそれぞれを１から０に変更する。

図４６は、物理アドレスＡＰＩ（タイプ＃２）で使用されるリードコマンドを示す。

リードコマンドは、フラッシュストレージデバイス３にデータの読み出しを要求するコマンドである。このリードコマンドは、コマンドＩＤ、ブロック番号ＢＬＫ＃、論理アドレス、長さ、転送先ポインタを含む。

コマンドＩＤはこのコマンドがリードコマンドであることを示すＩＤ（コマンドコード）であり、リードコマンドにはリードコマンド用のコマンドＩＤが含まれる。

ブロック番号ＢＬＫ＃は、リードされるべきデータが格納されているブロックのブロック番号を示す。論理アドレスは、リードされるべきデータの論理アドレスである。

長さは、リードすべきデータの長さを示す。このデータ長は、ＬＢＡの数によって示されてもよいし、Ｇｒａｉｎの数によって示されてもよい。

転送先ポインタは、読み出されたデータが転送されるべきホスト２内のメモリ上の位置を示す。

図４７のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃２）に対応するリード動作を示す。

ホスト２は、ホスト２によって管理されているブロック内ＬＵＴを参照して、ユーザアプリケーションからのリード要求に含まれる論理アドレス（ＬＢＡ）をブロック番号に変換する。そして、ホスト２は、このブロック番号、ＬＢＡ、長さを指定するリードコマンドをフラッシュストレージデバイス３に送信する。

フラッシュストレージデバイス３のコントローラ４がリードコマンドをホスト２から受信した時、コントローラ４は、このリードコマンドによって指定されたブロック番号に対応するブロック内ＬＵＴを選択し、この選択したブロック内ＬＵＴをリードコマンド内のＬＢＡを使用して参照して、このＬＢＡに対応するオフセット（ブロック内オフセット）を取得する（ステップＳ３１Ａ）。コントローラ４は、リードコマンドによって指定されたブロック番号と、取得したオフセット（ブロック内オフセット）とに基づいて、このＬＢＡに対応するデータをＮＡＮＤ型フラッシュメモリ５からリードし（ステップＳ３２Ａ）、このリードデータをホスト２に送信する。

図４８は、物理アドレスＡＰＩ（タイプ＃２）で使用されるガベージコレクション（ＧＣ）制御コマンドを示す。

ＧＣ制御コマンドは、ＧＣソースブロック番号およびＧＣデスティネーションブロック番号をフラッシュストレージデバイス３に通知するために使用される。ホスト２は、各ブロックの有効データ量／無効データ量を管理しており、有効データ量がより少ない幾つかのブロックをＧＣソースブロックとして選択することができる。また、ホスト２は、フリーブロックリストを管理しており、幾つかのフリーブロックをＧＣデスティネーションブロックとして選択することができる。このＧＣ制御コマンドは、コマンドＩＤ、ＧＣソースブロック番号、ＧＣデスティネーションブロック番号、等を含んでもよい。

コマンドＩＤはこのコマンドがＧＣ制御コマンドであることを示すＩＤ（コマンドコード）であり、ＧＣ制御コマンドにはＧＣ制御コマンド用のコマンドＩＤが含まれる。

ＧＣソースブロック番号は、ＧＣソースブロックを示すブロック番号である。ホスト２は、どのブロックをＧＣソースブロックとすべきかを指定することができる。ホスト２は、複数のＧＣソースブロック番号を一つのＧＣ制御コマンドに設定してもよい。

ＧＣデスティネーションブロック番号は、ＧＣデスティネーションブロックを示すブロック番号である。ホスト２は、どのブロックをＧＣデスティネーションブロックとすべきかを指定することができる。ホスト２は、複数のＧＣデスティネーションブロック番号を一つのＧＣ制御コマンドに設定してもよい。

図４９は、物理アドレスＡＰＩ（タイプ＃２）で使用されるＧＣ用コールバックコマンドを示す。

ＧＣ用コールバックコマンドは、論理アドレス（ＬＢＡ）とデスティネーションブロック番号との複数のペアを含むリストをホスト２に通知するために使用される。あるペアに含まれる論理アドレス（ＬＢＡ）は、コピーされた有効データの論理アドレスである。このペアに含まれるデスティネーションブロック番号は、この有効データがコピーされたＧＣデスティネーションブロックのブロック番号である。このＧＣ用コールバックコマンドは、ＧＣ制御コマンドによって複数のＧＣソースブロック番号および複数のデスティネーションブロック番号が指定された場合にのみ、フラッシュストレージデバイス３からホスト２に送信されてもよい。

図５０のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃２）に対応するガベージコレクション（ＧＣ）動作の手順を示す。

例えば、ホスト２は、ホスト２によって管理されているフリーブロックリストに含まれている残りフリーブロックの数が閾値以下に低下した場合、ＧＣソースブロックおよびＧＣデスティネーションブロックを選択し、ＧＣ制御コマンドをフラッシュストレージデバイス３に送信する（ステップＳ４１Ａ）。

このＧＣ制御コマンドを受信すると、フラッシュストレージデバイス３のコントローラ４は、ＧＣソースブロック内の有効データを書き込むべきＧＣデスティネーションブロック内の位置（コピー先位置）を決定する動作と、ＧＣソースブロック内の有効データをＧＣデスティネーションブロック内のコピー先位置にコピーする動作とを含むデータコピー動作を実行する（ステップＳ５１Ａ）。ステップＳ５１Ａでは、ＧＣソースブロック内の全ての有効データのコピーが完了するまでデータコピー動作が繰り返し実行される。複数のＧＣソースブロックがＧＣ制御コマンドによって指定された場合には、全てのＧＣソースブロック内の全ての有効データのコピーが完了するまでデータコピー動作が繰り返し実行される。

そして、コントローラ４は、論理アドレス（ＬＢＡ）とデスティネーションブロック番号との複数のペアを含むリストをＧＣ用コールバックコマンドを使用してホスト２に通知するとともに（ステップＳ５２Ａ）、コピーされた有効データの論理アドレスにマッピングされているオフセット（ブロック内オフセット）が、ＧＣソースブロック内のコピー元位置を示すオフセット（ブロック内オフセット）からＧＣデスティネーションブロック内のコピー先位置を示すオフセット（ブロック内オフセット）に変更されるように、ＧＣソースブロックに対応するブロック内ＬＵＴおよびＧＣデスティネーションブロックに対応するブロック内ＬＵＴを更新する（ステップＳ５３Ａ）。

ホスト２は、フラッシュストレージデバイス３から通知されるリストに基づいて、ブロック内ＬＵＴを更新する（ステップＳ４２Ａ）。

＜物理アドレスＡＰＩ（タイプ＃３）の詳細＞
次に、図５１〜図６０を参照して、物理アドレスＡＰＩ（タイプ＃３）について説明する。

図５１は、従来型ＳＳＤとホストとの間の役割分担と、物理アドレスＡＰＩ（タイプ＃３）をサポートするフラッシュストレージデバイス３とホスト２との間の役割分担とを示す。

図５１の右部は、物理アドレスＡＰＩ（タイプ＃３）をサポートするフラッシュストレージデバイス３とホスト２とを含む計算機システム全体の階層構造を表している。

ホスト（サーバ）２においては、複数のエンドユーザに複数の仮想マシンを提供するための仮想マシンサービス４０１が実行される。仮想マシンサービス４０１上の各仮想マシンにおいては、対応するエンドユーザによって使用されるオペレーティングシステムおよびユーザアプリケーション４０２が実行される。

また、ホスト（サーバ）２においては、複数のユーザアプリケーション４０２に対応する複数のＩ／Ｏサービス４０３が実行される。これらＩ／Ｏサービス４０３には、ＬＢＡベースのブロックＩ／Ｏサービス、キー・バリュー・ストアサービスなどが含まれてもよい。各Ｉ／Ｏサービス４０３は、論理アドレスそれぞれとフラッシュストレージデバイス３の物理アドレスそれぞれとの間のマッピングを管理するルックアップテーブル（ＬＵＴ）４１１を含む。ここで、論理アドレスとは、アクセス対象のデータを識別可能な識別子を意味する。この論理アドレスは、論理アドレス空間上の位置を指定する論理ブロックアドレス（ＬＢＡ）であってもよいし、あるいは、キー・バリュー・ストアのキー（タグ）であってもよいし、キーのハッシュ値であってもよい。

ＬＢＡベースのブロックＩ／Ｏサービスにおいては、論理アドレス（ＬＢＡ）それぞれとフラッシュストレージデバイス３の物理アドレスそれぞれとの間のマッピングを管理するＬＵＴ４１１が使用されてもよい。

キー・バリュー・ストアサービスにおいては、論理アドレス（つまり、キーのようなタグ）それぞれとこれら論理アドレス（つまり、キーのようなタグ）に対応するデータが格納されているフラッシュストレージデバイス３内の物理記憶位置を示す物理アドレスそれぞれとの間のマッピングを管理するＬＵＴ４１１が使用されてもよい。このＬＵＴ４１１においては、タグと、このタグによって識別されるデータが格納されている物理アドレスと、このデータのデータ長との対応関係が管理されてもよい。

各エンドユーザは、使用すべきアドレッシング方法（ＬＢＡ、キー・バリュー・ストアのキー、等）を選択することができる。

これら各ＬＵＴ４１１は、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３用の論理アドレスそれぞれに変換するのではなく、ユーザアプリケーション４０２からの論理アドレスそれぞれをフラッシュストレージデバイス３の物理アドレスそれぞれに変換する。つまり、これら各ＬＵＴ４１１は、フラッシュストレージデバイス３用の論理アドレスを物理アドレスに変換するテーブルとアプリケーションレベルアドレス変換テーブルとが統合（マージ）されたテーブルである。

また、各Ｉ／Ｏサービス４０３は、ＧＣブロック選択機能を含む。ＧＣブロック選択機能は、対応するＬＵＴを使用して各ブロックの有効データ量を管理することができ、これによってＧＣソースブロックを選択することができる。

ホスト（サーバ）２においては、上述のＱｏＳドメイン毎にＩ／Ｏサービス４０３が存在してもよい。あるＱｏＳドメインに属するＩ／Ｏサービス４０３は、対応するＱｏＳドメイン内のユーザアプリケーション４０２によって使用される論理アドレスそれぞれと対応するＱｏＳドメインに割り当てられたリソースグループに属するブロック群のブロック番号それぞれとの間のマッピングを管理してもよい。

ホスト（サーバ）２からフラッシュストレージデバイス３へのコマンドの送信およびフラッシュストレージデバイス３からホスト（サーバ）２へのコマンド完了のレスポンス等の返送は、ホスト（サーバ）２およびフラッシュストレージデバイス３の各々に存在するＩ／Ｏキュー５００を介して実行される。これらＩ／Ｏキュー５００も、複数のＱｏＳドメインに対応する複数のキューグループに分類されていてもよい。

フラッシュストレージデバイス３は、複数のＱｏＳドメインに対応する複数のライトバッファ（ＷＢ）６０１、複数のＱｏＳドメインに対応する複数のガベージコレクション（ＧＣ）機能６０３Ａ、ＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）６０３を含む。

この図５１の右部に示す構成においては、上位階層（ホスト２）はブロック境界を認識することができるので、ブロック境界／ブロックサイズを考慮してユーザデータを各ブロックに書き込むことができる。つまり、ホスト２はＮＡＮＤ型フラッシュメモリ（ＮＡＮＤフラッシュアレイ）６０３の個々のブロックを認識することができ、これにより、例えば、一つのブロック全体に一斉にデータを書き込む、一つのブロック内のデータ全体を削除または更新によって無効化する、といった制御を行うことが可能となる。この結果、一つのブロックに有効データと無効データが混在されるという状況を起こりにくくすることが可能となる。したがって、ＧＣを実行することが必要となる頻度を低減することができる。ＧＣの頻度を低減することにより、ライトアンプリフィケーションが低下され、フラッシュストレージデバイス３の性能の向上、フラッシュストレージデバイス３の寿命の最大化を実現できる。このように、上位階層（ホスト２）がブロック番号を認識可能な構成は有用である。

一方、データが書き込まれるべきブロック内の位置は、上位階層（ホスト２）ではなく、フラッシュストレージデバイス３によって決定される。したがって、不良ページ（バッドページ）を隠蔽することができ、またページ書き込み順序制約を守ることができる。

図５２は、物理アドレスＡＰＩ（タイプ＃３）に対応するデータ書き込み動作と、物理アドレスＡＰＩ（タイプ＃３）に対応するデータ読み出し動作とを示す。

データ書き込み動作は以下の手順で実行される。

（１）ホスト２のライト処理部４１２がフラッシュストレージデバイス３にデータ（ライトデータ）を書き込むことが必要な時、ライト処理部４１２は、フリーブロックを割り当てるようにフラッシュストレージデバイス３に要求してもよい。フラッシュストレージデバイス３のコントローラ４は、ＮＡＮＤ型フラッシュメモリ５のフリーブロック群を管理するブロック割り当て部７０１を含む。ブロック割り当て部７０１がライト処理部４１２からこの要求（ブロック割り当て要求）を受信した時、ブロック割り当て部７０１は、フリーブロック群の一つのフリーブロックをホスト２に割り当て、割り当てられたブロックのブロック番号（ＢＬＫ＃）をホスト２に通知する。

あるいは、ライト処理部４１２がフリーブロック群を管理する構成においては、ライト処理部４１２が自身で書き込み先ブロックを選択してもよい。

（２）ライト処理部４１２は、ライトデータに対応する論理アドレス（例えばＬＢＡ）と書き込み先ブロックのブロック番号（ＢＬＫ＃）とを指定するライト要求をフラッシュストレージデバイス３に送信する。

（３）フラッシュストレージデバイス３のコントローラ４は、データ書き込み用のページを割り当てるページ割り当て部７０２を含む。ページ割り当て部７０２がライト要求を受信した時、ページ割り当て部７０２は、ライト要求によって指定されたブロック番号を有するブロック（書き込み先ブロック）内の書き込み先位置を示すブロック内物理アドレス（ブロック内ＰＢＡ）を決定する。ブロック内物理アドレス（ブロック内ＰＢＡ）は、上述のブロック内オフセット（単にオフセットとしても参照される）によって表すことができる。コントローラ４は、ライト要求によって指定されたブロック番号と、ブロック内物理アドレス（ブロック内ＰＢＡ）とに基づいて、ホスト２からのライトデータを、書き込み先ブロック内の書き込み先位置に書き込む。

（４）コントローラ４は、書き込み先位置を示すブロック内物理アドレス（ブロック内ＰＢＡ）をライト要求に対するレスポンスとしてホスト２に通知する。あるいは、コントローラ４は、ライトデータに対応する論理アドレス（ＬＢＡ）と、書き込み先ブロックのブロック番号（ＢＬＫ＃）と、書き込み先位置を示すブロック内ＰＢＡ（オフセット）との組を、ライト要求に対するレスポンスとしてホスト２に通知してもよい。換言すれば、コントローラは、ブロック内物理アドレス、または論理アドレスとブロック番号とブロック内物理アドレスとの組のいずれかを、ホスト２に通知する。ホスト２においては、ライトデータが書き込まれた物理記憶位置を示す物理アドレス（ブロック番号、ブロック内物理アドレス（ブロック内オフセット））が、このライトデータの論理アドレスにマッピングされるように、ＬＵＴ４１１が更新される。

データリード動作は以下の手順で実行される。

（１）’ホスト２がフラッシュストレージデバイス３からデータをリードすることが必要な時、ホスト２は、ＬＵＴ４１１を参照して、リードすべきデータの論理アドレスに対応する物理アドレス（ブロック番号、ブロック内物理アドレス（ブロック内オフセット））をＬＵＴ４１１から取得する。

（２）’ホスト２は、取得されたブロック番号およびブロック内物理アドレス（ブロック内オフセット）を指定するリード要求をフラッシュストレージデバイス３に送出する。フラッシュストレージデバイス３のコントローラ４がこのリード要求をホスト２から受信した時、コントローラ４は、ブロック番号およびブロック内物理アドレスに基づいて、リード対象のブロックおよびリード対象の物理記憶位置を特定し、このリード対象のブロック内のリード対象の物理記憶位置からデータをリードする。

図５３は、物理アドレスＡＰＩ（タイプ＃３）で使用されるライトコマンドを示す。

ライトコマンドは、フラッシュストレージデバイス３にデータの書き込みを要求するコマンドである。このライトコマンドは、コマンドＩＤ、ブロック番号ＢＬＫ＃、論理アドレス、長さ、等を含んでもよい。

コマンドＩＤはこのコマンドがライトコマンドであることを示すＩＤ（コマンドコード）であり、ライトコマンドにはライトコマンド用のコマンドＩＤが含まれる。

ブロック番号ＢＬＫ＃は、データが書き込まれるべきブロックを一意に識別可能な識別子（ブロックアドレス）である。

論理アドレスは、書き込まれるべきライトデータを識別するための識別子である。この論理アドレスは、上述したように、ＬＢＡであってもよいし、キー・バリュー・ストアのキーであってもよいし、キーのハッシュ値であってもよい。論理アドレスがＬＢＡである場合には、このライトコマンドに含まれる論理アドレス（開始ＬＢＡ）は、ライトデータが書き込まれるべき論理位置（最初の論理位置）を示す。

長さは、書き込まれるべきライトデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、ＬＢＡの数によって指定されてもよいし、あるいはそのサイズがバイトによって指定されてもよい。

ホスト２からライトコマンドを受信した時、コントローラ４は、ライトコマンドによって指定されたブロック番号を有するブロック内の書き込み先位置を決定する。この書き込み先位置は、ページ書き込み順序の制約およびバッドページ等を考慮して決定される。そして、コントローラ４は、ホスト２からのデータを、ライトコマンドによって指定されたブロック番号を有するこのブロック内のこの書き込み先位置に書き込む。

図５４は、図５３のライトコマンドに対するレスポンスを示す。

このレスポンスは、ブロック内物理アドレス、長さを含む。ブロック内物理アドレスは、データが書き込まれたブロック内の位置（物理記憶位置）を示す。ブロック内物理アドレスは、上述したように、ブロック内オフセットによって指定可能である。長さは、書き込まれたデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、ＬＢＡの数によって指定されてもよいし、あるいはそのサイズがバイトによって指定されてもよい。

あるいは、このレスポンスは、ブロック内物理アドレスおよび長さだけでなく、論理アドレスおよびブロック番号をさらに含んでいてもよい。論理アドレスは、図５３のライトコマンドに含まれていた論理アドレスである。ブロック番号は、図５３のライトコマンドに含まれていた論理アドレスである。

図５５は、物理アドレスＡＰＩ（タイプ＃３）で使用されるＴｒｉｍコマンドを示す。

このＴｒｉｍコマンドは、無効にすべきデータが格納されている物理記憶位置を示すブロック番号およびブロック内物理アドレス（ブロック内オフセット）を含むコマンドである。つまり、このＴｒｉｍコマンドは、ＬＢＡのような論理アドレスではなく、物理アドレスを指定可能である。このＴｒｉｍコマンドは、コマンドＩＤ、物理アドレス、長さを含む。

コマンドＩＤはこのコマンドがＴｒｉｍコマンドであることを示すＩＤ（コマンドコード）であり、ＴｒｉｍコマンドにはＴｒｉｍコマンド用のコマンドＩＤが含まれる。

物理アドレスは、無効化すべきデータが格納されている最初の物理記憶位置を示す。物理アドレスＡＰＩ（タイプ＃３）をサポートするフラッシュストレージデバイス３では、この物理アドレスは、ブロック番号とオフセット（ブロック内オフセット）との組み合わせによって指定される。

長さは、無効化すべきデータの長さを示す。この長さ（データ長）は、粒度（Ｇｒａｉｎ）の数によって指定されてもよいし、バイトによって指定されてもよい。

コントローラ４は、複数のブロックの各々に含まれるデータそれぞれの有効／無効を示すフラグ（ビットマップフラグ）をブロック管理テーブル３２を使用して管理する。無効にすべきデータが格納されている物理記憶位置を示すブロック番号およびオフセット（ブロック内オフセット）を含むＴｒｉｍコマンドをホスト２から受信した場合、コントローラ４は、ブロック管理テーブル３２を更新して、Ｔｒｉｍコマンドに含まれるブロック番号およびブロック内オフセットに対応する物理記憶位置のデータに対応するフラグ（ビットマップフラグ）を無効を示す値に変更する。

図５６のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃３）に対応する書き込み処理のシーケンスを示す。

ホスト２は、まず、書き込みのために使用すべきブロック（フリーブロック）を自身で選択するか、またはブロックアロケートコマンドをフラッシュストレージデバイス３に送信することによってフリーブロックを割り当てるようにフラッシュストレージデバイス３に要求する。そして、ホスト２は、自身で選択したブロックのブロック番号ＢＬＫ＃（またはフラッシュストレージデバイス３によって割り当てられたフリーブロックのブロック番号ＢＬＫ＃）と、論理アドレス（ＬＢＡ）と、長さとを含むライトコマンドをフラッシュストレージデバイス３に送信する（ステップＳ２０Ｂ）。

フラッシュストレージデバイス３のコントローラ４がこのライトコマンドを受信した時、コントローラ４は、ホスト２からのライトデータを書き込むべき、このブロック番号ＢＬＫ＃を有するブロック（書き込み先ブロックＢＬＫ＃）内の書き込み先位置を決定し、この書き込み先ブロックＢＬＫ＃の書き込み先位置にライトデータを書き込む（ステップＳ１１Ｂ）。ステップＳ１１Ｂでは、コントローラ４は、論理アドレス（ここではＬＢＡ）とライトデータの双方を書き込み先ブロックに書き込んでもよい。

コントローラ４は、書き込み先ブロックＢＬＫ＃に対応するブロック管理テーブル３２を更新して、書き込まれたデータに対応するビットマップフラグ（つまり、このデータが書き込まれたオフセット（ブロック内オフセット）に対応するビットマップフラグ）を０から１に変更する（ステップＳ１２Ｂ）。

そして、図５６に示すように、コントローラ４は、このライトコマンドに対するレスポンスをホスト２に返す（ステップＳ１３Ｂ）。このレスポンスは、このデータが書き込まれたオフセット（ブロック内オフセット）を少なくとも含む。

ホスト２がこのレスポンスを受信した時、ホスト２は、ホスト２によって管理されているＬＵＴ４１１を更新して、書き込まれたライトデータに対応する論理アドレスそれぞれに物理アドレスをマッピングする（ステップＳ２１Ｂ）。

この後、ホスト２は、上述の更新データの書き込みによって不要になった以前のデータを無効化するためのＴｒｉｍコマンドをフラッシュストレージデバイス３に送信する。フラッシュストレージデバイス３のコントローラ４は、このＴｒｉｍコマンドに応じて、ブロック管理テーブル３２を更新する（図５６、ステップＳ１４Ｂ）。

図５７は、物理アドレスＡＰＩ（タイプ＃３）で使用されるリードコマンドを示す。

リードコマンドは、フラッシュストレージデバイス３にデータの読み出しを要求するコマンドである。このリードコマンドは、コマンドＩＤ、物理アドレスＰＢＡ、長さ、転送先ポインタを含む。

コマンドＩＤはこのコマンドがリードコマンドであることを示すＩＤ（コマンドコード）であり、リードコマンドにはリードコマンド用のコマンドＩＤが含まれる。

物理アドレスＰＢＡは、データが読み出されるべき最初の物理記憶位置を示す。物理アドレスＰＢＡは、ブロック番号、オフセット（ブロック内オフセット）によって指定される。

長さは、リードすべきデータの長さを示す。このデータ長は、Ｇｒａｉｎの数によって指定可能である。

転送先ポインタは、読み出されたデータが転送されるべきホスト２内のメモリ上の位置を示す。

一つのリードコマンドは、物理アドレスＰＢＡ（ブロック番号、オフセット）と長さの組を複数指定することができる。

図５８は、物理アドレスＡＰＩ（タイプ＃３）で使用されるガベージコレクション（ＧＣ）制御コマンドを示す。

ＧＣ制御コマンドは、ＧＣソースブロック番号およびＧＣデスティネーションブロック番号をフラッシュストレージデバイス３に通知するために使用される。ホスト２は、各ブロックの有効データ量／無効データ量を管理しており、有効データ量がより少ない幾つかのブロックをＧＣソースブロックとして選択することができる。また、ホスト２は、フリーブロックリストを管理しており、幾つかのフリーブロックをＧＣデスティネーションブロックとして選択することができる。このＧＣ制御コマンドは、コマンドＩＤ、ＧＣソースブロック番号、ＧＣデスティネーションブロック番号、等を含んでもよい。

コマンドＩＤはこのコマンドがＧＣ制御コマンドであることを示すＩＤ（コマンドコード）であり、ＧＣ制御コマンドにはＧＣ制御コマンド用のコマンドＩＤが含まれる。

ＧＣソースブロック番号は、ＧＣソースブロックを示すブロック番号である。ホスト２は、どのブロックをＧＣソースブロックとすべきかを指定することができる。ホスト２は、複数のＧＣソースブロック番号を一つのＧＣ制御コマンドに設定してもよい。

ＧＣデスティネーションブロック番号は、ＧＣデスティネーションブロックを示すブロック番号である。ホスト２は、どのブロックをＧＣデスティネーションブロックとすべきかを指定することができる。ホスト２は、複数のＧＣデスティネーションブロック番号を一つのＧＣ制御コマンドに設定してもよい。

図５９は、物理アドレスＡＰＩ（タイプ＃３）で使用されるＧＣ用コールバックコマンドを示す。

ＧＣ用コールバックコマンドは、ＧＣによってコピーされた有効データの論理アドレスとこの有効データのコピー先位置を示すブロック番号およびオフセットとをホスト２に通知するために使用される。

ＧＣ用コールバックコマンドは、コマンドＩＤ、論理アドレス、長さ、デスティネーション物理アドレスを含んでよい。

コマンドＩＤはこのコマンドがＧＣ用コールバックコマンドであることを示すＩＤ（コマンドコード）であり、ＧＣ用コールバックコマンドにはＧＣ用コールバックコマンド用のコマンドＩＤが含まれる。

論理アドレスは、ＧＣによってＧＣソースブロックからＧＣデスティネーションブロックにコピーされた有効データの論理アドレスを示す。

長さは、このコピーされたデータの長さを示す。このデータ長は、粒度（Ｇｒａｉｎ）の数によって指定されてもよい。

デスティネーション物理アドレスは、有効データがコピーされたＧＣデスティネーションブロック内の位置を示す。デスティネーション物理アドレスは、ブロック番号、オフセット（ブロック内オフセット）によって指定される。

図６０のシーケンスチャートは、物理アドレスＡＰＩ（タイプ＃３）に対応するガベージコレクション（ＧＣ）動作の手順を示す。

例えば、ホスト２は、ホスト２によって管理されているフリーブロックリストに含まれている残りフリーブロックの数が閾値以下に低下した場合、ＧＣソースブロックおよびＧＣデスティネーションブロックを選択し、選択されたＧＣソースブロックおよび選択されたＧＣデスティネーションブロックを指定するＧＣ制御コマンドをフラッシュストレージデバイス３に送信する（ステップＳ４１Ｂ）。あるいは、ライト処理部４１２がフリーブロック群を管理する構成においては、残りフリーブロックの数が閾値以下に低下した際にライト処理部４１２がホスト２にその旨通知を行ない、通知を受信したホスト２がブロック選択およびＧＣ制御コマンドの送信を行なってもよい。

このＧＣ制御コマンドを受信すると、フラッシュストレージデバイス３のコントローラ４は、ＧＣソースブロック内の有効データを書き込むべきＧＣデスティネーションブロック内の位置（コピー先位置）を決定する動作と、ＧＣソースブロック内の有効データをＧＣデスティネーションブロック内のコピー先位置にコピーする動作とを含むデータコピー動作を実行する（ステップＳ５１Ｂ）。ステップＳ５１Ｂでは、コントローラ４は、ＧＣソースブロック（コピー元ブロック）内の有効データのみならず、この有効データとこの有効データに対応する論理アドレスの双方を、ＧＣソースブロック（コピー元ブロック）からＧＣデスティネーションブロック（コピー先ブロック）にコピーする。これにより、ＧＣデスティネーションブロック（コピー先ブロック）内にデータと論理アドレスとのペアを保持することができる。

また、ステップＳ５１Ｂでは、ＧＣソースブロック内の全ての有効データのコピーが完了するまでデータコピー動作が繰り返し実行される。複数のＧＣソースブロックがＧＣ制御コマンドによって指定された場合には、全てのＧＣソースブロック内の全ての有効データのコピーが完了するまでデータコピー動作が繰り返し実行される。

そして、コントローラ４は、コピーされた有効データ毎に、その有効データの論理アドレス（ＬＢＡ）と、その有効データのコピー先位置を示すデスティネーション物理アドレス等を、ＧＣ用コールバックコマンドを使用してホスト２に通知する（ステップＳ５２Ｂ）。ある有効データに対応するデスティネーション物理アドレスは、この有効データがコピーされたコピー先ブロック（ＧＣデスティネーションブロック）のブロック番号と、この有効データがコピーされたコピー先ブロック内の物理記憶位置を示すブロック内物理アドレス（ブロック内オフセット）とによって表される。

ホスト２がこのＧＣ用コールバックコマンドを受信した時、ホスト２は、ホスト２によって管理されているＬＵＴ４１１を更新して、コピーされた各有効データに対応する論理アドレスにデスティネーション物理アドレス（ブロック番号、ブロック内オフセット）をマッピングする（ステップＳ４２Ｂ）。

以上説明したように、本実施形態によれば、ＮＡＮＤ型フラッシュメモリ５をアクセスするための複数種のインタフェースがサポートされており、ＮＡＮＤ型フラッシュメモリ５内のアクセス対象の領域毎に、使用すべきインタフェースを切り替えることができる。したがって、ホスト２は異なる種類のインタフェースに対応した複数の領域を選択的に利用することができる。また、これら複数の領域には、少なくとも、ホスト２が論理アドレスを指定しＮＡＮＤ型フラッシュメモリ５の物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる第１領域と、ホスト２がＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部または全体を指定する第２タイプのインタフェースを使用してリードアクセスされる第２領域とが含まれている。

第１タイプのインタフェースにおいては、ホスト２は、ＮＡＮＤ型フラッシュメモリの物理アドレスを指定する必要は無く、リードすべきデータに対応する論理アドレスのみを指定すればよい。したがって、第１領域をリードアクセスする場合においては、ＮＡＮＤ型フラッシュメモリ５を直接的にハンドリングするための機能群がホスト２上で既に実行されている必要は無い。よって、第１領域は、オペレーティングシステムをブートするためのブータブル領域として利用可能である。

また、第２タイプのインタフェース（物理アドレスＡＰＩ）を使用してデータをリードする場合においては、ホスト２は、ＮＡＮＤ型フラッシュメモリ５の物理アドレスの一部または全体を指定することができる。したがって、ホスト２は、必要に応じて物理アドレスＡＰＩを使用することにより、ＮＡＮＤ型フラッシュメモリ５を直接的にアクセスすることができる。

なお、フラッシュストレージデバイス３は、ストレージアレイ内に設けられる複数のフラッシュストレージデバイス３の一つとして利用されてもよい。ストレージアレイは、サーバ計算機のような情報処理装置にケーブルまたはネットワークを介して接続されてもよい。ストレージアレイは、このストレージアレイ内の複数のフラッシュストレージデバイス３を制御するコントローラを含む。フラッシュストレージデバイス３がストレージアレイに適用された場合には、このストレージアレイのコントローラが、フラッシュストレージデバイス３のホスト２として機能してもよい。

また、本実施形態では、不揮発性メモリとしてＮＡＮＤ型フラッシュメモリを例示した。しかし、本実施形態の機能は、例えば、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＰＲＡＭ（Ｐｈａｓｅ ｃｈａｎｇｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲｅＲＡＭ（Ｒｅｓｉｓｔｉｖｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、又は、ＦｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような他の様々な不揮発性メモリにも適用できる。

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

２…ホスト、３…フラッシュストレージデバイス、４…コントローラ、５…ＮＡＮＤ型フラッシュメモリ、２０…ＡＰＩ設定／選択部、２１…ライト動作制御部、２２…リード動作制御部、２３…ＧＣ動作制御部。

Claims (15)

1. ホストに接続可能なメモリシステムであって、
   各々が複数のページを含む複数のブロックを含む不揮発性メモリと、
   前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するコントローラとを具備し、
   前記コントローラは、
   前記不揮発性メモリを論理的に分割することによって得られる複数の領域を管理し、前記複数の領域は、前記ホストが論理アドレスを指定し前記不揮発性メモリの物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる一つ以上の第１領域と、前記ホストが前記不揮発性メモリの物理アドレスの一部または全体を指定する第２タイプのインタフェースを使用してリードアクセスされる一つ以上の第２領域とを含み、
   前記ホストからリード要求を受信し、
   前記受信したリード要求が前記一つ以上の第１領域の一つの第１領域を示す第１の識別子を含む場合、前記第１タイプのインタフェースを選択し、前記受信したリード要求から論理アドレスを取得し、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記一つの第１領域の物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得し、取得した物理アドレスに基づいて、前記一つの第１領域からデータをリードし、
   前記受信したリード要求が前記一つ以上の第２領域の一つの第２領域を示す第２の識別子を含む場合、前記第２タイプのインタフェースを選択し、前記受信したリード要求から前記一つの第２領域の物理アドレスの一部または全てを指定する物理アドレス情報を取得し、前記取得した物理アドレス情報に基づいて、前記一つの第２領域からデータをリードするように構成されている、メモリシステム。
2. 前記一つ以上の第１領域は、オペレーティングシステムをブート可能なブータブル領域を含む請求項１記載のメモリシステム。
3. 前記第１タイプのインタフェースにおいて前記ホストによって指定される前記論理アドレスは論理ブロックアドレスである請求項１記載のメモリシステム。
4. 前記複数の領域は、前記第１タイプのインタフェースおよび前記第２タイプのインタフェースの各々と異なる第３タイプのインタフェースを使用してリードアクセスされる一つ以上の第３領域をさらに含む請求項１記載のメモリシステム。
5. 前記第２タイプのインタフェースにおいては、前記ホストから受信されるライト要求は論理アドレスを指定し、前記ホストから受信されるリード要求は前記不揮発性メモリの物理アドレスの全体を指定し、
   前記コントローラは、
   前記第２の識別子を含み且つ第１の論理アドレスを指定するライト要求を前記ホストから受信した場合、前記ホストからのデータを書き込むべき、第１のブロックと前記第１のブロック内の第１の位置との双方を決定し、前記ホストからのデータを前記第１のブロックの前記第１の位置に書き込み、前記第１の論理アドレスと、前記第１のブロックを指定する第１のブロック番号と、前記第１の位置を指定する第１のブロック内物理アドレスとを前記ホストに通知し、
   前記第１のブロック番号および前記第１のブロック内物理アドレスを指定するリード要求を前記ホストから受信した場合、前記第１のブロック内物理アドレスに基づいて前記第１のブロックからデータをリードするように構成されている請求項１記載のメモリシステム。
6. 前記第２タイプのインタフェースにおいては、前記ホストから受信されるライト要求はブロック番号と論理アドレスとを指定し、前記ホストから受信されるリード要求はブロック番号と論理アドレスとを指定し、
   前記コントローラは、
   前記第２の識別子を含み且つ第１のブロック番号と第１の論理アドレスを指定するライト要求を前記ホストから受信した場合、前記ホストからのデータを書き込むべき、前記第１のブロック番号を有する第１のブロック内の第１の位置を決定し、前記ホストからのデータを前記第１のブロック内の前記第１の位置に書き込み、論理アドレスそれぞれと前記第１のブロックのブロック内物理アドレスそれぞれとの間のマッピングを管理する第１のアドレス変換テーブルを更新して、前記第１の位置を示す第１のブロック内物理アドレスを前記第１の論理アドレスにマッピングし、
   前記第１のブロック番号と前記第１の論理アドレスを指定するリード要求を前記ホストから受信した場合、前記第１の論理アドレスを使用して前記第１のアドレス変換テーブルを参照して、前記第１のブロック内物理アドレスを取得し、前記第１のブロック番号と前記取得された第１のブロック内物理アドレスとに基づいて、前記第１の論理アドレスに対応するデータを前記第１のブロックからリードするように構成されている請求項１記載のメモリシステム。
7. 前記第２タイプのインタフェースにおいては、前記ホストから受信されるライト要求はブロック番号と論理アドレスとを指定し、前記ホストから受信されるリード要求は前記不揮発性メモリの物理アドレスの全体を指定し、
   前記コントローラは、
   前記第２の識別子を含み且つ第１の論理アドレスと第１のブロック番号とを指定するライト要求を前記ホストから受信した場合、前記ホストからのデータを書き込むべき、前記第１のブロック番号を有する第１のブロック内の第１の位置を決定し、前記ホストからのデータを前記第１のブロック内の前記第１の位置に書き込み、前記第１の位置を示す第１のブロック内物理アドレス、または前記第１の論理アドレスと前記第１のブロック番号と前記第１のブロック内物理アドレスとの組のいずれかを、前記ホストに通知し、
   前記第１のブロック番号と前記第１のブロック内物理アドレスを指定するリード要求を前記ホストから受信した場合、前記第１のブロック番号と前記第１のブロック内物理アドレスとに基づいて、前記第１のブロック内の前記第１の位置からデータをリードするように構成されている請求項１記載のメモリシステム。
8. ホストに接続可能なメモリシステムであって、
   各々が複数のページを含む複数のブロックを含む不揮発性メモリと、
   前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するコントローラとを具備し、
   前記コントローラは、
   複数のネームスペースを管理し、前記複数のネームスペースは、前記ホストが論理アドレスを指定し前記不揮発性メモリの物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる第１ネームスペースと、前記ホストが前記不揮発性メモリの物理アドレスの一部または全体を指定する第２タイプのインタフェースを使用してリードアクセスされる第２ネームスペースとを含み、
   前記ホストからリード要求を受信し、
   前記受信したリード要求が前記第１ネームスペースの識別子を含む場合、前記第１タイプのインタフェースを選択し、前記受信したリード要求から論理アドレスを取得し、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記不揮発性メモリの物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得し、取得した物理アドレスに基づいて、前記第１ネームスペースからデータをリードし、
   前記受信したリード要求が前記第２ネームスペースの識別子を含む場合、前記第２タイプのインタフェースを選択し、前記受信したリード要求から前記不揮発性メモリの物理アドレスの一部または全てを指定する物理アドレス情報を取得し、前記取得した物理アドレス情報に基づいて、前記第２ネームスペースからデータをリードするように構成されている、メモリシステム。
9. 前記第１ネームスペースは、オペレーティングシステムをブート可能なネームスペースである請求項８記載のメモリシステム。
10. 各々が複数のページを含む複数のブロックを含む不揮発性メモリを制御する制御方法であって、
    前記不揮発性メモリを論理的に分割することによって得られる複数の領域を管理することと、前記複数の領域は、ホストが論理アドレスを指定し前記不揮発性メモリの物理アドレスを指定しない第１タイプのインタフェースを使用してリードアクセスされる一つ以上の第１領域と、前記ホストが前記不揮発性メモリの物理アドレスの一部または全体を指定する第２タイプのインタフェースを使用してリードアクセスされる一つ以上の第２領域とを含み、
    前記ホストからリード要求を受信することと、
    前記受信したリード要求が前記一つ以上の第１領域の一つの第１領域を示す第１の識別子を含む場合、前記第１タイプのインタフェースを選択する動作と、前記受信したリード要求から論理アドレスを取得する動作と、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記一つの第１領域の物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得する動作と、取得した物理アドレスに基づいて、前記一つの第１領域からデータをリードする動作とを実行することと、
    前記受信したリード要求が前記一つ以上の第２領域の一つの第２領域を示す第２の識別子を含む場合、前記第２タイプのインタフェースを選択する動作と、前記受信したリード要求から前記一つの第２領域の物理アドレスの一部または全てを指定する物理アドレス情報を取得する動作と、前記取得した物理アドレス情報に基づいて、前記一つの第２領域からデータをリードする動作とを実行することとを具備する制御方法。
11. 前記一つ以上の第１領域は、オペレーティングシステムをブート可能なブータブル領域を含む請求項１０記載の制御方法。
12. 前記第１タイプのインタフェースにおいて前記ホストによって指定される前記論理アドレスは論理ブロックアドレスである請求項１０記載の制御方法。
13. ホストに接続可能なメモリシステムであって、
    各々が複数のページを含む複数のブロックを含む不揮発性メモリと、
    前記不揮発性メモリに電気的に接続され、前記不揮発性メモリを制御するコントローラとを具備し、
    前記コントローラは、
    前記不揮発性メモリを論理的に分割することによって得られる複数の領域を管理し、前記複数の領域は少なくとも第１領域と第２領域とを含み、
    前記ホストから前記第１領域を示す第１の識別子を含むリード要求を受信した場合、前記受信したリード要求から論理アドレスを取得し、前記取得した論理アドレスに対応する物理アドレスを、論理アドレスそれぞれと前記第１領域の物理アドレスそれぞれとの間のマッピングを管理する論理物理アドレス変換テーブルから取得し、取得した物理アドレスに基づいて、前記第１領域からデータをリードし、
    前記ホストから前記第２領域を示す第２の識別子を含むリード要求を受信した場合、前記受信したリード要求から前記第２領域の物理アドレスの一部または全てを指定する物理アドレス情報を取得し、前記取得した物理アドレス情報に基づいて、前記第２領域からデータをリードするように構成されている、メモリシステム。
14. 前記第１領域は、オペレーティングシステムをブート可能なブータブル領域を含む請求項１３記載のメモリシステム。
15. 前記第１の識別子を含む前記リード要求に含まれる論理アドレスは、論理ブロックアドレスである請求項１３記載のメモリシステム。

Images