Re: [exim-dev] Old topic again: Option to avoid fsync()?

On Wed, Jan 10, 2007 at 04:26:29PM +0100, Florian Weimer wrote:
> If you want to throw money at the problem, a RAID controller with a
> battery-backed cache is a good option as well.

You completely miss the point, so let me rephrase it: I am _not_
talking about regular operation. I am talking about cleaning up a mess,
e.g. after an attack or double/triple fault that managed to kill all
redundancy. Additionally, exotic applications benefit from disabling
fsync().

It's not economical to run systems at 10% of their maximum performance
just to have enough if shit happens, unless of course you just run a
small site, where the economic disadvantage of doing so can be tolerated.

> On the other hand, with a lot drives in their default configuration,
> fsync() can't reliably do what it claims to anyway. 8-/

Actually, if you use maildir, there is no fsync() to synchronise the
directory, just one for the tmp file, but a code audit must be harder
than implicating to leave fsync in place under all conditions, because
it the most you can do and still sometimes not enough.

The only valid point so far was:

>> Do you vote for or against having an option to disable fsync()?

> Against; I don't want Exim authors blamed for irresponsible behaviour.

What's irresponsible most of the time, may exceptionally be sane.
LD_PRELOAD is an idea that probably works fine, although I don't like
the implications of a setuid library being usable for other setuid
applications, too. That's why I still prefer an exim-only configuration
file option.

Any other opinions than "enforce fsync, because it works for me"?

Michael