From 738c1fe326107a3e0c9acca105fee56a6ab86241 Mon Sep 17 00:00:00 2001 From: Lars Marowsky-Bree Date: Wed, 31 Jul 2019 15:02:25 +0200 Subject: [PATCH] doc: adjust examples to use 2^n pg_num The examples used pg_num set to 300 or 1000. This misled some users. Signed-off-by: Lars Marowsky-Bree (cherry picked from commit bd20d692bb38d206ebe268c4a2da35e35622f285) --- doc/rados/operations/placement-groups.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/rados/operations/placement-groups.rst b/doc/rados/operations/placement-groups.rst index 84e7fa47d841e..ba7cb575848ae 100644 --- a/doc/rados/operations/placement-groups.rst +++ b/doc/rados/operations/placement-groups.rst @@ -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 -- 2.39.5