On Wed, 18 May 2005, Ludvig Strigeus wrote:
>Link:
>http://searchstorage.techtarget.com/tip/1,289483,sid5_gci920473,00.html
>
>Quote: "FlushFileBuffers is an API call that forces all data for an open
>file handle to be flushed from the system cache and also sends a command to
>the disk to flush its cache (contrary to the name, this call affects all
>data stored in the device cache)"
The device cache is the cache on the drive, which has no knowledge of OS
files. Hence, all the cache must be flushed.
>
>So FlushFileBuffers flushes ALL writes to disk, not just those of the
>specified file handle.
No. Only the file contents in the "system cache" are synced. That the
device cache is flushed as well is not of concern to us. This should be
the norm.
>
>According to that article, it looks like the recommended way to achieve good
>performance and integrity is to use FILE_FLAG_WRITE_THROUGH, not
>FlushFileBuffers.
No, because *every single* write to that handle will involve a sync to the
underlying device! That would decimate performance.
Using a single FlushFileBuffers batches multiple write's in a single sync
operation.
That this hurts performance on Windows says more about Windows than about
the algorithm used by SQLite.
>
>Quote: "FILE_FLAG_WRITE_THROUGH indicates that a device may not complete a
>write request until the data is committed to media. This is enforced through
>the use of the FUA flag"
>
>Then this flag should be enabled when writing to the journal log:
>Quote: "FILE_FLAG_SEQUENTIAL_SCAN informs the file system that the file will
>be accessed sequentially. This allows the file system to be more aggressive
>in caching and perform read ahead/write behind operations and also
>flushing/discarding buffers once the I/O has progressed beyond the location
>of the file contained within the buffer. Benchmarks have shown that
>FILE_FLAG_SEQUENTIAL_SCAN provides a negligible improvement in read
>throughput, but provides a noticeable improvement in write throughput."
The journal may benefit from such a flag. Patch the source and try it!
>
>/Ludvig
>
If performance is your problem, and Windows appears to be the bottleneck
compounded by the slow HD on your laptop, use Linux on a reasonable HD.
Use the right tool for the job. The laptop is a reasonable development
platform. But for production, a laptop is not viable anyway. Stick to the
recommendations and batch writes in single transactions, then the commit
cost is amortized by the large volume of data written.
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
