On Wed, Feb 8, 2017 at 12:41 PM, Blair Bethwaite <blair.bethwaite@xxxxxxxxx> wrote: > Hi John, > > ceph osd set nobackfill/norecover/norebalance ? > > It's not something you want to accidentally leave set, but is use > nonetheless - I'm using it right at this moment to load an edited > crushmap and examine the PG remapping impact before actually pulling > the trigger and letting things sort themselves out (if I decide not to > I can always re-inject the previous/current crushmap). Ah ha, of course nobackfill is the one. I am exposing my lack of experience in actually operating a cluster here :-) John > > Cheers, > > On 8 February 2017 at 23:26, John Spray <jspray@xxxxxxxxxx> wrote: >> So I've just finished upgrading my home cluster OSDs to bluestore by >> killing them one by one and then letting backfill happen to "new" OSDs >> on the same drives. Hooray! >> >> One slightly awkward thing I ran into was that even though I had noout >> set throughout, during the period between removing the old OSD and >> adding the "new" one, some PGs would of course get remapped (and start >> generating backfill IO to third party OSDs). This does make sense >> when you think about it (noout doesn't make the cluster magically >> remember OSDs that have been removed), but is still an undesirable >> behaviour. >> >> A) Do we currently have a mechanism to tell the cluster "even though I >> removed this OSD, don't go moving PGs around just yet"? Should we add >> one? >> B) Was there a way for me to avoid this by e.g. skipping the "osd rm >> X" and "osd crush rm osd.X" that I'm currently doing before adding the >> new OSD that will take the old OSD's ID? >> >> John >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Cheers, > ~Blairo -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
