有誰知道什麼時候調用'seek'和'read'，硬盤驅動器如何受到物理影響？有關硬盤驅動器的問題，「搜索」和「讀取」在Windows操作系統
如果我會更具體一些，我知道硬盤有一些用來從磁盤讀取數據的磁針。所以我的問題是，針是什麼時候移動到閱讀位置？
當我們調用「seek」windowsApi方法時（無論是否執行實際讀取），還是「seek」只記住一個虛擬指針，並且僅在「讀取」方法被稱爲？
編輯：假設從硬盤驅動器所請求的數據不以任何緩存的存在（硬盤驅動器高速緩存，操作系統的緩存，內存和其他任何可能是）
本來是想從你的帖子中打出這個問題
什麼時候針實際移動到閱讀位置？
我認爲最簡單的答案是「只要數據被請求不存在於任何數量的緩存中」。預測硬盤移動的問題是您必須考慮緩存從硬盤讀取數據的所有不同位置。如果數據存在於這些高速緩存中並且在請求數據的上下文中可訪問，則將使用高速緩存而不是實際讀取硬盤驅動器。這裏只是一些地方，可以做緩存的硬盤數據
在在沒有數據存在的情況下，在撥打read時可能會從硬盤讀取數據。 A seek調用不太可能導致硬盤移動，因爲您沒有更改物理硬盤驅動器指針，而是在程序中指向該文件的虛擬指針。
硬盤驅動器磁頭（針頭）開始移動，並且磁盤開始旋轉（除非已經旋轉）read操作。在seek操作中沒有頭部移動或旋轉。
請注意，即使您依序對文件進行文件傳輸，磁頭也可能在磁盤上方不連續地移動，即第2,3等512字節塊的read也可能導致磁頭移動得太遠即使沒有介入seek s。這部分是因爲文件在文件系統上被分割，或者因爲固件具有重新映射扇區號（即邏輯扇區5不在邏輯扇區4和6之間）以補償壞塊錯誤。
這個問題中的假設「假設從硬盤驅動器請求的數據不存在於任何緩存（硬盤驅動器緩存，Os緩存，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操作的因素很多。這包括庫級別緩衝，操作系統兌現，設備驅動程序緩存，硬件級別兌現，設備塊大小，文件大小，硬件塊/扇區重新映射以及其他因素。
這裏的一個小故事是，您不能假定單個文件級別的讀取或查找操作對應於物理設備操作，例如磁盤頭查找。
考慮寫入時，這會變得更加棘手。寫入通常伴隨着一次刷新 - 應用程序開發人員將採用這種刷新方式將數據一直推送到物理介質。開發人員經常認爲，當刷新調用返回成功時，數據將保證在存儲設備上保留。這遠非如此，因爲設備和驅動程序經常會忽略刷新調用。
固態硬盤存在更多的複雜性，因爲它不是機械的，因此沒有「搜索」操作。在這裏，其他的物理特徵也表現出來，例如在塊被寫入之前擦除塊的必要性。
讓我們假設所請求的數據不存在於緩存中。 – user88637 2009-05-03 15:20:16