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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20061016/2c7c0b4c/attachment.bin>