On Mon, Jun 28, 2010 at 07:36:49PM -0400, Richard Pieri wrote: > On Jun 28, 2010, at 4:29 PM, Derek Martin wrote: > > > > All those extra system calls really add up for large mailboxes. > > So does having your connection to the server time out because the > header scan of a 7GB mbox file takes so long. But if it does indeed keep databases about its mail stores, there's no reason for that to be true. It can do any number of things, including maintain a header cache in its database (and I would imagine it probably does exactly that). In which case, the performance between the two should probably be about the same, given the same sized mail store. Even if it didn't, there are potentially other ways to prevent timeouts. > > Maildir also loses because on many filesystems, directories containing > > many files are inherently slow to deal with. > > Only if the IMAP server is stupid. You can make that argument about much of what you said too though, like the above, and like this: > You won't have to clean up the mess when the IMAP server barfs on a > fHuge file. Nor do you with mbox, unless the IMAP server is stupid. Barring hardware failure, the IMAP server barfing on a huge file should only ever happen if it's broken (i.e. stupid). Granted, the risk will always be technically higher with mbox. But in 20 years of using it, I've personally never had a problem, and in the, ah... 6 or so years I managed mail professionally, it occured only a handful of times. The major limitation here (assuming well-tested code) is that you could run out of disk space or create a file that's too large. Maildir has similar problems: You can run out of disk space, just like with mbox. You can also easily run out of inodes, which you aren't nearly as likely to do on mbox. You can also have enough messages in a directory to make doing anything in that directory painful, on filesystems not optimized for that case, which is a problem you're extremely unlikely to run into using mbox. Sure, disk corruption could wipe out your mbox mail store, but it can do that just as easily with maildir. Disk corruption is usually a result of either hardware failure or OS bugs, in which case all bets are off. And in either case, if you end up with corrupted mail stores, the solution is the same: restore from the last back-up, and lose some/all the mail you received since then. The only benefit maildir has here is you're likely to lose a little less mail when corruption does occur. Unless the disk is just plain dead. > You won't have to worry about them doing any housecleaning or what > happens when they don't. Sure you do. They can still fill up your filesystem, or use up all your inodes. > Your incremental and/or versioned backup sets of their data will be > smaller and run faster. This only matters IF you do backups at all -- this is for a home server, and most people don't bother to back up their home e-mail)... And, what if the user wants to use IMAP sometimes, and read mail locally other times? I've always done this since I started managing my own mail over a decade a go, and I know plenty of other folks who do too. Then you're back to the use case argument. Sometimes mbox is better, sometimes maildir is better. Maildir is fine, and does solve some problems that mbox has; but it's not the e-mail panacaea that the fanboys want it to be. Mbox still has its advantages too. If you're only ever going to access mail through your server, and it's well-implemented and not terribly broken, then it probably doesn't make any practical difference whether you use one or the other. Choose whichever one makes you feel better. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.