Operating Systems Practice Question 9: Journal Crash Recovery
Operating Systems · Test 1 · question 9 of 10
A file system uses data journaling. To append a block to a file it (1) writes a transaction to the journal (the new inode, bitmap and data block) (2) writes a commit block for that transaction, then (3) checkpoints the blocks to their final on-disk locations. Power fails after step 2 completes but while step 3 is only half done: the new inode is in place, but the bitmap and data block are not.
What happens when the machine boots?
Show answer and explanation
Answer:
Journaling (write-ahead logging) writes a description of the update to the log *before* touching the real structures. Once the commit block is safely on disk, the transaction is durable. If a crash happens after commit but before checkpointing completes, recovery at boot scans the log, finds committed transactions, and replays them in order, rewriting every block to its final location. Blocks that were already written are simply written again, so the half-done checkpoint is harmless. (If the crash had happened *before* the commit was on disk, the transaction would just be skipped.)
Option A is wrong: the commit block, not the checkpoint, is the point of no return. Throwing away a committed transaction would lose an update the file system had already made durable.
Option C describes fsck, the approach journaling was designed to replace. Recovery reads only the small journal instead of the whole disk, which is why journaled file systems come back quickly.
Option D is the inconsistency journaling prevents. Replay rewrites the bitmap and the data block too, so the inode and the bitmap agree again after recovery.