前回、昨年(2008年)のWinHECで語られたWindows 7のSSD対応について触れたが、そうこうするうちにWindows 7のRC(製品候補版)がリリースされた。そこで、Intelのメインストリーム向けSSD(X25M 80GB)にこのWindows 7 RC x86版をインストールして、対応の様子をうかがってみることにした。

　インストールの母機に用いたのはレノボのThinkPad X200s。RCをインストールすると、IntelのAMTとおぼしきデバイスが、2つほどドライバがインストールされていない状態となるが、動作そのものに特に問題はないようだ。

　IntelのSSDについては、4月にリリースされたファームウェアアップデートを適用し、最新と思われる状態にしてある。が、データシートのスペック上、このドライブはATA/ATAPI-7互換を謳っており、前回触れたATA8-ACS準拠のドライブではない。ATA8がまだ標準化作業中であることを考えれば、当然とも言えるが、果たしてどのような挙動になるのだろうか。

　結論から言うと、残念ながらRC版のWindows 7は、X25MをSSDとして認識しなかった(図1)。通常のATAデバイスとして認識しており、もちろん普通に利用できるが、自動デフラグは有効になったまま(図2)。SSDとして認識していないので、Trimコマンドが実装されているかどうか、それを確認する方法も今のところハッキリとしない。正式版のWindows 7では何か変更が加えられる可能性があるし、Windows 7の正式リリースを受けてSSDのファームウェアアップデート等が行なわれる可能性もあるものの、現時点ではSSDのサポートについてVistaと大きく変わってはいない印象だ。

【図1】Windows 7 RC版とIntel SSDの組合せでは、SSDは標準ディスクドライブとして認識される	【図2】SSDとして認識されないため、自動デフラグもスケジュールされている

　というわけでWindows 7におけるTrimコマンドの実装がどのようになるのかは、まだ分からない。ATAコマンドセットによるサポートの標準化には、もう少し時間がかかるようだ。それでもTrimコマンド、あるいはもっと大きな「くくり」としてのData Set Management Commandsは、何らかの形でATAでも実装されるだろう。

　その理由の1つは、それがSSDにとって有用であるから。そしてもう1つは、ATAとは別にData Set Management Commandsに相当する技術を実装しようという動きがあるからだ。あるインターフェイスが、過去の技術との互換性を重視するあまり、有用な技術の実装を行なわなければ、それを実装した別のインターフェイスに主役の座を奪われかねない。それを防止するには、同じ有用な技術を取り込んでしまうに限る(だからといって絶対に防止できるとも限らないが)。ここでは、有用性については後回しにして、「別の動き」から取り上げていくことにしよう。

　現在、PCプラットフォームに統合されたNANDフラッシュメモリには2つの形態がある。1つはここで何回も取り上げてきたSSD、もう1つがIntelが推進するTurbo Memory(Robsonテクノロジー)だ。SSDが標準のSATAポートに取り付けられ、ATAのコマンドで制御される(コマンドを送りつけるOS側から見たSATAコントローラのプログラミングインターフェイスがAHCI)のに対し、Turbo MemoryはPCI Expressのミニカードとして実装され、Intel独自のソフトウェア(Windows Vista対応のRobsonドライバとMatrix Storage Managerドライバ)によって制御される(図3)。

　Intelがこの次のステップとして考えているのが図4のような構成だ。NANDフラッシュメモリモジュールの接続インターフェイスが、PCI ExpressからNVMHCIに変わっている。NVMHCIはNon-Volatile Memory Host Controller Interface(不揮発メモリコントローラインターフェイス)の略で、その名前の通りNANDフラッシュメモリに代表される不揮発メモリ(電源を切ってもデータが保持されるメモリデバイス)を、PCに接続するコントローラに対するプログラミングインターフェイス標準である。2007年5月にIntelが議長を務める形で、DellとMicrosoftが賛同して標準化がスタートした。2007年秋の段階で参加企業は25社を越え、メンバーには上記3社に加え、AMDやNVIDIAといった名前も見られる(図5)。

【図3】現行のTurbo Memory(Robsonテクノロジー)は、PCI Express接続のコントローラチップを用いる	【図4】Turbo Memoryの次のステップは、PCI ExpressをNVMHCIで置き換えること	【図5】2007年秋(IDF 2007 Fall)の時点におけるNVMHCIワーキンググループの参加メンバー

【図6】NVMHCIの基本。レジスタ的には独立したPCIデバイスでありながら、AHCIの中から参照できるポートとして存在することで、HDDと不揮発メモリを1つのデバイスドライバで扱うことが可能になる

　話を図4に戻すと、この図の構成を見ただけでは、PCI Expressを置き換えるメリットが見えてこない。部品点数も変わらないからだ。その答えの少なくとも一部は図6に書かれている。NVMHCIは、レジスタ的には独立したPCIデバイスでありながら、AHCIの中から参照できるポートとして実装されることで、HDDと不揮発メモリを単一のデバイスドライバで扱うことを可能にする。

　図3に示したように、現在のTurbo Memoryは、HDDとは異なるポートを利用するため、OSからは別のクラスのデバイスとなる。したがってデバイスドライバも2本立てになってしまう(Matrix Storage ManagerとRobsonドライバ)。PCI ExpressからNVMHCIへ切り替えることで、両者は同じクラスのデバイスとなり、すべての機能をMatrix Storage Managerドライバに集約することが可能になる。これはソフトウェアのオーバーヘッドを減らすと同時に、ドライバの簡素化、さらにはプラットフォームの堅牢化につながる。

　さて、図4からさらに次のステップ、図7の構成になるともう1つのメリットが見えてくる。これまでTurbo Memoryのモジュール上にあったフラッシュコントローラがマザーボード上に移行している。図7は2007年のIDFのもので、モジュールとフラッシュコントローラの接続インターフェイスがONFI 2.0になっており、データレートが133MB/secになっているが、今年の1月にリリースされたONFI 2.1では166MB/secと200MB/secのデータレートが追加されており、さらなる高速化を図ることが可能だ(図8)。

【図7】図4の次のステップは、コントローラをモジュール上からマザーボード上へ移す	【図8】ONFIの最新規格では、データレートの引き上げ、パワーマネージメントの強化、ECC情報の拡張、コマンドの追加等が行なわれた

　上述したもう1つのメリットとは、フラッシュのモジュールからコントローラが取り除かれることである。コントローラが取り除かれることで、フラッシュメモリのモジュールは、メインメモリに使われるDIMMのような汎用性を獲得する。Turbo Memory専用のオプションではなく、汎用の不揮発メモリモジュール(正確にはONFI準拠のNANDモジュールなわけだが)となるわけだ。

　モジュールが汎用化することで、別の用途への転用、Intel製コントローラという「縛り」がなくなることによるモジュールのバイト単価改善等が期待できる。すでにONFIでは、汎用のフラッシュメモリモジュール用コネクタとモジュールの物理サイズに関する標準化も行なわれており、実用化を待つばかりとなっている。

　さらにその次のステップとなる図10のメリットは明らかだ。不揮発メモリコントローラはチップセットに取り込まれ、プラットフォームの標準機能となる。これにより不揮発メモリインターフェイス(NVMHCI)は、PCにとって事実上、タダで使えるインターフェイスとなる。AMDやNVIDIAがNVMHCIワーキンググループのメンバーになっているのは、こうした展開を見越しているからだ。

　さてここで、いくらタダでもTurbo Memoryじゃなぁ、と思う人もいることだろう。そう思った人は、もう1度、図6を見て欲しい。この図の一番下に、NVMHCIの用途としてTurbo Memory(ReadyBoost/ReadyDrive)に加え、SSDと書かれている。NVMHCIは、Turbo Memory用のインターフェイスではなく、汎用の不揮発メモリインターフェイスである(ついでに言えば、NANDフラッシュメモリ専用でもなく、不揮発メモリ汎用である)。不揮発メモリを何に使うかは、ホスト側のソフトウェアしだいだ。

　言い替えると、ソフトウェア次第で同じメモリモジュールをキャッシュに使うこともできれば、SSDに使うこともできる、ということになる。たとえば、4GBのNANDフラッシュモジュールを、MIDではSSDとして利用し、PCではキャッシュに使う、ということも可能になる。そのためにも、モジュールからコントローラを取り除き、モジュールそのものは汎用化しておいた方が都合がいい。

　もちろん、だからといって、すぐにPCのプライマリストレージがNANDフラッシュのモジュールになると言っているわけではない。図9に示したコネクタのうち、大きな直立型の方でも、ノートPCのメインメモリに使われているSO-DIMMコネクタより小型だ。すぐに大容量のNANDフラッシュメモリを実装するというわけにはいかない。PCのキャッシュとMIDのSSDを1つのモジュールでまかなえる、というくらいが現時的だろう。

　しかし、SSDの普及が予想を超えて進めば、キャッシュそのものの存在意義も問われてくる。複数モジュールの実装を前提にした、大容量化だってありえるかもしれない。将来的なビジョンとして、NVMHCI経由でNANDフラッシュメモリを直結し、これをプライマリストレージとして利用する時代がくる可能性はある。

　これが単なる笑い話で終わらないのは、Intelが2010年にリリースすると言われているMoorestownプラットフォームのチップセットであるLangwellに、見慣れない機能が含まれていることだ。図11のLangwellという文字の下に、Solid State Disk Controllerという文字が見える。PATAでなく、SATAでもないSolid State Disk Controllerとは何なのだろうか。この辺りが気になるところだ。

　さて、そろそろ「別の動き」に話を戻そう。AHCIにはコマンドセットとしてATAという標準がある。しかし、NVMHCIにはATAに相当するコマンドセットの標準はない。そこで、NVMHCIでは規格そのものがコマンドセット標準を持っている(図12)。ただし、コマンドセットといっても、インターフェイスとしての汎用性を確保するため、特定のデバイスに対する具体的な操作というより、それを記述したテーブルを引き渡したり、デバイスからデータやステータスを受け取るための枠組みという性格が強い。

【図9】ONFI準拠のNANDフラッシュを用いた汎用メモリモジュール用コネクタの標準化は完了しており、デスクトップPCには直立型、モバイル用には水平型(ライトアングルタイプ)のコネクタが用意されている	【図10】図7の次のステップは、不揮発メモリコントローラのチップセットへの統合、パワーマネージメントの強化、ECC情報の拡張、コマンドの追加等が行なわれた
【図11】MoorestownプラットフォームのチップセットであるLangwellには、Solid State Disk Controllerが統合される	【図12】NVMHCIのコマンドセット。不揮発メモリに対し具体的な操作を行なうというより、具体的なコマンドの書かれたメモリ上のテーブルをコントローラに引き渡す枠組みというところ

　そのオプションコマンドの1つに、Dataset Managementという文字が見える。このDataset Managementは、一定範囲の不揮発メモリ(ページ)がどのような属性を持つのか、その属性を記録するもの。NANDフラッシュメモリであれば、ページごとに用意されるスペア領域にメタデータとして記録するものだ。メタデータとして、1つのオブジェクトとして読み書きするページの範囲を指定したり、不使用(デバイス的に使われていない)、あるいは読み書きの頻度や、読み書きの際に期待されるレイテンシ等を指定することができる。書かれたメタデータをどう生かすかは、SSDやキャッシュのアルゴリズムに委ねられる。

　NVMHCIでは、コントローラはコマンドを受け渡す枠組みのようなもので、キャッシュやSSDとしての管理アルゴリズムといったものは、ホスト側のソフトウェアにより(つまりはPCのCPUにより)行なわれる。ATA/ATAPI-8で議論になっているTrimコマンドは、NVMHCIではホスト側で実行されるソフトウェア内部の問題であり、本来はNVMHCIのコマンドとは直接関係しない。それでも、スペア領域を、特定のブロックやページの用途の管理に使おうとすれば、その属性を書いておくためのコマンドが必要になる。

　NVMHCIのDataset Managementコマンドから透けて見えるのは、IntelやMicrosoftがNANDフラッシュメモリをどう使おうとしているのか、という思惑である。書き換え可能回数に制限のあるNANDフラッシュメモリのパフォーマンスと製品寿命を最大限に引き出すには、その管理にDatasetのメタデータ(属性)を活用する必要があるというのが、両社の思惑のようだ。

　ATA8に提案されているDataset Management Commands(Trimコマンド)は、NVMHCIで行なうつもりのNANDフラッシュメモリのメタデータ管理を、ATAにも持ち込もうとするものと考えられる。NVMHCIという「別の動き」でメタデータ管理を行なおうとしている以上、ATA/AHCIにも相当する仕組みが必要になる、というわけだ。ただ、OSから直接管理できるNVMHCI下のSSDと異なり、バスの先にあるコントローラに管理を委ねなければならない点、コントローラが採用する技術が必ずしもTrimコマンド等と親和性が高いと限らないことが、問題を複雑にしているのである。