>> Let's say I don't care about my data. How will forced writes affect
>> transaction overhead?

At 11:03 5/09/2008, Adam wrote:

>It will allow the database to flush changes to disk when it is
>convenient rather than straight away. Not using this I imagine would
>speed up commits, but I am not overly familiar with the inner workings
>of asynchronous writes because they are inappropriate to our
>environment (we do care about our data). If you do disable forced
>writes, then you need to know that some older versions on some
>platforms had some pretty serious bugs that could result in you losing
>quite a lot of data.

Actually, that's not the problem. The problem is that Windows takes "asynchronous" to the nth-degree and actually does not perform the write until the database file is closed. On Superserver, this means "all users logged out and no connections in the process of timing out"; on Classic it means "no processes running or in the process of terminating". Some judicious testing showed that 24/7 systems (including those involving web-based clients) simply *never* wrote to disk.

So Windows and asynch writes were never a good combination and it's been a known Windows gotcha for a long time. As a repairer of corrupted databases I can tell you that virtually all database corruptions have had async writes and Windows in the etiology.

On Linux, so the rap would go, turning off FW was demonstrably less risky. Certainly, the rarity of database corruptions in Linux-based databases, with or without FW, was hard to argue with.
*******
Only....quite recently....it was discovered that forced writes actually NEVER worked on Linux! I mean - never, not in the InterBase era, not in the Firebird era. That was due to an obscure bug in Linux itself that was never fixed (and still isn't!). A workaround was coded in to Firebird 2.1 at a late stage in the Beta cycle but, on anything older, FW does not work on Linux.
*******
From Fb 2.0 onward, there is no longer "open-ended" asynch writes on Windows. The Firebird engine actively controls how often the pages are flushed to disk when FW is off on Windows. By default, if there are writes waiting for 5 seconds or more, or there are 100 or more writes waiting, the cache will be flushed at the next commit regardless. (You can configure these numbers in firebird.conf via the parameters MaxUnflushedWrites and MaxUnflushedWriteTime. They don't have any effect on platforms other than Windows).

./heLen