У меня возникли проблемы с блокировкой файлов при запуске хранилища Dovecot IMAP на томе Gluster с тройной репликацией. Том монтируется с помощью 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 настройка мне кажется понятной. У меня есть конкретный вопрос по разделу «Отображение памяти»:
По умолчанию Dovecot mmap () s индексные файлы. Это может не работать со всеми кластерными файловыми системами., и уж точно не будет работать с NFS. Установка mmap_disable = yes отключает mmap (), а Dovecot выполняет собственное внутреннее кэширование. Если ваша файловая система поддерживает mmap (), все равно нельзя быть уверенным, что она дает лучшую производительность. Попробуйте выполнить сравнительный анализ, чтобы убедиться.
Подействовало ли это на меня? Поддерживает ли FUSE + GlustFS mmap() правильным образом?
Пытаясь найти ответ в Интернете, я обнаружил следующий хаос:
mmap() в общем режиме.mmap() интерфейс.Но они оба связаны с Python, и я не уверен, как Dovecot реализует mmap(). Я также нашел патч на lwm.net:
From: Tejun Heo <tj@kernel.org>
To: Miklos Szeredi <mszeredi@suse.cz>, lkml <linux-kernel@vger.kernel.org>,
fuse-devel@lists.sourceforge.net
Subject: [PATCH] FUSE/CUSE: implement direct mmap support
Date: Tue, 09 Feb 2010 15:08:36 +0900
Cc: Lars Wendler <polynomial-c@gentoo.org>,
Andrew Morton <akpm@linux-foundation.org>
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 в целом и не дает однозначного ответа на мой вопрос.
В целом GlusterFS поддерживает mmap() просто хорошо. Если что-то пойдет не так, это будет ошибкой. GlusterFS имеет несколько функций повышения производительности, которые могут создавать проблемы для многопоточных или многоклиентских рабочих нагрузок. Вы можете поэкспериментировать с отключением всех или некоторых из этих параметров:
Например: gluster volume set ${VOLUMENAME} performance.read-ahead off
На Вики-страница Dovecot, на которую вы указали, есть параграф про FUSE / GlusterFS:
FUSE кэширует данные и атрибуты файлов внутренне. Если вы используете несколько клиентов GlusterFS для доступа к одним и тем же почтовым ящикам, у вас могут возникнуть проблемы. Худших из этих проблем можно избежать, используя очистку кэша NFS, которая, как оказалось, также работает с FUSE:
mail_nfs_index = yes mail_nfs_storage = yesВероятно, они не работают идеально.
Я не знаю, почему это не сработало бы идеально ... Было бы неплохо узнать об этом подробнее. Для большинства рабочих нагрузок GlusterFS ведет себя почти так же, как NFS, поэтому рекомендации будут такими же.