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 ba12e1b7bec33f2a1fbc1104c82618ef7ba04c59 (commit) from b3de0ee358fb365fbb5cd12025bc8732c8e617a4 (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 ba12e1b7bec33f2a1fbc1104c82618ef7ba04c59 Author: cengiz <[email protected]> Date: Thu May 16 03:03:05 2013 -0400 Minor spelling changes to abstract *Third use case is ok imho ----------------------------------------------------------------------- Summary of changes: papers/asg-osd/sections/abstract.tex | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) Diff of changes: diff --git a/papers/asg-osd/sections/abstract.tex b/papers/asg-osd/sections/abstract.tex index e5775ef..9c1d5db 100644 --- a/papers/asg-osd/sections/abstract.tex +++ b/papers/asg-osd/sections/abstract.tex @@ -7,15 +7,15 @@ resources. Although many large-scale storage systems share common goals of performance, scalability and fault tolerance, their underlying object storage models are typically tailored to specific use cases and semantics, making it difficult to reuse them in other environments and leading to -unecessary fragmentation of data center storage facilities. In this paper +unnecessary fragmentation of data center storage facilities. In this paper we propose a new distributed object-based storage model that seeks to -unify the common underlying primitives for big data, cloud storage, +unify the common underlying primitives for big data, cloud storage and HPC storage. We investigate five popular categories of data models from these environments and determine the unique requirements that distinguish them. We then identify key features from previous object storage systems that address these requirements and explore how they can be unified effectively without sacrificing usability. We validate the -effectiveness of our approach with by evaluataing how the API could be +effectiveness of our approach by evaluating how the API could be used in the construction of three diverse but representative use cases: -a POSIX file system name space, a column-store NOSQL database, and a +a POSIX file system name space, a column-store NOSQL database and a \todo{is this third use case right?} data set with concurrent writers. hooks/post-receive --