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

[Shehjar Tikoo]

Thanks, we have similar locking improvements in mind but cannot promise 
a date when these will be available. Some of the challenges that we'll 
need to think about are how to map any such locking scheme to standard 
locking behaviour for posix/nfsv3/v4/cifs.

-Shehjar


Ed W wrote:
>  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