openstack/swift
Code Issues Proposed changes

Fix some minor typos in the docs and also add a -f to a suggested script to make it less noisy on first run.

Browse Source
This commit is contained in:
Paul Jimenez 2010-09-03 13:22:12 +00:00 committed by Tarmac
commit 6a0e8bf44b
2 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/deployment_guide.rst
View File

@ -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

8
doc/source/development_saio.rst
View File

@ -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