<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 11/26/2012 03:44 AM, Zohair Raza
wrote:<br>
</div>
<blockquote
cite="mid:CAF_PTev8q0j1_xJO4aLw-Zg4+Xg+hZa=fFcMtSB05xcMHVRc+Q@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
I wrote up about the first third of why what you're asking to do is
difficult on my blog at
<a class="moz-txt-link-freetext" href="http://www.joejulian.name/blog/why-replicated-filesystems-are-hard/">http://www.joejulian.name/blog/why-replicated-filesystems-are-hard/</a><br>
</body>
</html>