On Mon, 19 Oct 2015, Xusangdi wrote: > > > -----Original Message----- > > From: ceph-devel-ow...@vger.kernel.org > > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of > > Chen, Xiaoxi > > Sent: Monday, October 19, 2015 9:11 AM > > To: xusangdi 11976 (RD) > > Cc: ceph-devel@vger.kernel.org > > Subject: RE: chooseleaf may cause some unnecessary pg migrations > > > > Sorry but not following... > > > > > then shut down one or more osds (please don't touch the crushmap, just > > > stop the osd service or kill > > its process). > > > > In this case, OSD is only down but not out, but will be marked out after > > 300s. > > > > So in what case your patch is helping? > > > > If you said your patch helps on "down and out" , then my experiment > > is exactly the case, > > > > I am afraid it is probably not. Could you tell me how did you simulate > the osd "down and out" situation using crushtool? If it was done by > arguments such as '--remove-item' or 'reweight-item', it modified the > crushmap and is not what I'm aiming for.
There is a --weight argument (noted in usage near --test, which is the only piece that uses it). The crush map is not modified--only the weight vector that is passed in when a mapping is calculated (which is the equivalent of the in/out state in Ceph's OSDMap). This should let you simulate this case. When I'm debugging/understanding these issues I usually change the dprintk #define at the top of crush/mapper.c and use crushtool or osdmaptool to calculate a single mapping, comparing the log before and after a particular change. sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
