From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoHRU-00006L-D6 for qemu-devel@nongnu.org; Tue, 11 Nov 2014 14:49:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoHRP-0001cj-ER for qemu-devel@nongnu.org; Tue, 11 Nov 2014 14:49:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoHRP-0001cZ-6F for qemu-devel@nongnu.org; Tue, 11 Nov 2014 14:49:27 -0500 Message-ID: <5462683E.9000206@redhat.com> Date: Tue, 11 Nov 2014 12:49:18 -0700 From: Eric Blake MIME-Version: 1.0 References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-6-git-send-email-mreitz@redhat.com> <54612A27.7000801@redhat.com> <5461C751.3080607@redhat.com> <5462359D.4040503@redhat.com> <546236CD.30301@redhat.com> In-Reply-To: <546236CD.30301@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0iMGkQT7LVUHG3ax3p7OagxUOlmiIbq5M" Subject: Re: [Qemu-devel] [PATCH 05/21] qcow2: Refcount overflow and qcow2_alloc_bytes() 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) --0iMGkQT7LVUHG3ax3p7OagxUOlmiIbq5M Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2014 09:18 AM, Max Reitz wrote: >> No, I was envisioning that we have a brand new image with one cluster >> allocated (cluster 1 has refcount 1), then 5 times in a row we do >> 'savevm' to take an internal snapshot. If I understand your code >> correctly, the first two snapshots increase the refcount, so cluster 1= >> has a refcount of 3. Then the next snapshot can't increase the refcoun= t, >> so it instead copies the contents to cluster 2. >=20 > No, it just errors out. >=20 > qcow2_alloc_bytes() is only used for allocating space for a compressed > cluster. When taking a snapshot, update_refcount() will be called to > increase the clusters' refcounts, and that function will simply throw a= n > error. That's okay for now (always better for an initial feature to be conservative, then expand it later if there is demand). But I wonder if we could be made smarter in the future and auto-COW any cluster that would otherwise exceed max refcount. Thus, for a refcount_order=3D0 (width=3D1) image, a snapshot now doubles the size of the image (as every= single cluster would COW into a new cluster) rather than erroring out. Food for thought; maybe worth injecting comments into this series (whether in code or in commit messages, as appropriate) pointing out that we thought about the future possibility even though we chose not to allow it for now. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0iMGkQT7LVUHG3ax3p7OagxUOlmiIbq5M 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 iQEcBAEBCAAGBQJUYmg+AAoJEKeha0olJ0NqW9kH/0Hzxydgm82sMiCC5NyGnrC9 3mjP6xTPd9W8krYDLvQUSoO3jXaLohyUbK/G8E1hujCG+YANesOXw1x38hFeR04X LRLWXnKwj3LN1PFrovtV1qzuZrjva18XO9Qy/0iEYkGRssttw1lPIiiDoAC2ZvdA XujR3PEW7z4EmnPzcddts+lHtLXpjbq7zP5NeNPtQlJjc6iflnLD4ohmqQHKCJsb oSw9XzhHGxzs0xU1HeZneeOpnVBUA+af6NyDLGhICY1lQ+NT4OgRiQG9I9hIVhie KehjgUHsT8P83HbgHSozuBVi0Mt9Xn2py8x1bBT5JgmFpwDxg0gzNpbgZAX7YTc= =dFV2 -----END PGP SIGNATURE----- --0iMGkQT7LVUHG3ax3p7OagxUOlmiIbq5M--