\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 \#9: Serverless Network File System\\\\

The Serverless Network File System (xFS) presents an interesting new
approach to designing a file system.  Instead of relying upon central
servers to control the filesystem, then using client caching to
improve performace, xFS moves the entire file system onto the clients,
such that each client acts both as a file accessor, and possibly as a
file repository.  Files are stored in a manner similar to the Zebra
file system, such that a file can still be recovered if one of the
hosts storing it crashes.  Furthermore, each client can take up the
responsibilities of any other client, if the other one dies.  However,
despite these safeguards, there remain some single points of failure
that can take down a xFS network.

The physical file layout that xFS uses is a globally replicated stripe
map, where data is striped similar to the Zebra filey system, but the
stripes are duplicated accross several clients.  Thus, when a client
wants to write data, it will look up the appropriate stripe for the
data in the map, and send it to appropriate other clients, as well as
writing the data to its own disk.  When another client wants to read
back the data, it consults the same map, and can contact the
appropriate hosts to obtain data and parity bits.  In the same way
that RAID systems can continue to run after losing disks, xFS clients
can still read and write data even when some of the other clients go
down.  This is a major gain in availability over NFS and AFS, where
all data stored on a volume is unavailable if the server controlling
it goes down.

Unlike AFS and NFS, which require central servers to coordinate file
updates, cleanup, and access, xFS has some of the clients do double
duty, running the storage server, manager, and cleaner programs.
These programs are responsible for storage and file recovery, tracking
where files are, and garbage collection, respectively.  The key
distributed aspect of this is that when one client fails to act in its
assigned role, another client can coopted into doing so.  All data
needed for servers is globally replicated, so any client can pick up
where others have left off, after a crash for example.  

Unfortuntely, xFS is not perfect.  There are several points where a
single client failure can still take out the rest of the clients, thus
being equivalent to a crashed server.  For example, if a client gets
confused, and begins to broadcast invalid data, in a stripe map for
example, the other clients will accept this data, quite possibly
leading to major crashes.  Also, networking errors, such as a packet
flood by one host, can prevent any client from communicating with
others, and thus being able to read a file.  These failure points are
very difficult to prevent, and are certainly also present in
client-sever models, but nonetheless are still single points of
failure in xFS.

Thus, xFS does quite a good job of distributing responsibility for the
data that is being stored in it.  The striping mechanism used by xFS
is very good at allowing recovery and quorum reading of files, such
that several clients can fail, and the rest will be able to continue
to work normally.  Furthermore, the ability of any client to take up
the responsibilities of any other makes it very easy for an xFS
network to adapt to having some clients fail.  There exist some faults
in the protocol, such as one confused client confusing many other
clients, but in general, xFS does a good job at eliminating most
single points of failure.


\end{document}


