Slow ova export performance

Hi All, I'm facing a really slow export ov vms hosted on a single node cluster, in a local storage. The Vm disk is 600 GB and the effective usage is around 300 GB. I estimated that the following process would take up about 15 hours to end: vdsm 25338 25332 99 04:14 pts/0 07:40:09 qemu-img measure -O qcow2 /rhev/data-center/mnt/_data/6775c41c-7d67-451b-8beb-4fd086eade2e/images/a084fa36-0f93-45c2-a323-ea9ca2d16677/55b3eac5-05b2-4bae-be50-37cde7050697 A strace -p of the pid shows a slow progression to reach the effective size. lseek(11, 3056795648, SEEK_DATA) = 3056795648 lseek(11, 3056795648, SEEK_HOLE) = 13407092736 lseek(14, 128637468672, SEEK_DATA) = 128637468672 lseek(14, 128637468672, SEEK_HOLE) = 317708828672 lseek(14, 128646250496, SEEK_DATA) = 128646250496 lseek(14, 128646250496, SEEK_HOLE) = 317708828672 lseek(14, 128637730816, SEEK_DATA) = 128637730816 lseek(14, 128637730816, SEEK_HOLE) = 317708828672 lseek(14, 128646774784, SEEK_DATA) = 128646774784 lseek(14, 128646774784, SEEK_HOLE) = 317708828672 lseek(14, 128646709248, SEEK_DATA) = 128646709248 The process take a single full core, but i don't think this is the problem. The I/O is almost nothing. Any idea/suggestion? Thank you for your time Regards

On Wed, Jul 15, 2020 at 5:36 PM francesco--- via Users <users@ovirt.org> wrote:
Hi All,
I'm facing a really slow export ov vms hosted on a single node cluster, in a local storage. The Vm disk is 600 GB and the effective usage is around 300 GB. I estimated that the following process would take up about 15 hours to end:
vdsm 25338 25332 99 04:14 pts/0 07:40:09 qemu-img measure -O qcow2 /rhev/data-center/mnt/_data/6775c41c-7d67-451b-8beb-4fd086eade2e/images/a084fa36-0f93-45c2-a323-ea9ca2d16677/55b3eac5-05b2-4bae-be50-37cde7050697
A strace -p of the pid shows a slow progression to reach the effective size.
lseek(11, 3056795648, SEEK_DATA) = 3056795648 lseek(11, 3056795648, SEEK_HOLE) = 13407092736 lseek(14, 128637468672, SEEK_DATA) = 128637468672 lseek(14, 128637468672, SEEK_HOLE) = 317708828672 lseek(14, 128646250496, SEEK_DATA) = 128646250496 lseek(14, 128646250496, SEEK_HOLE) = 317708828672 lseek(14, 128637730816, SEEK_DATA) = 128637730816 lseek(14, 128637730816, SEEK_HOLE) = 317708828672 lseek(14, 128646774784, SEEK_DATA) = 128646774784 lseek(14, 128646774784, SEEK_HOLE) = 317708828672 lseek(14, 128646709248, SEEK_DATA) = 128646709248
The process take a single full core, but i don't think this is the problem. The I/O is almost nothing.
Any idea/suggestion?
I think you are hitting this bug: https://bugzilla.redhat.com/1850660 Looks like you should be able to defragment the file using xfs_fsr, and after that you may be able to set a extent size hint using: xfs_io -c "extsize 1m" <imgfile> To prevent the future fragmentation. I think future qemu-img will set a size hint to avoid this issue. Nir
Thank you for your time Regards _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/QF2QIA4ZRQIE6H...
participants (2)
-
francesco@shellrent.com
-
Nir Soffer