[Qemu-devel] [PATCH] Default to cache=writeback

[Qemu-devel] [PATCH] Default to cache=writeback

[Alexander Graf]

In the previous discussion Anthony brought up the fact that cache=writeback is
safe enough considering data integrity. If so, I don't see a reason not to use
it as default, as it speeds up things a lot.

Keep in mind that most people will want to use cache=none anyways if they want
to bypass the host cache.

To stress my point, I ran the same test I did for cache=unsafe again to compare
cache=write{through,back}.

cache=writeback

real	0m32.549s
user	0m16.069s
sys	0m6.152s

cache=writethrough

real	0m48.055s
user	0m16.677s
sys	0m8.045s

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 qemu-options.hx |   19 +++++++++----------
 vl.c            |    5 ++++-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index cea9b72..b389f36 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -162,16 +162,15 @@ This option specifies the serial number to assign to the device.
 Specify the controller's PCI address (if=virtio only).
 @end table
 
-By default, writethrough caching is used for all block device.  This means that
-the host page cache will be used to read and write data but write notification
-will be sent to the guest only when the data has been reported as written by
-the storage subsystem.
-
-Writeback caching will report data writes as completed as soon as the data is
-present in the host page cache.  This is safe as long as you trust your host.
-If your host crashes or loses power, then the guest may experience data
-corruption.  When using the @option{-snapshot} option, writeback caching is
-used by default.
+By default, writeback caching is used for all block devices. It will report
+data writes as completed as soon as the data is present in the host page
+cache.  This is safe as long as you trust your host.  If your host crashes
+or loses power, then the guest may experience data corruption.  When using
+the @option{-snapshot} option, writeback caching is always used.
+
+Writethrough caching means that the host page cache will be used to read
+and write data but write notification will be sent to the guest only when
+the data has been reported as written by the storage subsystem.
 
 The host page cache can be avoided entirely with @option{cache=none}.  This will
 attempt to do disk IO directly to the guests memory.  QEMU may still perform
diff --git a/vl.c b/vl.c
index bc15dd7..a70e487 100644
--- a/vl.c
+++ b/vl.c
@@ -917,11 +917,14 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
             bdrv_flags |= BDRV_O_CACHE_WB;
             bdrv_flags |= BDRV_O_NO_FLUSH;
         } else if (!strcmp(buf, "writethrough")) {
-            /* this is the default */
+            /* no special flag needed */
         } else {
            fprintf(stderr, "qemu: invalid cache option\n");
            return NULL;
         }
+    } else {
+        /* default to writeback */
+        bdrv_flags |= BDRV_O_CACHE_WB;
     }
 
 #ifdef CONFIG_LINUX_AIO
-- 
1.6.0.2

Re: [Qemu-devel] [PATCH] Default to cache=writeback

[Stefan Hajnoczi]

On Wed, May 26, 2010 at 7:13 PM, Alexander Graf <agraf@suse.de> wrote:
> In the previous discussion Anthony brought up the fact that cache=writeback is
> safe enough considering data integrity. If so, I don't see a reason not to use
> it as default, as it speeds up things a lot.

cache=writeback is not a good default for qcow2:

https://bugzilla.redhat.com/show_bug.cgi?id=572825
http://wiki.qemu.org/Features/Qcow2DataIntegrity

The actual qcow2 file itself can become corrupted because metadata
updates are not ordered or flushed with respect to each other or data.
 This is more serious than losing data written after the last flush.

I believe special case cache= defaults for raw vs qcow2 have been
mentioned before but I don't see any code in qemu.git currently that
ensures qcow2 is run safely by default.

Stefan

Re: [Qemu-devel] [PATCH] Default to cache=writeback

[Alexander Graf]

On 26.05.2010, at 21:28, Stefan Hajnoczi wrote:

> On Wed, May 26, 2010 at 7:13 PM, Alexander Graf <agraf@suse.de> wrote:
>> In the previous discussion Anthony brought up the fact that cache=writeback is
>> safe enough considering data integrity. If so, I don't see a reason not to use
>> it as default, as it speeds up things a lot.
> 
> cache=writeback is not a good default for qcow2:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=572825
> http://wiki.qemu.org/Features/Qcow2DataIntegrity
> 
> The actual qcow2 file itself can become corrupted because metadata
> updates are not ordered or flushed with respect to each other or data.
> This is more serious than losing data written after the last flush.
> 
> I believe special case cache= defaults for raw vs qcow2 have been
> mentioned before but I don't see any code in qemu.git currently that
> ensures qcow2 is run safely by default.

Well since cache=writethrough is the default, it apparently isn't hit by the issues you mentioned.

Kevin, what's your opinion on this?


Alex

Re: [Qemu-devel] [PATCH] Default to cache=writeback

[Kevin Wolf]

Am 01.06.2010 13:31, schrieb Alexander Graf:
> 
> On 26.05.2010, at 21:28, Stefan Hajnoczi wrote:
> 
>> On Wed, May 26, 2010 at 7:13 PM, Alexander Graf <agraf@suse.de> wrote:
>>> In the previous discussion Anthony brought up the fact that cache=writeback is
>>> safe enough considering data integrity. If so, I don't see a reason not to use
>>> it as default, as it speeds up things a lot.
>>
>> cache=writeback is not a good default for qcow2:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=572825
>> http://wiki.qemu.org/Features/Qcow2DataIntegrity
>>
>> The actual qcow2 file itself can become corrupted because metadata
>> updates are not ordered or flushed with respect to each other or data.
>> This is more serious than losing data written after the last flush.
>>
>> I believe special case cache= defaults for raw vs qcow2 have been
>> mentioned before but I don't see any code in qemu.git currently that
>> ensures qcow2 is run safely by default.
> 
> Well since cache=writethrough is the default, it apparently isn't hit by the issues you mentioned.
> 
> Kevin, what's your opinion on this?

To be honest, I can't follow your argumentation. What you're saying is
basically "with the current default of writethrough it works, so it
can't be dangerous to change the default to writeback". Not sure how you
draw this conclusion.

Kevin

Re: [Qemu-devel] [PATCH] Default to cache=writeback

[Stefan Hajnoczi]

On Tue, Jun 1, 2010 at 12:31 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 26.05.2010, at 21:28, Stefan Hajnoczi wrote:
>
>> On Wed, May 26, 2010 at 7:13 PM, Alexander Graf <agraf@suse.de> wrote:
>>> In the previous discussion Anthony brought up the fact that cache=writeback is
>>> safe enough considering data integrity. If so, I don't see a reason not to use
>>> it as default, as it speeds up things a lot.
>>
>> cache=writeback is not a good default for qcow2:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=572825
>> http://wiki.qemu.org/Features/Qcow2DataIntegrity
>>
>> The actual qcow2 file itself can become corrupted because metadata
>> updates are not ordered or flushed with respect to each other or data.
>> This is more serious than losing data written after the last flush.
>>
>> I believe special case cache= defaults for raw vs qcow2 have been
>> mentioned before but I don't see any code in qemu.git currently that
>> ensures qcow2 is run safely by default.
>
> Well since cache=writethrough is the default, it apparently isn't hit by the issues you mentioned.

cache=writethrough is safe because it uses O_SYNC.

Stefan