From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6SJx-0000yW-8P for qemu-devel@nongnu.org; Thu, 23 Jan 2014 17:00:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6SJs-0005TS-0m for qemu-devel@nongnu.org; Thu, 23 Jan 2014 17:00:21 -0500 Received: from paradis.irqsave.net ([62.212.105.220]:48196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6SJr-0005T1-MV for qemu-devel@nongnu.org; Thu, 23 Jan 2014 17:00:15 -0500 Date: Thu, 23 Jan 2014 23:00:14 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140123220014.GC22578@irqsave.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 1/3] block: resize backing file image during offline commit, if necessary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Le Thursday 23 Jan 2014 =E0 16:48:55 (-0500), Jeff Cody a =E9crit : > Currently, if an image file is logically larger than its backing file, > commiting it via 'qemu-img commit' will fail. >=20 > For instance, if we have a base image with a virtual size 10G, and a > snapshot image of size 20G, then committing the snapshot offline with > 'qemu-img commit' will likely fail. >=20 > This will automatically attempt to resize the base image, if the > snapshot image to be committed is larger. >=20 > Signed-off-by: Jeff Cody > Reviewed-by: Fam Zheng > Reviewed-by: Eric Blake > --- > block.c | 23 ++++++++++++++++++++--- > 1 file changed, 20 insertions(+), 3 deletions(-) >=20 > diff --git a/block.c b/block.c > index 64e7d22..dea7591 100644 > --- a/block.c > +++ b/block.c > @@ -1876,10 +1876,10 @@ int bdrv_check(BlockDriverState *bs, BdrvCheckR= esult *res, BdrvCheckMode fix) > int bdrv_commit(BlockDriverState *bs) > { > BlockDriver *drv =3D bs->drv; > - int64_t sector, total_sectors; > + int64_t sector, total_sectors, length, backing_length; > int n, ro, open_flags; > int ret =3D 0; > - uint8_t *buf; > + uint8_t *buf =3D NULL; Why assign NULL to buf ? Is it related to the rest of the patch ? Reviewed-by: Benoit Canet > char filename[PATH_MAX]; > =20 > if (!drv) > @@ -1904,7 +1904,24 @@ int bdrv_commit(BlockDriverState *bs) > } > } > =20 > - total_sectors =3D bdrv_getlength(bs) >> BDRV_SECTOR_BITS; > + length =3D bdrv_getlength(bs); > + backing_length =3D bdrv_getlength(bs->backing_hd); > + > + if (length < 0 || backing_length < 0) { > + goto ro_cleanup; > + } > + > + /* If our top snapshot is larger than the backing file image, > + * grow the backing file image if possible. If not possible, > + * we must return an error */ > + if (length > backing_length) { > + ret =3D bdrv_truncate(bs->backing_hd, length); > + if (ret < 0) { > + goto ro_cleanup; > + } > + } > + > + total_sectors =3D length >> BDRV_SECTOR_BITS; > buf =3D g_malloc(COMMIT_BUF_SECTORS * BDRV_SECTOR_SIZE); > =20 > for (sector =3D 0; sector < total_sectors; sector +=3D n) { > --=20 > 1.8.3.1 >=20 >=20