[Dovecot] 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.
participants (2)
-
Paolo Miotto
-
Timo Sirainen