From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqpT-0002WM-0q for qemu-devel@nongnu.org; Wed, 06 Jan 2016 11:20:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGqpO-0007uh-0v for qemu-devel@nongnu.org; Wed, 06 Jan 2016 11:20:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGqpN-0007uc-RV for qemu-devel@nongnu.org; Wed, 06 Jan 2016 11:20:49 -0500 References: <6ca84848.f052.15211b20317.Coremail.magazine.lihuiba@163.com> <568BCB6C.7010709@redhat.com> <557a47a5.3564.15214d76e2e.Coremail.magazine.lihuiba@163.com> <568D2D00.3050600@redhat.com> From: Max Reitz Message-ID: <568D3EDD.1090205@redhat.com> Date: Wed, 6 Jan 2016 17:20:45 +0100 MIME-Version: 1.0 In-Reply-To: <568D2D00.3050600@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NrqtVhOimlVATEUGoie8nqX1sLoO42bed" Subject: Re: [Qemu-devel] qcow2 snapshot + resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , lihuiba Cc: "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NrqtVhOimlVATEUGoie8nqX1sLoO42bed Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06.01.2016 16:04, Eric Blake wrote: > On 01/05/2016 07:50 PM, lihuiba wrote: >> At 2016-01-05 21:55:56, "Eric Blake" wrote: >>> On 01/05/2016 05:10 AM, lihuiba wrote: >>> >>>>>> In our production environment, we need to extend a qcow2 image wit= h >>>>>> snapshots in it. >>> >>>>> The thing is that one would need to update all the inactive L1 tabl= es. I >>>>> don't think it should be too difficult, it's just that apparently s= o far >>>>> nobody ever had the need for this feature. >>> >>> Is resizing a snapshot really what you want? Ideally, a snapshot tra= cks >>> the data from a point in time, including the metadata of the size bei= ng >>> tracked at that time. Extending the snapshots then reverting to that= >>> snapshot means your guest would see a larger disk on revert than it d= id >>> at the time the snapshot was created, which guests might not handle v= ery >>> well. >> I want to make resizing (extending only) and snapshot independent to e= ach other,otherwise going back and forth in snapshots may cause the disk = shrinked and extended. That would introduce some technical trouble, and p= ossibly confuse user as well. >=20 > If I take a snapshot while the guest sees a 1G disk, then resize the > disk to 2G, then roll back to the point in time of the snapshot, I'd > expect the disk to roll back to 1G in size. Anything else is likely to= > confuse the guest. And that's what current resize support already does= > (it only resizes the active image, not the snapshots). No, the current resize operation just refuses to resize the image if it has any snapshots. Snapshots currently do not store the size of the image when they were created. Max --NrqtVhOimlVATEUGoie8nqX1sLoO42bed 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 iQEcBAEBCAAGBQJWjT7dAAoJEDuxQgLoOKyt9wEH+gO6gVu6e8N1aZEFDc4Jw4r3 zrP4yH3wnaZsqwst6Rfmof1gOfqgY+AdHX8PML+syj3zNYWiLauyrKz+SNNAOEvT T0v7k+p5vEOuZ5e7nVtNXXSSqKCyf6srwBGLPd0MoALzd+jir+XggTst3enWpciO wgCM1m+uEsMfQVVOawpIRS5akwq4QvDyu1f8YKW8uffXj8PMAJk8KbT2Ch/J7QlY 5kR6KbG7gO/+38k20n9srWbvZUs/OA6japNP7CiEmp503LxlOBrE3D33QDXJuVX5 F2kR7nH55iny7gOelwocWO5e7pAPpivF3RBTJqbK5gXoS6pY6g/B6GP9RtjRoU0= =ppI/ -----END PGP SIGNATURE----- --NrqtVhOimlVATEUGoie8nqX1sLoO42bed--