qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: R. Armiento
Subject: Re: [Qemu-devel] Ensuring data is written to disk
Date: Tue, 08 Aug 2006 04:37:06 +0200
User-agent: Thunderbird 1.5.0.4 (X11/20060615)

Thomas Steffen wrote:
On 8/7/06, R. Armiento <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]