On Thu, 6 Sep 2001, Sheldon Hearn wrote:
> I'm queuing all the messages associated with a mailshot before starting
> a single queue runner. If I encounter _any_ problems during queuing, I
> smoke the queue and start again.
>
> 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.
It depends on exactly what degree of insurance you want. If you turn off
fsync(), and submit your zillion messages to your queue, the entire
submission will finish and return control to your calling script/program
saying "OK", but the final blocks of data will still be in memory, and
not on disc. If the power fails at that point, you are probably in
trouble. However, I suppose you could program round this by calling sync
(1) (i.e. /usr/bin/sync) once at the very end, and not recording "done"
till it completes.
If you turn off fsync() during delivery, Exim's journal of completed
deliveries won't be flushed to disc, so after a crash you will get
repeated deliveries because it will have forgotten what it's done.
Modern hardware is pretty reliable, so I imagine (IANAE on this) you'll
get away with it most of the time, but what "most" means I don't know.
(How reliable is your power supply?) You then have to judge whether the
risk is acceptable.
I think this area is too risky for me actually to add a no_fsync option
to the main source tree. It is giving people just too much rope...
An easier way to provide it for yourself, instead of patching the code
everywhere it occurs, would be to add the single line
#define fsync(x) 0
to macros.h and then compile a separate "nofsync" binary.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
