[Dovecot] Quota handling on NFS Maildir

[mikkel at euro123.dk]

> On Feb 22, 2008, at 11:26 AM, mikkel at euro123.dk wrote:
> Do you mean that you can see a situation with QUIT or EXPUNGE command
> when maildir's contents don't match maildirsize file? Or if you mean
> only setting the deleted flags, that's normal then because nothing
> really gets deleted yet anyway.

The delay wasn't long enough for me to physically test if the quota was
our of sync meanwhile.
My estimate is 5-10 seconds and it could be the system waiting for I/O or
something. I just figured that maybe this was due to grouping of the
transactions and thought that if so, then maybe it was possible that this
code could fail in some situations.

>> This may be the cause of the issue since some users in a production
>> environment will always break the connection (loss of internet
>> connectivity, the client program crashing or just generally badly
>> behaving
>> e-mail clients).
>
> For POP3 maybe, but they'd probably get duplicate messages downloaded
> then too, unless the client is smart with UIDLs.

I can see your point. If your coding does'n not allow for situations where
dovecot gets interrupted in between doing the actual delete and update the
maildirsize then I have no idea what happens.
I just figured that maybe there was a week spot somewhere that could break
in certain situations (like NFS locking troubles or something) :)

> With IMAP could it be just that users have marked messages deleted and
> their client hides them, but the messages are never expunged? Or that
> the messages have been moved to Trash mailbox..

When I "du" the user's storage I can see that there is a lot less data
than maildirsize claims (so this isn't due to hidden mails or mails in
Trash).

Apparently the large majority of users have no problems whatsoever while e
few specific users experience this every two weeks on average (when they
finally reach the upper quota limit and report the error).
The solution for now is to remove the file maildirsize so the quota will
be recounted.

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)?


Regards, Mikkel