On Fri, 2008-02-22 at 11:52 +0100, mikkel@euro123.dk wrote:
The way this happens it seems to me that it's not just a random NFS locking error but actually a bug somewhere and that some users manage to always trigger the bug (which seems to be triggered sometimes when pop3 is used) while others do not. But it's pretty difficult to get close to the cause.
Does Dovecot actually check whether updating the maildirsize is successful or not after calling the operations (e.g. what happens if the code is unable to read from or write to maildirsize)?
maildirsize updating works by just appending a value in it. This isn't entirely NFS safe and Dovecot doesn't bother verifying that two processes didn't write to it at the same time overwriting each others. Perhaps it should and if it detects that it would rebuild the file.
But this shouldn't normally be a problem. If a user is over quota and either
a) maildirsize file contains more than just the summary line b) the file is older than 15 minutes
The maildirsize gets recalculated. So even if Dovecot completely screws up updating the maildirsize file, users shouldn't see "quota exceeded" errors unless the recalculation is also broken.
Is anything else than Dovecot delivering mails to the maildir?