NTFSはどのブロック割り当てアルゴリズムを使用しますか？
Windows XP 64で、1.2 GBのファイルをダウンロードしたところ、画像が示すように断片化してしまいました。残念ながら、Piriform Defragglerからスナップショットを取得する前に、他のファイルを最適化したので、次のことができます。ファイルが書き込まれた時点の正確な状態を確認します。ただし、ディスクは常に現在とほぼ同じくらい空であり（25％が使用されています）、ほとんど断片化されていません。
NTFSはどのブロック割り当てアルゴリズムを使用しますか？ランダムに見えるか、ディスクヘッドが実際に立っている場所に置いているように見えます。
更新：
これは、67MiBの新しいファイルを書き込んだ後に今日起こったことです。それは731個のフラグメントに分割され、平均サイズはわずか95KiBでした。このファイルはいくつかのギャップを埋めるために使用されましたが、すべてではなく、巨大な連続空き領域も使用していません。不思議ですね。
更新2：
PC Gur とは異なり、Operaが原因だとは思いません。（GoogleChromeとは対照的に）Windowsに期待されるサイズを教えてくれないと思います。ただし、それが不可能な場合が多く、OSの責任で適切に処理します。次の図は、このパーティション（TEMPディレクトリとすべて）でほとんど何もしなかった数日後に何が起こったかを示しています。私のデータ（Windowsによって管理されているものを除く）は両方とも別の場所にあります。Windows自体はSetEndOfFileを使用していないようで、独自のファイルをひどい方法でフラグメント化します（約40 MBの小さなファイルのカップルに対して600フラグメント） 。NTFSは、最初に使用可能なセクターを使用していないようです。これは、完全に空のディスク（使用率23％）の中央と終わり近くにファイルがあるため、正確なアルゴリズムはまだ不明です。
IIRC、NTFSファイルシステムは、連続したストレージにファイルを割り当てようとします。ただし、ファイルシステムがファイルのサイズを知っている場合にのみそれを行うことができます。ファイルを開いて書き込みを開始すると、ファイルを収めるのに「最適な」場所（通常はPlatterの外側）に書き込みます。しかし、その「最良の」場所は、ファイルを収めるのに十分な大きさではない可能性があります。
アプリケーションがNTFSにファイルの実際のサイズを通知する場合（ SetEndOfFile （））、NTFSはファイルの連続したスペースを見つけるためのより良い仕事をすることができます（SetEndOfFile APIにより、NTFSは全体にストレージを割り当てますファイル）。
あなたの問題はOperaにあるに違いありません。非常にいっぱいで断片化されたドライブ上のファイルの束を見たところです。 Chromeを使用してダウンロードされた大きなファイルはすべて連続していました。
これは、Chromeがダウンロードの開始時にファイルのサイズを知っていたので、予想されるファイルのサイズをNTFSに伝えたことを示しています。そうすると、NTFSはファイルを単一のフラグメントに配置しようとします。十分な大きさのフラグメントがない場合は、使用可能な最大のフラグメントになります。興味深いことに、これらのフラグメントは常にサイズの降順で使用されるため、エクスプローラーによってフラグメント化されたドライブにコピーされた大きなファイルは、ドライブ全体を飛び回ることができます。
プログラムがファイルサイズを知らない場合、またはNTFSに通知することを気にせず、代わりにファイルを開いてシーケンシャルデータの書き込みを開始する場合、NTFSはFAT32と非常によく似た動作をし、最初に使用可能なクラスター（またはそのセッションで最後に割り当てられた後に使用可能な最初のもの）は、それ以降に使用可能なものをすべて使用します。例として、ほぼ同時に、CCleanerにレジストリをスキャンするように依頼し、レジストリを大きなtxt「.Reg」ファイルにバックアップしました。このファイルはドライブの開始近くから始まり、127の異なるフラグメントに散らばっていました。 Explorerでコピーされたファイル、またはChromeでダウンロードされたファイルとは異なり、私が調べたすべてのファイルで、クラスターは昇順で割り当てられました。
この調査では、Winhex（Winhex.comから入手できる無料の試用版）を使用しました。ディレクトリエントリを見るとき。ファイル名を右クリックし、「位置」、「クラスターのリスト」を選択して、そのファイルで使用されているクラスターのリストを表示します。