CrystalDiskMarkとTrim

SSDの速度を測る場合、その前の使い方（とくにライト）が影響するのはよく知られていて、Secure EraseやTrimでクリーンな状態にした後、ライトを繰り返して乱れた状態が一定以上に達すると速度低下が起こったりする。

そうした影響をなるべく防ぐための工夫は色々あり得るが、理由あって同じSSDを連続して計測する場合、その間にTrimをかけるのはどうかというアイデアを持っていた。で、最近はTrimもすっかり一般化したことだし、CrystalDiskMarkを使って試してみた（結果的には不発）。

1. 計測方法

CrystalDiskMarkを連続して実行し、その実行間にTrimをかける場合とかけない場合で差が出るかを見る。

環境

• PC: ThinkPad X61s
• SSD: Intel X25-M G2 80GB（OSなどで全容量の60%が埋まった状態）
• OS: Windows 8 Pro 64bit（ドライバーはすべてOSの自動インストール）

方法

• CrystalDiskMark（3.0.2）を4GBで空のNTFSのパーティションに対し、テスト種類All、テスト回数9、テストサイズ2000MBの設定で30回実行。
• 実行間には1分の間隔を挟み、Trimをかける場合は前回の実行直後にこのパーティションを対象に実行（先に示した方法で）。
• どちらの場合も最初の実行前にTrimをかける。
• ライト量の確認のため、一連の実行の直前と直後にCrystalDiskInfo（5.1.0 RC2）でHost Writes（総書き込み量）を取得する。Host Writesはあくまでホスト側（PC本体側）から見たライト量なので、SSD内部のライト量には直結しないが、参考にはなる。なお、この間は他のライトを伴う作業はしない（OSが勝手に行うものは除く）。

SSDのX25-Mには今更感があるが、これまでの実績から見て余裕を大幅に残したまま引退となるのは確実なので、多少消耗させてもよしという事情も背景にあり。

また、こういう計測をきっちり進めていくのは結構面倒なものだが、そこはDiskMarkStreamで楽々（自画自賛）、というよりDiskMarkStreamがあったからやる気になったというべきか。

2. 計測結果

先にどれぐらいのライト量になったかを確認すると、まずTrimをかけなかった場合の実行前と実行後のCrystalDiskInfoの結果。

次にTrimをかけた場合の実行前と実行後。

（注）E9が96から95に落ちているが、96になったのはかなり以前のことなので、意味はない。

一番最初のHost Writesの生の値は76752で、この16進数を10進数に換算すると485202になる。この値は65536セクタ、すなわち65536×512÷1024^2＝32（MiB）ごとに1増えていくので、容量としては以下のようになる。

485202×32＝15526464（MiB）≒14.807（TiB）

同様にそれぞれの値を計算し、実行前と実行後の差から増加量を求めると、

	生の値		換算後		増加量
	16進数	10進数	(MiB)	(TiB)	(MiB)	(GiB)
Trimをかけなかった場合
実行前	76752	485202	15526464	14.807	984320	961.25
実行後	7DF7A	515962	16510784	15.746
Trimをかけた場合
実行前	7E15F	516447	16526304	15.761	978496	955.56
実行後	858D1	547025	17504800	16.694

これらの増加量はそれぞれ9×30＝270回分のテストによるものなので、1回のテストの増加量は約3.54～3.56GiBとなるが、これはテストサイズが2GBということを考えるとこんなものかと思う。どちらも全増加量は1TiB近くに上っている。

ここで、X25-M G2で速度低下を起こした後にTrimで回復した例（SSDの性能低下とTrimの効き具合を大検証）を見ると、一旦容量の90%までライトで埋めている。

方法は違うが、この全増加量は全容量80GBの12倍に当たるので、変化を起こさせるに十分なライト量ではないかと思う。というか思った、が……。

結論から言うと、CrystalDiskMarkの結果は不発だった。

まずTrimをかけなかった場合、30回の実行中、ばらつきは多少あるが、有意な変化といえるものはなかった。以下は1回目、15回目、30回目のもの。

一応、次にTrimをかけた場合、同様に以下。

こちらも有意な変化はない（Trimが効果を発揮していれば変化はなくて問題ないわけだが）。

3. まとめ

1TiB近くのライトをもってして速度低下を起こせなかったのは誤算だったが、CrystalDiskMarkを連続実行しても再度Trimが必要になるような速度低下は起こらないことが確認できたので（X25-M限定でだが）、それはそれでよしとする。

しかし……、この結果を見るに、実使用でもTrimを頻繁にかける必要はない気がしてきた。1TiBなんて普通に使う限り数箇月たっても到達しない量だと思うし。

CrystalDiskMarkと雫ちゃんと

Windows 8発売の26日（というか25日深夜）にCrystalDiskMarkにも3.0.2で
Shizuku Editionが登場したので、早速、当然にDiskMarkStreamで対応。

通常版との違い、サイズなどは自動で判別する。

しかし、この麗しい姿といい、青白基調の流麗なデザインといい、これを目にすると、殺伐としたベンチマークの世界（ついあれもこれもとデータを取ろうとして、環境を整えて計測しているうちに消耗戦になってきて、あまり美しい状況にはなり難い）に涼風が吹き込まれる、というより、まとめて毒気を飛ばされてしまう危険性がある……。

その意味では機械的なマクロツールであるDiskMarkStreamはそぐわない気もするが、多少矛盾をはらんでいた方が面白い、ということにしておこう。

なお、通常版のテーマのShizukuでもエッセンスは共通。

ちなみに、Windows 8ではSSDのドライブに対してコマンドプロンプトから簡単にTrimを発行できるので（Defragの/Lオプション）、DiskMarkStreamのバッチ実行機能を使えばテスト間にTrimをすることができる。

[参考]
How to Use "Optimize Drives" to Defrag HDD and TRIM SSD in Windows 8

このためのバッチファイルの内容は以下のようなもの。対象のドライブはDで、結果は後から確認するためにresult.txtというファイルに出力している。

C:\Windows\System32\Defrag.exe D: /L >> C:\Work\result.txt

ただし、Windows 8が64bit版の場合、このパスではDefrag.exeがDiskMarkStreamから見えない問題がある。これは32bitのソフト（DiskMarkStreamは32bit）を64bitのWindows上で実行するときに起こり得る問題で、この場合は以下のようになる。

C:\Windows\Sysnative\Defrag.exe D: /L >> C:\Work\result.txt

[参考]
How to Suppress and Bypass System32 File System Redirect to SysWOW64 Folder with Sysnative

どちらの場合もDefragは管理者として実行する必要があるので、DiskMarkStreamも起動時に管理者として実行する必要がある（DiskMarkStream自体は管理者として実行される必要はないが、バッチ実行を管理者として行うトリガーとし、かつバッチ実行の度にUACの承認を求められるのを避けるため）。

[追記]

Windows 8におけるTrimについて、Microsoftの担当者（Kiran Bangalore）が答えていた（Defragging SSDs a default?）。Windows 8では（Windows 7と同様に）ファイルの削除、移動の際にTrimを発行しているが、SSDの方がリアルタイムに処理できない場合を考えて、「ディスクの最適化」で定期的にTrimを発行するようになっている（これがデフォルト）とのこと。