On 16 Aug 2017, at 8.37, Alexey Asemov (Alex/AT) lists@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.