有谁知道在调用 'seek' 和 'read' 时，硬盘在物理上会受到怎样的影响？
如果我更具体一点，我知道硬盘驱动器有某种磁针，用于从磁板上读取数据。所以我的问题是，针实际上是什么时候移动到阅读位置的？
当我们调用“seek”windowsApi 方法时它是移动的（无论是否执行了实际读取），还是“seek”只记住一个虚拟指针，并且指针的物理移动仅在“ read" 方法被调用了吗？
编辑：假设从硬盘驱动器请求的数据不存在于任何缓存中（硬盘驱动器缓存、Os Cache、Ram 和其他任何可能的缓存）
【问题讨论】：
标签： windows winapi file-io filesystems hard-drive
想从你的帖子中提出这个问题
指针实际上是什么时候移动到读取位置的？
我认为简单的答案是“只要请求的数据尚未存在于任何数量的缓存中”。预测硬盘驱动器移动的问题是您必须考虑缓存从硬盘驱动器读取的数据的所有不同位置。如果数据存在于这些缓存中并且可以在请求数据的上下文中访问，则将使用缓存而不是实际读取硬盘驱动器。这里只是一些可以缓存硬盘数据的地方
在没有数据存在的情况下，它可能会在read 调用期间从硬盘驱动器中读取。 seek 调用不太可能导致硬盘驱动器移动，因为您更改的不是物理硬盘驱动器指针，而是指向程序中文件的虚拟指针。
【讨论】：
在read 操作时，硬盘磁头（针）开始移动，磁盘开始旋转（除非已经旋转）。 seek 操作中没有头部移动或旋转。
请注意，即使您按顺序reading 文件，磁头也可能在磁盘上方不连续移动，即第 2、3 等 512 字节块的read 可能会导致磁头移动很远即使没有干预seeks，也会离开。这部分是因为文件在文件系统上是碎片化的，或者是因为固件具有扇区号重新映射（即逻辑扇区 5 不在逻辑扇区 4 和 6 之间）以补偿坏块错误。
【讨论】：
“假设从硬盘驱动器请求的数据不存在于任何缓存（硬盘驱动器缓存、Os Cache、Ram 和其他任何可能的）”问题中的假设很难假设并且比较少见。即使在这种情况下，用户模式文件 I/O 操作和物理存储设备操作之间也只有松散的关联。
在各种 Windows 库中有许多用户模式文件 I/O 函数。其中一些最古老的是C library low level I/O functions。还有C library stream I/O functions、C++ iostreams classes 和manged I/O classes。还有其他 I/O 接口是其他包的一部分。
一般来说，所有用户模式 I/O 库都建立在 Win32 file I/O functions 之上，包括 CreateFile()、SetFilePointer()、ReadFile() 和 WriteFile()。
除非文件以非缓冲模式打开，否则操作系统可以缓存文件内容。这是在系统范围内完成的，而不是在每个文件的基础上完成的。因此，即使您的程序没有读取或写入文件，文件的 I/O 也可能会被缓存，不会导致任何物理存储设备 I/O。
决定文件 I/O 如何映射到物理设备上的实际 I/O 操作的因素有很多。这包括库级缓冲、操作系统缓存、设备驱动程序缓存、硬件级缓存、设备块大小、文件大小、硬件块/扇区重新映射以及其他因素。
这里的简短故事是，您不能假设单个文件级别的读取或查找操作对应于物理设备操作，例如磁盘磁头查找。
当考虑写入时，这变得更加棘手。写入通常伴随着刷新 - 应用程序开发人员认为这会将数据一直推送到物理介质。开发人员经常假设，当刷新调用返回成功时，可以保证数据在存储设备上保持持久性。这远非如此，因为设备和驱动程序经常忽略刷新调用。
固态驱动器的复杂性更高，它们不是机械的，因此没有“寻道”操作。在这里，其他物理特性会表现出来，例如在写入块之前必须擦除它们。
【讨论】：