I've been doing some stress testing in the last few days and fixing all the errors I saw. I'm hoping that I've finally really fixed all the index/mbox problems. So, again I think the only thing left for v1.0 is the documentation. Please test this nightly snapshot before I'll release rc27 tomorrow: http://dovecot.org/nightly/dovecot-latest.tar.gz If you've seen any of the following error messages in log files, these should all be fixed now: - index: Append with UID 56297, but next_uid = 56298 - mbox: UID inserted in the middle of mailbox /home/tss/mail/inbox (45769 > 45768, seq=28, idx_msgs=30) - mbox: Expunged message reappeared in mailbox /home/tss/mail/inbox (UID 86957 < 86958, seq=28, idx_msgs=27) These should be fixed for most cases, but they can still rarely happen: - index: Extension reset without intro prefix There's a really tiny possibility of it still happening with mmap_disable=no, but I think it's practically fixed now. A proper fix would require more changes than I want to do for v1.0 (either support for marking transaction start/end positions or getting rid of the stupid intro prefix completely). - Cached message offset 38340 is invalid for mbox file /home/tss/mail/inbox This should happen only if you're using in-memory indexes or mbox_min_index_size isn't 0. This happens if the mbox file's timestamp and file size are the exact same after some expunges+appends, so the only way to properly fix it would be to wait a second and update the mtime before unlocking the mbox file after expunges. This sleep is actually already done when Dovecot notices that a) mtime and size really are the same after modification and b) mails have been moved around inside the file (ie. flag changes were done but there weren't enough empty space in the mail's own headers so mails had to be moved to get the needed space). Should be pretty rare. Anyway, this error is completely invisible to users and it doesn't have any other side effects that mbox_dirty_syncs doesn't already have. The whole error message could even be removed if it's going to become a problem.. Other changes in the snapshot: + mail-log plugin: Log the mailbox name, except if it's INBOX + dovecot-auth: Added a lot more debug logging passdbs and userdbs + dovecot-auth: Added %c variable which expands to "secured" with SSL/TLS/localhost. + dovecot-auth: Added %m variable which expands to auth mechanism name - Wrong endianess index files still weren't silently rebuilt - IMAP quota plugin: GETQUOTAROOT returned the mailbox name wrong the namespace had a prefix or if its separator was non-default -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070310/20497d4c/attachment.bin>
On Sat, 2007-03-10 at 21:45 +0200, Timo Sirainen wrote:> I've been doing some stress testing in the last few days and fixing all > the errors I saw. I'm hoping that I've finally really fixed all the > index/mbox problems.Promising. After running a bit less than 9 hours, zero errors with ext3 +maildir and 10 concurrent imaptest clients: Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo 3430404 1716719 1715506 3430403 3430401 4898510 1715205 1114566 3430394 1280678 6860566 There's something wrong with the logout numbers though since there are twice as many as logins :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070311/43c17666/attachment.bin>
Timo Sirainen wrote:> > Promising. After running a bit less than 9 hours, zero errors with ext3 > +maildir and 10 concurrent imaptest clients:I think dP alluded to this question earlier but I'm not sure if I see a response -- the default setting for login procs is: #login_process_per_connection = yes ...with all the notes about security ans so forth. The question is though what's a best recommended practice for efficiency and speed? What I'm wondering is that most clients like ThunderBird spawns multiple threads, which cause multiple logins. Typically 3-5 per user on TBird. So would it be correct to say that 50 people logged in at once would have ~150 login-auth procs running in order to get work done? At what point is a small tradeoff in security worth the recovery of CPU and process space? If one login proc is already running for the first thread 'user=tengel', do the subsequent threads re-use that same proc instead of launching another? Right now with min=3 and only myself logged in, I see 6 imap-login procs on the stack, and I'm worried that we'll start overloading the system. Thanks for any input -- just looking at how to best optimize here. -te -- Troy Engel | Systems Engineer Fluid Inc. | http://www.fluid.com
Timo Sirainen wrote:> I've been doing some stress testing in the last few days and fixing all > the errors I saw. I'm hoping that I've finally really fixed all the > index/mbox problems. So, again I think the only thing left for v1.0 is > the documentation. Please test this nightly snapshot before I'll release > rc27 tomorrow:I'm getting crashes from dovecot-auth every time #0 0xff0cf600 in ?? () (gdb) bt #0 0xff0cf600 in ?? () #1 0x1ec4c in get_uid (user=0x5bc08 "/opt/RDGdovect/etc/dovecot-ldap.conf") at main.c:75 #2 0x246e8 in checkpassword_request_half_finish (request=0x5bc30) at passdb-checkpassword.c:99 #3 0x2328c in passdb_blocking_lookup_credentials (request=0x0) at passdb-blocking.c:158 #4 0x17648 in auth_cache_parse_key (pool=0x5b838, query=0x51000 "") at auth-cache.c:44 #5 0x1ff0c in mech_cram_md5_auth_initial (auth_request=0x59fa8, data=0x51400 "", data_size=0) at mech-cram-md5.c:166 #6 0x2024c in verify_credentials (request=0x0, credentials=0xffbefb54 "???X") at mech-digest-md5.c:180 The really odd thing is that I'm not using LDAP this time (the authentication section for this is commented out and doesn't show up in "dovecot -n"). Chris P.S. I compiled imaptest10.c OK, but can't use it because of this! -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin at reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
On Sat, 2007-03-10 at 21:45 +0200, Timo Sirainen wrote:> I've been doing some stress testing in the last few days and fixing all > the errors I saw. I'm hoping that I've finally really fixed all the > index/mbox problems. So, again I think the only thing left for v1.0 is > the documentation. Please test this nightly snapshot before I'll release > rc27 tomorrow:I'm worried about the PAM crash that Chris reported, so I won't release rc27 before that's solved.> http://dovecot.org/nightly/dovecot-latest.tar.gzI updated this snapshot again. Changes since yesterday: - I added fsync_disable setting after all. It gives 20% better performance with some of my tests, and maybe even better with a lot of users. - mbox and index files should work now perfectly in out-of-quota conditions. - If some people were still having problems with Dovecot hanging, that could have been caused by sendfile() call being used when mail had CR+LF linefeeds. If the sendfile() didn't send the whole mail, Dovecot hanged. I just also had an idea how filesystem quota could be handled with maildir, as long as only Dovecot is used to add new files to maildir. Currently saving is done in this order: 1. write mails to tmp/ 2. lock dovecot-uidlist file 3. rename() mails from tmp/ to new/ 4. write the new dovecot-uidlist's contents to dovecot-uidlist.lock 5. rename() dovecot-uidlist.lock to dovecot-uidlist If I switched 3 and 4, there are only rename()s that can fail. And at least my Linux allows rename()ing when there's no disk space left. I hope that's the case for "out of quota" conditions too? Or does it create a new directory entry which can in some situations cause a new disk block allocation which will fail?.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070311/b6b6ed9a/attachment.bin>