On Wed, Mar 20, 2013 at 7:22 PM, Yan, Zheng <zheng.z.yan@xxxxxxxxx> wrote: > On 03/21/2013 02:40 AM, Greg Farnum wrote: >> The idea of this patch makes sense, but I'm not sure if we guarantee that each daemon sees every map update — if they don't then if an MDS misses the map moving an MDS into CLIENTREPLAY then they won't process them as having recovered on the next map. Sage or Joao, what are the guarantees subscription provides? >> -Greg > > See MDS::active_start(), it also kicks clientreplay waiters. And I will fix the 'clientreply' typo in my git tree. That's for the recovering MDS — I was referring to observers who are watching it come up. However, I've just checked and the monitor does guarantee every-map delivery, so this isn't a problem. Reviewed-by: Greg Farnum <greg@xxxxxxxxxxx> > > Thanks > Yan, Zheng > >> >> Software Engineer #42 @ http://inktank.com | http://ceph.com >> >> >> On Sunday, March 17, 2013 at 7:51 AM, Yan, Zheng wrote: >> >>> From: "Yan, Zheng" <zheng.z.yan@xxxxxxxxx (mailto:zheng.z.yan@xxxxxxxxx)> >>> >>> MDS in clientreply state already start servering requests. It also >>> make MDS::handle_mds_recovery() and MDS::recovery_done() match. >>> >>> Signed-off-by: Yan, Zheng <zheng.z.yan@xxxxxxxxx (mailto:zheng.z.yan@xxxxxxxxx)> >>> --- >>> src/mds/MDS.cc (http://MDS.cc) | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/src/mds/MDS.cc (http://MDS.cc) b/src/mds/MDS.cc (http://MDS.cc) >>> index 282fa64..b91dcbd 100644 >>> --- a/src/mds/MDS.cc (http://MDS.cc) >>> +++ b/src/mds/MDS.cc (http://MDS.cc) >>> @@ -1032,7 +1032,9 @@ void MDS::handle_mds_map(MMDSMap *m) >>> >>> set<int> oldactive, active; >>> oldmap->get_mds_set(oldactive, MDSMap::STATE_ACTIVE); >>> + oldmap->get_mds_set(oldactive, MDSMap::STATE_CLIENTREPLAY); >>> mdsmap->get_mds_set(active, MDSMap::STATE_ACTIVE); >>> + mdsmap->get_mds_set(active, MDSMap::STATE_CLIENTREPLAY); >>> for (set<int>::iterator p = active.begin(); p != active.end(); ++p) >>> if (*p != whoami && // not me >>> oldactive.count(*p) == 0) // newly so? >>> -- >>> 1.7.11.7 >> >> >> > -- 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
