summary refs log tree commit diff stats
path: root/results/scraper/launchpad/1126369
blob: d8fe9cb619b5c309c6bd918346778b217c8a332b (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
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.