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

皆さんによく知られているトピックの 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つの原則が立てられ、オペレーティング システムはこの原則に従おうとしています。

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

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

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

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

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

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

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

下図は、私たちが説明している内容を図示したものです。最初の図は、ディスクの理想的な状態を表しています。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