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 |
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 | |
We also thank MIT for the use of their facilities. |