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(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/VDMDZZ6TCT5...