NTFS使用哪种块分配算法？

如图所示，在Windows XP 64上，我下载了1.2 GB的文件，并且文件碎片化。不幸的是，在从Piriform Defraggler拍摄快照之前，我对其他文件进行了碎片整理，因此您无法在写入文件时看到确切的状态。但是，磁盘一直像现在一样空（已使用25％），几乎没有碎片。

NTFS使用哪种块分配算法？它看起来像是随机的，或者可能是放置在磁盘头实际所在的位置。

更新：

这就是今天写入新文件的67 MiB之后发生的情况。它被分成731个片段，平均大小仅为95 KiB。该文件用于填补一些空白，但不是全部，它也不使用巨大的连续可用空间。奇怪，不是吗？

更新2：

与PC Guru不同，我真的不认为Opera是罪魁祸首。我认为它（与Google Chrome相对）不能告诉Windows预期的大小，但是，在很多情况下，这是不可能的，并且操作系统有责任以理智的方式处理它。下图显示了几天后，我对该分区几乎不执行任何操作-TEMP目录和我所有的数据（由Windows管理的数据除外）都位于其他位置。Windows本身似乎并没有以SetEndOfFile可怕的方式使用和碎片化自己的文件（600个碎片相当于几个约40 MB的小文件）。NTFS似乎并没有使用第一个可用的扇区，因为在相当空的磁盘的中间以及末尾（使用率为23％），又有文件，

IIRC，NTFS文件系统尝试在连续存储中分配文件。但是，只有在文件系统知道文件大小的情况下，它才能这样做。如果您打开文件并开始对其进行写入，它将写入到适合该文件的“最佳”位置（通常朝磁盘的外部）。但是该“最佳”位置可能不足以容纳该文件。

如果应用程序告知NTFS文件的实际大小（使用SetEndOfFile（）），则NTFS可以为文件找到连续的空间做得更好（SetEndOfFile API使NTFS为整个文件分配存储空间）。

您的问题必须出在Opera上。我刚刚查看了非常完整且零散的驱动器上的一堆文件。使用Chrome下载的大文件都是连续的。

这表明Chrome浏览器在下载开始时就知道文件的大小，因此告诉NTFS预期的文件大小。如果这样做，NTFS将尝试将文件放在单个片段中，或者当没有足够大的片段时，将文件放入最大的可用片段中。有趣的是，它始终按大小降序使用这些碎片，因此资源管理器复制到碎片驱动器上的大文件可以在整个驱动器上跳转。

如果程序不知道文件大小，或者不费心告诉NTFS，而是打开一个文件并开始写入顺序数据，则NTFS的行为与FAT32非常相似，后者只是从第一个可用群集开始（或第一个在该会话的最后一个分配之后可用），然后使用此后可用的任何对象。例如，大约在同一时间，我要求CCleaner扫描注册表，使它备份到一个大的txt“ .Reg”文件中。该文件开始于驱动器开始附近，然后分散在127个不同的片段中。与使用资源管理器复制或通过Chrome下载的文件不同，在我查看的每个文件中，群集都是按升序分配的。

在这项研究中，我使用了Winhex（可从Winhex.com获得免费试用版）。查看目录条目时。右键单击文件名，然后选择“位置”，“列出群集”，以查看该文件使用的群集列表。