massive disk space leak vs thresh_update

[Tom Allison]

Matthias Andree wrote:
> Tom Allison <tallison at tacocat.net> writes:
> 
> 
>>I would rather suggest addressing the potential problem inherent with 
>>the database.  You have to routinely cleanup the logs and manage the 
>>database environment much more than you have in the past.  Thats the 
>>nature of the beast.
> 
> 
> I have thought about this a bit, and I think we should offer a mode
> where bogofilter automatically clears the lock files right away. Either
> we do this automatically per "time last run", or we offer a special
> bogofilter mode that the user can stuff into her crontab where it is run
> regularly. I'd also considered adding a "verify", or "check" mode, where
> bogoutil could go through the database files; and reimplement some parts
> of the utilities in bogoutil, because they're usually only on the order
> of 3...30 lines of code - that saves the user the hassle of finding and
> installing the utilities and allows us to wrap proper locking so the
> user doesn't need to take care to stop her mail system.
> 

I wonder how much perfomance cost we'll pay for all this transactional 
benefit.  I personally have never had a problem with any of these 
database issues with a possible exception of locking reads when writing 
to the database.  But procmail retries.

I read the rest of your post and realize that my experience is based on 
a mail server that would be considered modest at best.  Therefore my 
opinions should be considered with that in mind.

The only concern that I might have that's legitimate would be the payoff 
between performance and integrity.  I've always run a bogoutil dump 
daily with running with many updates and still have weekly today (no 
updates).  I don't know how often we actually see a problem with 
database corruptions taking place.  But I do know that bogofilters 
performance has been very good in the past.