[Top][All Lists]

[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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v5 07/12] qemu-img: Empty images after commit
Date: Wed, 23 Apr 2014 11:32:37 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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?

> 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


reply via email to

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