<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As of now, NSR makes use of etcd (which uses the RAFT distributed consensus protocol) to maintain information (term number, current leader) for the nodes in a replica group rather than using it in the data replication plane.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 2:45 PM, Prashanth Pai <span dir="ltr"><<a href="mailto:ppai@redhat.com" target="_blank">ppai@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
There is already an ongoing effort to use RAFT for synchronous replication. You can find the repo here:<br>
<br>
<a href="http://review.gluster.org/#/q/project:glusterfs-nsr,n,z" target="_blank">http://review.gluster.org/#/q/project:glusterfs-nsr,n,z</a><br>
<a href="https://forge.gluster.org/new-style-replication" target="_blank">https://forge.gluster.org/new-style-replication</a><br>
<br>
Regards,<br>
-Prashanth Pai<br>
<div><div class="h5"><br>
----- Original Message -----<br>
From: "Sharuzzaman Ahmat Raslan" <<a href="mailto:sharuzzaman@gmail.com">sharuzzaman@gmail.com</a>><br>
To: "Gluster Devel" <<a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a>><br>
Sent: Thursday, February 6, 2014 1:53:45 PM<br>
Subject: [Gluster-devel] raft consensus algorithm and glusterfs<br>
<br>
Hi all,<br>
<br>
I'm not sure if you all have heard about Raft Consensus Algorithm, but from the paper, video, and slides on the Internet, I think that this algorithm can help to solve a lot of distributed cases in GlusterFS.<br>
<br>
For example, right now the initial mounting of the filesystem can use any nodes IP, and later when the application needs to read or write the data, it will randomly picked from the peer list<br>
<br>
With Raft, one of the node will act as a master, after successful election among the peers. With one master in place, the read/write can directly goes to the master, which will replicate to other follower, according to the distribution requirement (distribute, replicate, stripe, distribute-replicate, etc)<br>
<br>
I also believe that with this method (having a master), the lock issue happen with samba could be reduced or resolved.<br>
<br>
For more information, please visit<br>
<a href="http://raftconsensus.github.io/" target="_blank">http://raftconsensus.github.io/</a><br>
<a href="https://www.youtube.com/watch?v=YbZ3zDzDnrw" target="_blank">https://www.youtube.com/watch?v=YbZ3zDzDnrw</a><br>
<br>
and the paper<br>
<a href="http://ramcloud.stanford.edu/raft.pdf" target="_blank">http://ramcloud.stanford.edu/raft.pdf</a><br>
<br>
Thanks.<br>
<br>
<br>
--<br>
Sharuzzaman Ahmat Raslan<br>
<br>
</div></div>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</blockquote></div><br></div>