Version: (using KDE KDE 3.4.0) A mailbox in mbox format could become quite large over time. It would be nice to have the possibility of a mailbox automatically and transparently segmenting itself based on predefined values - e.g. a 12,290KB mailbox (X) would consist of 4 files - X1, X2, X3 of, say, 4096KB and X4 of 2KB. Eventually, X4 will grow up to become a 4,096KB segment and then X5 would be created and so on. This way, not only fragmentation would be reduced on the filesystem, but overall performances would be improved, as KMail wouldn't have to deal with large files files.
Solution: use maildirs :)
Ah, because having say 20,000 files in a directory would bring much performance gain over a corresponding big monolithic mailbox? Don't think so...
I'd be interested in seeing numbers. So far, yes, I believe 20k files is better than a single 100MB file.
Well, yes and no. Having 20,000 20k files in a directory could impact I/O performance quite heavily - of course, it depends on the underlying file system, on its optimisations (or lack of) etc; but, as a general principle, having a big number of files within a directory, no matter what your FS is, will impact your I/O performance. On the other hand, a big file would have problems within the program itself - the way it's loaded or indexed or - well, as a developer, you must know those intricacies better than I do (I'm a sysadmin). But what I had initially said was: "well chosen segments" (something between 4,096-16,384KB in my experience); I didn't say anything about 100MB files - in fact, it was exactly what I was trying to avoid. I know of at least one mail program (on Windows) that lets you choose how big your mailbox segments will become; it's Rimarts' "Becky!", a very nice and feature-full application, quite similar to KMail in functionality (and even interface); Becky! stores its messages in mbox format (no maildir), but allows the user to choose the dimensions of the segments (or not - Becky! will use mbox by default, with no segmentation at all). By segmenting (again: transparently!) an mbox file, general fragmentation will decrease on the file system (especially when the user chooses "intelligent" segment sizes like 4,096KB or multiples of 2^10) and general operations with a few reasonably-sized files will be snappier than the same set of operations with either a huge number of small files or a unique hypersized file) Please note that I'm not willing to perpetuate the eternal (flame)war between mboxers and maildirers; both formats are very good for different scenarios; here, I'm only suggesting a feature associated with the mbox format and its performances, that's all.
My really big directories (50,000+ msg) have to be in mbox format (on ext3) otherwise KMail becomes unusably slow. (of course that size mbox file (~400M sucks as well... (esp. for deletes)).
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.