On Thu, Oct 27, 2016 at 10:05:06PM +0800, Zhengyuan Liu wrote:
> Sorry for the unclear expression.
>
> The log might look like this before we did a recovery :
> | mb1 | mb2 | mb3 | | | |
> last_checkpoint = mb1'postion, last_cp_seq = mb1'seq
> After we did a recovery(we would write a empty meta block emb at log tail):
> | mb1 | mb2 | mb3 | emb | | |
> last_checkpoint = emb'position, last_cp_seq = mb1'seq + 11
> Then we write two meta blocks and suppose crash happens:
> | mb1 | mb2 | mb3 | emb | mb4 | mb5 |
> last_checkpoint = emb'position, last_cp_seq = mb1'seq + 11
> Now we did another recovery after restart and suppose mb4 was invalid:
> | mb1 | mb2 | mb3 | emb | mb4 | mb5 |
> last_checkpoint = emb'position, last_cp_seq = mb1'seq + 11
> Since mb4 was invalid, we would stop recovering mb5 which should be discarded.
> After recovery, log_start points to mb4 and we wouldn't write a empty meta block
> because condition "ctx.seq > log->last_cp_seq + 1" doesn't satisfy. If we are going to
> write a valid meta block and crash happens again, the new meta block will fall into
> position of mb4 and recovery process may do a recovery to mb5 since it's seq
> is matched.
>
> What I try to say is that if the first meta block ,not only the mid one, we written was
> invalid, the log recovery could bring problem here too . I think the condition for
> write a empty meta block should like this:
> - if (ctx.seq > log->last_cp_seq + 1) {
> + if (ctx.seq > log->last_cp_seq） {
Get it, thanks! That's correct, as long as we recover one block, we should
rewirte the empty meta block. I'll queue a patch for this.
Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
