blob: 9729de9f453fc9b4a293b5becd596c9bc6b805a9 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
graphic: 0.658
device: 0.643
semantic: 0.573
instruction: 0.455
boot: 0.419
network: 0.411
other: 0.396
mistranslation: 0.392
socket: 0.384
vnc: 0.358
KVM: 0.258
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.
|