From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33887)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RSRJ8-0007te-R4
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 05:41:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RSRJ7-00005Z-SO
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 05:41:02 -0500
Received: from mx1.redhat.com ([209.132.183.28]:24700)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1RSRJ7-00005R-KT
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 05:41:01 -0500
Message-ID: <4ECA2B78.7040400@redhat.com>
Date: Mon, 21 Nov 2011 11:44:08 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1321607573-29744-1-git-send-email-zhihuili@linux.vnet.ibm.com>
	<CAJSP0QXfetSM8zewDtrYkL9F2790UXtcS1Bh761nL5UQxE8twQ@mail.gmail.com>
	<ja5eff$tdd$1@dough.gmane.org>
	<CAJSP0QUghLT5-bRFtwL2Yj0VwRp0PG3rV0hmhUB5D7jHn+3HWQ@mail.gmail.com>
In-Reply-To: <CAJSP0QUghLT5-bRFtwL2Yj0VwRp0PG3rV0hmhUB5D7jHn+3HWQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] block: Use bdrv functions to replace file
 operation in qcow.c
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org

Am 18.11.2011 15:34, schrieb Stefan Hajnoczi:
> On Fri, Nov 18, 2011 at 11:10 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 11/18/2011 11:59 AM, Stefan Hajnoczi wrote:
>>>
>>> +    tmp = g_malloc0(sizeof(uint64_t)*l1_size);
>>>>  +    ret = bdrv_pwrite(qcow_bs, header_size, tmp,
>>>> sizeof(uint64_t)*l1_size);
>>>>  +    g_free(tmp);
>>>>  +    if (ret != sizeof(uint64_t)*l1_size) {
>>>>  +        goto exit;
>>>>       }
>>>
>>> That means 400 MB of RAM for the zero L1 table for a 100 TB image.
>>> Since qcow is a legacy format this probably doesn't matter in practice
>>> but in theory this approach can require a noticable amount of RAM.
>>
>> 4 MB / TB is not a big deal (you probably would like the L1 table to be in
>> memory all the time), but why write the L1 table at all?  Since the file was
>> CREATed, it is already zero and you can just leave a hole in the file.
> 
> I thought the same thing then remember sometimes people want to use
> image formats on block devices.  I think at least making image
> creation not depend on has_zero_init is a good idea.

qcow1 doesn't work on block devices anyway.

Kevin