Gluster's write-behind translator by default buffers writes for flushing to disk later, *even* when the file is opened with O_DIRECT flag. Not honoring O_DIRECT could mean a reader from another client could be READing stale data from bricks because some WRITEs may not yet be flushed to disk. performance.strict-o-direct=on is one of the options needed to truly honor O_DIRECT behavior which is what qemu uses by virtue of cache=none option being set (the other being network.remote-dio=off) on the vm(s) -Krutika On Mon, Feb 25, 2019 at 2:50 PM Leo David <leoalex(a)gmail.com&gt; wrote: > Hello Everyone, > As per some previous posts, this "performance.strict-o-direct=on" > setting caused trouble or poor vm iops. I've noticed that this option is > still part of default setup or automatically configured with > "Optimize for virt. store" button. > In the end... is this setting a good or a bad practice for setting the vm > storage volume ? > Does it depends ( like maybe other gluster performance options ) on the > storage backend: > - raid type / jbod > - raid controller cache size > I am usually using jbod disks attached to lsi hba card ( no cache ). Any > gluster recommendations regarding this setup ? > Is there any documentation for best practices on configurating ovirt's > gluster for different types of storage backends ? > Thank you very much ! > > Have a great week, > > Leo > > -- > Best regards, Leo David > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/7FKL42JSHIK... >