[Dovecot] Moving index files on another disk: no troubles but need more assurances

Timo Sirainen tss at iki.fi
Mon Feb 11 03:26:05 EET 2013


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.





More information about the dovecot mailing list