<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Ed - <br> If I understand it looks like you are recommending a method for implementing an asynchronous replication solution as a possible alternative to the current synchronous replication method? <span><br><br><span name="x"></span><div><div><div>Thanks.<br><br>--<br>Craig Carl<br><div><div><div>Gluster, Inc. <br>Cell - (408) 829-9953 (California, USA)<br>Gtalk - craig.carl@gmail.com</div></div></div></div></div></div><span name="x"></span><br></span><br><hr id="zwchr"><b>From: </b>"Ed W" <lists@wildgooses.com><br><b>To: </b>gluster-devel@nongnu.org<br><b>Sent: </b>Thursday, September 23, 2010 1:32:32 PM<br><b>Subject: </b>[Gluster-devel] Can I bring a development idea to Dev's attention?<br><br> Hi Glusterfs Dev's,<br><br>I might be trying to teach you to suck eggs, but I was reading through <br>the publications on http://www.xtreemfs.org/publications.php and one of <br>the ideas there seemed very relevant to gluster<br><br>Please have a look at their FatLease papers and the Paxos lease <br>negotiation algorithm. It was new to me, but seems like an elegant and <br>robust (google use it) way of managing a distributed lock scenario?<br><br>In particular it would seem to be a very interesting way to introduce <br>the idea of optimistic locking to the gluster type infrastructure. What <br>I'm thinking here is the situation where you have a client talking to a <br>single brick in a replicated set, that it can effectively optimistically <br>lock a localised set of files/directories on that brick and so further <br>reads/modifications can be lazily written out to other servers (without <br>compromising coherency). If a read/write goes to one of the other <br>replicas then of course it must first break the other servers optimistic <br>lock before continuing and effectively you temporarily revert back to <br>the current situation where every file access causes a network access to <br>all other servers.<br><br>The win is clearly where you end up with clients localising their access <br>for certain files to certain servers and that server will then benefit <br>from holding an optimistic lock, since no network activity is generated <br>for further read access and lazy writes become possible without split <br>brain risk.<br><br>eg consider a master/master setup with serveral webservers. Especially <br>where each physical machine touches only a subset of the files (eg each <br>machine usually only serves a subset of data), then that machine can <br>start to access the gluster share at basically native disk speeds, <br>having acquired an optimistic lock on that subset of data (no need to <br>check with other bricks since we now have a lock on the data). This <br>would seem to be a huge win for a large class of problems?<br><br>(Thinking about it another way, it's a bit like a standard optimistic <br>locking architecture, where one server gets promoted to become the <br>master reader/writer at a time (for a subset of files) and no other <br>server can read/write those files without first breaking the lock by <br>requesting to become the master. The difference is that Paxos allows <br>this to be done robustly and efficiently without a centralised lock server)<br><br>The clever part seems to be the fairly stateless method that is used to <br>bootstrap a system with stateful leases (read the publications). I <br>hadn't come across the Fatlease/Paxos idea before and it seems extremely <br>clever<br><br>Cheers<br><br>Ed W<br><br>_______________________________________________<br>Gluster-devel mailing list<br>Gluster-devel@nongnu.org<br>http://lists.nongnu.org/mailman/listinfo/gluster-devel</div></body></html>