On 08/29/2013 08:00 AM, Paolo Bonzini wrote: > This command dumps the metadata of an entire chain, in either tabular or JSON > format. > > Signed-off-by: Paolo Bonzini <[email protected]> > --- > qemu-img-cmds.hx | 6 ++ > qemu-img.c | 191 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 197 insertions(+) >
> +++ b/qemu-img-cmds.hx
> @@ -45,6 +45,12 @@ STEXI
> @item info [-f @var{fmt}] [--output=@var{ofmt}] [--backing-chain]
> @var{filename}
> ETEXI
>
> +DEF("map", img_map,
> + "map [-f fmt] [--output=ofmt] filename")
> +STEXI
> +@item map [-f @var{fmt}] [--output=@var{ofmt}] @var{filename}
> +ETEXI
> +
Should the matching changes to qemu.texi (currently in 17/21) be hoisted
into this patch?
> + case OFORMAT_HUMAN:
> + if ((e->flags & BDRV_BLOCK_DATA) &&
> + !(e->flags & BDRV_BLOCK_OFFSET_VALID)) {
> + error_report("File contains external, encrypted or compressed
> clusters.");
> + exit(1);
> + }
> + if ((e->flags & (BDRV_BLOCK_DATA|BDRV_BLOCK_ZERO)) ==
> BDRV_BLOCK_DATA) {
> + printf("%#-16"PRIx64"%#-16"PRIx64"%#-16"PRIx64"%s\n",
printf("%#x", 0) prints 0, not 0x0. The automatic 0x is only for
non-zero values; do we really want 0 to look different in the output
from all other values? Let's see...
> + e->start, e->length, e->offset, e->bs->filename);
e->length is always non-zero. For a qcow2 file, e->offset will never be
0 (the first raw cluster is always after the metadata). But for a raw
file, the file starts at 0, so e->offset could be 0 there - is your new
'map' subcommand a useful way to probe where the holes are in a sparse
raw file? But e->start will cover at most one entry starting at 0 (none
if the logical data is unallocated at the start of the file, since the
human output elides those blocks); and indeed, your example in 17/21
shows the special casing:
+@example
+Offset Length Mapped to File
+0 0x20000 0x50000 /tmp/overlay.qcow2
+0x100000 0x10000 0x95380000 /tmp/backing.qcow2
I would have written "0x%-16"PRIx64 instead of "%#-16"PRIx64, but I can
live with your version.
> + case OFORMAT_JSON:
> + printf("%s{ \"start\": %"PRId64", \"length\": %"PRId64", \"depth\":
> %d,"
> + " \"zero\": %s, \"data\": %s",
> + (e->start == 0 ? "[" : ",\n"),
Here, e->start==0 will always be present, even when unallocated (since
you don't elide any blocks, and the logical data always starts at 0).
> +
> + if (output_format == OFORMAT_HUMAN) {
> + printf("%-16s%-16s%-16s%s\n", "Offset", "Length", "Mapped to",
> "File");
Are we ever planning on marking up qemu-img for translation? But this
patch need not worry about it.
Reviewed-by: Eric Blake <[email protected]>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
