D. Richard Hipp wrote:

 From what I am told, most IDE drives do signal the OS when the data
reaches the platter.  I'm also told that the Linux fsync() call does
not return until it gets that signal.  The Windows FlushFileBuffers(),
on the other hand, does not wait for the data to get to platter.  So
on a windows system, there is a brief moment of vulnerability where
a power loss can lose data.  But on Linux, that window of vulnerability
is zero.

The above is how IDE drives are *suppose* to work.  There is wide-
spread suspicion that many cheap IDE drives do not implement the
protocol correctly.  If your have one of those broken IDE disks,
all bets are off.


Keep in mind that I'm simply parroting my interpretation of the discussions over on the mailing lists at freebsd.org... You might want to go straight to the horse's mouth instead of having it filtered (possibly incorrectly) through me. :)

I am also told that the Linux IDE driver is broken with respect to
media errors.  If the disk drive has a media error, Linux does not
take appropriate corrective action, nor does it alert the user-space
code.  I don't know how true this is or if it is really a problem.
(How common are media errors?)


Not very common, but I don't anything about the Linux ATA driver, so I couldn't begin to guess just how badly broken it might or might not be.

Regardless of the situation, though, the window of vulnerability
during which a power loss might cause database corruption is small.
And Liz is reporting that she can reproduce the corruption
consistently.  So perhaps her trouble have a different cause.

Even a small window could do the job if it's being written to at a high rate of speed. By the time one set of writes actually hits the disk, more may be in flight. Dunno, there could be any number of factors contributing to this.


I guess the moral of the story is that reliable power is important.
--
http://www.classic-games.com/         http://www.indie-games.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to