Re: wikipedia down, slashdot covering, mysql mentioned

[Heikki Tuuri]

Jochem,

----- Original Message ----- 
From: "Jochem van Dieten" <jochemd@stripped>
Newsgroups: mailing.database.myodbc
Sent: Wednesday, February 23, 2005 1:01 AM
Subject: Re: wikipedia down, slashdot covering, mysql mentioned


> On Wed, 23 Feb 2005 00:22:55 +0200, Heikki Tuuri wrote:
>>
>> a buggy fsync() in Linux is one of  the possible reasons here. If an 
>> InnoDB
>> tablespace gets corrupt in a power outage, it is most probably caused by 
>> a
>> bad fsync() implementation or configuration in the operating system or
>> hardware. An fsync() call should write the data physically to disk or to 
>> a
>> battery-backed, non-volatile disk cache. If it fails to do so, then any
>> database, PostgreSQL or anything, can get corrupt.
>
> Can they? Even if the absolute ordering of writes is maintained, only
> full pages are written and each page has a checksum? It seems to me
> that then you might lose transactions that have not yet committed to
> disk, but your database would not get corrupt.

you are right, if the disk subsystem writes database pages to the disk or a 
non-volatile cache in the same order that fsync() was called on the pages, 
then the database cannot get corrupt. Corruption could only result from a 
partial page write, and against that InnoDB uses the 'doublewrite' method:

http://dev.mysql.com/doc/mysql/en/innodb-disk-i-slash-o.html

In the Wikipedia case, the disk subsystem apparently had written partial 
pages for whom the good copy of the page was not present in the doublewrite 
buffer. That means that the writes could not physically happen in the same 
order that fsync() was called on them. Thus, fsync() was not a 'barrier' in 
disk writes.

> Jochem

Regards,

Heikki