On Thu, 2001-09-06 at 15:31, Sheldon Hearn wrote:
> 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.
There is a blue sky alternative which is just getting to the point where
it could be really useful....
The problem with fsync is it basically forces data down to the rust on
the platter (assuming your disk subsystem really is quickly spinning
rusty iron plates). If you can put a reliable buffer in between you and
the disk, then writes can be spread out and made more efficient.
Linux ext3 has now developed to the stage where the journal file can be
put onto a separate device. That device could be a NVRAM disk, and
given a MTAs pattern of disk usage much of the data might never be
finally written to disk since it would be invalidated (ie message
shipped out) before the disk write came due.
Anyone who feels very brave could give this a test - you'd need a very
recent 2.4/ac kernel and you'd probably have to put the journal onto a
straight RAM disk (not good for real life, but ok for testing).
You would almost certainly want to be doing data journalling mode to
prevent fsyncs flushing data to disk (metadata journalling would not
prevent this).
Seeing as its Sheldon, he will have a good idea as to whether the *bsd
OSes have this sort of development in progress.
Nigel.
