[Gluster-users] GlusterFS 3.0.2 small file read performance benchmark

[Ed W]

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