【发布时间】：2015-08-31 13:50:54
【问题描述】：
当在 C 中调用 fseek() 或在任何现代语言（如 Python 或 Go）中对文件对象调用 seek() 时，在非常低的级别会发生什么？
操作系统或硬盘实际上是做什么的？ 读什么？ 会产生什么开销？ 块大小如何影响这种开销？
编辑添加：
给定块大小为 4KB 的 NTFS，寻找 4096 字节会比读取 4096 字节产生更少的 IO 开销吗？
第二次编辑：
如有疑问，请根据经验进行。
在 1.5GB 文件中使用一些简单的 Python 代码：
按顺序读取 4096：21.2
寻求 4096（相对）：1.35
求 4096（绝对）：0.75（有趣）
每隔 4096（相对）搜索和阅读一次：21.3
搜索并阅读每三分之一 4096（绝对）：21.5
平均时间以秒为单位。硬件是一台不起眼的 PC，带有运行 Windows XP 的 SATA 驱动器。
这非常令人失望。我有几 GB 的文件，我必须几乎不间断地阅读这些文件。文件中大约 66% 的 4KB 块是无趣的，我提前知道它们的偏移量。
最初，我认为重写所涉及的遗留代码可能是一个大胜利，因为它现在一次通过文件顺序读取 4096 个字节。假设 Win32 Python 没有在某些基本方面被破坏，合并搜索对于非随机读取没有任何优势。
【问题讨论】：
-
回答您的问题有点困难，因为“处于非常低的级别”实际上可能意味着很多事情......从硬盘驱动器可能必须进行的读取磁头移动到量子机械、磁盘控制器逻辑、文件系统簿记逻辑等。所有这些可能又取决于进一步的因素：你有硬盘驱动器（移动部件）还是 SSD（没有移动部件）？您使用的是什么文件系统？什么操作系统？
-
只是为了寻找，可能什么都没有。内核很可能缓存了文件的大小，并且可以在不执行任何 I/O 的情况下成功或失败查找。
-
我实际上几乎包括在我最初的问题中，我对物理头部运动不感兴趣。但是，我不想排除任何影响性能的事情。电子和磁通量水平？不。头部运动来阅读？是的。
标签： file-io ntfs hard-drive