Re: Alternate solutions

Christopher M Hanson (
Mon, 29 Jul 1996 20:44:12 -0400 (EDT)

Excerpts from internet.computing.linux-kernel: 29-Jul-96 Re: Alternate
solutions by Kai Henningsen@khms.west
> In such a scenario, cache coherency might, for example, work like this:
> * Possible scenarios:
> 1 One client has read-write access to a piece of cache.
> No client has read-only access.
> 2 One or more clients have read-only access to a piece of cache.
> No client has read-write access.
> 3 No client has access to a piece of cache.
> (You might want to handle the server's local fs underlying the net fs as
> another client here.)

(Before I present my information, I'd like to note that I have no
definite knowledge that this is how AFS does things. This appears to be
what is happening, and from conversations with people here at CMU and
osmosis I believe I have a handle on how this works.)

AFS handles another case:

4 One or more clients have read-only access to a piece of cache. At
least one client (I don't know if there can be more than one) has
read-write access to a piece of cache.

It accomplishes things like this via callbacks -- essentially,
asynchronous notifications from the server to the clients telling them
that something has changed. (Note that "the clients" in this case are
the AFS daemons on workstations, not emacs sessions and the like.) It
can do this because the server knows what files people have open for
reading, what files are open for reading and writing, and what files are
no longer open but still in the cache.

Also, AFS allocates a portion of the client workstation's local disk as
cache so not everything gets referenced across the network all the time.
When I log in to a workstation and start a lot of xterms, my .cshrc is
only copied from the server once to the local cache and then accessed
from there. And even if I open up my .cshrc to change something with
vi, other people (if system:anyuser has read access on my home
directory) can still read the previous version until my changes are
written out.

I've been inquiring with some people here about an AFS port to MkLinux
on PowerMac. I've been consistently told by those who would know --
i.e. people who've read the code or ported it -- that the cache manager
is highly nontrivial and is the hardest part to portt. However, I think
a comparable caching & coherency scheme for a new distributed filesystem
would be worth doing, and worth doing right.

If people want I can try and scare up some time to find references to
papers, conference proceedings, etc. for AFS and Coda in our library
system here at CMU.

Chris Hanson (,

"I always find my self wondering how people who
can't code manage to get through life."
-Steve Gifford