図1は、本実施の形態の情報処理装置の内部構成を示している。ここで例示する情報処理装置は、携帯ゲーム機、パーソナルコンピュータ、携帯電話、タブレット端末、PDAなど一般的な情報機器のいずれでもよい。情報処理装置10は、CPUを含むホストユニット12、システムメモリ14、NAND型フラッシュメモリ20(以後、単にフラッシュメモリ20と呼ぶ)、フラッシュコントローラ18を含む。
ホストユニット12は、フラッシュメモリ20に格納されたプログラムやデータをシステムメモリ14にロードし、それを用いて情報処理を行う。またアプリケーションプログラムやデータを、図示しない記録媒体駆動部において駆動された記録媒体から読み出したり通信部によりネットワーク接続されたサーバからダウンロードしたりしてフラッシュメモリ20に格納する。この際、ホストユニット12はフラッシュコントローラ18に、フラッシュメモリ20に対するアクセス要求を発行し、フラッシュコントローラ18はそれに応じてフラッシュメモリ20に対し読み出し/書き込み処理を実施する。
フラッシュメモリ20には複数のNAND型フラッシュメモリが接続されており、データは図示するように複数のチャネル(図では「ch0」〜「ch3」の4チャネル)に分散されて格納される。フラッシュコントローラ18は、ホストユニット12とのインターフェース機能を有するホストコントローラ22、フラッシュメモリ20とのインターフェース機能を有するメモリコントローラ28、およびSRAM(Static Random Access Memory)24を含む。ホストコントローラ22およびメモリコントローラ28の動作は、ハードウェア的には各種回路や装置で実現でき、ソフトウェア的には、内部に保持するプログラムで実現される。したがってハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
ホストユニット12は、情報処理の進捗に応じてフラッシュメモリ20に対するアクセス要求を発生させ、それをシステムメモリ14に格納する。当該アクセス要求にはアクセス先の論理アドレス(LBA:Logical Block Address)が含まれる。フラッシュコントローラ18のホストコントローラ22は、システムメモリ14に格納されたアクセス要求を読み出し、LBAをフラッシュメモリ20の物理アドレスに変換する。この際、必要となるアドレス変換テーブルは、元々フラッシュメモリ20に格納されていたものの少なくとも一部をSRAM24に展開しておく。
ホストコントローラ22は、当該アドレス変換テーブルを参照してLBAに基づき取得した物理アドレスをメモリコントローラ28に供給する。メモリコントローラ28は当該物理アドレスに基づきフラッシュメモリ20の該当する領域にアクセスすることによりデータを読み出したり書き込んだりする。一般に、フラッシュメモリ20に対するデータ読み出し/書き込みは、4096バイト等のアクセス単位でなされる。
またデータを書き換える際は、フラッシュメモリ20の対象領域のデータ消去を伴うが、このときは数MiB(1MiB=1020バイト)のブロック単位でなされる。フラッシュメモリ20はデータ消去を繰り返すほど摩耗されるため、消去回数を抑えるための工夫が必要となる。具体的には、データの書き換えが発生した際、できるだけ書き換え前のデータの消去を行わず、別の領域に書き換え後のデータを格納したうえ当該領域を指すようにアドレス変換テーブルを更新する。一方で、書き換えが頻発しても新規に割り当てる領域が枯渇しないよう、定期的に使用済みの領域を消去する。
上記のように4096バイトのアクセス単位でデータの読み出し/書き込みを行う場合、アドレス変換テーブルの各エントリのデータサイズを4バイトとすると、アドレス変換テーブル全体では、フラッシュメモリ20の全容量に対し0.1%のデータサイズを有することになる。例えばフラッシュメモリ20の全容量が1テラバイトであれば、アドレス変換テーブルは1ギガバイトとなる。フラッシュコントローラ18は、ホストユニット12からデータアクセスが要求される都度、指定されたLBAを物理アドレスに変換するために、まずアドレス変換テーブルを参照する必要がある。
参照対象のアドレス変換テーブルをフラッシュメモリ20に格納した場合、アドレス変換のためにフラッシュメモリ20へアクセスする頻度が増大し、処理のスループットの低下やレイテンシの増大につながる。アドレス変換テーブルの多くの部分を外付けDRAMなどにキャッシュしておくことにより効率化は図られるが、フラッシュメモリ20が大容量化するほど大容量のDRAMが必要となる。またDRAMのデータ伝送レートが支配的となり、やはりスループットがレイテンシの十分な改善が見込めないこともある。
そこで本実施の形態では、少なくとも一部のデータについては、書き込み要求に対するデータの処理単位、すなわち粒度を大きくすることによりアドレス変換テーブルのサイズを抑える。例えば書き込みの粒度を128MiBとし、アドレス変換テーブルの各エントリのデータサイズを上述同様、4バイトとすると、アドレス変換テーブル全体のデータサイズは、フラッシュメモリ20の容量の1/225倍となる。例えば32KiB(32×210バイト)のアドレス変換テーブルにより1TiB(240バイト)の領域を表すことができる。
このように十分小さなサイズのアドレス変換テーブルをフラッシュコントローラ18内部のSRAM24に格納することにより、外付けDRAMの介在なくアドレス変換が行える。書き込みの粒度を粗くする態様は、光ディスクやネットワークからロードしてフラッシュメモリ20に格納し、繰り返し参照のみされるゲームプログラムなどにおいては特に有効である。これは、格納済みのデータに対する書き換えが発生しない結果、書き換え後のデータを格納するために新たな領域をその単位で確保する必要がないことによる。
なおこのような粗い粒度で書き込みを行っても、当該書き込み単位内ではデータの連続性が保たれているため、読み出し時のデータは、より細かい単位でランダムに指定できる。一方、セーブデータなど書き換えが必要なデータのためには、書き込みについても細かい粒度で行えるようにすることが望ましい。そのため、データの特性に応じて書き込みの粒度が異なる複数の変換テーブルを定義する。粒度の細かいアドレス変換テーブルは上述のとおりデータサイズが大きくなるため、その一部をSRAM24にキャッシュする。
図2は、フラッシュメモリ20に格納されたデータとアドレス変換テーブルの構成との関係を模式的に示している。アドレス変換テーブルには粒度の異なる複数のアドレス空間が定義され、図示する例では粒度の細かい第1アドレス空間と粒度の粗い第2アドレス空間とからなっている。ただし粒度を3つ以上としてもよい。同図では、ホストユニット12が指定するLBAを「(アドレス空間番号)−(空間内でのアドレス)」なる形式で表している。例えば「1−1」は第1アドレス空間内のアドレス「1」、「2−2」は第2アドレス空間のアドレス「2」を表す。ただしLBAを記述する4バイト等のデータにはそのほかの情報が含まれてよい。
またアドレス変換によって取得される物理アドレスは基本的に、「(チャネル番号)−(アドレス)」あるいは「アドレス」なる形式で表している。一方、フラッシュメモリ20は、格納領域をチャネルごとに縦長の長方形で表している。当該長方形を分割してなる矩形のうち、「T」が記載された矩形はアドレス変換テーブルが格納された領域であり、「1−1」などのLBAが記載された矩形は、それに対応するデータが格納された領域を示す。第1アドレス空間で定義されるデータの書き込み時の粒度は典型的には読み出し時の粒度と等しい、例えば4KiBなどであり、LBAは当該サイズの領域に対し1つ定義する。
一方、第2アドレス空間では、1つのLBAによって、第1アドレス空間で定義される領域より大きい領域をまとめて定義できるようにする。図示する例ではch0〜ch3の4つのチャネルに渡る連続領域としている。このアドレス空間が対象とするデータの書き込みの時の粒度は、例えば128MiBであるが、フラッシュメモリ20とSRAM24の容量に基づくアドレス変換テーブルのサイズの上限などに応じて適宜決定してよい。このデータは情報処理による書き換えはなされないため、基本的にはその格納領域やデータ構成が維持される。
ただしフラッシュメモリ20の経年劣化などによってビットエラーが検出され、データを移動させるときは、新たに当該サイズの連続領域を割り当てる。また消去回数の増加に伴いフラッシュメモリ20のあるブロックが不良となった場合、第2アドレス空間のデータについては、書き込み単位に含まれるその周辺のブロックも割り当て不可となる。これに対し第1アドレス空間で定義されるデータを書き換えたり移動させたりする際は、4KiBなど細かい粒度で新たな領域を割り当てることができる。また粒度が細かいほど、近傍の不良により割り当て不可とされるブロックを少なくできる。
したがって上述のように、データの特性によって書き込み時の粒度を異ならせることにより、アドレス変換テーブルのサイズの縮小とフラッシュメモリ20におけるデータ格納領域の効率性とを両立させることができる。アドレス変換テーブルは、フラッシュメモリ20の「T」の領域に格納されていたものを、第1アドレス空間、第2アドレス空間で別々にSRAM24に読み出しておく。第2アドレス空間のアドレス変換テーブルは上述のようにデータサイズが小さいため、起動時に全てをプリロードしておくことにより常にキャッシュヒットさせることができる。
第1アドレス空間のアドレス変換テーブルは、SRAM24の容量に応じてその一部をキャッシュする。キャッシュ動作の手順については従来技術を適用できる。データの移動や書き換えなどによりSRAM24に格納されたアドレス変換テーブルを更新した場合は、適当なタイミングでフラッシュメモリ20に格納された元のテーブルに書き戻しておく。
ここでホストユニット12が、第1アドレス空間であるLBA=「1−1」を指定して読み出しあるいは書き込みを要求したとする。このときフラッシュコントローラ18は、アドレス変換テーブルを参照し、それに対応づけられた、フラッシュメモリ20の物理アドレス「ch0−C」を取得する。上述のとおり第1アドレス空間では書き込みの単位、ひいては読み出しの単位ごとにLBAが設定される。したがってアドレス変換テーブルに示された物理アドレス「ch0−C」、すなわちチャネル番号ch0のアドレスCを先頭アドレスとする1単位分のデータを読み出す。
書き込み要求の場合は、読み出したデータを適宜更新し、フラッシュメモリ20の別の領域に書き込んだうえアドレス変換テーブルにおける物理アドレスを、当該領域を示すように更新する。一方、ホストユニット12が第2アドレス空間であるLBA=「2−1」を指定して読み出しを要求したら、フラッシュコントローラ18は、アドレス変換テーブルに記述される物理アドレス「A」に基づき、読み出し単位のデータの格納領域を計算によって求める。
図3は第2アドレス空間のデータの格納領域を取得する手法を説明するための図である。第2アドレス空間におけるLBAの上位ビットは、これまで述べたように書き込み単位の領域ごとに一意に与えられた論理アドレスを表す。このアドレスは、図2における「2−1」などに対応する。例えば第2アドレス空間の書き込みアクセス粒度が128MiB(227バイト)、アドレス変換テーブルのサイズが512B(29バイト)、各アドレス空間が1TiB(1040バイト)とすると、LBA32ビットのうちビット31:19を上位ビットとする。
フラッシュコントローラ18は、この上位ビットをインデックスとしてアドレス変換テーブル100を参照し、それに対応づけられた物理アドレス(PA)を取得する。このアドレスは、図2における「A」などに対応し、書き込み単位の領域における先頭物理アドレスを表す。図3ではLBAの上位ビット「index」がアドレス変換テーブル100の「index3」と合致し、それに対応する物理アドレス「PA3」が取得されることを示している。
第1アドレス空間の場合、上述のとおりこの「PA3」を先頭アドレスとする読み出し単位の領域からデータを読み出せばよい。一方、第2アドレス空間の場合、フラッシュコントローラ18は、同図において「offset」と記載されたLBAの下位ビットと、取得した物理アドレス「PA3」とを加算したものを、最終的な物理アドレス102として取得する。そしてこの物理アドレス102を先頭アドレスとする読み出し単位の領域からデータを読み出す。ホストユニット12は、LBAの下位ビットを変化させることにより、粗い粒度の書き込み単位のうちの任意の部分を読み出すことができる。
第2アドレス空間で定義される領域に格納されるデータは、移動などにより先頭アドレスは低頻度で変化するものの、書き込み単位の内部におけるデータ構成は変化しないため、ホストユニット12は、下位ビットを含め同じLBAを示せば、常に同じデータを読み出すことができる。なおフラッシュメモリ20の構成として、チャネル数=4、チップセレクト数=1、ブロックサイズ=4MiB、ページサイズ=16KiB、LUN(Logical Unit Number)=1、プレーン数=2とすると、物理アドレスPA[31:0]の各ビットは次のような割り当てとなる。
オフセット[13:0]={PA[4:0],9’b0}
チャネル[1:0]=PA[6:5]
プレーン=PA[7]
ブロック=PA[31:8]/(4*1024/16)
ページ=PA[31:8]%(4*1024/16)
次に本実施の形態におけるホストユニット12について説明する。フラッシュメモリ20は、それを構成するNANDデバイスのそれぞれが実現可能な読み出し時の伝送レートがHDD1台より大きく、レイテンシはHDDの1/10以下である。大容量のSSDは多数のNANDデバイスを搭載するため、HDDと比べて飛躍的に高い伝送レートを実現できる。しかしながら大部分のSSDは、フラッシュコントローラにおけるホストインターフェースがボトルネックとなり、デバイス自体の高い伝送レートを活用しきれない。
一般的にHDDに格納されたデータは、512バイトあるいは4096バイトごとのブロックに分割され、分散されて記録されている。ファイルシステムは分散したデータを1つの連続データとして見せるためのメタデータを持ち、ファイルの連続領域に対するアクセス命令を、分散された複数のブロックに対するアクセス命令に変換する。アクセス対象のファイル名をHDDの各ブロックに対応するLBAに変換するためのメタデータもHDDに記録されるため、ファイルを読み出すためにはまずメタデータを読み出す必要がある。
メタデータ自体もHDD内の複数の領域に分散していることがあり得るため、当該メタデータを読み出すためにさらに上位のメタデータを読み出すなど、メタデータの階層化によりHDDに対して小さなデータアクセスが頻発する可能性がある。その間、アクセス先のデータが格納されている領域の論理ブロックアドレスを取得できないため、CPUは次の読み出し要求を発行できない。このようなデータアクセス手順をSSDにそのまま適用すると、複数のNANDデバイスへの並列アクセスによる高い伝送レートも実現できない。
また一般的なHDDは、暗号化や改ざん防止機能を持たないため、ホストCPUが暗号化や改ざんチェックを行う必要がある。暗号化および改ざんチェックはBIOSレベルでなされることもあればファイルシステムレベルでなされることもあるが、いずれの場合でもCPUが処理するため、SSDの高い伝送レートに対し当該処理がボトルネックになり得る。アクセラレータを用いてこれらの処理の負荷を分散させることも考えられるが、そのためには読み出したファイルを処理単位に分割したりそれに応じた多数の処理要求を発行したりする必要がありCPUの処理の負荷軽減には繋がりにくい。
さらにそのような多数の処理要求に対し完了を通知する割り込みが多数、発生することにより、CPUの処理が滞ることもあり得る。また、ファイルシステムにはデータ圧縮をサポートするものがある。この場合、ファイルシステムはファイル書き込み時にデータ圧縮を行い、ファイル読み出し時にデータ伸張を行う。このときデータ格納先のインターフェース速度が遅い場合は、データ量が減ることで実効伝送レートが向上することもあるが、SSDの高い伝送レートに対してはデータ圧縮/伸張処理がボトルネックになり得る。
このようにNANDフラッシュデバイス単体でみると飛躍的に向上する伝送レートも、HDDのために設計されたシステムに組み込むことにより生じる様々なボトルネックにより、それを活かしきれないことが多い。これらの様々なボトルネックを緩和するため、本実施の形態では、従来のファイルシステムに加えて高速アクセス用のソフトウェアスタックを設ける。従来のファイルシステムは、様々なストレージデバイスやネットワークファイルシステムに対応するために仮想ファイルシステムを介してアクセスされる。そのため上述のとおりメタデータが複数の階層にわたって構成され、目的とするファイルを読み出すまでに何度もメタデータを読み出す場合があった。
本実施の形態では、フラッシュメモリに特化した高速アクセス用のソフトウェアスタックを設けることによりメタデータを単純化する。さらに本実施の形態では、従来のCPUに加え、当該ソフトウェアスタックを主に実行・制御する補助プロセッサを設け、暗号化/復号、改ざんチェック、データ伸張のためのハードウェアアクセラレータの制御についても当該補助プロセッサが担うことにより処理を分散させる。またフラッシュメモリにおけるデータ読み出しの単位を拡張し、かつ統一することにより効率的な読み出し処理を実現する。
図4は、本実施の形態の情報処理装置の内部構成を示している。なお同図は、図1で示した情報処理装置10の内部構成のうち、ホストユニット12の構成を詳細に示したものである。したがってフラッシュメモリ20、フラッシュコントローラ18、システムメモリ14は図1で示したのと同様でよい。ただしフラッシュコントローラ18がLBAを物理アドレスに変換するためのアドレス変換テーブルは、上述のように粒度の異なる複数のアドレス空間で構成されてもよいし統一した粒度としてもよい。
ホストユニット12は、メインCPU30、サブCPU32、メモリコントローラ34がコヒーレントバス36で相互に接続された構成を有する。コヒーレントバス36にはさらに、IOコントローラ40およびアクセラレータ42が接続されたIOバス38が接続される。メインCPU30はフラッシュメモリ20に格納されたプログラムやデータをシステムメモリ14にロードし、それを用いて情報処理を行う。
サブCPU32は上述のように、フラッシュメモリ20に対するデータアクセスのための処理を主に担う補助プロセッサである。サブCPU32はいわゆるエンベデッド・プロセッサに用いられるような、演算性能はメインCPU30には劣るがチップ面積が小さいプロセッサコアでよい。メインCPU30とサブCPU32の命令セットアーキテクチャやオペレーティングシステムは同じである必要はないが、メインCPU30とサブCPU32でシステムメモリ14に格納されたデータを共有できるように、両者はコヒーレントバス36で接続され、ページサイズも共通とする。
サブCPU32は、メインCPU30から発行されたファイルの読み出し要求を、所定サイズのデータに対する読み出し要求に分割し、システムメモリ14に格納する。このように本実施の形態では、メインCPU30以外のハードウェアがフラッシュメモリ20に対するデータアクセスの主たる部分を遂行するとともに、ファイルへのアクセス要求の発行直後に読み出し単位を細かくする。これにより複数のNANDデバイスへの並列アクセスを可能にし、高い伝送レートを実現する。また読み出されたデータの内蔵SRAMへのバッファや、暗号化、改ざんチェックなどアクセラレータがなす処理と、データサイズの面で親和性を高くし、途中で処理が滞らないようにする。
IOバス38には、暗号処理、データ改ざんチェック、データ伸張を行うアクセラレータ42が搭載される。それらはシステムメモリ14に格納されたデータを図示しないDMACにより読み出し、復号、改ざんチェック、データ伸張を施して、再びDMACによりシステムメモリ14に格納する。フラッシュコントローラ18は、ホストユニット12が発行したデータアクセスに係る命令をシステムメモリ14より読み出し、フラッシュメモリ20に対する読み出し/書き込み処理を行う。
フラッシュコントローラ18は、フラッシュメモリ20から読み出したデータを一旦、内蔵するSRAM24に格納したうえECCチェックを施した後、システムメモリ14に転送する。ホストユニット12のメモリコントローラ34およびIOコントローラ40は、それぞれシステムメモリ14とフラッシュコントローラ18に対する一般的なインターフェース機能を有する。
図5は本実施の形態におけるソフトウェアスタックの構成を示している。一般的な技術では、最上層のアプリケーション50からコマンドが発行されると、システムコールにより仮想ファイルシステム48の処理がなされる。これにより、ネットワークファイルシステムやディスクファイルシステムといったローカルファイルシステム46が呼び出され、それぞれに対応するデバイスドライバ44へのアクセスが実現される。つまり仮想ファイルシステム48は、様々なデバイスに対応するローカルファイルシステム46を、アプリケーション50において共通の方法で扱えるようにするための機能を提供する抽象化レイヤである。
仮想ファイルシステム48はメタデータを構成するディレクトリエントリ情報を管理し、ファイル名やパスを解釈してデータが各デバイスのどこにあるのかを計算する。この際、ディレクトリーツリーの検索、排他制御、キャッシュ管理など複雑な処理を伴うため、例えば小さなファイルを大量にオープンするときなどには特に処理が滞りやすい。そこで本実施の形態では、仮想ファイルシステム48と別に、ファイルアーカイブ52と呼ぶ層を定義する。アプリケーション50は、ファイルアーカイブ固有のAPI(Application Programming Interface)を介してファイルにアクセスする。
ファイルアーカイブ52は、フラッシュメモリ20を動作させるNANDフラッシュドライバやアクセラレータ42を動作させるアクセラレータドライバとアプリケーション50とのインターフェースであり、アプリケーションからのアクセス要求を直接、それらのドライバに通達する。これにより、ファイルに対応するデータ格納領域の取得処理を単純化する。また細かい単位に分割したアクセス要求を円滑に並列処理できるように、対象となるデータは特有の形式でフラッシュメモリ20に格納しておく。
具体的には、ファイルアーカイブ52を介してアクセスするファイルは、あらかじめ64KiBなどの固定長のブロックに分割して圧縮したうえで格納する。またこれらのファイルを読み出し専用とすることにより、アプリケーション50の複数のプロセスが同時にファイルアクセスを行っても整合性が保たれるようにする。これにより同期処理をせずとも複数のファイルアクセスを並列に処理でき、圧縮によるデータサイズの縮小との相乗効果でより高い伝送レートを実現できる。
例えば上述のゲームプログラムのように繰り返し参照のみされるファイルは、ファイルアーカイブによる処理対象とするのに好適である。このように、ファイルアーカイブ52の処理対象とするか否かは、データの特性に応じて適宜決定する。図6は、ファイルアーカイブ52およびフラッシュコントローラ18が、処理対象のファイルデータをフラッシュメモリ20に格納する手順を模式的に示している。この段階でのファイルアーカイブの実行主体はメインCPU30、あるいはサブCPU32である。まずファイルアーカイブ52は処理対象とするファイル112をフラッシュメモリ20の連続領域に書き込む。
同図では1つのファイル112のみを示しているが、実際には複数のファイルをまとめて連続領域に格納する。例えば光ディスクなどから読み出した複数のプログラムファイルを、128MiBなどの粗い粒度で連続領域に書き込むように書き込み要求を発行する。実際の書き込み処理はフラッシュコントローラ18が行う。ここでファイルアーカイブ52は、ファイル名からその格納先の領域の論理アドレスが直接引けるようにハッシュリストを生成する。すなわちファイル名から所定のハッシュ関数を用いて固定長のハッシュ値を生成し、当該ファイルの論理アドレスを示すエントリをハッシュ値でソートしてハッシュリストを生成する。ただしアドレス検索の機構をこれに限定する主旨ではない。
次にファイルアーカイブ52は、そのようにしてフラッシュメモリ20の連続領域に格納した対象ファイル112を所定サイズのブロックに分割する(S10)。例えば16MiBのサイズのファイル112を64KiB単位で分割することにより、256個のブロック群114が形成される。さらにファイルアーカイブ52は、当該ブロックごとに圧縮処理を施し、圧縮後のブロック群からなるデータ116をフラッシュメモリ20の別の領域に格納するようにフラッシュコントローラ18に要求する(S12)。この場合も128MiBなどの粗い粒度で連続領域に書き込むようにする。
フラッシュコントローラ18は当該格納処理の実施とともに、圧縮後のデータの論理アドレスと実際のデータが格納されている領域の物理アドレスとを対応づけるアドレス変換テーブルを生成する。圧縮後のデータを粗い粒度で論理アドレスと対応づけておくことにより、図2で示した第2アドレス空間が定義され、アドレス変換テーブル64のデータサイズを小さくできる。一方、ファイルアーカイブ52は、ブロックの圧縮前後の論理アドレスを対応づける圧縮テーブルを生成する。
図7は、ファイルアーカイブを用いて要求されたファイルへアクセスするまでの処理手順を模式的に示している。まずアプリケーションを処理するメインCPU30は、その過程においてファイル読み出しの必要が生じたとき、当該ファイル名を指定してファイルアーカイブのAPIを呼び出す。図では「/map/001/dat01.bin」なるパスとファイル名を指定している。当該APIにより、メインCPU30は指定されたファイルに対応する論理アドレスを、上述のハッシュリスト60を利用して取得する。ハッシュリスト60はあらかじめフラッシュメモリ20からシステムメモリ14にロードしておく。
そしてアプリケーションおいて指定されたファイル名に基づき、ハッシュリストを作成したときと同じハッシュ関数を用いてハッシュ値を導出し(S20)、ハッシュリスト60を二分探索するなどして対応する論理アドレスを取得する(S22)。取得した論理アドレスをサブCPU32に通知したら、サブCPU32が処理を引き継ぐことにより、メインCPU30はファイルアーカイブ52の処理から一旦、開放される。サブCPU32は、システムメモリ14にロードしておいた上述の圧縮テーブル62を参照し、通知されたファイルの論理アドレスから、ファイルを分割してなる複数のブロックの圧縮後の論理アドレスを取得する(S24、S26)。
そしてサブCPU32は、圧縮後のブロックごとに、取得した論理アドレスを上述のLBAの形式として指定した読み出し要求を生成してフラッシュコントローラ18に発行する(S28)。すなわちサブCPU32は、メインCPU30が1つのファイルについて発行した読み出し要求を、ブロック単位の複数の読み出し要求に変換する。上述の16MiBのファイルの場合、64KiB単位の読み出し要求が256個発行されることになる。なおサブCPU32は読み出し要求時に、読み出されたデータの格納領域をシステムメモリ14のカーネルエリアに確保しておく。
これに応じてフラッシュコントローラ18は、図2で説明したのと同様に、アドレス変換テーブル64を用いてLBAを物理アドレスに変換し、フラッシュメモリ20から該当アドレスのデータを取得する(S30)。アドレス変換に際してフラッシュコントローラ18は、ファイルアーカイブを要求元とする読み出し要求については、上述のとおりLBAの上位ビットをインデックスとしてアドレス変換テーブル64を参照し、それに対応づけられた物理アドレスにLBAの下位ビットを加算することにより、要求されたブロックごとの物理アドレスを取得する。
図8は、ファイルアーカイブを用いて要求されたファイルの読み出しを完了するまでの処理手順を模式的に示している。まずフラッシュコントローラ18は、図7で説明したようにしてフラッシュメモリ20から要求されたデータを読み出し、内蔵するSRAM24に展開する(S40)。このデータは、元のファイルをブロック分割して圧縮した単位であり、SRAM24に十分格納できるサイズを有する。そしてフラッシュコントローラ18は、当該単位のデータにECCチェックを施す(S42)。
ECCチェックをパスした場合、サブCPU32が前もって確保しておいたシステムメモリ14内のカーネルエリア70に、図示しないDMAC等によって当該データを格納するとともにサブCPU32にその旨を通知する(S44)。なおECCチェックでエラーが検出された場合は、フラッシュコントローラ18内で再送要求を生成することにより再度、データを読み出す。フラッシュコントローラ18は、サブCPU32から発行された細かい単位の読み出し要求に対する処理が全て完了するまで、当該処理を繰り返す。
サブCPU32は、フラッシュコントローラ18からの通知に応じて、カーネルエリア70に読み出されたデータに対する、改ざんチェック、復号、伸張の処理要求をアクセラレータ42に発行する(S46)。アクセラレータ42は、格納されているデータごとにそれらの処理を実行し、処理後のデータ、すなわちファイルを構成するブロックのデータをシステムメモリ14のユーザバッファ72に格納しサブCPU32に通知する(S48)。
サブCPU32は、要求されたファイルを構成するブロックのデータが全て揃った時点で、メインCPU30に割り込みまたはプロセス間通信を用いて、読み出しの完了を通知する。これに応じてメインCPU30は、ファイルアーカイブのAPI処理に伴う事後処理を適宜行い、アプリケーションに処理を戻す。本実施の形態では図5で示すように、ファイルアーカイブ52と仮想ファイルシステム48が共存するファイルスタックを形成する。上述のようにフラッシュコントローラ18は、ファイルアーカイブ52からの要求に対しては、粗い粒度で書き込みを行う第2アドレス空間によりアドレス変換を行う。
一方、仮想ファイルシステム48からの要求に対しては、それより細かい粒度で書き込み行う第1アドレス空間によりアドレス変換を行うようにしてもよい。この場合、図2で示したように、各アドレス空間に対応する2つのアドレス変換テーブルをSRAM24に個別に格納し、要求元がファイルアーカイブ52か仮想ファイルシステム48かに応じて参照先を切り替える。要求元は、アクセス要求に含まれるLBAの上位ビットにより特定できる。
ファイルアーカイブ52による読み出し要求に対し高い伝送レートを保障するため、当該要求に対する処理を、仮想ファイルシステム48による読み出し/書き込み要求や、ファイルアーカイブ52による圧縮後のデータの書き込み要求に対する処理より高い優先度で行ってもよい。優先制御や伝送レート管理は、フラッシュコントローラ18に要求を発行するサブCPU32、または要求を受けたフラッシュコントローラ18が行う。ファイルアーカイブ52からの要求によりデータが読み出されている期間は、別の読み出し要求を禁止することにより、読み出されるべきデータが消去されることがなくなり、エラーが発生しない限りはガベージコレクションによるデータ消去も禁止できる。
次に上記構成による情報処理装置10の性能について検討する。所望の伝送レートを実現するために許容される処理時間は次の表のようになる。例えば1要求当たり4KiBのデータ粒度(処理単位)で1GB/秒の伝送レートを実現するには、1要求当たり4.1μ秒で処理を完了する必要がある。処理完了までの時間がそれより増えれば伝送レートは当然、低下していく。
これまで述べたように本実施の形態においてメインCPU30は以下の処理を行う。
1.ファイル名からのハッシュ値計算
2.ハッシュリストの検索
3.サブCPU32に対する要求発行
ファイルサイズが4KiB程度と小さい場合、10GB/秒の伝送レートを実現するには1ファイル当たり0.4μ秒以内で処理を完了させる必要がある。そのような細かい単位で読み出し要求を頻発させた場合、並列化の効果が小さいうえ、サブCPU32、フラッシュコントローラ18、フラッシュメモリ20における伝送レートの影響を受け易くなるため、容易にレイテンシが増加しメインCPU30での伝送レートが低下することが考えられる。したがって、このような小さいサイズでのデータアクセス要求が1m秒に1回程度の頻度の場合、複数のファイルを1つにまとめ、一度に10MiB程度のデータアクセスを要求することにより、高い頑健性で10GB/秒の伝送レートを実現できる。
本実施の形態においてサブCPU32は以下の処理を行う。
1.メインCPU30が発行した要求を固定長のデータブロックごとに分割する
2.圧縮テーブルを参照し圧縮後のデータが格納された論理アドレスを取得する
3.フラッシュコントローラ18に読み出し要求を発行する
4.読み出されたデータに対する改ざんチェック等の処理をアクセラレータに要求する
5.元のファイルを構成するブロックの準備ができた時点でメインCPU30へ通知する
サブCPU32は常に固定長のデータを処理単位とする。例えば処理単位を64KiBとすると、10GB/秒の伝送レートを実現するには、1要求当たり6.6μ秒で処理を完了させる必要がある。例えばメインCPU30から16MiBのファイルに対する読み出し要求が発行された場合、サブCPU32は上述のとおり、それを64KiBごとに分割して256個の読み出し要求を発行する。このとき6.6μ秒で1つずつ要求を処理するのでなく、複数の要求をまとめて処理する。
本実施の形態では、フラッシュコントローラ18や各種アクセラレータに対するコマンドの発行と完了通知の受領、といった単純化された処理のみを並列に高頻度で行える。そのため、例えば32個程度の要求をまとめて処理し211μ秒以内で完了させることも可能となり、結果として10GB/秒の伝送レートを実現できる。実現しなければならない伝送レートによっては、例えばフラッシュコントローラ18に対する要求発行や完了通知の受領などの処理を、さらに複数のCPUコアに分散させてもよい。
本実施の形態においてフラッシュコントローラ18は以下の処理を行う。
1.サブCPU32が発行した要求を読み出す
2.アドレス変換テーブルを参照しLBAを物理アドレスへ変換する
3.フラッシュメモリ20の該当領域からデータを読み出す
4.データをシステムメモリ14に格納しその旨をサブCPU32に通知する
高速処理が要求されるアドレス変換において、参照すべきアドレス変換テーブルは内蔵するSRAM24に格納されている。サブCPU32からの要求が64KiB単位であれば、10GB/秒の伝送レートを実現するには1要求当たり6.6μ秒で処理を完了させる必要がある。IOPS(Input Output Per Second)換算すると151,515IOPSとなるため、サブCPU32と同様に、複数のプロセッサコアに処理を分散させることが望ましい。またフラッシュコントローラ18は上述のように、フラッシュメモリ20に対し複数のインターフェースチャネルを持ち、読み出し要求はさらにチャネルごとに分割される。例えば64KiBのデータの読み出し要求が16KiBの処理単位に分割されると、4倍のIOPSが必要となるが、それらは複数のチャネルで並列処理されるため伝送レートに対する影響は大きくない。
本実施の形態においてアクセラレータ42は以下の処理を行う。
1.サブCPU32からの処理依頼
2.システムメモリ14からのデータ読み出し
3.改ざんチェック、復号、伸張処理
4.処理後のデータのシステムメモリ14への格納およびサブCPU32への通知
平均10GB/秒以上のスループットで動作させる場合、各種処理間のオーバーヘッドなども考慮すると、アクセラレータにはそれ以上のピークスループットが必要になる。128ビット/サイクル、1GHzで動作する回路であれば、ピークスループットは16GB/秒と十分な値となる。一方、128ビットの処理に16サイクルを要するような回路であれば、アクセラレータを16並列させるなどの対策を講じてもよい。
以上述べた本実施の形態によれば、フラッシュメモリに対する書き込みアクセスの粒度を、ページ単位など従来技術での書き込み粒度より大きくする。これによりアドレス変換テーブル全体を内蔵SRAMに格納できる程度のサイズとすることができ、アドレス変換のためにフラッシュメモリへのアクセスを繰り返す必要がなくなる。またフラッシュメモリの容量が大きくなっても、アドレス変換テーブルをキャッシュするために大容量の外付けDRAMを設ける必要がなくなる。結果として、フラッシュメモリや外付けDRAMへのアクセスによるレイテンシの増加やスループットの低下を防ぐことができるとともに、製造コストやチップ面積を削減できる。
さらにアドレス変換テーブルを複数のアドレス空間に分割し、それぞれで書き込みアクセスの粒度を異ならせることにより、データの特性に適したアドレス変換テーブルを選択できるようにする。細かい粒度のアドレス空間を定義するアドレス変換テーブルは、その一部をSRAMにキャッシュする。例えばデータが更新されることのないゲームプログラムなどは粒度を大きくし、更新されることの多いユーザデータなどは粒度を細かくする。これにより、データ更新時には別の領域を新たに確保することが求められるフラッシュメモリの特性を考慮した無駄のない領域割り当てが可能となり、上述した、粒度を大きくすることによる効果と両立できる。
またフラッシュメモリへのアクセス要求を担うプロセッサを、メインのプロセッサとは別に設ける。このプロセッサは、ファイルごとのアクセス要求を細かい単位に分割し、以後の処理はその単位でなるべく並列になされるようにする。これに対応するように、フラッシュメモリにはファイルを分割してなるブロックごとに圧縮したデータを格納しておく。これらの構成により、1つのアクセス要求に対する処理速度が実質的に増加する。また読み出されるデータもサイズが小さくなるため、フラッシュコントローラに内蔵したSRAMでのバッファが可能となり、外付けDRAMの介在が必要なくなる。
さらにソフトウェアスタックにおいて、従来のファイルシステムに加えて、アプリケーションとSSDとを直接つなぐインターフェース層を設けることにより、ファイル名からアドレス取得までの処理を単純化する。また読み出しアクセスの要求元が、当該インターフェース層か従来のファイルシステムか、により処理に優先順位をつけ、前者をより優先させるとともに、読み出し単位を従来より大きくすることにより読み出し処理を効率化する。これにより、プログラムファイルのように迅速な読み出しが求められるデータの読み出し処理を、ユーザデータのような一般的なファイルの読み出し処理と差別化できる。
ファイル名からアドレス取得までに必要なメタデータを単純化することにより、階層化されたメタデータを逐次辿っていく必要がなく、またメタデータ自体のデータサイズを小さくできるためシステムメモリに全体を格納することも可能である。結果として、アドレス取得のためのメモリアクセス処理の負荷が大幅に軽減される。以上の構成により、従来の様々なストレージに対するデータアクセス手順と共存させつつ、フラッシュメモリの高い伝送レートを十分に活かした高速なデータアクセスが可能となる。
以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。