From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsyZr-0003Fr-4m for qemu-devel@nongnu.org; Wed, 09 Jan 2013 11:32:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsyZp-0000VR-Ng for qemu-devel@nongnu.org; Wed, 09 Jan 2013 11:32:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsyZp-0000VJ-GG for qemu-devel@nongnu.org; Wed, 09 Jan 2013 11:32:29 -0500 Message-ID: <50ED9B92.6080303@redhat.com> Date: Wed, 09 Jan 2013 09:32:18 -0700 From: Eric Blake MIME-Version: 1.0 References: <20130109152443.GB3494@irqsave.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2E13256ED0188ED126C1B572" Subject: Re: [Qemu-devel] QCOW2 deduplication design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Paolo Bonzini , Stefan Hajnoczi , qemu-devel , efcount.@irqsave.net This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E13256ED0188ED126C1B572 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/09/2013 09:16 AM, Stefan Hajnoczi wrote: >> I.6) max refcount reached >> The L2 hash block of the cluster is written in order to remember at ne= xt startup >> that it must not be used anymore for deduplication. The hash is droppe= d from the >> gtrees. >=20 > Interesting case. This means you can no longer take snapshots > containing this cluster because we cannot track references :(. >=20 > Worst case: guest fills the disk with the same 4 KB data (e.g. > zeroes). There is only a single data cluster but the refcount is > maxed out. Now it is not possible to take a snapshot. Except that a sector of all zeroes should be represented as a hole, rather than occupying a cluster (that is, since all zeros is the most likely value for a very common data, but also has a special case representation that doesn't take any clusters at all, we should take advantage of that). But your point remains for a disk that reuses another common 4KB cluster more than the refcount allows (for example, how many copies of COPYING do you have on your disk?). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2E13256ED0188ED126C1B572 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.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQ7ZuSAAoJEKeha0olJ0NqSZgIAIlCnzktpitp0vxpLy7uK7o5 JPiDgPgzztw3AoZ6vMhiKNLhxkVy6H9LsSjjAeTYFCJDq2dkLCobMn8TbYQboj6Y vdVGyTxfwK+OwuUtVe2ltOPpTmddbbD8Khtr4PD0V3qzHROLCIHGemylAc/3usn8 FLHpvv3IZbg+pDnN0+v2TfWgW8i0MmH+KDbSz9JerOKocXV2u3KaDTNJvz66cicT Z4LbwPczTuVy2Y3TJkX+JwUy/lvXSEX7WYAR+JTB3jYvhiW6x7yOtfX5pYxIDIq/ 7wh4WNdpWCFe5D0zIbSWrLFGZhGlcc8yJVdQvk9Bs1eGphuNYIQIE8o4uwjIqlk= =3wEn -----END PGP SIGNATURE----- --------------enig2E13256ED0188ED126C1B572--