What is File System Consistency Checking (fsck)?
Learn how fsck detects and repairs file system corruption after a crash, and why journaling reduces the need for full scans.
Expected Interview Answer
File system consistency checking is the process of scanning on-disk metadata — inodes, directory entries, block bitmaps, and free lists — after an unclean shutdown to detect and repair structural inconsistencies before the file system is mounted for normal use.
When a crash or power loss interrupts a metadata update partway through — for example a new inode is linked into a directory but the block bitmap was never marked allocated — the on-disk structures can disagree with each other. A consistency checker such as fsck walks every inode, cross-checks link counts against directory entries, verifies that every allocated block is claimed by exactly one inode, and rebuilds the free-block bitmap from what it actually finds referenced. Anything unreferenced becomes a lost-and-found entry rather than being silently discarded, and any inode with a mismatched link count is corrected. Because a full scan touches every inode and block on the volume, fsck on a large spinning disk can take hours, which is why modern systems prefer journaling or copy-on-write designs that make full-volume scans unnecessary after most crashes.
- Repairs structural corruption left by an unclean shutdown
- Recovers orphaned data via lost-and-found rather than discarding it
- Rebuilds free-space bitmaps to prevent double-allocation
- Explains why journaling exists as a faster alternative
AI Mentor Explanation
A consistency check is like a scorer reconciling the paper scoreboard against the umpire’s counting after a rain delay cut the recording short mid-over. Every run, wicket, and extra on the board is cross-checked against what actually happened on the field, and any run credited to nobody gets logged separately for review rather than deleted. A full reconciliation of an entire innings takes far longer than just trusting a clean, ball-by-ball log kept throughout, which is why scorers prefer live logging over end-of-innings reconstruction.
Step-by-Step Explanation
Step 1
Detect unclean state
On mount, the OS checks a dirty bit or superblock flag set when the volume was not cleanly unmounted.
Step 2
Scan metadata
The checker walks every inode, directory entry, and block bitmap, cross-referencing link counts and allocation claims.
Step 3
Reconcile inconsistencies
Mismatched link counts are corrected, and blocks referenced by no inode or by multiple inodes are flagged.
Step 4
Recover or repair
Orphaned data is moved into lost-and-found, free-space bitmaps are rebuilt, and the volume is marked clean.
What Interviewer Expects
- Understanding of why an unclean shutdown causes metadata inconsistency
- Knowledge of what fsck actually checks (inodes, link counts, bitmaps)
- Awareness that full scans are slow on large volumes
- Ability to contrast fsck-style checking with journaling as prevention
Common Mistakes
- Thinking fsck runs on every normal boot regardless of shutdown state
- Believing fsck recovers lost data perfectly rather than just relocating it
- Not knowing why journaling reduces the need for full scans
- Confusing file system consistency checking with disk defragmentation
Best Answer (HR Friendly)
“File system consistency checking is the safety-net process that runs after a computer was not shut down properly, scanning the disk’s internal bookkeeping to make sure every file and free block is accounted for correctly. It fixes mismatches so the file system is safe to use again, though it can take a while on large disks, which is part of why modern systems use journaling to avoid needing a full check in the first place.”
Code Example
struct inode_info {
int inode_num;
int stored_link_count; /* value recorded on disk */
int counted_links; /* recomputed by scanning directories */
};
void reconcile_link_counts(struct inode_info *inodes, int n) {
for (int i = 0; i < n; i++) {
if (inodes[i].stored_link_count != inodes[i].counted_links) {
/* directory scan found a different reference count than
the inode itself claims -- trust the directory scan */
fix_inode_link_count(inodes[i].inode_num,
inodes[i].counted_links);
}
}
}Follow-up Questions
- How does journaling reduce the need for a full fsck scan?
- What happens to blocks that are allocated but referenced by no inode?
- Why can two inodes claiming the same block be a serious bug?
- How does a copy-on-write file system like ZFS avoid classic fsck entirely?
MCQ Practice
1. What primarily triggers a file system consistency check on mount?
The superblock records whether the volume was cleanly unmounted; an unclean flag triggers a consistency check before normal use.
2. What happens to a data block found on disk but referenced by no inode?
Rather than discard unreferenced data, the checker typically recovers it into a lost-and-found directory for manual inspection.
3. Why do modern systems prefer journaling over relying solely on full fsck scans?
A journal replays only the in-flight transactions from before the crash, avoiding a slow full-volume metadata scan.
Flash Cards
What is file system consistency checking? — Scanning on-disk metadata after an unclean shutdown to detect and repair structural inconsistencies.
What does fsck cross-check? — Inode link counts against directory entries, and block bitmaps against actual allocation.
Where does orphaned data go? — Into a lost-and-found directory rather than being deleted.
Why is journaling preferred over full fsck? — It avoids scanning the entire volume by replaying only in-flight transactions.