Re: [Qemu-devel] [PATCH v8 0/2] qemu-img info lists bitmap directory entries

[John Snow <jsnow@redhat.com>]

On 1/29/19 11:01 PM, Eric Blake wrote:
> On 1/28/19 12:40 PM, Andrey Shinkevich wrote:
>> Here is the update for the bitmap extension of the qcow2 specific
>> information as the output of the 'qemu-img info' command.
>> The version #7 was in email with the message ID:
>> <1544698788-52893-1-git-send-email-andrey.shinkevich@virtuozzo.com>
>>
>> v8:
>> The output benchmark files for the qemu-iotests, namely 060, 065 082, 198
>> and 206, were modified to show the bitmap extension for the qemu specific
>> information. A new test file 239 was added to the test set that checks the
>> output for the fields of the bitmap section.
>> The backward compatibility of the output for images of the version 2
>> of qcow2 was added.
> 
> So, I'm trying to test this, and I've discovered something rather
> annoying about persistent snapshots: they DON'T get written to disk
> until the qemu process exits.  In other words, even after creating a

Technically, they get written out on qcow2_inactivate -- so there is the
opportunity to write them out at key sync points if you want.

However, like Vladimir says, this data is going to be necessarily wrong
while the image is in-use, so there may not be great value in it. There
may be a lot of anti-value if users learn to use or rely on that data.

I suppose the debugging case you want to assist here is one of trust for
users -- if a user wants to take a quick poke at the image and see if
the persistent bitmap tracking really got enabled before trusting it for
the next week of operations.

> persistent bitmap via QMP (I'm trying to debug my libvirt API for
> incremental snapshots, so I did this via 'virsh snapshot-create-as $dom
> name', but it boils down to a QMP transaction with
> 'block-dirty-bitmap-add' as one of the commands), running:
> 
> $ qemu-img info -U Active1.qcow2
> 
> shows
>     bitmaps:
>     refcount bits: 16
> 
> for as long as the qemu process is running. What does it take to force a
> qcow2 image to write out its current set of known bitmaps to disk, even
> if they are known to be potentially dirty? Should it happen any time we
> flush L1/L2/refcount tables?  On a periodic but slow timer (say once
> every 5 minutes)? Other ideas?  I know we don't want to be flushing the
> full bitmap contents on every change to the in-memory internal bitmap,
> but meta-changes (such as adding a bitmap) seem like the sort of thing
> where it's worth flushing the qcow2 file; particularly when adding the
> bitmap via QMP 'transaction' which goes to the bother of flushing all
> pending I/O in order to properly roll back on failure (which means on
> success, it would be nice for the new bitmap name to show up in the
> qcow2 header, even if the contents of the bitmap are not up-to-date).
>