背景
我在三重复制的 Gluster 卷上运行 Dovecot IMAP 存储时遇到了一些文件锁定问题。该卷glusterfs
使用默认类型安装。这意味着 FUSE 安装。操作系统是 Fedora 28,内核 4.18.18-200.fc28.x86_64。
<host>:/volume /mount glusterfs defaults,x-systemd.automount,noauto 0 0
dovecot.index*
在我的电子邮件客户端 (Thunderbird) 中移动大量邮件时,文件日志中出现文件锁定错误。在研究该问题时,我发现了一些Dovecot 文档关于共享文件系统。
问题
关于设置的建议对lock_method
我来说似乎很清楚。我对内存映射部分有具体的问题:
默认为 Dovecotmmap() 函数索引文件。这可能不适用于所有集群文件系统,并且它肯定不能与 NFS 一起使用。设置 mmap_disable = yes 会禁用 mmap(),Dovecot 会执行其自己的内部缓存。如果您的文件系统支持 mmap(),仍然不能确定它是否能提供更好的性能。请尝试进行基准测试以确保无误。
我会受到影响吗?FUSE+GlustFS 是否mmap()
以适当的方式支持?
研究
当我在互联网上寻找答案时,我发现了以下混乱:
- python 的一些问题SO 上的开发
mmap()
尝试在共享模式下使用。 - Numpy 上一个封闭的 PR,试图修复
mmap()
界面。
但这些都是与 Python 相关的,我不确定 Dovecot 如何实现mmap()
。我还在以下位置找到了一个补丁:伦敦华人网:
From: Tejun Heo <[email protected]>
To: Miklos Szeredi <[email protected]>, lkml <[email protected]>,
[email protected]
Subject: [PATCH] FUSE/CUSE: implement direct mmap support
Date: Tue, 09 Feb 2010 15:08:36 +0900
Cc: Lars Wendler <[email protected]>,
Andrew Morton <[email protected]>
Implement FUSE direct mmap support. The server can redirect client mmap
requests to any SHMLBA aligned offset in the custom address space attached
to the fuse channel. The address space is managed by the server using
mmap/munmap(2). The SHMLBA alignment requirement is necessary to avoid
cache aliasing issues on archs with virtually indexed caches as FUSE
direct mmaps are basically shared memory between clients and the server
但这仅解决了 FUSE 整体问题,并没有真正肯定地回答我的问题。
答案1
总体而言,GlusterFS 支持得mmap()
很好。如果出现问题,那将是一个错误。GlusterFS 有几个性能特性可能会给多线程或多客户端工作负载带来麻烦。您可能想要尝试禁用以下所有或部分选项:
- 性能预读
- 性能.后写
- performance.readdir-ahead 和 performance.parallel-readdir
- 性能.快速读取
- performance.stat-预取
- performance.io-cache
例如:gluster volume set ${VOLUMENAME} performance.read-ahead off
在您链接的 Dovecot wiki 页面,有一段关于FUSE/GlusterFS的文字:
FUSE 在内部缓存目录项和文件属性。如果您使用多个 GlusterFS 客户端访问同一个邮箱,就会遇到问题。使用 NFS 缓存刷新可以避免这些问题中最糟糕的情况,而 NFS 缓存刷新恰好也适用于 FUSE:
mail_nfs_index = yes mail_nfs_storage = yes
这些可能不太完美。
我不知道为什么它不能完美地工作……最好能有一些关于它的详细信息。对于大多数工作负载,GlusterFS 的行为与 NFS 几乎相同,因此建议也相同。