デフラグには2つの意味があるようです。
デフラグ異物の量を減らすプロセスです。断片化は、ファイルシステムがファイル全体を1つの単位として保存するのに十分な連続スペースを割り当てることができない場合、または割り当てられていない場合に発生します。代わりに、コンテンツの一部を別のファイル間の間隔に配置します。
WindowsがNTFSパーティションから既存の空き容量を確保する場合（後で、特に既存のWindows OSの外部にUbuntuをデュアルブートインストールするときに新しいパーティションを作成するために）、Windowsツールを使用する必要があります。すべて削除ファイルがパーティションの一方の端に移動され、パーティションのもう一方の端にできるだけ多くの空き領域が残ります。これもと聞きましたデフラグ。
gpartedまたは、次のLinuxツールを使用できます。デフラグ（最初の段落ではなく、前段落の意味です。） 最初のものはNTFSパーティションです。
質問：
上記の2つの「彫刻コレクション」がいつも一緒に発生するかどうか疑問に思います。
ファイルシステム（NTFSなど）に最適化が必要かどうかは、次のように異なります。
- これを使用するオペレーティングシステム（WindowsまたはLinuxなど）または
- ファイルシステムの種類（NTFSなど）自体ですか？
デフラグの異なる意味によって、2つの質問に対する答えは異なりますか（前述のように）？たとえば、私は次のように聞きました。
- Linuxでは、EXT4パーティションは、パーティションが90％を超えない限り、最初の意味で最適化を実行する必要はありません。 Linuxは常に最適化を自動的に試みるからです。
- NTFS パーティションの空き領域を確保するために Linux ツールを使用すると、
gparted2 番目の意味では NTFS パーティションの最適化は不要です。 Linuxは常に自動的にすべてのファイルをパーティションの一端にできるだけ多く移動するからですか？
答え1
ファイルシステム（ファイル、ファイルシステム構造、メタデータなど）、空き容量、またはその両方に保存されているデータの最適化を実行できます。
おそらく誰かが「フラグメントコレクション」と言うと、データ（最初の定義）を意味します。伝統的に空き容量の最適化を実行したときに、最後（2番目の定義）に配置されました。通常、パーティションの縮小を準備するときにのみこれを実行しますが、たとえば、いくつかの連続した割り当てを許可するために（たとえば、一部のビデオを編集したい場合など）、これを行うこともできます。しかし、実際には通常、パーティションの縮小に加えて空き領域を最適化する必要はありません。
パーティションの縮小は通常、一方の端でのみ実行できます。 （すべてではありませんが、ほとんどのパーティションフォーマット[1]は途中で穴を切断することはできません。） 。これを行うには、どのツール（Windowsディスクマネージャ、gpartedなど）を使用しても十分な空き容量が必要で、通常はデータ移動が必要です。 Windowsとgpartedの両方がこれを行います。
FSの最適化が必要かどうかは、少なくとも次のようないくつかの要因によって異なります。
- それは何のために使用されますか？ランダムに頻繁に発生しない文書は、無制限の断片化を可能にします。 DVRアプリケーションは限界を超えたものを許可することはできません。データベースなどの一部の項目は、実際には思ったよりも断片化に寛容です（通常、順次読み取り/書き込みではなくランダム読み取り/書き込みを実行するため）。
- どのタイプのドライブですか？ SSDルックアップはほとんど無料なので、断片化ははるかに安いです。
- ディスクキャッシュに使用できるメモリ量。すべての読み取りがキャッシュ内で満たされている場合、ディスクがどの程度断片化されているかは重要ではありません。または、すべての書き込みをディスクに順番に送信できるだけ長くバッファリングできる場合。
- オペレーティングシステムは主にキャッシュの違いによって発生します。
- ファイルシステム一部は非常に断片化されたファイルに対してかなりのオーバーヘッドを引き起こします。
断片化の主な問題は、通常、シーケンシャル読み取り/書き込み照会が増加することです。
1：論理ディスクマネージャはしばしばこれを行います。例えば、希少な割当てを使用する場合、未使用のスペースのうち十分に大きいチャンクを回収しようとするのが一般的である。しかし、それらはスペースが回収されていないかのようにファイルシステムを偽装することに注意してください（そして、ファイルシステムがスペースに書き込もうとしたときにスペースを返します）。
答え2
ウィキペディアの断片的な記事は価値がありません…
なぜそんなことを話してみますか？いつ？断片化とデフラグに関する質問ですが、特定のFSに関する詳細はありません。
...また、頻繁に更新されるファイル（ログなど）またはディレクトリ（ダウンロードまたは/ tmpなど）が絶対最小値よりも多くの空き容量を確保するための3番目のオプションをお勧めします。
たとえば、大量のダウンロード（または低速リンク）用のスペースを事前に割り当てます。同期中、転送中（カメラまたは携帯電話から/へ）、コピー（またはバックアップまたはシステムアップデート）中です。
かなり重要な話題です。
前のブロックの近くに余分な空き領域なしで読み取り/書き込みF / Dを配置すると、断片化が可能になります。
成長しないF/Dは余分なスペースなしで安全に置くことができます。これには読み取り専用F/Dが含まれます。これには、解像度が既知の場合（FullHD、4K、8Kなど）、圧縮されていない単純形式（BMPなど）も部分的に含まれます。
F / Dは単に縮小されます（非常に奇妙で奇妙です）。これにより、実際に最適化する必要のある無駄な間隔ができます。これは、誰かが高速圧縮オプション（またはキャプチャ形式）を使用して同じディレクトリに圧縮した場合に発生する可能性があります。これは、一部のプログラムがF / Dを再利用するかどうかによって異なります。
F/D は一括削除されます。部分的な削除や即時デフラグなしでファイルシステムからF / Dを削除したり、履歴を削除したりできます。後でこれらの脆弱性を最適化したいと思います。
この断片化を処理する1つの方法は、各F / Dのピークの実際のサイズを追跡することです。より良い方法は、複数の数字を使用することです。ピークは簡単に代表性を持たない可能性があるためです（中央値から離れています）。 ）。たとえば、システム全体のバックアップとオフィス作業があります。
別のアプローチは成長率を追跡することです。これは特にＨＤＤの場合に当てはまる。最速の成長には、ディスク上の最速の位置が必要です。しかし、速度だけが唯一の要因ではありません。ミッションクリティカルF / D、大規模アカウント、いくつかの緊急優先順位、キルスイッチの追加オプション、または管理者がシステムにデータなしで成長を手動で予測する場合などがあります。
最善のアプローチは、関連期間中に成長に関する実際のデータを維持し、次にどの成長が起こるかを予測し（成長の予測データ）、予測値のギャップサイズ（予測ウィンドウ以降）を推測することです。 。もう関係ありません）。
要約：
縮小のみ - ビューが最適化されました。
絶対大きくなっても、減らなくても……
成長と縮小 - スペースとデフラグを観察します。
このウィキでは扱いません：ディスクパーティション化による断片化