Questions: Crash Consistency and Journaling File Systems

Question 1

To append a block to a file, a file system must write a new data block, update the inode to point to it, and mark the block as used in the data bitmap. Suppose a crash occurs after the inode write reaches the disk but before the bitmap write. What is the problem after reboot?

• A. There is no problem; the file is complete
• B. The inode points to a block that the bitmap says is free, so the block could later be given to another file
• C. The bitmap says a block is used, but no inode points to it, so the block is leaked
• D. The file's old contents are erased

Answer: (B)

The inode and bitmap now disagree. Because the bitmap marks the block free, the allocator may hand it to another file, and two files would share one block. (If the data block itself was not yet written, the inode would also point to old, garbage contents.) Option C describes the reverse crash, where the bitmap was written but the inode was not.

Question 2

In a journaling file system, at what point is a transaction considered committed, so that recovery will replay it?

• A. When the transaction-begin block is written to the journal
• B. When the first metadata block is written to the journal
• C. When the transaction-end (commit) block has been written to the journal after the rest of the transaction
• D. When all blocks have been written to their final locations on disk

Answer: (C)

The commit block is written only after the other journal blocks are safely on disk. On recovery, a transaction with a valid commit block is replayed; one without it is discarded. Writing blocks to their final locations, called checkpointing, happens after the commit.

Question 3

Journaling improves crash recovery partly because it writes each journaled metadata block to disk only once.

• T. True
• F. False

Answer: False

Journaled blocks are written twice: first into the journal, then to their home locations during checkpointing. The benefit is that recovery reads only the small journal instead of scanning the whole disk.

Question 4

Why is recovery with a journal usually much faster than running fsck on a large disk?

Model answer: fsck must scan all of the file system's metadata (every inode, bitmap and directory) to find and repair inconsistencies, so its time grows with the size of the disk. Journal recovery reads only the recent, small journal and replays committed transactions, so its time depends on how much recent activity there was, not on disk size.

As disks grew to terabytes, full scans took long enough to make journaling, used in ext3, ext4, NTFS and others, the standard approach.