[Top][All Lists]

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

Re: [Qemu-devel] [RFC] Disk integrity in QEMU

From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Date: Fri, 10 Oct 2008 11:32:16 +0200
User-agent: Thunderbird (X11/20080723)

Gerd Hoffmann wrote:

Read performance should be unaffected by using O_DSYNC.  O_DIRECT will
significantly reduce read performance.  I think we should use O_DSYNC by
default and I have sent out a patch that contains that.  We will follow
up with benchmarks to demonstrate this.

So O_SYNC on/off is pretty much equivalent to disk write caching being
on/off, right?  So we could make that guest-controlled, i.e. toggeling
write caching in the guest (using hdparm) toggles O_SYNC in qemu?  This
together with disk-flush command support (mapping to fsync on the host)
should allow guests to go into barrier mode for better write performance
without loosing data integrity.

IDE write caching is very different from host write caching.

The IDE write cache is not susceptible to software failures (well it is susceptible to firmware failures, but let's ignore that). It is likely to survive reset and perhaps even powerdown. The risk window is a few megabytes and tens of milliseconds long.

The host pagecache will not survive software failures, resets, or powerdown. The risk window is hundreds of megabytes and thousands of milliseconds long.

It's perfectly normal to leave a production system on IDE (though perhaps not a mission-critical database), but totally mad to do so with host caching. I don't think we should tie data integrity to an IDE misfeature that doesn't even exist anymore (with the advent of SATA NCQ).

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

reply via email to

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