From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRMLQ-0004yD-Ke for qemu-devel@nongnu.org; Fri, 18 Nov 2011 06:10:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RRMLP-0004sN-Gz for qemu-devel@nongnu.org; Fri, 18 Nov 2011 06:10:56 -0500 Received: from lo.gmane.org ([80.91.229.12]:40599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRMLP-0004sG-BJ for qemu-devel@nongnu.org; Fri, 18 Nov 2011 06:10:55 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RRMLM-0000JZ-VO for qemu-devel@nongnu.org; Fri, 18 Nov 2011 12:10:52 +0100 Received: from 93-34-207-114.ip51.fastwebnet.it ([93.34.207.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2011 12:10:52 +0100 Received: from pbonzini by 93-34-207-114.ip51.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Nov 2011 12:10:52 +0100 From: Paolo Bonzini Date: Fri, 18 Nov 2011 12:10:39 +0100 Message-ID: References: <1321607573-29744-1-git-send-email-zhihuili@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: 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: qemu-devel@nongnu.org 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. Paolo