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.