On Thu, 12 Oct 2006, John Peacock wrote:
Timo Sirainen wrote:
Yep, this is a problem with dovecot.index.cache file created with 32bit machine not working in 64bit machine. It should automatically detect this and delete it, but for some reason it doesn't seem to work always. You could do the exact same thing manually anyway by deleting them.
Yes, but the OP was reporting trying to run *both* a 32-bit and a 64-bit server sharing the same NFS-mounted filesystem. In other words, either you (Timo) need to change the indexes to be platform independent (i.e. no 64-bit-isms) or you need to put a BIG WARNING to not share the message indexes between different width platforms. The performance hit of repeated nuking of the index files is going to be huge.
Indeed. A fix, or a warning, would be very useful
Obviously, the OP could also configure the index files to be located on a local filesystem (i.e. not shared in the message store), which should also be higher performance under all circumstances with networked message stores...
In such a set-up (set of front end IMAP/LDA machines, accessing shared inbox/folder stores over NFS), what is the recommended place for the indexes? Shared (logically alongside the shared inbox/folder areas)? Or privately within each IMAP/LDA machine?
What are the locking implications on a busy mailstore?(*) Although we try to keep all activity for a given user on one machine, we cannot guarantee this. Suppose an email LDA/delivery occurs on one machine concurrently with an IMAP update to the same folder from a different machine? Or similarly multiple simultaneous deliveries on different machines? Etc. What are the locking considerations for indexes then?
(*) We use trad. UNIX format. Not ideal. But we're not in a position to migrate to (say) maildir.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :