From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlbyU-0000W0-R8 for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:04:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlbyP-0004HD-QJ for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:04:02 -0500 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:32942 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlbyP-0004H4-Em for qemu-devel@nongnu.org; Wed, 27 Nov 2013 05:03:57 -0500 Message-ID: <5295C37F.40703@kamp.de> Date: Wed, 27 Nov 2013 11:03:43 +0100 From: Peter Lieven MIME-Version: 1.0 References: <52956083.5000409@redhat.com> <20131127060109.GG24296@G08FNSTD100614.fnst.cn.fujitsu.com> <529593C5.5060003@redhat.com> In-Reply-To: <529593C5.5060003@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Fam Zheng Cc: Kevin Wolf , Hu Tao , qemu-devel@nongnu.org Am 27.11.2013 07:40, schrieb Fam Zheng: > On 2013年11月27日 14:01, Hu Tao wrote: >> On Wed, Nov 27, 2013 at 11:01:23AM +0800, Fam Zheng wrote: >>> On 2013年11月27日 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(BlockDriverState *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 allocated. 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 write. Peter