A quote from : https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/sect-creating_replicated_volumes


Sharding has one supported use case: in the context of providing Red Hat Gluster Storage as a storage domain for Red Hat Enterprise Virtualization, to provide storage for live virtual machine images. Note that sharding is also a requirement for this use case, as it provides significant performance improvements over previous implementations.


Also, FUSE will be able to read multiple shards from multiple bricks - so load should be properly spread among the bricks and performance is most optimal.

Also, I don't see that option in https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/configuring_red_hat_virtualization_with_red_hat_gluster_storage/app-virt_profile

How did this option got on your volume? Was this volume created by oVirt or manually ?


Best Regards,
Strahil Nikolov
It is because of a serious bug on cluster.lookup-optimize, it cause me few VM image corruption after new brick added. Although cluster.lookup-optimize theoretically impact all file not just shards. However, after ran many round verification test, corruption doesn't happen when  shards disabled. Therefore I'm interested to see why shards is essential in oVirt defaults.

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