Timo Sirainen skrev:
> On Thu, 2009-10-15 at 10:55 +0200, Mikkel wrote:
>> Some users would have mailboxes a several hundred megabytes and having
>> to recreate thousands of these every night because of a single mail
>> getting expunged a day could result in a huge performance hit.
>
> It doesn't matter what the user's full mailbox size is. It matters how
> many of these max. ~2 MB dbox files have expunged messages. Typically
> users would expunge only new mails, so typically there would be only a
> single file that needs to be recreated.
>
That way it seems pretty clever. But if the number of messages in each
mdbox file (we are talking about multi-dox and not single-dbox right?)
is configurable via mdbox_rotate_size (ranging from 1 to infinity I
guess) then how can you assume that each file is no more than ~2 MB?
>> dovecot: Oct 01 15:13:57 Error: IMAP(another_acco...@domain):
Corrupted
>> transaction log file /local/another_homedir/Maildir/dovecot.index.log
>> seq 229: duplicate transaction log sequence (229) (sync_offset=32860)
>
> Hmm. This means that Dovecot thought that dovecot.index.log file was
> rotated, but when it reopened it it actually had the same sequence
> number in the header. What NFS server are you using? One possible reason
> for this is if file's inode number suddenly changes.
I'm using a NAS appliance (Sun S7410) that is basically just a modified
Solaris 10 NFS server on x86 hardware (AMD).
The system has had some stability issues and therefore it's difficult to
tell whether that specific error happened during normal operation or if
it's just a special case.
The client also runs Solaris 10 but this is the Sparc version.
Solaris uses NFSv4 as default (and I haven't changed this).
Anyway do you think that dovecot would be able to recover from that kind
of error without loss of information if dbox/mdbox where used instead of
Maildir?
Regards, Mikkel
