|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [RFC] Disk integrity in QEMU |
Date: | Fri, 10 Oct 2008 11:32:16 +0200 |
User-agent: | Thunderbird 2.0.0.16 (X11/20080723) |
Gerd Hoffmann wrote:
Hi,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.
[Prev in Thread] | Current Thread | [Next in Thread] |