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
[email protected]
http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
