[Linux-cluster] FS-Cache

[Steven Whitehouse]

Hi,

On Thu, 2009-08-27 at 14:39 +0100, Mike Cardwell wrote:
> On 27/08/2009 14:25, Steven Whitehouse wrote:
> 
> >>>> Are there any plans to make GFS work with FS-Cache?
> >>>>
> >>>> http://people.redhat.com/~dhowells/fscache/FS-Cache.pdf
> >>>
> >>> Not that I'm aware of. I'm not sure it would make any sense to do so,
> >>
> >> Hi. Can you explain why it wouldn't make any sense please? I have a GFS
> >> filesystem mounted over 100Mb iSCSI (I'm not in a position to upgrade
> >> the network speed at this time, but will in future). It's read heavy.
> >> Particular files will be hit very regularly. I just thought it would be
> >> nice if those files could be cached locally rather than repeatedly
> >> pulling them over the network...?
> >
> > Unless you are doing something to push those files out of the cache,
> > then they will be cached locally anyway. GFS2 is a bit better at doing
> > that then GFS1 though,
> 
> Are you refering to some sort of in-memory cache? I've not been able to 
> find any information about how GFS2 caches file data and how to tune it 
> (if possible)? Each of my servers has over 100GB of unused local 
> storage. It would be nice if I could use that as a cache...
> 
Yes, the page cache, just like any other file system. If you want to
tune it, madvise, fadvise, etc are available. There is currently no
support for caching on other local storage as in most cases (I realise
your case may be an exception) the fastest storage is the shared disk.

If we were do to caching on local storage, then we'd need to make
significant changes to the glock subsystem (even if cachefs were used)
in order to ensure coherency. It would probably result in accesses from
remote nodes becoming so slow (due to the extended invalidation) that it
would only make sense on read-only mounts.

If your application is able to use read-only copies of the data most of
the time, then it might make more sense just to copy the data locally,
process it, and then copy back/delete the local copy as required,

Steve.