SSDの性能低下とその理由
SSDの速度は非常に魅力的で、その速さを一度体験してしまうとハードディスク(HDD)にはなかなか戻れません。SSDの高速性の大きな理由として、機械的な待ち時間が存在しないことが大きな要因を占めています。ハードディスクはいったん読み書きが始まればそこそこ高速なデバイスですが、目的のトラックまでヘッドを移動させる「シーク時間」と、そのトラック上で目的のセクターが来るまで待つ「回転待ち」時間に数十ミリ秒~百数十ミリ単位の時間を要するため、実質的なデータ転送時間以外のオーバーヘッドが大きく、これがSSDとハードディスクの速度の体感差を決めていると言っても過言ではありません。
その高速なSSDですが、実際にはいくつか弱点があることはこれまでの記事でも述べてきました。そのほとんどは記録媒体であるフラッシュメモリの仕様による制限で、「書き換え寿命」が存在すること、そして「書き換えが出来ない」特性によるものです。前者に関してはウェアレベリング機能によって、見かけ上問題ないレベルまで低減されていますが、後者はどうでしょうか。
「書き換えが出来ない」フラッシュメモリをうまく使うために、SSDでは工夫が凝らされています。通常、ハードディスクでは特定のセクターの内容を書き換える場合、そのセクターに「上書き」を行います。しかしフラッシュメモリは「書き換えが出来ない」デバイスなので、本来であれば次のようなステップを経る必要があります。(図1)
- 書き換えたいセクターを含むブロック全体をすべてバッファー(作業用メモリ)に読み出す
- バッファー上の目的のセクターを書き換える
- 該当ブロックをすべて消去する
- バッファーの内容をブロック全体に書き戻す
このようなアクセス方法では、たった1セクター(512バイト)の更新でもブロック全体(通常は数百キロ~数メガバイト)の読み出し・消去・書き込み作業が必要になり、さらにブロック消去にはミリ秒オーダーの時間を要するため、非常に長い時間を必要とします。またバッファー(作業用メモリ)を別途用意しなければなりません。
そこで実際のSSDでは、次のような方式が取り入れられています。
- あらかじめ消去済みのブロックを用意しておく
- 書き込み先のブロックから書き換えるセクター以外のデータをコピーする
- 書き換えたいセクター(新しいデータ)を消去済みのブロックに書き込む
- 書き込んだブロックを元のブロックと入れ替える(アドレステーブル更新)
- 用済みになったブロックを消去し、次の書き込みに備える
このように、空いているブロックをあらかじめ消去しておくことで、消去に要する時間を見かけ上隠蔽することができます。さらにアドレステーブルをブロック単位(最小消去サイズ)ではなくページ単位(最小書き込みサイズ)で管理することで、必要な書き換え範囲を最小化してさらなる高速書き換えを実現しているSSDもあります。
しかしいずれのケースでも、あらかじめ消去済みのブロックがあることが高速書き換えの条件となります。書き込みたいデータサイズ分の空きブロックがなかったり、あるいはまだ未消去の状態であった場合には、新たにブロックを消去する必要があるため、アクセス速度が大幅に低下してしまいます。さらにSSDを使い込んでいくと、ファイルのフラグメンテーションによるデータの断片化が増加し、多くの空きブロックを確保することが困難になってきます。
このような背景から、SSDは残り容量が少ない状態で使い続けると、大幅にアクセス速度、特に書き込み速度が低下し、本来の性能を発揮できなくなるという問題があります。
ファイル削除も初期化も効力がない
ではもし、そのような状態になったらどうすればいいでしょうか。 最初に思い浮かべるのは、不要なファイルを消して空き容量を確保することです。しかし実はこれは効果がありません。なぜかというと、OSによるファイルの削除はあくまでファイル管理情報、すなわちファイルの管理台帳からそのファイルの情報を削除するだけで、実際にはデータ実体は消去されないためです。(図2)そのファイルのデータが本当に消去されるのは、その場所に新たなデータが書き込まれる時、つまりデータ書き込みの際ですから、これではあらかじめ空きブロックを確保することは出来ません。
この問題は、SSDを初期化(論理フォーマット)しても完全には解決されません。通常の場合、OSによるストレージの初期化では、ファイルのデータ実体は消去されず、ファイル管理情報が初期化されるのみだからです。さらにSSDの全領域を完全消去(ゼロ消去や完全消去ソフトの利用など)しても、残念ながら問題の解決にはなりません。なぜならSSDにとっては、OSによるファイルの書き込みも、完全消去でのデータ書き込みも、すべて有効なデータの書き込みとして認識され、両者が区別されないためです。
この状況を解決するには、SSD専用のメンテナンスツールが必要です。メンテナンスツールにはさまざまな種類がありますが、多くの場合これらのツールは各SSDモデルのハードウェア機能を利用するため、適応可能な機種に制限があります。通常はSSD製品のメーカーからユーティリティーなどが提供されており、ファイルシステムに応じたオプティマイザー機能(不要ブロックの消去)およびSSD全体の完全初期化(Secure Erase)などの機能を提供しています。(図3)しかしこれらの機能は利用できるOSの種類に制限があったり、その存在自体がほとんど知られていなかったりするため、有効に利用されているとは言えない状況です。
「Trim命令」の功罪
実はこのような問題は「OSが削除した領域(データ)をストレージに伝える仕組みがない」ことに起因しています。つまりストレージのデータが更新された場合に、それが必要なデータの書き込みなのか、それとも不要なデータの削除のためのものなのか、の区別が従来のストレージインターフェースには存在しなかったのです。
それは磁気ディスクというストレージデバイスがそれを必要としてなかったためなのですが、特性の異なるフラッシュメモリではこのことが問題になっているわけです。
そこでこの問題を解決するための手段として、ストレージインターフェースに用意されたのが「Trim命令」です。Trim命令は、あらかじめ消去しても良いセクターをSSDに告知し、SSDはこれに基づいてブロックを消去して空きブロックを作ります。Trim命令が有効な環境下では、ファイルを削除するとその分空きブロックが発生し、速度低下を回避することができます。
このコラムを執筆している段階で、Trimに対応しているのはWindows OSでは7以降、Mac OS Xでは10.7(Lion)以降となります。(図4,図5)ただし、OSの種類やバージョンによっては手動での設定が必要なものがあります。また当然ながらSSDデバイスがTrim命令に対応したモデル(ファームウェア)であることが必須となります。
さて、このように良いことずくめに見えるTrim命令ですが、データ復旧に於いては、障害内容次第でこの機能が「弊害」となります。
Trim命令が機能していない従来の環境(ハードディスクやUSBメモリなど)では、OSはファイルを消去してもデータ実体を消去しませんでした。(図2)このためデータ実体が完全に失われるのは、同じセクターに新しいデータが上書きされた場合などに限定されていました。データ復旧ではこの仕組みを利用することで、「誤って消してしまったファイル」「初期化してしまったストレージ」「障害によって見えなくなったファイル」なども、復旧の可能性が残されていました。
しかしTrim命令が有効な場合、OSが「消して良し」としたデータは二度と戻ってくることはありません。OSが削除したファイルはSSDが消去して再利用に備えるため、データ実体が残留する可能性は無くなるためです。従ってこの機能を有効にする場合(有効になっている場合)には、従来よりいっそう定期的なバックアップが重要になることを忘れないで頂きたいと思います。