This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via 797ca0a10d9dd026fea99f06db4862007be2b67c (commit)
from f0df8ea2d7929b5bd0199673e7165a2749060d95 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 797ca0a10d9dd026fea99f06db4862007be2b67c
Author: cengiz <cengiz(a)snslmini.(none)>
Date: Fri Aug 30 18:00:42 2013 -0400
Replaced 'an operation's with 'the operation's in Section III
-----------------------------------------------------------------------
Summary of changes:
papers/asg-osd/sections/proposed_model.tex | 77 +++++++++-------------------
1 files changed, 25 insertions(+), 52 deletions(-)
Diff of changes:
diff --git a/papers/asg-osd/sections/proposed_model.tex b/papers/asg-osd/sections/proposed_model.tex
index fde2caf..5c34318 100644
--- a/papers/asg-osd/sections/proposed_model.tex
+++ b/papers/asg-osd/sections/proposed_model.tex
@@ -26,7 +26,7 @@ The main architecture of the ASG storage model is shown in Figure
Each record consists of a key, a version number, data and length of data.
The key, version number and length of data are represented with integers;
whereas data is an array of bytes of variable length. Key is the numerical
- identifier of a record. Version numbers are used to order write operations
+ identifier of a record. Version numbers are used to order the write operations
to the record. The Data field can be empty and a record at its \textit{initial
condition} will have version number \textit{zero} and will contain no
data. Note that the length of all records can be set to 1 byte in order
@@ -51,21 +51,17 @@ The main architecture of the ASG storage model is shown in Figure
\end{itemize}
-The record, fork and object identifiers in ASG storage model are not global.
+The record, fork and object identifiers in the ASG storage model are not global.
For example; two different containers can have objects with the same
identifiers. Similarly, two different objects or forks can have forks or
records with the same identifiers.
\subsection{Operations}
-\cengiz{THis whole section: not 'read operation' but 'THE read operation'.
-THE ASG storage model.}
-
In this section we describe the ASG storage model operations a client can use
-to interact with the storage system. All ASG storage model operations are
+to interact with the storage system. All of the ASG storage model operations are
atomic; meaning that intermediate steps of an operation between its invocation
and completion are not visible to higher-level applications.
-%\todo{indicate that all operations are atomic}
\cengiz{Point out that this goes beyond what is needed (refer back to overview
of four categories, but mention that there is no cost unless writes conflict}
@@ -73,7 +69,7 @@ of four categories, but mention that there is no cost unless writes conflict}
\subsubsection{write}
-\textit{write} operation stores data in a sequential range of records. The
+The \textit{write} operation stores data in a sequential range of records. The
input arguments to this function are the location information (container,
object, fork and starting record identifiers), local buffer that stores the
data to be written, number of records to be modified, conditional flags and a
@@ -101,9 +97,9 @@ version numbers:
\end{itemize}
-A successful write operation returns the size of the written data and the
-newly assigned version number. It is also possible to do a write operation
-with zero-length data.
+When the write operation is completed successfully, it returns the size of the
+written data and the newly assigned version number. The write operation can also
+take zero-length data as an input argument.
\cengiz{Explain that other properties (version, \ldots) are preserved}
\cengiz{Talk about how when writing mulitple records, each record has the same
length (which keeps record overhead low)}
@@ -137,20 +133,20 @@ The conditional flag can be set to one of the following three values:
\end{itemize}
-A successful read operation returns the number of the records read in addition
-to the version number of these records.
+When the read operation is completed successfully, it returns the number of
+the records read in addition to the version number of these records.
\subsubsection{reset}
-\textit{reset} operation returns an entity (container, object, fork or record)
+The \textit{reset} operation returns an entity (container, object, fork or record)
back to its \textit{initial condition}. In an entity at its original
condition, all the record(s) will have version number \textit{zero} and will
contain no data. The reset operation takes in the identifier information of the
entity to be reset as an input argument and it also supports conditional
execution based on the existing version number and given conditional flags.
The conditional flags that can be used with the reset operation are the same
-with the conditional flags used in read operation. A successful reset
-operation returns the number of entities reset.
+with the conditional flags used in the read operation. When the reset operation
+is completed successfully, it returns the number of entities reset.
\subsubsection{probe}
@@ -161,74 +157,51 @@ operation takes in the identifier information of the entity (container, object
or fork) to be probed as an input argument, an entity id to start with, a
local buffer to store the retrieved information, and the maximum number of
entities for which the information will be retrieved. If probe is called on
-the entire system then there is no need to provide an identifier. A probe
-operation on a fork also returns the version number of each record in the fork.
+the entire system then there is no need to provide an identifier. The probe
+operation on a fork also returns the version number of each record in the fork.
\subsection{Relation to data model requirements}
-%\textcolor{red}{TODO: somewhere around here we need to revisit the list of
-%requirements provided earlier and show how the model we presented here meets
-%those requirements. We unified byte stream and key/value storage into a
-%single mechanism (bytes are just 1 byte records) to support both file-like
-%and key/value access models. We eliminated attributes normally found in
-%object storage models, because this functionality can be provided by
-%reserved forks. Record versioning allows for highly concurrent writes to
-%remain consistent (especially across distributed replicas). Conditional read and write
-%flags provide synchronization primitives. Independently addressable,
-%versioned records serve as the lowest level atomic unit. Forks allow data
-%models to group data for locality. We need to say something about the
-%server location stuff (not mentioned so far in the paper?) can be used to
-%support compute/storage locality for MapReduce.}
-
-%\textcolor{red}{TODO: point out that none of these features are new (point
-%out key papers that describe forks, byte-granulary versioning,
-%record-oriented storage, etc- we are just trying to bring them together in a
-%reusable unified API while minimizing complexity and corner cases. Some
-%thoughts about minimizing complexity: you don't have special attribute API with different semantics than
-%the rest of the API, you don't have special atomic modes; all access is
-%atomic. Records are first-class citizens, you don't have to translate from
-%records into byte streams, etc.}
-
In this section, we introduce the features provided by the ASG storage model and
explain how they make it possible to meet the requirements of the common data models
listed in Table~\ref{tbl:reqs}. It is important to note that none of these features are new;
-ASG storage model just presents a reusable unified API bringing these features together
+the ASG storage model just presents a reusable unified API bringing these features together
while minimizing complexity. The features provided by the ASG storage model and how they
can be used to meet the requirements of common data models can be summarized as follows;
-\textcolor{red}{TODO: examples for each}
\begin{itemize}
\item\textbf{~\textit{Unified byte stream and key/value storage}}:
-ASG storage model supports both byte-stream~\cite{Welch08scalableperformance} and key/value based
+The ASG storage model supports both byte-stream~\cite{Welch08scalableperformance} and key/value based
storage~\cite{dynamodb}. Each byte is stored as a one-byte record. With the numerical identifiers
-and record contents, each record can be also used as a key/value store. As a result, ASG storage
+and record contents, each record can be also used as a key/value store. As a result, the ASG storage
model supports both file based and key/value based access models and also enables record oriented
access for both of these models.
\item\textbf{~\textit{Eliminating object attributes}}:
Object-based storage models, such as T10~\cite{osd-3}, use attributes to describe the objects;
-meaning that object attributes are used to store metadata. In ASG storage model, we still have
+meaning that object attributes are used to store metadata. In the ASG storage model, we still have
metadata describing the records; however we do not store them in separate attributes as it is
normally done in object-based storage models. The functionality of describing records can be provided
by reserved forks. Maintaining metadata in reserved forks gives opportunity to better scale data
stored in records and to meet the high performance requirement of common data models. This feature also
makes it possible to move data closer to computation to preserve compute/storage locality.
\item\textbf{~\textit{Record versioning}}
-Versioning in ASG storage model enables sorting writes to a record as shown in previous
+Versioning in the ASG storage model enables sorting writes to a record as shown in previous
studies~\cite{1251033, carns2010object}. As the version number changes with each write operation,
-highly concurrent write operations will be consistent and the performance of the system will increase.
+highly concurrent write operations will be consistent and the performance of the system will increase.
\item\textbf{~\textit{Conditional operations}}
-Conditional read and write operation flags provide synchronization primitives and atomicity in a data
+The conditional read and write operation flags provide synchronization primitives and atomicity in a data
model as it was previously shown in a couple of storage models~\cite{carns-pdsw12, simpledb, dynamodb, redis, hyperdex_atomic}.
-Using the conditional flags with ASG storage model operations, multiple processes can coordinate
+Using the conditional flags with the ASG storage model operations, multiple processes can coordinate
concurrent writes without using any explicit locking method. Using conditional flags also ensures that
each ASG operation is completed with intermediate steps between their invocation and completion remaining
unvisible to higher-level applications.
\item\textbf{~\textit{Independently addressable records}}
ASG is a record-oriented storage model similar to some previous data models~\cite{openvms-files-11, Lovelace:2003:VD:1406022}.
-Each entity in ASG storage model has a numerical identifier and when ASG primitives access a record, they
+Each entity in the ASG storage model has a numerical identifier and when ASG primitives access a record, they
explicitly use the identifiers of the enclosing container, object and fork along with the identifier of
that record. As a result, each record in ASG has a distinct location and they are independently accessable.
-Records are the smallest units of storage an operation can access in ASG model. Having access to independently
+Records are the smallest units of storage an operation can access in the ASG storage model. Having access to
+independently
addressable records makes it possible to support atomicity and concurrent read access since each record is
independently accessable.
\item\textbf{~\textit{Fork structure}}
hooks/post-receive
--
