これまで3回にわたって見てきたように、本来SSDに使われているNANDフラッシュメモリは、HDDに使われている磁気記録技術と大きく異なる特性を持つ。直接書き換えできない、書き換え動作に回数制限があるという欠点を補うための工夫をコントローラに盛り込むことで、SSDはHDDを置き換え可能なデバイスとなっているが、それでも完全に同じというわけにはいかない。

　理想としては、SSDの特性に最適化されたOSやファイルシステムによるサポートが望まれるが、普及期にあるデバイスだけに、それにはまだ時間がかかると予想される。それでも、今後一層の普及が期待されるSSDだけに、OSやファイルシステムをSSDフレンドリーにするための対応が始まろうとしている。ここでは年内にリリースされることが確実視されるWindows 7のSSD対応について見ていきたいと思う。

　昨年11月に開催されたWinHEC 2008でMicrosoftは、Windows 7のSSD対応について3点を挙げている。まず最初は、SSDを検出したら、そのデバイスに対しデフォルトで自動デフラグを無効にするというものだ(図1)。Windows Vistaで導入された自動デフラグだが、SSDデバイスに対しては、寿命を縮めるだけでメリットはない。現在のVistaでは手動で無効にしなければならないが、SSDがATA8-ACSに準拠していればWindows 7では何もする必要がなくなる。

　2番目はストレージデバイスに設定するパーティション境界の問題だ。Windows XPでは最初のパーティションが63セクタから始まる。これはパーティションがSSDのページの途中から始まることになるため、そのオーバーヘッドで性能が低下する(図2)。Microsoftはその低下率を最大で50%としている。Intelが発表したSYSmark 2007 Previewによるベンチマークテスト結果(図3)でも、Windows XPのスコアはWindows Vistaを下回っており、その理由の1つはこのパーティション境界の問題である可能性がある。

【図1】Windows 7ではSSDを検出した場合、自動デフラグはオフに設定される	【図2】Windows VistaやWindows 7ではパーティション境界の問題はないが、アップグレードインストールした場合の問題は残る	【図3】Intelの発表したデータでも、Windows XPとWindows Vistaでは、SSDで得られる性能向上に大きな差が見られる

　Windows VistaやWindows 7では、最新の規格に準拠することで、パーティション境界の問題は発生しないとMicrosoftは述べている。問題は、Windows XPからのアップグレードだ。一般にアップグレードインストールを行なう際、パーティション情報はそのまま維持される。現在、SSD上でWindows XPを利用しているユーザーが、Windows VistaやWindows 7にアップグレードした場合、本来の性能が発揮されない場合がある点に注意する必要がある。

【図4】Microsoftは自らの提案に基づいてWindows 7でTrimコマンドをサポートするというが

　3点目は、Trimコマンドの実装に関するものだ(図4)。このコマンドを一言で表せば、OSからデバイスに、そのブロックが(OSにとって)不要になったことを通知するものである。ミソは不要になったことを通知するのみで、不要になったブロックをどうするかはコントローラに委ねていることだ。以前に触れたように、デバイスに対し消去を命じることは、当該のブロックを0もしくは1で埋める、つまりは書き込みすることに等しい。それではかえってデバイスがビジーになり、システム性能が低下することも考えられる。Trimは消去を命じるのではなく、コントローラ(と内蔵するアルゴリズム)に対し、もっと自由度を与えようとするものだ。

　このTrimコマンドは、ATAの標準化を行なうINCITS(米国規格協会ANSIの諮問機関)のT13技術委員会に、Microsoftのエンジニアが、「Data Set Management Commands Proposal for ATA8-ACS2」として提案しているもの。一番最初の提案書がTrimコマンドの提案とされていたことから、一般にそう呼ばれる。Data Set Management Commandsとは、OS側からデバイス側へさまざまなデータの属性を伝えるためのコマンドセットを指し、その最初の実装として具体化しているのがTrimコマンド(不要という属性の通知)ということになる。

　これまで筆者は前々回、前回と、ストレージが使われているということの意味、あるいは消去するという行為の意味について、OS側からとデバイス側からの双方から取り上げてきた。その中で、ストレージデバイス自身は、セクタやブロックがOS(あるいはユーザー)から見て、使われているかどうかを知り得ないとしてきた。Trimコマンドは、知らないのなら、OSからデバイスに教えてあげてみてはどうかと提案するものである。

【図5】2008年11月に開かれたWinHECでは、正式なATA8規格ではなく、Microsoftによる提案書に基づいてTrimコマンドを実装するよう求めている

　デバイスにとって、セクタやブロック上にあるすべてのデータ、SSDの場合であればスペアブロック等を除いたLBAにマップされているすべてのデータは、みな有用なものとして取り扱われてきた。ユーザーが消去したファイルが占有していたクラスタに割り当てられていたセクタやブロックも、デバイスは有用なデータが記録されているものとしてその内容を維持する。ガベージコレクションの際、あるいは新規データの書き込みでブロック消去をする必要が生じた際も、SSDはそのデータをきちんと書き戻す。これがSSDにとって、性能上および製品寿命上の大きなオーバーヘッドになることは、すでに述べた通りだ。

　Trimコマンドが実装されて、OSからそのセクタやブロックが使われていない、そのセクタやブロックに書かれているデータが必要とされていないとデバイスが分かれば、そのデータを書き戻す必要はなくなる(Write Amplificationが小さくなる)。また、使われていないブロックを利用することで、ウェアレベリング等の自由度が大幅に増す。少なくともSSDのコントローラのアルゴリズムで工夫できる範囲は広がる。MicrosoftはWinHEC 2008で、Windows 7向けストレージのロゴ取得要件(プロポーザル)として、Trimコマンドを実装する場合は、Data Set Management Commands Proposal for ATA-ACS2(e07154r6)への準拠を求めていた(図5)。

　ところが、このe07154r6によるTrimコマンドの実装には、多くの疑問、あるいは反対が寄せられた。それは、Trimコマンドで不要とされたLBAを、もう1度読み出した時の挙動に関するものだ。e07154r6では、Trimコマンドが指定されたLBAを読み出した際の出力はIndeterminate(不確定)で、次に書き込みが行なわれて初めて確定するとなっている。コントローラによるガベージコレクションやERASEの自由度を高めるには、Indeterminateである方が望ましい。

　Trimコマンドで指定されたLBAは、OSから不要とされたものであり、本来、そこにあるデータを読み出す必要はないと考えがちだ(ゴミ箱機能等で簡単にファイルを復活させることはできなくなるが)。しかし、従来のストレージでは、OSが不要と判断したセクタやブロックであれ、そのデータが勝手に書き換えられることはなかった。そして、これを前提にしたストレージ技術が存在する。大容量ストレージでバックアップ代わりに使われることのあるスナップショットや、RAID技術だ。

　たとえばRAID 5の場合、複数台のストレージデバイスでストライピングセットを構成し、そのパリティを記録することで、1台故障した際に、元のデータを復元可能にしている。基本的にパリティは、データを書き込む際に計算され、記録される。しかしファイルが消去され、ファイルが占有していたブロックにTrimが適用されると、パリティは意味を失う。Trimされたブロックは、次に書き込みが行なわれるまで、そのデータ内容が確定しない。不確定なデータが混じっては、パリティの有用性が失われるからだ。本来は競合関係にあるストレージベンダ(EMCとNetApp)が、連名でTrimコマンドに異議を唱えたのも無理はない(図6、図7)。

【図6】ストレージシステム大手のEMCとNetAppは、ライバル関係にあるにもかかわらず、連名でTrimコマンドの実装に対して疑問を投げかけた	【図7】Trimされたブロックを読み出した場合に読み出されるデータが、ドライブのどこかに書かれていたものだとしたら、セキュリティの問題も発生すると、両社は指摘した

　こうした意見もあり、現時点においてATA8のドラフトでは、IDENTIFY DEVICEコマンドによりデバイスから返される値で、Trimコマンド後の読み出しが不確定になるデバイスと、Trimコマンド後も一定の値が読み出されるデバイスを識別可能にすることになっている。読み出しの不確定性を持つデバイスを許容することで、Trimコマンドによる自由度を最大限に確保しながら、RAIDに使うストレージではTrim後も確定した読み出しを保証しようというわけだ。

　ただこの場合、デバイスによってRAIDに使っていいドライブと、RAIDに使えないドライブが出現する可能性がある。ジャンパスイッチやDIPスイッチ等を使って両方のモードを切り替えることは可能だが、これではせっかくSATAでジャンパの設定が不要になったメリットが失われてしまう。

　このTrimコマンドの挙動については、この4月(2009年4月)にも、SCSI規格における同等のコマンドとの互換性をもたせるという意味から、Trim後に読み出されるデータをすべてゼロにするというオプションの実装が提案されるなど、まだ流動的な部分が少なくない。この状態で、Windows 7でTrimコマンドを実装することが正しいのか、疑問が残る。少なくともWinHECで示されたe07154r6に準拠した形での実装は避けるべきだろう。そんなことをすれば、WindowsロゴとATA規格で相反することになりかねないからだ。というわけで、この問題については、もうしばらく動向を注視する必要があると思っている。