[OpenAFS-devel] Regarding GSoC 2010 Collaborative Caching Project

[Tom Keiser]

On Sat, Apr 17, 2010 at 2:25 AM, shruti jain <shruti.jain1988@gmail.com> wrote:
> Here is what I know about the cache manager and its file server
> interactions.
> The Cache Manager resides on the client side in openAFS environment and
> communicates with AFS file server on behalf of the application programs
> running on the client. When an AFS file is needed by any application program
> running on a client machine, the request is sent to the Cache Manager which
> in turn issues RPC calls to the fille server storing the requested file.
> When the Cache Manager receives the requested data from the file Server, it
> stores it in the cache and also delivers it to the application program which
> had initially requested for the data. In order to maintain cache
> consistency, server issues a callback along with the data. A callback is a
> promise by a File Server to a Cache Manager to inform any change in the data
> delivered by the File Server to the Cache Manager. If any other client on
> the network modifies the file then the file server breaks this callback and
> thus gives an indication to the Cache manager that its locally cached copy
> of the file is obsolete and needs to be updated.The callback mechanism
> ensures that the Cache Manager always requests the most up-to-date version
> of a file. In this way, cache manager also performs the responsibility of
> maintaing the cache.
>
> So in this project, we need to modify the cache manager to enable
> interactions with other clients as well.
> In the first part of the project, where the cache manager contacts a fixed
> set of remote clients, it retrieves the file from any of these clients if
> their callback of the file is not broken. Since the callback is not broken,
> it is an indication that the file present on this remote client is most
> recent. In case no client has most recent copy of the file, we can contact
> the file server to retrieve the data.
>
> In the second part of the project, we can allow discovery of peer clients
> for collaboration. This can be done by modifying the file server to keep
> access logs of the clients and if a client requests for any data then its
> corresponding clients in the logs would be returned to the requesting
> clients. In order to maintain cache consistency, the requesting client also
> establishes a callback guarantee from the file server so that it knows of
> the modifications in the file irrespective of where it has got the file
> from.
>

I think Matt already covered the CC issues, so let me tackle the cache
directory issue...

By virtue of using cached data from other client nodes, you've already
fundamentally modified the trust model.  Given that we already
implicitly trust our peers, why not take this a step further and store
the cache directory itself as a distributed data structure (e.g. a
DHT)?  This will substantially reduce the load on the fileserver by
virtue of FetchStatus being its only role for read hits.

Cheers,

-Tom