]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commitdiff
docs: a few small edits to performance.txt and README
authorZooko O'Whielacronx <zooko@zooko.com>
Tue, 2 Feb 2010 05:27:50 +0000 (21:27 -0800)
committerZooko O'Whielacronx <zooko@zooko.com>
Tue, 2 Feb 2010 05:27:50 +0000 (21:27 -0800)
README
docs/architecture.txt
docs/performance.txt

diff --git a/README b/README
index 5196751e147703c7a2e191fd7a6c19dd9d8aeadb..27f60b6475f664183208ada7642b0ccaf59cda6d 100644 (file)
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-Welcome to the Tahoe project [1], a secure, decentralized,
+Welcome to the Tahoe-LAFS project [1], a secure, decentralized,
 fault-tolerant filesystem.  All of the source code is available under
 a Free Software, Open Source licence (or two).
 
index a0abbf97a9091337674c682942eca8f4ef262be3..c1cc21536173127d5b4687d1f0b2910e678caae5 100644 (file)
@@ -199,9 +199,9 @@ servers.)
 
   Other peer-node selection algorithms are possible. One earlier version (known
   as "Tahoe 3") used the permutation to place the nodes around a large ring,
-  distributed shares evenly around the same ring, then walks clockwise from 0
-  with a basket: each time we encounter a share, put it in the basket, each
-  time we encounter a node, give them as many shares from our basket as they'll
+  distributed the shares evenly around the same ring, then walked clockwise from 0
+  with a basket. Each time it encountered a share, it put it in the basket, each
+  time it encountered a server, give it as many shares from the basket as they'd
   accept. This reduced the number of queries (usually to 1) for small grids
   (where N is larger than the number of nodes), but resulted in extremely
   non-uniform share distribution, which significantly hurt reliability
index 1c74f968bd1248253ecf263624dbbb56ec65ed1d..c5b4d9e4c09b75e1981b610ec8964a82d28fade6 100644 (file)
@@ -4,10 +4,10 @@
 
 cost:  O(A)
 
-notes: An immutable file uploaded using convergent encryption will
-       require an additional I/O pass over the entire source file before
-       the upload process can start, since convergent encryption derives
-       the encryption key in part from the contents of the source file.
+notes: An immutable file upload requires an additional I/O pass over the entire
+       source file before the upload process can start, since convergent
+       encryption derives the encryption key in part from the contents of the
+       source file.
 
 === Publishing an A-byte mutable file ===
 
@@ -38,14 +38,14 @@ notes: When asked to read an arbitrary range of an immutable file,
        file actually has to downloaded from the grid, reading part of an
        immutable file will result in downloading all of the immutable
        file. Ticket #798 is a proposal to change this behavior.
-       
+
        Tahoe-LAFS will cache files that are read in this manner for a
        short while, so subsequent reads of the same file may be served
        entirely from cache, depending on what part of the file they need
        to read, what part of the file was read by previous reads, and
        how much time has elapsed since the last read.
 
-=== Downloading B bytes of an A-byte mutable file === 
+=== Downloading B bytes of an A-byte mutable file ===
 
 cost:  O(A)
 
@@ -87,7 +87,7 @@ notes: In Tahoe-LAFS, directories are implemented as specialized mutable
 
 === Listing an A entry directory ===
 
-cost:  O(A) 
+cost:  O(A)
 
 notes: Listing a directory requires that the mutable file storing the
        directory be downloaded from the grid. So listing an A entry