Re: Fw:Re:Re:Re: Question about write op processing of OSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 15, 2016 at 8:29 PM, xxhdx1985126 <xxhdx1985126@xxxxxxx> wrote:
>
> Sorry, I correct my question.
>
> I read the "already_complete" method. It returns true if it all op ealier than M is "all_committed" in repop_queue, so in our scenario, it will always return true, since OSD.X was not acting primary of the target pg. Then, what if when the resubmitted M arrives when the previous M has not been committed? If we ack the client not considering if the req has already been committed, wouldn't there be a possibility that things go wrong? For example, what if after OSD.X ack the client, the actual commit of M fails?
>
> Thank you:-)

You'll need to be more specific about what pieces you're looking at. I
don't think anything referencing OSD operation IDs will always return
true just because OSD.X wasn't acting primary in a previous interval,
for instance, but I dunno which bits you're referring to. In general
during the peering process the OSDs will agree on which set of
operations were logically "completed" (regardless of local state) and
either throw out everything outside that set or else block any
subsequent operations until it can see their results.
-Greg

>
>
>
> At 2016-12-16 10:09:56, "xxhdx1985126" <xxhdx1985126@xxxxxxx> wrote:
>>
>>Thanks for the quick reply:-)
>>
>>Is it possible that the client resubmit M after the new "Peering" process completes but before the processing of M is completed on OSD.X? I'm asking this because as far as I understand, if the "dup" req is not already completed, the OSD will put it in the "waitingg_for_ondisk" and "waiting_for_ack" queue which are only accessed when the previous repop completes "commit" and "apply" process and are not accessed in this scenario since there is no such "previous repop".
>>
>>Thanks:-)
>>
>>At 2016-12-16 08:35:15, "Gregory Farnum" <gfarnum@xxxxxxxxxx> wrote:
>>>On Thu, Dec 15, 2016 at 4:17 PM, xxhdx1985126 <xxhdx1985126@xxxxxxx> wrote:
>>>>
>>>> Hi, everyone.
>>>>
>>>>
>>>> What will the OSD do in the following scenario?
>>>>
>>>>        Say, a MOSDRepop M that is initiated at client A is being processed on an OSD.X, during which the acting primary turn "down" due to some error and OSD.X is chosen to be the new acting primary. Since OSD.X is a replica OSD for MOSDRepOp M, how can client A be acked after OSD.X finished the processing of M? Or does A be acked at all in this kind of circumstances?
>>>
>>>The client is not acked by OSD.X, but when the client sees the OSDMap
>>>marking down the previous primary, it will resubmit MOSDOpM to OSD.X
>>>(and increment the retry counter). OSD.X will notice that MOSDOpM has
>>>already been completed and reply with the same answer it gave
>>>previously.[1]
>>>-Greg
>>>[1]: Barring protocol or implementation bugs. There have historically
>>>been some issues with things like (successful) deletes returning
>>>ENOENT instead of 0; I don't remember if all the known ones have been
>>>squashed or not.
--
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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux