On 09/09/2012 23:30, Daniel Parthey wrote:
Cibest ML wrote:
On 08/09/2012 01:38, Daniel Parthey wrote:
Cibest ML wrote:
We've a strange quota behavior on our dovecot servers. It seems that it's somehow doubling the real used storage (or could be something like twice the inbox size + size of other folders, hard to know for sure). It was initial setup with the maildir++ system. Now it's been configured with dict and mysql table but the result is the same. Here are some tests to show the problem. The test mailbox is initialy empty. All described actions are done in a sequencial way (test mail with an attachement of ~2MB)
- Message delivered by LMTP Quota name Type Value Limit User quota STORAGE 2653 524288 User quota MESSAGE 1 - Seems ok.
- quota recalc Quota name Type Value Limit User quota STORAGE 5307 524288 User quota MESSAGE 2 - Strange. There must be some issue with quota recalculation. Maybe there are two instances of the message in the maildir? How large is the actual maildir measured by diskusage (du) command and where are the messages stored in the filesystem?
- move to draft + compact Quota name Type Value Limit User quota STORAGE 2653 524288 User quota MESSAGE 1 - Seems absolutely correct. Message is copied, deleted and removed from the old directory.
- recalc Quota name Type Value Limit User quota STORAGE 2653 524288 User quota MESSAGE 1 - Seems after compacting the folders there is only one instance of the message.
- move to subfolder "test" in inbox User quota STORAGE 2653 524288 User quota MESSAGE 1 -
- move message back to inbox Quota name Type Value Limit User quota STORAGE 5306 524288 User quota MESSAGE 2 - The message gets copied and deleted, so there are 2 messages.
- compact Quota name Type Value Limit User quota STORAGE 2653 524288 User quota MESSAGE 1 - After compaction the "copied+deleted" message gets finally removed.
- recalc quota Quota name Type Value Limit User quota STORAGE 5306 524288 User quota MESSAGE 2 - Very strange. The removed message "reappeared"? Are you using some network filesystem and possibly experience filesystem caching effects? In this case a dovecot director would help.
Regards Daniel
The storage is indeed done via NFS. There might be some caching effects but in that case, the behaviour should occur for all the test cases. But it seems only to happen if the mails are stored in INBOX, not in a subfolder of INBOX nor another IMAP folder. We've never been able to reproduce the issue if the email is not exactly in INBOX. We've added some options to check if it's a NFS issue (but it shouldn't be needed as indexes aren't on a NFS filer) : map_disable = yes mail_fsync = always mail_nfs_index = yes It doesn't change anything, same behavior.
Here are some test cases to show that there's always 1 mail stored on the filesystem
new incoming mail
du -> 8 ls -> -rw------- 1 vmail vmail 3748 Sep 10 16:11 1347286291.M194531P4329.mspooll01,S=3748,W=3847
quota get
Quota name Type Value Limit User quota STORAGE 3 524288 User quota MESSAGE 1 -
du -> 8 ls -> -rw------- 1 vmail vmail 3748 Sep 10 16:11 1347286291.M194531P4329.mspooll01,S=3748,W=3847
quota recacl
Quota name Type Value Limit User quota STORAGE 7 524288 User quota MESSAGE 2 -
du -> 8 ls -> -rw------- 1 vmail vmail 3748 Sep 10 16:11 1347286291.M194531P4329.mspooll01,S=3748,W=3847
it really seems to be connected to the recalc operation.
Moving to dovecot director would require some work but at the moment, we can't be sure it'd solve the issue (as we only have one IMAP/POP server
- one LMTP server, we shouldn't have issues with stickiness of connexions)
-- Regards Sébastien