]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc: adjust examples to use 2^n pg_num
authorLars Marowsky-Bree <lmb@suse.com>
Wed, 31 Jul 2019 13:02:25 +0000 (15:02 +0200)
committerNathan Cutler <ncutler@suse.com>
Thu, 29 Aug 2019 12:34:54 +0000 (14:34 +0200)
The examples used pg_num set to 300 or 1000. This misled some users.

Signed-off-by: Lars Marowsky-Bree <lmb@suse.com>
(cherry picked from commit bd20d692bb38d206ebe268c4a2da35e35622f285)

doc/rados/operations/placement-groups.rst

index 84e7fa47d841e21d60dea09a4424ca16051dbf17..ba7cb575848aef7ee79fa232c460742c600d9a2c 100644 (file)
@@ -382,14 +382,15 @@ makes every effort to evenly spread OSDs among all existing Placement
 Groups.
 
 As long as there are one or two orders of magnitude more Placement
-Groups than OSDs, the distribution should be even. For instance, 300
-placement groups for 3 OSDs, 1000 placement groups for 10 OSDs etc.
+Groups than OSDs, the distribution should be even. For instance, 256
+placement groups for 3 OSDs, 512 or 1024 placement groups for 10 OSDs
+etc.
 
 Uneven data distribution can be caused by factors other than the ratio
 between OSDs and placement groups. Since CRUSH does not take into
 account the size of the objects, a few very large objects may create
 an imbalance. Let say one million 4K objects totaling 4GB are evenly
-spread among 1000 placement groups on 10 OSDs. They will use 4GB / 10
+spread among 1024 placement groups on 10 OSDs. They will use 4GB / 10
 = 400MB on each OSD. If one 400MB object is added to the pool, the
 three OSDs supporting the placement group in which the object has been
 placed will be filled with 400MB + 400MB = 800MB while the seven