gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/storm article.rst


From: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/storm article.rst
Date: Mon, 27 Jan 2003 22:39:08 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/27 22:39:08

Modified files:
        storm          : article.rst 

Log message:
        more. nuff for today I think

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.42&tr2=1.43&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.42 manuscripts/storm/article.rst:1.43
--- manuscripts/storm/article.rst:1.42  Mon Jan 27 22:10:11 2003
+++ manuscripts/storm/article.rst       Mon Jan 27 22:39:08 2003
@@ -125,7 +125,20 @@
 We present Storm (for *storage module*), a design which addresses the issues 
 we have described. 
 
-This paper is structured as follows.
+The main contributions of this paper are...
+
+->
+This paper is structured as follows. In section 2, we introduce
+the basic storage unit of our system, file-like blocks of data 
+identified by cryptographic hashes. In section 3, we discuss 
+our implementation of Xanalogical storage on top of the block system. 
+In section 4, we discuss application-specific reverse indexing 
+of blocks by their content, essential for most applications.
+In section 5, we present techiques for efficient versioned storage
+of mutable data on top of blocks. In section 6, we discuss 
+potential peer-to-peer implementations of Storm. In section 7, 
+we report on implementation experience and future directions. 
+Section 8 concludes the paper.
 
 
 2. Block storage
@@ -221,7 +234,22 @@
 =============
 
 Clearly, for block storage to be useful, there has to be a way to
-update
+efficiently update documents. We archieve this by a combination of 
+two mechanisms. Firstly, a *pointer* is an updatable reference to a block;
+pointers can be updated by creating a specific kind of Storm block
+representing an assertion of the form, "pointer ``P`` now points
+to block ``B``." Pointers are resolved with the help of a Storm index 
+mapping pointer identifiers to blocks providing targets for that pointer.
+Through this mechanism, we can keep old versions of documents
+along with the current versions.
+
+Secondly, in the spirit of version control systems like CVS,
+we do not store each version, but only the differences between versions.
+However, we still refer to each full version by the id of a block
+containing that version, even though we do not store this block.
+When we want to access a particular version, we reconstruct it
+using the differences, and then check the result using
+the cryptographic hash in the full version's block id.
 
 
 5.1. Pointers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]