c - 什么时候使用小读取的顺序查找比读取整个文件慢？

Question

我遇到过这样一种情况:lseek 重复向前遍历 500MB 文件并在每次查找之间读取一小块(300-500 字节)似乎比 read 慢 从头开始​​遍历整个文件并忽略我不想要的字节。即使我只进行 5-10 次搜索(所以当我最终只读取文件的 ~1% 时)，这似乎也是正确的。我对此感到有点惊讶——为什么重复向前搜索(应该涉及更少的工作)比实际上必须将数据从内核空间复制到用户空间的读取要慢？

据推测，在本地磁盘上寻找时，操作系统甚至可以向驱动器发送消息进行寻找，而无需通过总线发送回任何数据，以节省更多费用。但是我正在访问一个网络挂载，我希望读取的速度比查找慢得多(发送一个数据包说要向前移动 N 个字节，而不是实际通过网络传输数据)。

无论是从本地磁盘读取还是从网络文件系统读取，怎么会发生这种情况？我唯一的猜测是操作系统在我寻找的每个位置之后预取大量数据。这是通常会发生的事情还是可能表明我的代码中存在错误？

Answer 1

差异的大小将是正在读取的寻道计数/数据与整个文件大小的比率的一个因素。

But I'm accessing a network mount, where I'd expect read to be much slower than seek (sending one packet saying to move N bytes ahead versus actually transferring data across the network).

如果网络的另一端存在旋转磁力驱动器，这种影响仍将存在，并且可能会因往返时间而显着加剧。网络协议(protocol)也可能发挥作用。即使是固态驱动器也可能会受到一些惩罚。

I/O 调度程序可能会重新排序请求，以尽量减少磁头移动(即使对于没有磁头的存储设备，也可能天真)。单个批量请求可能会给您带来跨多个层的更高效率。文件系统有机会在这里进行一些干预。

Regardless of whether reading from local disk or a network filesystem, how could this happen?

我不会很快忽略这些层的影响——您是否有测量显示本地磁盘的相同行为？如果您和硬件之间没有太多关系，就可以更容易地得出结论。从原始设备开始，然后从那里一分为二。

您是否考虑过使用内存映射？它非常适合此用例。