[Dovecot] 1.0.rc10 status report

[Timo Sirainen]

On Fri, 2006-10-20 at 13:26 +0100, David Lee wrote:
> 1. "User unknown":  We use NIS for our passwd information.  On the earlier
> rc8 test we had had several occurences of "User unknown" (from "deliver")
> giving "dsn=5..." for perfectly valid users.  So for this rc10 test I
> applied a local patch so these were reduced to "EX_TEMPFAIL" (dsn=4...).
> (This was triggered, as epected, a few times and subsequent delivery
> attemtps succeeded.)  I strongly suspect that this is some sort of issue
> with FC5, probably "nscd" and nothing to do with dovecot.  Hints would be
> nice, but from the dovecot perspective you may probably ignore this item.

Yea. Dovecot only does a getpwent() call which can't really be used
wrong.

> 2. For one particular user, the "deliver" consistently gave:
>       Failed to create storage for '...' with mail 'mbox:/HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB:INBOX=...
> 
> I think this is ultimately due to something strange in the user ".forward"
> file.  I'd be delighted to follow this up with anyone else who might have
> seen it.  Although in one sense we may be drifting off-topic, in another
> sense I suspect that there is scope for adjusting "deliver" to handle this
> more gracefully.

Is deliver executed from .forward file? In that case the HOME
environment isn't set and deliver doesn't assume that it's going to
deliver to the current local user, so it's not looking up the home
directory by itself..

> 3. There were several occurences of:
>       IMAP(...): file ../../../../../src/lib-storage/index/mbox/mbox-sync-rewrite.c: line 405 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space)
>       child 30842 (imap) killed with signal 6
> 
> This looks particularly awkward.  Any thoughts?

In case you missed, this fixes it:
http://dovecot.org/patches/1.0/dovecot-1.0.rc10-mbox-keywords-fix.patch

> 
> 4. There were two occurences of:
>       IMAP(...): file ../../../src/lib-index/mail-index.c: line 1801 (mail_index_move_to_memory): assertion failed: (index->fd == -1)
>       child 20493 (imap) killed with signal 6
> 
> Again, this looks particularly awkward.  Any thoughts?

The moving to memory code isn't perfect, but normally it shouldn't even
be done. I think there are only two reasons:

1) Filesystem quota / out of disk space in general

2) mbox_min_index_size


> For these last two items, note that the indexes are currently NFS-shared
> alongside the INBOX area.
> 
> I'm still not clear on how to regard the concept of indexes, as applied to
> a small cluster of machines, and handling simultaneous updates to INBOXes
> (analogous to the vital importance of INBOX locking for such updates).
> 
> If one imagines the IMAP daemon (and pop and deliver) as file-clients of
> the (NFS-shared) INBOXes on a fileserver, do the indexes belong very close
> to the INBOXes (fileserver) or the dovecot software (file client)?  So
> should I have the indexes on the fileserver (one instance), or should they
> be on each cluster machine's private storage (possibly several instances;
> one per cluster machine)?  I've got them on the server; would they be
> better on the cluster clients?  (Might that be the cause and fix of these
> two problems?)

Indexes contain metadata of the mailboxes, so if you're using multiple
different computers to read/write to the same user's mailbox, then it's
better to keep them in NFS.

If you can make only a single computer access the same user's mailbox
most of the time then it's probably faster to keep them in local disk.
Otherwise if you kept them in local disk in different computers you'd
waste time in synchronizing the indexes separately for each computer
that accesses the mailbox.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20061102/5294f894/attachment.pgp