dovecot - Feb 2013 - Moving index files on another disk: no troubles but need more assurances

Hi,

I'm using dovecot 1.2.15 on debian squeeze with maildir, and I want to  
move index files out of the mailboxes disk to reduce disk I/O.

I need to get the assurance that the switch is completely transparent  
to my clients (IMAP and POP).

I read the wiki documentation and have found this thread  
(http://dovecot.org/pipermail/dovecot/2009-September/042665.html),  
which makes me confident, even if it speaks of a older version and  
only pop3.

So I set up a test server, copied a true mailbox and changed mail  
location from:
mail_location = maildir:~/Maildir
to
mail_location = maildir:~/Maildir:INDEX=/srv/indexes/%1n/%n
(all users under the same domain, no need to use %d).

On the IMAP side all seems to work fine, new indexes are created in  
the new location (dovecot.index.log on 1st access, dovecot.index.cache  
on message manipolation).

A test client (evolution) doesn't notice at all, and I have verified  
via a telnet imap session that UIDs don't change.

But I see that when I move the indexes the IMAP HIGHESTMODSEQ response  
changes and is reset to 1. Can this baffle the clients? On the rfc I  
don't found reference to this status walking backwards.

Need I to verify that all messages have the virtual size (W=nnnn) in  
the file name (the mailboxes are from a previous cyrus installation,  
then we switch to dovecot 1.2)?

What other test you suggest that checking UIDL on the pop3 side?

What happens if the indexes disk disappears (broken or removed from  
bay or all paths down for FC/iscsi)? Can dovecot 1.2 continue with  
INDEX=MEMORY as for a disk full?

Sorry for the many questions....

Paolo

----------------------------------------------------------------------
SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine

On Fri, 2013-02-08 at 13:17 +0100, Paolo Miotto wrote:
> So I set up a test server, copied a true mailbox and changed mail  
> location from:
> mail_location = maildir:~/Maildir
> to
> mail_location = maildir:~/Maildir:INDEX=/srv/indexes/%1n/%n
> (all users under the same domain, no need to use %d).
> 
> On the IMAP side all seems to work fine, new indexes are created in  
> the new location (dovecot.index.log on 1st access, dovecot.index.cache  
> on message manipolation).
> 
> A test client (evolution) doesn't notice at all, and I have verified  
> via a telnet imap session that UIDs don't change.
Your load probably temporarily increases so cache file gets filled.
> But I see that when I move the indexes the IMAP HIGHESTMODSEQ response  
> changes and is reset to 1. Can this baffle the clients? On the rfc I  
> don't found reference to this status walking backwards.
Hmm. Good question. I remember wondering about using some kind of a
timestamp-based root value. Something like time()*1000 would probably
work quite well, but this of course increases the size of all the modseq
values, which somewhat wastes bandwidth and also makes debugging a bit
more annoying :)

Thunderbird is probably the only widely used client that uses QRESYNC.
You could see if it breaks.
> Need I to verify that all messages have the virtual size (W=nnnn) in  
> the file name (the mailboxes are from a previous cyrus installation,  
> then we switch to dovecot 1.2)?
W=size or S=size aren't required in the filenames. Also if you change
them, make sure to change dovecot-uidlist also or the UIDs change.
> What other test you suggest that checking UIDL on the pop3 side?
POP3 session with UIDL command? :) Anyway POP3 UIDLs are never stored in
index files.
> What happens if the indexes disk disappears (broken or removed from  
> bay or all paths down for FC/iscsi)? Can dovecot 1.2 continue with  
> INDEX=MEMORY as for a disk full?
There is code to do something like that, but it might not work
perfectly. Especially with v1.2 that is rather old.