[Gluster-devel] Can I bring a development idea to Dev's attention?

[Craig Carl]

Ed - 
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? 




Thanks. 

-- 
Craig Carl 



Gluster, Inc. 
Cell - (408) 829-9953 (California, USA) 
Gtalk - craig.carl at gmail.com 


From: "Ed W" <lists at wildgooses.com> 
To: gluster-devel at nongnu.org 
Sent: Thursday, September 23, 2010 1:32:32 PM 
Subject: [Gluster-devel] Can I bring a development idea to Dev's attention? 

Hi Glusterfs Dev's, 

I might be trying to teach you to suck eggs, but I was reading through 
the publications on http://www.xtreemfs.org/publications.php and one of 
the ideas there seemed very relevant to gluster 

Please have a look at their FatLease papers and the Paxos lease 
negotiation algorithm. It was new to me, but seems like an elegant and 
robust (google use it) way of managing a distributed lock scenario? 

In particular it would seem to be a very interesting way to introduce 
the idea of optimistic locking to the gluster type infrastructure. What 
I'm thinking here is the situation where you have a client talking to a 
single brick in a replicated set, that it can effectively optimistically 
lock a localised set of files/directories on that brick and so further 
reads/modifications can be lazily written out to other servers (without 
compromising coherency). If a read/write goes to one of the other 
replicas then of course it must first break the other servers optimistic 
lock before continuing and effectively you temporarily revert back to 
the current situation where every file access causes a network access to 
all other servers. 

The win is clearly where you end up with clients localising their access 
for certain files to certain servers and that server will then benefit 
from holding an optimistic lock, since no network activity is generated 
for further read access and lazy writes become possible without split 
brain risk. 

eg consider a master/master setup with serveral webservers. Especially 
where each physical machine touches only a subset of the files (eg each 
machine usually only serves a subset of data), then that machine can 
start to access the gluster share at basically native disk speeds, 
having acquired an optimistic lock on that subset of data (no need to 
check with other bricks since we now have a lock on the data). This 
would seem to be a huge win for a large class of problems? 

(Thinking about it another way, it's a bit like a standard optimistic 
locking architecture, where one server gets promoted to become the 
master reader/writer at a time (for a subset of files) and no other 
server can read/write those files without first breaking the lock by 
requesting to become the master. The difference is that Paxos allows 
this to be done robustly and efficiently without a centralised lock server) 

The clever part seems to be the fairly stateless method that is used to 
bootstrap a system with stateful leases (read the publications). I 
hadn't come across the Fatlease/Paxos idea before and it seems extremely 
clever 

Cheers 

Ed W 

_______________________________________________ 
Gluster-devel mailing list 
Gluster-devel at nongnu.org 
http://lists.nongnu.org/mailman/listinfo/gluster-devel 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20100923/34413b9c/attachment-0003.html>