mirror of
https://github.com/tahoe-lafs/tahoe-lafs.git
synced 2024-12-23 23:02:25 +00:00
Minor documentation tweaks.
This commit is contained in:
parent
59a77f82d7
commit
87ddf54ed8
@ -1,10 +1,22 @@
|
||||
= Tahoe-LAFS Architecture =
|
||||
|
||||
Tahoe-LAFS Architecture
|
||||
1. Overview
|
||||
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 ==
|
||||
|
||||
(See the docs/specifications directory for more details.)
|
||||
|
||||
OVERVIEW
|
||||
|
||||
There are three layers: the key-value store, the filesystem, and the
|
||||
application.
|
||||
|
||||
@ -31,7 +43,7 @@ There are several other applications built on top of the Tahoe-LAFS
|
||||
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
|
||||
@ -64,7 +76,7 @@ For future releases, we have plans to decentralize introduction, allowing any
|
||||
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
|
||||
@ -105,7 +117,7 @@ turn them into segments of ciphertext, use the decryption key to convert that
|
||||
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
|
||||
@ -137,7 +149,7 @@ filesystem layer (described below) adds human-meaningful names atop the
|
||||
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.
|
||||
@ -238,7 +250,7 @@ servers.)
|
||||
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
|
||||
@ -269,7 +281,7 @@ in the same facility, so the helper-to-storage-server bandwidth is huge.
|
||||
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
|
||||
@ -299,7 +311,7 @@ links to spaces that are shared with specific other users, and other spaces
|
||||
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,
|
||||
@ -320,7 +332,7 @@ See docs/garbage-collection.txt for further information, and how to configure
|
||||
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
|
||||
@ -377,7 +389,7 @@ to other nodes.
|
||||
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)
|
||||
@ -441,7 +453,7 @@ normal web site, using username and password to give a user access to her
|
||||
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
|
||||
|
@ -1,4 +1,4 @@
|
||||
= Tahoe FTP/SFTP Frontend =
|
||||
= Tahoe FTP and SFTP Frontends =
|
||||
|
||||
1. FTP/SFTP Background
|
||||
2. Tahoe Support
|
||||
@ -6,6 +6,8 @@
|
||||
4. Configuring FTP Access
|
||||
5. Configuring SFTP Access
|
||||
6. Dependencies
|
||||
7. Immutable and mutable files
|
||||
|
||||
|
||||
== FTP/SFTP Background ==
|
||||
|
||||
@ -24,6 +26,7 @@ Both FTP and SFTP were developed assuming a UNIX-like server, with accounts
|
||||
and passwords, octal file modes (user/group/other, read/write/execute), and
|
||||
ctime/mtime timestamps.
|
||||
|
||||
|
||||
== Tahoe Support ==
|
||||
|
||||
All Tahoe client nodes can run a frontend FTP server, allowing regular FTP
|
||||
@ -49,6 +52,7 @@ HTTP-based login mechanism, backed by simple PHP script and a database. The
|
||||
latter form is used by allmydata.com to provide secure access to customer
|
||||
rootcaps.
|
||||
|
||||
|
||||
== Creating an Account File ==
|
||||
|
||||
To use the first form, create a file (probably in
|
||||
@ -72,6 +76,7 @@ either of these strings.
|
||||
Then add an 'accounts.file' directive to your tahoe.cfg file, as described
|
||||
in the next sections.
|
||||
|
||||
|
||||
== Configuring FTP Access ==
|
||||
|
||||
To enable the FTP server with an accounts file, add the following lines to
|
||||
@ -96,6 +101,7 @@ that server in an "accounts.url" directive:
|
||||
You can provide both accounts.file and accounts.url, although it probably
|
||||
isn't very useful except for testing.
|
||||
|
||||
|
||||
== Configuring SFTP Access ==
|
||||
|
||||
The Tahoe SFTP server requires a host keypair, just like the regular SSH
|
||||
|
Loading…
Reference in New Issue
Block a user