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 |
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 |