[Mimedefang] BIG problems with mimedefang

David F. Skoll dfs at roaringpenguin.com
Thu Jan 19 12:30:47 EST 2006


Matthew.van.Eerde at hbinc.com wrote:

>> Even SpamAssassin shouldn't require locking unless the Berkeley DB
>> file is being written to.  If it's only being read, then concurrent
>> access shouldn't be a problem.

> Most bayesian analyses result in a write to add the new tokens and
> update the token counts.

But I though SA journaled Bayes updates, and then only ran the updates
periodically?

> Every so often a bayesian analysis results in a HUGE write to expire
> old tokens.

> Any mail that comes along during an expiry is going to have to sit
> and wait... the slaves pile up, processes drop into swap, and it's
> La Brea all over again.

Only if you do it the Wrong Way (tm).  The Right Way to update the Berkeley
database is as follows:

1) Copy database.db to database.db.new

2) Tie to database.db.new and do all your updates.

3) Atomically rename database.db.new to database.db

Presto!  No locking needed, no slaves piling up.  This assumes, of course,
that you're journalling your updates, and that only one process ever tries
to run the journal at a given time.  However, both of those conditions
are easy to meet.

(Step 3 relies on UNIX semantics -- any processes with the old file
open continue to see it; only when the last process closes the file
is the storage actually released.  This will probably not work at all
on Windoze... but who cares?)

Regards,

David.



More information about the MIMEDefang mailing list