From: david-sarah Date: Mon, 27 Dec 2010 05:10:56 +0000 (-0800) Subject: docs: corrections and clarifications. X-Git-Url: https://git.rkrishnan.org/pf/content/en/footer?a=commitdiff_plain;h=83f97dcf7dc968ee8442bf5caf011a70a8971b90;p=tahoe-lafs%2Ftahoe-lafs.git docs: corrections and clarifications. --- diff --git a/docs/backupdb.rst b/docs/backupdb.rst index 15aaaee9..5a36b518 100644 --- a/docs/backupdb.rst +++ b/docs/backupdb.rst @@ -52,7 +52,7 @@ The database contains the following tables:: CREATE TABLE local_files ( - path varchar(1024), PRIMARY KEY -- index, this is os.path.abspath(fn) + path varchar(1024), PRIMARY KEY -- index, this is an absolute UTF-8-encoded local filename size integer, -- os.stat(fn)[stat.ST_SIZE] mtime number, -- os.stat(fn)[stat.ST_MTIME] ctime number, -- os.stat(fn)[stat.ST_CTIME] @@ -91,7 +91,8 @@ The first step is to convert the path to an absolute form is not present in this table, the file must be uploaded. The upload process is: -1. record the file's size, creation time, and modification time +1. record the file's size, ctime (which is the directory-entry change time or + file creation time depending on OS) and modification time 2. upload the file into the grid, obtaining an immutable file read-cap diff --git a/docs/frontends/CLI.rst b/docs/frontends/CLI.rst index 00953443..7bb2d7fa 100644 --- a/docs/frontends/CLI.rst +++ b/docs/frontends/CLI.rst @@ -120,9 +120,9 @@ contact that node instead of a local one. These commands also use a table of "aliases" to figure out which directory they ought to use a starting point. This is explained in more detail below. -As of Tahoe-LAFS v1.7 (v1.7.1 on Windows), passing non-ASCII characters to the -CLI should work. On Unix, the command-line arguments are assumed to use the -character encoding specified by the current locale. +As of Tahoe-LAFS v1.7.0 (v1.8.0 on Windows), passing non-ASCII characters to +the CLI should work. On Unix, the command-line arguments are assumed to use +the character encoding specified by the current locale. Starting Directories -------------------- diff --git a/docs/garbage-collection.rst b/docs/garbage-collection.rst index ef92d36e..88522839 100644 --- a/docs/garbage-collection.rst +++ b/docs/garbage-collection.rst @@ -35,13 +35,14 @@ of duration-over-renewal-time will be more robust in the face of occasional delays or failures. The current recommended values for a small Tahoe grid are to renew the leases -once a week, and to give each lease a duration of 31 days. Renewing leases -can be expected to take about one second per file/directory, depending upon -the number of servers and the network speeds involved. Note that in the -current release, the server code enforces a 31 day lease duration: there is -not yet a way for the client to request a different duration (however the -server can use the "expire.override_lease_duration" configuration setting to -increase or decrease the effective duration to something other than 31 days). +once a week, and give each lease a duration of 31 days. In the current +release, there is not yet a way to create a lease with a different duration, +but the server can use the ``expire.override_lease_duration`` configuration +setting to increase or decrease the effective duration (when the lease is +processed) to something other than 31 days. + +Renewing leases can be expected to take about one second per file/directory, +depending upon the number of servers and the network speeds involved. Client-side Renewal =================== @@ -65,13 +66,13 @@ Note that newly uploaded files (and newly created directories) get an initial lease too: the ``--add-lease`` process is only needed to ensure that all older objects have up-to-date leases on them. -For larger systems (such as a commercial grid), a separate "maintenance -daemon" is under development. This daemon will acquire manifests from -rootcaps on a periodic basis, keep track of checker results, manage -lease-addition, and prioritize repair needs, using multiple worker nodes to -perform these jobs in parallel. Eventually, this daemon will be made -appropriate for use by individual users as well, and may be incorporated -directly into the client node. +A separate "rebalancing manager/service" is also planned -- see ticket +`#543 `_. The exact +details of what this service will do are not settled, but it is likely to +work by acquiring manifests from rootcaps on a periodic basis, keeping track +of checker results, managing lease-addition, and prioritizing repair and +rebalancing of shares. Eventually it may use multiple worker nodes to perform +these jobs in parallel. Server Side Expiration ====================== @@ -170,9 +171,7 @@ The ``tahoe.cfg`` file uses the following keys to control lease expiration: This key is meant to compensate for the fact that clients do not yet have the ability to ask for leases that last longer than 31 days. A grid which wants to use faster or slower GC than a 31-day lease timer permits can - use this parameter to implement it. The current fixed 31-day lease - duration makes the server behave as if "lease.override_lease_duration = - 31days" had been passed. + use this parameter to implement it. This key is only valid when age-based expiration is in use (i.e. when ``expire.mode = age`` is used). It will be rejected if cutoff-date