On Feb 27, 2008, at 8:49 AM, Andy Dills wrote:
From reading the docs, it appears I would not be able to use the
dovecot LDA due to locking issues (bummer), and I should configure dovecot to store index files on a local disk of the primary pop/imap server
rather than on the netapp.
I don't think locking is an issue. NFS caching is more problematic.
But with v1.1's mail_nfs_*=yes settings there should be no problems
with storing indexes on NFS.
My first question would be, how much of a performance hit should I
expect from having to update the indexes when mail is checked rather then
when mail is delivered since I can't use the LDA? Is this a minor issue
like I expect, or can it be something the user actually notices when checking mail?
It's a minor issue usually.
In a worst case scenario, if the pop/imap server is down, and another server is used, how long would it take to create an index for an
account with a few hundered megs, several thousand messages? I'm wondering if, since I have plenty of overhead available on the netapp, I should just store the indexes there in case another server must be used.
The actual index file creation is really fast. More problematic is
losing dovecot.index.cache file for clients that want to fetch/search
old data. But Courier/Binc did no caching at all, so Dovecot wouldn't
be any worse.
First off, I can't seem to find any info on a way to create an initial index file for all of the mailboxes. Can anybody suggest a command I
can use for this? I'm sure I just overlooked it.
I don't think you should worry about it. Like I said, the
dovecot.index.cache file generation is the slow part. But since its
generation depends entire on what fields client is using, you can't
really pregenerate it properly anyway. http://wiki.dovecot.org/IndexFiles
tries to describe this. http://imapwiki.org/Benchmarking might have
more understandable explanation as well.
Fortunately, courier is used for normal imap on 143, bincimap is
only used for webmail. So, it would seem that metadata from bincimap could be ignored; the only thing it would seem important to preserve is mailbox subscriptions. Please correct this assumption if I'm wrong.
Right.
So, it seems like my best option is to modify the courier-dovecot-migrate.pl script to consider the mailboxes
subscribed to via bincimap. Here's a modified convert_subscriptions that seems to
work well in limited testing, feel free to point out any idiot mistakes,
it's been a while since I've done anything substantial in perl.
I'm not that great perl coder either. :)