> 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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
