1

我在我的 fuse 文件系统实现上运行用于 fileio 的 dbench 基准测试工具，并且我确保该 fuse 可以维持测试。

我正在使用 libfuse 库（https://github.com/libfuse/libfuse）来实现 fuse。我没有做任何花哨的事情，我只是让它通过，读取只是做 pread，写只是做 pwrite。

我让它运行了大约 10 个小时，我看到内存从 0 稳定增加到 21G。有没有其他人看过这个？我检查了代码中的内存泄漏，但我正在做非常简单的直通代码，我没有专门分配堆内存。就像一个简单的读取函数看起来像这样。FUSE_DATA 是在主函数中分配的全局结构。

void fuse_fullpath(char fpath[PATH_MAX], const char *path, const char * rootdir)
{
    if (rootdir == NULL || path == NULL) {
        return;
    }
    strcpy(fpath, rootdir);
    strncat(fpath, path, PATH_MAX);
}

static int fuse_read(const char *path, char *buf, size_t size, off_t offset,
        struct fuse_file_info *fi)
{
    int res;
    char fpath[PATH_MAX];
    fuse_fullpath(fpath, path, FUSE_DATA->rootdir);

    res = pread(fi->fh, buf, size, offset);

   if (res == -1) {
       res = -errno;
   }

   return res;

}

我在 fuse 上尝试了 valgrind，它的报告在 libgobject 库中给了我很多这样的信息。

==31923== 8 bytes in 1 blocks are still reachable in loss record 2 of 245
==31923==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31923==    by 0x54E0668: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==31923==    by 0x4E63315: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==31923==    by 0x4E67108: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==31923==    by 0x4E6FF71: g_pointer_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==31923==    by 0x4E6FFF7: g_gtype_get_type (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==31923==    by 0x4E558E7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
4

0 回答 0