Hi all,
Thanks for the helpful responses everyone, I will look at the mounting options suggested.
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?
Jeff: I don'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?
Eric
On Thu, Apr 9, 2015 at 4:07 PM, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:
Might be worth mounting with --entry-timeout=0 too.On 04/09/2015 07:33 PM, Jeff Darcy wrote:
I was under the impression that gluster replication was synchrounous, so the
appserver would not return back to the client until the created file was
replicated to the other server. But this does not seem to be the case,
because sleeping a little bit always seems to make the read failures go
away. Is there any other reason why a file created is not immediately
available on a second request?
It's quite possible that the replication is synchronous (the bits do hit
disk before returning) but that the results are not being seen immediately
due to caching at some level. There are some GlusterFS mount options
(especially --negative-timeout) that might be relevant here, but it's also
possible that the culprit is somewhere above that in your app servers.
-Vijay
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
