|
From: | Max Reitz |
Subject: | Re: [Qemu-devel] [PATCH v5 07/12] qemu-img: Empty images after commit |
Date: | Thu, 24 Apr 2014 16:54:43 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 |
On 23.04.2014 11:32, Kevin Wolf wrote:
Am 22.04.2014 um 18:22 hat Max Reitz geschrieben:On 22.04.2014 17:19, Eric Blake wrote:On 04/17/2014 03:59 PM, Max Reitz wrote:After the top image has been committed into an image in its backing chain, all images above that base image should be emptied to restore the old qemu-img commit behavior. Signed-off-by: Max Reitz <address@hidden> --- qemu-img.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 84 insertions(+), 3 deletions(-)Does emptying an image take significant time? If so, does that need to be reflected in the progress meter?For a 16 GB image I have here (should be nearly full) it took 1:22 min. Copying it took six minutes, so I guess committing it would take even more. I think the ratio is small enough not to include it in the progress meter.Did you check why it took that long? Sounds like we're issuing a lot of independent discard requests instead of few big ones. Is the image heavily fragmented?
Indeed it is, judging from qemu-img map. Max
Furthermore, I don't see a reasonable implementation for a make_empty progress output: As a general implementation for all image formats implementing discard will not work (the qcow2 implementation clearly states that discarded sectors should read back as zero)We can always add new flags or a separate new callback if it improves things. Kevin
[Prev in Thread] | Current Thread | [Next in Thread] |