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 <mre...@redhat.com> > >>>>--- > >>>> 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
