(57)【要約】【課題】ＳＳＤを用いた情報処理においてデータアクセスを効率化する。【解決手段】書き込み処理における粒度が異なる２つのアドレス空間を準備する。第１アドレス空間は例えば読み出し処理の粒度と等しい細かい粒度とし、第２アドレス空間はそれより粗い粒度とし、それに対応するデータはフラッシュメモリ２０の連続した領域に格納する。第２アドレス空間のアドレス変換テーブルはサイズが小さいためフラッシュコントローラのＳＲＡＭ２４全体を格納し、第１アドレス空間のアドレス変換テーブルはＳＲＡＭ２４にその一部をキャッシュして参照する。【選択図】図２
2017068804.tif 000002
【特許請求の範囲】
【請求項１】
二次記憶装置の論理アドレスを指定してデータアクセスを要求するホストユニットと、
前記データアクセスの要求を受け付け、アドレス変換テーブルを用いて物理アドレスに変換し前記二次記憶装置の該当領域に対するデータアクセス処理を実行するコントローラと、を備え、
前記アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とする情報処理装置。
【請求項２】
前記コントローラは、前記粒度の粗いアドレス空間を定義するアドレス変換テーブルの全体を、前記二次記憶装置から当該コントローラが内蔵するメモリに格納することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記アドレス変換テーブルが定義するアドレス空間は、読み出し単位と等しい単位の物理アドレスを論理アドレスに対応づける粒度の細かいアドレス空間をさらに含み、
前記コントローラは、前記粒度の細かいアドレス空間を定義するアドレス変換テーブルのうちの一部を、前記データアクセスの要求に応じて入れ替えて格納することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記コントローラは、前記ホストユニットからデータ書き込み要求を受け付けた際、指定された論理アドレスが属するアドレス空間に応じて、前記二次記憶装置における書き込み対象の領域のサイズを切り替えることを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記コントローラは、前記ホストユニットからデータ読み出し要求を受け付けた際、指定された論理アドレスが属するアドレス空間に応じて、物理アドレスの導出手順を切り替えることを特徴とする請求項３または４に記載の情報処理装置。
【請求項６】
情報処理装置においてホストユニットから二次記憶装置へのデータアクセスを制御するアクセスコントローラであって、
前記ホストユニットが指定したアクセス先の論理アドレスを、アドレス変換テーブルを用いて物理アドレスに変換するホストコントローラと、
前記物理アドレスに基づき前記二次記憶装置に対するデータアクセスを実行するメモリコントローラと、を備え、
前記アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とするアクセスコントローラ。
【請求項７】
ホストユニットが、二次記憶装置の論理アドレスを指定してデータアクセスを要求するステップと、
コントローラが、前記データアクセスの要求を受け付け、アドレス変換テーブルを用いて物理アドレスに変換し前記二次記憶装置の該当領域に対するデータアクセス処理を実行するステップと、を含み、
前記アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とする情報処理方法。
【請求項８】
情報処理装置においてホストユニットから二次記憶装置へのデータアクセスを制御するコンピュータに、
前記ホストユニットが指定したアクセス先の論理アドレスを、アドレス変換テーブルを用いて物理アドレスに変換する機能と、
前記物理アドレスに基づき前記二次記憶装置に対するデータアクセスを実行する機能と、を実現させ、
前記アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、二次記憶装置としてフラッシュメモリを用いる情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
ＮＡＮＤ型フラッシュメモリの容量拡大に伴い、従来のＨＤＤ（Hard Disk Drive）に代わる記憶装置としてＳＳＤ（Solid State Drive）が用いられるようになってきた。ＳＳＤはＨＤＤと比較しデータアクセスを高速かつ低消費電力で行える、という利点がある一方、繰り返しの書き換えに対する耐久性が低い、という特性を有する。そのためＳＳＤに対するデータ書き換えには、書き換え対象の領域を分散させるウェアレベリング技術が用いられる。すなわちホストＣＰＵから書き換え要求がなされたとき、指定された論理ブロックアドレスを異なる物理アドレスに置き換えることにより、書き換え対象をできるだけ複数のメモリセルに分散させる（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】ＷＯ  ２０１４／１３２３４６  Ａ１公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
このような仕組みにおいては論理ブロックアドレスを物理アドレスに変換するためのアドレス変換テーブルが必要になる。アドレス変換テーブルは、ＳＳＤの全容量の０．１％程度のデータサイズを有するのが一般的である。当然、フラッシュメモリの容量が拡大するにつれ、アドレス変換テーブルのデータサイズも増大する。アドレス変換テーブルを効率的に参照するために、その一部を外付けのＤＲＡＭ（Dynamic Random Access Memory）などにキャッシュすることが考えられるが、効率性を追求するほど大容量のＤＲＡＭが必要となる。また参照頻度が上がるほどＤＲＡＭアクセスのためのレイテンシによってコマンド処理のスループットが低下し、ＳＳＤのアクセス速度の優位性を損なうこともある。
【０００５】
本発明はこうした課題に鑑みてなされたものであり、その目的は、ＳＳＤを利用する情報処理装置におけるデータアクセスを効率化できる技術を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のある態様は情報処理装置に関する。この情報処理装置は、二次記憶装置の論理アドレスを指定してデータアクセスを要求するホストユニットと、当該データアクセスの要求を受け付け、アドレス変換テーブルを用いて物理アドレスに変換し二次記憶装置の該当領域に対するデータアクセス処理を実行するコントローラと、を備え、アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とする。
【０００７】
本発明の別の態様はアクセスコントローラに関する。このアクセスコントローラは、ホストユニットが指定したアクセス先の論理アドレスを、アドレス変換テーブルを用いて物理アドレスに変換するホストコントローラと、物理アドレスに基づき二次記憶装置に対するデータアクセスを実行するメモリコントローラと、を備え、アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とする。
【０００８】
本発明のさらに別の態様は情報処理方法に関する。この情報方法は、ホストユニットが、二次記憶装置の論理アドレスを指定してデータアクセスを要求するステップと、コントローラが、データアクセスの要求を受け付け、アドレス変換テーブルを用いて物理アドレスに変換し二次記憶装置の該当領域に対するデータアクセス処理を実行するステップと、を含み、アドレス変換テーブルが定義するアドレス空間は、読み出し単位より大きい単位の物理アドレスをまとめて論理アドレスに対応づける粒度の粗いアドレス空間を含むことを特徴とする。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によると、ＳＳＤを利用した情報処理装置をリソースおよび処理時間の双方で効率化できる。
【図面の簡単な説明】
【００１１】
【図１】本実施の形態における情報処理装置の内部構成を示す図である。
【図２】本実施の形態におけるフラッシュメモリに格納されたデータとアドレス変換テーブルの構成との関係を模式的に示す図である。
【図３】本実施の形態において第２アドレス空間のデータの格納領域を取得する手法を説明するための図である。
【図４】本実施の形態における情報処理装置の内部構成を示す図である。
【図５】本実施の形態におけるソフトウェアスタックの構成を示す図である。
【図６】本実施の形態におけるファイルアーカイブおよびフラッシュコントローラが、処理対象のファイルデータをフラッシュメモリに格納する手順を模式的に示す図である。
【図７】本実施の形態における、ファイルアーカイブを用いて要求されたファイルへアクセスするまでの処理手順を模式的に示す図である。
【図８】本実施の形態における、ファイルアーカイブを用いて要求されたファイルの読み出しを完了するまでの処理手順を模式的に示す図である。
【発明を実施するための形態】
【００１２】
図１は、本実施の形態の情報処理装置の内部構成を示している。ここで例示する情報処理装置は、携帯ゲーム機、パーソナルコンピュータ、携帯電話、タブレット端末、ＰＤＡなど一般的な情報機器のいずれでもよい。情報処理装置１０は、ＣＰＵを含むホストユニット１２、システムメモリ１４、ＮＡＮＤ型フラッシュメモリ２０（以後、単にフラッシュメモリ２０と呼ぶ）、フラッシュコントローラ１８を含む。
【００１３】
ホストユニット１２は、フラッシュメモリ２０に格納されたプログラムやデータをシステムメモリ１４にロードし、それを用いて情報処理を行う。またアプリケーションプログラムやデータを、図示しない記録媒体駆動部において駆動された記録媒体から読み出したり通信部によりネットワーク接続されたサーバからダウンロードしたりしてフラッシュメモリ２０に格納する。この際、ホストユニット１２はフラッシュコントローラ１８に、フラッシュメモリ２０に対するアクセス要求を発行し、フラッシュコントローラ１８はそれに応じてフラッシュメモリ２０に対し読み出し／書き込み処理を実施する。
【００１４】
フラッシュメモリ２０には複数のＮＡＮＤ型フラッシュメモリが接続されており、データは図示するように複数のチャネル（図では「ｃｈ０」〜「ｃｈ３」の４チャネル）に分散されて格納される。フラッシュコントローラ１８は、ホストユニット１２とのインターフェース機能を有するホストコントローラ２２、フラッシュメモリ２０とのインターフェース機能を有するメモリコントローラ２８、およびＳＲＡＭ（Static Random Access Memory）２４を含む。ホストコントローラ２２およびメモリコントローラ２８の動作は、ハードウェア的には各種回路や装置で実現でき、ソフトウェア的には、内部に保持するプログラムで実現される。したがってハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
【００１５】
ホストユニット１２は、情報処理の進捗に応じてフラッシュメモリ２０に対するアクセス要求を発生させ、それをシステムメモリ１４に格納する。当該アクセス要求にはアクセス先の論理アドレス（ＬＢＡ：Logical Block Address）が含まれる。フラッシュコントローラ１８のホストコントローラ２２は、システムメモリ１４に格納されたアクセス要求を読み出し、ＬＢＡをフラッシュメモリ２０の物理アドレスに変換する。この際、必要となるアドレス変換テーブルは、元々フラッシュメモリ２０に格納されていたものの少なくとも一部をＳＲＡＭ２４に展開しておく。
【００１６】
ホストコントローラ２２は、当該アドレス変換テーブルを参照してＬＢＡに基づき取得した物理アドレスをメモリコントローラ２８に供給する。メモリコントローラ２８は当該物理アドレスに基づきフラッシュメモリ２０の該当する領域にアクセスすることによりデータを読み出したり書き込んだりする。一般に、フラッシュメモリ２０に対するデータ読み出し／書き込みは、４０９６バイト等のアクセス単位でなされる。
【００１７】
またデータを書き換える際は、フラッシュメモリ２０の対象領域のデータ消去を伴うが、このときは数ＭｉＢ（１ＭｉＢ＝１０２０バイト）のブロック単位でなされる。フラッシュメモリ２０はデータ消去を繰り返すほど摩耗されるため、消去回数を抑えるための工夫が必要となる。具体的には、データの書き換えが発生した際、できるだけ書き換え前のデータの消去を行わず、別の領域に書き換え後のデータを格納したうえ当該領域を指すようにアドレス変換テーブルを更新する。一方で、書き換えが頻発しても新規に割り当てる領域が枯渇しないよう、定期的に使用済みの領域を消去する。
【００１８】
上記のように４０９６バイトのアクセス単位でデータの読み出し／書き込みを行う場合、アドレス変換テーブルの各エントリのデータサイズを４バイトとすると、アドレス変換テーブル全体では、フラッシュメモリ２０の全容量に対し０．１％のデータサイズを有することになる。例えばフラッシュメモリ２０の全容量が１テラバイトであれば、アドレス変換テーブルは１ギガバイトとなる。フラッシュコントローラ１８は、ホストユニット１２からデータアクセスが要求される都度、指定されたＬＢＡを物理アドレスに変換するために、まずアドレス変換テーブルを参照する必要がある。
【００１９】
参照対象のアドレス変換テーブルをフラッシュメモリ２０に格納した場合、アドレス変換のためにフラッシュメモリ２０へアクセスする頻度が増大し、処理のスループットの低下やレイテンシの増大につながる。アドレス変換テーブルの多くの部分を外付けＤＲＡＭなどにキャッシュしておくことにより効率化は図られるが、フラッシュメモリ２０が大容量化するほど大容量のＤＲＡＭが必要となる。またＤＲＡＭのデータ伝送レートが支配的となり、やはりスループットがレイテンシの十分な改善が見込めないこともある。
【００２０】
そこで本実施の形態では、少なくとも一部のデータについては、書き込み要求に対するデータの処理単位、すなわち粒度を大きくすることによりアドレス変換テーブルのサイズを抑える。例えば書き込みの粒度を１２８ＭｉＢとし、アドレス変換テーブルの各エントリのデータサイズを上述同様、４バイトとすると、アドレス変換テーブル全体のデータサイズは、フラッシュメモリ２０の容量の１／２２５倍となる。例えば３２ＫｉＢ（３２×２１０バイト）のアドレス変換テーブルにより１ＴｉＢ（２４０バイト）の領域を表すことができる。
【００２１】
このように十分小さなサイズのアドレス変換テーブルをフラッシュコントローラ１８内部のＳＲＡＭ２４に格納することにより、外付けＤＲＡＭの介在なくアドレス変換が行える。書き込みの粒度を粗くする態様は、光ディスクやネットワークからロードしてフラッシュメモリ２０に格納し、繰り返し参照のみされるゲームプログラムなどにおいては特に有効である。これは、格納済みのデータに対する書き換えが発生しない結果、書き換え後のデータを格納するために新たな領域をその単位で確保する必要がないことによる。
【００２２】
なおこのような粗い粒度で書き込みを行っても、当該書き込み単位内ではデータの連続性が保たれているため、読み出し時のデータは、より細かい単位でランダムに指定できる。一方、セーブデータなど書き換えが必要なデータのためには、書き込みについても細かい粒度で行えるようにすることが望ましい。そのため、データの特性に応じて書き込みの粒度が異なる複数の変換テーブルを定義する。粒度の細かいアドレス変換テーブルは上述のとおりデータサイズが大きくなるため、その一部をＳＲＡＭ２４にキャッシュする。
【００２３】
図２は、フラッシュメモリ２０に格納されたデータとアドレス変換テーブルの構成との関係を模式的に示している。アドレス変換テーブルには粒度の異なる複数のアドレス空間が定義され、図示する例では粒度の細かい第１アドレス空間と粒度の粗い第２アドレス空間とからなっている。ただし粒度を３つ以上としてもよい。同図では、ホストユニット１２が指定するＬＢＡを「（アドレス空間番号）−（空間内でのアドレス）」なる形式で表している。例えば「１−１」は第１アドレス空間内のアドレス「１」、「２−２」は第２アドレス空間のアドレス「２」を表す。ただしＬＢＡを記述する４バイト等のデータにはそのほかの情報が含まれてよい。
【００２４】
またアドレス変換によって取得される物理アドレスは基本的に、「（チャネル番号）−（アドレス）」あるいは「アドレス」なる形式で表している。一方、フラッシュメモリ２０は、格納領域をチャネルごとに縦長の長方形で表している。当該長方形を分割してなる矩形のうち、「Ｔ」が記載された矩形はアドレス変換テーブルが格納された領域であり、「１−１」などのＬＢＡが記載された矩形は、それに対応するデータが格納された領域を示す。第１アドレス空間で定義されるデータの書き込み時の粒度は典型的には読み出し時の粒度と等しい、例えば４ＫｉＢなどであり、ＬＢＡは当該サイズの領域に対し１つ定義する。
【００２５】
一方、第２アドレス空間では、１つのＬＢＡによって、第１アドレス空間で定義される領域より大きい領域をまとめて定義できるようにする。図示する例ではｃｈ０〜ｃｈ３の４つのチャネルに渡る連続領域としている。このアドレス空間が対象とするデータの書き込みの時の粒度は、例えば１２８ＭｉＢであるが、フラッシュメモリ２０とＳＲＡＭ２４の容量に基づくアドレス変換テーブルのサイズの上限などに応じて適宜決定してよい。このデータは情報処理による書き換えはなされないため、基本的にはその格納領域やデータ構成が維持される。
【００２６】
ただしフラッシュメモリ２０の経年劣化などによってビットエラーが検出され、データを移動させるときは、新たに当該サイズの連続領域を割り当てる。また消去回数の増加に伴いフラッシュメモリ２０のあるブロックが不良となった場合、第２アドレス空間のデータについては、書き込み単位に含まれるその周辺のブロックも割り当て不可となる。これに対し第１アドレス空間で定義されるデータを書き換えたり移動させたりする際は、４ＫｉＢなど細かい粒度で新たな領域を割り当てることができる。また粒度が細かいほど、近傍の不良により割り当て不可とされるブロックを少なくできる。
【００２７】
したがって上述のように、データの特性によって書き込み時の粒度を異ならせることにより、アドレス変換テーブルのサイズの縮小とフラッシュメモリ２０におけるデータ格納領域の効率性とを両立させることができる。アドレス変換テーブルは、フラッシュメモリ２０の「Ｔ」の領域に格納されていたものを、第１アドレス空間、第２アドレス空間で別々にＳＲＡＭ２４に読み出しておく。第２アドレス空間のアドレス変換テーブルは上述のようにデータサイズが小さいため、起動時に全てをプリロードしておくことにより常にキャッシュヒットさせることができる。
【００２８】
第１アドレス空間のアドレス変換テーブルは、ＳＲＡＭ２４の容量に応じてその一部をキャッシュする。キャッシュ動作の手順については従来技術を適用できる。データの移動や書き換えなどによりＳＲＡＭ２４に格納されたアドレス変換テーブルを更新した場合は、適当なタイミングでフラッシュメモリ２０に格納された元のテーブルに書き戻しておく。
【００２９】
ここでホストユニット１２が、第１アドレス空間であるＬＢＡ＝「１−１」を指定して読み出しあるいは書き込みを要求したとする。このときフラッシュコントローラ１８は、アドレス変換テーブルを参照し、それに対応づけられた、フラッシュメモリ２０の物理アドレス「ｃｈ０−Ｃ」を取得する。上述のとおり第１アドレス空間では書き込みの単位、ひいては読み出しの単位ごとにＬＢＡが設定される。したがってアドレス変換テーブルに示された物理アドレス「ｃｈ０−Ｃ」、すなわちチャネル番号ｃｈ０のアドレスＣを先頭アドレスとする１単位分のデータを読み出す。
【００３０】
書き込み要求の場合は、読み出したデータを適宜更新し、フラッシュメモリ２０の別の領域に書き込んだうえアドレス変換テーブルにおける物理アドレスを、当該領域を示すように更新する。一方、ホストユニット１２が第２アドレス空間であるＬＢＡ＝「２−１」を指定して読み出しを要求したら、フラッシュコントローラ１８は、アドレス変換テーブルに記述される物理アドレス「Ａ」に基づき、読み出し単位のデータの格納領域を計算によって求める。
【００３１】
図３は第２アドレス空間のデータの格納領域を取得する手法を説明するための図である。第２アドレス空間におけるＬＢＡの上位ビットは、これまで述べたように書き込み単位の領域ごとに一意に与えられた論理アドレスを表す。このアドレスは、図２における「２−１」などに対応する。例えば第２アドレス空間の書き込みアクセス粒度が１２８ＭｉＢ（２２７バイト）、アドレス変換テーブルのサイズが５１２Ｂ（２９バイト）、各アドレス空間が１ＴｉＢ（１０４０バイト）とすると、ＬＢＡ３２ビットのうちビット３１：１９を上位ビットとする。
【００３２】
フラッシュコントローラ１８は、この上位ビットをインデックスとしてアドレス変換テーブル１００を参照し、それに対応づけられた物理アドレス（ＰＡ）を取得する。このアドレスは、図２における「Ａ」などに対応し、書き込み単位の領域における先頭物理アドレスを表す。図３ではＬＢＡの上位ビット「ｉｎｄｅｘ」がアドレス変換テーブル１００の「ｉｎｄｅｘ３」と合致し、それに対応する物理アドレス「ＰＡ３」が取得されることを示している。
【００３３】
第１アドレス空間の場合、上述のとおりこの「ＰＡ３」を先頭アドレスとする読み出し単位の領域からデータを読み出せばよい。一方、第２アドレス空間の場合、フラッシュコントローラ１８は、同図において「ｏｆｆｓｅｔ」と記載されたＬＢＡの下位ビットと、取得した物理アドレス「ＰＡ３」とを加算したものを、最終的な物理アドレス１０２として取得する。そしてこの物理アドレス１０２を先頭アドレスとする読み出し単位の領域からデータを読み出す。ホストユニット１２は、ＬＢＡの下位ビットを変化させることにより、粗い粒度の書き込み単位のうちの任意の部分を読み出すことができる。
【００３４】
第２アドレス空間で定義される領域に格納されるデータは、移動などにより先頭アドレスは低頻度で変化するものの、書き込み単位の内部におけるデータ構成は変化しないため、ホストユニット１２は、下位ビットを含め同じＬＢＡを示せば、常に同じデータを読み出すことができる。なおフラッシュメモリ２０の構成として、チャネル数＝４、チップセレクト数＝１、ブロックサイズ＝４ＭｉＢ、ページサイズ＝１６ＫｉＢ、ＬＵＮ（Logical Unit Number）＝１、プレーン数＝２とすると、物理アドレスＰＡ［３１：０］の各ビットは次のような割り当てとなる。
【００３５】
オフセット［１３：０］＝｛ＰＡ［４：０］，９’ｂ０｝
チャネル［１：０］＝ＰＡ［６：５］
プレーン＝ＰＡ［７］
ブロック＝ＰＡ［３１：８］／（４＊１０２４／１６）
ページ＝ＰＡ［３１：８］％（４＊１０２４／１６）
【００３６】
次に本実施の形態におけるホストユニット１２について説明する。フラッシュメモリ２０は、それを構成するＮＡＮＤデバイスのそれぞれが実現可能な読み出し時の伝送レートがＨＤＤ１台より大きく、レイテンシはＨＤＤの１／１０以下である。大容量のＳＳＤは多数のＮＡＮＤデバイスを搭載するため、ＨＤＤと比べて飛躍的に高い伝送レートを実現できる。しかしながら大部分のＳＳＤは、フラッシュコントローラにおけるホストインターフェースがボトルネックとなり、デバイス自体の高い伝送レートを活用しきれない。
【００３７】
一般的にＨＤＤに格納されたデータは、５１２バイトあるいは４０９６バイトごとのブロックに分割され、分散されて記録されている。ファイルシステムは分散したデータを１つの連続データとして見せるためのメタデータを持ち、ファイルの連続領域に対するアクセス命令を、分散された複数のブロックに対するアクセス命令に変換する。アクセス対象のファイル名をＨＤＤの各ブロックに対応するＬＢＡに変換するためのメタデータもＨＤＤに記録されるため、ファイルを読み出すためにはまずメタデータを読み出す必要がある。
【００３８】
メタデータ自体もＨＤＤ内の複数の領域に分散していることがあり得るため、当該メタデータを読み出すためにさらに上位のメタデータを読み出すなど、メタデータの階層化によりＨＤＤに対して小さなデータアクセスが頻発する可能性がある。その間、アクセス先のデータが格納されている領域の論理ブロックアドレスを取得できないため、ＣＰＵは次の読み出し要求を発行できない。このようなデータアクセス手順をＳＳＤにそのまま適用すると、複数のＮＡＮＤデバイスへの並列アクセスによる高い伝送レートも実現できない。
【００３９】
また一般的なＨＤＤは、暗号化や改ざん防止機能を持たないため、ホストＣＰＵが暗号化や改ざんチェックを行う必要がある。暗号化および改ざんチェックはＢＩＯＳレベルでなされることもあればファイルシステムレベルでなされることもあるが、いずれの場合でもＣＰＵが処理するため、ＳＳＤの高い伝送レートに対し当該処理がボトルネックになり得る。アクセラレータを用いてこれらの処理の負荷を分散させることも考えられるが、そのためには読み出したファイルを処理単位に分割したりそれに応じた多数の処理要求を発行したりする必要がありＣＰＵの処理の負荷軽減には繋がりにくい。
【００４０】
さらにそのような多数の処理要求に対し完了を通知する割り込みが多数、発生することにより、ＣＰＵの処理が滞ることもあり得る。また、ファイルシステムにはデータ圧縮をサポートするものがある。この場合、ファイルシステムはファイル書き込み時にデータ圧縮を行い、ファイル読み出し時にデータ伸張を行う。このときデータ格納先のインターフェース速度が遅い場合は、データ量が減ることで実効伝送レートが向上することもあるが、ＳＳＤの高い伝送レートに対してはデータ圧縮／伸張処理がボトルネックになり得る。
【００４１】
このようにＮＡＮＤフラッシュデバイス単体でみると飛躍的に向上する伝送レートも、ＨＤＤのために設計されたシステムに組み込むことにより生じる様々なボトルネックにより、それを活かしきれないことが多い。これらの様々なボトルネックを緩和するため、本実施の形態では、従来のファイルシステムに加えて高速アクセス用のソフトウェアスタックを設ける。従来のファイルシステムは、様々なストレージデバイスやネットワークファイルシステムに対応するために仮想ファイルシステムを介してアクセスされる。そのため上述のとおりメタデータが複数の階層にわたって構成され、目的とするファイルを読み出すまでに何度もメタデータを読み出す場合があった。
【００４２】
本実施の形態では、フラッシュメモリに特化した高速アクセス用のソフトウェアスタックを設けることによりメタデータを単純化する。さらに本実施の形態では、従来のＣＰＵに加え、当該ソフトウェアスタックを主に実行・制御する補助プロセッサを設け、暗号化／復号、改ざんチェック、データ伸張のためのハードウェアアクセラレータの制御についても当該補助プロセッサが担うことにより処理を分散させる。またフラッシュメモリにおけるデータ読み出しの単位を拡張し、かつ統一することにより効率的な読み出し処理を実現する。
【００４３】
図４は、本実施の形態の情報処理装置の内部構成を示している。なお同図は、図１で示した情報処理装置１０の内部構成のうち、ホストユニット１２の構成を詳細に示したものである。したがってフラッシュメモリ２０、フラッシュコントローラ１８、システムメモリ１４は図１で示したのと同様でよい。ただしフラッシュコントローラ１８がＬＢＡを物理アドレスに変換するためのアドレス変換テーブルは、上述のように粒度の異なる複数のアドレス空間で構成されてもよいし統一した粒度としてもよい。
【００４４】
ホストユニット１２は、メインＣＰＵ３０、サブＣＰＵ３２、メモリコントローラ３４がコヒーレントバス３６で相互に接続された構成を有する。コヒーレントバス３６にはさらに、ＩＯコントローラ４０およびアクセラレータ４２が接続されたＩＯバス３８が接続される。メインＣＰＵ３０はフラッシュメモリ２０に格納されたプログラムやデータをシステムメモリ１４にロードし、それを用いて情報処理を行う。
【００４５】
サブＣＰＵ３２は上述のように、フラッシュメモリ２０に対するデータアクセスのための処理を主に担う補助プロセッサである。サブＣＰＵ３２はいわゆるエンベデッド・プロセッサに用いられるような、演算性能はメインＣＰＵ３０には劣るがチップ面積が小さいプロセッサコアでよい。メインＣＰＵ３０とサブＣＰＵ３２の命令セットアーキテクチャやオペレーティングシステムは同じである必要はないが、メインＣＰＵ３０とサブＣＰＵ３２でシステムメモリ１４に格納されたデータを共有できるように、両者はコヒーレントバス３６で接続され、ページサイズも共通とする。
【００４６】
サブＣＰＵ３２は、メインＣＰＵ３０から発行されたファイルの読み出し要求を、所定サイズのデータに対する読み出し要求に分割し、システムメモリ１４に格納する。このように本実施の形態では、メインＣＰＵ３０以外のハードウェアがフラッシュメモリ２０に対するデータアクセスの主たる部分を遂行するとともに、ファイルへのアクセス要求の発行直後に読み出し単位を細かくする。これにより複数のＮＡＮＤデバイスへの並列アクセスを可能にし、高い伝送レートを実現する。また読み出されたデータの内蔵ＳＲＡＭへのバッファや、暗号化、改ざんチェックなどアクセラレータがなす処理と、データサイズの面で親和性を高くし、途中で処理が滞らないようにする。
【００４７】
ＩＯバス３８には、暗号処理、データ改ざんチェック、データ伸張を行うアクセラレータ４２が搭載される。それらはシステムメモリ１４に格納されたデータを図示しないＤＭＡＣにより読み出し、復号、改ざんチェック、データ伸張を施して、再びＤＭＡＣによりシステムメモリ１４に格納する。フラッシュコントローラ１８は、ホストユニット１２が発行したデータアクセスに係る命令をシステムメモリ１４より読み出し、フラッシュメモリ２０に対する読み出し／書き込み処理を行う。
【００４８】
フラッシュコントローラ１８は、フラッシュメモリ２０から読み出したデータを一旦、内蔵するＳＲＡＭ２４に格納したうえＥＣＣチェックを施した後、システムメモリ１４に転送する。ホストユニット１２のメモリコントローラ３４およびＩＯコントローラ４０は、それぞれシステムメモリ１４とフラッシュコントローラ１８に対する一般的なインターフェース機能を有する。
【００４９】
図５は本実施の形態におけるソフトウェアスタックの構成を示している。一般的な技術では、最上層のアプリケーション５０からコマンドが発行されると、システムコールにより仮想ファイルシステム４８の処理がなされる。これにより、ネットワークファイルシステムやディスクファイルシステムといったローカルファイルシステム４６が呼び出され、それぞれに対応するデバイスドライバ４４へのアクセスが実現される。つまり仮想ファイルシステム４８は、様々なデバイスに対応するローカルファイルシステム４６を、アプリケーション５０において共通の方法で扱えるようにするための機能を提供する抽象化レイヤである。
【００５０】
仮想ファイルシステム４８はメタデータを構成するディレクトリエントリ情報を管理し、ファイル名やパスを解釈してデータが各デバイスのどこにあるのかを計算する。この際、ディレクトリーツリーの検索、排他制御、キャッシュ管理など複雑な処理を伴うため、例えば小さなファイルを大量にオープンするときなどには特に処理が滞りやすい。そこで本実施の形態では、仮想ファイルシステム４８と別に、ファイルアーカイブ５２と呼ぶ層を定義する。アプリケーション５０は、ファイルアーカイブ固有のＡＰＩ（Application Programming Interface）を介してファイルにアクセスする。
【００５１】
ファイルアーカイブ５２は、フラッシュメモリ２０を動作させるＮＡＮＤフラッシュドライバやアクセラレータ４２を動作させるアクセラレータドライバとアプリケーション５０とのインターフェースであり、アプリケーションからのアクセス要求を直接、それらのドライバに通達する。これにより、ファイルに対応するデータ格納領域の取得処理を単純化する。また細かい単位に分割したアクセス要求を円滑に並列処理できるように、対象となるデータは特有の形式でフラッシュメモリ２０に格納しておく。
【００５２】
具体的には、ファイルアーカイブ５２を介してアクセスするファイルは、あらかじめ６４ＫｉＢなどの固定長のブロックに分割して圧縮したうえで格納する。またこれらのファイルを読み出し専用とすることにより、アプリケーション５０の複数のプロセスが同時にファイルアクセスを行っても整合性が保たれるようにする。これにより同期処理をせずとも複数のファイルアクセスを並列に処理でき、圧縮によるデータサイズの縮小との相乗効果でより高い伝送レートを実現できる。
【００５３】
例えば上述のゲームプログラムのように繰り返し参照のみされるファイルは、ファイルアーカイブによる処理対象とするのに好適である。このように、ファイルアーカイブ５２の処理対象とするか否かは、データの特性に応じて適宜決定する。図６は、ファイルアーカイブ５２およびフラッシュコントローラ１８が、処理対象のファイルデータをフラッシュメモリ２０に格納する手順を模式的に示している。この段階でのファイルアーカイブの実行主体はメインＣＰＵ３０、あるいはサブＣＰＵ３２である。まずファイルアーカイブ５２は処理対象とするファイル１１２をフラッシュメモリ２０の連続領域に書き込む。
【００５４】
同図では１つのファイル１１２のみを示しているが、実際には複数のファイルをまとめて連続領域に格納する。例えば光ディスクなどから読み出した複数のプログラムファイルを、１２８ＭｉＢなどの粗い粒度で連続領域に書き込むように書き込み要求を発行する。実際の書き込み処理はフラッシュコントローラ１８が行う。ここでファイルアーカイブ５２は、ファイル名からその格納先の領域の論理アドレスが直接引けるようにハッシュリストを生成する。すなわちファイル名から所定のハッシュ関数を用いて固定長のハッシュ値を生成し、当該ファイルの論理アドレスを示すエントリをハッシュ値でソートしてハッシュリストを生成する。ただしアドレス検索の機構をこれに限定する主旨ではない。
【００５５】
次にファイルアーカイブ５２は、そのようにしてフラッシュメモリ２０の連続領域に格納した対象ファイル１１２を所定サイズのブロックに分割する（Ｓ１０）。例えば１６ＭｉＢのサイズのファイル１１２を６４ＫｉＢ単位で分割することにより、２５６個のブロック群１１４が形成される。さらにファイルアーカイブ５２は、当該ブロックごとに圧縮処理を施し、圧縮後のブロック群からなるデータ１１６をフラッシュメモリ２０の別の領域に格納するようにフラッシュコントローラ１８に要求する（Ｓ１２）。この場合も１２８ＭｉＢなどの粗い粒度で連続領域に書き込むようにする。
【００５６】
フラッシュコントローラ１８は当該格納処理の実施とともに、圧縮後のデータの論理アドレスと実際のデータが格納されている領域の物理アドレスとを対応づけるアドレス変換テーブルを生成する。圧縮後のデータを粗い粒度で論理アドレスと対応づけておくことにより、図２で示した第２アドレス空間が定義され、アドレス変換テーブル６４のデータサイズを小さくできる。一方、ファイルアーカイブ５２は、ブロックの圧縮前後の論理アドレスを対応づける圧縮テーブルを生成する。
【００５７】
図７は、ファイルアーカイブを用いて要求されたファイルへアクセスするまでの処理手順を模式的に示している。まずアプリケーションを処理するメインＣＰＵ３０は、その過程においてファイル読み出しの必要が生じたとき、当該ファイル名を指定してファイルアーカイブのＡＰＩを呼び出す。図では「/map/001/dat01.bin」なるパスとファイル名を指定している。当該ＡＰＩにより、メインＣＰＵ３０は指定されたファイルに対応する論理アドレスを、上述のハッシュリスト６０を利用して取得する。ハッシュリスト６０はあらかじめフラッシュメモリ２０からシステムメモリ１４にロードしておく。
【００５８】
そしてアプリケーションおいて指定されたファイル名に基づき、ハッシュリストを作成したときと同じハッシュ関数を用いてハッシュ値を導出し（Ｓ２０）、ハッシュリスト６０を二分探索するなどして対応する論理アドレスを取得する（Ｓ２２）。取得した論理アドレスをサブＣＰＵ３２に通知したら、サブＣＰＵ３２が処理を引き継ぐことにより、メインＣＰＵ３０はファイルアーカイブ５２の処理から一旦、開放される。サブＣＰＵ３２は、システムメモリ１４にロードしておいた上述の圧縮テーブル６２を参照し、通知されたファイルの論理アドレスから、ファイルを分割してなる複数のブロックの圧縮後の論理アドレスを取得する（Ｓ２４、Ｓ２６）。
【００５９】
そしてサブＣＰＵ３２は、圧縮後のブロックごとに、取得した論理アドレスを上述のＬＢＡの形式として指定した読み出し要求を生成してフラッシュコントローラ１８に発行する（Ｓ２８）。すなわちサブＣＰＵ３２は、メインＣＰＵ３０が１つのファイルについて発行した読み出し要求を、ブロック単位の複数の読み出し要求に変換する。上述の１６ＭｉＢのファイルの場合、６４ＫｉＢ単位の読み出し要求が２５６個発行されることになる。なおサブＣＰＵ３２は読み出し要求時に、読み出されたデータの格納領域をシステムメモリ１４のカーネルエリアに確保しておく。
【００６０】
これに応じてフラッシュコントローラ１８は、図２で説明したのと同様に、アドレス変換テーブル６４を用いてＬＢＡを物理アドレスに変換し、フラッシュメモリ２０から該当アドレスのデータを取得する（Ｓ３０）。アドレス変換に際してフラッシュコントローラ１８は、ファイルアーカイブを要求元とする読み出し要求については、上述のとおりＬＢＡの上位ビットをインデックスとしてアドレス変換テーブル６４を参照し、それに対応づけられた物理アドレスにＬＢＡの下位ビットを加算することにより、要求されたブロックごとの物理アドレスを取得する。
【００６１】
図８は、ファイルアーカイブを用いて要求されたファイルの読み出しを完了するまでの処理手順を模式的に示している。まずフラッシュコントローラ１８は、図７で説明したようにしてフラッシュメモリ２０から要求されたデータを読み出し、内蔵するＳＲＡＭ２４に展開する（Ｓ４０）。このデータは、元のファイルをブロック分割して圧縮した単位であり、ＳＲＡＭ２４に十分格納できるサイズを有する。そしてフラッシュコントローラ１８は、当該単位のデータにＥＣＣチェックを施す（Ｓ４２）。
【００６２】
ＥＣＣチェックをパスした場合、サブＣＰＵ３２が前もって確保しておいたシステムメモリ１４内のカーネルエリア７０に、図示しないＤＭＡＣ等によって当該データを格納するとともにサブＣＰＵ３２にその旨を通知する（Ｓ４４）。なおＥＣＣチェックでエラーが検出された場合は、フラッシュコントローラ１８内で再送要求を生成することにより再度、データを読み出す。フラッシュコントローラ１８は、サブＣＰＵ３２から発行された細かい単位の読み出し要求に対する処理が全て完了するまで、当該処理を繰り返す。
【００６３】
サブＣＰＵ３２は、フラッシュコントローラ１８からの通知に応じて、カーネルエリア７０に読み出されたデータに対する、改ざんチェック、復号、伸張の処理要求をアクセラレータ４２に発行する（Ｓ４６）。アクセラレータ４２は、格納されているデータごとにそれらの処理を実行し、処理後のデータ、すなわちファイルを構成するブロックのデータをシステムメモリ１４のユーザバッファ７２に格納しサブＣＰＵ３２に通知する（Ｓ４８）。
【００６４】
サブＣＰＵ３２は、要求されたファイルを構成するブロックのデータが全て揃った時点で、メインＣＰＵ３０に割り込みまたはプロセス間通信を用いて、読み出しの完了を通知する。これに応じてメインＣＰＵ３０は、ファイルアーカイブのＡＰＩ処理に伴う事後処理を適宜行い、アプリケーションに処理を戻す。本実施の形態では図５で示すように、ファイルアーカイブ５２と仮想ファイルシステム４８が共存するファイルスタックを形成する。上述のようにフラッシュコントローラ１８は、ファイルアーカイブ５２からの要求に対しては、粗い粒度で書き込みを行う第２アドレス空間によりアドレス変換を行う。
【００６５】
一方、仮想ファイルシステム４８からの要求に対しては、それより細かい粒度で書き込み行う第１アドレス空間によりアドレス変換を行うようにしてもよい。この場合、図２で示したように、各アドレス空間に対応する２つのアドレス変換テーブルをＳＲＡＭ２４に個別に格納し、要求元がファイルアーカイブ５２か仮想ファイルシステム４８かに応じて参照先を切り替える。要求元は、アクセス要求に含まれるＬＢＡの上位ビットにより特定できる。
【００６６】
ファイルアーカイブ５２による読み出し要求に対し高い伝送レートを保障するため、当該要求に対する処理を、仮想ファイルシステム４８による読み出し／書き込み要求や、ファイルアーカイブ５２による圧縮後のデータの書き込み要求に対する処理より高い優先度で行ってもよい。優先制御や伝送レート管理は、フラッシュコントローラ１８に要求を発行するサブＣＰＵ３２、または要求を受けたフラッシュコントローラ１８が行う。ファイルアーカイブ５２からの要求によりデータが読み出されている期間は、別の読み出し要求を禁止することにより、読み出されるべきデータが消去されることがなくなり、エラーが発生しない限りはガベージコレクションによるデータ消去も禁止できる。
【００６７】
次に上記構成による情報処理装置１０の性能について検討する。所望の伝送レートを実現するために許容される処理時間は次の表のようになる。例えば１要求当たり４ＫｉＢのデータ粒度（処理単位）で１ＧＢ／秒の伝送レートを実現するには、１要求当たり４．１μ秒で処理を完了する必要がある。処理完了までの時間がそれより増えれば伝送レートは当然、低下していく。
【００６８】
【表１】
2017068804.tif 000003
【００６９】
これまで述べたように本実施の形態においてメインＣＰＵ３０は以下の処理を行う。
１．ファイル名からのハッシュ値計算
２．ハッシュリストの検索
３．サブＣＰＵ３２に対する要求発行
【００７０】
ファイルサイズが４ＫｉＢ程度と小さい場合、１０ＧＢ／秒の伝送レートを実現するには１ファイル当たり０．４μ秒以内で処理を完了させる必要がある。そのような細かい単位で読み出し要求を頻発させた場合、並列化の効果が小さいうえ、サブＣＰＵ３２、フラッシュコントローラ１８、フラッシュメモリ２０における伝送レートの影響を受け易くなるため、容易にレイテンシが増加しメインＣＰＵ３０での伝送レートが低下することが考えられる。したがって、このような小さいサイズでのデータアクセス要求が１ｍ秒に１回程度の頻度の場合、複数のファイルを１つにまとめ、一度に１０ＭｉＢ程度のデータアクセスを要求することにより、高い頑健性で１０ＧＢ／秒の伝送レートを実現できる。
【００７１】
本実施の形態においてサブＣＰＵ３２は以下の処理を行う。
１．メインＣＰＵ３０が発行した要求を固定長のデータブロックごとに分割する
２．圧縮テーブルを参照し圧縮後のデータが格納された論理アドレスを取得する
３．フラッシュコントローラ１８に読み出し要求を発行する
４．読み出されたデータに対する改ざんチェック等の処理をアクセラレータに要求する
５．元のファイルを構成するブロックの準備ができた時点でメインＣＰＵ３０へ通知する
【００７２】
サブＣＰＵ３２は常に固定長のデータを処理単位とする。例えば処理単位を６４ＫｉＢとすると、１０ＧＢ／秒の伝送レートを実現するには、１要求当たり６．６μ秒で処理を完了させる必要がある。例えばメインＣＰＵ３０から１６ＭｉＢのファイルに対する読み出し要求が発行された場合、サブＣＰＵ３２は上述のとおり、それを６４ＫｉＢごとに分割して２５６個の読み出し要求を発行する。このとき６．６μ秒で１つずつ要求を処理するのでなく、複数の要求をまとめて処理する。
【００７３】
本実施の形態では、フラッシュコントローラ１８や各種アクセラレータに対するコマンドの発行と完了通知の受領、といった単純化された処理のみを並列に高頻度で行える。そのため、例えば３２個程度の要求をまとめて処理し２１１μ秒以内で完了させることも可能となり、結果として１０ＧＢ／秒の伝送レートを実現できる。実現しなければならない伝送レートによっては、例えばフラッシュコントローラ１８に対する要求発行や完了通知の受領などの処理を、さらに複数のＣＰＵコアに分散させてもよい。
【００７４】
本実施の形態においてフラッシュコントローラ１８は以下の処理を行う。
１．サブＣＰＵ３２が発行した要求を読み出す
２．アドレス変換テーブルを参照しＬＢＡを物理アドレスへ変換する
３．フラッシュメモリ２０の該当領域からデータを読み出す
４．データをシステムメモリ１４に格納しその旨をサブＣＰＵ３２に通知する
【００７５】
高速処理が要求されるアドレス変換において、参照すべきアドレス変換テーブルは内蔵するＳＲＡＭ２４に格納されている。サブＣＰＵ３２からの要求が６４ＫｉＢ単位であれば、１０ＧＢ／秒の伝送レートを実現するには１要求当たり６．６μ秒で処理を完了させる必要がある。ＩＯＰＳ（Input Output Per Second）換算すると１５１，５１５ＩＯＰＳとなるため、サブＣＰＵ３２と同様に、複数のプロセッサコアに処理を分散させることが望ましい。またフラッシュコントローラ１８は上述のように、フラッシュメモリ２０に対し複数のインターフェースチャネルを持ち、読み出し要求はさらにチャネルごとに分割される。例えば６４ＫｉＢのデータの読み出し要求が１６ＫｉＢの処理単位に分割されると、４倍のＩＯＰＳが必要となるが、それらは複数のチャネルで並列処理されるため伝送レートに対する影響は大きくない。
【００７６】
本実施の形態においてアクセラレータ４２は以下の処理を行う。
１．サブＣＰＵ３２からの処理依頼
２．システムメモリ１４からのデータ読み出し
３．改ざんチェック、復号、伸張処理
４．処理後のデータのシステムメモリ１４への格納およびサブＣＰＵ３２への通知
【００７７】
平均１０ＧＢ／秒以上のスループットで動作させる場合、各種処理間のオーバーヘッドなども考慮すると、アクセラレータにはそれ以上のピークスループットが必要になる。１２８ビット／サイクル、１ＧＨｚで動作する回路であれば、ピークスループットは１６ＧＢ／秒と十分な値となる。一方、１２８ビットの処理に１６サイクルを要するような回路であれば、アクセラレータを１６並列させるなどの対策を講じてもよい。
【００７８】
以上述べた本実施の形態によれば、フラッシュメモリに対する書き込みアクセスの粒度を、ページ単位など従来技術での書き込み粒度より大きくする。これによりアドレス変換テーブル全体を内蔵ＳＲＡＭに格納できる程度のサイズとすることができ、アドレス変換のためにフラッシュメモリへのアクセスを繰り返す必要がなくなる。またフラッシュメモリの容量が大きくなっても、アドレス変換テーブルをキャッシュするために大容量の外付けＤＲＡＭを設ける必要がなくなる。結果として、フラッシュメモリや外付けＤＲＡＭへのアクセスによるレイテンシの増加やスループットの低下を防ぐことができるとともに、製造コストやチップ面積を削減できる。
【００７９】
さらにアドレス変換テーブルを複数のアドレス空間に分割し、それぞれで書き込みアクセスの粒度を異ならせることにより、データの特性に適したアドレス変換テーブルを選択できるようにする。細かい粒度のアドレス空間を定義するアドレス変換テーブルは、その一部をＳＲＡＭにキャッシュする。例えばデータが更新されることのないゲームプログラムなどは粒度を大きくし、更新されることの多いユーザデータなどは粒度を細かくする。これにより、データ更新時には別の領域を新たに確保することが求められるフラッシュメモリの特性を考慮した無駄のない領域割り当てが可能となり、上述した、粒度を大きくすることによる効果と両立できる。
【００８０】
またフラッシュメモリへのアクセス要求を担うプロセッサを、メインのプロセッサとは別に設ける。このプロセッサは、ファイルごとのアクセス要求を細かい単位に分割し、以後の処理はその単位でなるべく並列になされるようにする。これに対応するように、フラッシュメモリにはファイルを分割してなるブロックごとに圧縮したデータを格納しておく。これらの構成により、１つのアクセス要求に対する処理速度が実質的に増加する。また読み出されるデータもサイズが小さくなるため、フラッシュコントローラに内蔵したＳＲＡＭでのバッファが可能となり、外付けＤＲＡＭの介在が必要なくなる。
【００８１】
さらにソフトウェアスタックにおいて、従来のファイルシステムに加えて、アプリケーションとＳＳＤとを直接つなぐインターフェース層を設けることにより、ファイル名からアドレス取得までの処理を単純化する。また読み出しアクセスの要求元が、当該インターフェース層か従来のファイルシステムか、により処理に優先順位をつけ、前者をより優先させるとともに、読み出し単位を従来より大きくすることにより読み出し処理を効率化する。これにより、プログラムファイルのように迅速な読み出しが求められるデータの読み出し処理を、ユーザデータのような一般的なファイルの読み出し処理と差別化できる。
【００８２】
ファイル名からアドレス取得までに必要なメタデータを単純化することにより、階層化されたメタデータを逐次辿っていく必要がなく、またメタデータ自体のデータサイズを小さくできるためシステムメモリに全体を格納することも可能である。結果として、アドレス取得のためのメモリアクセス処理の負荷が大幅に軽減される。以上の構成により、従来の様々なストレージに対するデータアクセス手順と共存させつつ、フラッシュメモリの高い伝送レートを十分に活かした高速なデータアクセスが可能となる。
【００８３】
以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【符号の説明】
【００８４】
１０  情報処理装置、  １２  ホストユニット、  １４  システムメモリ、  １６  外付けＤＲＡＭ、  １８  フラッシュコントローラ、  ２０  フラッシュメモリ、  ２２  ホストコントローラ、  ２４  ＳＲＡＭ、  ２６  ＤＲＡＭコントローラ、  ２８  メモリコントローラ、  ３０  メインＣＰＵ、  ３２  サブＣＰＵ、  ３４  メモリコントローラ、  ３６  コヒーレントバス、  ４０  ＩＯコントローラ、  ４２  アクセラレータ。
【図１】
2017068804.tif 000004
【図２】
2017068804.tif 000005
【図３】
2017068804.tif 000006
【図４】
2017068804.tif 000007
【図５】
2017068804.tif 000008
【図６】
2017068804.tif 000009
【図７】
2017068804.tif 000010
【図８】
2017068804.tif 000011