From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxOnD-0002Sv-AD for qemu-devel@nongnu.org; Thu, 20 Oct 2016 21:38:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxOnC-00014j-FV for qemu-devel@nongnu.org; Thu, 20 Oct 2016 21:38:43 -0400 References: From: Eric Blake Message-ID: <8b945cd9-a601-4c81-495f-c1837f8d8231@redhat.com> Date: Thu, 20 Oct 2016 20:38:34 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ehSXNx5BNREuBU6vDIC6kiaq32DKhhVjK" Subject: Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ed Swierk , qemu-block@nongnu.org, qemu-devel@nongnu.org Cc: Kevin Wolf , "Denis V. Lunev" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ehSXNx5BNREuBU6vDIC6kiaq32DKhhVjK From: Eric Blake To: Ed Swierk , qemu-block@nongnu.org, qemu-devel@nongnu.org Cc: Kevin Wolf , "Denis V. Lunev" Message-ID: <8b945cd9-a601-4c81-495f-c1837f8d8231@redhat.com> Subject: Re: [Qemu-devel] Assertion failure on qcow2 disk with cluster_size != 64k References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/20/2016 07:24 PM, Ed Swierk wrote: > Shortly after I start qemu 2.7.0 with a qcow2 disk image created with > -o cluster_size=3D1048576, it prints the following and dies: >=20 > block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=3D= > s->cluster_size' failed. >=20 > I narrowed the problem to bdrv_co_do_pwrite_zeroes(), called by > bdrv_aligned_pwritev() with flags & BDRV_REQ_ZERO_WRITE set. >=20 > On the first loop iteration, offset=3D8003584, count=3D2093056, > head=3D663552, tail=3D659456 and num=3D2093056. qcow2_co_pwrite_zeroes(= ) is > called with offset=3D8003584 and count=3D385024 and finds that the head= > portion is not already zero, so it returns -ENOTSUP. > bdrv_co_do_pwrite_zeroes() falls back to a normal write, with > max_transfer=3D65536. Ah. When the cluster is larger than 64k, we HAVE to handle the entire cluster in one operation, or else the head occupies more than one 'sector' while the assert is that at most 'sector' is unaligned. >=20 > The next iteration starts with offset incremented by 65536, count and > num decremented by 65536, and head=3D0, violating the assumption that > the entire 385024 bytes of the head remainder had been zeroed the > first time around. Then it calls qcow2_co_pwrite_zeroes() with an > unaligned offset=3D8069120 and a count=3D1368064 greater than the clust= er > size, triggering the assertion failure. >=20 > Changing max_transfer in the normal write case to > MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix > the problem, but I don't pretend to understand all the subtleties > here. That actually sounds like the right fix. But since the bug was probably caused by my code, I'll formalize it into a patch and see if I can modify the testsuite to give it coverage. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ehSXNx5BNREuBU6vDIC6kiaq32DKhhVjK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYCXGaAAoJEKeha0olJ0Nqi5YH/1H0jK3Z/wtXSG9/8j7BZFS5 UyZJZt+R4wjvmh0bqaqC2+7I4nM1bA/XF1pfF24ReAK7jWYMXKais6Mu418oCydR PpCiOVo3M//LpCkBOR8XNa+9WoB9hfLEODmyuWYtNO/7/bOyoaDif3h3KeuyV5Q2 HjjLFHqvkEFrLIbtI9accWsVEuWmo4sUr83adgQryof4n3U1j466zGG+nHiEOoJx vGruN+mFsYJVroJztFWz69wAH+VZgkiUTA9ldmPUXeKQPF/Ny+yYJBaq+PpICUhy t+ISctztBc7Mk6mFSDWbY+6qK2ghcf0wYi/4Gq3znIZQF0GvzHAR7M4tbbgFtQI= =bgj7 -----END PGP SIGNATURE----- --ehSXNx5BNREuBU6vDIC6kiaq32DKhhVjK--