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

[Ed W]

 On 24/09/2010 09:42, Gordan Bobic wrote:
> This sounds remarkably similar to how DLM in GFS works. It caches file 
> locks, so performance is reasonable where a set of files is only 
> accessed from one of the nodes. Might it be easier to interface with 
> DLM for locking control instead of implementing such a thing from 
> scratch?
>
> The bulk of the performance hit comes from ping times, rather than 
> bandwidth issues / writeback caching. Latencies on a LAN are typically 
> 100us on Gb ethernet, vs. a typical RAM latency of 50ns, so call it a 
> 2000x difference. If this overhead on file lock acquisition can be 
> avoided, it'll make a lot more difference than data caching.

You have hit the nub of the issue.

Actually there are two issues here:

1) it would be excellent to see some kind of optimistic locking (which I 
think is a good generic description of this kind of optimisation) 
implemented in gluster

2) actually there are some subtleties in implementing this algorithm if 
you relax the restriction that all nodes are reliable, eg what happens 
if the node holding the locking information dies?  What happens if the 
server holding the lock dies (and a request turns up at the secondary 
server)?  How long do you wait before you decide to do something to 
break the deadlock and continue?

Paxos/Fatlease are clever implementations of a locking strategy in the 
face of non robust "bricks".  That said, google used a similar strategy 
up until recently and mogile and most other cluster systems still do use 
a non redundant locking strategy, so gluster going down the simple route 
would still largely be "state of the art" - however, a robust, shared 
nothing, redundant lock strategy is just icing on the cake?

Anyone interested in getting some sponsorship to implement something?

Thanks

Ed W