Re: Can I bring a development idea to Dev's attention?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Gordan

Ed W wrote:
  On 24/09/2010 05:10, Craig Carl wrote:
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?

I think there are two main use cases which benefit:

1) Master/Master, epecially where the client is itself one of the bricks. Eg recently there have been several threads on poor performance using gluster as the backing store for a web server. Here a common situation might be that we have a backing store holding say two web applications, each frontend server generally only serves one of the two applications and so we want to avoid network accesses in the common case that files typically have affinity for being used by just one of the servers.

2) Achieving effectively the benefit of a large writeback cache, yet without compromising coherency, in the face of larger RTT times between bricks. This could be anything from a 100mbit IP link between heavily accessed servers, to a WAN. Optimistic locking is basically a way of optimising for the case where a single brick at a time tends to access a subset of files. It does absolutely nothing for the situation that you have more than one brick competing for access to the same file (I think it's obvious that the latter situation is hard to improve anyway)

So really optimistic locking is a performance improvement in any situation where:

- One server accesses a file more than once in a row, before any other server requests access (doesn't matter whether its a read or write) - The above also implies that we will get maximum benefit in the case where there is relatively large RTT times between servers (this would include even gigabit for the case of a heavily used server though) - We can also infer that this optimisation benefits us most if we can tweak our applications to have some kind of affinity to prefer a given server for a given subset of files (often this is very easily done for a whole class of applications, eg webservers point A records to specific servers, mailservers trivially route users to their preferred storage server, geographic clustering tends to take care of itself if the client isn't in a rocket ship, etc)

OK, so that's "optimistic locking" and the reason why it would be nice to have it. Traditionally this is done using a shared lock server (single point of failure). However, my suggestion was to read up on the algorithms in the publications list, which show how it's possible to implement a fault tolerant, shared nothing, lock server (cool!). Now we have a lock server in the style of gluster, where there is no single point of failure!

So I think really it's two feature requests:

1) Can you please implement optimistic locking optimisations using a lock server 2) Can you please make the lock server fault tolerant, fully distributed, shared nothing, eg using a Paxos derivative

Cheers

Ed W


------------------------------------------------------------------------

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux