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: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
