<div dir="ltr">Understand your point, by the time I also tried with NFS like clustering but didn't help<div><br></div><div>There is master-master geo replication planned in 3.4 <a href="http://www.gluster.org/community/documentation/index.php/Planning34">http://www.gluster.org/community/documentation/index.php/Planning34</a></div>
<div><br></div><div>I think it is for the same purpose, has anyone got an idea on it?</div><div><br></div><div><div><div dir="ltr">Regards,<br>Zohair Raza<div><br></div></div><div class="gmail_quote">On Mon, Nov 26, 2012 at 2:58 PM, Robert Hajime Lanning <span dir="ltr"><<a href="mailto:lanning@lanning.cc" target="_blank">lanning@lanning.cc</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/25/12 23:26, Zohair Raza wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Thanks for reply,<br>
<br>
Can you please elaborate more on the last line, I understand that read<br>
will have no issues. I tried implementing a replicated volume but the<br>
problem is gluster starts uploading the file to node2 while copying for<br>
example if I have a 500MB file in site1 which is being copied from a LAN<br>
machine to node1 copies at the speed of my internet link which I want to<br>
get copied at much faster speed (in MBps) as it is LAN.<br>
<br>
Isn't there any way by which I can set synchronization speed or set<br>
gluster to sync after the file is copied?<br>
</blockquote>
<br></div>
All the smarts are in the client.<br>
<br>
If you have a replica count of 2, then when a client is writing, it is writing to 2 bricks at the same time. There is no such thing as queuing for later sync.<br>
<br>
What happens if a client at site A is writing to the same file as a client at site B? If you have a delayed write to a remote site, how do you solve write conflicts? You would need to completely understand the file format and it's transactional state, so that the 2 separate writes can be merged without corrupting the file.<br>
<br>
If there is a conflict, there is no way to notify the process that was writing, because the write would have already returned as successful, since it was queued for later execution on the file.<br>
<br>
The only way to solve this, is to have synchronized locks and synchronized writes. It needs to behave like a local filesystem with 2 processes writing.<br>
<br>
Geo-replication solves this by saying one site is the master and all writes happen there. The other site is a replica of the master, period. This gives you a single source of truth about file state and no conflicts to mediate.<br>
<br>
For a database with ACID transactions and atomic data structures, you can design the data and data structures for multi-master replication. You can state that the latest update of an atomic structure wins, then design your application around that. For a filesystem, you can't, as you do not have visibility into the structure of the files.<br>
<br>
The commercial NAS systems that have multi-master capabilities, do it at the block level (not file) and do it synchronously.<br>
<br>
I currently do not know of a way to implement a multi-master asynchronous network filesystem, without introducing the possibility of file corruption.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Mr. Flibble<br>
King of the Potato People<br>
</div></div></blockquote></div><br></div></div></div>