Re: win32 performance - fsync question

On Fri, 18 Feb 2005, Oliver Jowett wrote:

> Evgeny Rodichev wrote:
>
>> Write cache is enabled under Linux by default all the time I make deal
>> with it (since 1993).
>>
>> It doesn't interfere with fsync(), as linux kernel uses cache flush for
>> fsync.
>
> The problem is that most IDE drives lie (or perhaps you could say the
> specification is ambiguous) about completion of the cache-flush command --
> they say "Yeah, I've flushed" when they have not actually written the data to
> the media and have no provision for making sure it will get there in the
> event of power failure.

Yes, I agree. But in my real SA practice I've met 50-100 times the situation
when HDD were unexpectedly physically corrupted (the heads touch a surface),
without possibility to restore. And I never met any corruption because of
possible "hardware lie".

>
> So Linux is indeed doing a cache flush on fsync, but the hardware is not
> behaving as expected. By turning off the write-cache on the disk via hdparm,
> you manage to get the hardware to behave better. The kernel is caching
> anyway, so the loss of the drive's write cache doesn't make a big difference.

Again, in practice, it is different. FreeBSD had a "true" flush (at least
2-3 yeas ago, not sure about the modern versions), and for write-intensive
applications it was a bit slower (comparing with linux), but it never was
more reliable (since 1996, at least).

Another practical example is Google :) Isn't reliable?

>
> There was some work done for better IDE write-barrier support (related to
> TCQ/SATA support?) in the kernel, but I'm not sure how far that has
> progressed.

Yes, but IMHO it is not stable enough at the moment.

Regards,
E.R.
_________________________________________________________________________
Evgeny Rodichev Sternberg Astronomical Institute
email: er(at)sai(dot)msu(dot)su Moscow State University
Phone: 007 (095) 939 2383
Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er