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
