can we paypal you some money? It would be personal, not commercial and consequently not that much, but everything helps.......

Timo Sirainen wrote:

You can probably guess from my flood of mails that I'm no longer busy. I still have a couple of exams but since I haven't spent any time at all studying for them or attending the lectures, I can just as easily leave them for next year.

I've read and answered most of the "easy" mails in this list and in my INBOX. I'll try to answer the rest of them this weekend, so no need to forward them to me again, at least not yet. :)

Now that I'm finally non-busy, it also appears that I haven't worked for a long time and I'm almost broke. :) So now would be a great time for your corporation to buy/sponsor some Dovecot development. Otherwise I'm probably soon busy with non-Dovecot related work.

My own high priority TODO contains:

• Get the rewritten Squat full text search index working. It probably needs a name change, since it's not all that close to Cyrus Squat anymore. Suggestions? Could of course be just "fts_dovecot".
• Shared mailboxes / ACLs
• dbox cleanups and possibly partial redesign. I'll write a separate mail about this later.
• Index file code cleanups, simplifications and optimizations. Make it work with NFS with attribute cache enabled.

--

Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504
sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035

On Fri, 2007-05-11 at 19:41 +0300, Timo Sirainen wrote:

• Index file code cleanups, simplifications and optimizations. Make it work with NFS with attribute cache enabled.

Better explanation of this for those who are interested:

Currently mmap_disable=yes is faster (but takes more memory) than mmap_disable=no, although it really should be the other way. I think this isn't really because of mmaping but because of other differences between how they work. So one of the main goals would be to get them to use most of the same code paths so mmap_disable=no would be faster again.

Another thing I intended to do was make it use less locks. Currently it's locking files much more often than is necessary. Transaction log could also use O_APPEND instead of locks. These are explained in http://dovecot.org/list/dovecot/2007-April/021640.html Less locking means that index handling becomes slightly faster and throughput higher with shared mailboxes.

Simplifying the code also makes it easier to add NFS attribute cache workarounds, make error handling more reliable and index files in general more resistant against "corrupted index file" rebuilds (important for cydir and dbox mail storages).

And one final thing that I want to do is that Dovecot needs to be able to compare two index views. This is needed when a mailbox view is being synchronized. So the comparing happens between the "current view in memory" and "latest view in dovecot.index file". Currently the synchronization works only if Dovecot can read the changes from dovecot.index.log file. If the client has been idling for a really long time and a lot of changes have happened in the mailbox, the log file might have been deleted already, which causes "Out of sync" error and Dovecot disconnects the client. Even if the log was found, it still could be a lot faster to compare two small views than read huge log files.

On Fri, May 11, 2007 at 07:41:53PM +0300, Timo Sirainen wrote:

• Get the rewritten Squat full text search index working. It probably needs a name change, since it's not all that close to Cyrus Squat anymore. Suggestions? Could of course be just "fts_dovecot".

"squatimo" ? (or squatmo)

Mr. Marcus's "dovesquat" was pretty good.

mm