Obox Storage Support: NFS

Prerequisites

To use Obox over NFS you need at least NFSv3 capable storage shared to all your backends.

All your hosts must be using clock syncronization. Not using clock synchronization will cause problems.

Mail delivery must be set to use LMTP for deliveries.

You cannot use Quota Service.

Setting up

You need to provision NFS shares, either all in one, or one for mail, and one for indexes. FTS indexes can be stored in same place as indexes. Recommendation is to have FTS and index shares on fast disk and mail storage can be on slower disk. If all the disks are fast, you can also have all on same share.

Configuration

plugin {
  obox_fs = fscache:1G:/data/fscache:posix:prefix=/data/index/%2LMu/%u/fts/:no-fsync:accurate-mtime:dirs
  obox_index_fs = fscache:1G:/data/fscache:posix:prefix=/data/index/%2LMu/:no-fsync:accurate-mtime:dirs
  fts_dovecot_fs = fts-cache:fscache:1G:/data/fts-fscache:posix:prefix=/data/index/%2LMu/%u/fts/:no-fsync:accurate-mtime:dirs
}

It is recommended to use encryption and compression with obox and fts indexes for security and performance reasons. See Obox Configuration.

NFS tuning

NFS has many tunings, please consult your NFS vendor for details. For Dovecot, these are strongly recommended:

• actimeo=60: This or the more specific settings can be used to control NFS caching. Increasing this can reduce NFS traffic. It should be at least 60 seconds.
• nordirplus: Disable readdirplus operations, which aren’t needed by Dovecot. They can also slow down some NFS servers.
• noatime: Disable updating atime. Dovecot doesn’t need this and it may slow down NFS servers.
• root_squash: Dovecot doesn’t care about this. Typically Dovecot doesn’t store any root-owned files in NFS.
• nolock / local_lock=all: This is possible to use as a slightly unsafe optimization. All file locking is handled only locally instead of via NFS server. Assuming the cluster works perfectly, there is no need to use locking across NFS. Each user only locks their own files, and the user should only be accessed by a single server at a time. Unfortunately, this doesn’t work 100% of the time so in some rare situations the same user can become accessed by multiple servers simultaneously. In those situations the mails are more likely to become corrupted if nolock is used. However, if indexes and emails are on different mountpoints, email corruption shouldn’t be possible if the nolock is enabled only for the index mountpoint. This can still increase the likelihood of index corruption (which can lose message flags), but locking won’t prevent index corruption completely anyway.