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?
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
--
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
