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

> Maybe the no-fsync stuff should be limited to non-daemon mode operation?

I don't think the delivery process knows much about running under a
queue runner spawned by a daemon or by a manually started queue runner
or as part of direct manual delivery.

> I think "exim -qff" would do the trick for Michael, (and for me)
> wouldn't it? Michael?

I don't use Exim queue runners for larger systems, because they do not
scale with a growing queue.

> That would at least prevent people from running "exim -bd" or "-q5m"
> ordinarily. We could just ignore the no-fsync option or abort during
> startup.

Unfortunately, the frequent fsync() calls still impose a large penalty
for queue runners, even if those omit them. Try running one queue runner
with fsync and the rest without, and you won't see much improvement.

> > Thanks, that sounds like a perfect solution to me. :)
>
> If the Debian people will activate this switch at least in their -heavy
> package, I'd second that. Andreas, do you think you can bear the risk?
> At least with the above modification? I'm not sure whether I would.

Ah, the joy of "distributions". There ought to be a large banner on that
compile-time switch, saying: You SHOULD (capital letters and reference
to RFC 2119) not enable this option:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

And that describes the situation. Enable it, blow up the house, and it's
YOUR FAULT. It's not like compiling in all lookups and authenticators,
which is nice for those who like to use them and not dangerous to play
with. I don't know if Debian wanted to take responsibility for enabling
it, but if so, it would make sense if they already shipped Exim with a
suitable patch by now.

Whoever wonders what Exim 5 could contain to justify a new major version:
A queue storage API like INN has for articles would be my ultimate
favourite and definitively THE feature to start closing the performance
gap to some commercial MTAs. Well, one can dream of having the best of
both worlds.

Michael