大文件內存管理

我正在尋找關於如何處理我的庫中透明和明智地處理對大型（由大於可尋址內存定義的）文件/塊設備的訪問幫助。假設我們在32位架構上擁有512GB大小的塊設備。 512GB的方式比我們在32位架構上可以解決的要多，使用mmap()管理內存中的設備/文件部分是我試圖避免的。我試圖實現的是，獲得以64位數/偏移量尋址的塊，並且這些塊是任意大小的，但是每個設備都是靜態的（512字節，4K，8K，64MB等）。調用者只需要獲取內存地址，不需要考慮釋放內存或將實際內容加載到內存中。大文件內存管理

我在想一個機制如下：

有點像void* get_file_address(unit64_t blk_offset)調用採取一個偏移量（塊數），並且檢查是否該塊已被映射，如果沒有在讀取，因此它映射
一些結構，用於跟蹤訪問計數的到塊（更新在每get_file_address呼叫）
如果存儲器變低，並且開始卸載使用之前提到的結構

最後一點讓我很惱火：自己寫內存管理器似乎並不理智。另外，我確定我不是第一個遇到這個問題的人。

那麼有沒有解決方案/庫/ codefragment那裏已經有助於管理這樣或類似的情況？我對Win，Linux，* BSD或者OS X的解決方案沒問題。

來源

2013-08-31 grasbueschel

爲什麼不'mmap'只能訪問文件的某個特定部分並按照塊的形式訪問它？ 'mmap'支持偏移量尋址，所以你可以用4K塊來遍歷文件。 – Nobilis

@Nobilis，因爲如果我必須使用mmap，我也必須使用munmap - 這是我想避免編碼自己的內存管理器的工作，因爲工作看起來好像已經完成了：獲取內存地址透明地提供一個設備/文件+偏移量。 – grasbueschel

看起來你需要512GB的交換... 我在開玩笑，jeez ... –

我會使用「framed mmap」和「大文件支持」，這是Linux的一部分，因爲很久以來。從Wikipedia開始，然後轉到技術細節within the SuSE web site。

還有some examples在線和幾個答案here stackoverflow。我不認爲你可以很容易地找到一些預煮庫。就像上面的鏈接所暗示的那樣，處理大型多媒體文件的軟件的源代碼可能會有所幫助，而它們的「框架」特性可能會導致一些有趣的片段。

來源

2013-08-31 20:12:19 Enzo

大文件內存管理

回答

相關問題