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

We evaluated the system using a trace of NFS activity from the Berkley
Auspex file
system~\cite{blaze92:_nfs_tracin_by_passiv_networ_monit}. We compared
conventional optimistic concurrency control to our read-optimized OCC
algorithm for a
number of performance metrics: network traffic, and client and server
CPU usage. In each case, we found that our system offered substantial
improvements over OCC for the file system workload.  While both
algorithms provide global serializability, conventional OCC incurs
the additional cost of providing global causality, which this
experiment quantifies.

The trace runner constructs a simple file system atop the block store
and simulates the contents of the trace.  For each host in the trace,
the trace runner constructs an independent instance of the client
library, complete with its own cache.  The trace is replayed by
simulating an ext2-like file system complete with fixed-size data
blocks, inodes, indirect inodes and doubly indirect inodes.

Since the workload is not transactional, transactions were inferred
from open and close requests. Stat requests were
assumed to be single operation transactions. Another option for inferring
transactions would have been to assume one transaction per file system
operation. This assumption more closely emulates POSIX semantics, but
does not exercise the system as well because the transactions are much
shorter.

The trace runner simulates conventional OCC by strictly using
read/write transactions, even for transactions that perform only
reads.  In a pure read/write workload, our algorithm reduces to
conventional OCC, with the optimization of active aborts.

\begin{table*}[ht]
  \centering
  \begin{tabular}{|c|c|c|c|c|}
    \hline
    &Conventional&\multicolumn{3}{c|}{OCC with Read Optimization}\\
    &OCC&$\epsilon = 2$ secs&$\epsilon = .1$ secs&$\epsilon = 0$ secs\\
    \hline
    Network traffic&34.8 MB&27.19 MB&28.14 MB&28.14 MB\\
    Avg. client CPU time&.66 secs&.22 secs&.25 secs&.43 secs\\
    Server CPU time&32.67 secs&9.55 secs&13.07 secs&25.63 secs\\
    \hline
  \end{tabular}
  \caption{Performance results for a trace of 100,000 file system operations. The
    trace was run with conventional OCC and read-optimized OCC with different
    freshness requirements, $\epsilon$.}
  \label{tab:results}
\end{table*}

Table~\ref{tab:results} presents the performance of our system for
100,000~file system operations, spanning approximately 1~hour of the
trace and involving 134~distinct clients. Transaction inference
yielded 65883~read-only transactions and 3882~read/write
transactions. In all situations, about 100 transactions were aborted
due to conflicts.

Read-optimized OCC performs better all around because a large
percentage of the file system workload is read-only. Network traffic
is reduced because read-only transactions do not need to communicate
with the server. Aggregate CPU usage is reduced because less overhead
is incurred validating and serializing read-only transactions.

Unfortunately, because the Auspex traces were gathered by snooping NFS
traffic, they cannot account for the effects of client-side NFS
caching.  This reduces the effectiveness of our own system's caching
for the trace and thus the overall performance of read-optimized OCC.
Therefore, for a complete file system trace, we would expect the
performance benefits of our system over conventional OCC to be even
more dramatic.

% Would be nice to have: comparisons to normal OCC (just make all
% transactions R/W), maybe locking of some kind; some semblance of how
% much disk space is required and how often transactions actually run in
% the past (average staleness?).