[ovirt-users] Re: Poor performance of oVirt Export Domain

On Fri, Aug 3, 2018 at 12:12 PM <Aleksey.I.Maksimov(a)yandex.ru&gt; wrote: This is not a good test for copying images: - You are not using direct I/O, and - You are using block size of 512 bytes, way too small - You don't sync at the end of the transfer - You don't copy real image, reading zeros does not take any time, while reading real image takes time. This can drop dd performance in half A better way to test this is: dd if=/path/to/src of=/path/to/dst bs=8M count=1280 iflag=direct oflag=direct conv=fsync status=progress This does not optimize copying sparse parts of the image. For this you can use qemu-img, what oVirt is using. The command oVirt uses is: qemu-img convert -p -f raw|qcow2 -O raw|qcow2 -t none -T none /paht/to/src /path/to/dst The disk capacity of the VDO volume is connected to the oVirt 4.2.5 cluster This is very very low throughput. Can you give more details on - the source domain, how it is connected (iSCSI/FC)? - the destination domain, how is it connected? (NFS 4.2?, 1G nic? 10G nic?) - the source image - can you attach output of: qemu-img map --output json /path/to/src - If the source image is on block storage, please copy it to a file system supporting sparsness using NFS 4.2 using: qemu-img convert -p -f raw -O raw -t none -T none /path/to/src/ /path/to/dst (if the image is qcow2, replace "raw" with "qcow2") Again, not a good way to test. This sounds like https://bugzilla.redhat.com/1511891. (the bug may be private) Finally, can you provide detailed commands to reproduce your setup, so we can reproduce it in the lab? - how to create the vdo volume - how you created the file system on this volume - NFS version/configuration on the server - info about the server - info abut the network - info about the host Nir