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.. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20060424/7a975efe/attachment.bin>
> > 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?