> I try to avoid r/w contention by using full data journalling with external > journals, which are on physically different (and hopefully faster) HDDs. I > believe this is good practice for synchronous I/O like mail and NFS.
There is a bunch things you can do for _regular operation_. But disks can fail by getting ridiculous slow, networks can lose or destroy packets, name servers can fail, then of course there are attacks and whatever else... and you end up with a queue. Disable fsync() for a couple minutes and people have their mail. Enable it again and everything is fine. > For real psychopathic I-don't-care-about-my-data cases you can always use > tmpfs.. Right, but that may either cause swapping or I have a very limited queue. Running the system on real disks, but without fsync(), means data will either be written lazy, or not at all. It's nicely in between tmpfs and fsync(). Do you vote for or against having an option to disable fsync()? Michael -- ## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
