为什么 fsutil.exe 将大文件写入磁盘所需的时间比以编程方式写入的时间要少？

Question

这个问题是根据这个主题： 在案件中创建一个巨大的虚拟文件 。

我刚刚检查了 xp/vista/7 中的 fsutil.exe 将大量虚拟数据写入存储磁盘，与以编程方式相比，写入如此大的文件所需的时间更少

当我尝试在 .net 的帮助下做同样的事情时，它将比 fsutil.exe 花费更多的时间。

注意：我知道 .net 不使用本机代码，因为我刚刚使用本机 api 检查了这个问题，如下所示：

long int size = DiskFree('L' - 64);
const char* full = "fulldisk.dsk";
__try{
Application->ProcessMessages();
HANDLE hf = CreateFile(full,
                       GENERIC_WRITE,
                       0,
                       0,
                       CREATE_ALWAYS,
                       0,
                       0);
SetFilePointer(hf, size, 0, FILE_BEGIN);
SetEndOfFile(hf);
CloseHandle(hf);
}__finally{
    ShowMessage("Finished");
    exit(0);

答案与 .net 结果相同。

但在 fsutil.exe 的帮助下，它只需要比上面更短的持续时间，或者 .net 方法说它快 2 倍

示例： 使用 .net 写入 400mb 大约需要 40 秒 使用 fsutil.exe 执行相同的操作将需要大约 20 秒或更短的时间。

有什么解释吗？ 或者fsutil.exe使用哪个函数有这个意义速度写入？

Answer 1

我不知道 fsutil 到底在做什么，但我确实知道有两种写入大文件的方法，它们比您上面所做的更快（或者寻找您想要的长度并写入一个零，其具有相同的效果）结果）。

这些方法的问题在于，它们在写入时对文件进行零填充。

您可以通过以下任一方式避免零填充：

1. 创建稀疏文件。大小已标记在您想要的位置，但在您写入数据之前，数据实际上并不存在于磁盘上。所有未写入区域的读取都将返回零。
2. 使用 SetFileValidData 函数设置有效数据长度，无需先将文件清零。但是，由于潜在的安全问题，此命令需要提升权限。

Answer 2

我同意最后的评论。我正在尝试使用微过滤器驱动程序并在回调中捕获 IRP_MJ_WRITE IRP。当我从 cmd 行或 win32 应用程序创建或写入文件时，我可以看到写入操作。但是当我使用“fsutil file createnew ...”命令创建文件时，我没有看到任何写入。我在 NTFS 卷上的 win2k8 r2 上看到了这种行为。而且我也不认为（虽然不确定 100%）它是一个稀疏文件。它可能是在 MFT 中设置大小属性而不分配任何簇。 fsutil 会检查可用的可用空间，因此如果文件大小大于磁盘上的可用空间，则会出现错误 1。

我还运行了程序，对文件进行 FSCTL_GET_RETRIEVAL_POINTERS 检测，并获得了文件整个大小的一个范围。但我相信它正在获取所有数据

Answer 3

这可以用

• 汇编程序编写（原始速度令人眼花缭乱），
• 可以使用本机 C/C++ 代码来执行此操作，
• 也可以使用未记录的系统调用来执行此操作，或者使用一些未在任何地方记录的技巧。

上述三点可能有一个巨大的重要因素 - 当你考虑一下时，当加载 .NET 代码时，它会被运行时抖动（好吧，如果你有一台速度极快的机器，时间因素就不会那么明显） - 在低端奔腾上，加载速度会很明显）。

它很可能是用 C/C++ 编写的。如果它是用汇编程序编写的，您可能会感到惊讶。

您可以自己检查一下 - 查看可执行文件的文件大小并将其与 .NET 的可执行文件进行比较。您可能会说该文件是压缩的，我对此表示怀疑，因此倾向于排除这一点，微软不会在压缩可执行文件业务方面走得那么远。

希望这能回答您的问题，
此致，
汤姆.

Answer 4

fsutil 仅在 NTFS 和 exFAT 上速度快，在 FAT32、FAT16 上速度慢
这是因为某些文件系统具有“初始化大小”概念，因此支持快速文件初始化。这只是保留簇，但不会将它们清零，因为它在文件系统中指出没有数据写入文件，并且有效的读取都会返回填充 00 的缓冲区。