Journal transactions
- To perform a journal transaction (i.e., write a group of file system changes
to stable storage), the kernel:
- Writes its planned updates to the journal area
- Writes a commit record to the journal area
- Barrier (waits for completion)
- Copies the updates from the journal area to the main file system
- Barrier
- Writes a completion record to the journal area
Overlapping journal transactions with other file system activity
- Journal writes for transaction \(\textit{tid}\) can run in parallel with
copying writes for transaction \(\textit{tid} - 1\)
- It is valid for several journal transactions to be active at once
- But production file systems keep it simple: one open transaction at a time
Recovery
- To recover after reboot, the kernel:
- Scans the journal area for valid transactions that are committed, but not yet complete
- For each such transaction in order:
- Copies the updates from the journal area to the main file system
- Barrier
- Writes a completion record for all committed transactions to the journal area
Question 1: Free block bitmap
- Assume a block was freed during transaction \(\textit{tid}\)
- When can that block be reused?
- Journal area contains at least two kinds of blocks
- Metadata blocks: commit records, completion records, possibly more
- Data blocks: user-defined, any block may be valid
- Assuming an infinite journal, design a mechanism to ensure that recovery
will never mistake a data block for a metadata block
Finite journal
- Now assume a finite journal area (e.g., at most 1000 journal blocks)
- This means journal blocks must be reused eventually
Question 3: Reusing journal blocks
- Assume a journal block (data or metadata) is part of transaction \(\textit{tid}\)
- When can that block be reused?
Question 4: Distinguishing data blocks again
- Assuming a finite journal, design a mechanism so that recovery will
never mistake a data block for a metadata block
Kinds of journaling
- It’s safest for all file system writes to go to the journal first
- However, this can be slow—e.g., when writing very large data files
- Can distinguish different kinds of block and handle them differently
- Absolute requirement: protect file system metadata (inode and directory contents, FBB)
- If these break, the file system is inconsistent & can become arbitrarily corrupt
- Lesser requirement: protect user data (file contents)
- If that breaks, the relevant file is garbage, but the file system will
not become arbitrarily corrupt
- Full journaling vs. metadata journaling