Hi,
From the testing I did a few years ago the FlushFileBuffers API, it was not single file aware i.e. it flushed the whole cache to disk, and caused a large performance hit. Has this changed ?


>>I was serious :-) Really. Knowing Jim's extensive research on the subject, I thought he'd be delighted. Makes one wonder why it was done any differently in the past...
>>
>>Let us know how the testing goes. The MSDN library isn't very revealing on the matter.
>
>The help says FLUSH now calls the FlushFileBuffers API function... like you say, if it wasn't doing this before, exactly what WAS it doing?
>
>If by MSDN Library you're referring to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/flushfilebuffers.asp then yeah, it's not too enlightening.
>
>I think ultimately it has to depend on the device driver for the disk subsystem in question, and if/how well it implements FFB. The driver would absolutely have to respect FFB if called with a volume option because that's what must get called on a system shutdown. Would it respect FFB called with a single file or group of files as argument(s)? (a group of files might be treated in VFP as multiple single-file calls).
>
>I'd like to think if it respects the former, it *should* respect the latter. But, in a commodity market OEMs might be trying to differentiate themselves from the competition on benchmarks. It's possible they could show higher numbers if they ignored single-file FFB calls and simply left it up to a lazy-write algorithm to take care of it "whenever".
>
>To a certain extent nVidia and ATI have been engaging in dodgy optimizations to make their video cards look better in the fiercely competitive graphics world.