On 1.2.2007, at 3.39, Nate wrote:
- Third connection. It takes ~40 seconds to display a LIST after
login. The index files are untouched; however, during the 40
seconds I'm waiting, I can catch a few of these in lsof. pop3 1971 postfix 10r REG 8,3 4196 205963 /var/spool/ mail/test.visp.net/natetest/cur/1157863512.V902I1f3867.s3.visp.net:2,SThis tells me even though there is no new email, it is re-scanning
the cur/ directory somewhat. It doesn't take near as long as the
initial index build, but certainly takes longer than it would for
the system to read any or all of the listed index files above. Why
would dovecot need to even enter cur/ if the index file is up to
date? Is it verifying that the index file is up to date by re- reading some or all of the many files in cur/? If so, could it not
get the info it needs by simply doing the equivalent of a ls, which
would take considerably less time?
The reason why the messages are read in the first place is because
the message sizes need to be returned so that linefeeds are counted
in CR+LF format, while they're typically stored in LF-only format. So
if Dovecot just stat()ed the file and returned that as the message's
size, it would be violating the POP3 spec. tpop3d seems to be doing
that.
It sounds like dovecot.index.cache file doesn't contain all the
messages' sizes for some reason, and Dovecot goes and re-reads those
files again to get the sizes. I'm not sure why it wouldn't contain
the sizes though, so it sounds like a bug somewhere.
I think this fixes it: http://dovecot.org/list/dovecot-cvs/2007- February/007582.html