<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Dec 8, 2017 at 4:18 PM Kevin Wolf <<a href="mailto:kwolf@redhat.com">kwolf@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 07.12.2017 um 23:45 hat Nir Soffer geschrieben:<br>
> The qemu bug <a href="https://bugzilla.redhat.com/713743" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/713743</a> explains the issue:<br>
> qemu-img was writing disk images using writeback and fillingup the<br>
> cache buffers which are then flushed by the kernel preventing other<br>
> processes from accessing the storage. This is particularly bad in<br>
> cluster environments where time-based algorithms might be in place and<br>
> accessing the storage within certain timeouts is critical<br>
><br>
> I'm not sure it this issue relevant now. We use now sanlock instead of<br>
> safelease, (except for export domain still using safelease), and qemu<br>
> or kernel may have better options to avoid trashing the host cache, or<br>
> guarantee reliable access to storage.<br>
<br>
Non-direct means that the data goes through the kernel page cache, and<br>
the kernel doesn't know that it won't be needed again, so it will fill<br>
up the cache with the image.<br>
<br>
I'm also not aware that cache coherency is now provided by all backends<br>
for shared storage, so O_DIRECT still seems to be the only way to avoid<br>
using stale caches. Since the problem is about stale caches, I don't see<br>
how the locking mechanism could make a difference.<br>
<br>
The only thing I can suggest, given that there is a "glusterfs" in the<br>
subject line of the email, is that the native gluster driver in QEMU<br>
takes a completely different path and never uses the kernel page cache,<br>
which should make both problems disappear. Maybe it would be worth<br>
having a look at this.<br></blockquote><div><br></div><div>This is an interesting direction - currently oVirt does not use native </div><div>glusterfs for qemu-img operation, only for running vms. We still use</div><div>the fuse based glusterfs mount for storage operations like copying</div><div>and converting images.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Kevin<br>
</blockquote></div></div>