[ZODB-Dev] Use of fsync in FileStorage

[Tim Peters]

[Dieter Maurer]
>> In a former employees life, we used fflush in all places where is seemed
>> necessary (after writing the serial log, after updating the main data
>> file, after completing the serial log). The result was: we got 10 to 15
>> transactions per second. Almost the entire time was spent in "fflush".
>> This was on Sparc/Solaris 2.6.

[and now it's Dieter's turn]
> The "fflush"s above should have been "fsync"s, of course...

Sure, that was clear from context.

Looking at the timings people sent so far leaves a lot of guesswork, but
there appear to be two extremes:  people on Linux with good SCSI drives see
change in txn rate less than a factor of 2, between using no fsyncs in
FileStorage and using two.  The worst Linux reports so far are still over
100 txn/second with 2 fsyncs.

The other extreme, on both ends, remains me:  WinXP with a consumer-grade
IDE drive.  While this is still the fastest yet reported with no fsyncs
(~3000 txn/second), it's also (by far!) the slowest yet reported with two
fsyncs (~15 txn/second).  A factor of 200 will be hard to beat (or to
justify -- sheesh).

Linux users with what I'm guessing are single IDE drives appear to hover
around a factor-of-10 txn rate difference between 0 and 2 fsyncs, with most
of the damage done by the first fsync.

I'm most interested in the first kind of system, "server-class"
configurations.  Serious users with heavy loads run those, and they probably
have the most to lose if the database goes bad.  If it's generally true that
fsyncs really don't hurt them much, that makes a tempting default.

If possible, I'd like to see some timings from the kinds of boxes you run in
production.  I'd also like to know whether an option to run with *no* fsyncs
would be interesting to you.  You should answer that last one twice:  once
before running timings, then again after <wink>.