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
