[Dovecot] Dovecot 1.0-test45 indexing issues

[dovecot at spam.turbolink.net]

On Wed, 22 Sep 2004, Timo Sirainen wrote:

> On 22.9.2004, at 01:17, dovecot at spam.turbolink.net wrote:
>
> > T 192.168.199.48:57262 -> 192.168.196.53:143 [AP]
> >   27 uid store 5957 -Flags (\Seen)..
> >
> > very large delay here, 60-90 seconds
>
> Hmm. I can't really think of many reasons for this to happen.. Have you
> set mbox_dirty_syncs=no? If not, try it and see if it makes any
> difference?

I did try it both ways, because I wasn't sure whether yes or no would
produce the behavior described in the example.  It didn't seem to make
much of a difference.

> Only reason why it would do rereading there is if the message wasn't at
> the expected position in the mbox file. And if no-one else modified the
> mbox, the only reason for it is if Dovecot had somehow corrupted the
> message offset in index file.

How/where exactly could I check for these conditions?  I'm pretty familiar
with gdb but not with the new indexing code.  I set a breakpoint on
mbox_sync and tried to follow it through but I haven't been able to
pinpoint exactly where the decision is made to re-read or not.

> Your indexes are stored in NFS too? Have you set mmap_disable=yes then?

No, indexes are not on NFS.  I was doing some performance testing with
indexes on a local disk (XFS) and also with indexes in a ramdisk, but it
occurred with both.

- Mike