<div dir="ltr">Hi all,<div><br></div><div>Thanks for the helpful responses everyone, I will look at the mounting options suggested. </div><div><br></div><div>Just a quick question to confirm my understanding. When we all say replication is synchronous, that does mean that each of the filesystem operations on appserver1 that write a chunk of bytes to the file does not return back to the caller until the same chunks of bytes have been written to the OS filesystem cache/disk on the other appserver/brick, right? Or does it mean something else?</div><div><br></div><div>Jeff: I don&#39;t really understand how a write-behind translator could keep data in memory before flushing to the replication module if the replication is synchronous. Or put another way, from whose perspective is the replication synchronous? The gluster daemon or the creating client?</div><div><br></div><div>Eric</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 4:07 PM, Vijay Bellur <span dir="ltr">&lt;<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/09/2015 07:33 PM, Jeff Darcy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was under the impression that gluster replication was synchrounous, so the<br>
appserver would not return back to the client until the created file was<br>
replicated to the other server. But this does not seem to be the case,<br>
because sleeping a little bit always seems to make the read failures go<br>
away. Is there any other reason why a file created is not immediately<br>
available on a second request?<br>
</blockquote>
<br>
It&#39;s quite possible that the replication is synchronous (the bits do hit<br>
disk before returning) but that the results are not being seen immediately<br>
due to caching at some level.  There are some GlusterFS mount options<br>
(especially --negative-timeout) that might be relevant here, but it&#39;s also<br>
possible that the culprit is somewhere above that in your app servers.<br>
<br>
</blockquote>
<br></div></div>
Might be worth mounting with --entry-timeout=0 too.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Vijay<br>
<br>
</font></span></blockquote></div><br></div>