Yah, lets see how it fares now that the random I/O read-ahead issue in cluster_read() has been fixed. Just stick with fsync_mode=3 (which is equivalent to what UFS does but requires even fewer discrete media writes). The fsync modes have been completely revamped as of late 2.5 and mode 3 (REDO and wait for IO completion but no media sync) is now the default.
I suspect random I/O crossing 64K data block boundaries will still have issues even with nohistory because on-media data blocks are not immediately reused. An overwrite writes out a new datablock and changes the B-Tree record to point at it in order to guarantee that the old data block can be recovered by the crash recovery code. Reblocking the file will help there but it still presents a problem for a database which does a lot of writing. -Matt