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
