30.01.2019 7:01, 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.shinkev...@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 > 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). >
But what is the benefit of it, except qemu-img info with --force-share option, which of course is not guaranteed to show valid metadata? While qemu is running valid way to obtain info is qmp. Do libvirt call qemu-img --fore-share? -- Best regards, Vladimir
