On Thu, Feb 4, 2016 at 3:25 AM, Xinze Chi (信泽) <xmdxcxz@xxxxxxxxx> wrote: > I wonder when the client receive OSDMap::Incremental and > apply_incremental, why not compare the OSDMap.crc with inc.full_crc, > like this https://github.com/ceph/ceph/blob/master/src/osd/OSD.cc#L6456 > > The OSDMonitor also check the crc when update OSMap, like this > https://github.com/ceph/ceph/blob/master/src/mon/OSDMonitor.cc#L247 The kernel client literally doesn't have the code to apply all of the changes and check the CRCs. If we don't do it on the userspace client I guess it was just laziness, but again they might not even get all of the data required to match CRCs; I forget. (For instance, if the monitors are generating an OSDMap with new features the clients don't understand and don't need to, the client won't be able to decode those parts of the OSDMap correctly, and will get a different crc value on it.) -Greg > > 2016-02-04 1:00 GMT+08:00 Gregory Farnum <gfarnum@xxxxxxxxxx>: >> On Wed, Feb 3, 2016 at 5:54 AM, Xinze Chi (信泽) <xmdxcxz@xxxxxxxxx> wrote: >>> hi, all: >>> >>> When osd update the osdmap, it would apply the >>> OSDMap::Incremental and get the crc for the new osdmap. If the crc is >>> not the same as define in Incremental osd would request the full >>> osdmap. I think the logic is quite well. >>> >>> But in the client, the objecter do not check the crc. I do not >>> know why not client do the same logic as osd. >>> >>> Could anyone explain this? Thanks. >> >> Two things: >> 1) The client doesn't necessarily have the full OSDMap that the OSDs >> do, so the CRC won't match. (You can see this in the encoding family >> of functions; there are sections which are server-only.) I suppose the >> monitors could include a client-only CRC as well... >> 2) Nobody bothered since it seemed less important for "ephemeral" >> clients versus OSDs that persist their maps and share them with peers. >> -Greg > > > > -- > Regards, > Xinze Chi -- 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
