From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSRgJ-0006En-7u for qemu-devel@nongnu.org; Mon, 21 Nov 2011 06:05:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSRgH-0004WB-Ut for qemu-devel@nongnu.org; Mon, 21 Nov 2011 06:04:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSRgH-0004W6-Lt for qemu-devel@nongnu.org; Mon, 21 Nov 2011 06:04:57 -0500 Message-ID: <4ECA3115.9040208@redhat.com> Date: Mon, 21 Nov 2011 12:08:05 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1321607573-29744-1-git-send-email-zhihuili@linux.vnet.ibm.com> <4ECA2B78.7040400@redhat.com> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Paolo Bonzini , qemu-devel@nongnu.org Am 21.11.2011 11:53, schrieb Stefan Hajnoczi: > On Mon, Nov 21, 2011 at 10:44 AM, Kevin Wolf wrote: >> Am 18.11.2011 15:34, schrieb Stefan Hajnoczi: >>> On Fri, Nov 18, 2011 at 11:10 AM, Paolo Bonzini 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. > > Okay, both of my original points were moot, Kevin and Paolo have explained why: > > The L1 RAM size issue doesn't really matter since we hold the entire > L1 in RAM during normal operation anyway. Holding it in RAM during > creation is no worse. > > The zero initialization could be optimized as Paolo suggested with > truncate since qcow1 always works on image files (which have automatic > zero initialization). I didn't say this. :-) At least in theory, block devices may not be the only protocols with !has_zero_init. We have only covered raw-posix with this discussion. I would prefer an explicit write of the table to avoid breaking other protocols (though I don't think we have one today; curl would be a candidate, but it is read-only). Kevin