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

Am 24.04.2014 um 16:54 hat Max Reitz geschrieben:
> 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.

I see. But even that should be handled by the discard caching mechanism
in qcow2, so that it should still merge most requests, even if it has to
issue a few separate ones. I think some more in-depth debugging wouldn't
hurt.

Kevin



reply via email to

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