I...think so? Did you have a specific purpose in mind, though? I might
have missed something when I was going through it. ;)
-Greg
On Thu, Oct 5, 2017 at 7:11 AM, Xinze Chi (信泽) <xmdxcxz@xxxxxxxxx> wrote:
> so we could roll forward no matter object > last_backfill or <
> last_backfill, as long as it is backfill target?
> If so, we could set backfill in ECSubWrite true if it is backfill target?
>
> 2017-10-05 2:11 GMT+08:00 Gregory Farnum <gfarnum@xxxxxxxxxx>:
>> On Fri, Sep 29, 2017 at 5:19 PM, Xinze Chi (信泽) <xmdxcxz@xxxxxxxxx> wrote:
>>> such as transaction a would modify the object a < last_backfill, so
>>> transaction_applied would be true. Before transaction a is completed,
>>> the transaction b which modify the object b > last_backfill,
>>> so transaction_applied would be false, the current logic would
>>> roll_forward which including object a and b? is it right?
>>
>> Yes, I believe that's the case. It's just that we don't care very much
>> — if we copied the data while backfilling, we know that our source
>> peer has the rollback state. Keep in mind that we only have rollback
>> so that we can avoid the "RAID write hole" — eg, if we manage to write
>> down an update on 4 nodes in a 5+3 erasure code, we can recover
>> neither the old nor new data if it was written in-place. So we keep
>> rollback data in that case and everybody goes back to the previous
>> state.
>>
>> I *think* that if we manage to backfill an object for a particular
>> shard, then we know that we can roll forward on it anyway or the read
>> would have failed and the OSDs would have already rolled back. But I
>> didn't check that. Certainly doing something other than this automatic
>> roll forward would require a lot more bookkeeping that would make
>> everything else going on more difficult.
>> -Greg
>>
>>>
>>>
>>> 2017-09-30 2:27 GMT+08:00 Gregory Farnum <gfarnum@xxxxxxxxxx>:
>>>> On Fri, Sep 29, 2017 at 3:02 AM, Xinze Chi (信泽) <xmdxcxz@xxxxxxxxx> wrote:
>>>>> hi, all
>>>>>
>>>>> I confuse the roll_forward logic in the PG::append_log. The
>>>>> pg_log.roll_forward func may roll forward the all inflight
>>>>> transactions which maybe not be completed by all shards.
>>>>>
>>>>> The comment also makes me wonder. so could anyone explain it in
>>>>> detail. thanks.
>>>>>
>>>>>
>>>>> if (!transaction_applied) {
>>>>> /* We must be a backfill peer, so it's ok if we apply
>>>>> * out-of-turn since we won't be considered when
>>>>> * determining a min possible last_update.
>>>>> */
>>>>> pg_log.roll_forward(&handler);
>>>>> }
>>>>>
>>>>> /* We don't want to leave the rollforward artifacts around
>>>>> * here past last_backfill. It's ok for the same reason as
>>>>> * above */
>>>>> if (transaction_applied &&
>>>>> p->soid > info.last_backfill) {
>>>>> pg_log.roll_forward(&handler);
>>>>> }
>>>>
>>>> transaction_applied can only be false if we are being backfilled. If
>>>> we are being backfilled, we may not *have* the older data that we
>>>> would rollback to, and our peers don't rely on us having that data. So
>>>> there's no point in our trying to keep rollback data around, and
>>>> keeping it around would mean finding a way to clean it up later. Thus,
>>>> delete it now.
>>>> -Greg
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Xinze Chi
>
>
>
> --
> 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
