Re: [Qemu-devel] [PATCH v2 00/12] qcow2: Add new overlap check functions

[Eric Blake]

On 11/24/2014 08:56 AM, Max Reitz wrote:
> As has been requested, this series adds new overlap check functions to
> the qcow2 code. My local branch is called "qcow2-improved-overlap-v1",
> but I am not so sure whether it is actually an improvement; that is left
> for you to decide, dear reviewers.
> 

> 
> The problem with this series is obviously that all the metadata
> information is read when reading a qcow2 image. iotest 044 is a good
> test for this. I personally haven't seen a problem here, but I can't
> outrule any. I never noticed any waits when opening images.

I have another reason for WANTING to read the qcow2 metadata up front
when opening an image.  Right now, the 'query-blockstats' QMP command
reports a wr_highest_offset field (I don't know if it has any decent use
besides for qcow2 images on raw block devices, but it was part of the
design long before we had image-specific stats).  However, this field is
ALWAYS reported as 0 for backing images in a chain when qemu first
boots, because the current code base does not update the field UNTIL the
first allocating write to a file (whether that is a data write, or
whether it is something metadata-only such as creating and destroying a
temporary internal snapshot).  When doing a block commit operation, the
field becomes useful for predicting how fast the backing qcow2 file is
growing as part of the commit operation - but since the field starts
life at 0 instead of the real size of the file, it leads to some very
awkward startup code.  If we parse all qcow2 metadata up front when
opening a file, then we trivially have the correct wr_highest_offset
instead of 0, even for a read-only image.


> 
> tl;dr
> =====
> 
> * CPU usage at runtime decreased by 150 to 275 percent on
>   overlap-check-heavy tasks
> * No additional performance problems at loading time (in theory has the
>   same runtime complexity as a single overlap check right now; in
>   practice I could not find any problems)
> * Decent RAM usage (40 kB for a 1 TB image with 64 kB clusters; 40 MB
>   for a 1 PB image etc. pp.)
> 

Sounds reasonable to me.  Although I'm not sure if it counts as a bug
fix, so I'm not sure if we should try to rush it into 2.2 (yes,
performance CAN be a bug, but it is late to be adding complex code).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature