Federico Simoncelli has posted comments on this change.
Change subject: image: use qemu-img convert to copy internal volumes
......................................................................
Patch Set 5:
(3 comments)
http://gerrit.ovirt.org/#/c/33355/5//COMMIT_MSG
Commit Message:
Line 33: coreutils-8.4-37.el6.x86_64
Line 34: kernel-2.6.32-504.1.3.el6.x86_64
Line 35: qemu-img-rhev-0.12.1.2-2.415.el6_5.3.x86_64
Line 36:
Line 37: - dd 3Gb data volume on block domain: 67.16s +-2.19s [1]
What about other options - from file to block, from block to file,
from fil
The stats from file to file are below.
Data are average on 5 runs and stddev.
Other combinations, e.g. block to file and file to block are irrelevant because we already
proved that writing to block and writing to file is faster with qemu-img.
Line 38: - qemu-img 2Gb data volume on block domain: 37.60s +-0.32s
Line 39:
Line 40: - dd 2Gb data volume on file domain: 79.02s +-7.44s
Line 41: - qemu-img 2Gb data volume on file domain: 56.92s +-12.37s
Line 37: - dd 3Gb data volume on block domain: 67.16s +-2.19s [1]
Line 38: - qemu-img 2Gb data volume on block domain: 37.60s +-0.32s
Line 39:
Line 40: - dd 2Gb data volume on file domain: 79.02s +-7.44s
Line 41: - qemu-img 2Gb data volume on file domain: 56.92s +-12.37s
Why qemu-img is faster - copying only allocated blocks?
No, as
I stated below the volumes contained 2Gb of random data, and all the 2Gb are transferred
in both cases. It is clearly specified where there was a different amount of transferred
data (note [1]).
Line 42:
Line 43: All the volumes contained the same (u)random data.
Line 44:
Line 45: [1] here dd pays the price of having to copy the entire chunk of
Line 39:
Line 40: - dd 2Gb data volume on file domain: 79.02s +-7.44s
Line 41: - qemu-img 2Gb data volume on file domain: 56.92s +-12.37s
Line 42:
Line 43: All the volumes contained the same (u)random data.
Is this typical? I think we should test typical volume - for example,
syste
The random data is the worst case. In the other cases qemu-img will always
perform better because it transfers only the allocated data and you can't do a fair
comparison.
Line 44:
Line 45: [1] here dd pays the price of having to copy the entire chunk of
Line 46: allocated space (3Gb vs 2Gb of real data). Anyway even when
Line 47: normalized to the same amount of data it's still slower.
--
To view, visit
http://gerrit.ovirt.org/33355
To unsubscribe, visit
http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I1c740d88d52ca678d6c02d0ea500d2459c26560c
Gerrit-PatchSet: 5
Gerrit-Project: vdsm
Gerrit-Branch: master
Gerrit-Owner: Federico Simoncelli <fsimonce(a)redhat.com>
Gerrit-Reviewer: Adam Litke <alitke(a)redhat.com>
Gerrit-Reviewer: Allon Mureinik <amureini(a)redhat.com>
Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
Gerrit-Reviewer: Federico Simoncelli <fsimonce(a)redhat.com>
Gerrit-Reviewer: Francesco Romani <fromani(a)redhat.com>
Gerrit-Reviewer: Nir Soffer <nsoffer(a)redhat.com>
Gerrit-Reviewer: automation(a)ovirt.org
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes