branch, master, updated. ebc9d1c76675afdacc7277bc87f6cc8e15a6b2ed
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 ebc9d1c76675afdacc7277bc87f6cc8e15a6b2ed (commit) via cd9355d9effba6171fad3543286a609420348297 (commit) from 853e184fca61c76199d1e40426171a6b26c4cdb1 (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 ebc9d1c76675afdacc7277bc87f6cc8e15a6b2ed Author: Cengiz <[email protected]> Date: Fri Jul 26 08:06:10 2013 -0400 More modifications to Section II-C * Need to add examples to each feature to show that they are not new commit cd9355d9effba6171fad3543286a609420348297 Author: Cengiz <[email protected]> Date: Thu Jul 25 08:20:14 2013 -0400 Some initial work on the last section of proposed model ----------------------------------------------------------------------- Summary of changes: papers/asg-osd/sections/namespace_usecase.tex | 2 + papers/asg-osd/sections/proposed_model.tex | 47 +++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 0 deletions(-) Diff of changes: diff --git a/papers/asg-osd/sections/namespace_usecase.tex b/papers/asg-osd/sections/namespace_usecase.tex index a4b35b3..df32e26 100644 --- a/papers/asg-osd/sections/namespace_usecase.tex +++ b/papers/asg-osd/sections/namespace_usecase.tex @@ -47,6 +47,8 @@ The namespace implementation has \textit{insert}, \textit{remove}, Thse operations are mostly POSIX-compliant and they call underlying ASG storage model primitives, defined in Section \ref{primitives}, in order to accomplish their functionalities. Namespace operations for integer keys are shown in Figure~\ref{fig:integer-ops}. +Namespace operations for string keys are mostly similar to the namespace operations for integer keys +except for the computation of integer hash of the string keys. \textcolor{red}{TODO: should we insert a figure describing string key operations?} \begin{figure}[!t] diff --git a/papers/asg-osd/sections/proposed_model.tex b/papers/asg-osd/sections/proposed_model.tex index ae8f2b4..fc6da63 100644 --- a/papers/asg-osd/sections/proposed_model.tex +++ b/papers/asg-osd/sections/proposed_model.tex @@ -167,3 +167,50 @@ thoughts about minimizing complexity: you don't have special attribute API with 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 +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 and key-value based storage. Each byte is stored as +a one-byte record. With the numerical identifiers, each record can be also used as a key-value store. +As a result, 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 +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 the version number changes +with each write operation, 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 +model. Using the conditional flags with 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}} +Each entity in 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 +addressable records makes it possible to support atomicity and concurrent read access since each record is +independently accessable. +\item\textbf{~\textit{Fork structure}} +Forks can be used to store metadata as discussed previously. In addition to that, they can also be used to +group records that store related data together. This approach enables to move related data closer to computation +to preserve compute/storage locality and to collect provenance from related records in an efficient way to +support fault tolerance. +\item\textbf{~\textit{Server location}} +\end{itemize} hooks/post-receive --
participants (1)
-
noreply@mcs.anl.gov