Use writeback caching by default with qcow2
RFC PATCH 1/1 Use writeback caching by default with qcow2
qcow2 writes a cluster reference count on every cluster update. This causes performance to crater when using anything but cache=writeback. This is most noticeable when using savevm. Right now, qcow2 isn't a reliable format regardless of the type of cache your using because metadata is not updated in the correct order. Considering this, I think it's somewhat reasonable to use writeback caching by default with qcow2 files.
It at least avoids the massive performance regression for users until we sort out the issues in qcow2.
Regards,
Anthony Liguori
vl.c +3 -1
@@ -2225,7 +2225,7 @@ unit_id =-1 ; translation =BIOS_ATA_TRANSLATION_AUTO ; index =-1 ; - cache =1 ; + cache =3 ;if (machine->use_scsi) { type =IF_SCSI ;
@@ -2496,6 +2496,8 @@ bdrv_flags |=BDRV_O_NOCACHE ; else if (cache == 2) /* write-back */ bdrv_flags |= BDRV_O_CACHE_WB; + else if (cache == 3) /* not specified */ + bdrv_flags |= BDRV_O_CACHE_DEF; if (bdrv_open2(bdrv, file, bdrv_flags, drv) < 0 || qemu_key_check(bdrv, file)) {fprintf (stderr,"qemu: could not open disk image %s\n" , file);
qemu-doc.texi +6 -0
@@ -289,6 +289,12 @@ attempt to do disk IO directly to the guests memory. QEMU may still perform an internal copy of the data. +Some block drivers perform badly with @option{cache=writethrough}, most notably, +qcow2. If performance is more important than correctness, +@option{cache=writeback} should be used with qcow2. By default, if no explicit +caching is specified for a qcow2 disk image, @option{cache=writeback} will be +used. For all other disk types, @option{cache=writethrough} is the default. + Instead of @option{-cdrom} you can use: @example qemu -drive file=file,index=2,media=cdrom
block-qcow2.c +8 -0
@@ -189,6 +189,14 @@int len, i, shift, ret;QCowHeader header; +/* Performance is terrible right now with cache=writethrough due mainly +* to reference count updates. If the user does not explicitly specify +* a caching type, force to writeback caching. +*/ +if ((flags &BDRV_O_CACHE_DEF )) { + flags |=BDRV_O_CACHE_WB ; + flags &= ~BDRV_O_CACHE_DEF ; + } ret =bdrv_file_open (&s->hd, filename, flags);if (ret <0 )return ret;
block.h +2 -1
@@ -49,8 +49,9 @@bdrv_file_open()) */ #define BDRV_O_NOCACHE 0x0020/* do not use the host page cache */ #define BDRV_O_CACHE_WB 0x0040/* use write-back caching */ +#define BDRV_O_CACHE_DEF 0x0080/* use default caching */ -#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB) +#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_CACHE_DEF)void bdrv_info (void );void bdrv_info_stats (void );
Quoted 10 lines
[email protected]
Sent by: [email protected]qcow2 writes a cluster reference count on every cluster update. This causes performance to crater when using anything but cache=writeback. This is most noticeable when using savevm. Right now, qcow2 isn't a reliable format regardless of the type of cache your using because metadata is not updated in the correct order. Considering this, I think
Quoted 6 lines
it's somewhat reasonable to use writeback caching by default with qcow2 files.
It at least avoids the massive performance regression for users until we
sort out the issues in qcow2.
I applied it and tried 'delvm', 'savevm' and 'loadvm' and at least the performance problems went away. Thanks.
I see some other problems after restoring a VM and X11 not responding to keyboard inputs or Linux not shutting down properly. But these may be due to me making some experiments with the 'unreliable' features of qcow2.
Stefan
Quoted 32 lines
Regards,
Anthony Liguori
Index:vl.c
===================================================================vl.c (working copy) renamed from vl.c (revision 5751) +3
-1@@ -2225,7 +2225,7 @@ unit_id = -1; translation = BIOS_ATA_TRANSLATION_AUTO; index = -1; - cache = 1; + cache = 3; if (machine->use_scsi) { type = IF_SCSI;@@ -2496,6 +2496,8 @@ bdrv_flags |= BDRV_O_NOCACHE; else if (cache == 2) /* write-back */ bdrv_flags |= BDRV_O_CACHE_WB; + else if (cache == 3) /* not specified */ + bdrv_flags |= BDRV_O_CACHE_DEF; if (bdrv_open2(bdrv, file, bdrv_flags, drv) < 0 || qemu_key_check(bdrv, file)) { fprintf(stderr, "qemu: could not open disk image %s\n",file);Index: qemu-doc.texi
===================================================================
qemu-doc.texi (working copy) line 289
Quoted 1 line
qemu-doc.texi (working copy) renamed from qemu-doc.texi (revision 5751) +0
-0@@ -289,6 +289,12 @@ attempt to do disk IO directly to the guests memory. QEMU may still
perform
Quoted 8 lines
qemu-doc.texi (working copy) renamed from qemu-doc.texi (revision 5751) +3
-0an internal copy of the data. +Some block drivers perform badly with @option{cache=writethrough}, most notably, +qcow2. If performance is more important than correctness, +@option{cache=writeback} should be used with qcow2. By default, ifno explicit
+caching is specified for a qcow2 disk image, @option{cache=writeback}
will be
Quoted 1 line
+used. For all other disk types, @option{cache=writethrough} is the
default.
block-qcow2.c (working copy) line 192
Quoted 13 lines
+
Instead of @option{-cdrom} you can use:
@example
qemu -drive file=file,index=2,media=cdrom
Index:block-qcow2.c
===================================================================block-qcow2.c (working copy) renamed from block-qcow2.c (revision 5751) +1
-0@@ -189,6 +189,14 @@ int len, i, shift, ret; QCowHeader header; + /* Performance is terrible right now with cache=writethrough due
mainly
block-qcow2.c (working copy) line 193
Quoted 1 line
block-qcow2.c (working copy) renamed from block-qcow2.c (revision 5751) +1
-0+ * to reference count updates. If the user does not explicitly
specify
Quoted 25 lines
block-qcow2.c (working copy) renamed from block-qcow2.c (revision 5751) +6
-0+ * a caching type, force to writeback caching. + */ + if ((flags & BDRV_O_CACHE_DEF)) { + flags |= BDRV_O_CACHE_WB; + flags &= ~BDRV_O_CACHE_DEF; + } ret = bdrv_file_open(&s->hd, filename, flags); if (ret < 0) return ret;Index:
block.h
===================================================================block.h (working copy) renamed from block.h (revision 5751) +2
-1@@ -49,8 +49,9 @@ bdrv_file_open()) */ #define BDRV_O_NOCACHE 0x0020 /* do not use the host page cache */ #define BDRV_O_CACHE_WB 0x0040 /* use write-back caching */ +#define BDRV_O_CACHE_DEF 0x0080 /* use default caching */ -#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB) +#define BDRV_O_CACHE_MASK (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_CACHE_DEF) void bdrv_info(void);void
bdrv_info_stats(void);
Quoted 3 lines · Anthony Liguori
Right now, qcow2 isn't a
reliable format regardless of the type of cache your using because metadata is not updated in the correct order.
so you don't advise to use qcow2 as a VBD or what do you mean with "isn't reliable"?
or contrawise: on the other formats the metadata is updated in the correct order?
Quoted 7 lines · Thomas Mueller
Quoted 4 lines
Right now, qcow2 isn't a
reliable format regardless of the type of cache your using because metadata is not updated in the correct order.so you don't advise to use qcow2 as a VBD or what do you mean with "isn't reliable"?
Right, qcow2 is both very slow with cache=writethrough (or off), and may corrupt itself if the host crashes at the wrong moment.
Quoted 2 lines
or contrawise: on the other formats the metadata is updated in the correct order?
raw is the only format we're sure of.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Quoted 9 lines · Avi Kivity
Quoted 7 lines · Thomas Mueller
Quoted 3 lines
Right now, qcow2 isn't a
reliable format regardless of the type of cache your using because metadata is not updated in the correct order.so you don't advise to use qcow2 as a VBD or what do you mean with "isn't reliable"?
Quoted 8 lines
Right, qcow2 is both very slow with cache=writethrough (or off), and may corrupt itself if the host crashes at the wrong moment.
Quoted 3 lines
or contrawise: on the other formats the metadata is updated in the correct order?
raw is the only format we're sure of.
With that in mind I converted my qcow2 image to raw, and I'm trying to use that as a base image to create a new raw (writeable) image:
#qemu-img create -b vista.raw vista.delta
Formatting 'vista.delta', fmt=raw, backing_file=vista.raw, size=20971520 kB
qemu-img: Formatting or formatting option not supported for file format 'raw'
Doesn't that seem like a bug? Do people just not use raw images in this way?
Thanks.
Quoted 11 lines
Quoted 7 lines
Quoted 6 lines
or contrawise: on the other formats the metadata is updated in the correct order?
raw is the only format we're sure of.
With that in mind I converted my qcow2 image to raw, and I'm trying to use that as a base image to create a new raw (writeable) image:
Quoted 6 lines
#qemu-img create -b vista.raw vista.delta Formatting 'vista.delta', fmt=raw, backing_file=vista.raw, size=20971520 kB qemu-img: Formatting or formatting option not supported for file format 'raw'
Doesn't that seem like a bug? Do people just not use raw images in this way?
you can only use a backing file with qcow2 IMHO. also snapshots (savevm/ loadvm) work only with qcow2.
- Thomas