On 09/26/2010 12:54 AM, Ed W wrote:
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?
I still think it would be worth investigating interfacing with DLM,
which already does this sort of thing, and is already there. Untill the
scope for re-using that is investigated, it may better to hold off on
re-inventing that particular wheel.
Gordan
