| Message ID | 1274897594-4167-1-git-send-email-agraf@suse.de |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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(-)