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
