On 16 Aug 2017, at 8.37, Alexey Asemov (Alex/AT) <li...@alex-at.ru> wrote:
>
> Hello Timo,
>
> I am quite eager to test it, but I don't know if these changes can be
> applicable for my configuration (it is shared storage one, any mdbox on NFS
> can be accessed by multiple servers, I made it so it's mostly accessed by
> one, but at certain conditions multiple servers still access mailbox
> simultaneously).
>
> So if possible I want to ask few dumb questions:
>
> - I assume VOLATILEDIR can't be used with configurations where multiple
> servers access the same mdbox because lockfiles need to be shared as well? Or
> does this option touch only some (lock)files that do not need to be shared
> between servers accessing same mailbox?
If you're using e.g. Dovecot director, it should be very unlikely that multiple
servers access the same user simultaneously. Currently only two lock files use
VOLATILEDIR:
* .vsize.lock: Used to update folder's size in dovecot.index. So the worst
that can happen is that the vsize becomes wrong. If you're using quota=count,
it could become wrong. But this gets fixed automatically anyway later on.
* autoexpunge.lock : Only used if you have autoexpunge settings.
> - Would LISTINDEX indexes be regenerated properly for mdbox if
> lost/corrupted? Properly, meaning without losing flags, message numbering or
> some other vital data. If yes, then I assume they can be stored on local
> storage per server, and not on NFS. If LISTINDEX can be regenerated, will
> LISTINDEX be updated if it's detected to be obsolete compared to accessed
> mdbox contents?
dovecot.list.index* don't have any especially vital information, like message
flags. So it can be fully regenerated. You have 3 options actually:
a) Use mailbox_list_index_very_dirty_syncs=yes and keep LISTINDEX in NFS: This
optimizes LIST
b) Use mailbox_list_index_very_dirty_syncs=no and put LISTINDEX to local: This
automatically updates the list index as necessary, but it does some extra
stat()s on the folders to make sure they're up-to-date in the list index.
c) Use mailbox_list_index_very_dirty_syncs=yes and put LISTINDEX to local: This
fully trusts the locally cached list indexes. It works only if you can
guarantee that the local list indexes aren't obsolete. So it requires some
scripting. For example you can store in NFS or in Redis or elsewhere the user's
last backend hostname. Then create a post-login script that deletes the list
indexes if the hostname doesn't match the current server where user is logging
in. This can also be optimized to run the script only when the hostname changes
by using the new userdb postlogin socket and %{if...} that is coming to
v2.2.33. Although there are also other ways.
