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

[Ed W]

On 27/02/2010 18:56, John Feuerstein wrote:
> It would be really great if all of this could be cached within io-cache,
> only falling back to a namespace query (and probably locking) if
> something wants to write to the file, or if the result is longer than
> cache-timeout seconds in the cache. So even if the file has been
> renamed, is unlinked, has changed permissions / metadata - simply take
> the version of the io-cache until it's invalidated. At least that is
> what I would expect the io-cache to do. This will introduce a
> discrepancy between the cached file version and the real version in the
> global namespace, but isn't that what one would expect from caching...?
>    

I believe samba (and probably others) use a two way lock escalation 
facility to mitigate a similar problem.  So you can "read-lock" or 
phrased differently, "express your interest in caching some 
files/metadata" and then if someone changes what you are watching the 
lock break is pushed to you to invalidate your cache.

It seems like something similar would be a candidate for implementation 
with the gluster native clients?

You still have performance issues with random reads because when you try 
to open some file and you still need to check it's not open/locked/needs 
replicating from some other brick.  However, what you can do is have 
proactive caching with an active notification of any cache invalidation 
and this benefits the situation where you re-read stuff you already 
read, and/or you have an effective read-ahead which is grabbing stuff 
for you

Interesting problem

Ed W