[Dovecot] 1.0-test CVS HEAD index problems
Running current CVS HEAD I get:
dovecot: Dec 01 13:27:38 Info: Dovecot v1.0-test52 starting up dovecot: Dec 01 13:33:34 Info: imap-login: Login: jtl [69.162.177.245] dovecot: Dec 01 13:41:07 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:41:07 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:42:39 Info: imap-login: Login: jtl [69.x.x.x] dovecot: Dec 01 13:42:39 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:42:39 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:43:59 Info: imap-login: Login: jtl [69.x.x.x] dovecot: Dec 01 13:43:59 Error: IMAP(jtl): Corrupted index cache file /users/j/t/jtl/.i map/INBOX/dovecot.index.cache: indexid changed dovecot: Dec 01 13:47:24 Error: IMAP(jtl): file mbox-lock.c: line 493 (mbox_lock): asse rtion failed: (lock_type == F_RDLCK || ibox->mbox_lock_type != F_RDLCK) dovecot: Dec 01 13:47:25 Error: child 17528 (imap) killed with signal 6 dovecot: Dec 01 13:47:41 Info: imap-login: Login: jtl [69.x.x.x] dovecot: Dec 01 13:50:49 Error: IMAP(jtl): UIDVALIDITY changed (1101926435 -> 110192703 6) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:55:27 Info: imap-login: Login: jtl [69.x.x.x] dovecot: Dec 01 13:55:27 Error: IMAP(jtl): UIDVALIDITY changed (1101926435 -> 110192703 6) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:56:15 Info: imap-login: Login: jtl [69.x.x.x] dovecot: Dec 01 13:56:15 Error: IMAP(jtl): UIDVALIDITY changed (1101926435 -> 110192703 6) in mbox file /var/spool/mail/j/t/jtl
Using Thunderbird-0.9. Dovecot is running on RHEL 3, on top of Redhat/Sistina GFS (clustered filesystem.) Currently I'm keeping it on one node to avoid possible GFS locking issues. I'm running with mmap_disabled=yes, mbox format. Most of the 1.0-test builds I have done eventually corrupt their index files, and show strange behavior (click on a message in the folder view, and an entirely different message opens... delete three or four messages and expunge, the messages instantly reappear as unseen.). I typically wipe the .imap directories between different builds of Dovecot.
I've been following the -test code for a couple of months now, just to see how it does, because we're running UW IMAPd and are excited to have a way to increase the performance of our mail cluster (indexes) without having to move away from mbox.
Let me know if there's more information I could provide that would be helpful.
Jim
Jim Lawson wrote:
Using Thunderbird-0.9. Dovecot is running on RHEL 3, on top of Redhat/Sistina GFS (clustered filesystem.) Currently I'm keeping it on one node to avoid possible GFS locking issues.
Your error messages are file system locking problems in any case, what locking method are you using?
For me following locking config works fine with Polyserve clustered file system, don't know about GFS though..
lock_method = flock mbox_read_locks = flock mbox_write_locks = flock
I've been following the -test code for a couple of months now, just to see how it does, because we're running UW IMAPd and are excited to have a way to increase the performance of our mail cluster (indexes) without having to move away from mbox.
A small tip, put your indexes on separate LUN and preferably on seperate disks than your mail spool, and since indexes are written heavily non parity RAID like 1 or 10 is much better than RAID-5.
-- Tomi Hakala
Tomi Hakala wrote:
Jim Lawson wrote:
Using Thunderbird-0.9. Dovecot is running on RHEL 3, on top of Redhat/Sistina GFS (clustered filesystem.) Currently I'm keeping it on one node to avoid possible GFS locking issues.
Your error messages are file system locking problems in any case, what locking method are you using?
All of them appear locking-related, or just the assertion failure?
For me following locking config works fine with Polyserve clustered file system, don't know about GFS though..
lock_method = flock mbox_read_locks = flock mbox_write_locks = flock
Same configuration here. We use flock with UW IMAPd (no dotlocks) and procmail, and it seems to work fine. We could use fcntl, but it has more overhead. Glad to meet someone using Polyserve. Can you tell me more about your cluster? Is it just for mail access? How many nodes? How many users?
A small tip, put your indexes on separate LUN and preferably on seperate disks than your mail spool, and since indexes are written heavily non parity RAID like 1 or 10 is much better than RAID-5.
All the mail is stored on RAID-10, mailboxes and indexes. Splitting up the spindles might help somewhat, but having them together shouldn't cause problems like this, right?
Jim
Jim Lawson wrote:
All of them appear locking-related, or just the assertion failure?
My best guess is that all problems are result of locking problem.
Same configuration here. We use flock with UW IMAPd (no dotlocks) and procmail, and it seems to work fine.
Maybe there is some issues with flock on GFS, have you tried dotlocking with Dovecot?
Glad to meet someone using Polyserve. Can you tell me more about your cluster? Is it just for mail access? How many nodes? How many users?
For now it's just a small lab setup with two RHEL 3 nodes, no real users.
All the mail is stored on RAID-10, mailboxes and indexes. Splitting up the spindles might help somewhat, but having them together shouldn't cause problems like this, right?
No, it's just for a performance.
-- Tomi Hakala
On 1.12.2004, at 23:14, Jim Lawson wrote:
dovecot: Dec 01 13:41:07 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl dovecot: Dec 01 13:41:07 Error: IMAP(jtl): UIDVALIDITY changed (1100294646 -> 110192643 5) in mbox file /var/spool/mail/j/t/jtl ..
If these were all done by same session it's a Dovecot problem because it doesn't notice that index is supposed to be rebuilt. I fixed this now in CVS.
dovecot: Dec 01 13:47:24 Error: IMAP(jtl): file mbox-lock.c: line 493 (mbox_lock): asse rtion failed: (lock_type == F_RDLCK || ibox->mbox_lock_type != F_RDLCK)
There are at least two ways to make this happen. One is copying a mail into same mailbox, and the second one is something I haven't yet figured out. I don't see it happening often though.
dovecot: Dec 01 13:50:49 Error: IMAP(jtl): UIDVALIDITY changed (1101926435 -> 110192703 6) in mbox file /var/spool/mail/j/t/jtl
A bit strange that it keeps on doing that even with new sessions. Shouldn't happen unless for some reason it's not updating index files at all (or if reading doesn't notice the changes).
Using Thunderbird-0.9. Dovecot is running on RHEL 3, on top of Redhat/Sistina GFS (clustered filesystem.) Currently I'm keeping it on one node to avoid possible GFS locking issues. I'm running with mmap_disabled=yes, mbox format. Most of the 1.0-test builds I have done eventually corrupt their index files, and show strange behavior (click on a message in the folder view, and an entirely different message opens... delete three or four messages and expunge, the messages instantly reappear as unseen.). I typically wipe the .imap directories between different builds of Dovecot.
Have you tried moving indexes to local disk to see if it works better? I haven't seen much problems anymore with indexes even with mmap_disable=yes. There still are some bugs but I don't think anything should break in normal use.
participants (3)
-
Jim Lawson
-
Timo Sirainen
-
Tomi Hakala