Record boundaries and repeatable replay
What this concept is
A recovery record must be recognizable as complete before applying its effect. The lab uses a sequence byte, after-image byte, XOR check and final commit marker. It ignores a short incomplete suffix and rejects malformed complete records rather than guessing where to resume.
Why it matters here
A crash may retain only a prefix of a new append. Treating those bytes as a committed update can invent state. Conversely, replay may run more than once, including after another crash; an after-image assignment is naturally repeatable, while a naive increment is not.
Concrete example
Record 1 assigns 7 and record 2 assigns 3. A durable prefix of six bytes contains the whole first record plus two bytes of the second. Recovery returns 7. With all eight bytes it returns 3. Replaying the complete log again still returns 3; adding the values to current data instead would produce a different result.
Common confusion / misconception
The XOR check does not detect every corruption and cannot authenticate data. A marker alone is also not proof of a valid record. This toy format has bounded sequence numbers, no wrap and no resynchronization. Those are explicit limitations, not production format recommendations.
How to use it
Validate all complete records before applying them. Track sequence continuity, check bytes and markers independently. Store after-images for this exercise. Retain the full log so older checkpoints can always be brought forward; do not introduce log truncation until a separate checkpoint/reclamation protocol is specified.
Check yourself
Can the model append new records after restarting with a two-byte incomplete tail? No: it refuses until a repair policy exists. Does ignoring a torn suffix mean ignoring corruption in the middle? No: a malformed complete record raises an error.
Mini drill or application
Enumerate every persisted prefix of two records. Predict recovered values before running. Then change replay assignment to addition and show both repeated recovery and repeated writes to the same slot failing.
Read this only if stuck
Use OSTEP file abstraction to distinguish bytes from records; the record protocol is an additional contract your program defines.