On 16/01/2015 19:10, Samuel Just wrote: > 1) The part where you add the operator<< and change the debug output looks good. > 2) The other part looks like it should be an assert? Or it should > complain to the central log so that it causes the test to fail at > least? Yes. I'd rather have it report to central log for now instead of asserting. If it asserts it will be impossible to know if it is the source of the problem or not. If it does not assert and the problem does not show up anymore, it will mean that the origin of this specific problem is that we have a bad peer in the ok peers. If it asserts, it may mean that sometime a bad peer is among the good peers but not necessarily that this is the source of the problem. If it does not assert and the problem persist it will mean that we have two problems : a bad peer in good peers and the peer_missing assert, as separate issues. Does that make sense ? > 1 and 2 should be separate commits. Ok. > -Sam > > On Fri, Jan 16, 2015 at 8:39 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: >> Hi Sam, >> >> In the context of http://tracker.ceph.com/issues/10524 FAILED assert(peer_missing.count(fromshard)) I propose to add some information for when it happens: >> >> https://github.com/ceph/ceph/pull/3389 >> >> If what happens really is that a bad peer ends up being added with in missing_loc.add_location, that will be a useful information. I tried a number of scenarios and could not find the right conditions to reproduce the problem locally. Hopefully this additional information will show me where to go :-) >> >> Cheers >> >> -- >> Loïc Dachary, Artisan Logiciel Libre >> -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
