\documentstyle[]{article}
\addtolength{\oddsidemargin}{-1in}
\addtolength{\evensidemargin}{-.5in}
\addtolength{\textwidth}{1.75in}
\addtolength{\textheight}{1.75in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#8: Scalability in the Coda File System\\\\

The Athena computing environment, comprising several thousand
workstations, currently uses the AFS distributed file system.  Coda,
one of it's successors, is intended to be used in similar, or even
larger computing environments.  It must be able to handle failure of
the central file servers and the detachment of any one of the hosts
connecting to them, then resynchronize files when the detachment
period ends.  Given this set of goals, the designers of Coda tried to
build scalability into their design from the onset.  Their policies
included doing file caching on a whole-file basis, client-side
functionality, and optimistic file synchronization.  By using these
policies, the authors hope to make use of their file system in a truly
large environment a trivial extension from limited test runs.

In the Coda file system, when a user begins to read or otherwise
access a file for the first time, the entire file is brought onto the
local disk and cached.  This is in contrast to some file systems,
which only access files only as requested by the user.  This leaves
open the possibility that a user can be reading the beginning of a
file, the central file system crashes, and the user is unable to read
the end of the file.  Coda instead copies the entire file locally, so
that once it is on the local disk, either detachment from the file
system or a failure of the servers, usage of that file can proceed
without the user noticing.  This also makes synchronization of the
file easier when the file sytem is rejoined -- the entire file can be
dealt with, instead of trying to merge along some boundary point,
which may have been destroyed during changes while the file system was
detached.

Each client is responsible for maintaining it's own cache, keeping
track of the state of the central file servers, and synchronizing
files that have changed while the server was unaccessable.  This
increases scalability, because increasing the number of hosts
connected to servers does not increase the load on the servers.  Thus,
although the servers need to take a minimal role during the
synchronization process (to provide locks possibly), additional hosts
in no way impact the servers.  Additionally, this setup makes it
possible to handle the robust side of their design -- were servers to
take part in cache maintnance, then the loss of a server would be
highly noticed.  However, this added functionality can make merging
files back into the main tree very difficult, if several users have
made changes on the file while disconnected from the servers.
However, this setup does increase the complexity of the client-side
code, as compared to a evenly mixed distribution of work.

Finally, scalability is achieved via optimistic file synchronization,
where unattached modifies by one user don't block other users.
Although this area was not explicitly covered in the paper as a
scalability issue, maintainers quickly would have discovered that the
other option (pessimistic synchronization) would frequently prevent
them from updating their systems.  For example, most users would
certainly have the essential sytem binaries (ls, more, emacs, etc.)
with them when taking a mobile system elsewhere, and were the original
to be locked while they were gone, this would quickly lead to
continual locking of the binaries, preventing upgrades.  Furthermore,
group access to a file would become impossible once members needed to
detach from the servers; all other members would be denied the ability
to modify the file.  


There are many simple ways of limiting a design from the very
beginning, crippling the final product such that it will neither scale
well nor perform as expected.  Escaping such problems requires much
forethought, and the Coda designers attempted to give it such.  They 
used whole-file caching to increase simplicity of design and
implementation, put as much functionality on the client to prevent
overloading the servers as the system grew, and chose optimistic file
synchronization to prevent continual locking of resources as more
users attempted to access them.  This combination of design decisions
at least avoids many common pitfals, if not provides for a completely
scalable design.

\end{document}

