大文件内存管理

我正在寻找关于如何处理我的库中透明和明智地处理对大型（由大于可寻址内存定义的）文件/块设备的访问帮助。假设我们在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

大文件内存管理

回答

相关问题