[OpenAFS-devel] Regarding GSoC 2010 Collaborative Caching Project

[shruti jain]

--001636c59539d2b5fa048468c9a7
Content-Type: text/plain; charset=ISO-8859-1

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 have seen the files afs_callback.c, cbqueue.c, dcache.c and server.c and
think that these are some of the programs used in cache manager and
server-cache manager interactions. Please correct me if I am wrong.

Thank You.

Shruti

On Wed, Apr 14, 2010 at 8:15 PM, Derrick Brashear <shadow@dementia.org>wrote:

> Steve,
>
> You should like it. The idea was already implemented at Michigan once (ifs,
> the intermediate fileserver)
>
> Derrick
>
>
> On Apr 14, 2010, at 10:36 AM, Steve Simmons <scs@umich.edu> wrote:
>
> On Apr 13, 2010, at 10:12 AM, shruti jain wrote:
>
> The project aims at developing a system which would use collaborative
> caching techniques to improve the read accesses in OpenAFS. This project is
> based on two observations.
>
> Firstly, in a cluster environment, a large number of clients need same
> datasets to work on i.e. the data on which client nodes need to execute is
> same for many other nodes on the network. Currently, each client contacts
> the server individually to fetch the data. This increase load on the server
> unnecessarily. If the size of the file is very large then the problem would
> be highly magnified.
>
> Second observation is that the local bandwidth are mostly fast and runs
> into Gbps. In a cluster, many clients would share the same geography and
> thus have fast interconnects between them. The server might be connected
> through a slow network link. In this situation, accessing data from another
> client would be much faster than accessing data from server itself.
>
> Just one guy's opinion, but I like this. The more I think about it, the
> more I like it.
>
> One long-term benefit of this is in clusters. We've seen a number of
> instances where folks have attempted to use AFS as if it were a clustered
> file system, keeping various lockfiles, etc in the fs. It beat the hell out
> of our AFS servers when it happened. If a fs could delegate responsibility
> for such lockfiles to a local node, it's make that sort of thing feasible
> and fast.
>
> Steve
>
>

--001636c59539d2b5fa048468c9a7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Here is what I know about the cache manager and its file server interaction=
s.<br>
The Cache Manager<span class=3D"emphasis"><em></em></span> 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.<span class=
=3D"emphasis"><em></em></span>
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.<br><br>So in this proje=
ct, we need to modify the cache manager to enable interactions with other c=
lients as well.<br>In the first part of the project, where the cache manage=
r 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 callb=
ack 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.<br>
<br>In the second part of the project, we can allow discovery of peer clien=
ts 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 clien=
ts. In order to maintain cache consistency, the requesting client also esta=
blishes a callback guarantee from the file server so that it knows of the m=
odifications in the file irrespective of where it has got the file from.<br=
>
<br>I have seen the files afs_callback.c, cbqueue.c, dcache.c and server.c =
and think that these are some of the programs used in cache manager and ser=
ver-cache manager interactions. Please correct me if I am wrong.<br><br>
Thank You.<br><br>Shruti<br><br><div class=3D"gmail_quote">On Wed, Apr 14, =
2010 at 8:15 PM, Derrick Brashear <span dir=3D"ltr">&lt;<a href=3D"mailto:s=
hadow@dementia.org">shadow@dementia.org</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204);=
 margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF"><div>Steve,=A0</div><div><br></div><div>You should=
 like it. The idea was already implemented at Michigan once (ifs, the inter=
mediate fileserver)<br><font color=3D"#888888"><br>Derrick<div><br></div></=
font></div>
<div><div></div><div class=3D"h5"><div><br>On Apr 14, 2010, at 10:36 AM, St=
eve Simmons &lt;<a href=3D"mailto:scs@umich.edu" target=3D"_blank">scs@umic=
h.edu</a>&gt; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div=
><div>
<div>On Apr 13, 2010, at 10:12 AM, shruti jain wrote:</div><blockquote type=
=3D"cite"><span style=3D"border-collapse: separate; font-family: Courier; f=
ont-size: medium; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-t=
ransform: none; white-space: normal; word-spacing: 0px;"><p>
The project aims at developing a system which would use collaborative cachi=
ng techniques to improve the read accesses in OpenAFS. This project is base=
d on two observations.</p><p>Firstly, in a cluster environment, a large num=
ber of clients need same datasets to work on i.e. the data on which client =
nodes need to execute is same for many other nodes on the network. Currentl=
y, each client contacts the server individually to fetch the data. This inc=
rease load on the server unnecessarily. If the size of the file is very lar=
ge then the problem would be highly magnified.</p>
<p>Second observation is that the local bandwidth are mostly fast and runs =
into Gbps. In a cluster, many clients would share the same geography and th=
us have fast interconnects between them. The server might be connected thro=
ugh a slow network link. In this situation, accessing data from another cli=
ent would be much faster than accessing data from server itself.</p>
</span></blockquote></div>Just one guy&#39;s opinion, but I like this. The =
more I think about it, the more I like it.<div><br></div><div>One long-term=
 benefit of this is in clusters. We&#39;ve seen a number of instances where=
 folks have attempted to use AFS as if it were a clustered file system, kee=
ping various lockfiles, etc in the fs. It beat the hell out of our AFS serv=
ers when it happened. If a fs could delegate responsibility for such lockfi=
les to a local node, it&#39;s make that sort of thing feasible and fast.</d=
iv>
<div><div><br></div><div>Steve</div></div></div></blockquote></div></div></=
div></blockquote></div><br>

--001636c59539d2b5fa048468c9a7--