Re: some issue about peering progress

[Gregory Farnum <gfarnum@redhat.com>]

On Fri, Oct 27, 2017 at 12:46 AM Xinze Chi (信泽) <xmdxcxz@gmail.com> wrote:
>
> hi, all:
>
>      I confuse about the notify message during peering. Such as:
>
>     epoch 1, primary osd do Pering , GetInfo and GetMissing, it
> calling the func  proc_replica_log. in this func the last_complete and
> last_update maybe reset.
>
>     Before go to Activate. the OSDMap change (the new osdmap do not
> lead to restart peering), the non-primary osd send the notify to
> primary.


I don't think this can happen. The OSD won't re-send a notify during
the same peering interval, and even if it did the message would be
tagged with a new (higher) epoch so the PG wouldn't process it until
after it had switched states, right?

>
>
>     When the primary receive the notify, Primary::react(const
> MNotifyRec& notevt), so it call the func proc_replica_info.
>
>     In the func, we update the pg info including last_complete and
> last_update which modified in proc_replica_log.

Note also that "PG::RecoveryState::Active::react(const MNotifyRec&
notevt)" does *not* unconditionally invoke proc_replica_info(). I
think you were trying to say we hadn't reached this state on receipt
of the message? But as I mentioned above, I think we block so that's
not actually possible either.

>
>     When the primary call the func activate, the primary osd  process
> recovering based on pg info got by notify instead of proc_replica_log.
>
>     so it is a bug?

Have you seen issues in the wild, or just trying to understand this
code/algorithm? I would be surprised if we had undiscovered issues
here just because our tests exercise peering quite vigorously, but I
might be missing what's happening in my own code skims.
-Greg