SSDのデフラグ：死なずに生き続ける神話

毎週どこかで、新品のSSDにデフラグをかけるツールのスクリーンショットが投稿され、投稿者は進行バーを誇らしげに眺めています。そのパスは1マイクロ秒もドライブを速くしません — そして動かした1ギガバイトごとに、ディスクが使う必要のなかったセルの消耗になります。

断片化がハードディスクを苦しめ、フラッシュを苦しめなかった理由

機械式ドライブでは、500の断片に分割されたファイルの読み取りは500回の物理的なヘッド移動を意味し、そのそれぞれにミリ秒のコストがかかります。デフラグはそれらの移動を1回のきれいなシーケンシャルリードにまとめるために考案されたもので、回転するプラッタでは利益が現実に、測定可能に存在しました。SSDにはヘッドもプラッタもありません。どのブロックも、物理的にどこにあろうと、同じマイクロ秒の小数で応答します。最近のNVMeドライブではランダムリードとシーケンシャルリードがほぼ互角で走るため、デフラグが解決するはずの問題自体がフラッシュには存在しないのです。

断片化は今も発生します — Windowsはそれを「誰も気にしない」という棚にしまっているだけです。ドライブが埋まるにつれてファイルシステムは大きなファイルを空きブロックに分割し続けますが、HDDならそれを感じるところです。SSDでは、断片化したファイルのコストは少し長くなるブロックアドレスのリストだけで、コントローラはそれを実質無料で解決します。

ドライブの最適化がSSDに実際にすること

ドライブの最適化(dfrgui)を開いて「メディアの種類」列を見てください。WindowsはSSDとHDDを区別し、設計上まったく別扱いにします。SSDに対するこのツールの仕事はTRIMです — 論理的に削除済みのブロックをコントローラに伝え、将来の書き込みがリード・モディファイ・ライトのサイクルを経ずに新しいセルへ直行できるようにします。これは本物のメンテナンスで、デフォルトで週次スケジュールとして走り、ボタンを押してもスケジュールがまだしていないことを追加しません。見かけ上の例外が一つ。システムの復元が有効な場合、Windowsは意図的にSSDにほぼ月1回の従来型デフラグパスを実行します。ファイルの断片化がしきい値を超えるとスナップショットが壊れるためです。このパスはMicrosoft自身のエンジニアリング上のトレードオフであって、あなたの環境のバグではありません。

何かを実行する前に、ドライブの最適化(dfrgui)の「メディアの種類」列を確認する。
スケジュールされた最適化はオンのままに — SSDにはデフラグではなくTRIMを送る。
TRIMは一度だけ確認:管理者権限のコマンドプロンプトで fsutil behavior query DisableDeleteNotify を実行 — 目指すのは 0。
見かけたドライブをすべてデフラグするサードパーティ製スイートは無視する;2005年時代のツールにおける「SSD対応」はマーケティングであってメディア検出ではない。
システムの復元が有効なら、履歴に残る月次のデフラグ記録に慌てない — それはボリュームスナップショットを生かしておくため。
消耗が気になるならSMARTツールで Total Host Writes と TBW を監視する:SSDの本当の走行距離計は断片化ではなくその数字。

SSDが本当に望むメンテナンス

フラッシュは断片化ではなく書き込みで消耗するので、正直なチェックリストは短いです。コントローラがデータをシャッフルする余地を持てるようドライブの10〜15%は空けておく、ベンダーが修正をリリースしたらファームウェアを更新する、そしてページファイルサイズのパニックを抱えて眠らないこと。コンシューマ向けドライブは、大半の家庭が10年の通常使用でも近づかないTBW予算を積んで出荷されます。デフラグパスは性能ゼロのためにすべてのブロックを動かします — 耐久性を費やして何も買わない、唯一の「メンテナンス作業」です。

だから古いアドバイスがフォーラムのスレッドで再浮上したとき、答えは1行に収まります。Windowsは2012年からこれを正しく処理している。いとこが覚えているあのデフラガーは、フラッシュには存在しない問題のための道具でした。