Re: [Qemu-devel] Ensuring data is written to disk

["R. Armiento" <reply-2006@armiento.net>]

Thomas Steffen wrote:
> On 8/7/06, R. Armiento <reply-2006@armiento.net> wrote:
> And some IDE disks do not let you switch off write-caching. So as far
> as I know, you need SCSI for transactional guarantees. 

I don't think the fact that there are some buggy drives/firmwares out 
there should be taken to mean that you cannot ever have transactional 
guarantees on SATA/PATA. It just means that you have to be careful to 
make sure your drives are not buggy.

> [write barrier] gives much higher performance and guarantees
> the consistency of the disk content, but it does not guarantee the
> consistency with the rest of the world. My impression was that Linux
> only does the later, but I did not find a lot of information on this.

Right, and if you want full transaction guarantees in your database 
(e.g. ACID, http://en.wikipedia.org/wiki/ACID ) on power loss you cannot 
rely on any such fancy handling of fsync, you *have* to wait for data to 
first go to disk cache, and then flush the cache to make it go to disk 
platters. *Ext3* (rather than "Linux" as you say) has currently no mount 
option to enable this (as far as I know; but the one-line patch 
previously mentioned should enable this). However, I interpret Jens 
Axboe to say that Reiser4 in Linux may do this (as default?).

But if "full transaction guarantees" seems excessive, and 'merely' 
internal consistency of your database on power loss is acceptable: what 
file systems and mount options can be used on a later Linux 2.6 kernel? 
I would think ext3 in the non-default data=journal mode is what is 
needed, but the ext3/MySQL docs I have found is lacking on this topic.

> Both MySQL and ext3 are transaction safe if used on a correct disk (SCSI). 
> But if your disk does not handle sync correctly, then the resulting 
> system cannot be transaction safe.

Do you by 'transaction safe' mean 'internal consistency'? (That is not 
the definition I use; see above). On SCSI hardware with write cache and 
no battery back up, wont data in the cache be irrecoverably lost just as 
on SATA/PATA? Thus, while the file system (if you journal metadata) or 
your database (if you also journal data) may be guaranteed to stay 
consistent, I think you can still lose transactions that has been 
committed.

I don't recall to have seen warnings of this in database docs, hence my 
surprise. (However, I might just not have been looking hard enough.)

//Rickard