| Summary: | Segmentation of mailbox in mbox format | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | David Sinclair <david_sinclair> |
| Component: | mbox | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | wishlist | CC: | luigi.toscano |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
David Sinclair
2005-03-03 18:42:17 UTC
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. |