|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive |
Date: | Tue, 11 May 2010 12:09:14 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 05/11/2010 10:53 AM, Paul Brook wrote:
I disagree. We should not be removing or rejecting features just because they allow you to shoot yourself in the foot. We probably shouldn't be enabling them by default, but that's a whole different question.I disagree and think the mentality severely hurts usability. QEMU's role should be to enable features, not to simplify every obscure feature. In general, if someone wants to accomplish something, we should try to provide a mechanism to accomplish it. cache=none|writeback|writethrough is an example of this. No one other than QEMU can control how we open a file descriptor so we need to provide a knob for it.Doesn't the same argument apply to the existing cache=writethrough? i.e. if you want to avoid data loss you should make sure your guest issues flushes properly, and it's not something qemu should be trying to hack round be adding an implicit flushe after every write.
cache is the host page cache acting as an extended disk cache. In writethrough mode, the behavior is identical to writethrough on a normal disk cache in that all operations are completed only when sent down to the next storage layer. In writeback mode, you rely on the integrity of the host page cache to prevent data loss.
Data loss is different than data corruption though. In neither mode will a correct application experience data corruption because if a guest issues a flush, we respect those requests. However, the new proposed mode would introduce the possibility of data corruption because it becomes possible for writes to be written to disk outside the order requested by the guest. In the event of power loss, the result is corruption.
Regards, Anthony Liguori
Paul
[Prev in Thread] | Current Thread | [Next in Thread] |