diff --git a/doc/source/admin_guide.rst b/doc/source/admin_guide.rst index a39d164534..99cd9c2446 100644 --- a/doc/source/admin_guide.rst +++ b/doc/source/admin_guide.rst @@ -209,7 +209,7 @@ Debugging Tips and Tools When a request is made to Swift, it is given a unique transaction id. This id should be in every log line that has to do with that request. This can -be usefult when looking at all the services that are hit by a single request. +be useful when looking at all the services that are hit by a single request. If you need to know where a specific account, container or object is in the cluster, `swift-get-nodes` will show the location where each replica should be. diff --git a/doc/source/development_auth.rst b/doc/source/development_auth.rst index afbe776bab..2ac1bdf261 100644 --- a/doc/source/development_auth.rst +++ b/doc/source/development_auth.rst @@ -39,8 +39,8 @@ will be omitted. It is highly recommended that authentication server implementers prefix their tokens and Swift storage accounts they create with a configurable reseller -prefix (`AUTH_` by default with the included DevAuth). This prefix will allow -deconflicting with other authentication servers that might be using the same +prefix (`AUTH_` by default with the included DevAuth). This prefix will avoid +conflicts with other authentication servers that might be using the same Swift cluster. Otherwise, the Swift cluster will have to try all the resellers until one validates a token or all fail. diff --git a/doc/source/getting_started.rst b/doc/source/getting_started.rst index cfaaa7cd2a..4ce0d934c0 100644 --- a/doc/source/getting_started.rst +++ b/doc/source/getting_started.rst @@ -15,7 +15,7 @@ most Linux platforms with the following software: And the following python libraries: * Eventlet 0.9.8 -* Webob 0.9.8 +* WebOb 0.9.8 * Setuptools * Simplejson * Xattr diff --git a/doc/source/overview_architecture.rst b/doc/source/overview_architecture.rst index 9a69f746a7..7cd56a8c7c 100644 --- a/doc/source/overview_architecture.rst +++ b/doc/source/overview_architecture.rst @@ -18,7 +18,7 @@ example, if a server is unavailable for an object PUT, it will ask the ring for a handoff server and route there instead. When objects are streamed to or from an object server, they are streamed -directly through the proxy server to of from the user -- the proxy server +directly through the proxy server to or from the user -- the proxy server does not spool them. -------- @@ -32,7 +32,7 @@ container, or account, they need to interact with the appropriate ring to determine its location in the cluster. The Ring maintains this mapping using zones, devices, partitions, and replicas. -Each partition in the ring is replicated, by default, 3 times accross the +Each partition in the ring is replicated, by default, 3 times across the cluster, and the locations for a partition are stored in the mapping maintained by the ring. The ring is also responsible for determining which devices are used for handoff in failure scenarios. diff --git a/doc/source/overview_reaper.rst b/doc/source/overview_reaper.rst index 020085dbc2..7959c2c557 100644 --- a/doc/source/overview_reaper.rst +++ b/doc/source/overview_reaper.rst @@ -28,7 +28,7 @@ delete times out, the container won't be able to be deleted later and therefore the account won't be deleted either). The overall process continues even on a failure so that it doesn't get hung up reclaiming cluster space because of one troublesome spot. The account reaper will keep trying to delete an account -until it evetually becomes empty, at which point the database reclaim process +until it eventually becomes empty, at which point the database reclaim process within the db_replicator will eventually remove the database files. -------