* [Qemu-devel] [PATCH v2] qcow2: Flush image after creation
@ 2013-10-24 18:35 Max Reitz
2013-10-25 9:15 ` Kevin Wolf
2013-10-28 15:10 ` Benoît Canet
0 siblings, 2 replies; 3+ messages in thread
From: Max Reitz @ 2013-10-24 18:35 UTC (permalink / raw)
To: qemu-devel; +Cc: Kevin Wolf, Stefan Hajnoczi, Max Reitz
Opening the qcow2 image with BDRV_O_NO_FLUSH prevents any flushes during
the image creation. This means that the image has not yet been flushed
to disk when qemu-img create exits. This flush is delayed until the next
operation on the image involving opening it without BDRV_O_NO_FLUSH and
closing (or directly flushing) it. For large images and/or images with a
small cluster size and preallocated metadata, this flush may take a
significant amount of time and may occur unexpectedly.
Reopening the image without BDRV_O_NO_FLUSH right before the end of
qcow2_create2() results in hoisting the potentially costly flush into
the image creation, which is expected to take some time (whereas
successive image operations may be not).
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
v2:
- implemented Kevin's remarks:
- left ret = 0; in the code
- added goto out; in error handling of bdrv_open
- implemented Eric's remarks:
- changed indentation of bdrv_open arguments
- s/preponing/hoisting/ in the commit message
---
block/qcow2.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/block/qcow2.c b/block/qcow2.c
index 01269f9..6e5d98d 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1584,6 +1584,16 @@ static int qcow2_create2(const char *filename, int64_t total_size,
}
}
+ bdrv_close(bs);
+
+ /* Reopen the image without BDRV_O_NO_FLUSH to flush it before returning */
+ ret = bdrv_open(bs, filename, NULL,
+ BDRV_O_RDWR | BDRV_O_CACHE_WB, drv, &local_err);
+ if (error_is_set(&local_err)) {
+ error_propagate(errp, local_err);
+ goto out;
+ }
+
ret = 0;
out:
bdrv_unref(bs);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qcow2: Flush image after creation
2013-10-24 18:35 [Qemu-devel] [PATCH v2] qcow2: Flush image after creation Max Reitz
@ 2013-10-25 9:15 ` Kevin Wolf
2013-10-28 15:10 ` Benoît Canet
1 sibling, 0 replies; 3+ messages in thread
From: Kevin Wolf @ 2013-10-25 9:15 UTC (permalink / raw)
To: Max Reitz; +Cc: qemu-devel, Stefan Hajnoczi
Am 24.10.2013 um 20:35 hat Max Reitz geschrieben:
> Opening the qcow2 image with BDRV_O_NO_FLUSH prevents any flushes during
> the image creation. This means that the image has not yet been flushed
> to disk when qemu-img create exits. This flush is delayed until the next
> operation on the image involving opening it without BDRV_O_NO_FLUSH and
> closing (or directly flushing) it. For large images and/or images with a
> small cluster size and preallocated metadata, this flush may take a
> significant amount of time and may occur unexpectedly.
>
> Reopening the image without BDRV_O_NO_FLUSH right before the end of
> qcow2_create2() results in hoisting the potentially costly flush into
> the image creation, which is expected to take some time (whereas
> successive image operations may be not).
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
Thanks, applied to the block branch.
Kevin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qcow2: Flush image after creation
2013-10-24 18:35 [Qemu-devel] [PATCH v2] qcow2: Flush image after creation Max Reitz
2013-10-25 9:15 ` Kevin Wolf
@ 2013-10-28 15:10 ` Benoît Canet
1 sibling, 0 replies; 3+ messages in thread
From: Benoît Canet @ 2013-10-28 15:10 UTC (permalink / raw)
To: Max Reitz; +Cc: Kevin Wolf, qemu-devel, Stefan Hajnoczi
Le Thursday 24 Oct 2013 à 20:35:06 (+0200), Max Reitz a écrit :
> Opening the qcow2 image with BDRV_O_NO_FLUSH prevents any flushes during
> the image creation. This means that the image has not yet been flushed
> to disk when qemu-img create exits. This flush is delayed until the next
> operation on the image involving opening it without BDRV_O_NO_FLUSH and
> closing (or directly flushing) it. For large images and/or images with a
> small cluster size and preallocated metadata, this flush may take a
> significant amount of time and may occur unexpectedly.
>
> Reopening the image without BDRV_O_NO_FLUSH right before the end of
> qcow2_create2() results in hoisting the potentially costly flush into
> the image creation, which is expected to take some time (whereas
> successive image operations may be not).
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> Reviewed-by: Eric Blake <eblake@redhat.com>
> ---
> v2:
> - implemented Kevin's remarks:
> - left ret = 0; in the code
> - added goto out; in error handling of bdrv_open
> - implemented Eric's remarks:
> - changed indentation of bdrv_open arguments
> - s/preponing/hoisting/ in the commit message
> ---
> block/qcow2.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 01269f9..6e5d98d 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -1584,6 +1584,16 @@ static int qcow2_create2(const char *filename, int64_t total_size,
> }
> }
>
> + bdrv_close(bs);
> +
> + /* Reopen the image without BDRV_O_NO_FLUSH to flush it before returning */
> + ret = bdrv_open(bs, filename, NULL,
> + BDRV_O_RDWR | BDRV_O_CACHE_WB, drv, &local_err);
> + if (error_is_set(&local_err)) {
> + error_propagate(errp, local_err);
> + goto out;
> + }
> +
> ret = 0;
> out:
> bdrv_unref(bs);
> --
> 1.8.3.1
>
>
Reviewed-by: Benoit Canet <benoit@irqsave.net>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-10-28 15:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-24 18:35 [Qemu-devel] [PATCH v2] qcow2: Flush image after creation Max Reitz
2013-10-25 9:15 ` Kevin Wolf
2013-10-28 15:10 ` Benoît Canet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).