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

Question

这个问题是根据这个主题提出的：creating a huge dummy file in a matter of seconds in c#

我刚刚检查了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写入400MB将花费大约20秒或更少。

对此有什么解释吗？或者，fsutil.exe使用哪个函数来编写具有如此重要速度的函数？

Answer 1

我不知道fsutil到底在做什么，但我知道有两种方法可以写一个大文件，比上面的方法更快(或者寻找到你想要的长度，然后写一个零，结果是一样的)。

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

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

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

Answer 2

我同意最后一个评论。我正在试验一个微过滤器驱动程序，并在回调中捕获IRP_MJ_WRITE IRP。当我从cmd行或win32应用程序创建或写入文件时，我可以看到写下来。但是当我使用"fsutil file creatennew...“创建一个文件时命令，我看不到任何写入。我在NTFS卷上的win2k8 r2上看到了此行为。我也不认为(虽然不是百分之百确定)它是一个稀疏文件。它可能正在设置MFT中的大小属性，而没有分配任何集群。fsutil会检查可用的空闲空间，所以如果文件大小大于磁盘上的空闲空间，就会得到错误1。

我还对文件运行了FSCTL_GET_RETRIEVAL_POINTERS程序，我得到了整个文件大小的一个范围。但我相信它得到了所有的数据

Answer 3

这可能是一种

用汇编语言编写的

• (原始盲速)
• 完成此操作的本机C/C++代码
• 可能是未记录的系统调用，也可能是未记录在案的某些技巧。

以上三点可能有一个巨大的重要因素--当你想一想，当一个.NET代码被加载时，它会被运行时干扰(好的，如果你有一台速度极快的机器，时间因素将不会被注意到-在低端的奔腾上，它将是明显的，缓慢的加载)。

它很可能是用C/C++编写的。如果它是用汇编语言写的，你可能会大吃一惊。

您可以自己检查-查看可执行文件的文件大小，并将其与.NET的可执行文件进行比较。你可能会争辩说文件是压缩的，我怀疑它是压缩的，因此倾向于排除这种可能性，我认为微软不会在压缩可执行文件业务上走得那么远。

希望这能回答你的问题，向你致以最好的问候，汤姆。