From 4104a7d581f6d2cf6d58514a752d04b31fe4e8f7 Mon Sep 17 00:00:00 2001 From: Paul Jimenez Date: Wed, 1 Sep 2010 21:42:24 -0500 Subject: [PATCH] fix some typos in the docs --- doc/source/deployment_guide.rst | 6 +++--- doc/source/development_saio.rst | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/source/deployment_guide.rst b/doc/source/deployment_guide.rst index 8ba9d660c0..0c2e52e59a 100644 --- a/doc/source/deployment_guide.rst +++ b/doc/source/deployment_guide.rst @@ -67,7 +67,7 @@ For example, imagine we are building a cluster that will have no more than 5,000 drives. That would mean that we would have a total number of 500,000 partitions, which is pretty close to 2^19, rounded up. -It is also a good idea to keep the number of partitions small (realatively). +It is also a good idea to keep the number of partitions small (relatively). The more partitions there are, the more work that has to be done by the replicators and other backend jobs and the more memory the rings consume in process. The goal is to find a good balance between small rings and maximum @@ -81,7 +81,7 @@ less likely you are to lose data. It is also important to determine how many zones the cluster should have. It is recommended to start with a minimum of 5 zones. You can start with fewer, but our testing has shown that having at least five zones is optimal when failures -occur. We also recommend trying to configure the zones as high a level as +occur. We also recommend trying to configure the zones at as high a level as possible to create as much isolation as possible. Some example things to take into consideration can include physical location, power availability, and network connectivity. For example, in a small cluster you might decide to @@ -121,7 +121,7 @@ important whenever making changes to the ring to make all the changes required before running rebalance. This will ensure that the ring stays as balanced as possible, and as few partitions are moved as possible. -The above process should be done to make a ring for each storage serivce +The above process should be done to make a ring for each storage service (Account, Container and Object). The builder files will be needed in future changes to the ring, so it is very important that these be kept and backed up. The resulting .tar.gz ring file should be pushed to all of the servers in the diff --git a/doc/source/development_saio.rst b/doc/source/development_saio.rst index 1eaaec5bbe..fb0e303db4 100644 --- a/doc/source/development_saio.rst +++ b/doc/source/development_saio.rst @@ -2,9 +2,9 @@ SAIO - Swift All In One ======================= ------------------------------------ -Instructions for seting up a dev VM ------------------------------------ +------------------------------------ +Instructions for setting up a dev VM +------------------------------------ This documents setting up a virtual machine for doing Swift development. The virtual machine will emulate running a four node Swift cluster. It assumes @@ -476,7 +476,7 @@ good idea what to do on other environments. cd /etc/swift - rm *.builder *.ring.gz backups/*.builder backups/*.ring.gz + rm -f *.builder *.ring.gz backups/*.builder backups/*.ring.gz swift-ring-builder object.builder create 18 3 1 swift-ring-builder object.builder add z1-127.0.0.1:6010/sdb1 1