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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]/message/VDMDZZ6TCT5XL5CXR56RZS5QINRWIYQB/
_______________________________________________
Users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]/message/W5EFGYNLIH2HMAKW2N43CETJSCTHDZ27/
