/[gzz]/manuscripts/storm/article.rst
ViewVC logotype

Diff of /manuscripts/storm/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.42 by benja, Tue Jan 28 03:10:11 2003 UTC revision 1.43 by benja, Tue Jan 28 03:39:08 2003 UTC
# Line 125  We are currently in prototype stage, whi Line 125  We are currently in prototype stage, whi
125  We present Storm (for *storage module*), a design which addresses the issues  We present Storm (for *storage module*), a design which addresses the issues
126  we have described.  we have described.
127    
128  This paper is structured as follows.  The main contributions of this paper are...
129    
130    ->
131    This paper is structured as follows. In section 2, we introduce
132    the basic storage unit of our system, file-like blocks of data
133    identified by cryptographic hashes. In section 3, we discuss
134    our implementation of Xanalogical storage on top of the block system.
135    In section 4, we discuss application-specific reverse indexing
136    of blocks by their content, essential for most applications.
137    In section 5, we present techiques for efficient versioned storage
138    of mutable data on top of blocks. In section 6, we discuss
139    potential peer-to-peer implementations of Storm. In section 7,
140    we report on implementation experience and future directions.
141    Section 8 concludes the paper.
142    
143    
144  2. Block storage  2. Block storage
# Line 221  they are on. Again, see Section 6.) Line 234  they are on. Again, see Section 6.)
234  =============  =============
235    
236  Clearly, for block storage to be useful, there has to be a way to  Clearly, for block storage to be useful, there has to be a way to
237  update  efficiently update documents. We archieve this by a combination of
238    two mechanisms. Firstly, a *pointer* is an updatable reference to a block;
239    pointers can be updated by creating a specific kind of Storm block
240    representing an assertion of the form, "pointer ``P`` now points
241    to block ``B``." Pointers are resolved with the help of a Storm index
242    mapping pointer identifiers to blocks providing targets for that pointer.
243    Through this mechanism, we can keep old versions of documents
244    along with the current versions.
245    
246    Secondly, in the spirit of version control systems like CVS,
247    we do not store each version, but only the differences between versions.
248    However, we still refer to each full version by the id of a block
249    containing that version, even though we do not store this block.
250    When we want to access a particular version, we reconstruct it
251    using the differences, and then check the result using
252    the cryptographic hash in the full version's block id.
253    
254    
255  5.1. Pointers  5.1. Pointers

Legend:
Removed from v.1.42  
changed lines
  Added in v.1.43

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26