% -*- TeX-master: "report.tex"; TeX-PDF-mode: t -*-

Our system exposes a transactional, distributed block store
interface.  The generality of a block store allows it to serve as the
storage layer for a range of applications, from distributed database
systems to transactional file systems, etc.

As shown in Figure~\ref{fig:model}, a centralized block server
provides primary storage for block data.  Each client application
connects to the server through a standard client library.  This
library presents a procedural transactional block store interface to
the application and manages communications with the server as well as
client-side caching.

\begin{figure}
  \centering
  \includegraphics{model.pdf}
  \caption{System model}
  \label{fig:model}
\end{figure}

While frontend applications could be built directly atop the client
library, the library interface is intended for backend applications,
which then re-expose some application-specific interface to the local
host.  For example, a database engine could be built atop the library,
which would then expose a SQL interface to local database clients.
Alternatively, a file system service could be built atop the library,
which would then expose a file system interface to local applications
through some kernel mechanism.

In addition to taking better advantage of per-host resources, this
client-per-node structure may be necessitated by the causality
requirements of the application.  In particular, causality is
guaranteed for all operations performed through a particular instance
of the client library, but not between instances, even if running on
the same host.  For example, a file system that created an instance of
the client library for each application would expose the user of the
file system to violations of causality, even on a single host.  Thus,
the design of any application of the block store would have to account
for the application's causality requirements.  It may be possible to
provide more flexible causality guarantees, but this is future work.

The client library itself presents a fairly straightforward block
store interface.  A block store object acts as a factory for
read/write and read-only snapshots, which provide methods for reading
blocks and committing and (in the case of read/write snapshots)
writing blocks, creating new blocks, and aborting.  Any operation on a
read/write snapshot can potentially abort, so applications must be
prepared to handle this possibility.