The problem with sparse qcow2 images is that the Gluster shard xlator might not cope with the random I/O nature of the workload, as it will have to create a lot of shards in a short period of time ( 64MB shard size) for a small I/O ( for example 50 x 512 byte I/O request could cause  50 shards to be created simulatenously ).

With VDO enabled, preallocated disk images will take a fraction of the size , but qcow2 metadata and gluster metadata (shard files) will exist and that problem should not exist at all.

Can you try to reproduce the bug with Gluster v9.1 ? If it exists, let's create a separate thread in the gluster mailing list.


Best Regards,
Strahil Nikolov
for most safety, you create a new gluster layout and storage domain, and slowly migrate the VM into new domain. If you do other workaround, you should test it very carefully beforehand.

_______________________________________________
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/VDMDZZ6TCT5XL5CXR56RZS5QINRWIYQB/