From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOnfI-0007sz-NH for qemu-devel@nongnu.org; Fri, 20 Feb 2015 08:30:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOnfE-0004Wb-IX for qemu-devel@nongnu.org; Fri, 20 Feb 2015 08:30:44 -0500 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:46845 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOnfE-0004Uu-2R for qemu-devel@nongnu.org; Fri, 20 Feb 2015 08:30:40 -0500 Message-ID: <54E736FA.3040108@kamp.de> Date: Fri, 20 Feb 2015 14:30:34 +0100 From: Peter Lieven MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Fwd: Re: [PATCH 1/2] qemu-img convert: Rewrite copying logic] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mreitz@redhat.com Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 20.02.2015 um 14:27 schrieb Peter Lieven: > > On 2015-02-19 at 10:47, Kevin Wolf wrote: >> Am 18.02.2015 um 18:18 hat Max Reitz geschrieben: > [snip] > >>> Actually, now that I'm looking at is_allocated_sectors_min(), if the >>> first sectors is not allocated, it will return false and thus both >>> the current qemu-img convert and the new one after this patch won't >>> write data. That's a bug, I think (because it is guaranteed by the >>> man page). >> Or the description in the man page is wrong. >> >> The intention with -S was that we avoid splitting up writes into too >> many small chunks because that costs a lot of time. If you look at it >> from that angle, it's doing exactly the right thing because skipping >> zeros at the start doesn't increase the number of write requests. > Feel free to fix it. But I remember someone recently asking about > preallocation for qemu-img convert in the #qemu IRC channel, and "-S 0" > was one of the valid answers. > > The nice thing about -S 0 is that it works with all image formats; I > know that qcow2 is always our main concern (especially when it comes to > the target of qemu-img convert), but I think using -S 0 for > preallocation is justified. > > Considering that in this case the man page was lying (because the code > did not allocate everything), I'd be fine with fixing up the man page > and leaving the behavior as-is, though, too. For the uncompressed case the code *did* allocate everyting. has_zero_init was always set to 0 for -S 0 regardless what the backend reported and in this case is_allocated_sectors_min is never called. For the new version I would use the same behaviour altough you might bdrv_write_zeroes to optimize the write, but in the -S 0 case without BDRV_REQ_MAY_UNMAP. Peter