在Azure或Hyper-V下的Windows中，无论基础磁盘系统上的写入caching设置的实际状态如何，服务器configuration都始终显示虚拟磁盘的磁盘策略写入caching设置。 但是，有一个与第一个有关的第二个设置，在这种情况下，虚拟磁盘的效果不清楚，其中第一个在设置中被选中/启用，但在虚拟磁盘硬件中被禁用。 磁盘设置如下所示：
[x] Enable Write Caching on the device [ ] Turn off Windows write-cache buffer flushing on the device 直觉上，我认为没有理由启用这个function，因为写入caching对于设备来说实际上是没有的，如果它是一个物理磁盘，这个设置将被禁用。 但是这篇文章build议启用它将使操作系统和硬件免于无意义的工作，在保持相同数据完整性的同时提高性能，在这种情况下，在设置中启用了写入caching但实际上在硬件中禁用了这种情况：
…因为虚拟硬盘根本不是真正的磁盘，所以就虚拟磁盘而言，该设置没有任何意义。 但第二个设置是不同的，并且确实有意义，因为它控制磁盘的caching刷新开/关设置。 当您select第二个设置时，caching刷新将基本上假装成功 – 至less在软件堆栈级别。 …当您在来宾操作系统中为虚拟机中的虚拟硬盘select此设置时，虚拟机中运行的应用程序可能会有一些性能提升。 但请记住，就数据完整性而言，主机的磁盘caching设置是重要的。
任何人都可以确认这个说法是否属实，做一个WRT数据完整性的安全的事情？
如果您的数据磁盘最初configuration了读取/无caching，我认为这些设置没有任何意义。 本文指出，更重要的是可以通过Service Management API或Powershell命令修改主机caching。
只有在电源/ UPS或存储系统级别具有冗余的情况下，我才会build议使用带有启用选项的虚拟机“closures设备上的Windows写入caching缓冲区刷新”。 如果要启用该选项，则应考虑停电或硬件故障时的数据丢失情况。 我可以build议使用S2D，StarWind或HPE VSA作为软件定义存储，可以在节点级别为您提供冗余，因此您可以使用写入cachingfunction的内部虚拟机。
对于这种情况，“closures设备上的Windows写入caching缓冲区刷新”选项将提高整个VM系统的性能：RAM用作热数据的来源，只有RAM满时才执行数据刷新。
我build议禁用写caching，以防将Hyper-V独立主机与PSU连接在一条线上。
这些假设只对内部虚拟主机可靠。 云供应商拥有自己的function来为他们的实例提供冗余，因此，我只使用写入cachingfunction为我的Amazon VM。
编辑： function点是执行I / O操作的延迟减less 。