Re: [Dovecot] dbox redesign
I would add that having fewer, larger files should make backups much more feasible. There's a certain amount of overhead for each file operation (especially for us GFS people!) and reducing the number of files will reduce that overhead. Right now our backups (done via rsync) take a pretty scary amount of time, only to get worse as the size of the mailstore (currently 200G) grows. Personally I'm pretty excited about dbox. Allen Timo Sirainen wrote: On Wed, 2009-02-11 at 14:32 -0800, Seth Mattinen wrote: Timo Sirainen wrote: This is about how to implement multiple msgs/file dbox format. The current v1.1's one msg/file design would stay pretty much the same and it would be compatible with this new design. Out of curiosity, what's the advantage to going to multiple messages per file? Wouldn't this have the same problems as mbox? Multiple per file, not everything in one file. As long as the file size is set right, it's probably faster than one per file. We'll see :) -- Allen Belletti al...@isye.gatech.edu 404-894-6221 Phone Industrial and Systems Engineering404-385-2988 Fax Georgia Institute of Technology
[Dovecot] Occasional messages cause Thunderbird to loop
For the last four weeks or so, I have been getting very occasional reports of stuck messages from three users of my mail server. When this occurs, Thunderbird's status display in the bottom left will alternate rapidly between Opening folder and Checking mail server capabilities, and will never display the message. I'm not sure if this is something which crept into a recent release of Dovecot, or a problem with T'bird, or something else entirely. I had suspected corrupt messages the first time or two, and was once able to copy such a message into my own Maildir/cur directory and have it fail for me. Since then I've not been able to replicate this feat. I also thought that it might have been the Dovecot indices becoming corrupt but today I tried purging them for an affected user, and the problem still showed up. In addition, for the first time today that user reported a message which originally (as of 6 Nov. 2008) worked fine but today demonstrates the issue. If anyone has seen anything like this or has suggestions to try, please let me know. If necessary I can go to full debug-logging with Dovecot but I'd prefer to avoid that if possible :) Thanks, Allen -- Allen Belletti [EMAIL PROTECTED] 404-894-6221 Phone Industrial and Systems Engineering404-385-2988 Fax Georgia Institute of Technology
Re: [Dovecot] Backing Up
I'd like to add my vote here as well; dbox would be *the* feature that would make me happy. I'm the guy who asked a few weeks ago about ways to speed access on our GFS clustered mail environment. Meanwhile, I've done some preliminary testing with mbox. As expected, it's vastly faster than the Maildirs that we're using now. Of course it pains me to go backwards but that may be the interim solution. I got stopped temporarily when it seemed that I couldn't nest folders using mbox, but hopefully that's untrue. Allen [EMAIL PROTECTED] wrote: Timo Sirainen: One possibility is to just wait for dbox with multiple-messages-per-file feature. I can't really say when it'll be ready (or when I'll even start implementing it), but I know I want to use it myself and some companies have also recently been asking about it. Have you considered making dbox a major priority for v. 1.2? I have been holding back on v.1.2 because I don’t really see the big improvements in it that I saw in v.1.0 and v.1.1. With 1.0 and 1.1 I hurried off using them in production environments even while they where still in beta (of course only after proper testing) because they posed so many advantages (primarily speed and stability) over other solutions. Since I’m focused almost entirely on stability and speed, and very little on fancy functionality, what v.1.0 offers in terms of functionality is just fine. What drove me towards 1.1 were speed improvements (and stability on NFS). I remember you made a post about not many people testing v.1.2. I think the reason may be that most users feel the same as me. They’d like to se a major feature that benefits their primary needs, which isn’t in term of functionality but more in term of speed improvements. Dbox could be that feature as I think there isn’t much room for further developing the Maildir format (and as far as I can see you have gone as far as possible with regards to optimizing speed while working within the boundaries of the Maildir standard). Maildir is nice compared to mbox but it really isn’t optimal. In days where IOPS is the most difficult resource to get into your server (and dovecot already using close to nothing in terms of CPU time and memory) having one file per e-mail is less than sub-optimal especially when a large amount of users just downloads the whole mailbox using POP3 (not to mention backing up Maildirs). Now don't take this as a critic, I love your software. I just would really like to se dbox evolve and think it would be a major driving force for v.1.2 :) Develop dbox, Do it. Do it naoughw! (preferably pronounced with a schwarzeneggerish accent like in the last three seconds of this splendid video http://www.youtube.com/watch?v=adc3MSS5Ydc). Best regards, Mikkel -- Allen Belletti [EMAIL PROTECTED] 404-894-6221 Phone Industrial and Systems Engineering404-385-2988 Fax Georgia Institute of Technology
[Dovecot] Dovecot performance on GFS clustered filesystem
Hello All, We are using Dovecot 1.1.3 to serve IMAP on a pair of clustered Postfix servers which share a fiber array via the GFS clustered filesystem. This all works very well for the most part, with the exception that certain operations are so inefficient on GFS that they generate significant I/O load and hurt performance. We are using the Maildir format on disk. We're also using Dovecot's deliver from Postfix to handle local delivery. As best I can determine, the worst problems occur when certain users with very large Inboxes (~10k messages) receive new mail and their client looks up information about that message. GFS doesn't seem to efficiently handle the large directories that contain folders like this. As a result, lots of I/O ops are generated and performance suffers for everyone. I am beginning to wonder if it might be more efficient to revert to the old mbox format, with one file per folder (plus whatever indices are creates.) It seems that this ought to work better with GFS which is geared toward smaller numbers of larger files. Is anyone on the list currently doing that? Alternately, any thoughts regarding tuning or other options would be appreciated. Thanks, Allen -- Allen Belletti [EMAIL PROTECTED] 404-894-6221 Phone Industrial and Systems Engineering404-385-2988 Fax Georgia Institute of Technology
Re: [Dovecot] Possible bug involving LDA and Namespaces
Hi Timo,
This is with version 1.1.3. Unfortunately I hadn't gotten around to
trying deliver until very recently, so I don't have any results from
prior versions.
Thanks,
Allen
Timo Sirainen wrote:
On Fri, 2008-09-19 at 10:52 -0400, Allen Belletti wrote:
namespace private {
list = no
separator = /
prefix = INBOX/
inbox = no
hidden = yes
}
Nonetheless, when deliver starts up it believes that both namespaces
have list = yes.
What Dovecot version? Seems to work with me.
--
Allen Belletti
[EMAIL PROTECTED] 404-894-6221 Phone
Industrial and Systems Engineering404-385-2988 Fax
Georgia Institute of Technology
