<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">> You have got to be kidding me. Unless there's actually something which<br>
> requires the files to be rewritten (i.e. an expunge event) then this<br>> should not happen. Again, Cyrus 2.4.x will be much more efficient in<br>
> this regard, only rewriting if you have explicitly enable immediate<br>
> expunge rather than "default" expunge.<br></blockquote><div>It is a 2.3.16. Tu be sure I have tested again with a fresh downloaded tarball. Just sending a mail in LMTP and opening the mailbox several times (SELECT/CLOSE only)<br>
A binary diff indicated that Generation Number is incremented but nothing else. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
>> With a 6GB's mailbox that contains almost 100.000 emails. cyrus.index is<br>
>> about 8MB and cyrus.cache is about 120MB<br>
>> - on SELECT nfsstat shows 300 NFS READ => 9600KB on-the-wire NFS READ. OK it<br>
>> is less that the size of cyrus.index and cyrus.cache<br>
>> - on CLOSE nfsstat shows 4105 NFS READ and 4144 NFS WRITE => 2x130MB<br>
>> on-the-wire NFS.<br>
>><br>
>> In such situation mmap doesn't help because everything is read and write. I<br>
>> hope this behaviour can be optimized.<br>
<br>
</div>> So don't use NFS.<br></blockquote><div>NFS is not a problem here. I have flushed the buffered cache to see what's happen. Most of the time files are cached by the kernel. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br></blockquote></div>