[Dovecot] Dovecot NFS Indexes and IMAP Migration

[Timo Sirainen]

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. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20080227/b76b1000/attachment.bin