From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XswwR-0000Ws-1W for qemu-devel@nongnu.org; Mon, 24 Nov 2014 11:56:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XswwM-0000Ti-1u for qemu-devel@nongnu.org; Mon, 24 Nov 2014 11:56:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XswwL-0000Sq-QJ for qemu-devel@nongnu.org; Mon, 24 Nov 2014 11:56:41 -0500 Message-ID: <54736340.6030003@redhat.com> Date: Mon, 24 Nov 2014 09:56:32 -0700 From: Eric Blake MIME-Version: 1.0 References: <1416844620-17717-1-git-send-email-mreitz@redhat.com> In-Reply-To: <1416844620-17717-1-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G0EaoeSVOuu9Pjh41tx03vVisfP3iR2Fd" Subject: Re: [Qemu-devel] [PATCH v2 00/12] qcow2: Add new overlap check functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Lieven , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G0EaoeSVOuu9Pjh41tx03vVisfP3iR2Fd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 lef= t > for you to decide, dear reviewers. >=20 >=20 > 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. >=20 > tl;dr > =3D=3D=3D=3D=3D >=20 > * 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.) >=20 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). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --G0EaoeSVOuu9Pjh41tx03vVisfP3iR2Fd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUc2NAAAoJEKeha0olJ0NqyRQH/29iQZCKU+zDRFvagC+gzhjI tn/ELLKS9jKEhxaBu+g/fe/hL2EJujCG1ufy14JsbkiKaUekhxGkhMQN/+feNd7r MD4dDelOWLkiCkINREWb2p9l3GiS0V05KcSEvAx2ksq4kb0n6X4I55sby06bURms aXe5M9hG+V+60ptcD0yYPIRK2IJg/dnll2dA7wVBExifyj1asQU1IXSGm/ovan3z kiMW0fjktmXssCS+iTFETvOE2F1c9eRvDocCVv6GPL6S91hGTwG7WyOPKrL/BjvR WUuXEXHKcF7btq6f3r7wKZN7VsnKJDAYbzQK91iljFLdp1HqpwgP+2YFs0wjrkQ= =GY+5 -----END PGP SIGNATURE----- --G0EaoeSVOuu9Pjh41tx03vVisfP3iR2Fd--