C++ 如果并行执行，磁盘文件操作是否会更快？

假设有N个文件要完全写入磁盘（即从所有文件缓冲区刷新）。对于每个文件，我们使用

WriteFile

写入少量数据（相对于HDD寻道时间），例如64KB，然后在该文件上调用

FlushFileBuffers

，以确保该文件的数据完全刷新到硬盘驱动器

如果我们按顺序一个接一个地写入和刷新文件，那么我预计大约需要时间

N*seekTime

+

N*writeTime

，其中

seekTime

是将硬盘磁头定位到正确扇区的时间（可能需要整个磁盘旋转的时间），而

writeTime

是磁盘按顺序写入64KB数据所需的时间。使用这种一个接一个的方法，我们没有给操作系统优化的空间，因为我们定义了文件刷新的顺序

在操作系统的支持下，可以通过重新安排文件写入和刷新的顺序来实现性能改进，以便考虑磁盘旋转（即磁头在磁盘上的当前位置），重新安排文件操作，以便从几乎不需要旋转的操作开始（即离磁头当前位置最近的位置）并以需要几乎完全旋转磁盘的位置结束

---

问题是：操作系统（特别是Windows）是否提供了这样的优化？换句话说，在N个线程中并行运行文件写入和刷新操作（每个文件一个线程）可以提高性能？还是会导致额外的重新定位操作降低性能（作为硬盘驱动器的一种上下文开关）？

您需要进行基准测试，因为它是特定于操作系统、文件系统和硬件的。在我的Linux系统上，许多文件操作都要经过测试，因此如果两个程序（或同一程序运行两次）在几乎同时访问文件时，最新的访问可能不涉及任何物理磁盘I/O。Linux和POSIX甚至有一些系统调用来帮助页面缓存（，…）

我不知道Windows，但听说并相信有传言说它在这种缓存上不如Linux高效

硬件限制通常是一个非常重要的瓶颈。用SSD替换磁盘可能是值得的

---

AFAIK、旧的BSD、SunOS和Linux磁盘驱动程序进行了您建议的优化（重新组织I/O操作以降低寻道和旋转延迟）。今天，这并不重要（磁盘控制器本身将“逻辑”扇区映射为“物理”扇区）.

我相信Windows没有任何IO调度，事实上它甚至将大型IO分解为256KB。Linux内置了IO调度

也就是说，一些驱动程序和磁盘会进行一些重新排序。通常，IO/sec速率会增加到更高队列深度的某个点。Crystal Disk benchmark具有QD32模式

SSD确实做到了这一点，这在具有高队列深度的基准测试中很容易看到。SSD还具有硬件并行性。当您增加随机读取的队列深度时，它们会变得更快

---

我在Windows桌面磁盘上发现，通过IOs进行的顺序小写的速度比磁盘查找速度快得多。要么控制器是写缓存，要么磁盘几何结构确实适合于顺序写入，即使没有缓存。

您应该首先问自己，并在这里解释，为什么需要刷新。您需要什么想要实现的不一定是实际发生的事情

如果您确实希望以某种方式优化应用程序，从而在物理设备上产生特定的访问模式，那么您的解决方案将非常依赖于硬件。在测试用例上进行优化可能会在另一种情况下产生相反的效果。例如，文件碎片呢？raid磁盘呢？网络文件系统呢？SSD驱动器呢？同一台机器上运行的其他进程对同一磁盘的并发访问呢

---

使磁盘访问速度更快的关键是缓冲。如果不一定需要缓冲，就不要破坏它。

优化是在径向磁头运动上完成的。操作系统对轴向位置没有任何线索。为了持久性，我需要刷新：在采取下一步之前，确保数据实际写入磁盘。我可以刷新这些N个文件，以n任何顺序，甚至并行。重要的是每个文件的数据都会物理写入磁盘。让我们将范围限制在旋转磁盘（无SSD），忽略文件碎片（假设用户定期整理磁盘碎片以提高性能），并没有网络文件系统，忽略其他进程的磁盘访问。RAID很有趣。我们不要采取“不要优化任何东西，因为它毫无意义”的方法。我并不是试图在必要时阻止优化。我只是想确保您意识到，您想要的东西可能会导致一个脆弱的解决方案，该解决方案可能会在任何时候、出于任何原因停止提供您想要的好处。如果您意识到这一点，好吧。我知道其中的复杂性。这是一个重要原因ASON为什么我在Stackoverflow上问这个问题，而不是仅仅对两个选项进行基准测试，并在我的机器和测试用例中选择更快的选项。我问这个问题是为了从根本上理解问题，从而使预测（在某种程度上）成为可能选择的解决方案在我的性能测试用例未涵盖的情况下如何工作。关键问题是操作系统（尤其是Windows）是否（以及如何）优化针对不同文件的并行HDD写入+刷新请求。