On 02/03/2010 21:25, Ed W wrote:
I have had a very quick glance at the current locks module and it's quite a bit more complex than I might have guessed... I had wondered if it might not be possible to make the locks module talk to the cache module and add server side lock breaking through that module? Essentially it's the addition of the "push" lock breaking which helps, so if we are reading away and some other client modifies a file then we need a feedback loop to invalide our read cache
Hmm, how easily might a "push" be implemented from the server side to the client?
I'm wondering if oplocks level 1/2 might be implemented using a special advisory lock and a mandatory lock, plus a server side push to break the client lock and the cache talking to the lock module:
- If the client wants to cache data for reading then we implement an advisory lock. This lock is special in that the server will break it and notify us if some other client requests some kind of writelock, neither will we block a request for a mandatory lock (unless the client requested some locking themselves). The client need not invalidate read cache while it holds this read oplock. - If the client wants to write data then we implement a form of mandatory lock which can be broken and reduced to an advisory write lock if some other client requests read access. (obviously unless client originally escalated to a real mandatory lock). The client can use writeback cache "safely" (subject to server/link failure) while it holds this write oplock.
Does this sound feasible to implement? It potentially buys us coherent client caching?
Ed W _______________________________________________ Gluster-users mailing list Gluster-users@gluster.org http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
