仮想マシンで実行されているハードドライブをデフラグする必要がありますか？
SSDでDefragを実行する意味がない（実際には悪い考えです）ことを知っています。 SSDで実行されている仮想マシンはどうですか？ハードドライブに基本的に同じ方法でアクセスしているので、ハードドライブをデフラグする必要がありますか？
私はVHDをデフラグしますが、時間ではなくスペースの理由から：
私はVHDに動的に割り当てられたオプションを使用しているため、VHDは小さく始まり、必要に応じて拡張されます。しかし、VHD（必ずしもファイルではない）が断片化すると、割り当てられたすべてのブロックを含むように拡張されます。 VHDのデフラグは、再度圧縮するための最初のステップです。
SSDをデフラグする必要はありません。通常のハードドライブは、ファイル（の一部）を見つけるために回転する必要があります。 SSDはRAMに匹敵し、すべてのファイルに同じ遅延で到達できます。
Wikipedia states 「データがSSDに保存されている場所に基づいて読み取りパフォーマンスが変化しない」
仮想マシンが従来の磁気HDDまたは電子SSDに格納されているデータにアクセスしているかどうかにかかわらず、Windows NTFSファイルと空き領域の断片化により、データを要求するアプリケーションのアクセス速度が低下します。 NTFSファイルと空き領域の断片化は、予想よりもはるかに頻繁に発生します。オペレーティングシステムをインストールするとすぐに発生する可能性があります。これは、アプリケーションまたはシステムアップデートのインストール、インターネットへのアクセス、写真のダウンロードと保存、電子メール、オフィス文書の作成などで発生する可能性があります。これは、コンピュータシステムの通常の発生および動作ですが、すべてのアプリケーションとシステムのパフォーマンス。断片化が発生すると、コンピューターシステムと基盤となるストレージが必要以上の作業を実行します。各I/O要求には、かなりの時間がかかります。 SSD環境でも、「インスタント」I/Oリクエストなどはありません。アプリケーションがデータの読み取りまたは書き込みを要求し、その要求が追加のI/O要求に分割されると、さらに多くの作業が発生します。この余分な作業により、その瞬間に遅延が発生します。
ディスクドライブは長年にわたって高速になっていますが、CPUも同様です。実際、ハードディスクとCPUの速度の違いの差は実際に広がっています。つまり、アプリケーションは十分なCPUサイクルを取得できますが、それでもストレージからデータを取得するために飢えています。さらに、保存されるデータの量は劇的に増加しています。休暇中に撮影して共有したデジタル写真をすべて考えてみてください。各写真のサイズは約1MBでしたが、現在は写真あたり15MBを超えており、それを超えるものもあります。ビデオ編集、デジタルムービーのレンダリングおよび保存も非常に一般的になり、その結果、アプリケーションは数百ギガバイトのデータを操作しています。一般的なディスククラスターサイズが4kの場合、15MBサイズのファイルは約4,000エクステントに断片化される可能性があります。これは、ファイルの読み取りまたは書き込みに追加の4,000ディスクI/O要求が必要であることを意味します。ストレージのタイプに関係なく、操作が完了するまでに時間がかかるだけです。
SSD上のデータの物理的な配置は、通常の磁気HDDの場合のように重要ではありません。 SSDを使用すると、回転の待ち時間や競合するシーク時間はありません。多くの専門家は断片化はもはや問題ではないと想定していますが、アプリケーションのデータアクセス速度はこれらの用語で定義されているだけではありません。実行されるすべてのI/O要求には、かなりの時間がかかります。 SSDは高速ですが、瞬時ではありません。 Windows NTFSファイルシステムは、基盤となるストレージがSSDとHDDであり、フラグメンテーションが発生するため、動作に違いはありません。断片化を防止して根絶することにより、不要なI/Oを減らし、I/O要求の数を減らし、その結果、アプリケーションデータの応答時間を短縮し、SSDの全体的な寿命を改善します。本質的に、これにより、より高速でランダム書き込みよりも優れた、より順次的なI/O操作が可能になります。
さらに、SSDでは、HDDのように古い情報を上書きするだけでなく、新しいデータが上書きされる前に古いデータを消去する必要があります。これにより、摩耗が2倍になり、SSDの速度パフォーマンスと寿命に大きな問題を引き起こす可能性があります。ほとんどのSSDメーカーは、これを支援する非常に高度なウェアレベリング技術を備えています。主な問題は、空き領域の断片化による書き込み速度の低下です。 SSD全体に小さな空きスペースが散在していると、NTFSファイルシステムはそれらの小さな利用可能な空きスペースにファイルを断片化して書き込みます。これには、順次操作よりも遅いランダムI/Oトラフィックが発生するという影響があります。
これを裏付けるベンチマーク結果があります。必要に応じて、コメントを投稿し、これらの結果をリクエストしてください。共有させていただきます。
SSDの従来のデフラグの元の質問に関しては、それは悪い考えだと私は同意しますが、ファイルの移動とSSDの寿命の懸念に対処する利用可能な特定のソリューションがあります。
オペレーティングシステムとしてWindowsを実行している仮想マシンでは、フラグメンテーションが引き続き発生し、追加のI/Oトラフィックの複合効果により、ゲストシステムだけでなくホストの速度と効率も低下します。 MicrosoftとVMwareはどちらも、ゲストレベルで断片化に対処する必要があることを推奨しています。
その理由は…
アプリケーションがデータXを要求する
要求はNTFS.sysによって処理されます
ファイル属性が検査され（$ MFT）、データが単一のエクステント（フラグメント）に含まれていない場合は、元のデータ要求を満たすために、エクステント/フラグメントごとに追加のI/O要求が作成されます。
これらの各要求は、ディスクストレージドライバーに送信されます。
データが取得されると、スタックはユーザー/アプリケーションに戻されます。
各Windows仮想マシンは、このタイプのI/Oトラフィックをホストシステムに送信しています。ファイルシステム構造がゲスト/仮想マシンレベルで断片化されている場合、これは、ホストによって処理され、バックエンドストレージからファームされる必要がある追加の不要なI/Oトラフィックに変換されます。仮想マシンを追加するにつれて、これはさらに複雑になります。実際には、ホストファイルシステムレベルでの断片化の中に断片化を含めることができます。
データがSSDに保存されているか、従来のHDDに保存されているかに関係なく、Windowsを実行している場合、NTFSファイルシステムは断片化し、その結果、NTFSファイルと空き領域の断片化により、メーカーの定格速度とスループットを達成できません。効果は、PerfMonを介して平均ディスク読み取りキューの長さ、平均書き込みキューの長さ、そして最も重要な分割IO /秒を調べることで測定できます。
これは私の意見にすぎません。バックアップするためのテスト結果はありません。状況がどのように発生するかについての大まかな概算は次のとおりです。
実際のOS：
- アプリケーションがデータXを要求する（高速）
- OSがディスクドライバーにデータXを要求する（高速）
- 物理ディスクはデータXをフェッチしてOSに返します（断片化されている場合は低速）
これは、VMでの同等のコマンドチェーンです。
- VMアプリケーションがデータXを要求する（高速）
- VM OSがデータXを要求する（高速）
- VMホストが実際のOSに仮想ディスクファイルに保存されたデータXを取得するよう要求する（高速）
- 実際のOSはディスクドライバーにデータX（高速）の取得を要求する
- 物理ディスクはデータXをフェッチしてOSに返します（断片化されている場合は低速）。
ご覧のように、どちらの場合でも、断片化は実際には物理ハードドライブがデータを読み取ろうとする操作の段階でのみ問題となり、それはVMその前は、すべてがメモリ内で発生する可能性があります。
結論として、SSDは実際のOSで断片化の影響を受けないこと、およびVMでの断片化の問題はおそらく操作の最後の物理ステップでのみ発生することを知っているので、仮想OSまたはメインOSの仮想ディスクファイルのいずれかを最適化しても、SSDのパフォーマンスは向上しませんが、実際のOSを最適化するのと同じくらい有害/役に立たないと思います。
編集：それが正しい場合、VMを配置するのは当然の理由です！HDDでは、任意の段階（ゲストOS、仮想ディスクファイル、実際のOS）で断片化が壊れます直線性と物理ディスクのステップで断片化を引き起こします。
Windows Server 2008およびWindows Vista以降、Windowsのデフォルトのスケジュールされたデフラグタスクに注意してください。
次のようにして無効にできます：schtasks /change / tn “Microsoft\windows\defrag\ScheduledDefrag” /disable
またはPowerShellを使用：
Get-ScheduledTask ScheduledDefrag | Disable-ScheduledTask
抽出元： http://www.sysadmit.com/2015/10/vmware-y-gpo-defrag-windows.html
240Gb INTEL SSDSC2CW240A3でホストされているWindowsデフラグを使用して、VMLite XPMode VMをデフラグしたところです。
デフラグ前VMホスト上のサイズ-7.83Gb（C上の使用済みスペース：VMでは5.81Gb、121Gb）
ポストデフラグ-9.86Gb（Cの使用済みスペース：VMでは5.80Gb、121Gb）
期待した結果ではなく、デフラグ前のバージョンを復元しました。