Re: [ovirt-users] [Qemu-block] slow performance with export storage on glusterfs

Am 07.12.2017 um 23:45 hat Nir Soffer geschrieben: > The qemu bug https://bugzilla.redhat.com/713743 explains the issue: > qemu-img was writing disk images using writeback and fillingup the > cache buffers which are then flushed by the kernel preventing other > processes from accessing the storage. This is particularly bad in > cluster environments where time-based algorithms might be in place and > accessing the storage within certain timeouts is critical > > I'm not sure it this issue relevant now. We use now sanlock instead of > safelease, (except for export domain still using safelease), and qemu > or kernel may have better options to avoid trashing the host cache, or > guarantee reliable access to storage. Non-direct means that the data goes through the kernel page cache, and the kernel doesn't know that it won't be needed again, so it will fill up the cache with the image. I'm also not aware that cache coherency is now provided by all backends for shared storage, so O_DIRECT still seems to be the only way to avoid using stale caches. Since the problem is about stale caches, I don't see how the locking mechanism could make a difference. The only thing I can suggest, given that there is a "glusterfs" in the subject line of the email, is that the native gluster driver in QEMU takes a completely different path and never uses the kernel page cache, which should make both problems disappear. Maybe it would be worth having a look at this.

Kevin