On Wed, 20 Jan 1999, Tom Lane wrote:
> What the -F switch actually does is to disable calls to fsync(2),
> thereby allowing modified file blocks to hang around in kernel
> memory for a little while (up to 30 seconds in most Unixes)
> rather than being force-written to disk as soon as each transaction
> commits. If the same block of the database file gets modified
> again within that time window (very likely under a repeated-update
> load), you just saved a disk write.
Your effeciencies from running asynchronously run far beyond that.
By delaying writes, you allow the kernel to order them and pass them in
large chunks to the drive, getting very good effeciency. Compare ten
aggregated writes (the asynchronous case) to ten individual writes
(the synchronous case): in the former case, the disk arm needs to move
over the platter once, and you pay the cost of initiating a write once,
whereas in the later case the disk arm needs to do ten seeks, and you
pay the cost of initiating ten different disk operations, servicing ten
interrupts instead of one, etc. You save a lot more than just optimizing
out cancelling writes.
> I'm not sure I believe the argument that omitting -F buys very much
> safety, even if you do not trust your power company. Murphy's law
> says that a power flicker will happen in the middle of committing
> a transaction, not during the 30-second-max window between when you
> could've had the data flushed to disk if only you'd used fsync()
> and when the swapper process will fsync it on its own. And in that
> case you have a corrupted database anyway.
That depends on how you process your transactions, I guess. It is
possible to perform transactions safely, such that no interruption can
violate your db's integrity. I have not read and understood enough
of psql's transaction engine to know how safe it is in the face of
interruption, but there's no inherent reason that it need be unsafe.
The real way to solve this problem is to build a file system which is
more suitable for use in this way than a traditional unix fs. You're
working around the coarse-grained-ness of fsync() no matter what you do,
and there is no good solution until you move away from fsync() and towards
something like fsync(block) or fsync(transaction).
--
Todd Graham Lewis 32�49'N,83�36'W (800) 719-4664, x2804
******Linux****** MindSpring Enterprises tlewis@mindspring.net
"Those who write the code make the rules." -- Jamie Zawinski
