On Mon, 17 Nov 2014 09:55:47 Gaudenz Steinlin wrote: > I agree that it makes sense to upgrade old pools. However there are some > downsides to this. Issueing this command immediately makes the cluster > unclean and leads to a degraded state. This command changes the > algorithm to distribute PGs to OSDs. The cluster then starts > backfilling to have a correct placement of all PGs again. This can > create quite substantial IO load on a cluster which you probably want to > plan for on a highly loaded production cluster. I guess this is also the > reason this command is not mentioned at all in the ceph.com upgrade > guide.
This is the same as with changing tunables. I dismiss the argument regarding
load to production cluster as upgrade should be planned and impact understood.
Anyway it is easy to unset "hashpspool" if it is set during sub-optimal time
for backfilling. Once again changing tunables profile will cause similar
effect and it is easily reversible.
> Maybe someone from ceph.com can shed some more light on this.
You've expressed its effect very eloquently. :)
> I suggest the attached patch to the README.Debian text. If you agree I
> will commit that change.
Yes please go ahead and apply in "experimental" branch.
I have only one suggestion which is to use word "misplaced" instead of
"degraded". In "Giant" upstream uses this terminology to distinguish between
"degraded" state (when there are not enough replicas) and "misplaced" state
(when objects due to be relocated). As far as I understand changing tunables
profile and/or (re-)setting "hashpspool" flag will merely case misplacement of
objects but not their degradation.
Thanks.
--
Cheers,
Dmitry Smirnov.
---
Gullibility and credulity are considered undesirable qualities in every
department of human life -- except religion.
-- Christopher Hitchens
signature.asc
Description: This is a digitally signed message part.
