From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzjOr-0003nP-E8 for qemu-devel@nongnu.org; Thu, 18 Jul 2013 04:17:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzjOo-00063w-CM for qemu-devel@nongnu.org; Thu, 18 Jul 2013 04:17:21 -0400 Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:37685 helo=mx01.kamp.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1UzjOo-00063Y-20 for qemu-devel@nongnu.org; Thu, 18 Jul 2013 04:17:18 -0400 Message-ID: <51E7A48E.5030606@kamp.de> Date: Thu, 18 Jul 2013 10:17:18 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1373992168-26043-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1373992168-26043-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/17] Add qemu-img subcommand to dump file metadata List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 16.07.2013 18:29, Paolo Bonzini wrote: > This series adds a subcommand to "map" that can dump file metadata. > Metadata that is dumped includes: > > - whether blocks are allocated in bs->file and, if so, where > > - whether blocks are zero > > - whether data is read from bs or bs->backing_hd > > Metadata is dumped for an entire chain of images. One example usage is > (for non-compressed, non-encrypted images) to transform the metadata > into a Linux device-mapper setup, and make a qcow2 image available (for > read only) as a block device. Another possible usage is to determine > the used areas of a file, and convert it in place to another format. > Alternatively, the richer data can be used by block jobs to quickly > determine if a block is zero without reading it. > > The patches implement a new operation, bdrv_co_get_block_status, that > supersedes bdrv_co_is_allocated. The bdrv_is_allocated API is still > available of course, and implemented on top of the new operation. > > Patches 1-3 touch cow, which uses bdrv_co_is_allocated during its reads > and writes. I optimized it a bit because it was unbearably slow during > testing. With these patches (also tested with blkverify), booting of > a cow guest image is not particularly slow. > > Patches 4 to 6 clean up the bdrv_is_allocated and bdrv_is_allocated_above > implementation, eliminating some code duplication. > > Patches 7 and 8 tweak bdrv_has_zero_init and its usage in qemu-img in > a way that helps when implementing the new API. > > Patches 9 to 11 implement bdrv_get_block_status and change the formats > to report all the available information. > > Patch 12 adds the "map" subcommand to qemu-img. > > Finally, patches 13 to 17 tweak the implementation to extract more > information from protocols, and combine this information with format > metadata whenever possible. maybe i have missed it in your patches, but would it be also possible to issue DISCARDZEROES ioctl on linux to return zero status for block devices also? Peter