Red Hat Bugzilla – Bug 861375
RFE: More info in qemu-img info
Last modified: 2013-03-11 11:37:15 EDT
qemu-img info currently give me info like this:
image: /home/alex/.local/share/gnome-boxes/images/Fedora 16
file format: qcow2
virtual size: 11G (11794287616 bytes)
disk size: 4.5G
In order to figure out the "health" of an image there is some more information I would like:
in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations
amount of compressed clusters. I.e. "is it useful to re-compress the image".
This would be useful to both sysadmins in general and for automated things like
what we want to do in gnome-boxes:
All sounds useful. However these requests should probably
go upstream, along with patches!
Note upstream there is a patch floating around which adds
JSON output to qemu-img info. This is useful because it's
a big security problem to try to parse the text output from
this command. See:
Depending on how Boxes wants to consume this extra metadata, this may need to be done in libvirt instead, or as well. Libvirt does not actually use qemu-img info for getting file metadata, since it wants a low overhead code to extra basic properties & forking qemu-img doesn't really satisfy that.
Fragmentation estimation and in-use space is actually quite expensive to compute---not *that* expensive but certainly worse than a fork, and worse-case O(n) in the size of the disk.
Fragmentation statistics have been added to 'qemu-img check' for qcow2 and qed image files:
Author: Dong Xu Wang <firstname.lastname@example.org>
Date: Thu Mar 15 20:13:31 2012 +0800
qemu-img: add image fragmentation statistics
Note this is qemu-img check and not qemu-img info, because we need to scan the image metadata (expensive on large images).
Yes, I agree that most of this should be part of 'qemu-img check' rather than 'qemu-img info'.
Fragmentation statistics are only implemented for QED as of today, qcow2 doesn't have them yet.
In general I don't think RFE's make much sense in Fedora bugzilla, so I've moved this to the upstream qemu tracker:
Alex, I couldn't find a launchpad account for you, but please follow up on that report (or qemu-devel)