doc: update crush weight ramping process

Signed-off-by: Sage Weil <sage@inktank.com>

diff --git a/doc/cluster-ops/add-or-rm-osds.rst b/doc/cluster-ops/add-or-rm-osds.rst
index ec24315ea54cb9ff2848556dd4f5ab7f10429579..ea891472f1c6f5282ce07e7891a24781d173986e 100644 (file)
--- a/doc/cluster-ops/add-or-rm-osds.rst
+++ b/doc/cluster-ops/add-or-rm-osds.rst
@@ -136,11 +136,33 @@ hard disks than older hosts in the cluster (i.e., they may have greater weight).
 
 .. topic:: Argonaut (v0.48) Best Practices
 
-   To limit impact on user I/O, add an OSD to the CRUSH map with an initial 
-   weight of ``0``. Then, ramp up the CRUSH weight a little bit at a time
-   (e.g., ``0.2``) and allow migration to complete. Continue to increment
-   the CRUSH weight until you reach your desired CRUSH weight. This practice
-   will no longer be necessary in Bobtail and subsequent releases.     
+ To limit impact on user I/O performance, add an OSD to the CRUSH map
+ with an initial weight of ``0``. Then, ramp up the CRUSH weight a
+ little bit at a time.  For example, to ramp by increments of ``0.2``,
+ start with::
+
+      ceph osd crush reweight {osd-id} .2
+
+ and allow migration to complete before reweighting to ``0.4``,
+ ``0.6``, and so on until the desired CRUSH weight is reached.
+
+ To limit the impact of OSD failures, you can set::
+
+      mon osd down out interval = 0
+
+ which prevents down OSDs from automatically being marked out, and then
+ ramp them down manually with::
+
+      ceph osd reweight {osd-num} .8
+
+ Again, wait for the cluster to finish migrating data, and then adjust
+ the weight further until you reach a weight of 0.  Note that this
+ problem prevents the cluster to automatically re-replicate data after
+ a failure, so please ensure that sufficient monitoring is in place for
+ an administrator to intervene promptly.
+
+ Note that this practice will no longer be necessary in Bobtail and
+ subsequent releases.
 
 
 Adding an OSD (Chef)