Encode start index in open segment

[MathieuBordere]

Introduce a new disk format for the open segments, currently an open segment's first 8 bytes contain a version, I propose to update the version, and add a header at the beginning of an open segment, containing the first index of the entry encoded in the segment (and maybe some reserved space or just the index).

This would solve the following issues:

• There's no longer a need to have a barrier when taking a snapshot, the barrier is/was there to ensure that open segments detected on startup were newer than the snapshot, but even that is buggy, see next bullet.
• Solves a bug where when a node crashes after installing a snapshot, during removal of the segment files. The open segments left in the data folder would be considered newer than the snapshot and would be applied after it, while in fact they were older, leading to data corruption. (in case all closed segments were successfully deleted).
• We can remove the blocking/non-blocking barrier distinction, the non-blocking barrier was introduced to allow log entry writes to continue while the snapshot barrier was active.
• Simplifies the logic when loading the segments, we would no longer need to implicitly deduce the start index of the open-segment.

Fixes this TODO

raft/src/uv.c

Line 277 in d9e5752

* the last closed segment (TODO: we should encode the starting entry in the

Remark that once a system is on the new open segment format, it's no longer possible to revert to an older version of raft. Manual intervention is needed in that case to convert the open segments to the old format.

edit: Because a closed segment is just a renamed open-segment, the file format of the closed segments will change too.

[cole-miller]

This sounds great to me!

Solves a bug where when a node crashes after installing a snapshot, during removal of the segment files. The open segments left in the data folder would be considered newer than the snapshot and would be applied after it, while in fact they were older, leading to data corruption. (in case all closed segments were successfully deleted).

Have we observed this?

[MathieuBordere]

This sounds great to me!

Solves a bug where when a node crashes after installing a snapshot, during removal of the segment files. The open segments left in the data folder would be considered newer than the snapshot and would be applied after it, while in fact they were older, leading to data corruption. (in case all closed segments were successfully deleted).

Have we observed this?

No, but it's theoretically possible I think.

[MathieuBordere]

This sounds great to me!

Solves a bug where when a node crashes after installing a snapshot, during removal of the segment files. The open segments left in the data folder would be considered newer than the snapshot and would be applied after it, while in fact they were older, leading to data corruption. (in case all closed segments were successfully deleted).

Have we observed this?

No, but it's theoretically possible I think.

Correction, it's probably not possible, snapshot install will use a barrier that closes all open segments.

[cole-miller]

I think this is redundant with canonical/dqlite#578