On Thu, May 21, 2020 at 1:01 AM Eric Blake <address@hidden> wrote:
It's useful to know how much space can be occupied by qcow2 persistent
bitmaps, even though such metadata is unrelated to the guest-visible
data. Report this value as an additional QMP field, present when
measuring an existing image and output format that both support
bitmaps. Update iotest 178 and 190 to updated output, as well as new
coverage in 190 demonstrating non-zero values made possible with the
recently-added qemu-img bitmap command.
On the command-line side, 'qemu-img measure' gains a new --bitmaps
flag. When present, the bitmap size is rolled into the two existing
measures (or errors if either the source image or destination format
lacks bitmaps); when absent, there is never an error (for
back-compat), but the output will instead include a new line item for
bitmaps (which you would have to manually add), with that line being
omitted in the same cases where passing --bitmaps would error.
Supporting 2 ways to measure, one by specifying --bitmaps, and another
by adding bitmaps key is not a good idea. We really need one way.
Each one has advantages. adding --bitmaps flag is consistent with
"qemu-img convert"
and future extensions that may require new flag, and adding "bitmaps"
key is consistent
with "qmeu-img info", showing bitmaps when they exist.
Adding a "bitmaps" key has an advantage that we can use it to test if qemu-img
supports measuring and copying bitmaps (since both features are expected to
be delivered at the same time). So we can avoid checking --help learn about
the capabilities.
I'm ok with both options, can we have only one?