前々回はSSDに用いられるNANDフラッシュメモリが、直接書き換えできないこと、書き換えをERASEとPROGRAMの2段階で処理すること、書き換え可能回数には上限があること、ERASEとPROGRAMで処理の最小単位が異なるため書き換えがさらに複雑な手順になること、それが書き換え可能回数をさらに少なくしてしまうこと、などを紹介した。今回はこの問題を別の角度から見てみたいと思う。

IntelのSSD

　NANDフラッシュメモリは、PROGRAM時はページ単位(通常2KB/4KB)、ERASE時はブロック単位(通常64ページ/128ページ)で処理を行なう。新たに書き込むページが消去済みのブロックにあればそのままPROGRAMできるが、そうでなければERASEして書き込まねばならない。しかしERASEするには、同一ブロックの書き込まないページの内容もいったんバッファ等にコピーし、待避した上でブロックを丸ごとERASEし、ブロック分だけPROGRAMすることで書き戻す必要がある。1ブロックが64ページなら、2ページをPROGRAMするのに32倍(Write Amplificationが32)の64ページのPROGRAMが必要になるし、32ページのPROGRAMであっても2倍のPROGRAM量となる(Write Amplificationは2)。

　このオーバーヘッドがSSDへの書き込み、特に書き込みサイズが小さい場合の性能を低下させていると考えられる(書き込みサイズが大きければ、どうせブロックごとERASEしPROGRAMすることになる)。と同時に、SSDの寿命も短くしている。言い替えれば、4Kランダムライトが高速なIntelのSSDは、そのベンチマーク結果を見るだけで、Write Amplificationが小さいことが分かる。これはコントローラが内蔵するアルゴリズムに相当なヒミツ(工夫)が隠されている、ということであり、Write Amplificationの小ささから考えて、おそらく製品寿命も長いと推定できる。

　さて、ここで誰しも考えるのは、ブロック内のページが使われていないと分かっていれば、そのままERASEして、必要なページだけPROGRAMすれば良いのに、ということだ。それならオーバーヘッドを大幅に軽減でき、Write Amplificationは小さくなる。また、使われていないことが分かっていれば、バックグラウンドでERASE処理を行なっておくこともできるのではないか、ということだ。しかし、「使われていない」というのはどういうことだろう?

　ユーザーから見て使われていない、あるいはユーザーが使っていないということは、そのブロックあるいはセクタが、有効なファイル(ユーザーから見えないもの等も含む)やその他のデータ(ファイルシステムに関連するデータ等)で占有されていない、ということを意味する。たとえユーザーが意識していなくても、OSのファイルシステムにより管理されたデータである。

　だが、ストレージデバイス(ATAデバイス)は、自分のブロック/セクタが、ファイルの一部であるかどうかなどあずかり知らない。ストレージデバイスが行なうのは、指定されたブロック/セクタに所定のデータを書き込む、指定されたブロック/セクタからデータを読み出す、ということであって、それがユーザーから見て使われているかどうかなど、知りようがない。どのブロック/セクタが使われているのか、いないのかを知っているのはOSであり、ATAデバイスはそれを管理していないのである。

　仮にATAデバイスが、特定のブロック/セクタがユーザーにとって有効なファイルの一部であるかどうかを知ろうとすれば、OSのファイルシステムを理解していなければならない。が、もしそうだとしたら、ATAデバイスはOSやファイルシステムに依存することになり、OSのバージョンアップのたびごとに、ATAデバイスのファームウェアを更新するハメになったり、特定バージョンのOS用のHDDなどといった製品がなければいけないことになる。もちろん、市場にそんな製品は存在しない。

　実際、ATAコマンドには消去や削除といった機能に該当するものはない。正確には、現在のATA規格にはERASEと名のつくコマンドが2種類存在するが、いずれも一般的なOSがプライマリストレージに用いるものではない。

　その1つであるCFA ERASE SECTORSは、CF(コンパクトフラッシュ)用に、指定したLBAから連続した領域(最大256セクタ)を消去するコマンドで、HDDやSSDに用いられることはない。もう1つの消去コマンドは、SECURITY ERASE UNITというもので、これは文字通りセキュリティ目的に、ドライブ(ユニット)のユーザー領域を丸ごとゼロで埋めるもの。HDDを廃棄あるいは譲渡する際に、有意なデータが残らないようにするためのもので、ユーザーが運用中のHDDやSSDに対し、実行するコマンドではない。

　一般にデバイスにとって「消去」というのは、セクタやブロックに0または1を書き込むことで、以前書かれていたデータを読み出せなくする行為だ。SSDの場合は、1から0への変更(PROGRAM)はページ単位でできるが、0から1へはブロック単位でしか行なうことができない。そこでブロックをすべて1で埋めることで、次にブロック内の任意のページをPROGRAM可能にする行為をERASE(消去)と呼ぶが、それはユーザーが日常的に行なう消去とはかなり異なったオペレーションだ。

　「消去」という言葉を考える時、どうしてもユーザーは、ファイルを消すことでファイルシステムから見える空き領域が増えるため、ストレージデバイス上でも何かが消えているように思いがちだ。SSDの場合なら、書き込み可能な消去済みブロックが増えると勘違いするかもしれない。

　しかし、ユーザーが行なうファイルの消去は、OSが管理するファイルシステム上で、ファイルが使っていたクラスタのステータスを未使用に変更する行為に過ぎない。言い替えると、ファイル管理用のセクタやブロックのデータを書き換えているだけで、ファイルの実体(データ)があったセクタやブロックのデータを「消去」しているわけではない。そのセクタやブロックに対し書き込みのコマンドが実行されるまで、データはそこにそのまま存在する。だからこそ、PCやHDDを捨てる際セキュリティのリスクが生じるし、ファイルを消すたびにRAIDのパリティをすべて再計算する必要はないのである。

　SSDを一般のユーザーが利用するようになって日が浅いせいか、SSDの利用法について都市伝説のようなものが多く存在する。たとえば、SSDはその使用量が全体容量の50%を上回らないようにした方がいいとか、SSDをフルに使うと遅くなる、といった話だ。

　しかし、上に述べたように、ファイルシステム上、どれくらいの容量を使っているかなどSSDは知るよしもない。頑張ってユーザーがファイルを消したところで、ユーザーによるファイルの消去はファイルシステムの管理領域に書き込みを行なう行為に過ぎない。ファイルシステムから見て、使用量が大きかろうと、少なかろうと、SSDが行なうのは指定されたブロック/セクタのデータを読み出すことと、そこにデータを書き込むこと(必要があればブロック単位で待避/消去/書き戻しを行ないつつ)に過ぎない。

　ヘッドのシークという時間のかかる物理動作を伴うHDDであれば、使用量が増えることで、最大シーク量が増える(最内周から最外周)ということも考えられるが、物理的な動作を伴わないSSDでは、ほぼ無視できる。もし使用量が増えて遅くなるのだとすれば、その主要な原因はファイルシステム上のオーバーヘッドであり、SSDとは無関係だろう。ファイルを消すことでユーザーから見たOS上の空き容量が増えたとしても、それはSSD上の消去済みブロックの数とは無関係だ。

　同様にデフラグという行為は、ファイルが利用するクラスタの並びを変更することでHDDのヘッドシークを最適化する行為であり、デフラグによりデータが消去されるわけではない。ヘッドシークのオーバーヘッドを持たないSSDでは、デフラグを行なうメリットはない。むしろ、無意味なストレージシステム内でのデータコピーにより、書き換え可能回数が減少する。

　基本的に、SSDの性能改善のために、ファイルシステム上からの操作でできることはほとんどない。もし何らかの理由(使用量ではなく、のべ書き込み量が一定量を越えた等)で、利用中に速度が低下するといった現象が生じたとしても、その対策はSSDのコントローラに何かをさせるか、コントローラを司るファームウェア(コントロールアルゴリズム)を更新することしかない。逆にファイルシステムからの操作で、SSDの性能に何か影響が生じたとすれば、そのSSDが採用するコントローラのアルゴリズムに何らかの欠点、あるいはクセがあるのではないかと思われる。

　SSDの寿命を長持ちさせる一番いい方法は何もしないことだ。ただし、いくら何もしないのがいいといっても、使わなければSSDを購入する意味もない。普通にSSDを使い、デフラグなど余計なことをしないのが一番だ。そういう意味では、ストレージに対して自動的にデフラグしようとするVistaは困りものだが、次のWindows 7ではこのあたりにも手が入ることになっている。機会があれば、Windows 7のSSD対応についても取り上げてみたい。