比如 4 个程序（和 CPU 数相同）读同一块硬盘上的文件（文件名连续），文件都不相同，和一个程序依次读这些文件，最后时间谁多谁少呢？同时读的总时间为各程序的执行时间之和。假设内存足够。

对硬盘底层并不了解，我想如果来回切读取的位置，那读头应该会频繁移动，反而将时间耗在随机寻址上，相比单个程序顺序读，要慢不少，是这样吗？如果是这样的话，那一台机器难免会多个程序同时运行，难免会同时读取（这就更不说写入了），那这很难协调让效率最大化了？

文件大，无所谓。文件小，多个快。
如果文件远小于内存，只有读请求，来回 seek 影响不大。
文件名不影响文件读取数度，但我猜你的意思是文件是顺序创建的。

现在的硬盘都支持 ncq 了，会对队列顺序重新排序使磁头移动距离最少

只有一个磁头，文件碎片造成性能下降就是体现之一

如果文件不大,可以在内存虚拟一个硬盘出来放里面,就不考虑这些问题了

机械硬盘都要移动磁头寻道的然后读取的，底层理论上是顺序读写的， ncq 的意义就是把多个不同的请求尽量合并在一次寻道来读取。

多个程序读多个文件和一个程序读多个文件对操作系统的系统调用来说都是一样的，本质上不会有差异的。


这个场景中， ncq 需要多程序读才可能有作用吧，如果一个程序读没有太多队列信息用来排序啊。

不要把精力花费在无意义的优化上

文件本身并不一定是连续存储的

是的。但是一个程序总要按文件实际的存储位置依次顺序读下去，我的疑问是，我还没读到后面， ncq 怎能能知道我后续的磁头定位信息？

不要把操作系统当弱智好吧。。

你这个问题相当于这样：
要读取磁盘上的多个文件，让操作系统优化读取过程相比于自己写一个程序来读，会慢吗？

如果你需要更多性能， Linux 下可以调大 readahead 以及用 deadline scheduler ，据说 deadline 对某些情况有奇效
Windows 不知道有什么可调整
另外………上 SSD ，卍解
用 fadvise 或者异步 IO