我想知道，如果您有一個特別大的文件，例如 64 MB，是否可以找出該文件的物理硬碟位置，然後從特定偏移量讀取位元組到該文件中？
假設我對距離檔案開頭偏移 60 MB 的 100 個位元組感興趣。如果我使用某些應用程式級別的eek()函數，我不希望從文件開頭到文件末尾需要進行數百次磁碟搜索，效率低下。
有解決辦法嗎？
非常感謝！
答案1
您似乎對seek()行為方式有誤解。它確實盡可能有效率地找到儲存此偏移量處的資料的位置，而無需讀取中間位元組。將有幾次查找（可能不是數百次）來遍歷區塊索引。
你不能做的是保存從文件打開時到下一次打開時的塊索引的遍歷。作業系統必須記住該文件自上次打開以來尚未被修改或重新定位，這將需要記住大量數據以獲得非常小的潛在收益。
請注意，文件的內容通常不在連續的磁碟位置。文件往往是碎片化的。檔案系統通常會嘗試減少碎片，但這通常不能保證。
答案2
重讀一遍，似乎我沒有回答潛在的問題：
在應用程式（實際上是核心）層級使用「查找」並不一定會花費磁碟上的任何「查找」 - 它所做的只是更新與檔案句柄關聯的偏移量。
一旦您要求內核讀取或寫入，它就會將該偏移量轉換為磁碟偏移量，這可能需要讀取區塊來弄清楚，但最好的情況是一次查找成本- 就像您的直接訪問一樣。
這樣做絕對是可能的：畢竟，這正是檔案系統驅動程式所做的事情，因此其他人也一定可以做到。您所需要的只是存取原始磁碟。
那裡 是 的 例子人們對現有檔案系統格式這樣做。如果需要，您也可以手動執行此操作。
如果檔案系統處於活躍使用狀態，您將面臨一些技術挑戰，這使得操作變得更加困難 - 因為磁碟上的內容正在以您無法完全看到的方式發生變化 - 但這仍然是可能的。
也可以直接詢問內核；這xfs_bmap工具可以做到這一點，並且至少某些文件系統實現了相同的接口，因此您可以直接詢問。
不過，計算位置將花費與內核相同的搜尋次數，因此您不太可能實際保存任何事物做這個。
答案3
我不這麼認為。
如果開啟文件，您將位於開頭（用於讀取/寫入）或結尾（用於追加）。即使在「更新模式」下，您也不會簡單地落在檔案中間的某個指定位置。
我認為你能做的最好的事情就是你已經逃避的事情：如果你可以計算從一開始的偏移量，你就可以直接尋找該位置並讀取資料。我認為這之間不會涉及任何過多的讀取操作。開啟檔案後的下一次讀取應該位於計算出的偏移量處。