Filesystems and I/O: Worked Examples

Work through each trace before reading the explanation. Then solve the transfer task without the page open.

Example 1: Acknowledgment needs a durability contract

A service changes an in-memory record, sends success, and only afterward persists it. A crash between success and persistence loses an acknowledged update.

For a write-ahead model, durably record the required recovery information before acknowledging the committed update. Recovery replays committed work according to the model. This is a logical ordering requirement; which flush operation enforces it depends on the actual storage stack and documented failure assumptions.

Example 2: Atomic replacement is not automatically durable replacement

Writing a temporary file and renaming it over a target can provide atomic namespace replacement on filesystems with that guarantee. A reader avoids observing a half-written target.

Power-loss durability additionally involves data and metadata persistence, potentially including the containing directory. Do not infer that a successful rename alone persists every relevant byte. State the target platform and verify its contract; process termination does not simulate every power-loss failure.

Transfer and self-check

A crash occurs after a durable commit record but before applying the update to its data page. What should recovery do? Check: redo the committed update according to the log and recovery scheme.

Evidence to keep

Save your first attempt, corrected reasoning, and transfer result as checkpoint evidence. A matching final answer without an explanation is insufficient. Continue with the guided lab and use the reading guide to repair a specific gap.