“在设备上关闭Windows写缓存缓冲区刷新”的全部功能和效果是什么

在Windows 7中，使用“设备管理器”，显示磁盘的属性，然后转到“策略”选项卡，有2个开关项。写缓存，这个问题与此无关。

和

[X]关闭设备上的Windows写缓存缓冲区 <---仅此一个！

Microsoft在该项目的选项卡上放置了免责声明。“为防止数据丢失，请不要选中此复选框，除非设备具有单独的电源，允许设备在断电时刷新其缓冲区。”

简单来说，这对文件写入，文件保存，文件复制有何影响？

1.更改偏执程序的写入操作:( 事实或虚构）
它是否会改变写入刷新的方式，以便强制执行缓存刷新？有些程序非常有意完成写作，没有推测，这些程序是否能够继续保护性写作，或者这些程序是否也会改变？

2.实施的计划类型：
改变会产生或不会产生哪些行动/计划类型？键入，某些程序流，一些快速写出，一些是连续的，一些是保护性的（或者您可以用简单的术语定义的任何其他类型）。

3.你有没有看到任何东西，甚至是基准：
如果设置已经开启，那么写作中可观察到的变化是什么？观察到的行为变化的任何松散的例子。或观察到行为没有变化？

4.什么是持有或延迟：
我们知道大多数计算机上的这些操作都非常快，数据最终会被写入。相对于驱动器的速度，时间的重要性是多少？

出于我的问题的目的，存在的风险不是问题之一，如果你想覆盖它，它不会妨碍。

“写缓存缓冲区刷新”意味着什么几乎是一个骗局，但链接是针对不同的操作系统。虽然A有一些信息，但即使链接中使用的术语也不一样。它也没有回答用户想要知道的最重要的事情，我试图在这里概述。

1. 你在第一个问题中的主张是虚构的。Windows API调用，如将仍然确保数据得到所有的出路在物理介质，即使写入缓冲区冲洗禁用。因此，“安全”并知道他们正在做什么的程序将会很好。诸如.NET等的调用最终会调用此API。FlushFileBuffers() FileStream.Flush()

2. 在没有FlushFileBuffers()直接调用的情况下执行大量磁盘I / O的程序，或者最终调用它的任何辅助API，都会看到最显着的性能提升。例如，如果您正在运行非必要的I / O，如果数据丢失就可以了，例如BOINC（如果它丢失，您只需重新下载文件或尝试重新计算计算），您可以避免调用FlushFileBuffers()，只需调用一个API WriteFile()- 数据将被缓冲写入，但实际上不会被写入很长时间，例如文件描述符关闭时，或程序退出时。不幸的是，如果系统崩溃（例如BSOD），所有数据都会丢失，所以它非常重要如果您正在处理您打算调用的任何有价值/不可替换的数据FlushFileBuffers()，是否启用了缓冲区刷新！否则，一个简单的驱动程序错误（例如在您的图形驱动程序中）可能会导致您丢失大量数据。

3. 找不到任何基准测试，但您会注意到上述第二项中符合描述的程序。

4. 将数据同步到磁盘实际上并不那么快，特别是如果它在紧密循环中频繁完成。默认情况下，如果我从阅读Windows Internals书籍中正确回想起来，默认情况下NTFS会每隔5秒将所有脏文件系统缓冲区同步到磁盘。这显然是稳定性和性能之间的一个很好的权衡。频繁同步数据的问题在于它使得硬盘驱动器进行了大量的搜索和写入。

考虑以下伪代码：

1: seek to a certain block (1)
2: write a couple megabytes of data into blocks starting at (1)
3: wait 2 seconds
4: seek to another block (2)
5: write some more megabytes of data into blocks starting at (2)
6: seek back to block (1)
7: write some more megabytes of data into blocks starting at (1)
8: wait 10 minutes
9: seek to block (1)
10: write some megabytes of data into blocks starting at (1)
11: wait 5 seconds
12: seek to block (2)
13: write some megabytes of data into blocks starting at (2)
14: explicit call to FlushFileBuffers()

具有自动5秒缓冲冲洗上：

• 第2行，第5行和第7行发生的写入发生在RAM中，磁盘不移动，直到第一次写入后经过5秒，然后最新数据（来自第7行）被写入块（1）和只写入块（2）的数据被写入。
• 第10行和第13行发生的写操作会覆盖块（1）和（2）中的数据，必须再次写入磁盘
• 因此，块（1）写入RAM的总次数是3，磁盘是2次。块（2）写入RAM的总次数是2，磁盘是2。

自动关闭 5秒缓冲区（问题中复选框的效果）：

• 在第2,5,7,10和13行发生的写入发生在RAM中，并且磁盘不移动，直到执行第14行，然后最新数据（来自第10行和第13行）被写入块（1） （2）。第2,5和7行的旧数据永远不会出现在硬盘上！

考虑到繁忙的系统每秒可以体验数百到数万个文件写入，这对性能很有帮助，特别是在传统的旋转硬盘驱动器上（在SSD上不那么令人印象深刻）。作为一般衡量标准，RAM比硬盘驱动器快20倍，尽管SSD的差距较小。

他们之所以说你应该使用备用电池的原因是你不希望有35分钟的缓冲在RAM中的写入数据没有写入磁盘而只是因为你的程序员很懒而且没有调用FlushFileBuffers()，然后有电力故障。当然，备用电池不能保护您免受导致BSOD的驱动程序错误....

为了支持ChatBot John Cavil的回答，我写了一个小测试程序：

// ...
byteEx btTest;
btTest.resize(1024*1024, 0xff); // 1MB data

CSysFile sfTest(byT("test.bin"));

swTest.Start(); // Begin timing by call `QueryPerformanceCounter` API
for (UINT i=0; i<10000; ++i) // Write 1MB data for 10000 times
{
    sfTest.SeekBegin();
    sfTest.Write(btTest); // Call `WriteFile` API 
//  sfTest.Flush();       // Call `FlushFileBuffers` API
}
swTest.Stop(); // Calculate the time-consuming start from `swTest.Start() `
// ...

并在Samsung 950pro NVMe磁盘上运行它，并启用“关闭设备上的Windows写缓存缓冲区刷新”选项。

结果是：

D:\tmp> test        // without sfTest.Flush();
00:00:00.729766     // use 0.73 seconds without FlushFileBuffers()

D:\tmp> test        // with sfTest.Flush();
00:00:06.736167     // use 6.74 seconds with FlushFileBuffers()

因此，您可以看到FlushFileBuffers系统不会省略请求（FlushFileBuffers即使启用了选项，Windows也不会忽略调用）。