Crash Consistency and the Journal · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.

Journal records before home blocks

Computing · Computer Systems · ages 20-22
Name ______________________   Date ____________

  1. An unprotected rename removes the old entry durably. The new entry is not yet written when a crash occurs. Which naming result can remain?

    • Only the intended new name exists
    • Neither intended name exists
    • Both intended names still exist

  2. Why can a crash during an unprotected multi-block update cause inconsistency?

    • Some required block changes may persist while others do not
    • Every block update automatically becomes atomic
    • A crash affects RAM but cannot interrupt storage changes

  3. In the taught physical redo model, which order permits home metadata writes safely?

    • Home writes, then durable redo records and commit
    • Durable commit, then redo records with no durability wait
    • Durable redo records, durable commit, then home writes

  4. Recovery finds complete valid redo records and a durable commit, but home writes may be unfinished. What should it do in this model?

    • Replay the recorded metadata to its home blocks
    • Ignore it because commit proves home writes finished
    • Undo it because any unfinished home write cancels commit

  5. A metadata-only journal restores a consistent directory entry. Does that alone prove the latest user-data bytes were saved?

    • Yes; consistent names prove current contents
    • No; metadata recovery need not recover new user data
    • Yes; a metadata commit contains every user-data byte

  6. In the taught redo model, recovery ignores a transaction with no valid durable commit.

    Circle one:   True   False

  7. With no intervening writes, replaying the same committed metadata block image twice must create two separate files.

    Circle one:   True   False

  8. A designer makes home metadata changes durable before their redo records and commit. What crash risk does this introduce in the taught model?

    • None; issuing a log write makes it durable
    • Partial home changes can survive without a committed recovery log
    • Only slower replay; missing records are inferred
LightMySky · lightmysky.comW1-mt_I9DT0TUmiu-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Journal records before home blocks W1-mt_I9DT0TUmiu-s1

  1. Neither intended name exists · The old entry was removed, and the new one was not written. This says neither intended name remains, not that all file bytes were erased.
  2. Some required block changes may persist while others do not · A partial persistent update can violate the operation's expected result. Neither multi-block atomicity nor unaffected storage is automatic.
  3. Durable redo records, durable commit, then home writes · Complete redo records must be durable before commit, and commit must be durable before the home metadata changes.
  4. Replay the recorded metadata to its home blocks · The transaction qualifies for replay. Its commit establishes recovery eligibility, not completion of all home writes.
  5. No; metadata recovery need not recover new user data · Metadata consistency and user-data durability are different guarantees. A metadata-only journal need not contain the new file contents.
  6. True · The transaction is not eligible for replay. The model prevented its uncommitted metadata from reaching home blocks.
  7. False · Physical redo writes the same image to the same home block. Repeating that write leaves the same contents rather than running a file-copy command twice.
  8. Partial home changes can survive without a committed recovery log · A crash could retain partial home changes while losing the required redo records or commit. Recovery cannot rely on a committed log that is absent.
Worksheet · LightMySky