Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible iMAP server



On Jul 1, 2010, at 3:45 PM, Derek Martin wrote:
> 
> 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.

Nope.  Even with the database, header cache, whatever, manipulating multi-GB mbox files is *slow*, slow enough that it can cause the server or client to time out the connections.


> 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).

"Should" and "reality" often don't coincide, and I've seen users do some pretty brain-damaged things -- and had to clean up the messes afterwards.  mbox is a pain to fix by hand and that pain is compounded when having to deal with multi-GB files.  Similar explosions with Maildir -- when they happen -- are more files to fix but they're individually smaller, and then it's delete the cache and let the IMAP server rebuild it.  Sure, that takes time, too, but it isn't *my* time wasted doing it by hand.

Not saying that Maildir is the be-all, end-all.  Just saying that it is by far the lesser of evils in most circumstances.

--Rich P.









BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org