マイクロソフトのEngineering Windows 7 ブログ : Storage

ソリッドステートドライブ (SSD) に関するサポートと Q&A

e7blog — Mon, 25 May 2009 06:24:49 GMT

プライマリ ストレージとしてソリッド ステート ドライブ (SSD) が広範囲に採用される可能性について、特にノート PC への採用や、サーバーにどう応用していくかということについて、関心が高まっています。あらゆる新技術がそうであるように、その導入時には、使用されるテクノロジのパフォーマンス特性の結果として、全体的なシステム (OS、デバイスのサポート、アプリケーション) に当てはめる場合、しばしば再考する必要があります。この投稿では、SSDの最新世代に合わせて Windows 7 を調整してきたことについて見ていきます。これは非常に速く変化する分野であり、今後も Windows を調整するいろいろな方法が存在するだろうと考えています。また、このテクノロジが進化し続け、新たなトレードオフをもたらしたり、基礎となる仮定を覆したりすることを期待しています。Michael Fortin が、ストレージおよびファンダメンタルズ チームの多くの人々からの援助を受け、この投稿を執筆しました。 --Steven

今日のソリッドステートドライブ (SSD) の多くは、パフォーマンスの向上、より一貫した応答性、バッテリ寿命の増加、優れた耐久性、より迅速なスタートアップ時間およびノイズと振動の低減を約束します。価格が急激に低下したことにより、多くのアナリストは、従来の回転型ハードディスクドライブ (HDD) の代わりに SSD を搭載した PC の販売がますます増えるだろうと予測しています。

Windows 7 では、SSD のオペレーティング特性を念頭に置いて、数々のエンジニアリングの取り組みに焦点を当ててきました。その結果、Windows 7 のデフォルトの動作は、ユーザーの介入を必要とせずに SSD 上で効率的に機能します。Windows 7 の動きがどのように SSD 上で効率的に機能するよう自動的に調整されているかを探る前に、SSD のオペレーティング特性の概要について見てみましょう。

ランダム読み取り: SSD にとって、とても良い面

SSD はランダム読み取りが非常に高速になる傾向があります。回転ディスクヘッドを配置するために必要な機械的な作業が不要なため、ほとんどの SSD は従来の HDD をはるかに凌駕します。その結果、優れた SSD は、従来の HDD のほぼ 100 倍の速さである 4 KB のランダム読み取りを実行できます (約 1 ミリ秒の 1/10 vs. 約 10 ミリ秒)。

順次読み取りと書き込み: 良い面

順次読み取りと書き込みの操作は、”非常に良い” から ”最高” の間のレベルです。フラッシュメモリは同時に構成でき、データはチップ間に分散するため、今日のより優れた SSD では、200 MB/秒を超える速度で順次読み取りを実行できます。これは、多くの 7200 RPM ドライブが提供する速度のほぼ 2 倍にあたります。順次書き込みについては、一部のデバイスでは従来の HDD の速度をはるかに上回り、大多数の SSD では HDD と比較して大変良い動作をします。今日の市場では、順次書き込みの速度は SSD の間でかなりの差があります。あるものは通常の HDD のパフォーマンスをはるかに上回り、他のものはわずかに遅れをとり、少数ながら比較して劣るものもあります。

ランダム書き込みとフラッシュ: 効果はさまざま

順次書き込みの速度の違いは、興味深い点ではありますが、ほとんどのユーザーにとって、全体的なパフォーマンスにおいては、ランダム書き込みほどには顕著な相違点とはならないでしょう。

ランダム書き込みにかかる長い時間とはどのくらいでしょうか? 平均的な HDD は通常 4 KB のランダム書き込みを、7 ～ 15 ミリ秒で回転メディアに移動させます (これは許容しがたいことが分かっています)。その結果、ほとんどの HDD には 4 MB、8 MB、またはそれ以上の内部メモリがあり、7 ～ 15 ミリ秒をずっと待機する代わりに、少量のランダム書き込みのキャッシュを試行します。読み取りをキャッシュすると、バイトが回転メディアに移動されていなくても、OS に処理が終わったことを返します。通常このようなキャッシュされた書き込みは、数百 "マイクロ" 秒 (つまり、実際の回転メディアへの書き込みの、10 倍や 20 倍の速さ) で完了します。何千もの遠隔測定による何百万ものディスク書き込みを見てみると、4 KB 以下の IO の 92% で 1 ミリ秒未満、80% で 600 マイクロ秒未満、そして驚異的な 48% は 200 マイクロ秒未満しかかかっていませんでした。これはキャッシュの威力です!

時折、HDD が大量のランダム書き込みやフラッシュをうまく処理できない場合があります。ドライブがあまりに長い間、大量にキャッシュすると、フラッシュの際に大量の作業のバックログを完了するのに時間がかかり、問題となることが分かりました。これらのフラッシュおよび関連する IO は、応答時間を大幅に増加させることがあります。一部のデバイスでは、個々の IO を完了するのに 0.5 秒～ 1 秒かかり、より一貫した応答状態に戻るには数十秒もかかります。応答性が苦痛を感じるレベルにまで低下するため、ユーザーにとって耐え難いものとなり得ます。考えてみてください、単一 I/O の応答時間は、200 "マイクロ" 秒から、途方もない 1,000,000 "マイクロ" 秒 (1秒) にまで及ぶのです。

現実的なワークロードで示すと、最悪の SSD の場合、個別のランダム書き込みおよびフラッシュ要求を完了するのに 0.5 秒～ 1 秒と、非常に長い IO 時間が発生していることがわかりました。多くのワークロードにとってこれはひどく、システム全体が不安定、応答がない、または遅すぎるといった状態になります。

ランダム書き込みとフラッシュ: なぜそれほど難しいのか?

多くの人にとって、電子的アクセスを行う SSD で、従来の機械的アクセスを行う HDD よりもランダム書き込みの問題が発生しやすいという説は、初めは理解しがたいかもしれません。SSDは回転ディスク上のトラックでディスクヘッドをシークおよび位置付けする必要がないのです。それなのに、なぜランダム書き込みが、そのような難題となるのでしょうか?

この疑問に答えるにはかなりの説明を要しますが、Anand 氏の記事で詳細の大部分をカバーしています。興味のある方は、時間をとってこの記事や優れた USENIX ペーパーをお読みになることを強くお勧めします。同じ資料をカバーしすぎることを避けるため、ここではいくつかの要点のみを取り上げます。

ほとんどの SSD は、フラッシュ セル (SLC または MLC のいずれか) で構成されています。DRAM から SSD を構築することは可能です。これらは、非常に高速になりますが、非常に高価で消費電力も大きくなります。これらが使用されることは比較的まれであるため、はるかに一般的な NAND フラッシュベースの SSD を中心にディスカッションを行います。未来の SSD は、フラッシュだけでなく他の不揮発性メモリテクノロジを活用するかもしれません。
フラッシュ セルは実際には電子にとってのトラップであり、そして電子はトラップされることを好みません。1 つのフラッシュセルに 100 個の電子を配置することが 0 のビット値を構成し、それより少ない場合は値が 1 になる場合、コントローラーロジックは 80 から 120 の間をビット値 0 の許容範囲と見なす必要があるでしょう。ある電子はトラップを回避したり、他の電子は近くのセルを埋めようとしてトラップにはまったりする場合があるので、許容範囲は必要です。その結果、データ整合性を保証するには非常に高度なエラー修正ロジックが必要となります。
フラッシュ チップは、ブロック、ダイ、プレーン、およびパッケージなど、複雑な配列で編成される傾向があります。サイズ、配列、並列処理、消耗、相互接続、および転送速度の特性は、大幅に異なります。
フラッシュ セルは、書き込む前に消去される必要があります。フラッシュセルを使用する前に、そこに残留電子がないと決め込むことはできないため、電子を注入する前にセルを消去する必要があります。消去は大規模なスケールで行われ、1 つのセルを消去するのではなく、大きなセルのブロック (128 KB 相当など) を消去します。消去時間は通常長く、1 ミリ秒またはそれ以上になります。
フラッシュは消耗します。ある時点で、フラッシュセルは電子に対するトラップとして機能しなくなります。頻繁に更新されるデータ (ファイルシステムのログファイルなど) が同じセルに常に格納されていると、これらのセルは、読み取り専用のデータを含むセルよりも早く消耗します。書き込みをデバイスのセル全体に分散するよう、フラッシュコントローラーファームウェアは消耗平均化ロジックを採用しています。適切に行われれば、ほとんどのデバイスは通常のデスクトップ/ラップトップワークロードで何年も機能します。
電子を高速でトラップし、しかもそれをエラーなしで行い、またデバイスが平均的に消耗するようにするには、非常に有能なデバイス物理学者と、ゆるぎないエンジニアリングが必要となります。これまでのところ、どの SSD メーカーも、これをうまくやる方法を見つけ出せていないようです。

時間とともに起こるパフォーマンス低下、消耗、および Trim

先にも述べたように、フラッシュブロックおよびセルは、新しいバイトを書き込む前に消去する必要があります。その結果、新しく購入されたデバイス (あらかじめすべてのフラッシュブロックが事前消去されている) は、かなりの使用期間を経た後よりも、購入時の方がはるかに良く動作します。私たち自身このパフォーマンス低下を観察していますが、これが致命的な問題であるとはみなしません。実際、ベンチマーク測定によってでなければ、ユーザーが通常の使用中にパフォーマンスの低下に気付くことはないでしょう。

もちろん、デバイスメーカーと Microsoft は、可能な限り最良のパフォーマンス特性を維持したいと願っています。より優れた SSD メーカーが、通常の使用時にパフォーマンスに不利な条件が大部分は実現されないようあらかじめブロックを消去することにより、または書き込みが短期に大量に発生した場合に十分な予備領域を維持することにより、経年劣化の問題を克服しようと努めていることは、想像に難くありません。企業向けに設計された SSD ドライブでは、高度に持続する書き込みパフォーマンスを長期間提供するために、50% もの領域が予約されています。

上記に加えて、Microsoft と SSD メーカーは、Trim 操作を採用しています。SSD が ATA プロトコルの Data Set Management 命令の Trim 属性をサポートする場合、Windows 7 では,

ファイルが削除されファイルをバックアップする SSD ページを消去しても安全になると、NTFS ファイルシステムはデバイスに対して新しい操作を発行するよう ATA ドライバーに要求します。消去されたページは再使用可能なので、後続する書き込みでブロックの消去操作は必要ないことを前提として、この情報により SSD は該当するブロックを必要に応じて (かつ頻繁でなく) 消去することを計画できます。

付加価値として、Trim 操作により、多数のマージ操作を発生させる必要がなくなるので、SSD の消耗を軽減できます。たとえば、128 KB のファイルを含む、1 つの 128 KB の SSD ブロックについて考えてみましょう。ファイルが削除され、Trim 操作が要求されると、SSD では、その SSDブロックからのバイトと、そのブロックに後で書き込まれるその他のバイトとが混在されなくなります。これによって消耗が減少します。

Windows 7 では、ファイル削除操作のためだけに Trim 操作が要求されるわけではありません。Trim 操作は、Format や Delete など、パーティションレベルおよびボリュームレベルのコマンド、切り捨てや圧縮に関連したファイルシステムコマンド、およびシステムの復元（または、ボリュームスナップショット）機能と完全に統合されています。

Windows 7 の最適化とデフォルト動作のまとめ

前述のように、今日の SSD はすべて、ディスク書き込みおよびディスクフラッシュに関しては、まだまだ改善の余地があります。Windows 7 は、このような今日の SSD 上でも、ある程度うまく動作します。これは、私たちが書き込みとフラッシュの頻度を減らすよう多数のエンジニアリング上の変更を行ってきたからです。これは、従来の HDD にも役立ちますが、今日の SSD 上で特に有用です。

Windows 7 は、SSD システムドライブ上ではディスク最適化を無効にします。SSD はランダム読み取り操作できわめて優れたパフォーマンスを発揮するため、ファイルの最適化は、最適化によって生成される追加のディスク書き込みを埋め合わせるほど有用ではないからです。この後の FAQ セクションに、追加の詳細情報があります。

デフォルトでは、ランダム読み取り、ランダム書き込み、およびフラッシュの優れたパフォーマンスを備えた SSD 上では、Windows 7 は Superfetch、ReadyBoost、起動およびアプリケーション起動プリフェッチを無効にします。これらのテクノロジはすべて、ランダム読み取りのパフォーマンスが主要なボトルネックとなりやすい、従来の HDD のパフォーマンスを向上させるために設計されたものです。詳細については以下の、よく寄せられる質問のセクションを参照してください。

SSD は、オペレーティングシステムのパーティションが SSD 配列を考慮して作成される場合に最高のパフォーマンスを実現する傾向があるため、Windows 7 のパーティション作成ツールはすべて、新規に作成したパーティションを適切な配列で配置します。

よく寄せられる質問

よく寄せられる質問を取り上げる前に、私たちはモバイルおよびデスクトップ PC (そして、エンタープライズサーバー) に入っている SSD の将来は、私たちにとって非常に明るいと信じていることをみなさんに伝えたいと思います。SSDは、パフォーマンスの向上、より一貫した応答性、バッテリ寿命の増加、優れた耐久性、より迅速なスタートアップ時間およびノイズと振動の低減を約束します。価格が順調に低下し、品質が向上するにつれ、ますます多くの PC が従来の回転 HDD に代わって SSD を搭載して販売されることでしょう。それを念頭に置いて、Windows 7 ユーザーに SSD の優れたエクスペリエンスを保証するために、適切なエンジニアリングの取り組みを行いました。

Windows 7 は Trim をサポートしますか?

はい。詳細については、上記を参照してください。

SSD 上でディスク最適化はデフォルトで無効になっていますか?

はい。最適化の自動スケジュールは、自身を SSD として宣言するデバイス上のパーティションを除外します。また、システムディスクに8 MB/秒のしきい値を越えるランダム読み取りのパフォーマンス特性がある場合も除外されます。このしきい値は内部分析によって決定されました。

市場に存在する SSD の大半は、自身を SSD として適切に識別していない、という事実に対処するため、ランダム読み取りのしきい値テストが最終製品に追加されました。8 MB/秒はやや控え目の速度です。私たちがテストした HDD はどれも 8 MB/秒にはるかに及びませんでしたが、テストした SSD はすべてそのしきい値を越え、そのパフォーマンスは 11 MB/秒～ 130 MB/秒の範囲に及びました。テストされた 182 台の HDD のうち、わずか 6 つの構成だけがランダム読み取りテストで 2 MB/秒を超えました。その他の 176 台は、0.8 MB/秒～ 1.6 MB/秒の間でした。

Superfetch は SSD 上で無効にされますか?

はい、SSD を備えた大半のシステムで無効になります。

システムディスクが SSD であり、その SSD がランダム読み取りで十分に動作し、ランダム書き込みまたはフラッシュにおいてもパフォーマンス上の目立った問題点がない場合、Superfetch、起動プリフェッチ、アプリケーション起動プリフェッチ、ReadyBoost、および ReadDrive はすべて無効になります。

最初は、すべての SSD 上でこれらの機能がすべてオフとなるよう構成しましたが、一部のシステム上でかなり顕著なパフォーマンス低下に直面しました。このような低下を引き起こす原因として、一部の第一世代 SSD には深刻なランダム書き込みとフラッシュの問題があり、それによって結果的に長時間ディスク読み取りがブロックされていたことを発見しました。そして、Superfetch および他のプリフェッチ機能を再度有効にすると、主要なシナリオにおけるパフォーマンスは著しく向上しました。

SSD 上でのファイルおよびディレクトリの NTFS 圧縮は推奨されますか?

ファイルの圧縮は領域の節約に役立ちますが、圧縮と展開にかかる労力によって、余分な CPU サイクルとその結果としてモバイルシステムでは電力が必要となります。とは言え、めったに変更されないディレクトリおよびファイルでは、圧縮は貴重な SSD 領域を節約する優れた方法であり、領域が本当に貴重である場合には、良いトレードオフになり得ます。

ただし、頻繁に書き込まれるファイルまたはディレクトリを圧縮することはお勧めできません。ユーザー自身のドキュメントディレクトリおよびファイルはまだよいですが、インターネット一時ディレクトリやメールフォルダーは、突発的に大量のファイル書き込みが発生するため、圧縮には適しません。

Windows Search Indexer は SSD 上では違った動きをしますか?

いいえ。

BitLocker の暗号化プロセスは SSD 上で動作するよう最適化されていますか?

NTFS では「はい」です。BitLocker がパーティション上で最初に構成されるとき、パーティション全体が読み取られ、暗号化され、書き直されます。これが終わると、NTFS ファイルシステムは、SSD が動作を最適化できるように Trim コマンドを発行します。

SSD を含むドライブ上で BitLocker を有効にする場合、データプライバシーと保護に十分ご注意ください。

SSD上で設定したとき、Media Center で何か特別なことができますか?

いいえ。SSD は従来の HDD よりも利点がありますが、SSD は HDD に比べて GB あたりの単価が高くつきます。ほとんどのユーザーにとって、メディアの録音のために最適化された HDD の方がよりよい選択肢でしょう。なぜなら、メディアの録音および再生のワークロードは事実上連続して行われるためです。

書き込みキャッシュは SSD 上で機能しますか? また、SSD で書き込みキャッシュがサポートされる場合、Windows 7 で特別な機能がありますか?

一部の SSD メーカーは、単なる制御ロジック以上の理由でデバイスに RAM を組み込んでいます。それらのメーカーは、書き込み、そして恐らく読み取りをキャッシュすることで、従来のディスクの動作を模倣しているのです。揮発性メモリ内でキャッシュ書き込みを実行するデバイスについては、Windows 7 では、フラッシュコマンドおよび書き込み順序が少なくとも従来の回転するディスクと同じ程度に保持されると考えています。また Windows 7 は、書き込みキャッシュを無効にするユーザー設定が、従来のディスク上でそうであるように、書き込みキャッシュ SSD によっても受け入れられます。

RAID 構成は SSD 上で機能しますか?

はい。HDD RAID 構成によって得られる信頼性およびパフォーマンス上の利点は、SSD RAID 構成によっても実現できます。

ページ ファイルは SSD 上に配置する必要がありますか?

はい。ほとんどのページファイル操作は、小規模なランダム読み取りまたはより大規模な順次書き込みです。これらのどちらのタイプの操作も、SSD で適切に処理できます。

何千もの遠隔測定データを観察し、ページファイルの読み取りと書き込みに注目した結果、次のことがわかりました。

pagefile.sys 読み取りは、約 40 対 1 で pagefile.sys 書き込みを上回る。
pagefile.sys 読み取りサイズは、通常非常に小さく、67% が 4 KB 以下、88% が 16 KB 未満。
pagefile.sys 書き込みは比較的大きく、62% 以上が 128 KB、45 % がちょうど 1 MB。

実際、通常のページファイルの参照パターンおよびそれらのパターンに対する SSD の持つ有利なパフォーマンス特性を考えると、SSD 上に配置するのにページファイルより適したファイルはほとんどありません。

休止状態のファイルと SSD に関して、何か懸念事項がありますか?

いいえ、hiberfile.sys は、連続して大きなブロックで書き込みおよび読み取りされるため、HDD または SSD のどちらにも配置できます。

SSD パフォーマンス特性に対応するため、どのような Windows エクスペリエンス インデックスの変更が行われましたか?

Windows 7 では、新しくランダム読み取り、ランダム書き込みおよびフラッシュの評価を行います。より優れた SSD は 7.9 中 6.5 以上のスコアを出せます。その範囲に含まれるには、SSD には高いランダム読み取り速度が必要であり、フラッシュおよびランダム書き込みワークロードからの復帰も早くなければなりません。

Windows 7 Beta の期間では、ランダム書き込みおよびフラッシュの評価時にディスク (SSD または HDD) が十分に動作しなかった場合、1.9 や 2.9 といったスコアに制限されていました。この点についてのフィードバックはかなり一貫しており、大半のユーザーが、制限のレベルが行き過ぎだと感じていました。その結果、パフォーマンス上の問題のある SSD は、新しく追加された 6.0+ および 7.0+ の範囲にはしないことにしました。すべての評価にわたって高パフォーマンスを出せない SSD は、Windows Vista と同様の方法で採点されますが、Windows 7ではランダム読み取りパフォーマンスには寄与することはありません。

ディスク最適化 – その背景と Windows 7 の開発における改善

e7blog — Tue, 17 Feb 2009 12:09:05 GMT

皆さんによく知られているトピックの 1 つは (私は、それについて100通以上の電子メールを受け取りました!)、Windows 7 のディスク最適化ユーティリティを改善してほしいというものです。私たちはそれに取り組み改善しました。また、ブログのコミュニケーションによって、私たちは、皆さんからご指摘があったいくつかのことを理解しました。それは素晴らしいことです。そしてこれは思っている程簡単なことではありません。私たちは、最適化に多くの歴史があることを知っています。そして「ずっと以前は」、それがほとんどのユーザーにとっていかに重要なパフォーマンスの問題点であったか、そして、さらに大きなミステリーであったかということを知っています。コンピューターの動きが遅い場合に、特殊な最適化プロセスを経なければならなかったことが、広く知られるようになりました。Windows Vista では、ユーザーの皆様に余計なご心配をおかけしてはならないということを意識し、プロセスを自動操縦下に置くことを決定しました。実際に、これは実現されていますが、少なくともプロセスの自動実行という制限があります (つまり、毎晩コンピューターの電源が切られると、動作しません)。実行中の最適化の状態に関してより多くの情報を望む知識の豊富な方々から、多くのフィードバックを受け取りました。また、プロセスの管理全体に関して、より多くの柔軟性を望む方々からもフィードバックを受け取りました。この投稿では、そのフィードバックに基づいて行った変更の詳細を説明します。また、受け取ったメールやコメントを読ませていただいたときに、プロセス、パフォーマンス向上の認識と現実、さらに特定の向上点に関してより詳しく知ることは価値のあることだと考えました。この投稿は Rajeev Nagar および Matt Garsonによるものです、両名とも私たちのファイルシステムフィーチャーチームのプログラムマネージャーです。 --Steven

このブログでは、Windows 7 のディスク最適化に焦点を当てています。Windows 7に導入された変更を説明する前に、断片化とは何か、およびその適用性について簡単に説明しましょう。

ハードディスクと CPU の間のハードウェアパイプラインを含むストレージおよびメモリ階層内では、ハードディスクは動作が遅く、待機時間が長くなっています。ハードディスクとの間での読み取り/書き込み時間は、ミリ秒単位で測定されます (通常2～5ms)。これは、データがプロセッサの L1 メモリキャッシュに格納されると (平均で) 10 ナノ秒未満でデータを計算することができる、2 GHz CPU と比較すると非常に高速に思えます。

このパフォーマンスギャップが増加しているのは、過去 20 年間に限られます。下記の図は注目すべきものです。

要するに、これらの図は、ディスク容量は増えていますが、データを転送したり新しいデータを書き込む能力は、同等な割合で増えていないということを示しています。したがって、ディスクはより多くのデータを取り込めるようになっていますが、それを読み書きするのにより長い時間がかかるのです。その結果、高速な CPU は、データが処理できるようになるのを待つことになり、比較的アイドル状態が長くなります。

コンピューター科学における重要な研究では、システム全体の I/O パフォーマンスを向上させることに焦点を当てていました。その結果、次の2つの原則が立てられ、オペレーティングシステムはこの原則に従おうとしています。

I/O動作をより少なくする、つまり、ディスクの読み取り/書き込み要求が発行される回数の最小化を試みる。
I/Oが発行される場合、なるべく多量のデータを転送する、つまり大量に読み書きする。

両方の規則には、合理的に考えると、簡単に理解される次のような論理的根拠があります。

I/O が CPU によって発行されるたびに、複数のソフトウェアおよびハードウェアのコンポーネントが、要求を満たすために処理をしなければなりません。これは、待機時間 (つまり、要求が満たされるまでの時間の長さ) の増大に寄与します。データを読み取る際、ユーザーはこの待機時間にしばしば直面し、期待が満たされない場合には、ユーザーのフラストレーションの増加につながります。
機械的部品の動きは、発生する待機時間に本質的に寄与します。ハードディスクの場合、「回転時間」(ディスクヘッドの下にディスクの適切な部分がくるように、ディスクプラッタが回転するのに要する時間)、および「シークタイム」(ヘッドを位置決めして対象のトラックを読み取り/書き込みできるようにするために、ヘッドが移動するのに要する時間) が大きな要因となります。大量に読み書きすることによって、発生したコストが償却され、より多くの量のデータが転送されます。言いかえれば、「1つのユニット当たりの」データ転送コストが減少します。

NTFS などのファイルシステムは、上記の規則を満たそうとして、非常に迅速に動作します。例として、私がイーグルス (私の今までで最もお気に入りバンドの 1 つ) の「ホテルカリフォルニア」という歌を聞く場合を考えます。私がNTFS ボリュームに 5MB のファイルを最初に保存する時、ファイルシステムは、ディスク上に 5MB のデータを「まとめて」配置することができるように十分な隣接した空き領域を見つけようとします。なぜなら、論理的に関連するデータ (例えば同じファイルあるいはディレクトリのコンテンツ) は、ほぼ同時に読み取られたり書き込まれたりする可能性が高いからです。たとえば、私は通常、「ホテルカリフォルニア」の歌の一部だけでなく歌全体を再生します。歌が再生されている 3 分の間に、ファイル全体が消費されるまで、コンピューターは、ディスクからのこの「関連するコンテンツ」(つまりファイルのサブ部分) の部分をフェッチするでしょう。データがまとめて配置されていることを確かめることによって、システムは、大量の読み取り要求 (多くの場合、まもなく使用されるだろうという予想される読み取り前データ) を発行することができ、その結果、ハードディスクドライブコンポーネントの機械的な動きを最小限に抑え、発行される I/O を少なくすることもできます。

ファイルシステムが、データを隣接させて配置することを試みるとすれば、断片化はいつ生じるのでしょうか。格納されたデータに変更を加えると (例えば、コンテンツの追加、変更、削除)、ディスク上のデータレイアウトに変化が生じ、断片化につながる可能性があります。たとえば、ファイルの削除を行うと、必然的に、領域の割り当てが解除され、結果として割り当てられた領域マップの中に「穴」が生じます。これが、私たちが「使用可能な空き領域の断片化」と呼ぶ状態です。時間が経つにつれて、隣接した空き領域は見つけるのが困難になり、新しく格納されたコンテンツの断片化につながります。明らかなことですが、削除が断片化の唯一の原因ではありません。上記したように、コンテンツの位置の変更や、既存のファイルへのデータを追加などの他のファイル操作によっても、最終的に同じ状態になる可能性があります。

そうすると、最適化はどのように役に立つのでしょうか。本質的には、最適化とは、データをあちこちに移動して、もう一度ハードディスク上に、より最適に配置することであり、下記の利点を提供します。

断片化された、論理的に関連するどんなコンテンツでも、隣接させて配置することができる
空き領域をまとめて、ディスクへの新しいコンテンツの書き込みを、非常に効率的に行うことができるようになる

下図は、私たちが説明している内容を図示したものです。最初の図は、ディスクの理想的な状態を表しています。3つのファイル、A、B、および C があり、すべて隣接した場所に格納されています。つまり、断片化はありません。第 2 の図は断片化したディスクを表しています。ファイル A に関連付けられたデータの一部は、現在隣接していない場所に配置されています (ファイルの増え方による)。3 番目の図は、一旦、ディスクが最適化された場合、ディスク上のデータがどのように見えるかを示しています。

最新のファイルシステムはほぼすべて、最適化をサポートしています。相違点は、最適化のメカニズムにあります。たとえば、Windows の場合のように、個別のスケジュール可能なタスクなのかどうか、あるいはそのメカニズムはより暗黙的に管理され、ファイルシステム内のものなのかどうか、などです。設計の決定事項には、単に、システムおよび必要なトレードオフの特定の設計目標が反映されます。さらに、断片化が生じないように、汎用のファイルシステムが設計される可能性はあまりありません。

この数年にわたって、最適化が非常に強調されてきました。歴史的に、断片化が、非常に大きな影響をもたらす可能性のある問題だったからです。パーソナルコンピューティングの初期の時期には、ディスク容量がメガバイトで測定されており、ディスクはすぐにいっぱいになり、断片化も頻繁に発生していました。さらに、メモリキャッシュは大幅に制限され、システムの応答性はますますディスク I/Oパフォーマンスに基づくようになりました。この結果、一部のユーザーは、最適化ツールを毎週、もしくはそれ以上のペースで実行するようになりました! 現在、非常に大きなディスクドライブが安く手に入るようになり、また、平均的なコンシューマー向けのディスク使用率 (%) はおそらくより低くなり、その結果比較的断片化の発生は少なくなります。さらに、コンピューターは、より多くの RAM を安く (多くの場合、使用中のデータセットをアクティブにキャッシュするのに十分なレベルで) 利用することができます。それに加えて、ファイルシステム割り当て方針やキャッシングとプリフェッチングのアルゴリズムの改善が行われることで、一層、全体的な応答性を向上させることができます。したがって、CPU とディスクの間のパフォーマンスギャップが大きくなり続け、断片化が生じる一方で、他の領域でハードウェアとソフトウェアが一体化して進歩することにより、Windows における断片化の影響の軽減と、よりよい応答性が実現されます。
そうすると、私たちは、現在のソフトウェアおよびハードウェアを使用することを前提とした場合、どのように断片化を評価したらいいのでしょうか。最初の質問は次のようになるかもしれません : 「断片化は実際どの位の頻度で発生し、またどの程度まで生じるのか」。というのも、断片化が 1% の 500GBのデータと、断片化が 50% の 500GB のデータでは、同じ大きさのデータであっても、大幅に異なるからです。第 2 の質問は「現在のハードウェアおよびソフトウェアを使用することを前提とした場合、断片化による実際のパフォーマンス上のペナルティはどんなものになりますか」になるかもしれません。皆さんの中でかなり多数の人が、過去20年間にわたり導入されたさまざまな製品のことを思い出されるかもしれません。これらは当時、さまざまなパフォーマンスの向上 (例えば RAM 最適化、ディスク圧縮など) をもたらしましたが、それ以降その多くはハードウェアとソフトウェアの進歩により古くさいものになってしまいました。

平均的なホームコンピューターの断片化の発生率および範囲は、使用可能なディスク容量、ディスク消費量および使用パターンによって大きく変わります。言いかえれば、一般的な答えはありません。断片化による実際のパフォーマンスへの影響は面白い質問ですが、正確に計測するにはあまりに複雑です。断片化によるパフォーマンス上のペナルティの評価を意味あるものにするには、下記が要求されるでしょう。

通常的あるいは代表的なやり方で断片化を作成するのに「古くなった」システムの可用性。しかし、上述したように、単一の代表的なやり方はありません。たとえば、主として Web ブラウズのために使用されているコンピューター上の断片化の頻度と範囲は、ファイルサーバーとして使用されているコンピューターと異なります。
意味のあるディスクに関連する指標の選択、例えば、ブートおよび初めてのアプリケーションを起動した後のブート。
統計的に関連している可能性のある繰り返された測定

断片化の範囲を、ユーザーが理解できるパフォーマンスと直接関連付ける際の複雑さを示すのに役立つ例を順に見て行きましょう。

Windows XP では、複数の断片に分割されているファイルはすべて、断片化していると見なされます。Windows Vista では、フラグメントが十分に大きい場合、断片化していると見なされません。最適化アルゴリズムが 64 MB より大きいファイルの断片を無視するように、(Windows XPから) 変更されたからです。その結果、XP での最適化と Vista での最適化では、同一ボリューム上の断片化の量が異なって報告されます。そうすると、正しいのはどちらなのでしょうか。この質問に回答する前に、私たちは、Vista で最適化が変更された理由を理解しなければなりません。Vista で、私たちは、最適化の影響を分析した結果、次のようなことが判明しました。つまり、最適化によって最も大きなパフォーマンスの向上が得られるのは、ファイルの複数の断片が、"十分に大きなデータのまとまり" として一体化した場合であり、ディスクシークの待機時間の影響は、連続してファイルを読み取ることに関連付けられる待機時間と有意な関連性はない、と判断しました。これは、ある臨界点を超えると、断片化した数片のファイルを組み合わせることには、目に見る利点がなくなることを意味します。実際、そうすることにより否定的な結果が得られています。たとえば、最適化により 64 MB 以上のフラグメントを組み合わせる場合、多量のディスク I/O を必要とします。これは、私たちが上で説明した、I/O を最小化するという原則に反し (なぜなら、ユーザーが開始した I/O 用に使用可能な合計のディスク帯域幅が減るため)、システムに対して、空き領域の大きな隣接したブロックを見つけるという大きな圧力をかけることになります。ここに、特定の量のデータの断片化がちょうどよいという、シナリオがあります。つまり、この断片化を減少させるためには何もしないことが、正しい回答であると判明しました!

断片化の量とその影響のような、比較的理解しやすい概念は、実際には非常に複雑であり、その本当の影響は、正確に対応すべきシステム全体の総合的な評価を要求することに注意してください。Windows XP と Vista の間の異なる設計上の決定事項には、ユーザーが使用する通常のハードウェアとソフトウェア環境に関するこの評価が反映されています。最終的に、最適化に関して考える場合、システムの応答性には、既存のフラグメントの単純な数以上に、考慮すべき多くのその他の要因が寄与しているということを理解することが重要です。

Windows 7 の最適化エンジンおよびエクスペリエンスは、システムの応答性に対する影響の継続した全体的な分析に基づいて改良されました。

Windows Vista では、私たちは、詳細な最適化の状態を表示する UI をすべて削除しました。私たちは、この決定が気に入らなかったというフィードバックを受け取りました。そこで、私たちはさまざまなトレードオフについて調べ、評価し、最適化のための新しいGUIを構築しました。その結果、Windows 7 では、状態をより容易かつ直観的に監視することができるようになりました。さらに、最適化は、プロセス中いつでも、すべてのボリュームで (必要であれば) 非常に簡単に、安全に終了させることができます。2つの下記のスクリーンショットは、監視の容易さを示しています。

Windows XP では、最適化は、ユーザーが開始する (手動の) 操作でなければなりませんでした。つまり、それをスケジュールすることができませんでした Windows Vista は、最適化をスケジュールするために機能を追加しました。ただし、最適化できるボリュームは、常に 1 つだけでした。Windows 7 ではこの制限をなくしました。現在では、複数のボリュームを並行して最適化することができます。あるボリュームの最適化が完了するまで、他のボリューム上で同じ操作を開始するのを待つ必要がなくなりました。下記のスクリーンショットは、複数のボリュームに対して、どのように同時に最適化をスケジュールするのかを示しています。

Windows 7で行われたその他の変更には、下記があります。

Windows 7 の最適化はより包括的です。Windows Vista または以前のバージョンで再配置できなかった多くのファイルは、今では最適に再配置することができます。特に、さまざまな NTFS メタデータファイルを移動可能にするために、多くの作業が行われました。NTFS メタデータファイルを再配置するこの機能は、ボリュームの縮小を促進します。なぜなら、システムにより、すべてのファイルとファイルシステムメタデータがより緊密に圧縮され、「最後部の」領域が解放され、必要なときに再利用することができるからです。
ソリッドステートメディアが検出された場合、Windows は、そのディスクに対する最適化を無効にします。ソリッドステートメディアは、その物理的な特性により、最適化は必要でなく、実際特定のケースでは、メディアの全有効期間にわたって減少することがあります。
既定では、最適化は Windows Server 2008 R2 (Windows 7 サーバーリリース) では無効になっています。サーバーのワークロードのばらつきを考慮すると、これらのワークロードを把握している管理者が、最適化を有効にしてスケジュールすべきです。

Windows 7 の最適化を使用する上でのベストプラクティスは、シンプルです。何もする必要はありません! 最適化は、自動的に、定期的にかつバックグラウンドで実行されるようにスケジュールされ、フォアグラウンドアクティビティへの影響は最小限に抑えられます。これにより、ハードディスクドライブ上のデータが効率的に配置され、システムが最適な応答性を発揮することができるようになり、私は引き続き、故障を起こさずにイーグルスの歌を楽しむことができるようになります :-)。

Rajeev と Matt

マイクロソフトのEngineering Windows 7 ブログ : Storage

ソリッド ステート ドライブ (SSD) に関するサポートと Q&A

ディスク最適化 – その背景と Windows 7 の開発における改善

ソリッドステートドライブ (SSD) に関するサポートと Q&A