-= Tahoe-LAFS Architecture =
-2. The Key-Value Store
-3. File Encoding
-4. Capabilities
-5. Server Selection
-6. Swarming Download, Trickling Upload
-7. The Filesystem Layer
-8. Leases, Refreshing, Garbage Collection
-9. File Repairer
-10. Security
-11. Reliability
-
-== Overview ==
+ Tahoe-LAFS Architecture
(See the docs/specifications directory for more details.)
+OVERVIEW
+
There are three layers: the key-value store, the filesystem, and the
application.
filesystem (see the RelatedProjects page of the wiki for a list).
-== The Key-Value Store ==
+THE KEY-VALUE STORE
The key-value store is implemented by a grid of Tahoe-LAFS storage servers --
user-space processes. Tahoe-LAFS storage clients communicate with the storage
server to tell a new client about all the others.
-== File Encoding ==
+FILE ENCODING
When a client stores a file on the grid, it first encrypts the file. It then
breaks the encrypted file into small segments, in order to reduce the memory
into plaintext, then emit the plaintext bytes to the output target.
-== Capabilities ==
+CAPABILITIES
Capabilities to immutable files represent a specific set of bytes. Think of
it like a hash function: you feed in a bunch of bytes, and you get out a
key-value layer.
-== Server Selection ==
+SERVER SELECTION
When a file is uploaded, the encoded shares are sent to some servers. But to
which ones? The "server selection" algorithm is used to make this choice.
long-term connections, at the expense of complexity and latency.
-== Swarming Download, Trickling Upload ==
+SWARMING DOWNLOAD, TRICKLING UPLOAD
Because the shares being downloaded are distributed across a large number of
nodes, the download process will pull from many of them at the same time. The
See "helper.txt" for details about the upload helper.
-== The Filesystem Layer ==
+THE FILESYSTEM LAYER
The "filesystem" layer is responsible for mapping human-meaningful pathnames
(directories and filenames) to pieces of data. The actual bytes inside these
that are globally visible.
-== Leases, Refreshing, Garbage Collection ==
+LEASES, REFRESHING, GARBAGE COLLECTION
When a file or directory in the virtual filesystem is no longer referenced,
the space that its shares occupied on each storage server can be freed,
garbage collection.
-== File Repairer ==
+FILE REPAIRER
Shares may go away because the storage server hosting them has suffered a
failure: either temporary downtime (affecting availability of the file), or a
in client behavior.
-== Security ==
+SECURITY
The design goal for this project is that an attacker may be able to deny
service (i.e. prevent you from recovering a file that was uploaded earlier)
capabilities).
-== Reliability ==
+RELIABILITY
File encoding and peer-node selection parameters can be adjusted to achieve
different goals. Each choice results in a number of properties; there are