[Dovecot] Plan/Status of MBX support?
Hi, All,
I've been happy user of dovocot as far. It is easy to configure, reliable and secure. Hat off to all developers who make this possible!
I know dovecot is on the mailbox format front, it supports both mbox and maildir format well, and is developing and experimenting a new flexible format, dbox.
But is there any plan to add mbx (i.e., indexed mbox format) support, to complete the set?
There is some circumstance that mbox format is chosen over the mordern maildir format, For example in our situation, we receive many, many small messages and it would be expensive to create so many files with maildir. And we do a lot of searching - again a single mbox is faster in searching.
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly. Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
If dovecot support index mbox format, we be in the havean! But is there a plan to add this support in the near future?
Thanks,
JY
On Sat, 2006-04-22 at 15:42 +0100, Jiaying Xu wrote:
I know dovecot is on the mailbox format front, it supports both mbox and maildir format well, and is developing and experimenting a new flexible format, dbox.
But is there any plan to add mbx (i.e., indexed mbox format) support, to complete the set?
Not by me at least. I don't really see a need for it other than helping conversion from UW-IMAP.
But is "indexed mbox format" really a proper name for mbx? It's in no way compatible with mbox format and I wouldn't even call it "indexed".
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly.
I'm not exactly sure why deleting messages with mbx is any less costly, because it works practically the same way as with mbox: moving all data after deleted data over the deleted data.
Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
dbox should work nicely for that situation. :) It doesn't lock files for reading, writing new mails don't block other writes and expunges should be pretty fast. It finally even seems to be working in latest CVS version, but I guess it still needs a bit more testing before I'd recommend using it..
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly. Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
sorry just have to ask - does your server actually WORK at loads of 500? What kind of usage have you got?
On 2006-04-25 12:37:31 +0100, Daniel Watts wrote:
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly. Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
sorry just have to ask - does your server actually WORK at loads of 500? What kind of usage have you got?
ever thought on maildir?
darix
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Marcus Rueckert wrote:
On 2006-04-25 12:37:31 +0100, Daniel Watts wrote:
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly. Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
sorry just have to ask - does your server actually WORK at loads of 500? What kind of usage have you got?
ever thought on maildir?
darix
OP said he has - and the reason he wants MBX support is to support writing and reading of LOTS of SMALL emails. maildir overhead from creation of new files for each email, allegedly, makes it less efficient than a single file MBX.
Daniel
On Tue, 2006-04-25 at 10:35, Daniel Watts wrote:
Now the problem is, we have to use the tranditional mbox format with dovecot, as it does not support indexed mbox format, which makes deleting messages costly. Also the long-time file locking (due to the slow operation on the dovecot side) causes our MTA (exim, by the way) holds a huge queue. That drives up the system load to mad (load average above 500 is not unusual in our case).
sorry just have to ask - does your server actually WORK at loads of 500? What kind of usage have you got?
ever thought on maildir?
OP said he has - and the reason he wants MBX support is to support writing and reading of LOTS of SMALL emails. maildir overhead from creation of new files for each email, allegedly, makes it less efficient than a single file MBX.
Unless, of course, you delete one of those small emails which with mbox format involves copying the entire remaining content into a temporary file and back or with mbox copying the subsequent messages backwards to close the hole. A filesystem that is efficient at file creation (reiserfs/xfs) probably makes more sense.
-- Les Mikesell lesmikesell@gmail.com
participants (5)
-
Daniel Watts
-
Jiaying Xu
-
Les Mikesell
-
Marcus Rueckert
-
Timo Sirainen