On Wed, Feb 8, 2017 at 1:50 PM, John Spray <jspray@xxxxxxxxxx> wrote: > 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 :-) > That said, it might make sense for Ceph to wait a few minutes before starting to backfill after any osdmap changes. The current behaviour can be a little spastic at times. -- Dan > 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 -- 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
