On Mon, 2006-10-16 at 16:55 +0100, David Lee wrote:
Picture: A set of very similar UN*X IMAP servers all NFS-mounting their INBOX area (traditional Unix format) from a common "/var/spool/mail" area; activity for any given user ought to be within one box although this cannot be 100% guaranteed. There is the risk of multiple simultaneous access (e.g. simultaneous LDA/delivers; simultaneous LDA/deliver and user-driven IMAP update; etc.). So locking is an important consideration. Decent "noac,actimeo=0" seems to address this succcessfully.
But indexes...
What is the best place for the index files? Logically alongside the INBOX area on the shared-NFS area? Or within each UN*X machine? (Or something else?) And why?
If you have attribute cache disabled and it actually works, then index files could be placed on NFS safely. I did some stress testing a few months ago with two computers simultaneously reading and modifying the same mailbox and it worked, but only after using a Linux kernel with some NFS fix patches. I guess newer Linuxes would work without patches.
Is there documentation of what functionality the index files provide, and how, if at all, this interacts with the locking of INBOXes (and folders).
The point of the indexes is that Dovecot tries to get all the needed information out of them so that it doesn't even have to open the actual mailbox file. Only when user actually fetches some mail's contents the mbox is opened and locked. And when Dovecot notices that new mails have arrived.
At least that's the theory. v1.0 Dovecot doesn't write all the useful information directly into cache file while it's saving/syncing mails, so it has to open the mbox file a bit more often. v1.1 should fix this too. :)
In general what the index files contain is:
dovecot.index: Message sequence <-> UID mapping, flags, keywords, mbox file offsets and some other pointers.
dovecot.index.log: Just a transaction log describing changes what have been done to dovecot.index.
dovecot.index.cache: Cached message data. Dovecot tries to be smart and keeps only the data that clients actually want in here, so its contents are more or less client-specific. Anyway typical things include message dates, some specific headers, message size, MIME structure, etc.