performance: 0.850
graphic: 0.658
device: 0.643
semantic: 0.573
architecture: 0.452
kernel: 0.440
boot: 0.419
hypervisor: 0.413
network: 0.411
ppc: 0.394
mistranslation: 0.392
socket: 0.384
vnc: 0.358
risc-v: 0.355
PID: 0.332
files: 0.326
permissions: 0.325
x86: 0.325
register: 0.315
debug: 0.309
arm: 0.302
virtual: 0.297
i386: 0.285
VMM: 0.274
peripherals: 0.258
KVM: 0.258
user-level: 0.257
TCG: 0.238
assembly: 0.198

qemu-img snapshot -c is unreasonably slow

Something fishy is going on with qcow2 internal snapshot creation times.  I don't know if this is a regression because I haven't used internal snapshots in the past.

QEMU 1.4-rc2:
$ qemu-img create -f qcow2 test.qcow2 -o size=50G,preallocation=metadata
$ time qemu-img snapshot -c new test.qcow2
real	3m39.147s
user	0m10.748s
sys	0m26.165s

(This is on an SSD)

I expect snapshot creation to take under 1 second.

Skipping the bdrv_flush() in update_cluster_refcount() gives a huge speed-up from over 3 minutes down to <1 second.  I think Kevin already discovered this in the past.

Now we need to figure out how to safely perform the updates without flushing after each L2 table refcount increment.

Looking through old bug tickets... have this issue been fixed, i.e. could we close this ticket nowadays? Or is there still something left to do?

Code inspection shows that qcow2_update_cluster_refcount() no longer calls bdrv_flush().  This issue has been fixed.