From be1dac0e563db575597d07563501f05b25a8b875 Mon Sep 17 00:00:00 2001
From: Zooko O'Whielacronx <zooko@zooko.com>
Date: Mon, 1 Feb 2010 21:27:50 -0800
Subject: [PATCH] docs: a few small edits to performance.txt and README

---
 README                |  2 +-
 docs/architecture.txt |  6 +++---
 docs/performance.txt  | 14 +++++++-------
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/README b/README
index 5196751e..27f60b64 100644
--- 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).
 
diff --git a/docs/architecture.txt b/docs/architecture.txt
index a0abbf97..c1cc2153 100644
--- a/docs/architecture.txt
+++ b/docs/architecture.txt
@@ -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
diff --git a/docs/performance.txt b/docs/performance.txt
index 1c74f968..c5b4d9e4 100644
--- a/docs/performance.txt
+++ b/docs/performance.txt
@@ -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
-- 
2.45.2