![NTFS 使用什么块分配算法?](https://linux22.com/image/1273467/NTFS%20%E4%BD%BF%E7%94%A8%E4%BB%80%E4%B9%88%E5%9D%97%E5%88%86%E9%85%8D%E7%AE%97%E6%B3%95%EF%BC%9F.png)
在 Windows XP 64 上,我下载了一个 1.2 GB 的文件,结果它变得碎片化了,如图所示。不幸的是,在从 Piriform Defraggler 拍摄快照之前,我对其他文件进行了碎片整理,因此您无法看到文件写入时的确切状态。但是,磁盘一直和现在一样空(使用了 25%),几乎没有碎片。
NTFS 使用什么块分配算法?它看起来像是随机的,或者可能将其放置在磁盘头实际所在的位置。
更新:
今天在写入 67 MiB 的新文件后发生了这种情况。它被分成 731 个片段,平均大小只有 95 KiB。该文件被用来填补一些空白,但不是全部,它也没有使用巨大的连续可用空间。很奇怪,不是吗?
更新2:
不同于电脑大师,我真的不认为 Opera 是罪魁祸首。我认为它(与 Google Chrome 相反)不会告诉 Windows 预期的大小,但是,在很多情况下这是不可能的,操作系统有责任以合理的方式处理它。下图显示了几天后我几乎没有在这个分区上做任何事情的情况 - TEMP 目录和我的所有数据(Windows 管理的除外)都位于其他地方。Windows 本身似乎不使用并以可怕的方式SetEndOfFile
碎片化自己的文件(几个约 40 MB 的小文件有 600 个碎片)。NTFS 似乎不使用第一个可用扇区,因为在相当空的磁盘(使用率为 23%)的中间和末尾附近也有文件,因此确切的算法仍然未知。
答案1
如果我没记错的话,NTFS 文件系统会尝试将文件分配到连续的存储中。但是,只有当文件系统知道文件的大小时,它才能这样做。如果您打开一个文件并开始写入,它会写入适合该文件的“最佳”位置(通常是在磁盘的外侧)。但那个“最佳”位置可能不够大,无法容纳该文件。
如果应用程序告诉 NTFS 文件的实际大小(使用设置文件结束符())时,NTFS 可以更好地为文件找到连续的空间(SetEndOfFile API 导致 NTFS 为整个文件分配存储空间)。
答案2
你的问题肯定出在 Opera 上。我刚刚查看了一个非常满且碎片化的驱动器上的一堆文件。使用 Chrome 下载的大文件都是连续的。
这表明 Chrome 在开始下载时就知道文件的大小,因此会告诉 NTFS 预期的文件大小。如果您这样做,NTFS 会尝试将文件放在单个碎片中,或者当没有足够大的碎片时,将其放入最大的可用碎片中。有趣的是,它总是按大小降序使用这些碎片,因此 Explorer 复制到碎片驱动器上的大文件可能会在整个驱动器上跳来跳去。
如果程序不知道文件大小,或者懒得告诉 NTFS,而是打开文件并开始写入顺序数据,那么 NTFS 的行为似乎与 FAT32 非常相似,它只是从第一个可用簇(或该会话中最后一个分配簇之后的第一个可用簇)开始,然后使用从那里开始的任何可用簇。例如,大约在同一时间,我要求 CCleaner 扫描注册表,导致它将其备份到一个大型 txt“.Reg”文件中。该文件从驱动器的开头附近开始,然后分散在 127 个不同的片段中。与使用 Explorer 复制或使用 Chrome 下载的文件不同,在我查看的每个文件中,簇都是按升序分配的。
为了进行这项研究,我使用了 Winhex(可从 Winhex.com 获得免费试用版)。查看目录条目时,右键单击文件名并选择“位置”、“列出簇”,以查看该文件使用的簇列表。