On Thu, 06 Sep 2001 15:43:53 +0200, Sheldon Hearn wrote:
> Surely under these conditions, a no_fsync option (as demonstrated below)
> would be "safe" given these limitations? The configure file I use for
> queuing would contain no_fsync, while the configure file used by the
> queue runners would not.
Hmmm, posting that patch without a fatter disclaimer was irresponsible.
I should have said that
a) I haven't tried it myself, yet. I'm waiting to hear from Philip that
fsync() isn't used for any other purpose than to as-best-as-guarantee
that stuff makes it to disk in case of a catastrophic failure.
b) Even once (a) above is resolved, it's still not a sensible option for
everyday use.
That said, the fsync() calls seem to me to be a continual cost that only
pays off in the face of catastroiphic failure. If the entire spool
directory is going to be deleted and recreated on failure, the cost
doesn't buy anything.
Obviously, I wouldn't _dream_ of enabling no_fsync in queue runners,
only in queue injectors (exim -bS).
