qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 07/12] qemu-img: Empty images after commit


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]