added more content to the moveChunk command page.

Author: Andrew Leung

source/administration/sharding.txt

@@ -619,17 +619,16 @@ In most circumstances, you should let the automatic balancer
 migrate :term:`chunks <chunk>` between :term:`shards <shard>`.
 However, you may want to migrate chunks manually in a few cases:
 
-- If you create chunks by presplitting the data in your collection,
+- If you create chunks by :term:`pre-splitting` the data in your collection,
   you will have to migrate chunks manually to distribute chunks
   evenly across the shards.
 
 - If the balancer in an active cluster cannot distribute chunks within
   the balancing window, then you will have to migrate chunks manually.
 
-To further understand the chunk migration process in detail, see the
-:ref:`sharding-chunk-migration` section, and how to improve throughput
-for a shard cluster, see the
-:ref:`sharding-administration-create-chunks` section.
+See the :ref:`chunk migration <sharding-chunk-migration>` section to
+understand the internal process of how :term:`chunks <chunk>` move
+between :term:`shards <shard>`.
 
 To migrate chunks, use the :dbcommand:`moveChunk` command.
 
@@ -659,6 +658,10 @@ This command moves the chunk that includes the shard key value "smith" to the
 :term:`shard` named ``mongodb-shard3.example.net``. The command will
 block until the migration is complete.
 
+See :ref:`create chunks <sharding-administration-create-chunks>` to
+understand how to use :term:`pre-splitting` to improve initial data
+load on a :term:`shard cluster`.
+
 .. versionadded:: 2.2
    :dbcommand:`moveChunk` command has the: ``_secondaryThrottle``
    paramenter. When set to ``true``, MongoDB ensures that

source/faq/sharding.txt

@@ -342,7 +342,7 @@ Consider the following error message:
    ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
 
 :program:`mongod` procudes this message if, during a :ref:`chunk
-migration <sharding-chunk-migration>`, the term:`shard` could not
+migration <sharding-chunk-migration>`, the :term:`shard` could not
 connect to the :term:`config database` to update chunk information. If
 the shard cannot update the config database after
 :dbcommand:`moveChunk`, the shard cluster will have an inconsistent

source/reference/command/moveChunk.txt

@@ -6,22 +6,64 @@ moveChunk
 
 .. dbcommand:: moveChunk
 
-   :dbcommand:`moveChunk` is an internal command that supports the
-   sharding. Use the :method:`sh.moveChunk()` helper in the
-   :program:`mongo` shell for manual chunk migrations.
+   :dbcommand:`moveChunk` is an internal command that moves
+   :term:`chunks <chunk>` between :term:`shards <shard>`. The command
+   uses the following syntax:
+
+   .. code-block:: javascript
+
+      db.runCommand( { moveChunk : <namespace> ,
+                       find : <query> ,
+                       to : <destination>,
+                       <options> } )
+
+   :param moveChunk: the name of the :term:`collection` which the :term:`chunk`
+     exists. The collection's full namespace must be given, including
+     the database name, for example: ``"test.blog.posts"``
+
+   :param find: a query expression that specifies a document of the chunk
+     to be moved, for example: ``{ author: "eliot" }``
+
+   :param to: the shard ID where the chunk will be moved to, for
+     example: ``"shard1"``
+
 
    :option _secondaryThrottle: Set to ``false`` by default. Provides
-                               :ref:`write concern <write-concern>`
-                               support for chunk migrations.
-
-   If ``_secondaryThrottle`` is set to ``true``, during chunk
-   migrations when a :term:`shard` hosted by a :term:`replica set`,
-   the :program:`mongod` will wait until the :term:`secondary` members
-   replicate the migration operations continuing to migrate chunk
-   data. In the balancer configuration, the ``replThrottle``
-   configuration provides ``_secondaryThrottle`` behavior.
-
-   For details on chunk migrations see the :ref:`Chunk Migration
-   <sharding-chunk-migration>` section.
+     :ref:`write concern <write-concern>` support for chunk
+     migrations.
+
+     If ``_secondaryThrottle`` is set to ``true``, during chunk
+     migrations when a :term:`shard` hosted by a :term:`replica set`,
+     the :program:`mongod` will wait until the :term:`secondary`
+     members replicate the migration operations continuing to migrate
+     chunk data. In the balancer configuration, the ``replThrottle``
+     configuration provides ``_secondaryThrottle`` behavior.
+
+   Use the :method:`sh.moveChunk()` helper in the :program:`mongo`
+   shell for manual chunk migrations.
+
+   For details on how chunks move within MongoDB see the :ref:`chunk
+   migration <sharding-chunk-migration>` section.
+
+   :dbcommand:`moveChunk` will return the following ``errmsg`` if the
+   :term:`chunk` to be moved is in use by another :term:`cursor`:
+
+   .. code-block:: none
+
+      The collection's metadata lock is already taken.
+
+   These errors usually occur when there are too many open
+   :term:`cursors <cursor>` accessing the chunk you are migrating. You
+   can either wait until the cursors complete their operation or close
+   the cursors manually.
+
+   .. note::
+
+      This command should not be used except in special circumstances
+      such as preparing your :term:`shard cluster` for an initial
+      ingest of data.
+
+      .. seealso:: ":ref:`Create chunk <sharding-administration-create-chunks>`"
+
 
    .. admin-only