File io 当我调用fseek（）时，在低级别会发生什么？

在C-or中调用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

平均时间以秒为单位。硬件是一台运行Windows XP的SATA驱动器的普通PC

这非常令人失望。我有几GB的文件，我必须在几乎连续的基础上阅读。文件中大约66%的4KB块是无趣的，我提前知道它们的偏移量

---

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

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

回答您的问题有点困难，因为“非常低的级别”实际上意味着很多事情。。。从硬盘驱动器可能必须进行的读取头移动到量子力学、磁盘控制器逻辑、文件系统簿记逻辑等。所有这些可能再次取决于其他因素：您是否有硬盘驱动器（移动部件）或SSD（无移动部件）？您使用的是什么文件系统？什么操作系统？只是为了寻找，可能什么都没有。内核很可能缓存了文件的大小，可以在不做任何I/O的情况下成功或失败查找。实际上，我在最初的问题中几乎提到我对物理头部运动不感兴趣。但是，我不想排除任何影响性能的因素。电子和磁通量水平？不，头要动吗？对