From: Loic Dachary <loic@dachary.org>
To: sjust@redhat.com
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: FAILED assert(peer_missing.count(fromshard))
Date: Fri, 16 Jan 2015 19:16:04 +0100 [thread overview]
Message-ID: <54B95564.3030703@dachary.org> (raw)
In-Reply-To: <CA+4uBUbcQ8OTg=SMnVN7tA5fGqmcqair=kSKKawGtf_+MDSYSA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
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@dachary.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2015-01-16 18:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 16:39 FAILED assert(peer_missing.count(fromshard)) Loic Dachary
2015-01-16 18:10 ` Samuel Just
2015-01-16 18:16 ` Loic Dachary [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54B95564.3030703@dachary.org \
--to=loic@dachary.org \
--cc=ceph-devel@vger.kernel.org \
--cc=sjust@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.