[Gluster-users] How caches are working on AFR?

[Anand Babu Periasamy]

Replicate in 2.0 performs atomic writes by default. This means, writes will return control
back to application only after both the volumes (or more) are successfully written.

To mask the performance penalty of atomic writes, you should load write-behind on top of
it. Write-behind returns control as soon as it receives the write call from the
application, but it continues to write in background. Write-behind also performs
block-aggregation. Smaller writes are aggregated into fewer large writes.

POSIX says application should verify the return status of close system call to ensure all
writes were successfully written. If they are any pending writes, close call will block to
  ensure all the data is completely written. There is an option in write-behind to even
close in background. It is unsafe and turned off by default.

Applications that expect every write to succeed, issues synchronous writes.

I Hope it answers your question.

Happy Hacking,
--
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
Blog [http://ab.multics.org]
GlusterFS [http://www.gluster.org]
The GNU Operating System [http://www.gnu.org]



Stas Oskin wrote:
> Hi.
> 
> I have a question to GlustreFS developers.
> 
> if I have a pair of servers in client-server AFR (A and B), and the 
> application running on A writes to disk, how soon the application 
> receives OK and can continue?
> 
> After the cache on server A is filled with data (and then all is 
> synchronized in background), or only after cache on server B gets data 
> as well?
> 
> Thanks.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users