file-io - 当我调用 fseek() 时，底层会发生什么？

Question

当在 C 中调用 fseek() 或在任何现代语言(如 Python 或 Go)中对文件对象调用 seek() 时 - 在非常低的级别会发生什么？

操作系统或硬盘实际上做了什么？读什么？会产生什么开销？ block 大小如何影响这种开销？

编辑添加:

给定 block 大小为 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 block 是无趣的，我提前知道它们的偏移量。

最初，我认为重写所涉及的遗留代码可能是一个巨大的胜利，因为它现在通过文件一次顺序读取 4096 字节。假设 Win32 Python 在某些基本方面没有被破坏，合并 seek 对于非随机读取没有优势。

Answer 1

这在很大程度上取决于当前条件。通常，fseek() 仅更改流的状态(设置当前位置，或者如果参数错误则返回错误)。但是 - fseek() 刷新缓冲区，这可能会导致挂起的写操作。如果文件是 UTF8 文件并且启用了翻译，则从 fseek() 调用的 ftell() 需要读取文件的那部分才能正确计算偏移量。如果启用了 CRLF 转换，它也会引发读取操作。但是如果是普通二进制文件并且没有挂起的写操作，fseek() 只是在流中设置位置并且不需要转到较低级别。更多详细信息，请参见 CRT 的源代码。