edits: typo changes

Author: Sam Kleinman

draft/reserved-keywords.txt

@@ -15,12 +15,13 @@ best-practice configurations for common use cases.
 
 While both interfaces provide access to the same collection of options
 and settings, this document primarily uses the configuration file
-interface. If you run MongoDB using a control script or a package for
-your operating system, you likely already have a configuration file
-located at ``/etc/mongodb.conf``. Confirm this by checking the content
-of the ``/etc/init.d/mongod`` or ``/etc/rc.d/mongod`` script to
-insure that the :term:`control scripts <control script>` start the
-:program:`mongod` with the appropriate configuration file (see below.)
+interface. If you run MongoDB using a control script or installed from
+a package for your operating system, you likely already have a
+configuration file located at ``/etc/mongodb.conf``. Confirm this by
+checking the content of the ``/etc/init.d/mongod`` or
+``/etc/rc.d/mongod`` script to insure that the :term:`control scripts
+<control script>` start the :program:`mongod` with the appropriate
+configuration file (see below.)
 
 To start MongoDB instance using this configuration issue a command in
 the following form:

source/administration/configuration.txt

@@ -271,7 +271,7 @@ Diagnosing Performance Issues
 -----------------------------
 
 Degraded performance in MongoDB can be the result of an array of
-causes, and is typically a function of the relationship amongst the
+causes, and is typically a function of the relationship among the
 quantity of data stored in the database, the amount of system RAM, the
 number of connections to the database, and the amount of time the
 database spends in a lock state.

source/administration/monitoring.txt

@@ -71,7 +71,7 @@ For MongoDB on Linux use the following recommended configurations:
   database files are acceptable. See the :ref:`Readahead
   <production-readahead>` section
 
-- Use NTP to synchronize time amongst your hosts. This is especially
+- Use NTP to synchronize time among your hosts. This is especially
   important in sharded clusters.
 
 .. _production-readahead:
@@ -406,13 +406,13 @@ Additionally, see information on :ref:`replica set rollbacks
 Additional Deployment Considerations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- Pick your shard keys carefully! They cannot be changed except
-  manually by making a new collection.
+- Pick your shard keys carefully! There is no way to modify a shard
+  key on a collection that is already sharded. 
 
-- You cannot shard an existing collection over 256 gigabytes. You
-  could as a workaround create a new sharded collection and copy over
-  the data via some script -- albeit that will likely take a while at
-  this size.
+- You cannot shard an existing collection over 256 gigabytes. To shard
+  large amounts of data, create a new empty sharded collection, and
+  ingest the data from the source collection using an application
+  level import operation.
 
 - Unique indexes are not enforced across shards except for the shard
   key itself. See :doc:`/tutorial/enforce-unique-keys-for-sharded-collections`.
@@ -422,8 +422,8 @@ Additional Deployment Considerations
   necessary but on a bulk import of size it is helpful.
 
 - Use :doc:`security/auth </administration/security/>` mode if you
-  need it. It is not on by default; rather a trusted environment is
-  assumed.
+  need it. By default :setting:`auth` is not enabled and
+  :program:`mongod` assumes a trusted environment.
 
 - You do not have :doc:`fully generalized transactions
   </tutorial/isolate-sequence-of-operations/>`. Create rich documents
@@ -439,14 +439,10 @@ Additional Deployment Considerations
 
 - Check :doc:`ulimits </administration/ulimit/>` settings.
 
-- Use SSD if available and economical. Spinning disks can work well but
-  SSDs and MongoDB are a nice combo. See :ref:`production-nfs` for more
-  info.
-
-- Maintain reasonable pool sizes on clients. If you have 100 client
-  machines and each has a pool size of 1000 connections, that would be
-  a worst case of 100,000 connections to MongoDB -- which would be too
-  many to a single :program:`mongod` or :program:`mongos` (if connected to a
-  cluster with many :program:`mongos`, then 100,000 connections may be ok).
-  Try to maintain a
-  reasonable number: 1K is fine; 100K is too much; 10K is ok.
+- Use SSD if available and economical. Spinning disks can work well
+  but SSDs capcity for random I/O operations work well with the update
+  model of :program:`mongod`. See :ref:`production-nfs` for more info.
+
+- Ensure that clients keep reasonable pool sizes to avoid overloading
+  the connection tracking capacity of a single :program:`mongod` or
+  :program:`mongos` instance.

source/administration/production-notes.txt

@@ -691,7 +691,7 @@ free pace created by document deletion or relocation.
 
 However, in those exceptions where you must pad manually, you can use
 the strategy of first adding a temporary field to a document and then
-:operator:`$unset <$unset>` the field, as in the following example:
+:operator:`$unset` the field, as in the following example:
 
 .. code-block:: javascript
 

source/faq/developers.txt

@@ -1,4 +1,3 @@
-.. _mongodb_extended_json:
 =====================
 MongoDB Extended JSON
 =====================