Re: [exim] Exim 5 Wishlist

Top Page
Delete this message
Reply to this message
Author: Wakko Warner
Date:  
To: Wouter Verhelst
CC: exim users, W B Hacker
Subject: Re: [exim] Exim 5 Wishlist
Wouter Verhelst wrote:
> On Fri, Feb 16, 2007 at 04:56:53AM +0800, W B Hacker wrote:
> > Richard Pitt wrote:
> > > SQL generally requires far
> > > more resources for similar performance - especially with "blobs" of any
> > > size.
> >
> > Not 'generally'. 'Always'. And by a large margin.
> >
> > At the end of the day any DB must *also* map to the underlying fs -
> > and not just the raw data - but all of its own overhead, logs, checks
> > and balances, bells and whistles.
>
> You're oversimplifying here. Kernels have the ability to switch off
> caching (O_DIRECT, etc), metadata-updates, and similar, for specific
> files, and database servers generally use those APIs.
>
> It's also perfectly possible in some cases to run a database directly on
> a raw device ('/dev/XXX'), and bypass the filesystem entirely.
>
> Finally, if you run a mail store on a filesystem, you usually require
> many files -- exim requires two files per mail in the mail store. Most
> database systems dump all their tables in one file, so the stress on the
> filesystem implementation isn't as extensive.


Also, if implemented in a specific way, the exim spool when stored in SQL
could save on disk writes when delivering locally, only 1 copy of the
message is ever written. The user accounts could just point to the body
part of the message as it was in the spool. It would be deleted when
there's no more reference to it. Kind of like storing your mail spools in
maildir format and every user who gets a copy of the same message is
hardlinked to the same physical file.

--
Lab tests show that use of micro$oft causes cancer in lab animals
Got Gas???