On Thu, Jul 22, 2004 at 02:47:52AM EDT, Thomas Glanzmann wrote: > Hello 'Mr I would cache mailbox, if I had the time', LOL ;-P > > An mbox cache could be done. This isn't really accurate. > > so please enlighten me and tell me what you would use as unique > identifier for eMails? The message id? And tell me how you would > invalidate a cache entry on a edited message? Using a md5 sum over the > whole message? Why do you need md5 on the entire message? Doesn't a header-only md5 suffice? > I see absolut no way of doing a *efficient* way to do mailbox header > caching, but maybe you have some ideas. Please share! I guess the problem you're seeing is that mbox is already quite efficient, so almost anything you'd do to cache information from it in yet another file would only add up to incremental performance gains. With maildir, you start out far worse with nothing, so you have far more to gain by caching headers. (Try a 300MB maildir with no headercache, and I think you'd sooner die than wait for it to load ... hehe. . .) Based on my own experience, even taking the mbox itself and binary-indexing it in-place (basically what mbx does) only offers incremental performance improvements. If you're serious about scalable performance, I'd suggest a real database server (like mysql) for the mail store. Trying to emulate a database with the filesystem isn't really The Right Way (TM). You just got me curious about an interesting possible user-mode filesystem, actually: How about a filesystem server providing a virtual maildir from an mbx back-end? Network clients can use the virtual maildir over NFS about as safely as a real maildir. Local clients can use the mbx back-end directly, or the virtual maildir, if it's more convenient (say, for the mairix symlink trick). - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpU6MTpB7lJF.pgp
Description: PGP signature