From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFIOS-0001Ps-Td for qemu-devel@nongnu.org; Wed, 15 Jul 2015 04:50:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFIOR-0006EV-T2 for qemu-devel@nongnu.org; Wed, 15 Jul 2015 04:50:20 -0400 Date: Wed, 15 Jul 2015 10:50:09 +0200 From: Kevin Wolf Message-ID: <20150715085009.GA3582@noname.redhat.com> References: <1310916852.125556.1436925467887.JavaMail.weblogic@mdmob08> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1310916852.125556.1436925467887.JavaMail.weblogic@mdmob08> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] =?utf-8?q?=5BQemu-block=5D=5BPATCH=5Dblock/truncate?= =?utf-8?q?=3A_qcow2=E2=80=99s__resize_status_is_not_showed_to?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?6rmA7YOc7ZWY?= Cc: kthguru@gmail.net, qemu-devel@nongnu.org, qemu-block@nongnu.org Am 15.07.2015 um 03:57 hat =EA=B9=80=ED=83=9C=ED=95=98 geschrieben: > To put it briefly, when resize qcow2 image, the "file" tool detected in= creased > size. However, the "ls", =E2=80=9Cstat=E2=80=9D, and =E2=80=9Cdu=E2=80=9D= utility still don't know increased > size. The following patch enables to let userland tools - ls, du, stat = - know > and apply changed size after resizing qcow2 image created by the qemu-i= mg tool. > Currently, can know only using =E2=80=9Cfile=E2=80=9D utility without t= his patch. Even your goal is already wrong. For any image format other than raw, the file size doesn't represent the virtual disk size. It's just the size that the image file actually takes on the host, and that's something entirely different. The correct way to check the virtual disk size is 'qemu-img info'. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Signed-off-by: Taeha Kim >=20 > diff --git a/block.c b/block.c > index 5e80336..277adf3 100644 > --- a/block.c > +++ b/block.c > @@ -2473,6 +2473,9 @@ int bdrv_truncate(BlockDriverState *bs, int64_t o= ffset) > if (bs->blk) { > blk_dev_resize_cb(bs->blk); > } > + if (ret =3D=3D 0) { > + ret =3D truncate(bs->filename, offset); > + } > } > return ret; > } Even if your goal were right, this wouldn't work because images don't have to be local files. And to be clear: Truncating the image file is not only misguided and unnecessary, but it will actively corrupt image files, because qcow2 images can be larger than the virtual disk size (e.g. if you have taken some snapshots). In this case you would destroy the image by throwing away part of it. Kevin