[Dovecot] some mail accesses in dovecot 1.1 stall for a bit (in progress)

[Timo Sirainen]

On 11.11.2007, at 19.28, Adam McDougall wrote:

> On Fri, Nov 09, 2007 at 10:06:00AM -0500, Adam McDougall wrote:
>
> [snip]
>
>     pwrite(0xd,0x7fffffffcb44,0x4,0x0,0xc6f3c)       = 4 (0x4)
>     pwrite(0xd,0x7fffffffcb44,0x4,0x0,0xc6f74)       = 4 (0x4)
>     pwrite(0xd,0x7fffffffcb44,0x4,0x0,0xc6fac)       = 4 (0x4)
>     pwrite(0xd,0x7fffffffcb44,0x4,0x0,0xc6fe4)       = 4 (0x4)
>     pwrite(0xd,0x7fffffffcb44,0x4,0x0,0xc701c)       = 4 (0x4)
>
>   I did a little more checking to confirm that the filehandle being  
> written
>   to is dovecot.index.cache.
>
> Just to update, right now I am not seeing this issue, but I've made
> a number of changes this weekend and something may have affected it.
> I'll bring it up again if I see it, but still writing in chunks of
> 4 bytes seems suboptimal to me in any case but I won't care if it
> doesn't happen :)

That kind of behavior happens when Dovecot is linking records in  
cache file. For example if you start with an empty cache:

1 fetch 1:* internaldate

writes the first records to cache file and writes indexes to them in  
dovecot.index. The next command:

2 fetch 1:* rfc822.size

does the same, except it also needs to link the old and new cache  
records together by writing those 4 bytes to each message.

But .. Yes, I suppose it should be possible to change it to just  
write links to the old records directly while writing the new  
records. :) Although it doesn't work well always. The current code  
handles properly the case when those 1 and 2 commands are done  
simultaneously by different processes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20071111/de750fbb/attachment.bin