From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50038) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlc2Z-00039Z-IP for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:08:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vlc2N-0005On-Tf for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:08:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vlc2N-0005Oa-Kj for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:08:03 -0500 Message-ID: <5295C474.4080002@redhat.com> Date: Wed, 27 Nov 2013 18:07:48 +0800 From: Fam Zheng MIME-Version: 1.0 References: <52956083.5000409@redhat.com> <20131127060109.GG24296@G08FNSTD100614.fnst.cn.fujitsu.com> <529593C5.5060003@redhat.com> <5295C37F.40703@kamp.de> In-Reply-To: <5295C37F.40703@kamp.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v2 5/6] qcow2: implement bdrv_preallocate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , Hu Tao , qemu-devel@nongnu.org On 2013=E5=B9=B411=E6=9C=8827=E6=97=A5 18:03, Peter Lieven wrote: > Am 27.11.2013 07:40, schrieb Fam Zheng: >> On 2013=E5=B9=B411=E6=9C=8827=E6=97=A5 14:01, Hu Tao wrote: >>> On Wed, Nov 27, 2013 at 11:01:23AM +0800, Fam Zheng wrote: >>>> On 2013=E5=B9=B411=E6=9C=8827=E6=97=A5 10:15, Hu Tao wrote: >>>>> Signed-off-by: Hu Tao >>>>> --- >>>>> block/qcow2.c | 7 +++++++ >>>>> 1 file changed, 7 insertions(+) >>>>> >>>>> diff --git a/block/qcow2.c b/block/qcow2.c >>>>> index b054a01..a23fade 100644 >>>>> --- a/block/qcow2.c >>>>> +++ b/block/qcow2.c >>>>> @@ -2180,6 +2180,12 @@ static int qcow2_amend_options(BlockDriverSt= ate *bs, >>>>> return 0; >>>>> } >>>>> >>>>> +static int qcow2_preallocate(BlockDriverState *bs, int64_t offset, >>>>> + int64_t length) >>>>> +{ >>>>> + return bdrv_preallocate(bs->file, offset, length); >>>>> +} >>>>> + >>>> >>>> What's the semantics of .bdrv_preallocate? I think you should map >>>> [offset, offset + length) to clusters in image file, and then >>>> forward to bs->file, rather than this direct wrapper. >>>> >>>> E.g. bdrv_preallocate(qcow2_bs, 0, cluster_size) should call >>>> bdrv_preallocate(qcow2_bs->file, offset_off_first_cluster, >>>> cluster_size). >>> >>> You mean data clusters here, right? Is there a single function to get >>> the offset of the first data cluster? >>> >> >> There is a function, qcow2_get_cluster_offset. > This should return no valid offset as long as the cluster is not alloca= ted. > > I think you actually have to "write" all clusters of a qcow2 one by one. > Eventually this write could be an fallocate call instead of a zero writ= e. > Yes, I was wrong about qcow2_get_cluster_offset. The logic here is more=20 like cluster allocation in qcow2_alloc_cluster_offset. Maybe we can=20 reuse that. Fam