anchor.diff:  
   NOTE: Mappings may not be specified in the `_split` request.
   
  -[float]
  -==== Monitoring the split process
  +
  +[[monitor-split]]
  +==== Monitor the split process
   
   The split process can be monitored with the <<cat-recovery,`_cat recovery`
   API>>, or the <<cluster-health, `cluster health` API>> can be used to wait
  
positive.code: properties of the default number of routing shards will then apply to the
  newly split index.
  
  [float]
  ==== How does splitting work?
  
  Splitting works as follows:
  
  * First, it creates a new target index with the same definition as the source
    index, but with a larger number of primary shards.
  
  * Then it hard-links segments from the source index into the target index. (If
    the file system doesn't support hard-linking, then all segments are copied
    into the new index, which is a much more time consuming process.)
  
  * Once the low level files are created all documents will be `hashed` again to delete
    documents that belong to a different shard.
  
  * Finally, it recovers the target index as though it were a closed index which
    had just been re-opened.
  
  [float]
  [[incremental-resharding]]
  ==== Why doesn't Elasticsearch support incremental resharding?
  
  Going from `N` shards to `N+1` shards, aka. incremental resharding, is indeed a
  feature that is supported by many key-value stores. Adding a new shard and
  
negative.code: old and new indices have respectively +M+ and +N+ shards, this has no overhead
  compared to searching an index that would have +M+N+ shards.
  
  
  [[split-index]]
  ===== Split an index
  
  To split `my_source_index` into a new index called `my_target_index`, issue
  the following request:
  
  [source,console]
  --------------------------------------------------
  POST /my_source_index/_split/my_target_index
  {
    "settings": {
      "index.number_of_shards": 2
  