From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38798 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pilte-0000xj-Gq for qemu-devel@nongnu.org; Fri, 28 Jan 2011 05:49:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiltO-00006i-Ll for qemu-devel@nongnu.org; Fri, 28 Jan 2011 05:49:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiltO-00006e-Dj for qemu-devel@nongnu.org; Fri, 28 Jan 2011 05:49:26 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0SAnP0N024978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Jan 2011 05:49:25 -0500 Date: Fri, 28 Jan 2011 10:49:22 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] qcow2: Add full image preallocation option Message-ID: <20110128104922.GA26309@redhat.com> References: <1296143534-13495-1-git-send-email-kwolf@redhat.com> <20110127155824.GC20364@redhat.com> <4D427CD7.8040208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D427CD7.8040208@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On Fri, Jan 28, 2011 at 09:22:47AM +0100, Kevin Wolf wrote: > Am 27.01.2011 16:58, schrieb Daniel P. Berrange: > > On Thu, Jan 27, 2011 at 04:52:14PM +0100, Kevin Wolf wrote: > >> This adds a preallocation=full mode to qcow2 image creation, which does not > >> only allocate metadata for the whole image, but also writes zeros to it, > >> creating a non-sparse image file. > >> > >> Signed-off-by: Kevin Wolf > > > Is there a way you can calculate the total size of the qcow2 > > file upfront, and just use a single posix_fallocate() call to > > do the zero-filled allocation of all the data blocks. It is > > many orders of magnitude faster than truely writing blocks of > > zero'd data on modern filesystems. I guess if you're using > > compression or encryption, we'd really have to go the slow > > path, but for regular usage it'd be better to take a fast > > path. > > Encryption doesn't really change anything with respect to cluster > allocations, but combining compression with preallocation doesn't make > any sense. We should probably forbid that. > > To get the size of the image, it should be enough to get the offset of > the last cluster as the allocation is done sequentially. However, we > don't have a bdrv_fallocate (yet). I'm not sure how to emulate this for > drivers that don't support it directly, but maybe we could just ignore > it for them. FWIW in libvirt code we ended up with 'posix_fallocate()' as our first choice. If that wasn't available, then we do a sequence of 'ftruncate()+mmap()+memset()+munmap()' for the region as second choice. And if mmap doesn't exist, as the catch-all portable option for any OS we do a write() of 1MB chunks in a loop. Regards, Daniel