From: Zooko O'Whielacronx Date: Tue, 2 Feb 2010 05:27:50 +0000 (-0800) Subject: docs: a few small edits to performance.txt and README X-Git-Tag: allmydata-tahoe-1.6.0~5 X-Git-Url: https://git.rkrishnan.org/components/%22news.html//%22?a=commitdiff_plain;h=be1dac0e563db575597d07563501f05b25a8b875;p=tahoe-lafs%2Ftahoe-lafs.git docs: a few small edits to performance.txt and README --- 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