■元麻布春男の週刊PCホットライン■
5月1日にリリースされたWindows 7 RCにおけるSSDのサポートだが、Microsoftのブログで、若干の情報が公開された。それによると、Windows 7がデバイスをSSDと認識し、自動デフラグを無効にする条件は、前々回取り上げたATA8-ACS準拠のコマンドによる方法(メディアが非回転であるデバイス)に加え、内部的にデバイスのランダムリード性能を計測する方法がインプリメントされているという。ランダムリード性能が8MB/secを越えるデバイスについては、デバイスをSSDだと判定し、自動デフラグを無効にする(ついでにスーパーフェッチ、ブートプリフェッチ、アプリケーション起動プリフェッチ、ReadyBoost、ReadyDriveもすべて無効化される)。
この8MB/secという数字を設定するに際し、Microsoftは182種類のHDDをテストし、わずか6種類のみが2MB/secを越え、残りの176種類が0.8MB/secから1.6MB/secの間の性能であることを確認したという。逆にSSDは、テストしたすべての製品(何種類かは明らかにされていない)が11MB/secから130MBsecの性能を示しており、8MB/secという閾値は、十分に安全な数字だと述べている。
 |
| 【図1】IntelのMainstream SSDを搭載したThinkPad X200sでのWindowsエクスペリンス インデックス。SSDをサポートするのなら、コンポーネントの表示名は「プライマリ ハードディスク」ではなく、「プライマリ ストレージ」とでもするべきだと思う |
だが、前回示したように、筆者はIntelのMainstream SSDとRCの組合せで自動デフラグがデフォルトで無効にならないことを確認している。IntelのMainstream SSDは、現時点においてこの種のデバイスとしては最速に近い製品であり、図1に示したように、Windowsエクスペリエンス インデックスでも7.7というスコアをたたき出す(Windows 7ではVistaの5.9から7.9に、インデックスの上限が変更された)。このデバイスのランダムリード性能が基準に達していないとは考えにくいし、もしそうなら市販のSSD製品でWindows 7からランダムリード性能によってSSDと認識されるデバイスはほとんど存在しないことになってしまうだろう。
また、Trimコマンドについても、Windows 7 RCはサポートしているのだという。外付けRAIDアレイでTrimコマンドがパリティを無意味なものにしてしまう潜在的な問題について、上記のブログでは、RAIDコントローラがOSに対してメディアが非回転のデバイス、という返答を返せばTrimコマンドを発行し、そうでなければTrimコマンドを発行しない、という趣旨の発言があった。
 |
| 【図2】Windows 7のWindows Power ShellからDisableDeleteNofityの値を調べてみた。帰ってきた答えはHDDと同じゼロであった |
さらにファイルシステムにおけるTrimコマンドのステータスが、DisableDeleteNotifyであることが明らかにされたので確認してみたのだが、IntelのSSDを用いたシステムも、HDDにRC版をインストールした別のシステムも同じ0を返してきた(図2)。やはりIntel SSDは今のところSSDとして認識されていない、ということなのだと思われる。が、このような曖昧な方法で、データ損失につながる可能性のある技術の適用可否を決めて良いのか、疑問が残る(疑わしきは非サポート、というポリシーなのかもしれないが)。
Trimコマンドの実装は、WinHEC時点と同じMicrosoftのプロポーザルに基づくものなのか、最新のATAドラフトに準拠したものなのかも含めて、まだハッキリしない部分が多い。にもかかわらずTrimコマンド、あるいはもっと大きな母集団としてのDataset Management Commandsの実装が行なわれる最大の理由は、それが有用で、今後さらにその有用性が増すと考えられているからだ。
書き換え可能回数(消去可能回数と言い替えてもいい)に制限のあるNANDフラッシュメモリを用いたSSDで長い製品寿命を実現するには、ウェアレベリングが必要となる。ウェア(wear:摩耗あるいは疲弊、NANDフラッシュでは書き換えられた回数の多いブロックを指す)のレベリング(平準化)を行なうことで、SSDを構成するNANDフラッシュメモリの特定ブロックに消去が集中することを防ぐ。
特にPCの起動デバイスに用いる場合、OSはテンポラリファイルやページファイルなどを含め、頻繁にファイルの更新を行なう。これに伴いファイルシステムの管理情報も頻繁に更新される。これらが、SSDの特定の物理ブロックに存在した場合、その物理ブロックに消去が集中し、真っ先に更新できなくなってしまう。ファイルシステムの管理情報が更新できなくなれば、そのストレージの寿命は終わりだ。ウェアレベリングが必要となる理由はここにある。
実は、NANDフラッシュメモリ用のコントローラチップのすべてが、ウェアレベリングを行なっているわけではない。USBメモリやメモリカードに使われているコントローラの多くは、ウェアレベリングをサポートしていない。単に書き込みがエラーになったら、そのブロックをスペアブロックに代替する、という処理を行なっているだけのものがかなりの割合で存在する。これならLBAから物理アドレスを仮想化する(コントローラがLBAと物理アドレスの対照表を管理する)必要もない。
こうした製品の主な用途はデジタルカメラのデータ記録であったり、MP3ファイルの保存であり、一度書き込んだファイルを更新することはマレである。ファイルを追加したり消去する際にFATやディレクトリエントリが更新されるから、これらの書かれた部分をスペアブロックで代替できるようにしておけば、おおかた用が足りる。このようなシンプルなコントローラをSSD用に転用した製品もあり、データ領域用としてなら十分に使えるのだが、システムドライブとして使うのであればウェアレベリングをサポートした製品の方が安心である。
ウェアレベリングで最も基本的なものは、以前に触れたことのあるダイナミック・ウェアレベリングだ。記録する際に、利用可能なブロックのうち、書き換えられた回数の最も少ないブロック(書き換え可能回数の最も多く残ったブロック)を利用することで、書き換え可能回数の平準化を図る。データを更新するブロックとスペアブロックの中から、最も書き換えられた回数の少ないブロックを選び、そこにデータを書き込んだ後、LBAと物理アドレスの対照表を更新する、という処理となる。
ところが、このダイナミック・ウェアレベリングには限界がある。更新頻度の小さい(あるいは全く更新されない)データが、書き換え可能回数の多く残されたブロックを占拠してしまうと、それだけウェアレベリングされる物理ブロックの数が減ってしまう。すでにデータの書かれた物理ブロックは、ダイナミック・ウェアレベリングの対象とならないからだ。
これを解消するために用いられる(ダイナミック・ウェアレベリングと組み合わせられる)のがスタティック・ウェアレベリングだ。スタティック・ウェアレベリングでは、書き換え可能回数の多いブロックに書かれたデータを書き換え可能回数の少ないブロックに移動させることで、書き換え可能回数の平準化を図る。ただ、処理にデータのコピーが含まれるため、更新頻度の高いデータを書き換え可能回数の少ないブロックに移しては、すぐに再コピーの必要が発生してしまい、性能低下や寿命の短縮を招く。コントローラのファームウェアアルゴリズムが賢くなければならない。
Dataset Management Commandsは、こうしたウェアレベリングを賢くするのに大いに役立つ。特定のページに書かれたデータが不要だと分かっていれば、Write Amplificationを小さくできるし、ガベージコレクションに要する時間も短縮できる。ダイナミック・ウェアレベリングを行なう際に、利用可能なブロックの数を増やすことも可能だ。
Trimコマンド以外のDataset Management Commandsがサポートされれば、OSの側からそのデータの読み出し頻度や更新頻度といった情報もコントローラに提供されることになる。データの更新頻度が少ない(たとえばOSのシステムファイル等)と分かっていれば、最初から書き換え可能回数が残り少ないブロックに書き込むこともできる。SLCとMLCの両方を用いたハイブリッドSSDなら、それぞれに適切にファイルを配置することも可能だ。
現在、NANDフラッシュメモリは、半導体製造プロセスのテクノロジーリーダーとなっている。早いメーカーだと、年末には34nmプロセスへの移行が行なわれる。製造プロセスの微細化はNANDフラッシュメモリのコストを下げる一方で、データを保持するTunnel Oxide(絶縁膜)を薄くする。薄い絶縁膜は書き換え可能回数を減らしてしまう。同じくNANDフラッシュメモリのバイト単価改善に寄与するMLCチップのさらなる多値化も、書き換え可能回数の減少を招く。
こうした避けられない書き換え可能回数の減少を補うためにも、ウェアレベリングアルゴリズムの改善とWrite Amplificationの低減が不可欠だ。Dataset Management Commandsは、コントローラのアルゴリズム改善に大きく寄与すると考えられている。RAIDコントローラやスナップショット技術等との共存という問題がありながらも、Dataset Management Commandsの実用化が避けて通れないのは、こうした理由からだろう。