From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcFAd-0008JF-HS for qemu-devel@nongnu.org; Thu, 09 Oct 2014 10:58:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XcFAX-0001Nw-MV for qemu-devel@nongnu.org; Thu, 09 Oct 2014 10:58:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31960) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcFAX-0001No-Es for qemu-devel@nongnu.org; Thu, 09 Oct 2014 10:58:17 -0400 Message-ID: <5436A286.30704@redhat.com> Date: Thu, 09 Oct 2014 08:58:14 -0600 From: Eric Blake MIME-Version: 1.0 References: <201410091917519618804@sangfor.com> In-Reply-To: <201410091917519618804@sangfor.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ffp6EfXnTewM6pvILgICnGbcUaqBuxFG6" Subject: Re: [Qemu-devel] [question] is it posssible that big-endian l1 table offset referenced by other I/O while updating l1 table offset in qcow2_update_snapshot_refcount? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhang Haoyu , qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ffp6EfXnTewM6pvILgICnGbcUaqBuxFG6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/09/2014 05:17 AM, Zhang Haoyu wrote: > Hi, > I encounter a problem that after deleting snaptshot, the qcow2 image si= ze is very larger than that it should be displayed by ls command,=20 > but the virtual disk size is okay via qemu-img info. > I suspect that during updating l1 table offset, other I/O job reference= the big-endian l1 table offset (very large value), so the file is trunca= ted to very large. Not quite. Rather, all the data that the snapshot used to occupy is still consuming holes in the file; the maximum offset of the file is still unchanged, even if the file is no longer using as many referenced clusters. Recent changes have gone in to sparsify the file when possible (punching holes if your kernel and file system is new enough to support that), so that it is not consuming the amount of disk space that a mere ls reports. But if what you are asking for is a way to compact the file back down, then you'll need to submit a patch. The idea of having an online defragmenter for qcow2 files has been kicked around before, but it is complex enough that no one has attempted a patch yet. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ffp6EfXnTewM6pvILgICnGbcUaqBuxFG6 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 iQEcBAEBCAAGBQJUNqKGAAoJEKeha0olJ0NqXckH/Rs6kYZh3wXS5yZondUJ07oO FFyRldweZZLdodacPzGdv4iQfDXrXr+AulQj+R/S9Ag+AyS/cczeAv4Q2/Jj0lXU 1yjhGXaPHI/OPnbOoSXqForY0IIvdM73kth2gkr7+lo85PQgkVkQle0JL7MK1Cwp 67aCpd8AqV6ox8F+8wCvKJdWMoacYa/bRzXuC/7s8xEL6YATTZk1H7EcRoF6UCNZ ijDHynNsFoDYIPCTVPhIf+PWykj8BsJSB42n3iQx1dEmxoMNWv3I6vHh0fLyj/QC iHTTF9O+8tBp6ha8DMkFSCKJ+Q6JcL3RHy0T6T9gkTRjUVfKP+TMSJYr3hVZ4pA= =VhxF -----END PGP SIGNATURE----- --ffp6EfXnTewM6pvILgICnGbcUaqBuxFG6--