How Linux Recovers from File Corruption Using fsck

File system corruption in Linux typically arises from sudden power loss, hardware malfunctions, or kernel crashes that interrupt write operations. To restore integrity, the Linux operating system utilizes fsck (File System Consistency Check), a core maintenance utility that inspects the underlying data structures, resolves metadata inconsistencies, repairs broken directory trees, and safely isolates unlinked data blocks. This article breaks down how fsck operates, its phased repair process, and how it recovers corrupted file systems to ensure system stability.

Understanding the Role of fsck

The fsck utility serves as a frontend wrapper that calls file-system-specific checkers based on the target partition, such as e2fsck for ext2/ext3/ext4, fsck.vfat for FAT filesystems, or xfs_repair for XFS. Its primary responsibility is auditing file system metadata—such as superblocks, inode tables, allocation bitmaps, and directory structures—to ensure that the physical layout on disk matches the logical state expected by the Linux kernel.

How fsck Is Triggered

Linux initiates fsck through two primary methods:

The Multi-Pass Repair Mechanism

For standard Linux filesystems like ext4, fsck executes a structured, multi-pass procedure to detect and resolve errors without destroying valid data:

1. Replaying the Journal

On modern journaled file systems, fsck first checks the file system journal. If transactions were mid-flight during a crash, fsck replays completed transactions to bring the metadata up to date or discards incomplete ones to restore the last known consistent state. Often, this resolves the issue within seconds without requiring a deep scan.

2. Pass 1: Checking Inodes and Blocks

fsck inspects every inode (the data structure holding metadata about a file, excluding its name and actual content). It checks for valid file sizes, proper block counts, and illegal or overlapping block assignments. If two files claim ownership of the exact same physical block, fsck marks it for resolution to prevent data collisions.

3. Pass 2: Checking Directory Structures

The utility traverses the directory hierarchy, ensuring that all directory entries point to valid inodes identified in Pass 1. It validates directory headers, checks for invalid characters or zero-length filenames, and removes references to corrupted or non-existent inodes.

4. Pass 3: Checking Directory Connectivity

fsck verifies that every directory is connected back to the root directory. If a directory has been disconnected due to corrupted parent pointers, fsck reconnects it to the filesystem's dedicated recovery directory.

5. Pass 4: Checking Reference Counts

Files can have multiple hard links pointing to the same inode. Pass 4 cross-references the actual link count discovered in Pass 2 and Pass 3 with the link count stored inside each inode. Any mismatch is corrected to prevent files from being accidentally freed while still referenced, or remaining locked when deleted.

6. Pass 5: Checking Cylinder Group and Allocation Bitmaps

Finally, fsck compares the actual block and inode allocations discovered during the previous passes against the filesystem’s allocation bitmaps. Free blocks that are mistakenly marked as used are reclaimed, and used blocks marked as free are properly protected from being overwritten.

The lost+found Recovery Directory

When fsck encounters an inode that contains valid data but has lost its filename and parent directory path, the utility cannot deduce where the file originally belonged. Rather than deleting the data, fsck creates a new directory link inside the partition's /lost+found directory.

The recovered files are named using their unique inode numbers (e.g., #1234567). Users and administrators can inspect these files using utilities like the file command to determine their content type and manually restore them to their intended locations.