Cache Manager

[Assar Westerlund]

wwshen at eecs.umich.edu writes:
> So you mean that AFS is "last close wins".

Yes.

> So why do we need the callback?

Callbacks are used for maintaining cache coherency.  Once you have a
callback the file server guarantees it will tell you before changing
that file.  This means that you can cache it and use your cached copy
until you get the callback.

>    I am trying to reading your source code. As far as I know about AFS,
> the file open system call, issued by the application program, is
> intercepted by a small "hook" installed in the workstation's kernel.
> The user's program is suspended and the intercepted request is divereted
> to the Cache Manager, implemented as a user-level process on the
> workstation.

That's more or less how it works in Arla.  In the Transarc
implementation all of this takes place in the kernel.

> The cache manager then forwards the file request to a file
> server, receives the file, stores it on the local disk, .....  So could
> you tell me which files and functions in arald implement the beginning
> function of the cache manager? I think your detailed explanation will
> help me to understand how you do it?

What happens is basically this (from the point of view of arlad):

1. the kernel module notices it doesn't have the data of particular
file and sends a message to arlad over the xfs character device
2. this message is read from the cdev by process_message() and calls xfs_message_recieve()
3. xfs_message_recieve() looks at the type of message and call the
relevant function.  let's assume it's a `getdata'
4. xfs_message_getdata() will eventually call cm_open()
5. cm_open() calls fcache_get_data()
6. fcache_get_data() looks and see if the data is cached.  If it's not
it calls read_data()
7. read_data() retrieves data from the file server over rx (with
RXAFS_FetchData)
8. read_data() writes it into a local cache file
9. xfs_message_getdata() sends back a handle to the cache file to the
kernel module

/assar