NTFSはどのブロック割り当てアルゴリズムを使用しますか？

Windows XP 64で、1.2 GBのファイルをダウンロードすると、画像が示すように、断片化してしまいました。残念ながら、Piriform Defragglerからスナップショットを取得する前に、他のファイルを最適化したため、ファイルが書き込まれた時点の正確な状態を確認できません。ただし、ディスクは常に現在とほぼ同じくらい（25％使用済み）で、ほとんど断片化されていません。

NTFSはどのブロック割り当てアルゴリズムを使用しますか？ランダムに見えるか、ディスクヘッドが実際に立っている場所に置いているようです。

更新：

これは、67 MiBの新しいファイルを書き込んだ後に今日起こったことです。それは731個の断片に分割され、平均サイズはわずか95 KiBです。ファイルはいくつかのギャップを埋めるために使用されましたが、すべてではなく、巨大な連続空きスペースも使用していません。奇妙ですね。

更新2：

PCグルとは異なり、私はOperaが犯人だとは思いません。（Google Chromeとは対照的に）Windowsに予想サイズを通知しないと思いますが、それが不可能な場合が多く、OSが正常に処理するのはOSの責任です。次の画像は、このパーティションで私がほとんど何もしていない状態で数日後に何が起こったかを示しています。TEMPディレクトリとすべてのデータ（Windowsで管理されているものを除く）はどちらも別の場所にあります。Windows自体はSetEndOfFileひどい方法で自身のファイルを使用および断片化していないようです（約40 MBの小さなファイルのカップルに対して600断片）。NTFSは最初の利用可能なセクターを使用していないようです。これは、まったく空のディスク（使用率23％）の中央と終わり近くにもファイルがあるためです。

IIRC、NTFSファイルシステムは、隣接するストレージにファイルを割り当てようとします。しかし、ファイルシステムがファイルのサイズを知っている場合にのみ、それを行うことができます。ファイルを開いて書き込みを開始すると、ファイルを収めるための「最適な」場所に書き込まれます（通常、プラッターの外側に向かって）。しかし、その「最良の」場所は、ファイルを収めるのに十分な大きさではない場合があります。

アプリケーションがNTFSにファイルの実際のサイズを通知する場合（SetEndOfFile（）を使用）、NTFSはファイルの連続した領域をより適切に見つけることができます（SetEndOfFile APIにより、NTFSはファイル全体にストレージを割り当てます）。

あなたの問題はOperaにあるに違いありません。非常に完全で断片化されたドライブ上のファイルの束を見たところです。Chromeを使用してダウンロードされた大きなファイルはすべて連続していた。

これは、Chromeがダウンロードの開始時にファイルのサイズを知っていることを示唆しているため、NTFSに予想されるファイルのサイズを伝えました。その場合、NTFSはファイルを単一のフラグメントに配置しようとするか、またはフラグメントが十分に大きくない場合、使用可能な最大のフラグメントに配置しようとします。興味深いことに、これらのフラグメントは常にサイズの降順で使用されるため、エクスプローラーによってフラグメント化されたドライブにコピーされた大きなファイルは、ドライブ全体を飛び回ることができます。

プログラムがファイルサイズを知らないか、またはNTFSに通知する必要がなく、代わりにファイルを開いてシーケンシャルデータの書き込みを開始する場合、NTFSはFAT32と非常によく似ており、利用可能な最初のクラスター（またはそのセッションで最後に割り当てられた後に利用可能な最初のもの）その後、そこから利用可能なものを使用します。例として、ほぼ同時にCCleanerにレジストリをスキャンするように依頼しました。これにより、大きなtxt ".Reg"ファイルにバックアップされます。このファイルはドライブの開始近くから始まり、127の異なるフラグメントに分散されました。ExplorerでコピーしたファイルやChromeでダウンロードしたファイルとは異なり、私が調べたすべてのファイルで、クラスターは昇順で割り当てられていました。

この調査では、Winhex（Winhex.comから入手できる無料の試用版）を使用しました。ディレクトリエントリを見るとき。ファイル名を右クリックし、[位置]、[クラスターのリスト]の順に選択して、そのファイルで使用されているクラスターのリストを表示します。